What engineering leadership owns in a data breach
The incident response structure should already exist, with a named incident lead. In a company with a CISO, that person usually leads a security incident, and engineering leadership runs the technical workstream inside it. If no such structure exists, you create one in the first hour. Then you make sure everyone knows who decides what.
Inside that structure, engineering owns three things and should own them completely.
Containment, sequenced to preserve evidence. Stop the exposure first: revoke the credential, close the access path, isolate the host. But do not wipe and rebuild compromised systems before capturing disk images, memory where feasible, and logs. A rebuilt server is clean and also silent. Forensic investigators, insurers, regulators and lawyers will all ask questions you can no longer answer if the evidence went with it. The token-leak page covers the credential-level first hour; at executive level the job is making sure that urgency does not destroy the record.
The fact base. Everyone downstream depends on one document: what data, whose, over what window, through what path, and how confident you are in each answer. It is versioned and timestamped, and every statement says whether it is confirmed, estimated or unknown. Legal will use it to decide on notification. Communications will use it to write the customer letter. The board will read it. If three teams run three spreadsheets, someone will say something untrue in public.
Recovery and the systemic fix. Eradicate the access path, restore service, then fix the class of weakness, not just the instance. That work continues long after the incident is closed.
Who you bring in, and how fast
The instinct many engineering leaders have is to understand the incident fully before escalating. In a data breach that instinct is dangerous. Some regimes start the notification clock from awareness, not certainty. The EU GDPR, for example, expects notification to the supervisory authority within 72 hours of becoming aware of a reportable personal-data breach, where feasible. Other countries, sectors and contracts set their own triggers and deadlines. Whether and when "awareness" happened is a legal question, which is exactly why legal needs to hear early.
| Who | Why they are needed | When |
|---|
| Security lead or CISO | Incident leadership, forensic method | Immediately |
| Legal counsel | Notification obligations, privilege, contracts, law enforcement | Within the first hours |
| Privacy or data protection officer | What the data is, whose it is, which regimes apply | Within the first hours |
| CEO and executive team | Business decisions, customer and public posture | Within the first hours, with a short written brief |
| External forensic firm | Independent investigation and capacity | As legal and security decide |
| Cyber insurer | Many policies require prompt notice and approved vendors | As legal advises, often early |
| Communications | Customer, media and employee statements | Before anything is said outside |
| Customer support and account teams | Inbound questions, scripts, escalation | Before customers are told |
| Board | Oversight; may be needed for disclosure decisions | Per the company's escalation policy |
Some items are deliberately hedged. Whether forensics should be engaged through counsel, whether to contact law enforcement, and whether a listed company must consider securities disclosure are all decisions that vary by country and circumstance. Your job is to put each question to legal in writing, early, and record the time you did.
If your company processes data on behalf of business customers, those customers may be the ones with the regulatory duty, and your contracts may require you to tell them promptly. That changes the order of communication and is another reason legal reads the contracts before anyone writes to customers.
Running the engineering side of incident response
Protect the responders. Incident response for a breach runs for days or weeks, not hours. Set shifts early, keep the group with access to the evidence small, and keep everyone else out of the war room. Treat internal channels as potentially visible to the attacker until you know they are not. If the intruder had access to email or chat, move the response to a separate channel.
Keep a decision log from the first minute: what was learned, when, by whom, and what was decided. It feels bureaucratic during the incident. Afterwards it is the only reliable answer to "when did you know?", and that question decides a great deal.
Control what engineers say. Engineers are trusted by customers and naturally want to reassure them. A well-meant forum post saying "no passwords were affected", sent before the investigation has confirmed it, can contradict the official notice a day later. All external statements go through the communications and legal path, and the team should hear that from you directly.
"No evidence of access" is a statement about your logs
The most consequential sentence in any breach is a version of "we have no evidence that data was accessed". It is only meaningful if you had the logging to see access in the first place. If read access to the affected table was never logged, or your log retention is shorter than the exposure window, the honest position is "we cannot rule out that this data was read". Your notification posture changes accordingly.
Strong candidates draw this distinction without being prompted. They tell legal exactly what the logs can and cannot show, rather than letting a hopeful sentence travel into a customer letter. The access-control release page makes the same point about the forensic gap from the design side. From the executive chair, you are accountable for not overstating certainty in either direction.
After the incident
When the incident is stood down, engineering still owes the post-incident review, the systemic fixes with owners and dates, and support for whatever follows: regulator questions, customer audits, possibly litigation. Most of those will draw on the fact base and decision log, so keep both. Then fund the gaps the incident exposed, especially logging and retention, because the next investigation will need them.
In a data breach, engineering owns the facts and the fix; legal owns what you are obliged to say and when. Preserve evidence while you contain, bring legal in early, and never let a hopeful sentence outrun what your logs can prove.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).