HRS-009 Security Event Reporting Channel
Description
All personnel have access to a clearly communicated and easy-to-use mechanism for reporting observed or suspected security events. Reporting channels are documented, tested at defined intervals, and personnel are trained on when and how to use them. Reports are acknowledged and tracked. The same mechanism is reachable by suppliers and by customers, is communicated to them, and a report arriving through it is acknowledged and tracked on the terms the channel states. The same mechanism, or a separate published route, accepts a report from a person who believes on reasonable grounds that the organisation has broken the law or that a system it operates poses a substantiated risk to public safety, including a report the person takes to a competent authority. A published protection statement names the detrimental actions the organisation will not take against a person who makes such a report in good faith. A report of that kind is acknowledged and tracked in the same way as any other.
Rationale
Personnel are frequently the first to observe indicators of security incidents. Without a clear, trusted reporting channel, many incidents go unreported until they have escalated. Awareness that reporting is expected and safe is as important as the mechanism itself. An external reporter has no induction and no intranet, so the channel has to be published where a supplier or a customer will find it and it has to answer, or the second report never comes. APP-014 is the inbound route for a vulnerability in the product and is a narrower thing: the channel here takes a suspicious event, which is most of what an outsider actually notices. The confidential channel HRS-012 publishes takes a concern about a person; the route stated here takes a concern about the organisation itself, which is the whistleblower case; the protection statement is what makes the second such report come. A report of that kind is acknowledged and tracked but is not necessarily a security event, so the tracking may hand it to the function the report concerns. The GPAI Code of Practice names the same indicators for a model provider's risk culture (COP-S-8.3).
Applicability (9 profiles)
Annex points 3.3.1 and 3.3.2 are now stated: the mechanism is reachable by suppliers and customers as well as employees, is communicated to them, and an external report is acknowledged and tracked on the terms the channel states. The control is renamed Security Event Reporting Channel, because it is no longer a personnel-only route.
Framework Mappings (10)
| HRS-13 | Compliance User Responsibility | partial |
| HRS-13 | Compliance User Responsibility | partial |
| COP-S-8.3 | Promotion of a healthy risk culture | informative |
| HIPAA-164.308.a.5.ii.B | Protection from Malicious Software | informative |
| 6.8 | Information security event reporting | full |
| A.3.3 | Reporting of concerns | partial |
| NIS2-CIR-3.3 | Event Reporting | full |
| AT-2 | Literacy Training and Awareness | informative |
| GV-2.1-005 | AI Risk Roles and Responsibilities | GV-2.1-005 | full |
| CC2.2 | COSO Principle 14: Communicates Internally | partial |
Evidence (3)
Security event reporting procedure defining what to report, available reporting channels, and the obligation and protections for reporters.
Example: Security Incident Reporting Procedure (Confluence runbook), specifying: categories of events that must be reported (suspicious email, lost device, unauthorised access, data loss), reporting channels (e.g. security@company.com, Slack #security-alerts, anonymous hotline), timeline for reporting, and non-retaliation statement.
Test: Request the security event reporting procedure. Verify: (1) categories of reportable events are listed, (2) at least two reporting channels are defined, (3) a reporting timeline is specified, (4) a non-retaliation or safe-reporting statement is included, (5) the procedure was communicated to all staff, confirmed via training records or onboarding documentation. (6) the mechanism is reachable by a supplier and by a customer and is published where each would find it, (7) a supplier or customer report received in the period was acknowledged and tracked on the same terms as an employee report, or a test submission through the external route was.
Security event reports received via the reporting channel in the last 12 months, confirming the mechanism is being used and reports are acknowledged.
Example: Security incident or event ticket log (ServiceNow / Jira / email inbox export) showing: received reports from personnel, date received, date acknowledged, reporter role (not individual name), and disposition.
Test: Request a summary of security events reported by personnel in the last 12 months. Verify: (1) reports were received through the defined channels, (2) each report was acknowledged within the defined SLA, (3) reports are tracked to disposition (investigated/closed/escalated), (4) channel testing results exist, confirming the channel was tested at least once in the last 12 months.
The published protection statement for a person who reports in good faith that the organisation has broken the law or that a system it operates poses a substantiated risk to public safety, together with the published route such a report takes.
Example: Speak-up and protection statement version 2, published on the intranet and the trust page, 4 May 2026.
Test: Verify: (1) the statement is published where personnel, suppliers and customers can reach it without asking, (2) it names the detrimental actions the organisation will not take, at minimum dismissal, demotion, adverse evaluation, legal action and a hostile working environment, (3) it covers a report the person takes to a competent authority as well as one made internally, (4) it names the route such a report takes and who receives it, (5) reports received under it in the period were acknowledged and tracked to an outcome and none is recorded as followed by one of the actions the statement excludes.
Questions (3)
Do all personnel have access to a documented mechanism for reporting observed or suspected security events?
At least two reporting channels should be defined (e.g. email alias, Slack channel, ticketing form) and included in security awareness training. A non-retaliation statement should be present.
How frequently are the security event reporting channels tested to confirm they are operational?
Channel testing (e.g. a test submission verified to have been received and acknowledged) should produce a dated test record. Reports received via the channel should be acknowledged within a defined SLA.
Which of the following apply to your security event reporting channels?
Options run from the most commonly in place to the least. An unacknowledged report teaches the reporter not to send the next one, which is the failure mode the control exists to prevent. The external item asks about a suspicious event rather than a vulnerability report, which is a narrower channel held elsewhere. The last two items are the whistleblower case: a report about the organisation itself rather than about a security event, plus the protection that lets a person make it.