Loading module...

Incident Reporting & Response | Top 10 Dev Training

GSA-09

Incident Reporting & Response

Know what counts as a security incident, how to report it quickly and correctly, and why a no-blame reporting culture directly reduces breach impact.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

A security incident is any event that compromises, or has the potential to compromise, the confidentiality, integrity, or availability of your company's data or systems. That definition is intentionally broad. The goal isn't for you to diagnose whether something is a confirmed breach. The goal is for you to recognize when something looks wrong and report it quickly, so the people with the right tools and training can investigate.

What counts as a reportable event?

Credential compromise. You entered your password on a page you now suspect was fake. You received an MFA prompt you didn't trigger. You discovered a service you use was breached and you reused that password elsewhere.

Suspicious communications. You received a phishing email, a suspicious text, or a phone call asking for credentials. Even if you didn't click or respond, the security team needs to know so they can check whether others received the same message.

Unauthorized access or data exposure. You noticed someone accessing a system they shouldn't have access to. You accidentally sent sensitive data to the wrong person. You found company data in a place it shouldn't be, like a public repository or an unapproved cloud service.

Device issues. Your laptop or phone was lost or stolen. You noticed unusual behavior on your device, like programs you didn't install or unexpected pop-ups.

Policy violations you observe. A colleague shared credentials. Pasted customer data into an unapproved AI tool. Gave a contractor access without going through IT. You don't need to confront them. Just report it.

And anything that feels wrong. This is the most important category. If something about an email, a phone call, a request, or a system behavior makes you uneasy and you can't quite articulate why, report it anyway. Your instinct is picking up on something your conscious mind hasn't fully processed yet. Security teams would rather investigate a false alarm than miss a real incident because someone hesitated.

Now, the single most important variable in incident response is time. Not expertise. Not technology. Time. The average time from initial breach to detection in 2025 was one hundred eighty one days. Organizations that detected breaches through their own internal teams rather than being notified by an attacker or a third party spent significantly less on remediation. Organizations that had tested incident response plans in advance reduced breach costs by an estimated two point six six million dollars per incident.

Every hour between a compromise and its detection gives the attacker more time to explore, escalate, exfiltrate data, and cover their tracks. An employee who reports a suspicious email thirty minutes after receiving it gives the security team a chance to block the sender, warn other employees, and check whether anyone clicked. An employee who deletes the email and says nothing gives the attacker a head start measured in days.

This is why the standard for reporting is "I think something might be wrong," not "I'm certain this is an incident." You don't need to diagnose the problem. You don't need to prove anything. You just need to raise your hand.

How to report. For suspicious emails, use the Report Phishing button in your email client if your company provides one. If not, forward to your security team's reporting address. Don't just delete. Deleting removes the evidence the security team needs.

For all other incidents, contact your IT or security team through the channel your company designates. A Slack or Teams channel. An email address. A ticketing system. A phone number.

For urgent situations, like you just transferred funds to a suspected fraudster, a device with sensitive data was stolen, or you're watching an active compromise unfold, call your IT or security team directly. Don't wait for a ticket response.

What to include. Whatever you know. What happened. When. What you did in response. Any relevant details: sender address, phone number, URL. Whether anyone else might be affected. More detail is better, but a brief "I got a weird email from someone pretending to be our CEO asking me to wire money, and I'm not sure if it's real" is infinitely more useful than silence.

Many people hesitate to report because they don't know what happens next. Triage comes first. Not every report becomes an investigation. Many are classified as false positives and closed. That's a good outcome, not a waste. If the report warrants deeper review, the security team investigates. If a real incident is confirmed, they move to containment, remediation, and recovery. Throughout, you may or may not be kept in the loop, depending on the incident's scope.

The most important part of this module is the reporting culture. Security organizations across the industry, from NIST to the UK's National Cyber Security Centre, consistently advocate for what's called a no-blame reporting culture. The principle is simple. The act of reporting a security incident should always be encouraged, never discouraged. When employees believe that reporting means getting in trouble, they stop reporting. And every unreported incident is a missed opportunity to catch an attack early.

The Uber breach of 2022 is a case study. An attacker socially engineered an employee into approving an MFA prompt. The employee didn't immediately report it. By the time the breach was discovered, the attacker had reached internal systems, security tools, and the company's bug bounty dashboard. Rapid reporting might not have prevented the initial compromise, but it would have dramatically shortened the attacker's window.

Two things are true at the same time. Reporting should always be the right call. The information you provide when you report is almost always more valuable than any error that preceded it. And your company's policies still apply. Accidentally clicking a phishing link despite your best judgment is human. Repeatedly ignoring security policies is different. These aren't in conflict. The strongest security cultures make it safe to report and take policy compliance seriously.

When in doubt, report. The consequences of silence are virtually always worse than the consequences of speaking up.

This completes the General Security Awareness Training course. Security isn't a one-time event. It's the set of decisions you make every day, at your desk, in your inbox, and on your phone. Thank you for investing the time.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

Module 9: Incident Reporting & Response

General Security Awareness Training
Estimated Time: 10 minutes

Learning Objectives

By the end of this module, you will be able to:

Identify what counts as a security incident and distinguish between confirmed incidents and suspicious activity worth reporting
Describe your company's incident reporting process and explain why speed matters more than certainty
Explain what happens after you report an incident and how the response process works
Explain why security organizations advocate for a reporting culture that encourages speed and honesty
Recognize the connection between fast reporting and reduced breach costs

What Counts as a Security Incident

A security incident is any event that compromises, or has the potential to compromise, the confidentiality, integrity, or availability of your company's data or systems. That definition is intentionally broad. The goal isn't for you to diagnose whether something is a confirmed breach. The goal is for you to recognize when something looks wrong and report it quickly so the people with the right tools and training can investigate.

Here are examples of events you should report:

Credential compromise. You entered your password on a page you now suspect was fake. You received an MFA prompt you didn't trigger. You discovered that a service you use has been breached and you reused that password elsewhere. You shared your credentials with someone, intentionally or accidentally.

Suspicious communications. You received a phishing email, a suspicious text, or a phone call asking for credentials or sensitive information. Even if you didn't click or respond, the security team needs to know so they can check whether others received the same message.

Unauthorized access or data exposure. You noticed someone accessing a system or file they shouldn't have access to. You accidentally sent sensitive data to the wrong person. You found company data in a place it shouldn't be (a public repository, an unapproved cloud service, an AI tool).

Device issues. Your laptop or phone was lost or stolen. You noticed unusual behavior on your device (programs you didn't install, unexpected pop-ups, significant slowdowns). You plugged in an unknown USB device before thinking better of it.

Policy violations you observe. A colleague shared credentials, pasted customer data into an unapproved AI tool, or gave a contractor access to a system without going through IT. You don't need to confront them. Just report it.

Anything that feels wrong. This is the most important category. If something about an email, a phone call, a request, or a system behavior makes you uneasy, and you can't quite articulate why, report it anyway. Your instinct is picking up on something your conscious mind hasn't fully processed yet. Security teams would rather investigate a false alarm than miss a real incident because someone hesitated.

Why Speed Matters More Than Certainty

The single most important variable in incident response is time. Not expertise, not technology, not budget. Time.

The average time from initial breach to detection in 2025 was 181 days. Organizations that detected breaches through their own internal teams rather than being notified by an attacker or a third party spent significantly less on remediation. And organizations that had tested incident response plans in advance reduced breach costs by an estimated $2.66 million per incident.

Every hour between a compromise and its detection gives the attacker more time to explore, escalate privileges, exfiltrate data, and cover their tracks. An employee who reports a suspicious email 30 minutes after receiving it gives the security team a chance to block the sender, warn other employees, and check whether anyone clicked. An employee who deletes the email and says nothing gives the attacker a head start measured in days.

How to Report

Your company has a defined process for reporting security incidents. The specifics vary by organization, but the process generally follows one of these paths:

For suspicious emails: Use the "Report Phishing" button in your email client if your company provides one. If not, forward the email to your security team's reporting address (check your company's security policy or intranet for the correct address). Don't just delete the email. Deleting it removes the evidence the security team needs to investigate.

For all other incidents: Contact your IT or security team through the channel your company designates. This might be a dedicated Slack or Teams channel, an email address, a ticketing system, or a phone number. If you're unsure of the right channel, tell your manager and they'll help route it.

For urgent situations (you transferred funds to a suspected fraudster, you're watching an active compromise unfold, a device with sensitive data was stolen): call your IT or security team directly. Don't wait for a ticket response. Pick up the phone.

What to Include in Your Report

When reporting, share whatever you know. Don't worry about formatting or completeness. Any of the following is helpful:

What happened (or what you suspect happened)
When it happened (or when you noticed it)
What you did in response (clicked a link, entered credentials, opened an attachment, or took no action)
Any relevant details: sender address, phone number, URL, error message, device involved
Whether anyone else might be affected (did the email go to your whole team?)

More detail is better, but a brief "I got a weird email from someone pretending to be our CEO asking me to wire money, and I'm not sure if it's real" is infinitely more useful than silence.

What Happens After You Report

Many people hesitate to report because they don't know what happens next and worry they're creating a big disruption. Here's what the process actually looks like:

Triage. The security team reviews your report and assesses the severity. Not every report turns into a full investigation. Many are quickly classified as false positives (legitimate emails that looked suspicious, system behavior with a benign explanation) and closed. That's a good outcome, not a waste of anyone's time.

Investigation. If the report warrants further review, the security team digs deeper. They might check email logs, review authentication records, scan your device for malware, or look for indicators of compromise across the company's systems. You may be asked follow-up questions.

Containment. If the incident is confirmed, the security team takes action to limit the damage: resetting compromised credentials, isolating affected devices, blocking malicious domains, revoking OAuth tokens, or locking down accounts. The goal is to stop the attacker from going further.

Remediation and recovery. The team fixes whatever was broken, restores any affected systems, and ensures the vulnerability that was exploited is closed. This might involve patching software, revoking and reissuing credentials, or updating security rules.

Lessons learned. After the incident is resolved, the team reviews what happened and what can be improved. This isn't about finding someone to blame. It's about finding gaps in process, technology, or training that allowed the incident to happen and closing them so it doesn't happen again.

Throughout this process, you may or may not be kept in the loop depending on the incident's scope and sensitivity. If you're curious about the outcome, it's fine to ask. But the most important thing you did was report it. Everything that followed was possible because you raised the flag.

Reporting Culture and Accountability

This is the most important section of this module, and possibly of the entire course.

Incident reporting only works if people actually do it. And people will only do it consistently if they believe that coming forward is the right thing to do and will be treated as such. Security organizations across the industry, from NIST to the UK's National Cyber Security Centre, consistently advocate for what's known as a "no-blame" reporting culture. The principle is simple: the act of reporting a security incident should always be encouraged, never discouraged.

Why Fear of Blame Destroys Security

When employees believe that reporting means getting in trouble, they stop reporting. The phishing email gets deleted instead of flagged. The accidental data exposure gets quietly covered up. The suspicious phone call goes unmentioned.

Every one of those unreported incidents is a missed opportunity to catch an attack early. And some of them spiral into full breaches that would have been containable if someone had spoken up in the first 30 minutes.

The Uber breach of 2022 is a case study. An attacker socially engineered an employee into approving an MFA prompt. The employee didn't immediately report it. By the time the breach was discovered, the attacker had accessed internal systems, security tools, and the company's bug bounty dashboard. Rapid reporting might not have prevented the initial compromise, but it would have dramatically shortened the attacker's window for lateral movement.

Reporting vs. Policy Compliance

It's important to understand two things that are both true at the same time:

Reporting should always be the right call. The best security organizations treat every report as a contribution to the company's defense, regardless of whether the person reporting made a mistake that led to the incident. The information you provide when you report is almost always more valuable than any error that preceded it. Delaying or withholding a report out of fear will always make the situation worse.

Your company's policies still apply. Most organizations distinguish between good-faith errors and patterns of policy non-compliance. Accidentally clicking a phishing link despite your best judgment is human. Repeatedly ignoring security policies, bypassing controls after training, or willfully disregarding established procedures is a different matter. Your company's internal policies define how these situations are handled, and you should familiarize yourself with them.

The key insight is that these two things aren't in conflict. You can have a culture that encourages fast, honest reporting while also holding people accountable for following the policies and training they've been given. In fact, the organizations with the strongest security cultures do both: they make it safe to report and they take policy compliance seriously. Reporting an incident you contributed to doesn't erase the underlying behavior, but it does ensure the damage is minimized and the organization can respond effectively.

The bottom line: When in doubt, report. The consequences of silence are virtually always worse than the consequences of speaking up. Your security team needs the information you have, and getting it to them quickly is the single most useful thing you can do when something goes wrong.

Tying It All Together

This is the final module of the course, and it connects to every module that came before it:

When you spot a phishing email (Module 2), the value is in reporting it.
When you suspect your credentials are compromised (Module 3), the value is in reporting it quickly.
When you accidentally share data with the wrong person (Module 4), the value is in reporting it, not hiding it.
When you notice a former employee still has access (Module 5), the value is in reporting it.
When you click a link that looked suspicious in hindsight (Module 6), the value is in reporting it.
When you discover a teammate is using an unapproved tool with customer data (Module 7), the value is in reporting it.
When you realize you pasted sensitive data into a public AI tool (Module 8), the value is in reporting it immediately.

Every security control in this course reduces the probability of an incident. But no set of controls reduces that probability to zero. When something goes wrong, the speed and honesty of the response determine whether it stays a minor event or becomes a headline. Your willingness to report is the bridge between prevention and recovery.

Key Takeaways

Report anything that feels wrong. You don't need certainty. "I think something might be off" is enough. The security team would rather investigate 100 false alarms than miss one real incident.
Speed is the most critical variable. The average breach takes 181 days to detect. Every hour of delay gives the attacker more room to operate. Fast reporting shrinks the window.
Know your reporting channel. Use the "Report Phishing" button for suspicious emails. For everything else, use your company's designated channel (Slack, Teams, email, ticketing system, or phone for urgent issues).
Reporting starts a process, not a crisis. Most reports are triaged quickly. Many turn out to be false positives. That's a win, not a waste. If it is real, the security team handles containment, remediation, and recovery.
When in doubt, report. The consequences of silence are virtually always worse than the consequences of speaking up. Familiarize yourself with your company's policies, follow them, and always report promptly when something goes wrong.

This completes the General Security Awareness Training course. Thank you for investing the time to strengthen your company's security posture. Remember: security isn't a one-time event. It's the set of decisions you make every day at your desk, in your inbox, and on your phone.

Module Version: 1.0
Last Updated: March 2026
Framework References: NIST Cybersecurity Framework 2.0 (Detect, Respond, Recover), SOC 2 Trust Services Criteria (CC 7.3, CC 7.4, CC 7.5)
Data Sources: IBM/Ponemon Cost of a Data Breach Report 2025, Verizon Data Breach Investigations Report 2025, NIST SP 800-61 (Computer Security Incident Handling Guide)