Security Event Reporting Procedure Template (ISO/IEC 27001 A.6.8)

Security Event Reporting Procedure: [Organization name]

Procedure that tells everyone working for [Organization name] what to report, how, when and what happens next. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.6.8 (reporting security events) and feeds A.5.25 (assessing security events) and the incident response plan (A.5.24 to A.5.28). Control guidance is in ISO/IEC 27002:2022 and incident management guidance in ISO/IEC 27035-1:2023 and 27035-2:2023. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Terms used in this procedure
3. Reporting culture and no-blame rule
4. Reporting channels
5. When to report
6. What to report
7. Receiving, triage and hand-off
8. Feedback to reporters
9. Special cases
10. Size tiers
11. One-page summary for staff
12. Metrics
13. Records and evidence
14. Review and testing
15. References

1. Purpose and scope

This procedure makes sure that anyone who notices something that may affect the security of [Organization name] information reports it quickly, through a known channel, and that the report reaches the people who can assess it. Early reports limit damage, start legal clocks at the right time and give the organization the information it needs to learn.

The procedure covers events affecting:

• information in any form (electronic, paper, spoken);
• systems, devices, cloud services and networks used by the organization, including those run by suppliers;
• personal data processed by the organization as controller or processor;
• physical security where it affects information (lost badges, tailgating, unlocked server rooms).

It applies to all employees, contractors and temporary staff. Suppliers report through the route agreed in their contract (isms/supplier-security-agreement-27036). Customers, researchers and members of the public report through the external route in section 9.4.

The procedure ends when the event is handed to the security operations team and the reporter has received feedback. Assessment, classification and response follow compliance/incident-response-plan (DOC-ISMS-020).

2. Terms used in this procedure

These are working terms written for this template. Read ISO/IEC 27000:2026 and ISO/IEC 27035-1:2023 for the official vocabulary.

3. Reporting culture and no-blame rule

[Organization name] wants to hear about every possible security event, including mistakes people make themselves. The following commitments apply:

1. Reporting is always right. No one is criticised for a report that turns out to be harmless. "When in doubt, report" is the rule.
2. No blame for honest mistakes. A person who reports their own error promptly (for example a click on a phishing link or an email sent to the wrong recipient) is not disciplined for that error. Disciplinary action is considered only for deliberate, malicious or repeated reckless conduct, under isms/security-disciplinary-process (DOC-ISMS-052), and never for the act of reporting.
3. Delay is the real risk. Hiding or delaying a report makes harm worse and can breach legal deadlines. Deliberate concealment is a policy breach.
4. Confidentiality. Reports are shared only with those who need them to respond. Reporters may ask that their name is not passed to their manager.
5. Protection. No retaliation against reporters. Concerns about retaliation, or about misconduct by managers, may go through the [whistleblowing channel] instead.
6. Thanks. Good reports are recognised in [team meetings, newsletters], with the reporter's permission.

4. Reporting channels

Rules for channels:

1. All channels end in the same security queue with one ticket per event, so nothing is lost between teams.
2. If a channel is unavailable, use the next one. If you think your own device or account is compromised, phone CH-03 from another phone.
3. Do not report through public social media or to personal email of security staff.
4. Managers who receive a report (CH-06) pass it on without first investigating it themselves.

5. When to report

Report immediately, and in any case within the times below.

Legal deadlines can start from the moment the organization becomes aware of a personal data breach or a significant incident. A report made late by an individual can make the organization miss a deadline, for example the 72-hour notification to a supervisory authority under GDPR Article 33, or the early warning under NIS2 Article 23 for entities in its scope.

6. What to report

6.1 Examples of events to report

6.2 Facts to include

• what you saw or did, in your own words;
• when it happened and when you noticed;
• which device, account, system or document is involved;
• whether personal data or customer information may be affected;
• anything you already did (for example "I closed the page", "I changed my password");
• how to contact you in the next hours.

6.3 What not to do

1. Do not try to investigate or "test" the problem yourself.
2. Do not delete the suspicious email, files or messages: report them first, then follow the analyst's instructions.
3. Do not forward suspicious emails to colleagues to warn them; the security team does this.
4. Do not switch off a device that shows a ransom note unless the analyst tells you to; disconnect it from the network (Wi-Fi off, cable out) and phone CH-03.
5. Do not contact the attacker, the press or customers.

7. Receiving, triage and hand-off

7.1 Flow

Every report follows the same path from the channel to closure. The diagram shows the decisions the receiver and the analyst take; steps 7.2 and 7.3 describe them.

7.2 Receiver steps

1. Acknowledge the report to the reporter within [15 minutes] for CH-03 and [1 working hour] for other channels.
2. Record the facts from section 6.2, the channel, the time of the report and the time the reporter noticed the event.
3. Check for urgent indicators: active compromise, ransomware, lost unencrypted device, personal data exposed, executive or privileged account involved. If present, page the on-call analyst at once.
4. Give the reporter immediate safety instructions where needed (for example, "disconnect from Wi-Fi", "do not delete the email").
5. Do not close a report without a recorded reason.

7.3 Analyst triage and hand-off

The security analyst assesses the event against the incident criteria in compliance/incident-response-plan (section on triage and declaration) and the levels in ops/incident-severity-matrix.

7.4 Example log (Example rows)

8. Feedback to reporters

1. Every reporter receives an acknowledgement (section 7.2) and a closing message within [5 working days] or at closure, whichever is sooner.
2. The closing message says, at a level the reporter can understand, what the report was ("a real phishing attempt, blocked for all staff", "harmless, thank you") and what, if anything, the reporter should do.
3. For incidents still open, the reporter gets a short status update and is told the team may contact them again.
4. Reporters of simulated phishing receive automatic positive feedback (see isms/phishing-simulation-plan).
5. Each quarter, the security team shares anonymised examples of good reports and what they prevented, in [newsletter, all-hands].

9. Special cases

9.1 Reporting about privileged staff or management

If the event involves the security team, IT administrators or senior management, report directly to [@ciso] or, if the CISO is involved, to [@ceo / audit committee chair / whistleblowing channel].

9.2 Suppliers and partners

Suppliers report events affecting [Organization name] information through CH-05 and the contact named in the contract, within the time agreed there. Staff who learn of a supplier incident through other means report it on CH-02.

9.3 Physical and office events

Facilities or reception staff record physical events (lost badges, tailgating, forced doors) in the security queue as well as in the facilities log, so that patterns across sites are visible (isms/physical-security-policy).

9.4 External reports

Customers, security researchers and the public report through [security contact page, security.txt, security@ address]. The security team acknowledges external reports within [3 working days] and handles reports of product vulnerabilities under security/vulnerability-management-policy.

9.5 Anonymous reports

Anonymous reports are accepted through [anonymous form or whistleblowing channel]. The team acts on them, knowing it may not be able to ask follow-up questions or give feedback.

10. Size tiers

11. One-page summary for staff

See something? Report it. You will never be blamed for reporting.

1. Suspicious email? Press [Report phishing]. Do not forward it.
2. Something happening now, lost device, or you clicked? Call [+00 000 000 000], any time.
3. Anything else? Service desk portal, category "Security event".
4. Say: what you saw, when, which device or account, what you did.
5. Do not: investigate, delete evidence, or warn others yourself.
6. You will hear back within [5 working days].

12. Metrics

Worked example (Example): Quillmere Health Systems received 104 reports in Q1 2027 with 320 staff, which is 32.5 reports per 100 staff (104 / 320 x 100). Of the 104, 101 were acknowledged within target, which is 97.1 %.

13. Records and evidence

Reports can contain personal data of reporters and others. Access is limited to the security team, and retention follows data/data-retention-deletion-standard.

14. Review and testing

The procedure is reviewed at least annually, after any incident where reporting was late or failed, and when channels or tools change.

15. References

• ISO/IEC 27001:2022, https://www.iso.org/standard/82875.html, with Amendment 1:2024, https://www.iso.org/standard/88435.html (Annex A A.6.8 and A.5.24 to A.5.28 cited by number only)
• ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html
• ISO/IEC 27035-1:2023 and ISO/IEC 27035-2:2023, incident management principles and planning (cited only)
• ISO/IEC 27000:2026, https://www.iso.org/standard/84257.html (vocabulary)
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, April 2025, https://csrc.nist.gov/pubs/sp/800/61/r3/final
• Regulation (EU) 2016/679 (GDPR), Article 33, and Directive (EU) 2022/2555 (NIS2), Article 23, as examples of deadlines that start from awareness
• Related templates: compliance/incident-response-plan, isms/incident-register, isms/post-incident-review, ops/incident-severity-matrix, security/security-incident-report, compliance/personal-data-breach-assessment, isms/security-disciplinary-process, isms/control-evidence-matrix

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.6.8 and the incident management controls A.5.24 to A.5.28, with practical content informed by NIST SP 800-61 Rev. 3 (a US Government work in the public domain) and the public texts of the GDPR and NIS2. The text of this template is original. No ISO/IEC text is reproduced; control numbers and short descriptive labels only are used, and you need the official standards to read the requirements and guidance. Check the current editions before use. Template licence: MIT.