# Incident Review to Training Drill Mini-Course

A free, reviewable AI Studio course package for turning a recent security incident, near miss, help desk pattern, or tabletop lesson into practical employee training.

Use this starter as a template. Replace the placeholders with your approved incident language, reporting channel, escalation process, data-handling rules, and review owners before assigning it to learners.

## Intended audience

Security awareness leads, SOC and incident response teams, GRC teams, MSPs, vCISOs, L&D teams, help desk leaders, and managers who need to turn lessons learned into repeatable training without turning the incident review into a blame session.

## Course outcome

After this micro-course, learners should be able to:

1. Recognize when a security event, near miss, or suspicious request should be reported.
2. Use the approved reporting and escalation path instead of improvising.
3. Preserve useful details without collecting or sharing more sensitive information than the process requires.
4. Apply one practical lesson learned from an incident review to future work.
5. Understand that training supports response readiness and policy communication, but does not guarantee incident prevention or compliance.

## Lesson 1: From incident review to better decisions

Security incidents and near misses should produce more than a ticket, a timeline, and a quiet sigh of relief. When handled well, they also create better training.

The goal is not to embarrass employees or turn every event into a scary story. The goal is to identify the decision point that mattered:

- A suspicious email was reported quickly.
- An MFA prompt was approved by mistake.
- A vendor request bypassed the normal verification path.
- Sensitive information was almost uploaded into an unapproved tool.
- A manager was unsure whether to escalate a strange request.
- A help desk workflow created confusion during an urgent access issue.

A useful incident-review training drill turns that moment into a short, practical lesson. It explains what happened in neutral terms, what decision the learner may face later, and which approved action the organization wants people to take.

## Lesson 2: Keep the training blameless and specific

Incident-based training works best when it is blameless, concrete, and reviewed. Avoid naming employees, exposing private details, or implying that one person caused the entire problem. Focus on the workflow and the decision.

A safe structure looks like this:

1. **Situation:** What type of event or near miss occurred?
2. **Decision point:** What did someone need to decide?
3. **Approved path:** What should learners do next time?
4. **Reporting details:** What information helps the security team respond?
5. **Review note:** Which assumptions need security, legal, privacy, GRC, or leadership review?

Example:

> During a busy support window, an employee received an unexpected login prompt and a message asking them to approve access quickly. The safer decision is to deny prompts you did not start, avoid sharing codes, and report the event through `[approved reporting channel]` with the time, system, and message details you can safely provide.

## Scenario 1: The strange prompt after a normal workday

You finish work and get an MFA prompt on your phone. A few minutes later, a message appears in chat: “I’m locked out and need you to approve the login. This is urgent.”

What should you do?

A. Approve it because urgent requests should not block work.
B. Deny the prompt, do not share any code, and report the request through `[approved reporting channel]`.
C. Ask the sender for more proof in the same chat thread.
D. Ignore the prompt and do nothing else.

**Best answer: B.** If you did not start the sign-in, do not approve it and do not share a code. Reporting helps security or help desk teams check whether the request is part of a larger pattern. Replace the reporting path with your approved process before publishing.

## Scenario 2: The vendor request that almost skipped review

A vendor contact asks a business owner to add a new user to a shared workspace before a project deadline. The request sounds familiar, but the name is new and the request did not come through the usual access process.

What should the business owner do?

A. Add the user because the vendor relationship already exists.
B. Forward the request to a colleague and ask them to decide.
C. Use the approved access request and vendor verification process before granting access.
D. Send the vendor a temporary shared password.

**Best answer: C.** Existing vendors can still create new access risk. Confirm the current business purpose, named user, permission scope, and approved owner before granting access. Never use shared passwords as a shortcut.

## Scenario 3: The incident summary in an AI tool

After a near miss, a manager wants to summarize notes quickly. The notes include internal system names, employee names, customer context, and screenshots. The manager considers pasting the notes into a public AI tool to create a cleaner summary.

What should the manager do?

A. Paste the notes as-is because the tool will save time.
B. Remove a few names and paste the rest.
C. Check whether the AI tool is approved for this information type and use the approved process for summaries.
D. Ask the AI tool not to retain the information.

**Best answer: C.** Incident notes can include sensitive, confidential, regulated, or security-relevant information. Use approved tools and workflows. Do not rely on a prompt instruction as a data-protection control.

## Knowledge check

### Question 1

What is the main purpose of turning an incident review into training?

A. To prove the organization will not have the same issue again.
B. To identify one practical decision learners can make better next time.
C. To assign blame quickly.
D. To replace incident response procedures.

**Answer: B.** Training should reinforce the practical decision and approved next step. It does not guarantee prevention, replace procedures, or prove compliance.

### Question 2

Which detail should normally be removed or generalized before using an incident as a training scenario?

A. The approved reporting path.
B. The learner decision point.
C. Unnecessary names, private details, sensitive customer information, and unsupported speculation.
D. The safe next step.

**Answer: C.** Keep the training useful without exposing unnecessary personal, customer, contractual, regulated, or security-sensitive details.

### Question 3

Who should review this type of course before publishing?

A. No one, because incident-based training is always safe if it is short.
B. Security or incident response only.
C. Security plus the relevant process owner, and legal, privacy, GRC, HR, or leadership when the scenario touches sensitive areas.
D. Learners after assignment.

**Answer: C.** Incident-based training can touch sensitive facts, employee behavior, customer commitments, regulated data, contractual obligations, or legal considerations. Review before publishing.

## Remediation note template

Use this after a simulation, tabletop, help desk pattern, or real near miss.

> You are receiving this refresher because our team is reinforcing the approved process for `[topic]`. The goal is to make the next decision easier. If you see `[trigger or scenario]`, use `[approved action]` and report through `[approved reporting channel]`. If you are unsure, pause and ask `[owner/team]` before continuing.

## LMS packaging guidance

Recommended structure:

- Duration: 5-7 minutes.
- Format: micro-course with three scenarios and three knowledge checks.
- Completion criterion: view lesson plus pass knowledge check.
- Accessibility: include captions, transcript, readable scenario text, and keyboard-friendly interactions.
- Export: SCORM, xAPI, HTML, or PDF depending on your LMS and reporting needs.
- Review owners: security/incident response, process owner, L&D, and legal/privacy/GRC where appropriate.

## AI Studio prompt

Copy and adapt this prompt in AI Studio by Jericho:

```text
Create a 6-minute incident-review-to-training micro-course for employees on [incident theme or near miss]. Use blameless language. Include one short lesson, three realistic workplace scenarios, three quiz questions with teaching feedback, a remediation note, captions/transcript guidance, LMS packaging notes, and a review checklist. Teach learners to use [approved reporting channel], follow [approved process], avoid sharing unnecessary sensitive details, and escalate uncertainty to [owner/team]. Flag assumptions that security, legal, privacy, GRC, HR, or leadership should review before publishing. Do not claim the course guarantees compliance, prevents incidents, or proves control effectiveness.
```

## Review checklist

Before publishing, confirm:

- The scenario is generalized enough to avoid unnecessary employee, customer, contractual, regulated, or security-sensitive exposure.
- The approved reporting channel is accurate.
- The process owner agrees with the safe next step.
- Legal, privacy, HR, GRC, or leadership reviewed the content if the scenario touches sensitive issues.
- Quiz feedback teaches the decision, not just the correct answer.
- LMS packaging and completion tracking match your delivery requirements.
- The course is presented as support for training and readiness, not as legal advice, compliance proof, or an outcome guarantee.

## What to build next

In AI Studio by Jericho, adapt this drill for:

- MFA prompt safety.
- Vendor access review.
- Payment-change phishing.
- AI data handling.
- CUI or sensitive information handling.
- Help desk escalation.
- Manager decision-making after a near miss.

Visit https://contentstudio.jerichosecurity.com to create a reviewable version for your audience, brand, LMS, and approved workflows.
