Annex A 5.25 assessment and decision on information security events

An alert lands on Friday evening and nobody is sure whether it counts as an incident. Annex A 5.25 assessment and decision on information security events is the control that settles that question, and the one auditors test almost entirely by reading your log.

This guide sets out what ISO 27001 A.5.25 requires, how to score an event, who decides without a 24/7 security operations centre, what to record and what auditors sample. It is written for IT leads, security managers and compliance officers at 25–250-person firms heading into certification or surveillance.

What does ISO 27001 Annex A 5.25 require?

ISO 27001 Annex A 5.25 assessment and decision on information security events requires an agreed classification scheme, designated people who apply it, and a written record of every verdict. The control is the judgement step between detection and response: an event is observed, assessed, and either dismissed or declared an incident.

The control asks for three things, and an auditor will look for each one:

• An agreed scheme. Written criteria for what qualifies as an incident, and for how consequence and urgency set priority.
• Designated assessors. Named people with the competence to apply the criteria, rather than whoever happens to be on shift.
• A recorded verdict. Each call is written down with its reasoning, so it can be revisited and defended later.

An event is anything observed that could matter: an odd login, a flagged email, a system behaving unexpectedly. It becomes an incident only when assessment concludes that it harms, or credibly threatens, the confidentiality, integrity or availability of your information. The assessment step is the boundary, and A.5.25 is that step.

For a firm that already has an incident procedure under A.5.24, the extra work is small. The classification rules, worked examples and log fields are add-ons to that procedure, typically a day or two of effort rather than a separate build.

What goes wrong when security event triage fails?

Triage fails in two directions. Under-calling lets a real breach sit in a queue while the UK GDPR 72-hour notification clock, which starts at awareness, runs out. Over-calling labels everything P1, so teams burn out, mute alerts, and miss the genuine signal. Written criteria, a named decider and recorded rationale sit between the two.

The Information Commissioner's Office guidance on personal data breach reporting says certain personal data breaches must be reported within 72 hours of becoming aware of them, where feasible. A breach that idles in a queue for a week has used up the clock before anyone senior has heard the word incident. The regulator conversation then becomes about your process rather than the breach.

Over-calling costs differently. When every alert is a P1, the label stops meaning anything and the team stops sprinting. The real incident then gets the same tired shrug as the false alarms, which is how well-monitored firms still miss intrusions.

Triage also decides what your incident metrics mean. Management review and insurer questionnaires both consume incident counts, and those counts are only as honest as the classification behind them. For a firm of 25–250 people with no security operations team, the paper trail is the difference between a defensible middle and either failure.

How do you score a security event as an incident?

Score every event on two axes: impact, meaning which of confidentiality, integrity or availability is threatened and on which asset, and urgency, meaning how quickly the situation is getting worse. Combine them in a matrix that maps to P1–P4 tiers, each with a response-time expectation set under A.5.24.

The National Cyber Security Centre incident response guidance considers severity against availability, confidentiality and integrity, with attention to the scale of the problem and the type of system or data involved. Your matrix turns that into a repeatable calculation instead of a gut feel.

Build the scoring in four moves:

1. Grade impact. Define what low, medium and high mean for each of confidentiality, integrity and availability, and note which asset is affected.
2. Grade urgency. Define how you tell a contained event from one that is spreading, ongoing or about to reach client data.
3. Cross them in a matrix. Multiply or tabulate the two grades into P1–P4, with the response time for each tier written beside it.
4. Make asset criticality explicit. The same alert on a build server and on the client-data platform deserves different priorities, so the triage guide should say so rather than trusting everyone to remember.

Keep the matrix on one page inside the incident procedure, next to the worked examples that follow. A non-specialist deciding at speed should never have to open a policy document to find a threshold.

The pitfall that undoes a good matrix is keeping it in someone's head. The triage basis then shifts with whoever is on duty, and nothing written exists to argue against.

How does Annex A 5.25 assessment and decision on information security events work in practice?

A single failed login is an event; hundreds against one account within an hour is an incident. A reported phishing email is an event; a user entering credentials into it is an incident. A one-page set of worked examples lets a non-specialist make that call at speed, consistently.

Write the examples into the incident procedure, one short entry per family:

• Failed logins. The single failure needs a one-line log entry and nothing more. The burst against one account needs the account locked, the source reviewed and a tier read off the matrix.
• Phishing reports. The report prompts a check of who else received the email, and its removal. Credentials entered into it prompt a reset, a review of recent sign-ins and a higher tier if the account touches client data.
• System anomalies. Unusual outbound traffic from a build server and from the client-data platform trips the same alert. The example should state that the platform call jumps the queue, and why.

Each example carries a verdict, a tier and a first action, so the decider sees the pattern as well as the answer. Concrete cases beat abstract definitions when someone is deciding in the middle of other work.

Treat the page as living. When a category keeps being argued in the ticket thread, that argument is the signal to add another example, and the quarterly log review is the natural moment to collect them.

Who should make the triage call without a 24/7 SOC?

Name one accountable triage role (the IT lead, incident manager or fractional CISO) and a trained deputy. The 2022 wording of A.5.25 lets any competent designated person assess events, so a formal response team is unnecessary. What matters is that the call is never orphaned on a Friday evening.

The designation record should be short and easy to find. It shows:

• who holds the triage call, by name and role;
• who deputises, and how they are reached out of hours;
• the authority to declare an incident and page the response lead.

The usual trap is rota ambition. The flexibility in the 2022 wording is there to be used, so use it rather than inventing a schedule you cannot staff. Where nobody in-house has the judgement yet, a fractional CISO can hold the role or coach the person who will.

Train the deputy exactly as you train the primary: the criteria, the matrix, the asset register and a few worked calls. Equal competence is what makes the cover real rather than nominal.

A related temptation is importing a 24/7 SOC severity framework with six tiers, each carrying an SLA clock. Four tiers with response times your team has actually met are worth more, and each missed clock becomes an audit finding of its own.

A severity framework a 40-person firm can't staff is a promise it will break in front of the auditor.

Why do you have to log events that turned out to be nothing?

Because the one-line record, 'assessed, not an incident, because…', is the evidence that triage actually runs. Auditors ask for dismissed events and false positives first; a log containing only confirmed incidents suggests triage happens off the record. Each entry needs a timestamp, observation, reasoning, verdict and first action.

Record the call in the place the event landed, whether that is the ticket or the channel thread. Add the assessor's name, so an auditor can see that the named decider or the deputy made the call.

A dismissal can be as short as “14:20. Endpoint alert on a finance laptop for a PowerShell script. Assessor: IT lead. Signed vendor backup job. Not an incident. Alert rule excluded for this signer.”

Two disciplined minutes per event turn a decision from a memory into a defensible record. It also keeps the 72-hour awareness clock honest, because a dismissed event revisited later shows exactly what you knew and when. Occasionally the dismissal turns out to be the early breadcrumb of something bigger.

How does A.5.25 fit with A.5.24, A.5.26, A.6.8 and A.8.16?

A.5.24 builds the scheme and names the deciders; A.6.8 (human reports) and A.8.16 (monitoring) feed events in; A.5.25 sorts them; a 'yes, incident' verdict triggers A.5.26 response. The verdict is the hinge, so escalation should fire automatically at classification, with no second decision about whether to escalate.

The lifecycle runs in four steps:

1. A.5.24 builds the scheme, the P1–P4 tiers and the named deciders.
2. A.6.8 carries staff reports in, and A.8.16 carries monitoring alerts in.
3. A.5.25 sorts each event and records the verdict.
4. A.5.26 starts the response once the verdict is incident.

The ISO/IEC 27035-1:2023 international standard on incident management describes the same arc as a structured process for preparing, detecting, reporting, assessing and responding. It is a useful reference when you document the flow end to end.

Staff reports and monitoring alerts should land in the same log. Two inputs feeding two logs is how a shadow pipeline forms. Where escalation needs a second decision, hours disappear between verdict and page, and nobody can say when the response clock began.

What do auditors ask about ISO 27001 A.5.25?

Auditors pull the event log and trace entries in both directions: a confirmed incident back through its assessment reasoning, and a dismissed event forward to check the rationale was recorded. Expect questions on who decides when the usual person is away, and how asset criticality changes a priority.

The questions to expect in the room:

• "Show me your event log for the last year. Now pick something you decided wasn't an incident and defend the call."
• "What are your criteria for escalating an event, and who may decide when the usual person is away?"
• "This entry was rated high priority. Did the response meet the timeframe your own matrix promises?"
• "How does the asset register's view of what is critical change a triage decision? Show me an example."
• "How do you know your alerting isn't crying wolf, and when did you last tune it?"

Two checks sit behind those questions. The first hunts the shadow pipeline: incidents mentioned in interviews or the ticket system that never touched the log. The second is quantitative and easy, comparing response time against the matrix. The best exhibit for the fourth question is a traceable line from the asset register to a priority, with the client-data platform visibly jumping the queue.

Certification bodies typically grade by absence or breakdown. No classification criteria at all, or clear evidence that real events bypass assessment, grades major. An undocumented rationale on a sampled call, an inconsistently applied matrix or missed tuning grades minor. Minor findings aggregate to major as a pattern, and unrecorded 'no' decisions are the pattern that aggregates here.

How can GRC engineering automate A.5.25 triage?

Make the workflow enforce the discipline: the ticket requires impact, urgency and rationale before it can be classified, asset criticality suggests the impact score, an incident verdict pages the response lead, and false-positive rates feed a quarterly tuning dashboard. A human still owns the incident or not-incident verdict.

Forced fields are the foundation. The record exists because the workflow will not proceed without it, not because someone remembered. When an alert references a tagged system, the register's criticality pre-fills the impact score, and the human confirms or overrides it. An override is itself a recorded judgement, and the incident verdict stamps the response-clock start in the same step.

Automate the plumbing: alert enrichment, suggested severity and escalation on classification. Keep a human owning the verdict at this scale. What matters at audit is that the decision and its reasoning are recorded, whoever or whatever drafted them.

Per-source false-positive rates give the quarterly review numbers to work from, so noisy rules are demoted on evidence rather than irritation. That dashboard is the guard against set-and-forget thresholds.

An alert dismissed two hundred times without tuning is a decision nobody is making.

At 25–250 people, the result is a triage process a rota of two can run, producing the full population of evidence an auditor samples as a by-product.

Frequently asked questions