Insider Sabotage Response Playbook: Stop a privileged insider before deletion spreads

An administrator who decides to cause damage already holds the access, knows where the backups are and can plant something that fires after they leave. In a case prosecuted in the US, a former Cisco engineer who had resigned around April 2018 accessed the company's AWS environment that September and deployed code that deleted 456 virtual machines for Webex Teams; over 16,000 accounts were shut down for up to two weeks, and Cisco reported about $1.4 million in staff time to restore the service and over $1 million in customer refunds. Sabotage differs from data theft: the goal is disruption, the damage is often immediate and irreversible, and the timing of HR and legal action can trigger it. This template is for incident responders, identity and cloud teams, HR and legal handling deliberate destruction, backdoors or logic bombs by a current or former insider. Theft of data is handled in the Insider Data Theft Response Playbook.

How to use this template

• Replace placeholders: [Organisation], [IdP], [cloud providers], [backup platform] and the bracketed thresholds with your own values.
• Keep it need to know: the suspect may be on the distribution list for normal incident channels, may administer the ticketing system, and may read security alerts. Run this playbook in a restricted channel with named members only.
• Sequence HR and technical actions: the moment a privileged insider learns they are suspected or being dismissed is the moment of greatest risk. Section 4 defines the order.
• Preserve evidence for court: CISA defines virtual sabotage as malicious action through technical means to disrupt or stop normal business operations, and these cases often end in prosecution or civil claims, so chain of custody matters from the first hour.

1. Scope and triggers

This playbook applies to sabotage by any [Organisation] employee, contractor, supplier staff or former insider, against on-premises, cloud, SaaS, OT or code assets. Invoke it on any of the following:

• Destructive activity by an insider identity: mass deletion of virtual machines, storage, databases, repositories or backups (ATT&CK T1485 Data Destruction, T1490 Inhibit System Recovery) by an account belonging to, or recently used by, a known person.
• Lockout of others: administrator accounts removed, passwords changed or MFA methods reset for colleagues (T1531 Account Access Removal).
• Planted code or persistence: unexplained scheduled tasks (T1053.005), cron jobs, scripts checking for an account's existence, new accounts (T1136) or added credentials on service principals (T1098).
• Post-departure access: any activity by a leaver's account, key or token after their exit date.
• Credible warning: a manager, HR or colleague reports threats to damage systems, often around performance action, demotion or dismissal.

Out of scope: accidental deletion by an authorised administrator (handle through operations and change review) and external attackers using stolen insider credentials (use the incident response plan, but check this list).

2. Roles and contacts

3. Detection and triage

1. Is destruction happening now? If yes, go straight to section 4, step 1. Preserve evidence in parallel, not first.
2. Which identities are involved? List the person's human accounts and every non-human credential they could use: personal access tokens, SSH keys, cloud access keys, service principal secrets, API keys, signing keys and shared admin passwords.
3. Is it the insider, or someone using their account? Check device, location and sign-in context. Do not assume either way; both lead to containment.
4. What is at risk next? Identify backups, logging, identity provider and code pipelines the person could reach, since saboteurs commonly target recovery and evidence.
5. Rate severity:

4. Containment

Order of actions for a planned dismissal or suspension

1. Prepare quietly: build the full access list (human and non-human), confirm backups are immutable and current, and stage revocation scripts. Do not change anything the person would notice.
2. Revoke at the same moment the person is told: HR holds the meeting while the identity lead disables accounts and revokes sessions. Not before (which tips them off) and not after (which leaves a window).
3. Collect devices and badges during the meeting, with physical security present if needed.

Revocation checklist

• Identity provider: disable the user and revoke sessions. Microsoft documents disabling the account, running Revoke-MgUserSignInSession and disabling registered devices, and warns that existing access tokens remain valid until they expire (one hour by default) unless the application supports Continuous Access Evaluation, and that app-issued session cookies depend on each application.
• Active Directory: disable the account and reset the password twice; Microsoft notes the double reset mitigates pass-the-hash risk.
• Non-human credentials: rotate every key, token and secret the person created or could read, including cloud access keys, CI tokens and signing keys. A former Coupang engineer reportedly kept a token signing key that was never rotated after he left; see the Coupang Breach 2025.
• Shared and break-glass credentials: rotate any shared admin, root or emergency passwords the person knew.
• External access: VPN, remote access tools, personal devices enrolled in MDM, and any third-party SaaS where they were an administrator.
• Stop ongoing destruction: if deletion is running, apply a deny policy at the cloud organisation level (for example an AWS service control policy or Azure deny assignment) for the identities involved, and pause automation pipelines they control.

Decision: when there is a credible threat but no technical activity yet, the incident commander, HR and legal choose between covert monitoring (to gather evidence of planted mechanisms before acting) and immediate coordinated revocation. Monitor only where local law and employment terms allow it, for a defined short period, and only if backups are confirmed immutable; otherwise revoke. Smaller organisations, where one administrator may be the only person who knows a system, should first secure working access for a second trusted person, then revoke. Any destructive activity ends the monitoring option at once.

5. Eradication

• Hunt for planted mechanisms: scheduled tasks, cron jobs, systemd timers, CI jobs, serverless functions and scripts created or modified by the person in the last [12] months, especially code that checks whether an account exists or is enabled.
• Find hidden access: new local or cloud accounts, extra credentials on service principals and IAM users, SSH keys in authorized_keys, OAuth apps they consented to, and mailbox forwarding rules.
• Review code changes: commits by the person to production repositories and infrastructure as code, with a second engineer reviewing each one.
• Check data integrity: sabotage can mean altering data rather than deleting it (T1565.001 Stored Data Manipulation). Compare critical datasets with backups.

6. Recovery

1. Restore from protected backups: confirm the backup copies were outside the person's control. Immutable options such as AWS Backup Vault Lock in compliance mode make recovery points undeletable, including by the root user, once the grace time (at least 72 hours) expires.
2. Restore in priority order from the business continuity plan: identity and access, then customer-facing services, then internal systems.
3. Verify before reconnecting: scan restored systems for the planted mechanisms found in section 5, since backups may contain them.
4. Re-establish admin coverage: the person may have been a key administrator. Confirm others hold working, documented access to every system they ran.
5. Monitor for [90] days for any use of revoked credentials and for the planted indicators.

Where identity fits

Sabotage succeeds through access that outlives the person's role or employment: personal tokens on automation, cloud keys created years ago, service accounts only they understood. The Cisco case involved access after resignation. Build an offboarding process that covers non-human credentials as well as the human account; see the NHI Offboarding and Decommissioning Guide and the Joiner-Mover-Leaver Guide.

7. Communication and notification

• Internal: brief only those who need to act. Staff updates describe service impact, not the person, until legal approves.
• Executives and board: impact, recovery estimate and legal position.
• Customers: service status and any refunds or credits; in the Cisco case customer data was not compromised, but customers lost service.
• Regulators: legal assesses whether the availability or integrity impact is reportable under [GDPR, NIS2, DORA, sector rules].
• Law enforcement: legal decides on referral; computer misuse offences apply to unauthorised access and damage by former staff in most jurisdictions.
• Employee relations: HR follows the disciplinary policy, works council or union requirements, and keeps statements factual.

8. Post-incident review

• Timeline: first warning signs, access changes, destructive action, detection, revocation, restoration.
• Warning signs missed: were behavioural concerns raised to HR or managers without reaching security? CISA's insider threat framework (define, detect and identify, assess, manage) depends on that link. See the Insider Threat Programme Guide.
• Access design: standing admin rights, single-person control of backups, credentials owned by individuals instead of teams.
• Offboarding gaps: which credentials survived departure and why.

Implementation guidance

1. Agree the HR to security trigger: HR notifies security confidentially before any dismissal, demotion or performance action involving a privileged user.
2. Script revocation: maintain a tested script that disables a person across the identity provider, AD, cloud and key SaaS, and lists their non-human credentials.
3. Make backups immutable and separate backup administration from production administration.
4. Use just-in-time privilege for destructive actions so no one holds standing rights to delete production. See the Insider Threat and Identity Guide.
5. Alert on mass deletion by any identity, and on any activity by an account after its owner's exit date.
6. Exercise yearly: a tabletop where a cloud administrator is being dismissed tomorrow.

Framework mapping

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Insider Threat Mitigation Guide
• CISA: Defining Insider Threats
• Carnegie Mellon SEI: Common Sense Guide to Mitigating Insider Threats, Seventh Edition
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• AWS Documentation: AWS Backup Vault Lock
• US Department of Justice: San Jose man pleads guilty to damaging Cisco's network

Related NHI Mgmt Group resources: Insider Data Theft Response Playbook · Insider Threat Programme Guide · NHI Offboarding and Decommissioning Guide · Insider Risk Management Buyer's Guide