What ISO 27001 asks of incident management and how automation helps meet it
If you own the ISMS or lead the SOC and a surveillance or recertification audit is coming, the question is whether incident handling is planned, documented and visibly followed. Controls A.5.24 and A.5.26 in ISO/IEC 27001:2022 require that you define and communicate incident management processes, roles and responsibilities, and that incidents are responded to under documented procedures. Shuffle does not write that plan for you, but a well-built set of playbooks produces the triage, escalation and case records that show the plan is being followed. The 2022 edition of the standard lists 93 controls in four themes, and the incident controls sit in the organizational theme, clause 5.
ISO does not certify organizations. Accredited certification bodies audit your management system against the control set, and they will sample evidence from the period since your last audit. Before you change anything, confirm with your certification body which edition and transition date applies to your certificate, and check how they expect incident records to be presented. Agree with the auditor in advance what counts as a logged incident, which severities trigger escalation, and who must approve a closure. Those answers decide which fields your Shuffle workflows must write into each case.
Start by mapping each playbook step to a sentence in your incident procedure and to a field in the case record, for example a triage verdict, the escalation recipient and the time of each handoff. Keep the playbook version, the approval for any destructive action and the link to the lessons-learned entry together with the case. Ask your implementation partner how Shuffle workflow versions and execution history will be retained, exported and protected from change, since an auditor sampling incidents will ask for both the record and proof it has not been altered. Plan the lessons-learned step as a required workflow stage, so the register cannot be closed without a recorded review.
Mapping A.5.24 to A.5.26 to Shuffle playbooks, Wazuh and case records
This table maps the two ISO/IEC 27001:2022 incident controls, A.5.24 and A.5.26, to the Shuffle, Wazuh and case record configuration that produces the evidence an auditor samples. Read each row as a requirement, the function it needs, and the configuration choices that make it demonstrable. The main takeaway is that the documented procedure and the automated workflow must match, or the auditor will find the gap.
| Requirement | What the function must do | How to configure it |
|---|---|---|
| A.5.24 planning and preparation | Define, establish and communicate the incident process, roles and responsibilities before incidents occur | Keep the incident procedure as the source for playbook names and owners; set on-call routing in Shuffle workflows; record role assignments and communication paths in the incident register |
| A.5.24 playbook library and on-call routing | Show that planned responses exist for likely incident types and that someone is reachable to act on them | Version each playbook as a Shuffle workflow with a named owner; route high-severity alerts to on-call contacts through a notification app; test routing on a schedule and log the results |
| A.5.26 triage and enrichment | Respond to incidents in accordance with documented procedures, starting with classification and context gathering | Build triage workflows that call enrichment apps (threat intelligence, asset inventory, identity lookups) and write each result to the case record with a timestamp |
| A.5.26 escalation and containment | Escalate and contain incidents through defined steps, with authority levels that match the procedure | Place destructive actions such as account disablement or host isolation behind manual approval steps in the workflow; record the approver and decision in the case |
| Detection feed into response | Connect detection output to the response process so that alerts reach the documented triage path | Forward Wazuh alerts to a Shuffle webhook trigger; filter by rule group and severity in the workflow; map each rule group to the playbook named in the procedure |
| Logging of automated actions | Keep a reviewable record of what automation did, when, on what input, and who approved it | Enable workflow execution history in Shuffle; export run results to the case system; retain execution records for the period your procedure sets |
| Worker and credential handling | Protect connected-tool credentials and keep workflows running when one worker fails | Set a single SHUFFLE_ENCRYPTION_MODIFIER value under change control and back it up securely, since changing it breaks saved app authentications; run more than one Orborus node so workflows keep executing |
Which open-source platforms fit each part of the incident chain
An ISO 27001 incident process runs from detection through triage, response and record keeping, and each stage can rely on a different tool. The cards below separate the detection, automation, network, threat context, identity and case record layers so you can decide which ones your organization needs and which it already runs.
Shuffle for triage and response
Shuffle is the SOAR layer that runs enrichment, escalation and response playbooks and keeps a record of each execution. It is licensed under AGPL-3.0, and v2.3.0 was published on September 28, 2026. Deployment options include a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, and Kubernetes with Helm charts. Check the edition limits, since licensing differs between the open-source and paid editions, and confirm how your run volume maps to the license metric before you design playbooks that call many actions.
Wazuh for detection and alerting
Wazuh supplies the endpoint and log detection that starts most incident records, with agents on Linux, Windows and macOS, and a server that applies decoders and rules. It is distributed under GPL-2.0, and the current release line is 4.14. Confirm which rule sets map to the detection scenarios in your incident register, and check how the indexer stores alerts and how long you keep them, because auditors often sample alerts back to their original detection.
Security Onion, Suricata and Zeek for network signals
Network evidence is often what confirms scope in an incident. Suricata provides intrusion detection and prevention alerts under GPL-2.0, Zeek produces protocol logs under a BSD-style license, and Security Onion bundles both with the Elastic stack under the Elastic License 2.0. Decide whether you need the full Security Onion platform or only sensor components feeding your SIEM. Confirm sensor placement and retention, since packet and log data can carry personal data and may need its own handling rules.
MISP or OpenCTI for threat context
Threat intelligence helps you classify an incident and decide whether to share indicators with peers. MISP is licensed under AGPL-3.0, and OpenCTI ships a Community Edition under Apache-2.0 alongside a separate Enterprise Edition license. Choose MISP when your priority is exchanging indicators with sharing communities, and OpenCTI when you need relationship mapping and reporting. Confirm which sharing agreements your organization is bound by, and whether the sharing you plan to do is permitted under them.
DFIR-IRIS as a separate case tool
Case management is a separate decision from automation. Shuffle records what its playbooks did, but a dedicated case tool such as DFIR-IRIS can hold the analyst narrative, evidence, IOCs and timeline that the incident register needs. Decide early whether the case record lives in the case tool, in Shuffle, or in both, and map each field to the lessons-learned evidence you will show an auditor. Licensing differs by edition and by tool, so confirm the license for each component before you commit.
Keycloak, authentik or ZITADEL for identity inputs
Account-related incidents, such as credential misuse or unexpected privilege changes, need identity events as inputs. Keycloak is licensed under Apache-2.0, authentik under MIT with an enterprise directory under a separate license, and ZITADEL under AGPL-3.0. Confirm which of these emits the login, session and admin events your playbooks need, how they reach the SIEM, and whether disabling or resetting an account in response is covered by your approval steps.
How the incident register builds itself during automated response
The incident register does not build itself on its own. Automated response writes a detailed record of what Shuffle did, but an auditor sampling incidents under ISO/IEC 27001 Annex A control A.5.26 will expect a register that a named person reviewed, classified and closed. In a typical self-hosted design, a detection tool such as Wazuh raises an alert, which triggers a Shuffle workflow. Enrichment apps then add context from threat intelligence and asset data, a decision gate routes the case by severity, and a case or ticket is created. A human approval step sits in front of any destructive action, such as isolating a host or disabling an account, and the workflow waits for that approval before it proceeds. Your first decision is which steps are destructive and who holds the approver role for each of them.
Shuffle stores workflow execution history in its OpenSearch document database, so each run, its inputs, outputs and the actions it took can be retrieved later. That history is evidence of automated activity, not a substitute for the incident register. Record the case identifier in every workflow run, and define how the case moves through triage, containment, closure and lessons learned under the incident management process your organization documented for control A.5.24. Analysts should write the classification, the root cause and the lessons learned into the case themselves, and the register entry should link to the run history rather than copy it. Confirm with your certification body how it expects automated records and human records to be linked before you finalize the design.
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The configuration documentation warns that losing or changing this value breaks every saved app authentication, so the workflows that depend on those credentials would stop running. Treat this value as part of your evidence plan: record where it is held, who can read it, how it is backed up separately from the OpenSearch data, and how a rotation would be documented. Test a restore into a non-production environment so you know the credentials can be decrypted before an incident depends on them. Ask your implementation partner to show this procedure as a written runbook.
Evidence an auditor samples and which component produces it
This table compares each record an auditor is likely to sample for ISO 27001 controls A.5.24 and A.5.26 with the component that produces it and the gap to close before an assessment. Read it against your documented incident procedure, because auditors sample records and check that tooling output matches what the plan says.
| Evidence | Typical producer | Gap to close |
|---|---|---|
| Incident management policy and plan | Document owned by the CISO or security lead, approved by management | Plan must name Shuffle playbooks, case tool and escalation roles exactly as they operate |
| Playbook versions and change history | Shuffle workflow export held in version control | Confirm exports are tagged per release and that approvals for each change are recorded |
| Sampled incident records with timestamps | Case management tool with Shuffle execution history | Check that case timestamps and workflow run logs agree and that retention matches the plan |
| Wazuh alerts that triggered each case | Wazuh indexer and dashboard alert records linked to the case ID | Confirm the alert ID is stored on the case so an assessor can trace alert to outcome |
| Approval records for containment actions | Shuffle approval steps or the case tool workflow log | Gate destructive actions with named approvers and keep the decision next to the action record |
| Lessons-learned reviews and corrective actions | Case tool post-incident review fields and the issue tracker | Confirm each corrective action has an owner, due date and closure record tied to the incident |
| Management review inputs | Summary report generated from incident register and case data | Agree what metrics leadership reviews and confirm the report can be reproduced for an audit period |
What automation alone does not satisfy in ISO 27001
Annex A controls 5.24 and 5.26 are about people, procedures and decisions as much as tooling. A Shuffle playbook can move an alert through triage and record each step, but the policy, roles, severity judgments, reporting calls and improvement actions behind it have to be owned by the organization. The cards below cover what the workflow cannot decide for you.
Approved incident policy and roles
Control 5.24 expects incident management processes, roles and responsibilities to be defined, established and communicated. A playbook can route a case, but it cannot decide who owns a decision, who may approve containment and who speaks for the company. Confirm that the policy is approved by management, names an incident manager and deputy, and states who can authorize automated response actions. Check that the playbooks reference those roles rather than individual usernames, so staff changes do not break the record.
Responder training and exercises
Automation shortens the path from alert to action, but responders still need to know what the playbook will do on their behalf and where it stops. Run tabletop exercises that include a case where an automated action is wrong, such as a blocked host that serves business operations. Record attendance, scenarios and lessons from each exercise, because an auditor will look for evidence that people were prepared, not only that the platform was configured.
Severity and reporting decisions
Severity criteria and the decision to notify customers, regulators or authorities depend on business impact, contractual terms and legal advice. An enrichment step can supply indicators, but it cannot weigh them against those obligations. Document the severity matrix, name the person who classifies each incident, and define the approval gate before any external notice. Confirm with counsel which notification clocks apply to your sector and jurisdiction, since these vary by regulation.
Lessons learned and corrective actions
Control 5.26 expects incidents to be handled under documented procedures, and the improvement loop after an incident is where many programs fall short. The workflow can record the timeline, but a person has to assess root cause, decide on corrective actions and confirm they were completed. Keep the incident register linked to lessons-learned reviews and a corrective-action log with owners and closure dates. Ask the partner how that log is kept and reviewed.
Risk assessment of the SOAR platform
A SOAR platform holds API keys and service credentials for the tools it controls, and it can disable accounts or isolate hosts. That makes it a high-value target and part of your ISMS scope. Assess its risks, restrict administrator access, and protect the encryption secret that Shuffle uses for saved app credentials, since losing or changing it breaks those authentications. Confirm how workers, backend and OpenSearch are hardened and who approves changes to playbooks that take destructive actions.
Questions buyers ask before hiring help with ISO 27001 incident automation
What does automating ISO 27001 incident management cost, and what drives it?
The cost depends on the number of alert sources, playbooks, integrations, environments and approval paths in the written scope, and no single figure applies to every organization. Four components usually appear in a quote: your internal staff time, DeployOpen's fixed-scope fees for planning, building and documenting the playbooks, the infrastructure that runs Shuffle and its workers, and Shuffle licensing. Shuffle prices on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, so the volume of automated actions matters. Ask any partner to separate one-time build work from recurring items such as licensing, hosting, connector upkeep and retainer support.
How long does a scoped first phase of incident automation take?
The duration of a first phase comes from the written scope, not from a generic estimate. The scope should name the alert sources to connect, the first playbooks to build, the approval gates for destructive actions, and the environments where the work runs. Engagements are normally fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ask the partner to show which items are in phase one, which depend on your change windows and access approvals, and what evidence the phase delivers.
Can our security team run this ISO 27001 automation without a partner?
A team can do it alone if it already has working skills in Shuffle, the SIEM feeding it and the ticketing or case tools involved, and if it can test workflows before production. Many teams still ask a partner to review the playbooks, because a playbook that automates containment without approval can create a control gap. Check that your team can version workflows, store credentials safely, keep the encryption secret for saved app credentials safe, and document each playbook as a controlled procedure.
Will a certification body accept records produced by automated playbooks?
The certification body decides whether the records meet its sampling needs, because ISO does not certify organizations and accredited certification bodies perform the audit. Automated records are generally easier to defend when the playbook is documented, approved, version controlled and linked to a case with timestamps and actions taken. Confirm the expectations with your certification body before you design the evidence format. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications.
What does our organization need to provide for the engagement?
The work needs named owners on your side for incident management, the SIEM, identity, change approval and each connected tool. It also needs test accounts or API access with the least privilege required, network paths from the Shuffle environment to your tools, and scheduled change windows for production deployment. Without a named approver for destructive actions such as isolating a host or disabling an account, playbooks stall during an incident. Confirm these dependencies in the written scope before the first phase begins.
How does the move from ISO 27001:2013 to 2022 affect incident records?
The 2022 edition replaced the 2013 control A.16.1.5 with control A.5.26 on responding to incidents in line with documented procedures, and the incident planning control is now A.5.24. Under IAF MD 26:2023, certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025. If your records still follow the 2013 structure, map the playbook steps, approval points and lessons-learned fields to the 2022 controls and confirm the mapping with your certification body. The IAF transition rules are the place to check the dates that apply to your certificate.
Is ongoing support for the automation available after the first phase?
Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope build. A retainer is useful when playbooks must follow changes in connected tools, new Shuffle releases, updated detection content or changes to the incident procedure. Ask what the retainer covers, how changes are approved and tested, how backups of the Shuffle database and its encryption secret are handled, and how the partner records changes so the evidence trail stays complete.
What to confirm with your certification body and your own environment
Start by confirming the scope of your ISMS, because nothing else in the incident design holds until you know it. Decide in writing whether incident records from Shuffle, the alert sources feeding it and the case notes produced by playbooks fall inside the scope statement, and whether the systems hosting them are in the Annex A control set you have declared as applicable. Ask your certification body how it will sample incident evidence, and whether it expects the incident register to cover automated closures as well as analyst-handled cases. A mismatch here is far cheaper to fix on paper than after a surveillance audit has sampled your records.
Confirm the certification cycle and the audit schedule with the certification body rather than assuming a single assessment will carry you. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. Ask which audit falls in which year, which evidence the auditor will request ahead of each visit, and whether the body applies ISO/IEC 27006-1:2024 to your engagement. Accredited bodies were required to apply that standard to all clients by 31 March 2026, but you should still get the answer in writing, because it governs how the body audits ISMS scope and the information security controls around your tooling.
Confirm the retention period for incident records in your own policy, not in the tool defaults. Shuffle keeps workflow execution history and case data in its OpenSearch document store, and your retention rule has to match what the ISMS, your legal advisers and any sector regulator require. Also confirm that the SHUFFLE_ENCRYPTION_MODIFIER secret is backed up separately, since the Shuffle configuration docs warn that losing or changing it breaks all saved app authentications. Finally, check Shuffle's edition limits against your planned app-run volume with the vendor before go-live. The open-source edition includes all features, but since v2.1.1 the limits against the enterprise edition are actively enforced, and licensing is counted on app runs. Ask the vendor to confirm how your expected executions will be counted and what happens when a limit is reached during an incident.
How DeployOpen scopes, builds and supports ISO 27001 incident automation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ISO 27001 incident management, that means turning your incident process into Shuffle playbooks, case records and evidence that you can show to an internal audit or an accredited certification body.
How we scope
- Review your current incident management process, roles and escalation paths against Annex A controls 5.24 and 5.26
- Agree in writing which alert sources, playbooks and connected tools are in scope before work starts
- Define which automated actions run without approval and which destructive steps need a named human approver
How we build
- Deploy Shuffle in your own cloud accounts, data center or air-gapped network, using the architecture your scope requires
- Build and version playbooks for triage, enrichment and escalation, storing connector credentials in your chosen secrets store
- Test each workflow against sample alerts in a non-production environment before any playbook touches live systems
How we hand over
- Document each playbook, its trigger, decision logic, approval gates and the records it writes to the case system
- Provide the incident register template and lessons-learned evidence format, and confirm with you how auditors will sample them
- Train your incident responders and platform owners to run, change and review playbooks under your change control
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review playbooks when Annex A mappings, reporting rules or connected tools change, and log each change
- Coordinate with your independent auditor or certification body on evidence requests, since DeployOpen prepares evidence but does not issue audit reports
