HRS-009 Security Event Reporting by Personnel
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.
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.
Framework Mappings (3)
| HRS-13 | Compliance User Responsibility | partial |
| 6.8 | Information security event reporting | full |
| AT-2 | Literacy Training and Awareness | partial |
Evidence (2)
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, unauthorized 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 — confirm via training records or onboarding documentation.
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 — confirm the channel was tested at least once in the last 12 months.
Questions (2)
Do all personnel have access to a clearly communicated, easy-to-use mechanism for reporting observed or suspected security events, and are they trained on when and how to use it?
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.