When data leaves without permission, the clock for regulators and customers starts the moment you become aware, yet most teams lose the first day arguing about whether exfiltration actually happened. This template gives [Organisation] a ready-to-adopt playbook for suspected or confirmed theft of data by an external attacker: bulk downloads from cloud storage and SaaS, transfers over command-and-control channels, uploads to attacker-controlled cloud accounts, and exports through stolen API keys or OAuth tokens. Background on techniques and preventive controls sits in the Data Exfiltration Guide; theft by an employee or contractor follows the Insider Data Theft Response Playbook. Replace every [bracketed] placeholder and exercise it before you need it.
How to use this template
- Adopt, then tailor: copy sections 1 to 8 into your incident response plan alongside the Incident Response Plan Template, and fill in named owners, log sources and retention periods.
- Turn on the logs first: this playbook only works if object-level logging exists before the incident. AWS CloudTrail does not log data events such as S3 GetObject by default, and Google Cloud Data Access audit logs are disabled by default for every service except BigQuery.
- Treat the identity as the exfiltration channel: most cloud and SaaS theft uses valid credentials (T1078.004 Cloud Accounts), API keys or OAuth grants. Section 4 revokes them before anything else.
- Review annually and after every exfiltration incident, cloud platform change or new SaaS data store. Owner: [Head of Security Operations].
1. Scope and triggers
1.1 This playbook applies to suspected or confirmed unauthorised transfer of [Organisation] data, or data [Organisation] holds for others, to a location outside its control, by an external actor or by a compromised account or non-human identity (NHI). It covers on-premises systems, cloud storage, SaaS applications, data warehouses and email.
1.2 Exfiltration paths in scope.
| Path | ATT&CK v20 | Where it shows | First containment lever |
|---|---|---|---|
| Over the command-and-control channel | T1041 Exfiltration Over C2 Channel | EDR network events, proxy and firewall egress volume per host | Isolate the host, block the C2 destination |
| To a web service or cloud storage (for example file-sharing or sync sites) | T1567 Exfiltration Over Web Service; T1567.002 Exfiltration to Cloud Storage | Proxy and CASB logs, DLP alerts, large POST or PUT uploads | Block the destination domain or tenant, revoke the session |
| Over another protocol (FTP, DNS, SMTP) | T1048 Exfiltration Over Alternative Protocol | Firewall logs, DNS query volume and length, mail gateway logs | Block the protocol outbound from the source segment |
| Direct reads from cloud storage with stolen keys | T1530 Data from Cloud Storage | CloudTrail S3 data events, Azure Storage logs, GCS Data Access logs | Deactivate the key, deny the principal, block public access |
| Copy or snapshot shared to another cloud account | T1537 Transfer Data to Cloud Account | Snapshot sharing and cross-account copy events in the control plane log | Remove the share, revoke the role, lock the account |
| Bulk export from SaaS, wikis, CRM or code repositories | T1213 Data from Information Repositories | SaaS audit log export and report API calls, OAuth app activity | Revoke the OAuth grant and refresh tokens, disable the app |
| Mailbox harvesting | T1114.002 Remote Email Collection | Mailbox audit events (for example MailItemsAccessed), mail forwarding rules | Revoke sessions, remove forwarding rules and app consents |
1.3 Triggers: a DLP or CASB alert on sensitive data leaving; egress from one host or identity above [5] times its 30-day baseline; staged archives on servers (T1074 Data Staged, T1560 Archive Collected Data); a cloud key or token used from an unknown network; a supplier or researcher reporting [Organisation] data online; an extortion email (follow the Extortion Email Playbook in parallel); or ransomware, where theft before encryption is now usual.
1.4 Out of scope: data published by misconfiguration with no evidence of access uses the Cloud Storage Exposure Playbook unless logs show downloads; theft by a current or former insider uses the Insider Data Theft Response Playbook.
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [Security Operations Manager] | Declares the incident, sets severity, owns the decision log and the awareness timestamp |
| Cloud and SaaS Lead | [Cloud Security Lead] | Log exports, key and role actions, storage policies, SaaS admin actions |
| Identity Lead | [IAM Lead] | Session, token, OAuth grant and NHI revocation and rotation |
| Forensics Lead | [DFIR Lead or retained provider] | Evidence preservation, volume and object reconstruction, root cause |
| Data Owner | [Business owner of the affected data set] | Says what the data is, whose it is and how sensitive it is |
| Data Protection Officer | [DPO] | Risk to individuals, regulator notification, breach register entry |
| Legal and Communications | [General Counsel], [Head of Communications] | Privilege, contracts, insurer, law enforcement, customer and media messages |
2.1 Pre-authorisation. While a trigger in 1.3 is active, the Identity Lead may revoke any session, token, key or OAuth grant, and the Cloud and SaaS Lead may block any outbound destination, without further approval. Disabling a production integration used by customers needs the Data Owner, reachable within [30] minutes.
2.2 Keep 24/7 contacts for cloud and SaaS support, the retainer, the insurer, outside counsel and the data protection authority offline.
3. Detection and triage
- Record the awareness time. Note in the decision log when [Organisation] had a reasonable degree of certainty that a breach occurred. This is the point the ICO and GDPR 72-hour period runs from, so record it carefully.
- Confirm transfer, not just access. Correlate three views: the source (storage, SaaS or database audit logs showing reads or exports), the identity (who or what made the calls, from where) and the egress (proxy, firewall, NetFlow or cloud VPC flow logs showing bytes leaving). One view is suspicion; two that agree on time and volume is confirmation.
- Find the identity. List every principal involved: user, service account, access key, role session, OAuth app, personal access token. Check where its secret lived and who else could read it.
- Scope the data. From object-level logs, build a list of objects, tables, mailboxes or record types read during the window. Where object logs are missing, treat everything the identity could read as exposed until proven otherwise, and say so in the log.
- Scope whose data. The Data Owner and DPO classify it: personal data (and special category data), customer confidential data under contract, credentials, regulated data (payment card, health) and intellectual property. Use the Data Classification Guide labels.
- Look for secrets inside the stolen data. Scan exported records, tickets and files for keys, passwords and tokens. In the Salesloft Drift breach the attacker searched exported Salesforce support cases for AWS keys and Snowflake tokens, which turned one theft into many.
Decision point A: if transfer is still in progress, go to section 4 immediately and finish scoping afterwards. Stopping the flow comes before a complete picture.
Evidence to preserve: cloud control plane and data event logs, SaaS audit logs and API logs exported to write-once storage before their retention expires (Microsoft Purview Audit Standard keeps records for 180 days by default); proxy, DNS, firewall and flow logs; DLP and CASB alert detail; EDR telemetry and memory images from any staging hosts; copies of any extortion messages with full headers. Follow the Evidence Handling and Chain of Custody Guide and the Cloud Forensics Guide.
4. Containment
- Revoke the identity doing the transfer: disable the user, deactivate (then delete) the access key, revoke role sessions, revoke OAuth access and refresh tokens and disable the connected app or service principal. Resetting a password alone leaves issued tokens valid.
- Block the destination: add the domain, IP range, storage tenant or cloud account to proxy, DNS and firewall blocks. Remove external shares, public links and cross-account snapshot permissions created in the window.
- Isolate staging hosts with EDR containment, keeping the agent connected so memory and files can still be collected.
- Tighten the data store: apply a deny statement for the compromised principal in the bucket or resource policy, enable block public access, and restrict the store to known networks.
- Protect the logs: confirm logging is still on and that the attacker has not altered trails or retention (T1685 Disable or Modify Tools covers tampering with security tools).
Decision point B: watch or cut. Monitoring to learn more is acceptable only when no further regulated data can leave; the Incident Lead and General Counsel decide and record why.
Decision point C: if the identity is an integration many customers rely on, the Data Owner chooses between disabling it now or restricting its scopes and network range while a replacement credential is issued.
5. Eradication
5.1 Close the initial access route: the phished account, the exposed key in a repository, the exploited server, or the compromised third-party integration.
5.2 Credential and NHI resets.
| Credential | When | Action |
|---|---|---|
| Cloud access keys and role trust used in the theft | Always | Delete keys, review and narrow trust policies, replace long-lived keys with federated or workload identity |
| OAuth grants and refresh tokens | If any SaaS export was involved | Revoke all tokens for the app, review consent grants tenant-wide, reissue with least scopes |
| Secrets found inside the stolen data | Always | Rotate every one, then check its logs for use since the theft |
| Data warehouse and database service accounts | If readable by the attacker | Move to key pair or federated authentication, enforce network policies, assign an owner |
| Personal access tokens and SSH keys | If repositories were read | Revoke, reissue with expiry, enable secret scanning |
| User accounts used from attacker infrastructure | Always | Reset, revoke sessions, re-register phishing-resistant MFA |
5.3 The Snowflake breach shows why section 5.2 matters: Mandiant found accounts without MFA, credentials not rotated for years and no network allow lists. See the Leaked Credential Response Playbook for rotation at scale.
6. Recovery
- Restore integrations with new, narrowly scoped credentials and network restrictions, one at a time.
- Keep destination blocks and add detection rules for the volumes, user agents and destinations seen in this incident.
- Monitor for [90] days for use of rotated credentials, re-registration of OAuth apps and [Organisation] data appearing on leak sites or paste sites.
7. Communication and notification
7.1 Notification decision. The DPO and General Counsel decide, with the Data Owner, using the facts from section 3. Under UK and EU GDPR Article 33 a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless it is unlikely to result in a risk to individuals; the ICO accepts reports in phases when details are incomplete. Where the risk is high, affected people must be told directly without undue delay (Article 34). Every breach goes in the breach register with the reasoning, whether reported or not. US state, sector and other national laws differ in triggers and deadlines: see the Breach Notification Laws by Country Guide, the Data Breach Notification Checklist and the GDPR Compliance Guide for Security Teams.
| Audience | When | Owner | Content |
|---|---|---|---|
| Executives | Within [1] hour of confirmation | Incident Lead | What left, whose data, decisions needed |
| Data protection authority | Within 72 hours of awareness where required | DPO | Nature, categories and approximate numbers, likely consequences, measures |
| Affected individuals | Without undue delay if high risk | DPO and Communications | What happened, likely consequences, what they should do, contact point |
| Business customers | Per contract, often [24] to [72] hours | Legal Counsel | Facts, data involved, indicators, contact point |
| Cyber insurer | Per policy, before engaging any extortion actor | Legal Counsel | Notice, request for panel support |
| Law enforcement | For criminal theft or extortion | Legal Counsel | Timeline, indicators, extortion messages |
7.2 Extortion overlap. If the attacker demands payment not to publish, run the Extortion Email Playbook alongside this one and read the Data Extortion Without Encryption Guide and the Ransomware Payments and Sanctions Guide. Paying does not remove a notification duty, and claims of deletion cannot be verified.
8. Post-incident review
8.1 Within [10] business days run a blameless review using the Post-Incident Review and Root Cause Analysis Template.
8.2 Ask: time from first transfer to detection and revocation; which logs were missing; was the identity over-privileged; how did the secret leak.
Implementation guidance
Confirmation sources compared.
| Source | Proves | Gap |
|---|---|---|
| Object-level storage and SaaS audit logs | Which objects or records were read, by which identity | Often off by default or short retention |
| Proxy, firewall and flow logs | Bytes leaving and to where | Encrypted content, cloud-to-cloud transfers never cross your edge |
| DLP and CASB | Sensitive content patterns in transit | Misses encrypted archives and unmanaged paths |
| EDR | Staging, archiving and the process that sent data | No view of SaaS or API-only theft |
Rollout.
- Inventory sensitive data stores and turn on object-level logging for them (CloudTrail S3 data events, GCS Data Access logs, SaaS audit logs), shipping to a SIEM with [12] months retention. See the Cloud Logging and Audit Trail Guide.
- Build per-identity egress and read-volume baselines and alerts, starting in alert-only mode for [30] days to tune.
- Pre-write revocation runbooks for each cloud and SaaS platform, and test them on a non-production key.
- Run a tabletop with the DPO using a cloud bulk-download scenario. See the Tabletop Exercise Guide.
- Rollback: document how to restore each blocked destination and disabled integration once replaced.
Small vs large organisations. A small organisation should at least enable SaaS and cloud audit logs, list OAuth apps with data access and name who makes the notification call. A large organisation needs per-platform revocation automation and a data inventory mapping stores to owners.
Metrics. Time from first transfer to detection; time from confirmation to revocation; percentage of sensitive data stores with object-level logging; percentage of NHIs with a named owner and expiry; notification decisions made within [48] hours of awareness; secrets found in stolen data rotated within [24] hours.
Framework mapping.
| Framework | References |
|---|---|
| NIST CSF 2.0 and SP 800-61 Rev. 3 | DE.AE-02 event analysis; RS.AN-03 analysis; RS.AN-07 evidence integrity; RS.AN-08 magnitude estimated; RS.MI-01 containment; RS.CO-02 notification |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling; IR-6 Incident Reporting; SI-4 System Monitoring; SC-7 Boundary Protection; AC-4 Information Flow Enforcement; AU-11 Audit Record Retention; IA-5 Authenticator Management |
| UK and EU GDPR | Article 33 notification to the authority; Article 34 communication to data subjects |
| MITRE ATT&CK v20 | T1041, T1567, T1567.002, T1048, T1530, T1537, T1213, T1114.002, T1074, T1560, T1078.004 |
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- EUR-Lex: Regulation (EU) 2016/679 General Data Protection Regulation
- ICO: Personal data breaches, a guide
- AWS: Logging data events with CloudTrail
- Google Cloud: Cloud Audit Logs overview
- Microsoft Learn: Manage audit log retention policies
- MITRE ATT&CK: T1567 Exfiltration Over Web Service
- MITRE ATT&CK: T1041 Exfiltration Over C2 Channel
Related NHI Mgmt Group resources: Data Exfiltration Guide · Insider Data Theft Response Playbook · Extortion Email Playbook · Data Loss Prevention (DLP) Guide · Cloud Incident Response Guide