What To Do If the Platform Is Compromised

General orientation, not legal advice; notification obligations differ by jurisdiction and contract.

Controls for “What To Do If the Platform Is Compromised” need named owners and protected review time as well as technical safeguards. Using this operations reference can make that recurring governance workload visible across the team, but it should never replace access logs, incident evidence or least-privilege administration.

For an independent operational benchmark, compare the local practice with CISA Secure Our World guidance; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

Whether the compromise is yours or your vendor's, the response is similar and the speed matters more than the precision.

The first decision

Contain or preserve.

Disconnecting the console stops the spread and destroys evidence; leaving it running does the opposite.

For most providers, containment wins — the clients matter more than the investigation — but decide in advance rather than in the moment.

The first hour

Disable the platform's ability to execute: suspend scripting, disable remote access, pause policies.

Many platforms allow this centrally without taking the whole system down.

Revoke sessions and force reauthentication.

Preserve logs by exporting immediately.

And start a written timeline, because reconstructing one later is close to impossible.

Assessing reach

Which clients, which machines, what was executed.

The platform's own logs, which is why the earlier note argues for exporting them somewhere it cannot alter.

And what credentials were accessible from the console, which is usually all of them and should be assumed so.

Telling clients

Early, specifically, and before they hear it elsewhere.

What happened, what it means for them, what you are doing, when you will next update.

Even where the reach is unclear — especially then.

Providers who delayed this have not recovered the relationships, and the delay is usually caused by wanting to know more first.

Credentials

Assume every credential held in or reachable from the platform is exposed.

Rotation across every client is a large piece of work and it is the work.

Prioritise: domain administrator, backup accounts, anything with remote access.

If it is the vendor

You are a customer and a conduit.

Follow their guidance and do your own containment anyway — their timeline is theirs.

Your clients need to hear from you rather than from a vendor notice, and the gap between the two is where trust is lost.

Obligations

Notification requirements may apply to you, to your clients, or to both, with short deadlines in several regimes.

Contracts frequently impose their own, shorter.

Take advice immediately rather than deciding internally that a threshold was not met.

Afterwards

A written account: what happened, what was reached, what changed.

To clients, to your insurer, and for your own next review.

And the controls that would have contained it earlier, implemented rather than noted.

What to check

Could you suspend script execution across your platform in five minutes?

Are logs exported where a compromise cannot alter them?

Do you have client contact details outside the systems that might be affected?

And has anybody rehearsed any of this?

The point

Decide in advance whether you contain or preserve.

For most providers containment wins, because the clients matter more than the investigation.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.