After data leaves your environment, the question that drives every notification, regulator conversation, extortion decision and cost estimate is simple and hard: exactly which records, about which people, were taken? Teams that cannot answer it either over-notify millions of people or under-notify and face regulators later. This playbook is a reusable procedure for scoping a data exposure: preserving the evidence that proves access, reconstructing what was read or copied, mapping it to data elements and individuals, and handing a defensible count to legal and privacy teams. It is for incident responders, data and platform engineers, privacy officers and counsel. It sits between containment and notification; for the legal clocks themselves, use the Data Breach Notification Checklist.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Incident Lead], [Data Scoping Lead] and [DPO], with your own names and roles. "Must" is mandatory; "should" is recommended.
- Run it alongside your incident response plan: this playbook covers the data question only. Containment of the intruder and recovery of systems follow your main plan. See the Incident Response Plan Template.
- Prepare the evidence sources now: section 3 lists the logs that make scoping possible. Most of them are off or short-lived by default, so the preparation in Implementation guidance matters more than anything done on the day.
- Work under privilege where counsel advises it: scoping outputs are sensitive. Agree with [Legal] how reports are labelled and who receives them.
1. Scope and triggers
1.1 This playbook applies to any confirmed or suspected unauthorised access to, or copying of, data held by or for [Organisation], including data in SaaS platforms, cloud storage, data warehouses, email, file shares, backups and data held by processors and suppliers.
1.2 It must be invoked when any of the following occurs:
- Exfiltration indicator: unusual egress volume, staging of archives, cloud storage copy or export jobs, or bulk API reads. See the Data Exfiltration Playbook.
- Extortion or leak claim: a threat actor claims to hold [Organisation] data, posts samples, or contacts staff or customers. See the Data Extortion Without Encryption Guide.
- Third-party notice: a supplier, platform provider, researcher or law enforcement reports exposure of [Organisation] data.
- Compromised identity with data access: a user, service account, API key or OAuth token with read access to sensitive stores is confirmed as compromised.
- Misconfiguration exposure: a store found publicly readable, even without evidence of access.
1.3 The objective is a documented answer, at a stated confidence level, to five questions: which systems, which data sets, which data elements, which individuals (and in which jurisdictions), and over which time window.
2. Roles and contacts
| Role | Responsibility in scoping | Named person or team |
|---|---|---|
| [Incident Lead] | Owns the overall incident, approves scoping priorities and resource | [Name, deputy, phone] |
| [Data Scoping Lead] | Runs this playbook, owns the scoping record and the confidence statement | [Name] |
| [Forensics] | Evidence preservation, log collection, timeline reconstruction | [Internal team or retained firm] |
| [Data Owners] | Explain what each affected data set contains and who it relates to | [Per system] |
| [Data Engineering] | Run queries over copies of affected data, deduplicate and resolve identities | [Team] |
| [DPO] and [Privacy] | Risk to individuals, regulator and data subject notification decisions | [Name] |
| [Legal] | Privilege, contractual notice to customers, law enforcement, extortion response | [Name, external counsel] |
| [Communications] | Holding statements based only on confirmed scoping facts | [Name] |
2.1 Contact details for platform providers (cloud, SaaS, data warehouse) and the support routes that can preserve or export their logs must be listed in [Appendix: provider contacts]. See the Incident Response Contact and Call Tree Template.
3. Detection and triage
3.1 Preserve first. Within [4 hours] of invocation, [Forensics] must export or extend retention of every log source in the table below that covers affected systems, because many sources roll over in days. Place a legal hold where required. See the eDiscovery and Legal Hold Guide.
| Data location | Evidence that shows what was read or copied | Default behaviour to know about |
|---|---|---|
| Microsoft 365 mailboxes | MailItemsAccessed audit events: Bind (individual messages by InternetMessageId) and Sync (whole folder downloaded by desktop Outlook) | Enabled by default for E3 and E5 licensed users; a Sync event means every item in that folder must be assumed compromised |
| AWS S3 | CloudTrail data events (GetObject on AWS::S3::Object) or S3 server access logs | Data events are not logged by default; CloudTrail event history holds management events only, for 90 days |
| Snowflake | ACCOUNT_USAGE.QUERY_HISTORY and ACCESS_HISTORY (direct and base objects and columns accessed) | ACCESS_HISTORY requires Enterprise Edition or higher, has up to 180 minutes latency and covers 365 days |
| SaaS applications (CRM, ticketing, HR) | API and report export logs, bulk API job records, connected app and OAuth token activity | Often a paid add-on with short retention; confirm with the provider |
| Databases | Database audit logs, query logs, proxy or DAM records, row counts in result sets | Query text is often logged without result size |
| File shares and endpoints | File access auditing, EDR file read and archive creation events, DLP events | Object access auditing is frequently off on file servers |
| Network egress | Proxy, firewall and NetFlow volumes per destination | Shows how much left, rarely what it was |
3.2 Triage the exposure path. [Data Scoping Lead] must record the access path (which identity, which credential, which interface) and list every data store that identity could read. Start from the identity's effective permissions, not from where the attacker was seen. What a credential could reach sets the outer bound; logs narrow it.
3.3 Set the working window. Record the earliest possible access time (credential creation, exposure or first suspicious login) and the containment time. Scoping covers the whole window unless logs prove a narrower one.
3.4 Classify confidence. Each data set in scope must be labelled with one of: Confirmed taken (logs or recovered copies show the data left), Accessed (read in place, no proof of copy), Exposed (reachable, no evidence either way, or logs missing) and Not affected (logs prove no access). Regulators expect missing logs to be treated as exposure, not as innocence.
4. Containment
4.1 Containment of the access path follows the main incident plan: revoke sessions, rotate or disable the credentials, OAuth grants and API keys involved, and block exfiltration destinations. See the Identity Incident Response Playbook.
4.2 Containment must not destroy scoping evidence. Before deleting a malicious OAuth app, temporary stage, export job, mailbox rule or service account, [Forensics] must capture its configuration, creation time and activity logs.
4.3 If an extortion actor provides a sample or file listing, [Forensics] must preserve it with hashes and chain of custody, and compare it against source data in an isolated environment. Samples are evidence of what was taken, and of whether the claim is real.
5. Eradication
5.1 Reconstruct the data actually taken. For each data set labelled Confirmed taken or Accessed, [Data Engineering] must reproduce the attacker's queries, exports or file reads against a preserved snapshot (not production) to produce the exact record set. Use query text, object and column lists, time ranges and row counts from the evidence.
5.2 Map records to data elements. For each record set, list the columns or fields present and map them to [Organisation]'s data classification and to the legally significant elements below. See the Data Classification Guide.
| Data element group | Examples | Why it matters for notification |
|---|---|---|
| Direct identifiers | Name, email, phone, postal address, customer ID | Turns a record into personal data about an identifiable person |
| Government and account identifiers | National insurance or social security number, passport, driving licence, bank account and card numbers | Commonly the trigger elements in US state breach laws when combined with a name |
| Credentials | Usernames with passwords or hashes, security questions, API keys, tokens | Enables further compromise; often a trigger element on its own |
| Special category and health data | Health, biometric, genetic, sexual orientation, religion, trade union data | Raises GDPR risk severity; PHI engages HIPAA's four-factor risk assessment |
| Children's data | Pupil records, age, parental contacts | Higher risk to individuals and sector-specific rules |
| Protected data | Fields encrypted with keys not exposed, tokenised or pseudonymised values | May reduce risk, or the duty to tell individuals, if keys and mapping tables stayed safe |
5.3 Resolve to individuals. [Data Engineering] must deduplicate records across all affected data sets to unique individuals, using a documented matching rule (for example customer ID first, then verified email, then name plus date of birth). Record the counts before and after deduplication. Separate categories (customers, employees, former employees, patients, children) and derive jurisdiction from the most reliable address or residency field.
5.4 Check protections claimed. Where data was encrypted, tokenised or pseudonymised, confirm whether the keys, token vault or mapping tables were reachable by the same identity in the window. If they were, treat the data as clear text. See the Tokenisation and Data Masking Guide.
5.5 Look beyond the obvious store. Free-text fields, attachments, support tickets, logs and backups frequently contain data elements that the schema does not show. Sample them before stating that a data set holds no sensitive elements.
6. Recovery
6.1 Produce the scoping record. [Data Scoping Lead] must issue a versioned scoping record containing, per data set: system, access path, window, confidence label, record count, unique individuals by category and jurisdiction, data elements present, protections and their status, and the evidence relied on.
6.2 State confidence and gaps. Each version must say what is confirmed, what is estimated and why, and which log gaps forced an Exposed label.
6.3 Re-baseline when evidence changes. New logs, provider reports or leaked samples can widen or narrow scope. Each change produces a new version with a change note, and [DPO] and [Legal] are told within [24 hours].
6.4 Support affected people. Feed the deduplicated individual list, with contact details and data elements, to the notification and support process (credit monitoring, password resets, card reissue) under access controls equal to the original data.
7. Communication and notification
7.1 Notification clocks do not wait for scoping to finish. Under UK and EU GDPR Article 33, a notifiable breach must be reported to the supervisory authority without undue delay and not later than 72 hours after becoming aware, and Article 33(4) allows information to be provided in phases. The ICO expects the report to include the categories and approximate number of individuals and of personal data records concerned. Section 6 versions are the basis for each phase.
7.2 [DPO] must use the scoping record to assess risk to individuals, and whether the high-risk threshold for telling individuals directly is met. For protected health information, the HIPAA Breach Notification Rule presumes a breach unless a risk assessment of four factors (the nature and extent of the PHI, the unauthorised person, whether it was actually acquired or viewed, and the extent of mitigation) shows a low probability of compromise; scoping provides the evidence for factors one and three.
7.3 [Legal] must check customer and processor contracts for notice duties and timings, and inform controllers where [Organisation] acts as processor.
7.4 Public statements must use only confirmed facts from the current scoping version. Say the investigation is continuing.
7.5 Use the Data Breach Notification Checklist and the Breach Notification Laws by Country Guide for regime-by-regime deadlines and content.
8. Post-incident review
8.1 Within [20 working days] of closure, [Data Scoping Lead] must run a review that records how long scoping took, which evidence sources were missing or expired, how many data sets ended as Exposed because of log gaps, and how far early estimates differed from the final count.
8.2 Every log gap must become a tracked action with an owner: enable data event logging, extend retention, buy the audit add-on, or reduce what is stored.
8.3 Record all breaches, including those not notified, with the facts, effects and remedial action, as GDPR Article 33(5) requires.
8.4 Review data minimisation: data sets that held information nobody needed should be reduced, because the cheapest records to notify about are the ones you deleted beforehand.
Implementation guidance
Prepare before the incident
- Map sensitive stores: for each store holding personal or confidential data, record the owner, the data elements, the population and jurisdictions, and the identities (human and non-human) that can read it.
- Turn on access evidence: enable object-level and query-level logging where it is off by default (S3 data events, database audit, SaaS event monitoring, file access auditing), and set retention to at least [12 months] for high-value stores.
- Pre-build queries: keep tested queries that turn audit records into "which objects, which rows, which columns" for each major platform, plus a deduplication script for individuals.
- Rehearse: run a tabletop where a service account is compromised and the team must produce a scoping record version 1 within [48 hours]. The Snowflake customer breaches are a good scenario: attackers used stolen credentials and plain SQL to copy whole tables, and victims had to work out from query history which tables and people were affected.
- Include non-human identities: many mass data thefts run through service accounts, connected apps and API tokens. The ShinyHunters Salesforce data theft campaign used malicious connected apps to export CRM data, so scoping depended on connected app and API logs.
Measure readiness
- Coverage: share of sensitive stores with object or query-level access logging retained for [12 months].
- Speed: time from invocation to scoping record version 1 in exercises and real incidents.
- Precision: share of in-scope data sets that end Confirmed or Not affected rather than Exposed.
- Accuracy: difference between the first notified estimate and the final count.
- Minimisation: number of records held in sensitive stores beyond their retention period.
Framework mapping
- NIST SP 800-61 Rev. 3: this playbook supports incident analysis and reporting in the CSF 2.0 Respond function (RS.AN, RS.CO).
- NIST SP 800-53 Rev. 5: IR-4 Incident Handling, IR-6 Incident Reporting, AU-2 Event Logging and AU-11 Audit Record Retention.
- ISO/IEC 27001:2022 Annex A: 5.26 Response to information security incidents, 5.28 Collection of evidence and 8.15 Logging.
- CIS Controls v8.1: Control 8 Audit Log Management and Control 17 Incident Response Management. See the CIS Control 17 Incident Response Management Guide.
References
- ICO: Personal data breaches, a guide
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- HHS: HIPAA Breach Notification Rule
- Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
- AWS: Logging Amazon S3 API calls using AWS CloudTrail
- Snowflake: ACCESS_HISTORY view
Related NHI Mgmt Group resources: Data Breach Notification Checklist · Data Exfiltration Playbook · Forensic Readiness Guide · Incident Response Guide