# 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*.

<!--
Guidance: How to use this template
- When to use: always. Every ISMS needs a simple, known way for people to
  report what they see. A.6.8 covers people reporting; detection by tools
  is covered by `isms/security-monitoring-procedure`.
- Fill first: section 4 (channels) and section 5 (timing). Test every
  channel yourself before publishing: send a report, call the number out
  of hours, check who receives it.
- Main pitfall: a procedure that stops at "report to IT". The value is in
  the hand-off (section 7), the feedback to the reporter (section 8) and
  the no-blame rule (section 3). Without them, reporting dries up.
- Related templates: `compliance/incident-response-plan` (DOC-ISMS-020),
  `isms/incident-register` (DOC-ISMS-021), `isms/post-incident-review`,
  `security/security-incident-report`, `ops/incident-severity-matrix`,
  `isms/employee-security-handbook`, `isms/phishing-simulation-plan`,
  `compliance/personal-data-breach-assessment`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Keep the procedure controlled, but keep a one-page summary (section 11) for posters and the intranet. Changes to channels must be published the same day. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-023 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-operations-lead] |
| Approvers/reviewers | [@ciso], [@isms-manager], [@privacy-lead], [@service-desk-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, Annex A A.6.8 (with A.5.24 to A.5.28); ISO/IEC 27002:2022; ISO/IEC 27035-1:2023, 27035-2:2023 |
| Parent documents | DOC-ISMS-001 Information security policy, DOC-ISMS-020 Incident response plan |
| Applies to | [All employees, contractors, temporary staff, and suppliers' staff with access to [Organization name] information or systems] |
| Reporting channels last tested | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Procedure owner | [@security-operations-lead] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Privacy lead | [@privacy-lead] | [Reviewed] | YYYY-MM-DD |
| CISO or top management | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@security-operations-lead] | First approved version |
| 1.1 *(Example)* | YYYY-MM-DD | [@security-operations-lead] | Added chat channel and supplier reporting route |

## Contents

<!-- Guidance: Sections 1 to 6 are what reporters need, sections 7 to 9 are what the receiving teams do, sections 10 to 14 keep the procedure working and auditable. -->

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

<!-- Guidance: Questions to answer: who must report, what is covered (information security only, or also privacy and physical security?), and where reporting ends and incident response begins. Pitfall: separate, unconnected routes for privacy, physical and IT events. -->

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

<!-- Guidance: Use plain words. Staff do not need to know whether something is an "event" or an "incident" before reporting; that is the receiver's job. -->

| Term | Meaning in this procedure |
|---|---|
| Security event | Anything observed that might indicate a breach of policy, a failure of a control or a threat to information. Most events turn out to be harmless |
| Security weakness | A gap that could be exploited but has not yet caused harm, such as a door that does not lock or a shared password |
| Security incident | One or more events that the security operations team has assessed as harming, or likely to harm, information or services |
| Reporter | The person who makes a report |
| Receiver | The service desk agent or security analyst who records and triages the report |
| Near miss | An event that could have caused harm but did not, for example a phishing email reported before anyone clicked |

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

<!-- Guidance: This is the most important section. State the rule clearly and make management sign it. Auditors increasingly ask staff whether they would report a mistake they made themselves. -->

[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

<!-- Guidance: Offer few channels, all ending in one queue. Give at least one channel that works when email or the laptop is compromised (phone). Test them every quarter (section 14). -->

| Channel ID | Channel | Use for | Availability | Ends in |
|---|---|---|---|---|
| CH-01 | [Report phishing] button in the email client | Suspicious emails, including simulations | 24/7 | Security mailbox queue, auto-ticket |
| CH-02 | Service desk portal, category "Security event" | Most other events and weaknesses | 24/7 submission, staffed [business hours] | Ticketing system, security queue |
| CH-03 | Security hotline [+00 000 000 000] | Urgent events: lost device, account takeover, ransomware note, anything happening now | 24/7, on-call analyst | On-call phone, ticket raised by analyst |
| CH-04 | Chat channel [#security-help] | Quick questions, "is this real?" | [Business hours] | Monitored by security operations; analyst raises ticket |
| CH-05 | Email [security@example.com] | Reports from suppliers, or when other channels are unavailable | 24/7 submission | Security mailbox queue |
| CH-06 | In person to the line manager or office security | People without a device, such as shift or plant staff | Working hours | Manager or security officer raises a ticket on CH-02 at once |

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

<!-- Guidance: Set a clear, short time. Explain why: legal deadlines (for example 72 hours under GDPR Article 33 for a controller's notification to the supervisory authority) start from awareness, and awareness can be the moment a staff member notices. -->

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

| Situation | Report within | Preferred channel |
|---|---|---|
| Something is happening now: ransom note, unusual pop-ups, files changing, account doing things you did not do | Immediately | CH-03 |
| Lost or stolen device, badge, token or work papers | 1 hour of noticing | CH-03 |
| You clicked a suspicious link, opened an attachment or entered your password on a suspicious page | Immediately | CH-03, then CH-01 for the email |
| Personal data sent to the wrong person or exposed | 1 hour of noticing | CH-02 or CH-03 |
| Suspicious email you did not act on | As soon as you see it | CH-01 |
| Security weakness (door, shared password, misconfigured sharing link) | Same working day | CH-02 |
| Policy breach observed (someone sharing passwords, tailgating) | Same working day | CH-02 or CH-06 |

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

<!-- Guidance: Give examples people recognise and a short list of facts to include. Tell them what NOT to do, because well-meant investigation destroys evidence. -->

### 6.1 Examples of events to report

| Category | Examples |
|---|---|
| Suspicious messages | Phishing emails, texts or chat messages; calls asking for passwords, codes or payments; urgent payment change requests |
| Account and access | MFA prompts you did not start; password reset emails you did not request; access to data you should not have |
| Devices | Lost or stolen devices; malware alerts; device behaving strangely; unknown USB device found |
| Data handling | Email or file sent to the wrong recipient; public sharing link on a Confidential file; papers left in a printer |
| Physical | Tailgating; unlocked secure rooms; lost badge; unknown visitor unescorted |
| Suppliers | A supplier tells you of a breach; a supplier asks for unusual access |
| Weaknesses | Shared accounts, outdated software, missing backups, controls that do not work |
| AI tools | Confidential information entered into an unapproved AI service; AI output that exposes other people's data |

### 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

<!-- Guidance: Describe what receivers do in the first minutes, and where reporting hands over to incident response. Keep severity levels in the severity matrix, not here. Auditors trace a sample of reports from ticket to closure. -->

### 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.

```mermaid
flowchart TD
  R["Reporter uses a channel"] --> T["Ticket in security queue"]
  T --> A["Receiver acknowledges to reporter"]
  A --> Q{"Urgent indicators?"}
  Q -- "Yes" --> O["Page on-call analyst"]
  Q -- "No" --> S["Analyst triages in working hours"]
  O --> S2["Analyst triages now"]
  S --> D{"Security incident?"}
  S2 --> D
  D -- "No" --> C["Close as event, weakness or near miss, record reason"]
  D -- "Yes" --> H["Hand off to incident response plan, open incident register entry"]
  H --> P{"Personal data involved?"}
  P -- "Yes" --> B["Privacy lead starts breach assessment"]
  P -- "No" --> F["Feedback to reporter"]
  B --> F
  C --> F
  C --> W["Weakness: create remediation task"]
```

### 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`.

| Triage outcome | Action | Record |
|---|---|---|
| False positive or harmless event | Close with reason; thank reporter | Ticket |
| Near miss | Close; check whether others received the same lure; block indicators | Ticket, near-miss tag |
| Security weakness | Create remediation task with owner and due date; link to risk register if material | Ticket, `compliance/risk-register` or `isms/vulnerability-remediation-tracker` |
| Security incident | Declare under the incident response plan, assign severity and category, open entry in `isms/incident-register` (DOC-ISMS-021) | Incident record |
| Possible personal data breach | Notify privacy lead at once; start `compliance/personal-data-breach-assessment` | Breach assessment record |
| Policy breach by an individual | Hand facts to HR under `isms/security-disciplinary-process` only after the incident is contained, and only for conduct outside the no-blame rule | HR case reference in ticket |

### 7.4 Example log *(Example rows)*

| Report ID | Received | Channel | Summary | Outcome | Linked record |
|---|---|---|---|---|---|
| SER-2027-0142 *(Example)* | 2027-03-04 09:12 | CH-01 | Invoice email with password-protected archive | Near miss, sender blocked, 6 other recipients found | none |
| SER-2027-0143 *(Example)* | 2027-03-04 21:40 | CH-03 | Laptop stolen from car | Incident, SEV3, device encrypted and wiped | INC-2027-019 |
| SER-2027-0144 *(Example)* | 2027-03-05 11:05 | CH-02 | Customer file shared with "anyone with the link" | Incident, privacy assessment opened | INC-2027-020, PDB-2027-004 |

## 8. Feedback to reporters

<!-- Guidance: Feedback is what keeps people reporting. Promise it, and measure it (section 12). Do not disclose details of other people or of the investigation. -->

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

<!-- Guidance: Cover the reports that do not fit the normal path. Questions to answer: what if the reporter suspects a security team member or a manager? What if the event comes from outside? -->

### 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

<!-- Guidance: The principle is the same at every size: one queue, fast hand-off, feedback. What changes is who receives and how out-of-hours cover works. These are the library's working tiers. -->

| Topic | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large: Quillmere Group *(Example)* |
|---|---|---|---|
| Context | 46 staff (38 employees, 8 contractors), one office plus remote staff | 320 staff, two offices, one colocation suite | 2,400 staff, 6 sites in 4 countries, OT and IT |
| Channels | CH-01, CH-02 (helpdesk tool), CH-03 rings the on-call engineer rota, CH-05 for suppliers | All six channels; CH-03 to the 3-person security team plus a managed detection provider out of hours | All six channels, local hotline numbers per country forwarding to the group security operations centre; CH-06 strong at plants |
| Receiver | On-call engineer; ISMS manager (0.5 FTE) reviews every ticket weekly | Service desk, then security team analyst | Regional service desks, group security operations centre |
| Out-of-hours cover | Engineering on-call rota | Managed detection provider | Group security operations centre 24/7 |
| Language | English | English | English plus local languages at each site; posters translated |
| Feedback | Personal reply by the analyst | Templated replies plus monthly newsletter | Templated replies in local languages, quarterly recognition |
| Typical volume *(Example)* | 4 to 8 reports a month | 25 to 50 a month | 200 to 350 a month |

## 11. One-page summary for staff

<!-- Guidance: Publish this section as a poster, intranet card and onboarding slide. Keep it identical to sections 4 to 6. -->

**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

<!-- Guidance: Measure the health of reporting, not just counts. A rising number of reports is usually good news. Feed the measurement programme (DOC-ISMS-080). -->

| Metric ID | Measure | Formula | Target *(Example)* | Source |
|---|---|---|---|---|
| SER-M01 | Reports per 100 staff per quarter | Reports in quarter / headcount x 100 | Rising trend | Security queue |
| SER-M02 | Acknowledgement within target | Reports acknowledged on time / reports | ≥ 95 % | Ticketing system |
| SER-M03 | Feedback given at closure | Reports with closing message / closed reports | ≥ 95 % | Ticketing system |
| SER-M04 | Time from noticing to reporting (median) | Median of report time minus noticed time | ≤ 1 hour for urgent categories | Ticket fields |
| SER-M05 | Share of incidents first reported by people | Incidents whose first signal was a report / all incidents | Tracked, compared with tool detection | Incident register |
| SER-M06 | Real phishing reported | Real malicious emails reported per month | Rising trend | Security mailbox |
| SER-M07 | Staff who know how to report | Correct answers in awareness quiz or spot check | ≥ 90 % | Awareness survey |

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

<!-- Guidance: List the records that prove the procedure operates, and map them in the control evidence matrix (DOC-ISMS-033). Auditors usually trace three reports end to end and ask two employees how they would report. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| Security event tickets with timestamps | Events are reported, acknowledged, triaged and closed with reasons | Security operations lead | [Ticketing system] | [3] years |
| Incident register entries linked to reports | Hand-off to incident response | Security operations lead | `isms/incident-register` | Per incident register |
| Channel test log (section 14) | Channels work, including out of hours | Security operations lead | [GRC tool] | [3] years |
| Awareness material and completion records | Staff were told how to report (A.6.3) | Awareness lead | [Learning platform] | [3] years |
| Feedback messages | Reporters receive feedback | Security operations lead | [Ticketing system] | With ticket |
| Quarterly metrics report | Monitoring of procedure performance | ISMS manager | `isms/isms-performance-report` | [3] years |

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

<!-- Guidance: Test channels quarterly, including out-of-hours calls, and review the procedure after significant incidents. Record each test. -->

| Test ID | Test | Frequency | Pass criterion | Owner |
|---|---|---|---|---|
| SER-T01 | Send a test report on each channel | Quarterly | Ticket created in security queue within [10 minutes] | Security operations lead |
| SER-T02 | Call the hotline out of hours | Quarterly | Answered or called back within [15 minutes] | Security operations lead |
| SER-T03 | Ask 10 staff "how would you report a lost laptop?" | Twice a year | ≥ 9 correct | Awareness lead |
| SER-T04 | Check every closed ticket in a month for a reason and feedback | Quarterly sample | 100 % | ISMS manager |

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

## 15. References

<!-- Guidance: Cite editions and keep links to the official pages only. -->

- 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.