Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.26 — Response to Information Security Incidents

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.26 ISO 27001ISO 27002BSI DER.2.1

A ransomware attack encrypts the file server at 2 a.m. The on-call administrator reboots the machine, destroying volatile forensic evidence. The CEO learns about the incident from a customer tweet the next morning. A.5.26 exists to prevent exactly this kind of chaos — by requiring documented, rehearsed response procedures.

When an information security event has been classified as an incident under A.5.25, the organisation must respond quickly, effectively and in a coordinated manner. This control defines what “response” means in practice: containment, evidence preservation, escalation, communication and recovery.

What does the standard require?

  • Establish response procedures. The organisation must have documented procedures for responding to confirmed incidents, covering containment, eradication, recovery and communication.
  • Assign qualified responders. A designated team with the necessary competence handles the response. Responsibilities are defined before an incident occurs.
  • Contain the damage. Immediate actions focus on preventing the incident from spreading — isolating affected systems, revoking compromised credentials, blocking malicious traffic.
  • Preserve evidence. Response activities must not destroy evidence needed for root-cause analysis or legal proceedings. A.5.28 provides detailed guidance.
  • Communicate with stakeholders. Internal escalation (management, legal, HR) and external communication (regulators, customers, law enforcement) follow predefined rules.
  • Conduct post-incident review. After resolution, the organisation analyses what happened, identifies control weaknesses and feeds improvements back into the ISMS.

In practice

Build tiered response playbooks. A single generic procedure cannot cover a phishing compromise, a DDoS attack and a physical break-in equally well. Create playbooks for your most likely incident categories and maintain a generic fallback for unexpected scenarios.

Conduct tabletop exercises. Procedures that have never been tested will fail under pressure. Run tabletop exercises at least annually, walking through realistic scenarios with the actual response team. Document the results and update playbooks accordingly.

Define escalation thresholds. Specify clear criteria for when an incident moves from the operational team to management, from management to the board and from internal handling to external authorities. Ambiguity in escalation is one of the most common reasons for delayed response.

Coordinate with external parties. Establish relationships with external forensic providers, legal advisors and relevant CERTs before you need them. During a crisis is the worst time to negotiate contracts or exchange NDAs.

Typical audit evidence

Auditors typically expect the following evidence for A.5.26:

  • Incident response procedure — documented, approved and version-controlled
  • Incident response playbooks — category-specific procedures for common incident types
  • Incident log / register — records of all incidents with timeline, actions taken, responsible persons and resolution status
  • Tabletop exercise reports — evidence that procedures have been tested and improvements identified
  • Communication records — internal escalation messages, regulatory notifications, customer communications
  • Post-incident review reports — root-cause analysis and corrective actions

KPI

% of IS incidents resolved within defined response timeframes

This KPI measures whether the organisation meets its own service-level targets for incident response. Define target resolution times per severity level (e.g. critical: 4 hours, high: 24 hours, medium: 72 hours). Track the percentage of incidents resolved within these windows.

Supplementary KPIs:

  • Mean time to contain (MTTC) per incident severity
  • Percentage of incidents with completed post-incident review within 30 days
  • Number of incidents requiring external escalation (regulator, law enforcement)

BSI IT-Grundschutz

A.5.26 maps to the BSI requirements for incident handling:

  • DER.2.1 (Incident handling) — requires documented procedures for detection, classification, escalation, containment, eradication and recovery of security incidents.

A.5.26 is the operational core of the incident management lifecycle:

Sources

Frequently asked questions

What is the difference between an information security event and an incident?

An event is any observable occurrence in a system or network. An incident is an event (or series of events) that has a significant probability of compromising business operations or threatening information security. A.5.25 covers the classification of events; A.5.26 kicks in once an event has been confirmed as an incident.

Who should be on the incident response team?

At minimum: the CISO or information security officer, an IT operations representative, legal counsel and a communications contact. Depending on the incident type, data protection officers, HR and external forensic specialists may need to join. Roles should be defined and documented before an incident occurs.

Must incidents be reported to authorities?

It depends on applicable law. Under GDPR, personal data breaches must be reported to the supervisory authority within 72 hours. NIS2 mandates reporting of significant incidents to the national CSIRT. Your incident response procedure should include a regulatory notification checklist.