A.6.8 Information security event reporting: audit evidence

What A.6.8 asks for and why auditors test it

A.6.8 Information security event reporting asks the organization to give personnel a working channel for reporting observed or suspected information security events, and to make sure those reports travel through appropriate routes in a timely manner. If you are a compliance lead or engineer preparing for an assessment, the question an auditor will ask is simple: can a staff member who notices something odd report it, and does the report reach someone who acts on it? The control merges two controls from the 2013 edition, A.16.1.2 on reporting information security events and A.16.1.3 on reporting information security weaknesses, so it covers both the event itself and the weakness that made it possible. The risk it addresses is delay. Events that go unreported for hours or days leave attackers time to move, data time to leave, and logs time to roll over.

The control is harder to meet than it reads. Many organizations have a reporting address, a form on the intranet or a line in the security policy, yet cannot show a single report that was received, classified and closed. The channel exists on paper, but reports land in a shared mailbox, a chat thread or a manager's inbox, and nobody can say who saw them or what happened next. Before you write anything, confirm which channels staff are actually told to use, who owns the intake, and whether a report creates a record with a timestamp, a reporter reference and a status. Those records are what an auditor samples when testing whether the control works, and they are often the first thing missing.

Plan for the trail, not only the channel. Decide how a report moves from intake into your incident management process, where the triage decision is recorded, and how a report that turns out to be a false alarm is still kept as evidence. Ask your certification body or auditor early which reports they expect to see and over what period. Your evidence should show intake, triage and closure for real reports, including reports about weaknesses that were not events. A channel with a clear owner and a complete record will usually satisfy the auditor more readily than a larger channel with gaps in its history.

Which people, systems and third parties fall inside A.6.8 scope

A.6.8 is only as strong as the population it reaches. Each scoping decision below changes which reports exist, which channels must be tested and which records an auditor will ask to see. The organization keeps the reporting obligation even when a provider performs the monitoring or takes the calls.

All personnel and contractors

Scope the reporting channel to everyone who can observe an event: employees, contractors, temporary staff and anyone with system access. Staff who only see a phone screen or a shared mailbox still notice suspicious emails and lost devices. Confirm that each group knows the channel exists and can reach it outside working hours, because an auditor will sample people from these groups, not only from the security team.

Each reporting channel in use

List every route a report can take: email, chat, telephone, web forms, and tickets raised by the service desk. Each channel creates its own evidence trail and its own failure modes, such as a mailbox nobody monitors or a chat message that never becomes a ticket. Test each channel end to end and keep the test records, since an auditor will expect proof that a report sent through any listed channel reached incident management.

Systems that generate events

Decide which systems feed events into reporting, including endpoint protection, email security, identity platforms, cloud consoles and SIEM alerts. Automated detections are not personnel reports, but they show observed events that must be triaged and recorded. Document which systems are in scope and where their alerts are routed, so the audit trail can show how each event moved from detection to a recorded decision.

Third parties that detect or report

Managed service providers, hosting companies and outsourced help desks may detect events or receive reports on your behalf. Define in the contract how they forward events, within what window and to which queue. The organization still owns the reporting obligation, so keep records of each forwarded event and of the provider's acknowledgement. Confirm these terms with the provider and your contract owner before relying on them.

Weaknesses as well as events

Decide whether personnel may report weaknesses, such as an unpatched kiosk or a misconfigured shared folder, as well as observed or suspected events. The 2013 edition handled these in two separate controls, and A.6.8 combines them in one. Including weaknesses widens the report volume, so set triage rules that separate them from incidents and keep both kinds traceable in the records.

How an assessor tests the reporting channel

This table lists the steps an independent auditor typically takes to test A.6.8, the evidence each step draws on, and the findings that come up most often. Read it as a checklist of what your records must prove, since the auditor, not the implementer, draws the conclusions.

Test step	Evidence requested	Common finding
Read the reporting procedure	Documented procedure for reporting events and weaknesses, with owner, approval date and version history	Procedure exists but does not say how staff report outside working hours or who receives the report
Walk a reporting path end to end	Live demonstration from a staff member's account through the channel to the case queue, with timestamps	Channel works for the security team but a staff member cannot find the form or address
Ask staff how they would report	Interview notes from a sample of personnel across roles, including remote and contract staff	Staff name the wrong mailbox or say they would tell their manager instead
Sample reports and trace each to a triage decision	Report log, ticket or case IDs, triage notes and the link to a decision on whether the event becomes an incident	Reports logged with no recorded outcome or closure reason
Check that weakness reports reach security	Records of reports on weaknesses, such as a suspicious control or misconfiguration, routed to the security team	Weakness reports stay inside a help desk queue and never reach the security team
Confirm feedback and closure	Acknowledgment messages, closure notes and any communication back to the reporter	Reporters receive no acknowledgment, so they stop reporting
Check links to incident management	Records showing escalation into the incident process defined under A.5.24 to A.5.26	Escalation depends on one person's judgment with no written criteria
Review reporting channel availability and awareness	Awareness material and training completion records that reference the channel	Channel is described in onboarding material that was last updated before a system change

How reports reach incident management and what the mapping data says

A.6.8 is the reporting channel, and it is deliberately separate from the decision about what a report means. A staff member who notices a suspicious login, a misdirected file or a broken access check should be able to report it quickly through a route that does not depend on first deciding whether it is an incident. Once a report arrives, the organization applies its assessment and decision process under A.5.25 to determine whether the event is an information security incident. If it is, the response follows A.5.26 under the incident management planning set up for A.5.24. Keep these handoffs distinct in your design: the reporting route, the triage queue, the decision record and the response record. An auditor will ask how a report moves from the person who saw it to a documented decision, so confirm that each step leaves a timestamped record.

A.6.8 covers weaknesses as well as events. A report that a control is not working, such as a backup job that silently fails, a shared mailbox with no access review or a guard that no longer checks badges, counts under this control even when nothing malicious has happened. Many organizations route only suspected attacks into their incident tool and lose these weakness reports, so check that your reporting form, helpdesk categories or case types accept both. In practice, that means testing the channel with a weakness report as well as an event report and confirming that the record shows where it went.

Mapping data helps with planning but does not replace the standard. NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022, posted to the OLIR catalog in November 2023, relates A.6.8 to AU-6 (Audit Record Review, Analysis, and Reporting), IR-6 (Incident Reporting) and SI-2 (Flaw Remediation). NIST itself cautions that mapped controls are not always equivalent, so treat these links as starting points for finding evidence you may already hold. ENISA's mapping table for its NIS2 technical implementation guidance (version 1.2, August 2025) links A.6.8 to point 3.3 (event reporting) of the Annex to Commission Implementing Regulation (EU) 2024/2690. That link is useful if you are also scoped under NIS2, but it is ENISA's mapping, not a finding that the two requirements are the same. Ask your auditor how they will treat each mapping before you build evidence around it.

How to build a reporting channel an auditor can test

This sequence turns A.6.8 from a policy sentence into a working channel with published rules, traceable tickets and records that show reports were triaged, decided and closed. Each step names the artifact an assessor will ask to see.

Define reportable events and weaknesses
The information security owner writes a short definition of what personnel should report, covering observed or suspected events such as lost devices, phishing messages, unexpected access, and weaknesses such as a misconfigured shared folder or a process that does not work as written. The definition should be distinct enough that staff can tell an event from a weakness. The output is a published reporting procedure with examples drawn from your environment. You know it is done when a sample of staff can describe, unprompted, what they should report.
Choose and publish reporting channels
Select at least one channel that works when the usual route is unavailable, such as an email alias monitored by more than one person, a web form, a phone line or a chat channel. Document who monitors each channel and what hours it covers. The output is a channel list included in the procedure and in onboarding material, with the same channels referenced in the awareness program. Confirm that each channel is reachable from company laptops, mobile devices and remote work setups, since the channel must be usable by personnel who are not at the office.
Assign triage ownership and response expectations
Name the role that triages every incoming report, usually the security operations or service desk lead, with a named backup. Write the expectations for first acknowledgment and escalation to incident management in the procedure, and state who can declare an incident. The output is a RACI or ownership table and a triage checklist. An assessor will test this by asking who was on duty for a sampled report, so the rota or on-call record should exist and match the table. Confirm the timing expectations with your own incident response plan, since they must be consistent with A.5.24 to A.5.26.
Route reports into a ticketing or case system
Configure the channel so every report creates a record in a ticketing or case system with a unique identifier, a timestamp, the reporter, the category and the source channel. Open-source options include GLPI, whose Assistance module tracks tickets, problems and changes following ITIL practices, and Zammad, a helpdesk that gathers email and other channels into one ticket system. For security-heavy triage, DFIR-IRIS keeps each case as a single record with tasks, evidence and an audit trail. The output is a routing rule and a sample ticket showing the identifier and the fields populated. Confirm that the tool's audit log cannot be edited silently by administrators.
Record the triage decision and closure
For each report, the triage owner records whether it is an event, a weakness, a false positive or an incident, the reasoning, the actions taken and the closure date and approver. Reports that become incidents are linked to the incident record so that A.5.25 and A.5.26 decisions can be traced back to the original report. The output is a set of closed sample records that show the full chain from report to decision to closure. Assessors commonly sample both reports that were escalated and reports that were closed without action, so both types should be complete.
Train staff on how to report
Include the reporting procedure, the channel list and worked examples in onboarding and in the recurring awareness program described under A.6.3. Test that staff know the channel by running periodic exercises, such as a simulated phishing report, and record the results. The output is training material, completion records and exercise results linked to named individuals. An assessor will check that the people sampled from the roster know how to report, so training records should be retrievable by person and date.
Review reporting records at management review
Include reporting volumes, categories, time to triage, open items and channel problems in the management review agenda. Record the decisions taken, such as changing a channel, clarifying the definition or retraining a team. The output is the management review minutes and the follow-up actions with owners. Ask your certification body or consultant which metrics they expect to see, since the choice of measures is yours to define, and keep the reviews consistent across cycles so that the trend itself is evidence the channel is maintained.

Which records pass an A.6.8 audit

An auditor testing A.6.8 looks for a working reporting path and proof that it was used, not a policy alone. The records below connect the channel to what happens after a report arrives, and each one is sampled differently, so no single record carries the audit on its own.

Reporting procedure and channel list

The written procedure names every channel personnel can use to report an observed or suspected event, such as a service desk queue, a security mailbox or a phone line, along with what counts as an event and how fast to report it. The auditor checks that the channels listed are the ones staff actually see and that the procedure matches the tooling in use. Review it at least yearly and whenever a channel changes, and record the approval date and owner.

Register of reports with timestamps

A single register lists every report with the date and time received, the channel used, and the reporter's role rather than personal details where policy allows. The auditor compares register entries against helpdesk or case system logs to confirm nothing is missing. Export a sample each month and confirm that each entry has a timestamp and an assigned owner.

Triage and closure records per report

Each report links to a triage decision that classifies it as an event, an incident or a false alarm, followed by the actions taken and the closure reason. The auditor picks several reports and follows each one from receipt to closure, checking that the decision was made promptly and documented. Keep these links intact in the ticket or case system so the trail does not depend on memory.

Weakness reports and follow-up

Reports of weaknesses, such as an unpatched system or a misconfigured form, are tracked separately from events and given a remediation owner and due date. The auditor checks that weakness reports from staff were acted on and not closed as routine tickets. Review open weakness items with the security lead each month so that repeated reports of one weakness trigger a fix rather than a new ticket.

Awareness materials and channel knowledge

Training content, posters, intranet pages and onboarding modules show staff how to report and where. The auditor asks a sample of personnel how they would report a suspected event and compares the answers with the channel list. Keep completion records by role and refresh the materials when the channel changes, so the evidence shows that people know the path.

Periodic review minutes

Minutes from a periodic review of reporting volumes, response times and channel problems show that management checks the process works. The auditor looks for decisions and actions that followed from the review, such as a new channel or a revised form. Hold the review on a fixed cadence, record attendees, and carry open actions into the next meeting.

What meeting A.6.8 costs in money and effort

This table breaks the cost of running A.6.8 reporting into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No supplied figures exist for price or hours, so use it to shape your quote request and to see where open-source tooling changes the split between license spend and effort.

Cost component	One-time or recurring, and who is paid	What drives it
Channel and intake tooling or licenses	Recurring if a commercial helpdesk is licensed per agent or seat; one-time for setup. Paid to a vendor, or absorbed if already licensed	Number of reporting channels (email, portal, phone, chat), number of agents, and whether a ticketing tool is already in place
Self-hosted open-source ticketing and case tools	No license fee; recurring hosting, patching and backup effort done in-house or by an implementation partner	Hosting platform, upgrade cadence, integration with email and identity, and staff skills to maintain the service
Engineering time to configure routing and intake forms	One-time build, plus small recurring changes. Paid to internal engineers or an implementation partner under a fixed-scope agreement	Number of routing rules, categories for event types, integrations with the SIEM or service desk, and approval steps
Policy and procedure writing	One-time drafting, with recurring annual review. Paid to internal staff, legal or a consultant	Number of sites and business units, whether the reporting procedure is separate from incident management, and translation needs
Staff training time on how and when to report	Recurring, usually folded into general awareness training. Paid as staff hours, not a vendor invoice	Headcount in scope, contractors and third parties who must report, and how often refresher content is delivered
Triage staffing for incoming reports	Recurring. Paid as salary or contractor time, often within the security operations or service desk budget	Report volume, expected response times, out-of-hours coverage, and how many reports turn into incidents under A.5.25
Evidence upkeep: register review and sampling	Recurring. Paid as staff time before each audit and during surveillance reviews	Length of the reporting register, number of channels to evidence, and the sample size the auditor selects
External review or testing	Periodic, paid to an assessor, penetration tester or implementation partner. Independent auditors issue findings, not partners	Scope of review, whether the reporting path is tested end to end, and whether the auditor requests a walkthrough

Self-hosted tools that produce A.6.8 records

A.6.8 is tested through records: who reported an event, when, how it was triaged and who acted on it. The three tools below each produce part of that trail, and they cover different points in the flow, from the service desk to the incident case. Confirm which of them fits your reporting channels before you choose one.

DFIR-IRIS case records

DFIR-IRIS keeps each security case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail of changes. It can triage alerts from SIEM, EDR and REST sources into cases and build a consolidated investigation timeline. Evidence files are logged with SHA-256 verification and chain of custody, and reports are generated from case data. Confirm that its audit trail retention and access controls meet your own record-keeping needs. The product is licensed under LGPL-3.0-or-later, so review the terms with your legal team before you modify or redistribute it.

GLPI assistance tickets

The GLPI Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices. Planning views, statistics, recurrent ticket tracking and a Kanban view help managers see how reports move through the queue. This produces the timestamped reporting record an auditor samples for A.6.8. Confirm that the ticket categories, escalation rules and closure fields match how your organization classifies events. Licensed under GPL-3.0-or-later, so check the obligations that apply if you extend or distribute it.

Zammad multichannel intake

Zammad brings messages from email, chat, telephone and social media into one ticket system. This matters for A.6.8 because staff may report suspicious events through whichever channel they use first, and each report should still reach incident management. Confirm which channels your staff actually use, how a report made by phone or chat becomes a ticket, and who monitors the shared mailboxes. Licensed under AGPL-3.0-only, which carries network-use obligations for modified versions, so confirm the implications with your legal team before you deploy it as a service.

Who owns the reporting channel, who can build it and who tests it

Your organization owns A.6.8 in full. Accountability for the reporting channel, the triage decisions that follow a report and the record of what happened cannot be handed to a contractor or a tool. Your security function sets the policy, decides which events count as reportable, approves who sees reports and maintains the register that auditors will sample. Staff only report what they have been told to report, so training is also your job.

Policy and scope: Define what counts as an observed or suspected event, who must report it, the expected timing and the channel to use, and approve the document yourself.
Triage decisions: Name the people who classify reports, decide whether an event becomes an incident under A.5.25 and A.5.26, and record that decision with a reason.
Staff training: Teach personnel how to recognize and report events, and keep completion records that show coverage.
Register ownership: Keep the log of reports, outcomes and follow-up actions, and review it on a schedule you can name.
Management review: Check trends in reports and close gaps in the channel, so the control is shown to operate and improve.

Check that each of these duties has a named owner who can explain it to an assessor without notes.

Questions buyers ask about A.6.8 cost, effort and outside help

How much effort does A.6.8 take for a small team?

For a small team, A.6.8 is mostly a process and record-keeping task rather than a large technical build, but the effort is real and easy to underestimate. The work covers defining what counts as an event worth reporting, publishing one or more reporting channels, writing triage rules that route reports to whoever handles incidents, and keeping a log that shows each report was received and acted on. The main drivers of effort are the number of staff and locations, how many systems produce events, whether reports arrive through several channels, and how much history an auditor will expect to sample. Ask any consultant or implementer for a written breakdown of tasks, the owner of each task, and which tasks recur after the first setup.

Is a staff chat or email channel enough for A.6.8?

A chat or email channel can satisfy A.6.8 if it is easy to use, monitored by people who know what to do with a report, and leaves a record that can be sampled. Problems arise when reports land in a personal inbox, a chat thread that is not archived, or a channel nobody checks outside office hours. A shared mailbox or chat channel usually works best when reports are converted into tickets in a system such as GLPI or Zammad, so each report has a timestamp, an owner and a status. Confirm with your own auditor which channel records they will accept as evidence, and confirm who covers the channel when the primary owner is absent.

How long does it take before the reporting register produces audit-ready samples?

Ask for a written schedule. The time needed depends on how many reporting channels exist, whether staff have already been told how to report, and whether the register is already captured in a ticketing or case system. An auditor typically samples records over the period they review, so the register needs to have been running long enough to show real entries, and that period is set by the certification body, not by the implementer. Any proposal should state the milestones, the date each channel goes live, the date staff are briefed, and the date the first records are reviewed internally before the auditor sees them.

Can the team do A.6.8 without outside help?

Yes, a team with an existing ticketing tool, an incident owner and a manager who can enforce the reporting rule can usually do A.6.8 internally. Outside help tends to add value in designing the triage logic, configuring open-source tools such as DFIR-IRIS for case records, and testing whether the register works under realistic conditions. The organization still owns the policy, the reporting duty and the sign-off. Before deciding, list the tasks, assign internal owners, and estimate the time each owner can realistically give over several months.

What does the work need from staff and management?

A.6.8 needs staff who know what to report, how to report it and that they will not be penalized for raising a genuine concern. It needs managers to reinforce that expectation, pass on reports promptly and take part in periodic reviews of the register. Management must approve the reporting procedure, allocate someone to triage reports, and make sure the incident response team can act on them. Staff time is usually small per person, but briefings, reminders and onboarding content add up across the workforce. Confirm in writing who in management signs off the procedure and who reviews the register.

Can our implementation partner also be the auditor for A.6.8?

No. An implementation partner prepares systems, procedures and evidence, while only an independent auditor or certification body can assess the organization and issue a certificate. Using the same firm to design the reporting process and to audit it would undermine independence, and accredited certification bodies will not accept that arrangement. Ask any partner to confirm in writing that it will not perform the certification audit, and choose the certification body separately, checking its accreditation through the IAF CertSearch database.

What should we confirm in writing before signing for A.6.8 work?

Ask for a fixed scope listing the channels, tools, systems and sites covered, the deliverables such as the procedure, triage rules and register template, the responsibilities split between your team and the partner, and the acceptance criteria. Also confirm which tasks recur after handover, such as periodic reviews and tool upgrades, and what support is included. Engagements of this kind are typically agreed on a fixed scope with written deliverables before work starts, and any quote should follow from that scope.

How DeployOpen scopes and prepares A.6.8 evidence

DeployOpen works on A.6.8 as an implementation partner: it prepares the reporting channel, its routing into incident management and the records an auditor samples, all inside the client's own infrastructure. The organization keeps ownership of the control, and only an independent auditor or certification body issues any report or certificate.

How we scope

Engagements are fixed-scope, with the reporting channels, systems and teams in scope agreed in writing before work starts.
The written scope names which event types staff must report and which ticketing or case tools will hold the records.
Scope also states who owns the reporting procedure, the awareness content and the sign-off on the evidence pack.

How we build

We deploy the chosen self-hosted reporting channel and configure intake so every submission creates a timestamped record.
We connect that intake to the incident management tool so reports route to a named triage queue with an owner.
We test the path end to end with sample reports, recording who received each one, when, and what action followed.

How we hand over

We document the reporting procedure, triage categories and escalation contacts in language staff and assessors can follow.
We deliver an evidence pack listing exported ticket histories, audit log settings and test records mapped to the A.6.8 requirement.
We walk the client's owners through the records so they can produce the same evidence during a surveillance or recertification audit.

How we support

Ongoing support, upgrades and continuous testing of the reporting path are available as a retainer after handover.
Retainers can cover periodic reviews of reporting volumes, closed-loop checks and updates when tools are upgraded.
Ask the team to confirm in writing which support tasks sit inside the retainer and which are billed separately.

A.6.8 Information security event reporting