Stop it continuing: change credentials, revoke sessions, isolate affected systems, and preserve evidence. Write down what you do as you do it, and start the assessment once containment holds.

Containment before understanding

The natural response to discovering a compromise is to find out what happened.

That is the wrong first move, because whatever caused it is frequently still running: an attacker still logged in, a forwarding rule still copying mail, or a compromised account still sending.

Every minute spent reconstructing the story is a minute the situation continues to develop.

Stop it, then understand it. The investigation is considerably easier once nothing further is happening, and the evidence you need will still be there if you preserve it.

The first fifteen minutes

The second is the one people miss. Changing a password does not necessarily end an existing session, so an attacker can remain logged in for days afterwards.

Forwarding rules are the usual persistence

Worth checking specifically because it is the most common way access outlives a password change.

Somebody with access to a mailbox frequently creates a rule copying incoming mail elsewhere, or filtering certain messages so the real owner does not see them.

Those rules survive a password change, keep working silently, and are how a compromise that appears resolved continues for months.

Check rules, forwarding settings, delegated access, connected applications, and any recovery address or phone number that has been altered.

The altered recovery details are the other one: an attacker who has changed the recovery email can regain access after you have locked them out.

Preserve as you go

The step that is easy while containing and impossible afterwards.

Take screenshots of what you find before you change it: the rule, the unfamiliar session, the message, the login history.

Export logs if the system offers them, since many retain sign-in history for a limited period and it will roll off.

Keep the actual emails rather than forwarding descriptions of them.

And start a plain document, timestamped, recording what you observed and what you did.

That record is what your assessment, your insurer, and any report will be built from, and reconstructing it from memory three days later produces something considerably less useful.

Do not delete anything

An instinct worth resisting explicitly.

Deleting the fraudulent messages, wiping the machine, or clearing the mailbox feels like cleaning up and destroys the evidence of what happened and what was accessed.

The same applies to reinstalling a compromised machine before anybody has looked at it.

Isolate rather than erase: disconnect the machine, park the mailbox, and leave the contents alone until you know whether anybody needs to examine them.

If the incident turns out to be minor you have lost nothing by preserving. If it turns out to be serious, you have kept the only record of it.

A worked example

A firm discovered a compromised mailbox when a customer asked about an invoice nobody had sent.

The first action was containment: password changed, all sessions signed out, two-factor enabled.

Checking rules found two. One forwarded everything containing the word invoice to an external address. The other moved messages from their bank into an archive folder so nobody would see them.

Both were screenshotted before removal.

Sign-in history showed access from an unfamiliar location going back six weeks, which was exported before it aged out.

Only then did they start working out what had been accessible: six weeks of correspondence, including customer details and two invoices with bank information.

The whole containment took under an hour, and the record made the assessment that followed straightforward rather than speculative.

Who to tell in the first hour

A short list, and it is not customers yet.

Whoever needs to act: your own staff, so nobody acts on instructions from the compromised account, and your supplier or IT contact if you have one.

Anybody at immediate risk of a payment: if a fraudulent invoice has gone out, telling those recipients is urgent rather than something to plan.

Your insurer, promptly, because cyber policies frequently require notification within a short period and some provide response support you have already paid for.

Customer notification comes after assessment, because you cannot usefully tell people what happened until you know, and a hurried first message that turns out to be wrong is worse than one sent a day later.

Then assess

Once nothing further is happening, the questions become answerable.

What was accessible, which is broader than what you can prove was taken.

Whose information was in it, and which fields.

Whether that combination creates real risk of significant harm, which is the question notification and reporting decisions turn on.

How it happened, which determines what you change.

Write the assessment down with your reasoning, whichever way it comes out, because a documented decision is what you rely on later and an undocumented one is indistinguishable from not having decided.

The counter-case

Not every incident warrants a formal response, and treating everything as a breach exhausts people.

A blocked phishing attempt, a spam message nobody clicked, or a password reset done as a precaution are not incidents and do not need a document.

There is also a risk in acting so fast that you destroy evidence or lock out a colleague on a false alarm, so a moment establishing that something has actually happened is not wasted.

The threshold worth applying is whether somebody had access they should not have had, or whether information left your control. Below that, note it and move on.

Above it, containment in the first hour is what limits the size of everything that follows.

The first hour

  1. Change credentials on affected accounts.
  2. Sign out all sessions separately.
  3. Check rules, delegates, and recovery details.
  4. Isolate machines rather than wiping them.
  5. Screenshot and export before changing anything.
  6. Warn anybody at risk of an imminent payment.
  7. Notify your insurer, then start the assessment.

Step three is where compromises survive an otherwise correct response, and it takes five minutes to check.

Recovery depends on backups, covered in backups nobody has tested.


Frequently asked questions

What should I do first?

Stop it continuing rather than work out what happened. Whatever caused it is frequently still running, and every minute spent reconstructing the story is a minute it develops further.

Is changing the password enough?

No. Changing a password does not necessarily end existing sessions, so sign out all sessions as a separate action and enable two-factor if it was not on.

What is the most commonly missed step?

Checking for forwarding rules, delegated access, connected applications, and altered recovery details. Those survive a password change and are how a compromise continues silently.

Should I wipe the affected machine?

No. Isolate rather than erase. Deleting messages or reinstalling before anybody has looked destroys the record of what happened and what was accessible.

When do I tell customers?

After assessment. You cannot usefully tell people what happened until you know, and a hurried first message that turns out to be wrong is worse than one sent a day later.

Does every incident need this?

No. A blocked phishing attempt or a precautionary password reset is not a breach. The threshold is whether somebody had access they should not have, or information left your control.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Mailbox behaving strangely?

Sign out all sessions and check for forwarding rules before anything else. That is where access survives a password change.

Start a Conversation