What A.5.25 asks you to decide about every security event
A.5.25 requires your organization to assess information security events and decide whether each one is to be categorized as an information security incident. The control sits between detection and response: alerts, tickets and user reports are events, and it is the recorded decision that turns some of them into incidents that go to the response process under A.5.26. If your SOC or ticket queue produces events but nobody can show how they became incidents, or why they did not, you have a gap an auditor will find quickly. The control carries forward ISO/IEC 27001:2013 control A.16.1.4, so organizations that already had an assessment step under the older edition should check whether it still matches the 2022 wording and their current tooling.
Without a clear rule, events get handled inconsistently. One analyst closes a suspicious login as noise while another escalates the same pattern, and a real incident is either missed or buried in a backlog of low-priority tickets. The usual cause is not a lack of tools. It is the absence of two things: written triage criteria that say what makes an event an incident, and a record of each decision that shows who made it, on what basis and when. Start by defining a short set of categories, severity levels and escalation triggers, and confirm that the owner of the decision is named in your incident management procedure under A.5.24.
Test the control by sampling. Pick events from several months across each source, including closed ones, and check that each has a categorization, a priority, a decision and a reviewer. Confirm with your certification body or consultant which sample sizes and evidence formats they expect, since these depend on your scope and risk assessment. Your tooling can help here: an alert platform such as Wazuh or OpenSearch Security Analytics records findings with rule and severity, and a case manager such as DFIR-IRIS can hold the decision and its audit trail. Check each tool's exact export and logging options in its own documentation before you rely on them as evidence.
Which event sources and teams fall under the event assessment decision
A.5.25 applies to every reported or detected event that someone must judge, not only to alerts that reach the security team. The cards below cover the sources that feed that judgment, the teams who make it, and the scoping choices that decide how much work each source creates.
SIEM alerts and rule matches
Alerts from the SIEM are the highest-volume source and the first place assessment happens in practice. Each rule match should carry enough context (host, user, log type, rule and severity) for a triage analyst to decide whether it is a security event at all. Check which rules are enabled, who owns tuning them, and whether suppressed rules still leave a record that the suppression was a deliberate decision. Confirm that every alert has a recorded disposition, including false positives.
EDR detections on endpoints
Endpoint detection and response flags suspicious process, file and network behavior on laptops and servers. These detections often arrive with a host isolation or quarantine action already taken, so the assessment must confirm whether the automated action was correct and whether the event spread beyond one device. Assign endpoint triage to a named team and state who may release a quarantined host and on what evidence.
Cloud audit and control plane logs
Changes in cloud accounts, such as new access keys, policy edits, disabled logging or unusual regions, are events that rarely trip endpoint tools. Decide which cloud log sources are in scope for assessment, how they reach the team that triages them, and who can judge a change as authorized. Note that a change approved in a ticket still needs assessment if the approval does not match what happened.
User and staff reports
Phishing reports, lost devices, unexpected password prompts and misdirected data are reported by people, often in free text and sometimes late. The reporting route defined under A.6.8 feeds this source, but the assessment decision belongs to the security function. Check that the reporting mailbox or form is monitored, that reporters receive a response, and that reports that turn out to be benign still get a recorded decision.
Supplier and third-party notifications
A provider may notify you of its own breach, a vulnerability in a shared service or a change that affects your data. These notices arrive through contracts, status pages and email, and they are easy to miss. Name the owner for supplier notifications, define the contract clauses that trigger assessment, and decide whether a supplier notice counts as an event for your organization even when your systems show no sign of impact.
Triage roles and escalation owners
Triage is usually split between a first-line analyst who applies the criteria, a duty lead who confirms or escalates, and an incident manager who opens formal incident handling. The assessment record should show who made each decision and who had authority to overrule it. Confirm that these roles are named in the incident procedure, that coverage exists outside working hours, and that the duty lead can reach legal and privacy staff when personal data may be involved.
Scoping by rule or by alert
A key scoping choice is whether low-severity events are assessed one by one or handled as a class under a documented rule. Assessing each alert individually gives the strongest record but is rarely practical at volume. Assessing by rule is workable when the rule states the criteria, the conditions that break the rule, and a periodic sample check by a reviewer. Ask how many events fall into each path, who signs off the rules, and how the sampling is recorded.
How an assessor tests the event assessment decision
The assessor starts with the document that tells staff how to decide. They look for written criteria that separate an ordinary event from an incident, a categorization scheme, and a priority model that sets how fast each category must be handled. The assessor checks that the criteria are approved, dated, reviewed on a planned cycle, and linked to the organization's risk assessment and incident management process. They then ask whether the criteria are specific enough for an analyst on night shift to apply without guessing.
- Decision thresholds: Criteria name the conditions that turn an event into an incident, such as confirmed data exposure, loss of a critical service, or activity that breaches a defined rule.
- Categories and priorities: Each category has a priority and an owner, and the priority drives response timing.
- Approval and review: The document shows an approver, a version history and a review date tied to changes in threats or systems.
- Links to other controls: The criteria reference the incident process, reporting routes and the classes of asset in the inventory.
Before the audit, confirm that the criteria are findable by the people who triage, and that they match the scheme the security tool actually uses.
The assessor then samples real decisions, usually from a period the organization chooses and the assessor can extend. For each sampled event they trace the record from the original alert to the decision and any follow-on action. They check that the reasoning is written down, that the decision matches the criteria, and that the person who made it had the authority and skills to do so. Gaps in the record are a common source of findings, because an unrecorded decision cannot be shown to have been made at all.
- Complete trail: Each sampled event shows who assessed it, when, the category chosen, and the outcome, whether that was no incident, an incident, or a pending review.
- Consistent reasoning: Similar events receive similar decisions, and any departure from the criteria carries a written justification.
- Closed loops: Events judged to be incidents link to an incident record, and events closed as non-incidents show why nothing further was needed.
- Timeliness: Records show how long assessment took against the priority, and late decisions have an explanation.
Typical findings include decisions recorded only in chat messages, events closed with no reason, and sampled events that were never assessed at all. Ask for the sample population early so you can check it yourself.
The third test checks that the decision process is fed by detection and connected to incident handling. The assessor wants to see where events come from, how they reach the people who decide, and whether the flow between tooling and the incident process is controlled. They also look for evidence that the process works when detection changes, such as new log sources or new rules. Tools support this test, but the assessor is testing the process around them, not the product.
- Event sources: The assessor asks which logs, sensors and reports feed the decision point, and whether the list matches the systems in scope.
- Rule governance: Detection rules have owners, change records and tests, so the assessor can see why an event was raised.
- Routing to cases: Alerts move into case records with a clear hand-off to incident response, and the case keeps the original alert.
- Coverage gaps: The organization can explain which events it does not detect and how those gaps are accepted or treated.
For self-hosted stacks, a SIEM such as OpenSearch Security Analytics or Wazuh and a case tool such as DFIR-IRIS can each produce part of this trail. Confirm with the assessor which records they will accept as the primary evidence before you build the workflow around them.
Implementing event assessment step by step
This sequence turns A.5.25 from a policy statement into a working triage process, where every reported event gets a documented decision on whether it is an incident, who made that call, and why. Each step ends with an artifact an assessor can sample.
Define event categories and severity criteria
The information security lead, with the operations and incident response owners, writes the categories that events fall into (for example, malware, unauthorized access, data exposure, service disruption and suspicious activity) and the criteria that set severity for each. Criteria should reference business impact, affected data classification and the number of assets or customers involved. The step is done when a written category and severity table is approved by the owner of the ISMS and every triager can apply it to a sample event without asking for help.
Assign decision authority and response timeframes
Name the role that decides whether an event becomes an information security incident, plus a deputy, and state the escalation route for events that cannot be classified in time. Set response targets for each severity level and record them in the procedure. The organization sets these targets itself, so confirm the values with your own risk appetite and contractual notification duties rather than copying figures from another organization. The output is a signed decision matrix with named roles, backups and a rule for who may close an event as not an incident.
Configure detection rules and case records
Connect the log sources that matter (identity provider, endpoints, network devices, cloud audit trails and key applications) to a SIEM or detection platform such as OpenSearch Security Analytics or Wazuh, and enable the rules that map to your categories. Route alerts into a case management tool such as DFIR-IRIS so each triaged event opens a record with its source, timestamps and assigned triager. Test the chain with a known benign event (illustrative: a test login from an unusual location) to confirm the alert, the case and the notification all arrive. Done means the test event is traceable from raw log to case record.
Write the decision record template
Create one template that every triage decision uses, with fields for the event reference, category, severity, facts checked, the incident decision (yes or no), the decider, the date and time, the rationale and any linked incident or follow-up action. Keep the template short enough that triagers complete it during a shift, and require a reason whenever an event is closed as not an incident. Store the template in the case tool or document system under version control. The output is an approved template and an example completed record that auditors can read.
Train triagers on the criteria and template
Run a session for everyone who triages events, including on-call engineers and service desk staff who may see the first report. Walk through the category table, the severity criteria, the decision matrix and the template using worked examples, and include at least one event that looks harmless but meets the incident threshold. Record attendance and have each triager classify a short set of practice events against the agreed answers. The output is training records and practice results that show each triager can apply the criteria.
Run the event assessment sample review
Select a sample of recent events from the case tool, covering each category, each triager and both incident and non-incident decisions, then check each record against the criteria, the decision authority and the timeframes. The reviewer should be someone who did not make the decisions. Log each exception, correct the record or the criteria, and feed recurring gaps back into training or the category table. Done means the review report, the list of exceptions and their closure are filed, which is the evidence most assessors ask to see for this control.
Which evidence shows each event was assessed and decided
An auditor testing A.5.25 wants to see the rules used to judge events, the record of each judgment, and proof that the rules are applied consistently. The cards below cover the documents, system records and review evidence that connect a raw alert to a documented decision, and what to refresh between audits so the evidence stays current.
Triage criteria document
This is the written rulebook that tells analysts which events are information security incidents and which are routine. It should define the conditions that trigger escalation, such as confirmed unauthorized access, malware on a production host or data leaving the boundary, and name who may downgrade or close an event. Check that the version in force on the audit date is the one analysts actually used, and that its approval and review dates are recorded.
Categorization and priority scheme
Categories describe what kind of event occurred, such as phishing, malware, access abuse or service disruption, and priorities describe how fast it must be worked. Both should be defined in the same document as the triage criteria so that the same event receives the same labels from different analysts. An assessor will compare the scheme against a sample of closed events and look for labels that have no definition or priorities that contradict the stated impact.
Event-to-case records with rationale
For each event, the system should hold a record showing when it was received, which rule or source raised it, who assessed it, the category and priority assigned, and the written reason for the decision to treat it as an incident or dismiss it. Dismissals need the same rationale as escalations. Confirm that timestamps come from synchronized clocks and that edits to a record leave an audit trail, because an assessor will question any decision that cannot be reconstructed.
Escalation records
When an event is escalated, the record should show who was notified, through which channel, at what time, and what action was requested. Escalations to the incident response team, management, legal counsel or an external party such as a regulator or customer each need their own trail. Check that the escalation path in the record matches the incident management plan, since gaps between the plan and practice are a common finding.
Alert rule configuration
The detection rules that generate events are part of the evidence, because they decide what reaches an analyst at all. Keep the rule set under version control with change history, record who approved each rule change, and retain the configuration that was live during the audit period. An assessor may ask why a particular rule was disabled or tuned, so each change should carry a reason and a reference to the triage criteria it supports.
Periodic sample reviews
A periodic review takes a sample of closed events, both escalated and dismissed, and checks whether the criteria, categories and rationale were applied correctly. Record the sample method, the reviewer, the findings and the corrective actions, and keep the reviewer independent of the analysts who made the decisions. Reviews that run regularly between audits show the control operates continuously rather than only when an assessor is watching.
What meeting A.5.25 costs in money and effort
This table breaks down the cost components of running A.5.25 triage and decision-making, who gets paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to see where open-source tooling removes license spend and where effort remains, then take the rightmost column into a quote request. No figures are given because none were supplied for this control.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it, and what to request in a quote |
|---|---|---|---|
| Tooling and licenses | Software vendor or none if self-hosted | Recurring if commercial, none for open source | Self-hosted OpenSearch, Wazuh and DFIR-IRIS carry no license fee, but confirm each component's license terms. Ask for a line-item list of any commercial add-ons. |
| Infrastructure to host the stack | Cloud provider or data center team | Recurring | Log volume, retention period and number of monitored sources. Ask the partner to state assumed event volume and storage sizing. |
| Engineering time to configure detection | Implementation partner or internal platform team | One-time, with periodic tuning | Number of log sources, custom rules and Sigma rules to adapt. Ask for the hours per rule set and who writes the triage criteria. |
| Engineering time to configure cases and workflows | Implementation partner or internal team | One-time setup, then change requests | Number of alert sources feeding DFIR-IRIS and the categories needed. Ask what is delivered for case templates and the audit trail. |
| Analyst time for triage | Internal security operations staff or outsourced monitoring | Recurring | Alert volume, false-positive rate and hours for categorization and priority decisions. Ask how the provider measures triage workload. |
| Decision record upkeep | Internal compliance or security staff | Recurring | Number of events needing a documented incident decision and how often records are reviewed. Confirm who signs off each decision. |
| Detection tuning and rule review | Internal engineers or implementation partner | Recurring | Changes in environment, new log sources and noisy rules. Ask whether tuning is included in a retainer or billed separately. |
| External review of the process | Independent auditor or certification body | Recurring per audit cycle | Scope of the ISMS and sampling depth. Confirm the fee basis with the certification body before scheduling. |
| Auditor sampling and evidence requests | Internal staff preparing records for the auditor | Recurring per audit | How many events and decision records the auditor samples. Ask the partner to deliver a sample-ready export from DFIR-IRIS. |
| Support and upgrades | Implementation partner under a retainer or internal staff | Recurring | Version upgrades of the stack and vulnerability patching. Ask for the support scope and response expectations in writing. |
Who owns the triage decision and what partners can prepare
Your organization owns A.5.25. The people who decide whether an event is an incident must be named, trained and authorized to act, and the criteria they apply must be written by the organization and approved by management. No partner or tool can take that decision for you, because the assessor will ask who made each call and whether that person had the authority to make it.
- Triage criteria: Define what counts as an event, what counts as an incident, and the severity and impact levels that drive prioritization. Approve them and review them when systems or business services change.
- Decision authority: Name the on-call analysts who may close an event as benign and the role that must confirm an incident. Record who holds each authority and any backup.
- Categorization scheme: Agree the categories your teams use so that the same event type is labeled the same way across tickets, alerts and reports.
- Decision records: Keep a dated record for each event showing the facts reviewed, the category, the priority, the decision and the reviewer.
- Periodic review: Sample closed events and check that decisions followed the criteria, then act on any gaps.
Check that every triage decision in a sample traces back to an approved criterion and a named person with authority to decide.
An implementation partner prepares the systems, templates and evidence that let your team make and record triage decisions consistently. The partner works inside your environment and under your direction. It does not decide what counts as an incident in your organization, does not approve criteria on your behalf and does not sign off on your decisions.
- Tooling configuration: Set up detection and case tools, such as a SIEM, a rule engine and a case management platform, so that alerts reach the people who triage them. Document the configuration.
- Templates: Draft triage checklists, categorization tables, decision record forms and case fields for your team to review and adopt.
- Evidence samples: Build worked examples and sample records from your own tooling so you can show how a decision is captured end to end.
- Testing support: Help you confirm that alerts, cases and audit trails behave as documented before an assessment.
- Handover: Document how the tooling operates so your staff can run it without the partner.
Confirm in the written scope which templates and configurations the partner will deliver, and that every decision still belongs to your staff.
An independent auditor or certification body tests whether A.5.25 operates as described. It samples events, traces each decision back to the criteria and the record, and reports what it finds. Auditors are independent of both your organization and any implementation partner, so the partner cannot audit or certify its own work.
- Sampling: The auditor selects events from your records and checks whether each one was assessed and categorized as your procedure requires.
- Traceability: The auditor follows each sampled decision to the criteria, the authority of the decider and the evidence reviewed.
- Consistency: The auditor checks whether similar events received similar decisions over the audit period.
- Reporting: The auditor records any nonconformities and, where it applies, issues the report or certificate. DeployOpen does not issue audit reports, attestations or certifications.
- Independence line: An implementation partner that prepared your records may support the audit by answering questions about the tooling, but it must not make the auditor's findings or judgments.
Ask any auditor or certification body how it will test A.5.25 and what samples it expects to see before the audit date.
Where event assessment usually fails an audit
Assessment failures rarely come from a missing tool. They come from decisions that were made but not written down, criteria that exist only in someone's head, and events that never reached the incident process. Each card below names one gap an assessor tends to find under A.5.25 and the check that closes it.
No written triage criteria
Without documented criteria, an assessor cannot tell whether an event was judged fairly or by chance. A.5.25 expects the organization to decide whether an event is an incident, so the decision needs a stated basis: which signals matter, which asset classes are in scope, and what elevates an event. Check that a current triage standard exists, names its owner, and is available to every analyst on shift.
Decisions made in chat
When an analyst agrees in a chat thread that an event is benign, the decision exists but the record does not. Auditors sample events and ask for the reasoning behind each outcome, and a chat message rarely shows who decided, when, and on what evidence. Confirm that every assessment outcome is written into the case or ticket system, with a timestamp and the analyst's identity, before anyone acts on it.
Inconsistent severity across analysts
Two analysts looking at the same detection should reach the same severity, or the organization cannot show that its assessment is controlled. Drift often appears in alert priority fields that are set by habit rather than by a defined matrix of asset value and impact. Test this by giving several analysts the same sample events and comparing their categories. Where they differ, tighten the matrix and record the change.
Alerts closed without rationale
A closed alert with no reason is indistinguishable from an alert that was ignored. Assessors look for a short rationale on each closure, such as a known administrative task, a confirmed false positive with a tuning ticket, or an escalation. Make the closure reason a required field with a controlled list, and sample closed alerts regularly to confirm the reasons hold up.
No link to incident response
An assessment that ends without a handoff leaves confirmed incidents waiting in a queue. A.5.25 connects directly to A.5.24 planning and A.5.26 response, so every event categorized as an incident should open a case with a named owner and the response procedure attached. Check that the escalation path is defined in the procedure and that a test event proves it works end to end.
Detection rules without triage ownership
Detection content is often tuned by engineers while assessment belongs to a separate team, so no one owns the link between a rule and the decisions it produces. Rules that fire often without a documented outcome create noise that analysts learn to dismiss. Assign an owner for each detection source, review rule hit rates against assessment outcomes, and record every tuning change with the reason it was made.
Questions buyers ask about A.5.25 cost, effort and outsourcing
How much effort does A.5.25 take to run day to day?
Effort depends on alert volume, the number of log sources feeding your detection tools and how many people sit in the triage path. A.5.25 is not a one-time document: the organization must keep assessing events and recording decisions for as long as it operates. Start by counting how many alerts arrive in a typical week and how many of them need a human decision. That count, not the control itself, sets the workload. Ask any implementation partner to size the effort from that count and from the number of detection sources in scope, in writing, before work starts.
Can our security team implement A.5.25 without outside help?
Yes, many teams do. The control asks the organization to define triage criteria, categorize events, set priorities and keep a record of each decision. Those are internal responsibilities that cannot be handed to a vendor. Outside help is most useful for configuring detection and case tools, writing the triage procedure in a form an auditor can sample, and testing that alerts reach the people who must decide. Whether your own team has the time and skills is a judgment you should make against your current alert load.
What does the work need from our people?
It needs a named owner for the triage procedure, analysts who can apply the categorization criteria consistently, and a manager who reviews a sample of decisions. Analysts need time to work the queue and access to the logs behind each alert. Leadership must agree the priority levels and the threshold at which an event becomes an incident. Plan for these roles to be filled by people who already hold them, since the control depends on consistent judgment rather than new headcount alone.
How long does it take to have A.5.25 evidence ready?
Duration depends on how mature your detection and logging already are and how quickly you can agree the criteria. If alerts are already recorded in a case tool, the remaining work is mostly documentation and sampling. If triage happens in chat or email with no record, the gap is larger. Ask any partner to give a timeline tied to a written scope, and confirm which evidence the certification body will sample so you know when the records must exist. No fixed period applies to every organization.
Can an implementation partner make the incident decisions for us?
No. A partner can prepare the tooling, the criteria, the workflow and the evidence trail, but each categorization and incident decision must be made and owned by your organization. An auditor will expect to see your people making those calls and recording their reasoning. A partner can help you test the criteria against past events, which often shows where the rules are unclear, but the decisions remain yours.
How does A.5.25 differ from A.5.26?
A.5.25 covers deciding whether a reported or detected event is an information security incident, including how it is categorized and prioritized. A.5.26 covers responding to incidents once they are confirmed, such as containment, escalation, recovery and closure. In practice A.5.25 is the hinge: it routes events into the response process. Auditors often test them together by following a sample of alerts from detection through decision into response, so the records for each should link to each other.
What should we ask for in a quote for this work?
Ask for the written scope, the detection sources included, the number of alerts or events the design assumes, the tools to be configured, the documents to be produced, and the testing of triage and decision records. Ask which items are one-time and which recur, such as tuning rules or reviewing samples each year. Confirm what is excluded, including your own staff time and any independent audit fees, which an auditor or certification body charges separately.
How DeployOpen prepares event assessment for your audit
DeployOpen prepares the systems and evidence behind A.5.25 under a fixed scope. In practice that means planning, implementing and configuring self-hosted platforms in your own cloud accounts, data centers or air-gapped network, then drafting the triage criteria, categorization scheme and decision record template that your team will use. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask for the scope to name the detection sources in use, the platforms being deployed, the criteria templates to be produced and the audit support hours included, so that you can compare proposals on the same terms.
DeployOpen does not issue audit reports or certificates. Only an independent auditor or accredited certification body can test A.5.25 and conclude whether it is met. Your organization owns the decisions the control describes: which events are escalated, who classifies them, and whether a given event is an information security incident. Your own people must review the criteria, approve them and apply them to real events. Confirm before signing that the named accountable owner for event triage is inside your organization and that the decision records will be produced by your staff in daily operation, not reconstructed for the audit.
During the audit, DeployOpen can support your team by walking through how the configured platforms record each decision and by helping to retrieve the records an assessor samples. Ask whether the partner will attend walkthroughs, how it will handle evidence requests after the audit and whether ongoing support is a separate retainer. Retainers for upgrades and continuous testing are available, but they are priced separately from the initial fixed-scope work, so keep those items in separate lines of the quote.
