BrowseToolsGuidesComparePricingStacksPlaybooksBlogSearch
ComplianceReadiness checkISO 27001ISO 42001SOC 2PCI DSSPolicy templatesControl mapCompliance softwareFramework compare
A.5.25A.5 Organizational controls

Assessment and decision on information security events

A.5EVIDENCEA.6EVIDENCEA.7EVIDENCEA.8EVIDENCECONTROL MAPA.5.25 Evidence MapPOLICY / CONTROL / EVIDENCE / REVIEW

Purpose

Assess security events and decide whether each one should be classified as a security incident.

How to meet this control

In short: Assess security events and decide whether to classify them as incidents.

  1. Step 01Define triage criteria and a categorisation and prioritisation scheme that maps events to severity and priority
  2. Step 02Document the threshold at which a security event becomes a security incident
  3. Step 03Have the point of contact assess each event against the scheme and record the assessment
  4. Step 04Let the incident response coordinators make the final classification decision
  5. Step 05Use consistent criteria so similar events are categorised the same way over time

Tip: Define triage criteria so events are consistently categorised.

What ISO 27002 says to cover

Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.

  • ›Agree a scheme for categorising and prioritising incidents that defines consequences and priority
  • ›Include clear criteria for deciding when an event becomes an incident
  • ›Have the point of contact assess each event against the agreed scheme
  • ›Let the staff responsible for coordinating and responding to incidents make the final decision
  • ›Record the assessment and decision in detail for future reference and verification
  • ›Use consistent criteria so similar events are treated the same way

Audit evidence to keep

  • - Documented event triage and severity classification criteria
  • - Records of events assessed against the scheme with the decision made
  • - Evidence that classification decisions are made by the responsible coordinators
  • - Sample incident tickets showing consistent categorisation

Common mistakes

  • - Having an incident plan that staff cannot find
  • - Closing incidents without root cause or lessons learned
  • - Not preserving evidence before systems are changed

Owner, cadence, and proof

Assign one accountable owner for A.5.25. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.

Policy templates for this control

Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.

Incident response policyUse for ISO 27001 A.5.24 to A.5.28, SOC 2 incident response, PCI DSS 12.10, and security event handling.AI use and governance policyUse for ISO 42001, AI governance, employee AI use, data handling, human review, and AI supplier risk.Data breach response policyUse for ISO 27001 A.5.24 to A.5.28, SOC 2 incident handling, privacy notification, and PCI DSS requirement 12.10.Data retention and disposal policyUse for ISO 27001 A.5.33, A.5.34, A.8.10, SOC 2 Confidentiality and Privacy, and PCI DSS requirement 3.
Open the control-to-policy map
← A.5.24 Information security incident management planning and preparationA.5.26 Response to information security incidents →
Back to all organizational controls or see the requirements (clauses 4 to 10). To run this control with automation, read how AI manages controls.