Most database breach investigations fail at one question: which rows actually left, and for whom do we have to notify? SQL injection, a stolen database or warehouse credential, and a database left open to the internet all end the same way, with an attacker running queries you did not authorise. Teams that cannot answer the row question from logs end up notifying everyone in the table, or worse, notifying too few and correcting it later. This playbook template gives [Organisation] a response for relational, NoSQL and cloud data warehouse breaches, built around query log scoping, credential containment and evidence that will survive scrutiny. It is for SOC leads, database administrators and privacy teams. It goes deeper on the database specifics than the general Data Exfiltration Playbook, which it complements.
How to use this template
- Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
- Fill in the audit sources first. Section 3 only works if the logs in the table in 3.3 are already enabled for your crown-jewel databases. Gaps found while drafting are findings to fix now, not during an incident.
- Use the three entry tracks. Steps marked A apply to application-layer attacks such as SQL injection, C to stolen or misused database credentials, and E to databases exposed without authentication. Many incidents combine tracks.
- Keep decision points explicit. Each "Decision" line names who decides and on what evidence, so the decision log can be reconstructed later.
- Replace every [placeholder] and review the template at least yearly and after each use.
1. Scope and triggers
1.1 This playbook applies to any [Organisation] database, data warehouse or managed data service (for example PostgreSQL, MySQL, Microsoft SQL Server, Oracle, MongoDB, Elasticsearch, ClickHouse, Snowflake) where there is evidence or credible report of unauthorised reading, copying, modification or deletion of data.
1.2 Entry routes and the ATT&CK techniques to record in the case:
| Track | Entry route | ATT&CK | What it means for scoping |
|---|---|---|---|
| A | SQL or NoSQL injection through a web application or API | T1190 Exploit Public-Facing Application | Queries run as the application's database account; web and WAF logs are as important as database logs |
| C | Stolen, leaked or reused database or warehouse credential | T1078.004 Cloud Accounts (managed services) | Activity is attributable to one login; database login and query history are the primary evidence |
| E | Database reachable without authentication | T1190 Exploit Public-Facing Application | There may be no logs at all; assume full exposure for the period it was open unless proven otherwise |
| All | Bulk reading of tables once inside | T1213.006 Data from Information Repositories: Databases | Row counts and objects read decide the notification population |
| All | Copy out to attacker storage | T1567.002 Exfiltration to Cloud Storage, T1041 Exfiltration Over C2 Channel | Egress volumes corroborate or contradict the query evidence |
1.3 Triggers: a WAF or application log showing injection patterns followed by unusual response sizes; a database account querying tables it never touches; large exports, COPY or unload operations to new destinations; an external researcher or journalist reporting an open database; a ransom note or extortion email; your data appearing on a leak site or forum.
1.4 Related playbooks: extortion claims with no confirmed access follow the Extortion Email Playbook; a listing on a ransomware leak site follows the Ransomware Data Leak Site Listing Playbook; misconfigured cloud object storage follows the Cloud Storage Exposure Playbook.
2. Roles and contacts
| Role | Named lead | Responsibilities |
|---|---|---|
| Incident lead | [Name, phone] | Declares the incident, sets severity, owns the decision log |
| Database administrator | [Name, phone] | Preserves audit logs, rotates database credentials, runs scoping queries on a copy |
| Data owner | [From data inventory] | Confirms what each affected table holds and which data subjects it relates to |
| Application owner | [Name] | Fixes the injectable code path, supplies application and WAF logs |
| Forensics lead or retained firm | [Name, retainer reference] | Independent analysis, chain of custody. See the Incident Response Retainer Buyer's Guide |
| Privacy and legal | [Name] | Notifiability assessment, regulator and individual notices, privilege decisions. See the Legal Privilege in Incident Response Guide |
| Communications | [Name] | Customer, media and staff statements |
3. Detection and triage
3.1 Preserve before you touch. Export the database audit trail, database server logs, application, WAF and load balancer logs, and cloud control plane logs for the period from [90] days before the first suspicious event to now. Many audit views and log files roll over: retention is the first thing an incident loses.
3.2 Confirm the access path (A, C or E) and the database account or accounts used. For track A this is usually the application's own service account, which is why least privilege on that account limits the damage. See the Database Credential and Access Security Guide.
3.3 Identify the scoping evidence you actually have.
| Platform | Source | What it can prove | Gotchas |
|---|---|---|---|
| PostgreSQL | pgaudit extension, session or object logging | READ class logs SELECT and COPY; pgaudit.log_rows adds rows retrieved or affected; pgaudit.log_relation logs each table referenced | Default pgaudit.log is none; log_rows and log_parameter are off by default |
| MySQL | General query log | Every statement received, including SELECT, plus connects and disconnects | Disabled by default; the binary log never contains SELECT, so it cannot scope reads |
| SQL Server | SQL Server Audit with a database audit specification | SELECT action on named objects; SCHEMA_OBJECT_ACCESS_GROUP for object permission use; FAILED_LOGIN_GROUP for failed logons | Audits are created disabled; parameterised queries may log the parameter instead of values |
| Amazon RDS (Oracle, SQL Server) | Database Activity Streams to Kinesis | Events matching your audit policies, near real time | Nothing is captured by default; streams are asynchronous and may record gaps |
| MongoDB Enterprise or Atlas | Auditing facility | Authentication, DDL and, only with auditAuthorizationSuccess set to true, CRUD reads | Without that parameter, reads are not logged |
| Snowflake | ACCOUNT_USAGE.ACCESS_HISTORY | base_objects_accessed down to columns, objects_modified, for 365 days | Enterprise Edition or higher; up to 3 hours latency |
3.4 Scope the rows, not the tables. For each attacker query, record the objects read, the predicate (WHERE clause) and the row count. Re-run read-only reconstructions on a restored snapshot taken at the time of the query, never on production, so the result reflects the data as it was. Join the result to the data inventory to list the data subjects and data categories affected.
3.5 Corroborate with volume. Compare the reconstructed result size with web response sizes (track A), network egress or warehouse unload and stage operations (track C). A large mismatch means a query source is missing.
3.6 Rate severity. Critical: special category data, credentials, payment data or more than [10,000] individuals. High: personal data of customers or staff. Medium: internal data with no personal data.
3.7 Decision (incident lead and data owner): if no log can scope reads (track E, or auditing was off), treat every record reachable by the account for the exposure window as exposed. Record the evidence gap in the decision log rather than estimating.
4. Containment
4.1 Track A: block the exploited parameter or route at the WAF or API gateway, then take the vulnerable endpoint offline if a block cannot be confirmed. Do not wait for the code fix.
4.2 Track C: disable the database login or warehouse user, revoke sessions and tokens, and rotate the credential through the vault. Check for new users, roles, grants and keys created with it.
4.3 Track E: remove public network exposure (security group, firewall rule, bind address) and enforce authentication. Snapshot first if forensics needs the exposed state.
4.4 Apply network allow lists for database and warehouse logins so that only application subnets and named admin paths can connect.
4.5 Decision (incident lead and application owner): contain in place or take the database offline. Prefer in-place containment when the attacker's path is closed and confirmed; take it offline when the path is unknown or data is being modified.
5. Eradication
5.1 Fix the root cause: parameterised queries for the injectable code path (see the SQL Injection Prevention Guide), MFA and key pair authentication for human and service logins, or authentication and private networking for the exposed instance.
5.2 Remove every persistence item: new database users, altered grants, stored procedures, triggers, scheduled jobs, external stages, replication targets and linked servers added during the attack window.
5.3 Rotate every secret stored in or readable from the database: application API keys, OAuth client secrets, password hashes (force resets) and any connection strings in configuration tables. The DeepSeek database exposure leaked API keys and backend details alongside chat logs, which turns a data breach into a credential incident.
5.4 Check data integrity. Compare current tables with a known-good backup for unauthorised UPDATE or DELETE activity found in the WRITE logs.
6. Recovery
6.1 Restore modified or deleted data from a backup verified as pre-dating the attack, and record the restore point.
6.2 Return the application to service behind a confirmed WAF rule and with the code fix deployed and tested.
6.3 Turn on, or raise, the audit settings that were missing: read logging on sensitive tables, row counts, and log shipping to a store the database administrators cannot alter. Keep enhanced monitoring for [30] days.
7. Communication and notification
| Audience | Owner | When |
|---|---|---|
| Data protection regulator (UK ICO, EU supervisory authority) | Privacy lead | Where a risk to individuals is likely: as soon as possible and where feasible within 72 hours of becoming aware; further details can follow |
| Affected individuals | Privacy lead and communications | Without undue delay where the risk is high, using the scoped list from 3.4 |
| Card brands and acquirer | Payments lead | If cardholder data is in scope, per the merchant agreement |
| Customers whose data you process | Account owners and legal | Within contractual deadlines |
| Insurer, law enforcement, national CSIRT | Incident lead | At declaration for criminal attacks; the ICO also suggests considering the NCSC in the UK |
7.1 Notification content must state what is known and what is still being scoped. Update notices when the row scoping in 3.4 changes the population.
8. Post-incident review
8.1 Within [10] working days, record the timeline: first malicious query, detection, containment, scoping complete, notifications sent.
8.2 Root cause questions: Did the application account have read access to tables it never needed? Was read auditing enabled on regulated tables? Were warehouse logins protected by MFA and network policy? The Snowflake breach showed infostealer passwords, no MFA and no allow lists combining across about 165 customer accounts.
8.3 Metrics: time from first malicious query to detection; time to containment; percentage of regulated tables with read auditing and row counts; days of audit retention available; difference between first and final notification population.
Implementation guidance
- Decide audit depth by data class. Full read auditing on every table is expensive. Enable object-level read auditing on tables holding personal, payment and credential data, and statement logging for privileged and service accounts.
- Ship logs off the host. Send audit records to a SIEM or immutable store so a compromised administrator account cannot erase them.
- Test scoping before you need it. In a tabletop, give the team a sample attacker query and time how long it takes to produce a list of affected individuals.
- Size by organisation. A small organisation with one application database can rely on managed audit features and a retained forensics firm. A large organisation needs per-platform scoping runbooks, a data inventory that maps tables to data subjects, and an on-call database rota.
- Treat database accounts as NHIs. Inventory them, give each an owner and rotate them. See the Database Security Guide.
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Audit sources (3.3) | DE.CM-09 | AU-12, AU-11, AU-9 | A.8.15 |
| 3. Detection and triage | RS.AN-03 | AU-6, IR-4 | A.5.25 |
| Evidence handling | RS.AN-06 | IR-4 | A.5.28 |
| 4. and 5. Containment and eradication | RS.MI-01, RS.MI-02 | IR-4 | A.5.26 |
| 6. Recovery | RC.RP-01, RC.RP-03 | CP-9, CP-10 | A.8.13 |
| 7. Communication | RS.CO-02 | IR-6 | A.5.26 |
References: NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management · ICO: Personal data breach reporting · pgAudit: PostgreSQL Audit Extension · MySQL: The General Query Log · Microsoft: SQL Server Audit Action Groups and Actions · AWS: Database Activity Streams overview · MongoDB: Auditing · Snowflake: ACCESS_HISTORY view
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Data Exfiltration Playbook · Database Security Guide · SQL Injection Prevention Guide · Snowflake Security Guide · Incident Response Plan Template