The First Hour After a Suspected Breach: How to Help Your Incident Responders Help You

It often starts with something small.

A senior executive support staff member clicks what appears to be a legitimate document-sharing link. The email looks familiar, the branding is recognisable, and the request does not seem unusual in the context of a busy workday. Within hours, suspicious activity begins appearing across the organisation's Microsoft 365 environment.

The mailbox is accessed from unfamiliar external infrastructure. Audit logs show repeated mailbox access events, SharePoint and OneDrive file activity, outbound email behaviour, movement or deletion of notification emails, and changes to mailbox settings. By the next morning, a new inbox rule has been created - a common business email compromise technique used to hide replies, suppress warnings, move security alerts, or reduce the chance of detection by the mailbox owner.

The affected account belongs to someone in a trusted administrative or executive support role. That makes it high value. It may contain sensitive correspondence, meeting information, governance material, internal communications, and access to documents shared across the organisation. From an attacker's perspective, this type of account can be useful for fraud, impersonation, invoice manipulation, further phishing, or gathering intelligence about the business.

This scenario is common enough that many organisations will face some version of it. The details change, but the first-hour priorities remain the same: preserve the evidence, contain the immediate risk, understand the likely scope, and give responders the information they need to move quickly without losing visibility.

When an organisation suspects it has been breached, the first hour matters.

Not because every incident can be solved in sixty minutes. It cannot. The first hour matters because early decisions often determine whether responders can clearly understand what happened, preserve useful evidence, and contain the incident without accidentally making things worse.

In many breaches, the organisation's first instinct is to move quickly: reset passwords, shut down systems, delete suspicious emails, wipe devices, block everything, or start making changes across the environment. Those actions can feel productive, and sometimes they are necessary. But without direction, they can also destroy evidence, interrupt forensic visibility, or make it harder to understand the attacker's path.

A better first-hour response is not panic. It is structured action.

At Clearnet Labs, we often tell organisation's that the goal of the first hour is simple:

Protect the organisation while preserving enough evidence to understand the breach properly.

Start With What You Know

The first step is to slow the incident down just enough to write down the facts.

That does not mean delaying containment. It means avoiding guesswork. Before major changes are made, capture what is currently known:

• Who noticed the issue?
• What did they observe?
• When did it start?
• Which user, mailbox, system, device, or application is involved?
• What actions have already been taken?
• What systems may be affected?
• Are there signs of data access, account compromise, malware, suspicious logins, or unauthorised email activity?

This early record becomes extremely valuable. In the middle of an incident, details change quickly. Staff may reset credentials, devices may reboot, logs may rotate, and alerts may disappear from dashboards. A short written timeline helps responders separate facts from assumptions.

Even rough notes are useful:

9:31 AM - User clicked suspicious link in email.
10:05 AM - User reported unusual Microsoft 365 prompt.
11:13 AM - Suspicious mailbox access observed from unfamiliar IP address.
11:25 AM - ICT disabled account and contacted incident response provider.

This kind of timeline gives responders a starting point and helps focus the investigation.

Preserve Evidence Before Cleaning Up

One of the most common mistakes during an incident is removing the very artefacts responders need.

Suspicious emails are deleted. Devices are wiped. Browser history is cleared. Mailbox rules are removed without screenshots. Cloud sessions are revoked without capturing session details. Logs are exported too late, after retention windows have passed.

Good incident response depends on evidence. Where possible, preserve before changing.

Useful evidence may include:

• Suspicious emails, including full headers
• URLs clicked by the user
• Screenshots of alerts, login prompts, mailbox rules, or suspicious activity
• Sign-in logs and audit logs
• Endpoint detection alerts
• Firewall, VPN, proxy, and DNS logs
• Device hostnames, usernames, and IP addresses
• Copies of suspicious files, where safe to preserve
• Details of any accounts used by the attacker

For Microsoft 365 or Google Workspace incidents, mailbox audit logs, sign-in logs, OAuth consent activity, inbox rules, forwarding rules, and file access logs can be especially important. For endpoint incidents, responders may need memory, disk, process, network, or EDR telemetry before the machine is rebuilt.

The key principle is simple:

Capture first, clean second.

Contain the Smallest Thing First

Containment is essential, but broad containment can have consequences.

Disabling every account, shutting down entire systems, or blocking large parts of the network may interrupt business operations and alert the attacker before responders understand their access. On the other hand, waiting too long can allow the attacker to continue moving through the environment.

The practical approach is to contain the smallest confirmed area first.

If a single user account appears compromised, disable that account, revoke active sessions, reset credentials, and check for persistence such as mailbox rules or registered MFA methods. If a single endpoint appears infected, isolate that endpoint from the network rather than powering it off immediately, unless there is a safety reason to do so. If a malicious email is identified, preserve a copy and then search for other recipients.

Good containment is targeted. It reduces attacker access while keeping the investigation intact.

Do Not Assume the First Alert Is the Whole Incident

The first thing you see is often not the first thing that happened.

A suspicious login may be the result of credentials harvested earlier. A mailbox rule may indicate an account was compromised days before. A malware alert may be the final stage of a longer intrusion. A file access alert may be one action within a broader business email compromise or data theft event.

This is why responders need context, not just the alert.

Helpful questions include:

• Has this user reported phishing recently?
• Were there suspicious MFA prompts?
• Was the user travelling or using a VPN?
• Were any files accessed, shared, downloaded, or deleted?
• Were any mailbox rules, forwarding rules, or OAuth applications added?
• Were other users targeted by the same email?
• Are there related alerts from identity, endpoint, email, or network tools?

The first hour should aim to define the likely scope, not prematurely close the incident around the first visible symptom.

Give Responders Access to the Right People and Systems

Incident response slows down when responders cannot access the logs, people, or systems needed to investigate.

Organisations can help by quickly identifying:

• A primary technical contact
• A business decision-maker
• Someone with access to identity logs
• Someone with email security access
• Someone with endpoint or EDR access
• Someone who understands the affected system or application
• A communications contact for internal updates

For cloud and SaaS incidents, responders may need access to Microsoft Entra ID, Microsoft Defender, Exchange Online, Purview, Google Workspace Admin, firewall logs, VPN logs, EDR platforms, SIEM tooling, or backup systems.

The faster the right people are involved, the faster responders can confirm what happened.

Record Every Action Taken

During an incident, every action matters.

If an account is disabled, record the time. If a password is reset, record who did it. If a device is isolated, record when and how. If a firewall rule is added, record the change. If an email is removed from mailboxes, record the query used and the number of messages removed.

This matters for two reasons.

First, responders need to distinguish attacker activity from defender activity. Second, leadership may later need a clear timeline for reporting, insurance, legal review, or customer communications.

A simple action log is enough:

The action log does not need to be perfect. It just needs to exist.

Communicate Clearly, But Carefully

Good communication reduces confusion. Poor communication can create panic.

In the first hour, avoid broad statements such as "we have been hacked" unless the facts support that conclusion. Use clear, factual language:

We are investigating suspicious activity involving one user account. The account has been disabled while we review sign-in and mailbox activity. Further updates will follow once the scope is confirmed.

This kind of message is calm, accurate, and avoids overcommitting before the investigation has caught up.

Internal communications should also remind staff not to delete suspicious emails, forward them externally, or discuss sensitive incident details in public channels. If the suspected breach involves email or chat systems, consider whether those channels are safe for incident coordination.

What Organisations Can Do Before an Incident

The first hour is much easier when preparation has already happened.

Every organisation should know, before an incident occurs:

• Who has authority to declare an incident?
• Who contacts the incident response provider?
• Where are logs stored?
• How long are logs retained?
• Who can access identity, email, endpoint, and firewall logs?
• How are backups protected?
• How are privileged accounts secured?
• What systems are business-critical?
• What communication channel will be used if email is compromised?

Preparation does not need to be complicated. A one-page incident contact sheet and a basic first-hour checklist can make a major difference.

A Practical First-Hour Checklist

If you suspect a breach, focus on the following:

1. Write down what happened, when it was noticed, and who is involved.
2. Preserve suspicious emails, alerts, logs, screenshots, and affected device details.
3. Contain the smallest confirmed area first.
4. Avoid wiping, rebooting, or deleting evidence unless required for safety or business continuity.
5. Record every action taken by ICT or the business.
6. Identify the right technical and business contacts.
7. Contact your incident response provider early.
8. Use careful, factual internal communication.

The aim is not to solve everything immediately. The aim is to give responders enough clarity and evidence to act effectively.

Clarity Beats Speed Without Direction

In the first hour after a suspected breach, speed matters. But speed without direction can cause damage.

The organisations that respond best are not the ones that panic fastest. They are the ones that preserve evidence, contain carefully, communicate clearly, and bring the right people together quickly.

A breach investigation is a team effort. The client knows the environment. The responders know the investigation process. When both sides work from a clear first-hour plan, the organisation has a much better chance of understanding what happened, limiting the impact, and recovering with confidence.

Clearnet Labs helps organisations prepare for, investigate, and respond to cyber incidents. If you are unsure whether your current first-hour process would hold up under pressure, now is the time to test it - before an incident forces the question.