Guides

Incident Response Communications Guide for SaaS Teams

When an incident hits, the reporting clock may already be running. This guide walks your team through identification, containment, notification, and closure, plus gives you a customer email template and a print-ready checklist so nobody's improvising roles or wording in the moment.

Download document

Key Takeaways

Establish incident response roles, severity levels, and escalation paths before an incident happens.
The 12-step SOP runs from identification through post-incident review, with one incident lead owning coordination and the decision record throughout.
Regulatory and contractual reporting clocks often start the moment the organization becomes aware, so legal/compliance escalation happens immediately, in parallel with technical investigation.
All external communication should follow a "what we know / what we don't yet know / what we're doing" structure, and never present assumptions as confirmed facts.
The customer notification email template is ready to adapt, paired with a short holding statement for the first hours when facts are still unconfirmed.
Evidence preservation and a single authoritative timeline are maintained throughout so the incident can be reconstructed later.
Closure needs required notifications, customer commitments, and retained documentation all have to be complete first.
A post-incident review (within 5–10 business days) should assign an owner and deadline to every improvement identified.
Regulatory classification and notification decisions need qualified legal review.

Security Operations Resource

Incident Response Communications Guide

When a security incident happens, the reporting clock may already be running. Work through this once before you need it — assign the roles, agree the severity model, and get the notification language reviewed by legal and communications while nothing is on fire.

CISOs & security leaders SaaS & software companies Engineering & security teams Vendors selling into the EU

Twelve steps from identification through post-incident review

Click a step to expand it. Fields in brackets are decisions your organization owns.

Function	Primary responsibility
Security	Investigation, evidence, containment, and security assessment
Engineering	Product analysis, remediation, testing, and deployment
Legal & compliance	Regulatory, legal, and contractual assessment
Executive leadership	Business decisions and executive escalation
Communications	External messaging and communications coordination
Customer success & support	Customer communication and inbound questions

1Incident identified▾

Open an incident record and notify the incident response lead. Do not wait for complete information before opening an incident.

—May surface via monitoring, employee/customer/vendor report, vulnerability disclosure, pentesting, threat intel, or law enforcement contact

—Record immediately: discovery date/time, how it was found, affected systems, initial evidence, actions already taken

2Assign an incident lead▾

One person coordinates the response and maintains the record of decisions and actions, even when several teams are involved. Incident lead: Role / name Backup: Role / name

3Triage and classify▾

Establish as quickly as possible: what happened and when it began, whether exploitation is suspected or confirmed, whether the incident is ongoing, which systems/customers may be affected, and what evidence exists versus what's still unknown.

SEV-1 CriticalConfirmed or highly likely significant compromise, active exploitation, or major business impact.

SEV-2 HighSignificant issue requiring urgent investigation, with limited or unconfirmed impact.

SEV-3 MediumRequires investigation with limited immediate impact.

SEV-4 LowLow-risk event that can follow normal security workflows.

Replace these definitions with your established severity model where one exists — what matters is that the level maps to a known escalation path.

4Preserve evidence▾

Preserve what will be needed to reconstruct the incident and avoid unnecessarily altering it during containment. Record significant vulnerabilities and decisions with timestamps as you go.

—Application, API, auth/identity, and cloud audit logs; SIEM events; endpoint telemetry; network logs

—Source code and deployment records, CI/CD records, vulnerability scanner results, affected component versions

—Third-party notifications and relevant internal communications

5Contain the incident▾

Security and engineering weigh the risk of continued exploitation against operational impact. Document what changed, when, who approved it, and why.

—Disable compromised accounts, rotate credentials/keys/tokens, isolate affected systems

—Disable vulnerable functionality, block indicators of compromise, apply temporary mitigations

—Restrict access, increase monitoring, withdraw affected releases

6Determine reporting and notification obligations▾

Escalate potentially reportable incidents to legal, compliance, and security decision makers immediately — this is the step where the clock matters most.

—Assess: cybersecurity regulations, breach/privacy notification requirements, customer contract commitments, cyber insurance and partner/vendor obligations

—Record for every reportable event: time of awareness, reporting decision and rationale, deadlines, submission owner, and confirmation of submission

7Establish a communications plan▾

Decide which audiences require communication and designate one owner for external messaging (regulators, customers, employees, executives, the board, insurer, partners, law enforcement, media). Structure every update around:

—What we know — facts supported by current evidence, nothing inferred

—What we do not yet know — open questions, stated plainly rather than omitted

—What we are doing — containment, investigation, remediation, and customer protection measures underway

Never present assumptions as confirmed facts.

8Notify affected customers▾

Where notification is required or appropriate, start from the customer notification template in Part 02. Security, legal, and communications review external copy per your approval process — don't delay urgent escalation because final wording isn't approved yet.

9Remediate and validate▾

Once root cause is understood: develop, review, and test the fix, then validate the vulnerability can no longer be exploited. Check for related attack paths elsewhere. Targeted or penetration testing can confirm the remediation addresses the underlying vulnerability rather than just its symptoms.

10Maintain a single incident timeline▾

One authoritative timeline maintained throughout: initial activity, detection, internal escalation, major decisions, containment, reporting decision, regulatory notification, customer communication, remediation, validation, closure.

11Close the incident▾

The incident lead approves closure only once every condition below is true:

—Immediate security risk addressed; remediation complete or formally tracked

—Required notifications made; customer commitments complete or assigned

—Relevant monitoring remains in place; evidence and documentation retained

Closure date: Date Approved by: Name / role

12Conduct a post-incident review▾

Schedule within five to ten business days of closure for significant incidents. Assign every improvement an owner and target date. Ask: what allowed the incident to occur, what delayed detection, did we have sufficient logs and access, were escalation paths clear, and were communications timely and accurate?

Customer notification email

Built on the known / unknown / doing structure. Send this once the facts in it are true, and not before.

Subject

[Security Incident Update] Important information regarding Product / Service

Dear Customer name,

We are writing to inform you of a security incident that may affect your use of Product / Service. We want you to have the facts we have today, what we are still working to confirm, and the steps we are taking.

What happened

On date, our security team identified factual description of the issue affecting system, product, or component. We began investigating immediately and contained / are actively containing the issue.

What we know

Based on our investigation to date: confirmed facts, including period of exposure and data or functionality involved. We have no evidence at this time that state only what the evidence actually supports.

What we do not yet know

Our investigation is ongoing. We are still working to determine open questions. We will not speculate ahead of the evidence, and we will tell you what we find.

What we are doing

We have containment and remediation actions taken. We are investigation, monitoring, and validation work underway, and we have engaged external support, if applicable.

What we recommend you do

Specific customer actions, or: no action is required from you at this time. If you would like to review activity on your own account, how to do that.

Next update

We will provide our next update by date and time, with time zone, whether or not there is new information to report. If you have questions in the meantime, contact us at security contact address.

We take the security of your data seriously, and we are treating this with the urgency it deserves.

Name
Title, Company

Holding statement — first hours

Use when customers are asking and the investigation is too young to answer them:

"We are aware of a potential security issue affecting Product / Service and our security team is actively investigating. We are treating it as our highest priority. We will share confirmed information, including any impact to your account, by date and time. We would rather be accurate than fast, and we will not speculate while the investigation is open."

Quick checklist and key contacts

Print and keep working. Sequence matters less than coverage — note the time against each item and hand the page to whoever takes over from you.

—Open the incident record and note the discovery time

—Assign the incident lead

—Determine initial severity

—Identify affected or potentially affected products and systems

—Preserve relevant evidence

—Determine whether exploitation is active

—Begin containment

—Notify required internal stakeholders

—Escalate potential reporting obligations to legal and compliance

—Record regulatory and contractual deadlines

—Establish what is known, unknown, and under investigation

—Determine whether customers require notification

—Prepare and approve the customer communication

—Remediate the identified vulnerability

—Validate the remediation independently

—Continue monitoring; maintain the incident timeline

—Complete required follow-up communications

—Conduct the post-incident review; assign and track improvement actions

Key contacts

Incident lead

Name / phone / email

Security

Contact

Engineering

Contact

Legal & compliance

Contact

Executive escalation

Contact

Communications

Contact

Customer support

Contact

Cyber insurer

Contact

External IR provider

Contact

This guide supports incident response planning and communications. Organizations should adapt it to their own environment and have qualified legal and compliance professionals determine applicable notification and reporting obligations. Adapt to your environment — not legal advice.