Episode 54 · Module 11 · Monitoring & Incident Response

Incident Response Playbooks

19 May 2026 · 9:29 · Security for Legal SaaS

9:29 9:29

The worst time to figure out what to do during a security incident is during the incident. Adrenaline is high, information is incomplete, and every minute of delay means more data exposed or more systems compromised. Incident response playbooks — pre-written, rehearsed procedures for specific types of security events — transform a chaotic scramble into a structured process. NIST SP 800-61 Revision 3, finalised in April 2025, represents the first major update to NIST's incident response guidance since 2012.

Today’s Lesson

Security for Legal SaaS — Episode 54: Incident Response Playbooks

The Worst Time to Write Your Plan

NIST SP 800-61 Revision 3, finalised in April 2025, represents the first major update to NIST's incident response guidance since 2012. It restructures incident response activities around the NIST Cybersecurity Framework 2.0 six core functions (Govern, Identify, Protect, Detect, Respond, Recover), integrating incident response into broader risk management rather than treating it as a standalone process.¹²

For a legal SaaS platform — where a breach means compromised attorney-client privileged communications, case strategy documents, and personally identifiable information — the response window is measured in minutes, not days.

Incident Classification: Severity Levels

Not every security event is a crisis. Classification determines the speed and scope of the response.

Severity	Criteria	Example	Response Time
Critical (P1)	Active data exfiltration; compromised admin access; client data confirmed exposed	Attacker downloading case files via compromised admin account	Immediate. All-hands.
High (P2)	Confirmed compromise with potential data exposure; production system breach	Malware on application server; database credentials found on dark web	Within 1 hour
Medium (P3)	Suspicious activity requiring investigation; no confirmed data exposure	Unusual login patterns; failed exploit attempts against known vulnerability	Within 4 hours
Low (P4)	Minor policy violation; potential vulnerability requiring assessment	Developer committed an API key to a public repo; outdated dependency found	Within 24 hours

The trigger for escalation must be objective, not subjective. "This looks serious" is not a classification criteria. "Successful authentication from a country where we have no users, followed by API calls to the document export endpoint" is a P1.

The Incident Lifecycle

NIST SP 800-61r3 maps incident response to five phases, aligned with the CSF 2.0 Respond and Recover functions:¹

1. Detection and Analysis

This is where Episode 53's monitoring pays off. The monitoring system generates an alert. The on-call responder triages: Is this a real incident or a false positive? What systems are affected? What data may be at risk?

Key actions:

Verify the alert using multiple data sources (don't act on a single log entry)
Determine the scope: which systems, which users, which data
Assign severity based on the classification table above
Begin an incident log — timestamp every action from this point forward

2. Containment

Stop the bleeding without destroying evidence. Containment has two stages:

Short-term containment: Immediate actions to prevent further damage. Block the attacker's IP. Terminate compromised sessions. Disable compromised accounts. Isolate affected servers from the network.

Long-term containment: More surgical actions while you prepare for eradication. Apply temporary patches. Redirect traffic away from compromised systems. Set up enhanced monitoring on affected systems.

Evidence preservation is critical for legal SaaS. Do not wipe or rebuild a compromised system before capturing forensic images. If client privileged data was exposed, you may need those forensic records for regulatory notifications, insurance claims, or litigation. Containment must preserve evidence, not destroy it.

3. Eradication

Remove the cause of the incident. If malware was involved, clean or rebuild affected systems from known-good images. If credentials were stolen, rotate every affected credential — not just the ones you know about, but every credential the compromised system had access to (as we discussed in Episode 50 regarding workstation compromise). If a vulnerability was exploited, patch it.

4. Recovery

Restore systems to normal operation. Verify that the root cause has been eliminated. Monitor recovered systems with heightened scrutiny for days or weeks after recovery — attackers often leave secondary access paths (backdoors) that activate after the initial breach appears resolved.

5. Post-Incident Learning

Conduct a blameless retrospective within one week of the incident. Document: What happened? When was it detected? How long until containment? What worked? What didn't? What changes prevent recurrence? Update your playbooks based on lessons learned.

Playbook Templates for Legal SaaS

Data Breach Playbook

Trigger: Confirmed or suspected unauthorised access to client data.

Contain: Isolate affected systems. Terminate all sessions for compromised accounts. Block attacker access.
Assess scope: Which clients' data was accessed? What type of data — case documents, communications, PII?
Preserve evidence: Forensic image of affected systems before any cleanup.
Legal assessment: Engage legal counsel (internal or external) to determine notification obligations.
Notification chain: Client notification, regulatory notification, law enforcement (if applicable).
Remediate: Patch the vulnerability, rotate credentials, enhance monitoring.
Post-incident: Retrospective, playbook update, client follow-up.

Compromised Credentials Playbook

Trigger: Credentials found on dark web, successful login from impossible geography, or credential stuffing with confirmed account access.

Force password reset for all affected accounts immediately.
Terminate all active sessions for those accounts.
Review audit logs for actions taken while the account was compromised.
Check for persistence: Did the attacker create new accounts, modify permissions, or install API keys?
Notify affected users with specific guidance on what to do.
Review MFA status — if compromised accounts lacked MFA, enforce it platform-wide.

Insider Threat Playbook

Trigger: Unusual data access patterns from an authorised user — bulk downloads, access outside role scope, data transfers to personal devices.

Do not alert the subject until legal and HR are consulted.
Preserve logs and access records before any investigation conversation.
Assess scope: What data was accessed? Was it transferred externally?
Coordinate with legal for employment law implications and potential law enforcement referral.
Revoke access once the investigation supports it.

Communication Plans: Who to Notify, When, and What to Say

Legal Notification Obligations

Breach notification is not optional. Timelines vary by jurisdiction:

Regulation	Notification Window	Who Must Be Notified
GDPR (EU)	72 hours to supervisory authority³	Authority + affected individuals if high risk
PDPA (Singapore)	3 calendar days to PDPC	Commission + affected individuals if significant harm
US State Laws	Varies (30-90 days typical)	State AG + affected individuals
HIPAA (US healthcare)	60 days to HHS	HHS + affected individuals + media if >500 people

The GDPR imposes fines of up to EUR 20 million or 4% of global revenue for serious breaches, and missing the 72-hour notification window increases penalties and erodes trust.³

For legal SaaS specifically: NYC Bar Formal Opinion 2024-3 and ABA Formal Opinion 483 establish that lawyers must notify clients when a breach exposes material client confidential information that is "likely to affect the position of the client or the outcome of the client's legal matter."⁴⁵ A data breach doesn't automatically waive attorney-client privilege — but the firm must take affirmative steps to reaffirm privilege designations and prevent unauthorised use of leaked material.

Communication Rules During an Incident

Designate a single spokesperson. Inconsistent public statements create legal liability.
Say what you know, not what you speculate. "We detected unauthorised access and are investigating" — not "we think a Russian hacker group got in."
Don't promise what you haven't verified. "No data was compromised" is a statement you may have to retract. "Our investigation is ongoing" is safe.
Document everything. Every communication, every decision, every timestamp. This is evidence for regulators and potentially for litigation.

Legal Hold Preservation

When a breach may involve litigation or regulatory investigation, implement a legal hold: a directive to preserve all potentially relevant documents, logs, communications, and forensic data. This means:

No automated log rotation that deletes incident-period logs
No system rebuilds that destroy forensic evidence
No email deletion by involved employees
Forensic images of affected systems stored securely

Failure to preserve evidence after a known incident can result in sanctions, adverse inference rulings, and regulatory penalties separate from the breach itself.

The Playbook Maintenance Cycle

A playbook that was written once and never updated is only slightly better than no playbook. Review and update quarterly:

After every real incident (incorporate lessons learned)
After major infrastructure changes (new services, new data flows)
After regulatory changes (new notification requirements)
After tabletop exercises (simulated incidents reveal gaps)

The goal is not perfection — it's preparation. A team with a decent playbook they've rehearsed will outperform a team with a perfect playbook they've never opened.

Next episode: disaster recovery and business continuity — what happens when the incident isn't a breach but a complete system failure, and your clients need their case files.

Sources & references

NIST, SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
NIST, Cybersecurity Framework 2.0.
Konfirmity, GDPR Incident Response Plan: A Practical Guide with Steps & Examples (2026).
NYC Bar Association, Formal Opinion 2024-3: Ethical Obligations Relating to a Cybersecurity Incident.
ABA, When Should Law Firms Notify Clients About Data Breaches?.
UnderDefense, Data Breach Incident Response Plan for 2026.
ABA, Attorney-Client Privilege and Work Product Considerations Following Cyber Incidents.
Linford & Company, NIST SP 800-61 Rev 3: New Incident Response Framework Guide.
Tandem, Updated NIST Incident Response Guidance: SP 800-61 Rev. 3.
Inside Privacy, NIST Publishes Updated Incident Response Recommendations.
Epiq Global, ABA Issues Opinion — How To Respond to Data Breaches.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 54 — incident response playbooks. Last episode we talked about monitoring and detecting security events. This episode is what happens next. Alice, the alert fires, something bad is happening — what do you actually do?

Alice: And the most important thing I can say is: you figure that out before the incident happens, not during it. The worst time to write your incident response plan is while an attacker is actively downloading your clients' case files. That's why you need playbooks — pre-written, rehearsed procedures for specific types of incidents. When something happens, you open the playbook and follow the steps. Adrenaline is high, information is incomplete, and having a checklist to follow is the difference between a contained incident and a catastrophe.

Dan: Mm. NIST updated their guidance on this recently, right?

Alice: They did. NIST SP 800-61 Revision 3 came out in April 2025 — the first major update since 2012. The biggest change is that it now maps incident response directly to the NIST Cybersecurity Framework 2.0. Instead of treating incident response as a standalone activity, it's integrated into the Detect, Respond, and Recover functions we introduced last episode. The message is clear: incident response isn't something that happens separately from your security programme. It's part of it.

Dan: Right. So walk us through the lifecycle. An incident happens — what are the phases?

Alice: Five phases. First: detection and analysis. This is where last episode's monitoring pays off. An alert fires. The on-call person triages it. Is this real or a false positive? What systems are affected? What data might be at risk? You verify using multiple data sources — don't act on a single log entry. Then you classify severity. A successful admin login from an unknown country followed by document downloads is critical — that's all-hands, right now. Unusual login patterns with no confirmed access is medium — investigate within four hours.

Dan: Mm-hmm. Then what — you try to stop it?

Alice: Phase two: containment. Stop the bleeding without destroying evidence. There are two stages. Short-term containment is immediate: block the attacker's IP, terminate compromised sessions, disable compromised accounts, isolate affected servers. Long-term containment is more surgical — apply temporary patches, redirect traffic, set up enhanced monitoring while you prepare for the full fix.

Dan: And the evidence part — that's especially important for legal SaaS, isn't it?

Alice: <sigh> Critically important. If client privileged data was exposed, you may need forensic records for regulatory notifications, insurance claims, or even litigation. Do not wipe or rebuild a compromised system before capturing a forensic image — that's a bit-for-bit copy of the affected system's storage. Containment must preserve evidence, not destroy it.

Dan: Yeah. Phase three?

Alice: Eradication. Remove the root cause. If malware was involved, rebuild affected systems from known-good backups. If credentials were stolen — and we talked about this in Episode 50 with workstation security — rotate every credential the compromised system had access to. Not just the ones you know the attacker used. Every one. Because you can't be certain which credentials were accessed and which weren't. If a vulnerability was exploited, patch it across all systems, not just the one that was hit.

Dan: Mm. Then recovery, I assume?

Alice: Phase four. Restore systems to normal operation. But — and this is key — monitor recovered systems with extra scrutiny for days or weeks after. Attackers commonly leave backdoors. Secondary access paths that activate after the initial breach looks resolved. You think you've cleaned everything up, the attacker has a shell script set to phone home in seventy-two hours.

Dan: Hmm. And the final phase is the retrospective?

Alice: Phase five: post-incident learning. Within a week — while memories are fresh — do a blameless retrospective. What happened? When did we detect it? How long until containment? What worked in the playbook? What didn't? What changes would prevent this from happening again? Then update the playbook. Every real incident teaches you something your hypothetical planning missed.

Dan: Right. Let's talk about specific scenarios. What does a data breach playbook look like for a legal SaaS platform?

Alice: Step one: contain. Isolate affected systems, terminate all sessions for compromised accounts, block attacker access. Step two: assess scope. Which clients' data was accessed? What type — case documents, communications, PII? This determines your notification obligations. Step three: preserve evidence. Forensic images before any cleanup. Step four: legal assessment. Engage legal counsel to determine your notification obligations, because they vary by jurisdiction.

Dan: And those notification timelines are tight.

Alice: Very tight. Under GDPR, you have seventy-two hours to notify the supervisory authority. Singapore's PDPA gives you three calendar days. US state laws vary but typically thirty to ninety days. And missing the GDPR window doesn't just look bad — the regulation imposes fines of up to twenty million euros or four percent of global revenue for serious breaches. Missing the notification deadline is treated as an aggravating factor.

Dan: Mm. And there's an extra layer for legal platforms, right? The attorney-client privilege issue.

Alice: The ABA issued Formal Opinion 483 establishing that lawyers must notify clients when a breach exposes material confidential information. And the NYC Bar's Opinion 2024-3 expanded on this — clarifying that the ethical obligations extend to the technology platforms lawyers choose to use. Here's a crucial point though: a data breach doesn't automatically waive attorney-client privilege. The privilege survives the breach. But the firm — and by extension, the platform — must take affirmative steps to reaffirm privilege designations and prevent unauthorised use of any leaked material.

Dan: Yeah. What about communication during the incident? What do you say publicly?

Alice: Four rules. One: designate a single spokesperson. Inconsistent statements create legal liability. Two: say what you know, not what you speculate. "We detected unauthorised access and are investigating" is safe. "We think it was a Russian hacker group" is not — and you may have to retract it. Three: don't promise what you haven't verified. "No data was compromised" is a statement you might have to walk back. "Our investigation is ongoing" is honest. Four: document everything. Every communication, every decision, every timestamp. This is evidence for regulators, insurers, and potentially for litigation.

Dan: Mm-hmm. And then there's legal hold — preserving evidence for potential legal proceedings?

Alice: When a breach may involve litigation or regulatory investigation, you implement a legal hold. That means: no automated log rotation that deletes incident-period data. No system rebuilds that destroy forensic evidence. No email deletion by anyone involved. Forensic images stored securely. Failure to preserve evidence after a known incident can result in sanctions and adverse inference rulings — meaning the court assumes the destroyed evidence was unfavourable to you. That's separate from any penalties for the breach itself.

Dan: Right. And these playbooks — they're not write-once documents?

Alice: Review quarterly. Update after every real incident, after major infrastructure changes, after regulatory changes, and after tabletop exercises — those are simulated incidents where your team walks through the playbook. The goal isn't a perfect document. It's a rehearsed team. A team with a decent playbook they've actually practised will outperform a team with a perfect playbook sitting in a folder nobody's opened.

Dan: Next episode — disaster recovery and business continuity. What happens when the problem isn't a breach but a complete system failure, and your clients can't access their case files.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.