Database Breach Investigation Playbook

Breach Investigation Mindset Checklist

Establish the Evidence-First Mindset

What would you lose if the first person who noticed unusual database activity restarted the server, deleted a suspicious account, or opened the only backup in a desktop tool?

You could lose the exact evidence needed to determine whether data was accessed, copied, changed, or merely exposed. Database investigations often fail before analysis begins because well-intentioned responders alter timestamps, overwrite logs, trigger cleanup jobs, or let several people handle the same files without recording what they did. The Evidence-First Mindset prevents those errors by placing preservation before explanation and documented facts before assumptions.

The workflow must cover more than the live database. A useful investigation considers the database server, transaction logs, audit records, backup files, exports, cloud storage, access records, and the systems that could have moved data elsewhere. A suspicious login may show access without proving a query. A changed row may show alteration without proving theft. A missing audit record may indicate disabled logging, retention expiry, or deliberate deletion. Each conclusion requires a traceable evidence path.

After applying this mindset, you should know what to preserve first, how to separate facts from working theories, how to assign investigation roles from beginner through senior practitioner, and how to record decisions before touching a system. Ask yourself one question at every stage: “What action could destroy or change the evidence I need next?” That question keeps the investigation controlled.

Apply the Evidence-First Mindset Before Collection

Start by defining the investigation question in observable terms. Replace “Was the database breached?” with separate questions: Did an unauthorized account authenticate? Did that account run queries? Did a process read a backup? Did a user export rows? Did anyone alter data or security settings? Did data leave the environment? Specific questions determine which records matter and prevent investigators from collecting everything without a plan.

Use this sequence before opening a console or mounting a backup:

1. Declare the incident boundary. Record the suspected systems, database names, cloud accounts, backup locations, user accounts, and time window. Include a wider time range than the alert initially suggests; clock differences and delayed logging can shift apparent event times.

2. Assign control and roles. Name one incident lead, one evidence custodian, and one technical analyst. The incident lead approves actions, the custodian tracks originals and copies, and the analyst performs examination on working copies. Smaller teams may combine roles, but the record must show who performed each action and why.

3. Preserve volatile records first. Capture current connections, running processes, active sessions, mounted storage, and relevant cloud access information before rebooting or stopping services. Volatile evidence can disappear when a process exits or a session expires.

4. Protect original evidence. Acquire forensic copies of files and storage, calculate a cryptographic hash such as Secure Hash Algorithm 256-bit (SHA-256), and record the tool, command, time, and operator. A hash acts as a file fingerprint; matching values support the claim that a copy did not change.

5. Build a timeline from independent sources. Compare database audit records, operating system logs, authentication records, backup job logs, cloud access logs, and network records. One timestamp rarely answers the question by itself.

6. Test each conclusion against alternatives. A large query may reflect a scheduled report, a backup job, a migration, or unauthorized extraction. Check job schedules, service accounts, application behavior, and approved change records before labeling it exfiltration.

Evidence priorities depend on the suspected action. If an attacker may still have access, preserve active sessions and access controls while avoiding changes that erase context. If a backup may have been copied, preserve the original backup, its object-storage metadata, access logs, and encryption-key records. If data may have changed, preserve transaction logs and point-in-time recovery material before routine retention processes remove them.

Use an evidence register rather than relying on email or memory. Record an evidence identifier, source, acquisition time in Coordinated Universal Time (UTC), local time zone, collector, hash, storage location, and handling history. Keep original files read-only. Perform searches, parsing, and recovery work against verified copies. The result should allow another analyst to reproduce the collection and reach the same observations.

The progression from beginner to senior practitioner follows this same discipline. A beginner can identify systems and stop casual handling....