How to Report a Security Incident at Work

Most security incidents are first seen by someone who does not work in security, and the minutes between "that looked odd" and a report reaching the security team decide how much damage follows. This guide is the staff-facing companion to the policy: it tells employees, contractors and line managers what counts as a security incident, which route to use, what to say, what to do and not do while waiting, and how fast each kind of event needs to be reported. It also gives the security and service desk teams who publish the process the settings, wording and measures that make reporting quick and safe. The mandate, roles and authority sit in the Incident Response Policy Template, and the intake record sits in the Security Incident Report Form Template; this page does not repeat them.

Key takeaways

Report on suspicion, not certainty. A report that turns out to be harmless costs the service desk a few minutes; a real incident reported a day late can cost a regulatory deadline and a much larger clean-up.
Clicking is not the incident, silence is. The NCSC warns that users who fear reprisals will not report mistakes promptly, if at all, so the process must reward the person who says "I clicked" within minutes.
Use the built-in report button for suspicious email. Forwarding a phishing message to colleagues or to a shared inbox spreads the link and strips the headers analysts need.
Some events have a clock from the moment you notice. Under GDPR Article 33 the controller has 72 hours after becoming aware of a personal data breach, and awareness can start with one member of staff.
Every route needs a fallback that does not depend on the affected system. If your laptop, email or account may be compromised, report by phone or from another device.

What counts as a security incident at work

A useful test for staff is the confidentiality, integrity and availability question: could this affect the confidentiality, integrity or availability of the organisation's information, systems or accounts? If the answer is "maybe", report it. Staff do not need to classify the event or decide whether it is "serious enough"; that is the triage team's job. The table below translates the policy triggers into the things people actually see, with the timing the organisation should publish.

What you notice	Why it matters	Report within	Best route
A suspicious email you have not interacted with	Early warning: other staff will have received the same message (ATT&CK T1566 Phishing)	Same working day	Report button in the mail client
You clicked a link, opened an attachment or typed your password after a suspicious message	Possible credential theft or malware; the account may already be in use by someone else	Immediately (minutes)	Phone the service desk, then use the report button
A multi-factor authentication prompt or code request you did not start	Someone may already hold your password (T1621 Multi-Factor Authentication Request Generation, T1078 Valid Accounts)	Immediately; deny the prompt	Phone the service desk
Lost or stolen laptop, phone, security key or badge	Device wipe, session revocation and badge disablement are time critical	Immediately, including out of hours	24x7 phone line
Personal or confidential data sent, shared or published to the wrong person or place	Possible personal data breach with a 72 hour regulatory clock	Immediately	Service desk or privacy mailbox, and your manager
A password, API key, token or private key pasted into a ticket, chat, code repository or public site	Anyone who finds a leaked credential can use it until it is revoked	Immediately	Security mailbox or service desk, plus the system owner
Ransom note, files renamed or unreadable, a machine behaving strangely	Possible malware or ransomware spreading	Immediately; disconnect from the network	Phone, from a different device
A caller, text or chat asking for access, MFA resets, payment changes or gift cards	Social engineering often targets several staff at once	Same hour	Service desk or security mailbox
A supplier or customer tells you about an incident on their side	Third-party incidents can reach your data and accounts	Same day	Security mailbox and the supplier manager
An AI assistant, bot or automation doing something nobody asked for with work data	Automated identities act with real permissions and at speed	Same hour	Service desk, and the system owner

Out of scope: ordinary IT faults with no security angle, such as a printer jam or a forgotten password with nothing suspicious around it. When in doubt, report: the service desk can reclassify in seconds.

How to report: routes, and what to say

Organisations should publish no more than three routes and make each one obvious: a button for email, a phone number for anything urgent, and a mailbox or portal form for everything else. The NCSC phishing guidance asks for a reporting process that is clear, simple and quick to use, communicated before an incident because a compromised device may cut off normal channels.

Suspicious email: use the report button

Microsoft 365: in Outlook, select Report, then Report phishing (or Report junk). Administrators enable this in the Microsoft Defender portal under Settings, Email & collaboration, User reported settings, with "Use the built-in Report button in Outlook".
Google Workspace and Gmail: open the message, select More next to Reply, then Report phishing. If a genuine message was flagged by mistake, the same menu offers Report not phishing.
Do not forward the message to colleagues to ask whether it is real, do not reply to the sender, and do not click links "to check". The report button sends the original with its headers intact.
Personal or non-work channels: in the UK, suspicious email can also be forwarded to the NCSC Suspicious Email Reporting Service at [email protected] and scam texts to 7726. These help take down malicious sites but are not a substitute for telling your employer when work accounts or devices are involved, and the NCSC states that a report to this service is not a crime report.

Anything urgent: phone

Clicked links, unexpected MFA prompts, lost devices, data sent to the wrong place and signs of malware all go to the phone line, because a person on a call can start containment straight away: disable the session, reset the password, block the device. Call from a device that is not the one involved. The NCSC incident response process guidance recommends at least two contact methods for each contact and alternative channels for when email, phone or network systems are down, so publish a number that does not depend on the corporate telephony platform as well.

What to say: the five facts

What happened, in your own words. "I got a text saying it was IT, clicked the link and typed my password" is perfect.
When, as accurately as you can, with your time zone. Regulators measure deadlines from awareness, so the time matters.
Which account, device or data was involved: your username, the laptop asset tag, the file or customer list.
What you have done since: closed the page, entered a code, changed your password, told a colleague.
How to reach you on a channel that is not the affected device.

"I don't know" is a valid answer to every question. A partial report in ten minutes beats a complete one tomorrow. The intake fields behind these questions are laid out in the Security Incident Report Form Template.

What to do, and not do, while you wait

Situation	Do	Do not
Clicked a link or entered credentials	Close the page; report by phone; change the password only if the service desk asks you to, from a known clean device	Reuse that password anywhere; wait to see if anything happens
Unexpected MFA prompt	Deny it; report it; note the time and the location shown in the prompt	Approve it "to make it stop"; read a code out to anyone who calls
Possible malware or ransomware	Disconnect from the network (unplug the cable, turn off Wi-Fi); leave the machine powered on unless told otherwise	Shut down, wipe or "clean" the machine yourself; plug in USB drives to save files
Data sent to the wrong recipient	Report; ask the recipient politely to delete it and confirm; record who and when	Rely on a mail recall alone; send follow-up mail with more data
Secret or key exposed	Report with the exact location (link, channel, commit); tell the owning team	Delete the message and assume it is gone; the secret must be revoked and rotated
Lost device	Report straight away with the asset tag and last known location	Wait until you have searched everywhere
Suspicious caller	End the call; call back on a number you already know; report	Confirm any detail about colleagues, systems or processes

The underlying rule is preservation. Analysts need the original message, the browser history, the running memory of an infected machine and the audit trail of the account. Well-meant tidying destroys exactly that evidence. Device-specific steps are in the Lost or Stolen Device Response Checklist, and wrong-recipient handling is covered in Misdirected email and email recall.

How fast, and why the clock starts with you

Several legal and contractual deadlines run from the moment the organisation becomes aware of an incident, and a member of staff noticing something can be that moment. GDPR Article 33(1) requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of a personal data breach, unless the breach is unlikely to result in a risk to people's rights and freedoms. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware, which is why staff at service providers must escalate breaches affecting client data at once. Article 33(5) requires every personal data breach to be documented, including ones that are not notified, so even "minor" misdirected emails need a report.

Sector and national rules add their own clocks, and supplier contracts often require notice within 24 or 48 hours. Staff do not need to know these rules; they need to know that delay can make the organisation miss them. The obligations themselves are mapped in the Data Breach Notification Checklist and the Cyber Incident Reporting Requirements Map.

Minutes: anything where an attacker may already have access (clicked and entered credentials, approved a prompt, malware signs, exposed secret, lost device).
Same hour: social engineering attempts, odd automation behaviour, data sent to the wrong place.
Same day: suspicious email not interacted with, supplier notices, policy breaches you witnessed.
Out of hours: the minutes category still applies. Publish the 24x7 number on badges, the intranet and in onboarding material.

Managers, contractors and remote staff

Line managers: do not investigate, interview or decide whether to escalate. Pass the report on, make sure the person has made it themselves, and protect them from blame. A manager who sits on a report for a day has broken the clock for everyone.
Contractors and suppliers' staff: they report to both their own employer and the organisation whose systems or data are involved. The contract should name the route; the induction should repeat it.
Remote and travelling staff: save the phone number on a personal phone, not only in the work address book, so it is reachable if the work device is lost or locked.
Help desk and service desk: they receive most reports and are themselves a target. Verification rules for callers are in the Vishing and Help Desk Social Engineering Awareness Guide.
Engineers who leak a secret: the fix is revocation and rotation by the owning team, not deleting the commit. The patterns behind these incidents are in Leaked secret breaches.

Building the reporting process: what the security team sets up

Pick the routes and publish them in one place. One intranet page, one short URL, one phone number, one mailbox. Put the same three items in onboarding, the email signature of the service desk and the back of ID badges.
Configure the report button and the reporting mailbox. In Microsoft Defender for Office 365, the "Send reported items to" setting offers Microsoft and my reporting mailbox, My reporting mailbox only, or Microsoft only. The reporting mailbox must be an Exchange Online mailbox; Microsoft advises configuring it as a SecOps mailbox in the advanced delivery policy so reports are not filtered, and excluding it from data loss prevention policies. In Google Workspace, confirm with the vendor documentation how user reports surface to administrators before publishing staff instructions.
Close the loop with the reporter. Microsoft offers a customisable results email for Phishing, Junk and No threats found outcomes and a "Mark as and notify" action on the Submissions page. The NCSC advises responding promptly with what action was taken, so reporters learn their effort mattered.
Write the no-blame statement and get HR to co-sign it. The NCSC recommends buy-in from HR, support and senior management so reassurance is consistent. State plainly that prompt self-reporting of a mistake is never itself a disciplinary matter.
Pilot with one department. Run a short campaign, time how long it takes for a report to reach a triage analyst, and fix the slowest step before rolling out.
Test the fallbacks. Run a desk exercise where email and SSO are unavailable and check that staff can still find and reach the phone route.
Rehearse twice a year. Combine with awareness training and, if used, simulations. See the Phishing Simulation Programme Guide for measuring report rates rather than only click rates.

Small vs large organisations: a small organisation can use a single phone number and a single mailbox monitored by named people with deputies. A large one needs a ticketing queue, the mail client integration, a 24x7 rota and language variants, but the staff-facing message should stay the same three routes.

Measuring whether reporting works

Metric	What good looks like	Source
Median time from first user report to triage start	Minutes for urgent routes, same working day for email reports	Ticketing timestamps
Report rate on real and simulated phishing campaigns	Rising over time; the NCSC recommends tracking reports, not only clicks	Report button data, simulation platform
Proportion of incidents first detected by staff reports	Stable or rising share; a fall may mean people have stopped reporting	Incident records
Self-reported clicks as a share of all clicks found	High; low values suggest fear of blame	Incident records compared with proxy or mail logs
Reporter feedback sent within agreed time	Close to all reports	Submissions or ticket closure data
Staff who can name the urgent route in a spot check	Most staff asked	Quarterly pulse survey

Common failure patterns

Reporting only works through the channel under attack. SMS phishing reaches staff outside corporate email filtering; the Twilio Breach 2022 shows texts posing as IT capturing credentials and one-time codes, which is why routes beyond email matter.
Staff approve a prompt to make it stop and say nothing. The Uber Breach 2022 followed repeated MFA approval requests until one was accepted. Teach staff that an unexpected prompt is itself a report, and alert on repeated denied prompts; see the MFA Fatigue and Bypass Guide.
Blame after a click. Naming people, mandatory retraining as punishment or "wall of shame" dashboards teach staff to hide mistakes.
Forward-to-a-mailbox processes. Forwarded phishing loses headers, lands in DLP or spam filters and spreads the link to whoever reads the mailbox.
No feedback. Reports vanish into a queue, reporters stop bothering, and the report rate quietly falls.
Managers as a bottleneck. Policies that tell staff to "inform your manager" without a direct route add hours to the clock.

Framework mapping

Framework	Reference	What it expects
NIST SP 800-53 Rev. 5	IR-6 Incident Reporting; IR-6(1) Automated Reporting; IR-7 Incident Response Assistance	Personnel report suspected incidents within a defined time; support is available to users
NIST SP 800-53 Rev. 5	AT-2 Literacy Training and Awareness; AT-2(3) Social Engineering and Mining	Staff can recognise and report social engineering
NIST CSF 2.0	PR.AT-01; DE.AE-02; RS.CO-02	Awareness for general tasks; analysis of adverse events; stakeholders notified of incidents
NIST SP 800-61 Rev. 3	CSF 2.0 Community Profile for incident response	Incident response integrated into overall cyber risk management
CIS Controls v8.1	14.6 Train Workforce Members on Recognizing and Reporting Security Incidents; 17.3 Establish and Maintain an Enterprise Process for Reporting Incidents	A documented reporting process that staff are trained on
ISO/IEC 27001:2022	Annex A 6.8 Information security event reporting	Personnel report observed or suspected events through appropriate channels in a timely manner
GDPR	Article 33(1), (2), (5)	72 hours from awareness for controllers; processors notify without undue delay; all breaches documented

The wider awareness programme that these reporting duties sit in is covered in the CIS Control 14 Security Awareness and Skills Training Guide.

Practitioner checklist

Publish one page with the three routes: report button, 24x7 phone number, mailbox or portal.
Enable the built-in report button and route reports to a monitored mailbox excluded from filtering and DLP.
Publish the "what you notice" table with timings, in plain language, in onboarding and on the intranet.
Issue a no-blame statement for prompt self-reporting, co-signed by HR and an executive.
Give a fallback number that works when email, SSO and corporate telephony are down.
Send every reporter an outcome message within an agreed time.
Tell staff explicitly: deny unexpected MFA prompts and report them.
Track time to triage, report rate and self-reported click share every quarter.
Test the fallback route in an exercise at least once a year.

How to Report a Security Incident at Work: What to Report, How and How Fast