ISO 27001 Incident Management: Requirements and Response Framework

Information security incidents are not a question of if but when. A credential compromise exposes customer records. A misconfigured API endpoint leaks sensitive data. A phishing campaign targets your finance team and succeeds. When these events occur, ISO 27001 requires that your organization detect them rapidly, respond in a structured manner, contain the damage, recover operations, and learn from the experience so the same class of incident does not recur.

ISO 27001 takes a comprehensive approach to incident management through both its core clauses and a dedicated set of Annex A controls. The standard does not prescribe a specific incident response technology stack or mandate a particular team structure. Instead, it requires that you establish a systematic framework for managing incidents — one that is documented, communicated, tested, and continuously improved as part of your broader Information Security Management System (ISMS).

This guide covers the ISO 27001 requirements for incident management, walks through the relevant Annex A controls (A.5.24 through A.5.28), explains how to build a response framework that works under pressure, and addresses the specific challenges SaaS companies face when managing security incidents.

What ISO 27001 Requires for Incident Management

ISO 27001 addresses incident management through two mechanisms: the core management system clauses and the Annex A controls. Understanding both is essential for building a compliant program.

Core Clause Requirements

Clause 6.1 — Actions to address risks and opportunities. Your risk assessment must consider incident scenarios as potential risks. The likelihood and impact of specific incident types should inform your risk treatment decisions, and incident management controls should appear in your risk treatment plan. If your risk assessment identifies “unauthorized access to production database” as a high risk, your treatment plan should include incident response procedures specifically designed for that scenario.

Clause 8.1 — Operational planning and control. Your incident management processes must be planned, implemented, and controlled. This means documented procedures, assigned responsibilities, adequate resources, and defined criteria for evaluating whether the processes are achieving their intended outcomes.

Clause 9.1 — Monitoring, measurement, analysis and evaluation. You must monitor and measure the effectiveness of your incident management processes. Metrics like mean time to detect, mean time to respond, incident recurrence rates, and post-incident action completion rates provide evidence that your program is functioning.

Clause 10.1 — Nonconformity and corrective action. When incidents reveal control failures or process deficiencies, these must be treated as nonconformities. Corrective actions must address root causes, not just symptoms. The connection between incidents and your continuous improvement process is direct and mandatory.

Annex A Controls for Incident Management

The 2022 revision of ISO 27001 consolidates incident management controls under section A.5, within the organizational controls category. Five controls form the incident management framework.

A.5.24 — Information security incident management planning and preparation. This control requires you to establish and communicate incident management procedures. You must define what constitutes an information security event versus an incident, assign roles and responsibilities, establish communication channels, and prepare response procedures before incidents occur. Preparation is not optional — it is a control that auditors will test.

A.5.25 — Assessment and decision on information security events. When an event is detected, you must have a process to assess its nature and severity and decide whether it qualifies as an information security incident. Not every security alert is an incident. A single failed login attempt is an event. Ten thousand failed login attempts against multiple accounts from a botnet is an incident. Your classification criteria must define where that line falls.

A.5.26 — Response to information security incidents. Once an event is classified as an incident, you must respond according to documented procedures. This control covers the full response lifecycle: containment, eradication, recovery, and communication. Responses must be proportional to the severity of the incident, and the procedures must be practical enough that your team can execute them under stress.

A.5.27 — Learning from information security incidents. Every incident is a learning opportunity. This control requires that you analyze incidents after resolution to identify root causes, evaluate the effectiveness of your response, and determine whether controls need to be strengthened. The knowledge gained must feed back into your ISMS — through updated risk assessments, revised controls, modified procedures, or enhanced training.

A.5.28 — Collection of evidence. When an incident may lead to legal proceedings, regulatory action, or disciplinary measures, you must collect and preserve evidence in a forensically sound manner. This control addresses chain of custody, evidence integrity, and admissibility requirements. For SaaS companies, this often means preserving logs, capturing system state, and maintaining detailed timelines.

For a complete walkthrough of all Annex A controls and how they interrelate, see our ISO 27001 Annex A controls guide.

Events vs. Incidents: Why the Distinction Matters

ISO 27001 draws a deliberate line between information security events and information security incidents. Understanding this distinction is critical because it determines your response.

An information security event is any identified occurrence in a system, service, or network state indicating a possible breach of information security policy, failure of controls, or a previously unknown situation that may be security-relevant. Events are observations that require evaluation. Examples include a failed login attempt, a firewall blocking an inbound connection, an antivirus alert on an employee workstation, or an unusual spike in outbound network traffic.

An information security incident is one or more related information security events that have a significant probability of compromising business operations and threatening information security. Incidents require a coordinated response. Examples include confirmed unauthorized access to customer data, successful phishing that led to credential compromise, malware infection that spread across multiple systems, or a DDoS attack that disrupted service availability.

The assessment process defined by control A.5.25 sits between these two concepts. Every event must be evaluated against your classification criteria to determine whether it constitutes an incident. This triage process prevents two equally damaging failure modes: treating every event as an incident (which exhausts your response team and desensitizes them to real threats) and failing to recognize genuine incidents among the noise of routine events.

Practical triage criteria. Your triage process should evaluate events against these factors:

• Confidentiality impact: Was sensitive data accessed, exposed, or exfiltrated?
• Integrity impact: Was data or system configuration modified without authorization?
• Availability impact: Were services disrupted or degraded?
• Scope: Is the impact limited to a single system or user, or does it affect multiple systems, customers, or data sets?
• Active threat: Is the threat actor still present or is the vulnerability still being exploited?
• Regulatory implications: Does the event potentially trigger breach notification obligations under GDPR, contractual commitments, or other regulatory frameworks?

If any of these factors indicate significant impact, the event should be escalated to incident status.

Incident Classification and Severity Levels

Once an event is classified as an incident, you must assign a severity level that determines the speed and scale of your response. ISO 27001 does not prescribe specific severity levels — you define them based on your organization’s context, risk appetite, and operational requirements.

A four-tier severity model works well for most SaaS organizations:

Severity	Definition	Response Initiation	Example Scenarios
Critical (P1)	Active breach with confirmed data exposure, complete service outage, or active exploitation of production systems	Immediate — within 15 minutes	Customer data exfiltration confirmed, ransomware encrypting production databases, complete platform unavailable
High (P2)	Significant security compromise without confirmed data exposure, partial service outage, or active attack in progress	Within 1 hour	Unauthorized admin access detected, authentication service degraded, active brute force attack with some successes
Moderate (P3)	Security event requiring investigation and response, limited operational impact	Within 4 hours	Suspicious data access patterns, non-critical service disruption, malware contained to single workstation
Low (P4)	Minor security event, near-miss, or policy violation with minimal impact	Within 24 hours	Failed phishing attempt (no credentials compromised), minor policy exception, vulnerability discovered but not exploited

Severity determines resource allocation. A P1 incident activates your full incident response team, executive communication, and potentially customer notification. A P4 incident might be handled by a single engineer during normal business hours. Your procedures must define what resources are mobilized at each severity level, who has authority to escalate or de-escalate, and what communication cadence applies.

Severity can change during an incident. An event initially classified as P3 may be escalated to P1 when investigation reveals broader impact. Your procedures should define escalation triggers and ensure that escalation is frictionless — the person investigating a P3 should be empowered to escalate to P1 without seeking management approval if the criteria are met.

The Incident Response Process

ISO 27001 requires documented response procedures (A.5.26) that your team can execute under pressure. A structured five-phase response process provides the framework.

Phase 1: Detection and Reporting

Detection is the starting point for every incident. Your ability to detect incidents depends on the monitoring capabilities you have deployed and the reporting culture you have established.

Technical detection sources. For SaaS companies, detection typically comes from:

• SIEM and log management — Centralized log analysis with correlation rules that detect patterns indicating compromise (unusual access patterns, privilege escalation, data exfiltration indicators)
• Cloud security monitoring — AWS CloudTrail, GCP Audit Logs, Azure Activity Logs with alerts on security-relevant events (IAM changes, security group modifications, unexpected resource creation)
• Application monitoring — APM tools that detect anomalies in application behavior (unexpected error rates, unusual API usage patterns, latency anomalies)
• Endpoint detection and response (EDR) — Monitoring on employee workstations for malware, unauthorized software, and suspicious process activity
• Vulnerability scanning — Regular automated scans that identify exploitable vulnerabilities before attackers do
• Third-party threat intelligence — Feeds that alert you to threats targeting your industry, technology stack, or supply chain

Human reporting. Not every incident is detected by technology. Employees who notice suspicious emails, customers who report unexpected behavior, and partners who observe anomalies are all valid detection sources. Your incident management procedures must include a clear, accessible reporting channel — a dedicated email address, a Slack channel, a button in your internal tools — and employees must know how to use it. Your ISMS policies should define reporting obligations for all personnel.

Reporting requirements. Every detected event must be logged with:

• Date and time of detection
• Source of detection (system alert, human report, external notification)
• Description of the observed behavior
• Systems or data potentially affected
• Initial assessment of severity
• Name and contact information of the person reporting

Phase 2: Assessment and Triage

Once an event is reported, it must be assessed against your classification criteria to determine whether it constitutes an incident and, if so, what severity level applies.

Initial triage should happen fast. For events detected by automated systems, initial triage should occur within minutes. The on-call engineer or security analyst evaluates the alert, checks for corroborating evidence, and makes an initial classification decision. This is not the time for deep investigation — it is a rapid assessment to determine whether the event warrants incident-level response.

Triage checklist. Within the first 30 minutes of receiving a report:

1. Is the event confirmed (true positive) or can it be ruled out (false positive)?
2. What systems, data, or services are affected or potentially affected?
3. Is the threat still active? Is the vulnerability still being exploited?
4. Is customer data potentially at risk?
5. What is the blast radius — single system, single customer, all customers, all systems?
6. Does this trigger any regulatory notification obligations (e.g., GDPR breach notification)?

Decision: escalate or close. Based on the triage, the event is either classified as an incident (with an assigned severity level) and escalated to the incident response team, or it is closed as a non-incident with documentation explaining why. Closing an event does not mean ignoring it — the event log should capture the triage analysis and the rationale for the closure decision.

Phase 3: Containment

Containment stops the incident from getting worse. The goal is to limit the damage while preserving your ability to investigate the root cause.

Short-term containment focuses on immediate actions:

• Isolate affected systems from the network (without powering them off, to preserve forensic state)
• Revoke compromised credentials and rotate affected API keys and tokens
• Block malicious IP addresses, domains, or user agents at the firewall or WAF
• Disable compromised user accounts
• Apply emergency access restrictions to limit exposure

Long-term containment establishes sustainable measures while you prepare for eradication:

• Deploy temporary patches or configuration changes to close the exploited vulnerability
• Implement additional monitoring on the attack vector
• Set up compensating controls to maintain security while primary controls are being rebuilt
• Redirect traffic away from compromised components to known-good systems

SaaS-specific containment considerations:

• Multi-tenant isolation. If the incident affects one tenant, verify that your tenant isolation controls prevented lateral movement to other tenants. If isolation controls may have been breached, treat all tenants as potentially affected.
• API key rotation. Compromised API keys may be embedded in customer applications. Coordinate with affected customers before rotating keys to avoid cascading service disruptions.
• Infrastructure-as-code environments. If the attacker modified infrastructure configurations, your containment must include reverting infrastructure changes and ensuring the attacker did not introduce persistent access mechanisms in your IaC repositories.
• CI/CD pipeline compromise. If the build or deployment pipeline was compromised, all artifacts produced by that pipeline during the compromise window must be considered tainted.

When to take services offline. This is one of the hardest decisions during an incident. Taking a service offline stops the attack but also stops your customers’ operations. Consider taking services offline when active data exfiltration is occurring and cannot be stopped otherwise, when the attacker has persistent access that cannot be contained in place, or when continuing to operate would put additional customer data at risk.

Phase 4: Eradication and Recovery

Once the incident is contained, eliminate the root cause and restore normal operations.

Root cause analysis. Determine exactly how the incident occurred. Common root causes in SaaS incidents include:

• Unpatched vulnerabilities in application code, frameworks, or infrastructure
• Misconfigured cloud resources (overly permissive IAM policies, public storage buckets, insecure network configurations)
• Compromised credentials, often from credential reuse, phishing, or credential stuffing
• Vulnerable third-party dependencies
• Insufficient input validation enabling injection attacks
• Social engineering that bypassed security awareness training

Eradication actions. Based on the root cause:

• Patch the exploited vulnerability across all affected systems
• Remove all unauthorized access mechanisms (backdoors, rogue SSH keys, unauthorized IAM roles, malicious code)
• Rebuild compromised systems from known-good images or clean deployments rather than attempting to clean compromised systems in place
• Rotate all credentials that may have been exposed, including service accounts, API keys, database credentials, and encryption keys
• Update firewall rules, WAF configurations, and security group settings to prevent the same attack vector

Recovery validation. Before declaring the incident resolved and restoring full service:

• Verify that the vulnerability is fully patched across all affected systems and environments
• Confirm that all unauthorized access mechanisms have been removed
• Validate data integrity by comparing against clean backups
• Run security scans against restored systems
• Confirm that monitoring and alerting are operational on restored systems
• Verify that all credentials have been rotated and old credentials are fully invalidated

Heightened monitoring period. After recovery, maintain enhanced monitoring for at least 30 days. Sophisticated attackers often establish multiple persistence mechanisms, and eradicating one does not guarantee the others have been found. Watch for indicators of re-compromise: unusual authentication patterns, unexpected process execution, anomalous network traffic, or unauthorized configuration changes.

Phase 5: Post-Incident Review

Control A.5.27 requires that you learn from incidents. The post-incident review is where that learning happens, and it is one of the elements auditors examine most carefully because it connects incident management to your continuous improvement processes.

Timing. Conduct the post-incident review within 5 business days of incident resolution while details are still fresh. For P1 incidents, consider scheduling a brief initial review within 24-48 hours, followed by a more thorough analysis once the team has had time to compile data.

Blameless culture. The review must focus on systemic factors, not individual blame. If people are afraid to be honest about what happened and what they did or failed to do, the review will miss the insights that prevent future incidents. Document the contributing factors, not the person who clicked the phishing link.

What to document:

• Timeline — A detailed, timestamped reconstruction of the incident from first indicator through full resolution. Include when the event was detected, when it was classified as an incident, when containment was achieved, and when recovery was confirmed.
• Root cause — The technical root cause and the contributing factors that enabled it (process gaps, monitoring blind spots, training deficiencies, architectural weaknesses).
• Impact assessment — Quantify the impact: number of records exposed, number of customers affected, duration of service disruption, financial cost (direct and indirect), regulatory implications.
• Response effectiveness — What went well? What could have been done faster or better? Were the procedures adequate? Did the team have the tools and information they needed?
• Action items — Specific, assigned, time-bound improvements. Every action item must have an owner and a deadline. Action items that are never completed are worse than no action items at all — they signal to auditors that your improvement process is performative rather than genuine.

Feed findings back into the ISMS. Post-incident findings must flow back into multiple ISMS processes:

• Update your risk assessment if the incident revealed previously unidentified risks or demonstrated that existing risks were scored too low
• Revise controls and procedures based on identified weaknesses
• Update training content to address skill or awareness gaps revealed by the incident
• Consider whether the incident affects your Statement of Applicability or control selection

Reporting and Escalation Procedures

ISO 27001 requires that you define and communicate escalation procedures so that incidents reach the right people at the right time.

Internal Escalation

Severity-based escalation matrix. Define who is notified at each severity level:

Severity	Immediate Notification	Within 1 Hour	Within 4 Hours
P1	Incident Response Team, CISO/Security Lead, CTO	CEO, Legal Counsel, Customer Success Lead	Board (if data breach confirmed)
P2	Incident Response Team, Security Lead	Engineering Manager, Legal Counsel	CISO, CTO
P3	On-call Security Analyst	Security Lead	Engineering Manager
P4	On-call Security Analyst	Security Lead (next business day)	—

Escalation authority. Anyone in the organization should be able to report a security event. However, the authority to declare an incident (triggering formal response procedures) and to escalate severity should be defined. Typically, the on-call security analyst or engineer can declare P3 and P4 incidents, while P1 and P2 declarations require confirmation from the security lead or incident commander. Critically, escalation should never be delayed because the designated authority is unavailable — define backup authorities for every role.

External Reporting

Regulatory notification. If the incident involves personal data of EU residents, GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of the breach. Article 34 may require direct notification to affected individuals if the breach poses a high risk to their rights and freedoms. Your incident response procedures must include specific steps for assessing GDPR notification obligations and executing notifications within the required timeframes. See our complete GDPR data breach notification guide for detailed requirements.

Customer notification. For SaaS companies, customer notification is often both a contractual obligation and a trust imperative. Your procedures should define:

• Criteria for determining which customers must be notified
• Notification timeframes (often defined in your DPA or service agreement — see our GDPR DPA guide)
• Communication channels (email, status page, in-app notification, phone for critical accounts)
• Content requirements (what happened, what data was affected, what you are doing about it, what customers should do)
• Follow-up communication cadence

Law enforcement. Some incidents may warrant law enforcement involvement — particularly if criminal activity is suspected (ransomware, deliberate data theft, insider threat). Your procedures should define the criteria for law enforcement notification and identify who within your organization has authority to engage law enforcement.

Evidence Preservation

Control A.5.28 specifically addresses evidence collection and preservation. For SaaS companies, this is particularly important because your infrastructure exists in cloud environments where evidence can be ephemeral.

Principles of evidence preservation:

• Collect early. Begin evidence collection as soon as an incident is suspected, not after it is confirmed. Evidence that is not collected cannot be analyzed later.
• Maintain chain of custody. Document who collected each piece of evidence, when, how, and where it was stored. If evidence may be used in legal proceedings, chain of custody documentation must be rigorous.
• Preserve integrity. Do not modify evidence during collection. Use forensic imaging tools that create exact copies. Calculate and record hash values (SHA-256) for all collected evidence to prove it was not tampered with after collection.
• Secure storage. Store evidence in a location accessible only to authorized personnel. Evidence stored in the same environment that was compromised is not secure.

SaaS-specific evidence types to preserve:

• Cloud audit logs — CloudTrail, GCP Audit Logs, Azure Activity Logs. These logs may have retention limits — ensure they are preserved before they rotate out.
• Application logs — API access logs, authentication logs, authorization logs, error logs. Centralize these before they are overwritten by normal log rotation.
• Database audit logs — Query logs showing what data was accessed, by whom, and when.
• Network flow logs — VPC flow logs, load balancer logs, WAF logs showing traffic patterns.
• Container and orchestration logs — Kubernetes audit logs, Docker container logs, deployment records.
• Infrastructure-as-code history — Git history for Terraform, CloudFormation, or other IaC repositories showing any unauthorized modifications.
• Email and communication records — Relevant to social engineering incidents. Preserve the phishing email, message headers, and any communications the attacker had with employees.
• System state — Memory dumps, disk images, running process lists, network connection states. In cloud environments, create snapshots of affected instances before terminating them.

Incident Management Policy Template Outline

Your incident management policy is a required document within your ISMS. It should be reviewed and approved by senior management, communicated to all relevant personnel, and reviewed at least annually. Here is a structural outline aligned with ISO 27001 requirements.

1. Purpose and scope — Define the objective of the policy (systematic management of information security incidents) and its scope (all systems, data, and personnel within the ISMS scope).

2. Definitions — Define information security event, information security incident, and incident severity levels. Use the ISO 27000 definitions as a starting point and tailor them to your organization’s context.

3. Roles and responsibilities — Define the incident response team roles (Incident Commander, Technical Lead, Communications Lead, Scribe), identify who fills each role, and establish backup assignments. Define responsibilities for all employees (reporting obligations, evidence preservation).

4. Incident classification — Document your severity levels (P1-P4), the criteria for each level, and the escalation and response requirements associated with each.

5. Response procedures — Reference your detailed response playbooks for each incident type. The policy establishes the framework; the playbooks provide step-by-step procedures.

6. Communication and notification — Define internal escalation paths, external notification obligations (regulatory, customer, law enforcement), communication templates, and approval workflows for external communications.

7. Evidence handling — Define evidence collection procedures, chain of custody requirements, secure storage locations, and retention periods.

8. Post-incident review — Mandate post-incident reviews for all P1 and P2 incidents, define the review process, and establish the connection between review findings and corrective actions.

9. Testing and exercises — Define the frequency and types of incident response testing (tabletop exercises, simulations, red team exercises) and the requirement to document test results and improvements.

10. Metrics and reporting — Define the incident management KPIs that are reported to management and reviewed as part of the management review process.

This policy should integrate with your broader ISMS policy framework and be referenced in your certification checklist.

Tabletop Exercises

Tabletop exercises are the most practical way to test your incident response procedures without impacting production systems. ISO 27001 auditors look favorably on organizations that regularly exercise their response capabilities.

Structure of a tabletop exercise:

1. Scenario briefing — The facilitator presents a realistic incident scenario relevant to your organization. For SaaS companies, scenarios should be drawn from real-world incidents in your industry.
2. Phased injects — The facilitator reveals new information in stages, simulating how an incident unfolds in reality. Each inject forces the team to reassess, make decisions, and take actions.
3. Team discussion — At each phase, the response team discusses what they would do, who they would contact, what information they need, and what decisions they need to make. This reveals gaps in procedures, unclear responsibilities, and missing capabilities.
4. Debrief — After the scenario concludes, the team reviews what worked, what did not, and what needs to change. This produces an action list similar to a post-incident review.

Recommended tabletop scenarios for SaaS companies:

• Customer data breach — An attacker exploits a SQL injection vulnerability to exfiltrate customer records. Tests detection, containment, customer notification, and GDPR breach notification procedures.
• Ransomware — Ransomware encrypts production databases and the attacker demands payment. Tests backup and recovery procedures, business continuity, executive decision-making, and customer communication.
• Supply chain compromise — A widely-used open-source dependency is discovered to contain malicious code that has been present in your production environment for weeks. Tests vulnerability assessment, blast radius analysis, and remediation at scale.
• Insider threat — A departing employee is discovered to have been exfiltrating proprietary data for months. Tests access review procedures, forensic investigation capabilities, legal coordination, and HR involvement.
• Cloud infrastructure compromise — An attacker gains access to your cloud management console through a compromised service account. Tests cloud-specific response procedures, infrastructure-as-code integrity verification, and multi-tenant isolation validation.
• DDoS attack — A sustained DDoS attack overwhelms your application, rendering it unavailable to customers. Tests availability incident procedures, CDN/WAF failover, customer communication, and SLA impact assessment.

Frequency and documentation. Conduct tabletop exercises at least twice per year, rotating through different scenarios. Document each exercise: the scenario presented, participants, decisions made, gaps identified, and resulting action items. This documentation serves as audit evidence of your testing program.

SaaS-Specific Incident Scenarios

SaaS companies face incident types that traditional on-premises organizations may not encounter. Your incident management framework must account for these.

Multi-Tenant Data Exposure

A code defect or misconfiguration causes one tenant to see another tenant’s data. This is one of the most damaging incidents for a SaaS company because it undermines the fundamental trust that customer data is isolated.

Response considerations:

• Immediately investigate whether the exposure was bidirectional (could both tenants see each other’s data?) or unidirectional
• Determine the exact data types exposed and the duration of the exposure
• Assess whether the exposed data includes personal data triggering GDPR notification
• Notify both the exposing tenant and the affected tenant, even if the exposure was unintentional and brief
• Conduct a thorough review of all tenant isolation mechanisms to verify no similar vulnerabilities exist

CI/CD Pipeline Compromise

An attacker compromises your build pipeline — through a malicious dependency, a compromised build tool, or access to your CI/CD configuration — and injects malicious code into your application.

Response considerations:

• Identify the exact window during which the pipeline was compromised
• Determine which builds and deployments were affected
• Roll back to the last known-good build artifact
• Audit all dependencies introduced during the compromise window
• Review CI/CD access controls, secrets management, and pipeline integrity verification
• Consider whether customer data was accessible to the injected code

API Key Leakage

A developer accidentally commits API keys or secrets to a public repository, or API keys are exposed through a misconfigured logging system.

Response considerations:

• Immediately rotate the exposed keys, even before the full investigation is complete
• Determine whether the exposed keys were used during the exposure window
• Review access logs for any unauthorized usage of the compromised keys
• Implement pre-commit hooks and secrets scanning to prevent future leaks
• If customer API keys were exposed, coordinate notification and rotation with affected customers

Third-Party Service Breach

A critical vendor — your identity provider, cloud infrastructure provider, or a SaaS tool that processes customer data — reports a security breach that may affect your data.

Response considerations:

• Assess which of your data or systems the vendor had access to
• Determine whether the vendor breach affected your data specifically (vendors may not immediately know which customers were impacted)
• Implement compensating controls (additional monitoring, credential rotation, increased access restrictions)
• Review your contractual provisions for vendor breach notification (see your supplier management procedures)
• Evaluate whether the vendor breach triggers your own customer notification obligations

Account Takeover Campaign

Attackers use credential stuffing (testing stolen credentials from other breaches against your application) to gain unauthorized access to customer accounts.

Response considerations:

• Identify all compromised accounts and force password resets
• Lock accounts showing indicators of compromise
• Analyze the attack pattern (source IPs, timing, targeted accounts) to implement blocking rules
• Assess what data the attackers accessed from compromised accounts
• Implement or strengthen rate limiting, bot detection, and anomalous login detection
• Notify affected customers with specific guidance on securing their accounts

Integrating Incident Management with GDPR Breach Notification

For SaaS companies processing personal data of EU residents, incident management and GDPR breach notification are intertwined. Your incident response procedures must include specific steps to assess and execute GDPR notification obligations.

When GDPR breach notification is triggered. A personal data breach under GDPR is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Not every security incident is a personal data breach, but every personal data breach assessment must happen early in your incident response.

72-hour notification deadline. GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. The clock starts when your organization becomes aware — not when the investigation is complete. Your incident response procedures must include a GDPR assessment step within the first 2 hours of incident classification to determine whether the 72-hour clock has started.

Individual notification. If the breach is likely to result in a high risk to the rights and freedoms of affected individuals, GDPR Article 34 requires direct notification to those individuals. Your incident response procedures must include criteria for assessing high risk and templates for individual notification.

Documented assessment. Even if you determine that GDPR notification is not required (because the breach did not involve personal data or because the data was encrypted and the encryption was not compromised), you must document the assessment and the rationale for the decision. Auditors and regulators will want to see this documentation.

For complete details on GDPR breach notification requirements, timelines, and procedures, see our GDPR data breach notification guide.

Measuring Incident Management Effectiveness

ISO 27001 Clause 9.1 requires that you monitor and measure the effectiveness of your ISMS processes, including incident management. The following metrics provide meaningful insight into your program’s performance.

Mean time to detect (MTTD). The average time between an incident occurring and your organization detecting it. This metric reflects the effectiveness of your monitoring and detection capabilities. Track trends over time — MTTD should decrease as you improve monitoring coverage and detection rules.

Mean time to respond (MTTR). The average time between incident detection and the initiation of formal response procedures. This measures how quickly your team mobilizes. It should be compared against your target response times for each severity level.

Mean time to contain (MTTC). The average time between response initiation and successful containment of the incident. This measures operational response effectiveness.

Mean time to resolve (MTTR-resolve). The average time from detection to full resolution and recovery. This end-to-end metric captures the complete incident lifecycle.

Incident recurrence rate. The percentage of incidents that represent a recurrence of a previously experienced incident type. A high recurrence rate indicates that post-incident improvements are not being effectively implemented.

Post-incident action completion rate. The percentage of action items from post-incident reviews that are completed within their defined deadlines. This directly measures the effectiveness of your continuous improvement process.

False positive rate. The percentage of reported events that are classified as non-incidents after triage. An excessively high false positive rate indicates that detection rules need tuning. An excessively low rate may indicate that your monitoring is not sensitive enough.

Report these metrics in your management review (Clause 9.3) to provide senior management with visibility into incident management performance and to support data-driven decisions about resource allocation and improvement priorities.

Common Mistakes in ISO 27001 Incident Management

No distinction between events and incidents. When every security alert triggers a full incident response, your team burns out quickly. When no alerts trigger a formal response, incidents go unmanaged. Define clear classification criteria and train your team to apply them consistently.

Incident response plan that exists but has never been tested. An untested plan provides false confidence. When a real incident occurs and the team opens the plan for the first time, they discover outdated contact information, undefined escalation paths, and procedures that do not match the current environment. Test at least annually with tabletop exercises.

Post-incident reviews that produce action items that are never completed. This is worse than not conducting reviews at all. It signals to auditors that your improvement process is performative. Every action item must have an owner, a deadline, and tracking until completion.

Failing to preserve evidence. In the rush to restore service, teams reboot servers, redeploy applications, and rotate logs before forensic analysis is complete. Establish a clear protocol: preserve evidence first, then restore service. In cloud environments, take snapshots before terminating affected instances.

No integration with GDPR breach notification. For SaaS companies processing EU personal data, failing to assess GDPR notification obligations during incident response is a compliance failure independent of the ISO 27001 finding. Your incident procedures must include a GDPR assessment step.

Treating incident management as a security team responsibility only. Effective incident response involves engineering, legal, customer success, communications, and executive leadership. If your incident management program is siloed within the security team, you will have gaps in communication, notification, and business decision-making during incidents.

No SaaS-specific playbooks. Generic incident response procedures developed for traditional IT environments often do not address SaaS-specific scenarios like multi-tenant data exposure, CI/CD pipeline compromise, or API key leakage. Develop playbooks tailored to your architecture and threat model.

How GRCTrail Helps

GRCTrail provides SaaS teams with structured incident management workflows that satisfy ISO 27001 requirements while generating the audit evidence your certification body needs to see.

• Incident response playbook templates aligned with ISO 27001 Annex A controls A.5.24-A.5.28, pre-configured for common SaaS incident types with step-by-step procedures, severity-based escalation paths, and integrated GDPR breach assessment checklists
• Incident tracking and evidence management that captures timelines, decisions, containment actions, and post-incident review findings in a timestamped, auditable format — with automatic evidence packaging for certification audits and surveillance assessments
• Tabletop exercise management with scenario libraries, participant tracking, findings documentation, and action item tracking that demonstrates your testing program to auditors

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Complete Guide for SaaS Companies
• ISO 27001 Annex A Controls: Complete Guide
• ISO 27001 Continuous Improvement: Surveillance Audits and ISMS Maintenance
• ISO 27001 Certification Checklist
• SOC 2 Incident Response: Requirements and Playbook
• GDPR Data Breach Notification Guide
• ISO 27001 Policies: What You Need to Document