ISO/IEC 27001:2022 A.6.8 — Information security event reporting

What this control requires

The organization should provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

In plain English

The organization should provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. In practice, this means you can prove you policy information security-level controls on a defined cadence.

Why it matters

ISO 27001 certification depends on showing each Annex A control is either implemented or explicitly justified for exclusion in the Statement of Applicability (SoA). Certification bodies sample controls during surveillance audits, and a missing SoA entry — or implementation that doesn't match the SoA wording — is a finding.

This control is rated critical in the source catalogue. Treat gaps here as production incidents in the risk register, not housekeeping.

What an auditor looks for

An ISO 27001 lead auditor looks for: (1) an SoA entry covering the control with justification, (2) a documented procedure or policy implementing it, (3) records that prove the procedure runs (logs, tickets, training records) and (4) management-review evidence that effectiveness is monitored.

Within People controls, the assessor will trace your implementation back to the catalogue reference (Annex A A.6.8) and look for objective evidence on the latest two assessment cycles.

How to implement

Incident Response

Runbook. Maintain a runbook keyed by incident type with named roles (IC, comms, scribe), an out-of-band comms channel, and a 72-hour timeline for external notification.

Tabletop. Run a quarterly tabletop exercise (ransomware, insider, supply-chain) and feed gaps back into the runbook.

Policy Management

Docs. Keep each policy in version-controlled Markdown alongside the code that implements it; ship a signed PDF snapshot at each annual review and link the SHA into the SoA.

Operational checklist

• Policy. Document the trigger, the owner and the cadence.
• Information. Document the trigger, the owner and the cadence.
• Management. Document the trigger, the owner and the cadence.
• Response. Document the trigger, the owner and the cadence.
• Security. Document the trigger, the owner and the cadence.
• Scope: information security, management, people.

Evidence to collect

• Code Repo Scan. Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports.

Source control pipelines (GitHub, GitLab) enforce SDLC guardrails. Focus: Information security event reporting.

Common pitfalls

• Runbooks that name a role but no person, or list a paging channel that no longer exists.
• Policies that no engineer has read; the version in Confluence drifts from the version that's actually being enforced.

How it maps to other frameworks

Computed from shared tags, control component and key-operation subjects — handy when you are reconciling controls across an audit.

• NIST SP 800-53 Rev. 5 IR-2(3) — Breach
• HIPAA (45 CFR Part 164) 164.308(a)(5)(i) — Security Awareness and Training
• ISO/IEC 27701:2025 A.3.3 — Information security policies
• SOC 2 (2017 TSC) C1.2 — Confidential Information Disposal
• NIST SP 800-171 Rev. 3 3.3.5 — Audit Record Review, Analysis, and Reporting

Related controls in ISO/IEC 27001:2022

• Annex A A.6.2 — Terms and conditions of employment
• Annex A A.6.4 — Disciplinary process
• Annex A A.6.5 — Responsibilities after termination or change of employment
• Annex A A.6.7 — Remote working
• Annex A A.5.24 — Information security incident management planning and preparation
• Annex A A.6.6 — Confidentiality or non-disclosure agreements

References

• ISO/IEC JTC 1/SC 27 — ISO/IEC 27001:2022
• Catalogue identifier: Annex A A.6.8

Topics: application securityincident responsepolicy management