Root cause analysis explains why an incident happened or why its impact became worse. ISO 27001 control improvement turns that learning into a risk-based change that can be assigned, implemented, evidenced, and reviewed.
Short answer: connect the RCA finding to the affected risk, determine which control or control set needs attention, record the treatment decision, assign an improvement action, update related policies and evidence, and verify that the change operates in practice.
This is more disciplined than adding a generic action such as “improve security” or editing a policy and marking the finding closed.
Keep the ISO 27001 boundary clear
ISO/IEC 27001:2022 specifies requirements for an information security management system. It supports risk management and continual improvement, but a blog workflow cannot determine an organisation’s conformity or certification outcome.
An incident RCA can provide useful input to an ISMS. It does not automatically determine that a particular Annex A control applies, that a control failed, or that changing a document proves implementation.
Use the RCA as evidence for a structured decision:
- What risk or weakness did the incident expose?
- Which part of the control environment was relevant?
- Was the issue control design, scope, implementation, operation, monitoring, evidence, or response?
- What treatment is proportionate to the risk?
- What evidence will show the treatment is operating?
The ISO 27001 control applicability article explains why applicability decisions require context rather than automatic copying from a reference list.
Start with the RCA finding, not the control catalogue
An RCA finding should be specific enough to investigate.
Weak finding:
Access controls were not good enough.
Stronger finding:
A former contractor’s privileged access remained active for nine days because the offboarding request was not routed to the system owner and the quarterly review did not include the application.
The stronger finding identifies:
- The affected identity and system.
- The failure mode.
- The process gap.
- The review gap.
- A possible control scope issue.
Only then can the team examine which controls, procedures, owners, and evidence are relevant.
Map the finding to the control environment
Create a traceable chain:
| Layer | Question |
|---|---|
| Incident | What happened and what was the impact? |
| RCA | Why did it happen or become harder to contain? |
| Risk | What risk or weakness now needs treatment? |
| Control | Which safeguard or outcome addresses the risk? |
| Policy or procedure | What approved rule and operating process support it? |
| Owner | Who is accountable for operation and review? |
| Evidence | What record shows that the control operates? |
| Improvement | What must change and how will it be verified? |
The risk, controls, policies, and evidence workflow provides a broader traceability model.
Avoid mapping the incident to every related control. Select the controls that materially address the finding and explain the reasoning.
Decide what kind of improvement is needed
An RCA may lead to different improvement types.
Control design improvement
The existing control does not address the risk sufficiently. The organisation may need a stronger or more specific safeguard.
Implementation improvement
The control is appropriate, but it was not implemented for the affected system, user group, supplier, or process.
Operating improvement
The control exists and is in scope, but the recurring activity was missed, delayed, or performed inconsistently.
Evidence improvement
The control may operate, but the organisation cannot reliably demonstrate when, how, or by whom it operated.
Ownership or process improvement
The requirement is reasonable, but accountability, escalation, or handoffs are unclear.
These categories prevent a policy rewrite from being used as the default response to every incident.
Record the risk treatment decision
For each material finding, record:
- The risk statement and affected scope.
- The incident and RCA reference.
- The treatment decision.
- The selected control or controls.
- Any applicability or exclusion reasoning.
- The policy or procedure changes required.
- The owner, contributors, and approval authority.
- The expected evidence and verification method.
- Residual risk and the next review point.
If the organisation accepts the residual risk, record who accepted it and why. Do not disguise acceptance as an implemented control.
Update policy and evidence without overstating the result
Policy language should describe approved, intended behaviour accurately.
If MFA is planned but not yet enforced, the policy should not state that MFA is already required everywhere unless that is true and supportable. Record the gap and the implementation action separately.
After the change is implemented, evidence might include:
- Access review results.
- Configuration or enforcement records.
- Approved requests and removal tickets.
- Test results.
- Exception records.
- Monitoring or review reports.
- Updated procedures with an accountable owner.
The evidence should demonstrate operation over the relevant period, not only the existence of a new document.
Verify the improvement
Use a completion test that matches the RCA finding.
For the contractor-access example, verification could include:
- Confirming that the application is included in the access-review scope.
- Testing an offboarding request from submission to technical removal.
- Checking that the system owner receives and acknowledges the request.
- Sampling completed removals for timestamps and approval records.
- Reviewing whether overdue requests escalate.
- Reassessing the residual risk after the evidence is available.
The improvement is not complete merely because the ticket says “policy updated.”
Connect the work to Framework Pro carefully
Aneo Framework Pro can help teams turn business context and selected framework needs into tailored, editable policy drafts and supporting readiness documents. That can support the documentation part of an improvement programme.
The organisation still owns the risk decision, control implementation, evidence, approval, internal audit, and certification relationship. Framework Pro does not certify a business or prove that a control operates.
For the wider control and evidence relationship, see the security framework readiness hub.
Quick FAQ
Does every incident need to be mapped to an ISO 27001 Annex A control?
No. The relevant question is which risks and controls are in scope for the organisation’s ISMS and treatment decisions. Some incident findings may require process, ownership, supplier, or evidence changes instead.
Can an incident prove that a control is ineffective?
An incident alone does not prove that a control is ineffective. It can provide evidence that the control or its surrounding process needs investigation. The conclusion should distinguish design, implementation, operation, scope, and evidence.
Is updating the Statement of Applicability enough?
No. An applicability record is part of the management system. It does not replace implementation, operation, evidence, review, or corrective action.
What should happen if the organisation cannot fix the issue immediately?
Record the risk, interim safeguards, accountable owner, target date, dependencies, and residual risk. Do not represent planned work as completed implementation.