Foundry Academy · Cybersecurity Fundamentals · Lesson 6 of 6

Incident recognition, reporting, and recovery

Recognize possible incidents, preserve safety and evidence, use the approved reporting path, and support coordinated response and recovery without exceeding role authority.

Start the lesson

Your learning work, on this device

No signup, cloud storage, cross-device sync or verified completion. Saving is optional. This browser profile is shared with anyone who can use it; private mode, browser cleanup or storage limits may remove work. Use only fictional or non-sensitive material. Export a copy before relying on this device.

Not saved. Worksheets, answers and practice notes currently last only in this tab.

Practice markers are self-reported, never credentials.

01 · Explanation

Incident recognition, reporting, and recovery

Objective: Recognize possible incidents, preserve safety and evidence, use the approved reporting path, and support coordinated response and recovery without exceeding role authority.

Possible incident signals include unexpected MFA prompts, disabled security tools, unusual forwarding rules, locked or encrypted files, missing devices, unauthorized transactions, vendor notices, exposed shares, new administrators, suspicious login alerts, or reports that data reached the wrong person. Employees do not need to prove an incident before reporting. The first-actions card should name internal and alternate contacts, information to capture, prohibited actions, and emergency routes. Record what was observed, when, on which asset, by whom, and any actions already taken. Do not delete messages, wipe systems, confront a suspected actor, or investigate beyond authorization.

Response coordinates preparation, detection, analysis, containment, eradication, recovery, communication, legal and regulatory duties, and improvement under qualified leadership. Immediate actions depend on the incident; disconnecting or powering off a device can either limit harm or destroy evidence, so follow the approved responder's direction. Keep customer, employee, media, regulator, insurer, law-enforcement, and vendor communications with authorized owners. Recovery verifies restored systems, credentials, integrations, data integrity, monitoring, and business service before declaring success. Conduct a blameless after-action review, assign corrective actions, and test the changed control. Serious incidents require experienced security, legal, privacy, insurance, and possibly law-enforcement support.

Before you begin

  • Confirm F01-F12 and CB01; record that exact timestamps/order, reporter/device/account identifiers, preserved artifacts, response actions, communications, decisions, approvals, recovery validation, and closure evidence are not supplied.
  • STOP. If the event order, identifiers, preserved artifacts, response record, communication decision, recovery validation, or closure evidence is missing or conflicts with F01–F12/CB01, route the incident record to the authorized incident commander and security, finance, and recovery reviewers; do not claim approval or execute attribution, notification, recovery, or closure.

Original overview module anchor →

02 · Compare the artifacts

Supported work. Visible uncertainty.

This fictional, sanitized defensive-security case contains no real credentials, account numbers, personal data, or exploitable instructions. It is not legal, forensic, insurance, or cybersecurity assurance.

SilverPine payment-change incident

SilverPine Fabrication is a fictional 38-person manufacturer. At 9:12 a.m., accounts payable received an email inside an existing supplier thread requesting that the next $84,600 payment move to a new bank. The message used the supplier controller's display name and included an attached letter, but the phone number on the letter differs from the approved supplier record. At 9:26, an employee opened the attachment and entered a cloud password on a page that later disappeared. At 9:31, a push-notification approval arrived; the employee denied it and called the office manager. The manager told the employee to change the password from the same laptop but did not contact the incident lead. Email logs available to the internal administrator show a new forwarding rule created at 9:29 and a login from an unfamiliar region. The laptop reports that endpoint protection last checked in 11 days ago. The supplier master record can be changed by three accounts; one belongs to a former contractor and has no recorded multi-factor authentication. Backups run nightly to a connected network share. The dashboard is green, but the last documented restoration test occurred 14 months ago and recovered only one folder. The company's incident sheet lists names but no after-hours method, severity criteria, evidence-preservation steps, payment-hold authority, or customer and regulatory decision process. No payment has been released. Learners must map assets and responsibility, protect authentication and recovery, verify communication independently, manage device and software actions, assess data, vendor, and backup controls, and construct an authorized incident response. They must not investigate outside authorization, contact an attacker, destroy evidence, or declare breach scope and legal notification obligations without qualified review.

Supported example — reference only

Event ID
INC-EVT-01
Date/time or not supplied
9:12 a.m. (CB01)
Observed fact
Supplier-thread email requests $84,600 to a new bank; the letter phone differs from the approved supplier record; no payment has been released.
Source ID
M06-B01 (CB01); M06-I01 (F01); M06-I02 (F02); M06-I12 (F12)
Confidence
Confirmed observations; sender legitimacy and fraud determination not established
Evidence location/status
Original message, headers, attachment, and approved supplier record are not supplied/preserved in this exercise.
Decision/action pending
Authorized finance/security owner must decide verification, payment hold, and incident linkage.
Owner/reviewer
Finance/payment owner with security and procurement reviewers
Dependency
Approved supplier contact, purchase/order record, bank-change evidence, and decision log
Status
Open — decisions pending

A well-handled evidence gap

Event ID
INC-EVT-02
Date/time or not supplied
9:26 a.m. (CB01)
Observed fact
Employee entered a cloud password after opening the attachment.
Source ID
M06-B01 (CB01); M06-I03 (F03)
Confidence
Confirmed observation; page ownership, credential use, and incident scope not established
Evidence location/status
Original browser, identity, device, and page evidence are not supplied; no preservation result is claimed.
Decision/action pending
Qualified incident owner must establish an authorized containment and evidence-preservation sequence.
Owner/reviewer
Security incident owner
Dependency
Trusted administrative path, identity logs, endpoint telemetry, device identifier, and action log
Status
Blocked — evidence and action chronology pending

Flawed approach — do not copy

Marking this incident-record starter “approved and complete” without the required evidence or reviewer is a flawed submission. Stop closure, attribution, recovery, notification, or assurance claims while critical evidence, authority, or validation is absent.

Repair: Rework the incident-record starter as an evidence-backed draft, not an approved result. Open one incident record with a training identifier and mark status open. Enter each supplied event/condition as a separate timeline item with its source ID; never invent a timestamp. Separate observed facts from hypotheses and decisions pending. Check the revision against this requirement: All twelve facts are represented across separate source-linked items or explicit context links. If the required evidence is still absent, keep the decision blocked and identify the missing input or authorized reviewer.

Full case record, ambiguities and all assignments →

03 · Bounded practice

Build the incident-record starter.

Construct an incident-timeline starter and tabletop design from the supplied events; do not exercise response, contact external parties, or claim containment or recovery.

Deliverable: An incident-record starter, tabletop-inject plan, decision-register template, and after-action template with simulation and outcome fields pending.

Complete a bounded starter and gap analysis using only CB01, F01, F02, F03, F04, F05, F06, F07, F08, F09, F10, F11, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

Exact supplied inputs for this assignment
  • M06-I01 · F01 — A supplier-thread email requests an $84,600 payment to a new bank.
  • M06-I02 · F02 — The letter's phone number differs from the approved supplier record.
  • M06-I03 · F03 — An employee entered a cloud password after opening the attachment.
  • M06-I04 · F04 — The employee denied an unexpected push notification and reported to the office manager.
  • M06-I05 · F05 — A new forwarding rule and unfamiliar-region login appear in administrative logs.
  • M06-I06 · F06 — The manager advised a password change from the same possibly affected laptop.
  • M06-I07 · F07 — Endpoint protection on the laptop last checked in eleven days ago.
  • M06-I08 · F08 — Three accounts can change supplier banking details.
  • M06-I09 · F09 — One privileged account belongs to a former contractor and lacks recorded multi-factor authentication.
  • M06-I10 · F10 — Nightly backups write to a connected network share.
  • M06-I11 · F11 — The last recorded restore test was fourteen months ago and covered one folder.
  • M06-I12 · F12 — No payment has been released and the incident sheet lacks operative decision rules.
  • M06-B01 · CB01 — Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
  • M06-S01 · F01, F02, F03, F04, F05, F06, F07, F08, F09, F10, F11, F12 — Build a starter version of “An incident-record starter, tabletop-inject plan, decision-register template, and after-action template with simulation and outcome fields pending.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

Operating procedure

  1. Open one incident record with a training identifier and mark status open.
  2. Enter each supplied event/condition as a separate timeline item with its source ID; never invent a timestamp.
  3. Separate observed facts from hypotheses and decisions pending.
  4. Link payment, identity, email, endpoint, privilege, backup, and recovery workstreams.
  5. For each item, name evidence needed and the role authorized to decide or act.
  6. Add communication, legal/privacy, insurer, supplier, and leadership decision gates without claiming notification.
  7. Final-QC chronology uncertainty, evidence preservation, decisions, owner authority, recovery/closure criteria, and no executed-response claim.
Field-by-field guidance
Event ID
Assign a stable event/condition ID; it is not a live incident number.
Date/time or not supplied
Use exact CB01 time when present; otherwise write Not supplied.
Observed fact
Record one supplied event or condition without adding cause, scope, or outcome.
Source ID
Cite exact module input/fact IDs and CB01 through M06-B01 where used.
Confidence
Preserve the supplied confidence and distinguish observation from conclusion.
Evidence location/status
Name the supplied location or exact evidence still not supplied; do not claim preservation.
Decision/action pending
State the authorized decision or action that remains pending.
Owner/reviewer
Name an authorized role, not an invented person.
Dependency
Name the prerequisite evidence, specialist review, communication decision, or recovery gate.
Status
Use Open, Blocked, Observed — unverified, or Pending decision.
Incident-record starter · learning draft
Event IDDate/time or not suppliedObserved factSource IDConfidenceEvidence location/statusDecision/action pendingOwner/reviewerDependencyStatus

Start with 6 rows; the complete workbook specifies 12 stable rows for this artifact. Add rows here or use the full download. No action is saved until you explicitly choose saving above.

Download complete six-module workbook (.md) · Structured case packet (.json)

Keep private client data, unpublished inventions, personal identifiers and credentials out of these public learning tools.

Module 6 · 2-item formative check

Incident recognition, reporting, and recovery

Choose an answer and request feedback. Read why each option does or does not fit the evidence. Answers stay in this tab unless you choose device-only saving; they are never submitted.

Question 1 of 2 · MODULE 6 · knowledgeAn employee suspects malware after opening an attachment. What is the best first principle?
Question 2 of 2 · MODULE 6 · scenarioSilverPine’s F01 through F12 are all confirmed case records, including a suspicious payment request, credential entry, identity and administrative anomalies, stale access, connected backups, limited restore evidence, and no released payment. Which incident starter is traceable?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • All twelve facts are represented across separate source-linked items or explicit context links.
  • Payment, identity, endpoint, access, backup, communication, recovery, and after-action gates are present.
  • No timestamp, action, root cause, notification, recovery, or closure is invented.

Stop: Stop closure, attribution, recovery, notification, or assurance claims while critical evidence, authority, or validation is absent.

Go: Proceed to coordinated incident review when every supplied observation is source-linked and each missing action/evidence item has an owner.

Escalate: Escalate payment risk, privileged access, suspected account compromise, evidence loss, or recovery failure immediately under the approved incident process.

04 · Evidence to keep

Leave with usable work.

Submit the event timeline, contact tree, first-actions card, decision log, communication ownership, recovery checks, and after-action plan.

Download your artifact CSV and, if wanted, export the learning-work JSON above. Neither export is a reviewed submission or certificate. Device-only saving is optional; you must press Save my work now after edits.

When all six artifacts are ready, compare the full packet against the track rubric. Qualified human review is still required before real-world decisions.

Computer user working at a secured workstation during a cybersecurity exercise.
Learn the standard. Practice the work.
Technology professional reviewing account and device security controls.
Leave with evidence you can inspect.

Sources, scope and review boundaries

Curriculum 2026.10.08-learning-paths-1. External source dates below are record checks, not continuing guarantees. Verify current requirements before consequential use.

nist-csf-2-publication · Official guidance

The NIST Cybersecurity Framework (CSF) 2.0

Primary NIST framework for governing, identifying, protecting, detecting, responding to, and recovering from cybersecurity risk.

Open reviewed external source ↗

nist-sp-800-61-r3 · Official guidance

NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations

Current NIST guidance for integrating incident response throughout cybersecurity risk management.

Open reviewed external source ↗

ws-cybersecurity-operating-standard · Academy internal operating standard

Wealth Synergy cybersecurity internal operating standard

Academy-selected asset, access, verification, device, backup, incident, and restoration controls; it does not authorize security testing. This is an internal operating standard selected by Foundry Academy; it is not law, accreditation, licensure, or an external-standard requirement.

Version 1.0 · reviewed 2026-09-01 · owner: Foundry Academy curriculum owner

A future Wealth Synergy private professional-development certificate would be issued only after its assessment, capstone, identity, reviewer, retention, access, deletion, appeal, and issuance controls pass quality review. No credential is currently issued. Any future certificate would not be an accredited academic qualification, professional license, or government certification.