# SilverPine payment-change incident — evidence-and-artifact workbook **Case packet version:** 2026.08.31-practice-3 **Case brief record:** CB01 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. ## How to use this workbook Complete only what the fictional packet supports. Cite the module input ID beside each material statement. Write **not supplied** for missing operational records, approvals, dates, test results, or identities. Label anything you design as a **learner proposal**. Do not contact people, access systems, run tests, sign records, or present a proposed control as an observed fact. Each module contains a prerequisite gate, six-to-eight task-specific operating steps, field-by-field guidance, schema-exact supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, a completion test, blank artifact tables, and mapped criteria. Row counts are contractual: if an assignment calls for 47 requirements, 20 records, 40 evaluations, or 27 tasks, the corresponding table contains that many stable rows. ## Module 1 — Map business exposure **Task mode:** bounded-case-starter **Prompt:** Identify critical processes, assets, owners, dependencies, consequences, and immediate authority gaps. **Deliverable:** A prioritized asset-process map and responsibility matrix. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M01-I01 | case-fact | F01 | A supplier-thread email requests an $84,600 payment to a new bank. | | | M01-I02 | case-fact | F02 | The letter's phone number differs from the approved supplier record. | | | M01-I03 | case-fact | F03 | An employee entered a cloud password after opening the attachment. | | | M01-I04 | case-fact | F04 | The employee denied an unexpected push notification and reported to the office manager. | | | M01-I05 | case-fact | F05 | A new forwarding rule and unfamiliar-region login appear in administrative logs. | | | M01-I06 | case-fact | F06 | The manager advised a password change from the same possibly affected laptop. | | | M01-I07 | case-fact | F07 | Endpoint protection on the laptop last checked in eleven days ago. | | | M01-I08 | case-fact | F08 | Three accounts can change supplier banking details. | | | M01-I09 | case-fact | F09 | One privileged account belongs to a former contractor and lacks recorded multi-factor authentication. | | | M01-I10 | case-fact | F10 | Nightly backups write to a connected network share. | | | M01-I11 | case-fact | F11 | The last recorded restore test was fourteen months ago and covered one folder. | | | M01-I12 | case-fact | F12 | No payment has been released and the incident sheet lacks operative decision rules. | | | M01-B01 | case-brief | 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. | | | M01-S01 | assignment-scope | F01, F02, F03, F04, F05, F06, F07, F08, F09, F10, F11, F12 | Build a starter version of “A prioritized asset-process map and responsibility matrix.” 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. | | ### Completion boundary 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. ### Prerequisite check - [ ] Confirm F01-F12; record that authoritative asset inventory, data classification, business-impact tiers, system owners, network/data-flow diagrams, supplier contacts, backup topology, and risk acceptance are not supplied. - [ ] STOP. If asset ownership, classification, impact tiers, data flows, supplier contacts, backup topology, or risk acceptance is missing or conflicts across F01–F12, route the exposure map to authorized finance, security, and IT owners; do not claim risk approval or execute payment, access, containment, or recovery action. ### Operating procedure 1. Inventory the payment, email, identity, endpoint, supplier-master, administrative-log, and backup processes named in the case. 2. Map the supplier request from email receipt through banking-detail change and payment authorization. 3. Map credential entry, unexpected push, forwarding rule, unfamiliar login, and endpoint-health facts as linked observations without declaring root cause. 4. Map who can change banking details and flag the former-contractor privileged account as an access-governance gap. 5. Map connected backups and stale restore testing as resilience dependencies. 6. Prioritize by potential business impact and evidence strength, not by invented likelihood. 7. Final-QC every node for source ID, owner role, open question, priority rationale, and no implied containment. ### Field-by-field guidance — M01-A01 | Field | What high-quality completion requires | |---|---| | Element | Name the process node, asset, state, or transition. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | From or trigger | State the observable event that activates the path. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | To or outcome | State the proposed next state without implying execution. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | Owner | Name the authorized operating or specialist role. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | Open question | Record the unanswered question that prevents a final decision. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | | Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the map to connect the payment, identity, endpoint, access, and recovery exposure before selecting controls. | ### Completed supported example — M01-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | Supplier-payment change path | Email requests an $84,600 payment to a new bank. | Verification and authorized banking-change/payment decision path. | F01, F02, F12 | Finance/payment process owner with security and supplier-management reviewers | Approved supplier contact, change-control record, dual-authorization rule, and decision log are not supplied. | Priority 1 - verification and review pending | ### Completed known-gap example — M01-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | Backup-recovery dependency | Nightly backup writes to a connected network share. | Verified isolated recovery path and restore evidence. | F10, F11 | IT/recovery owner | Backup separation, retention, recovery objectives, full restore scope, and current test result are not supplied. | Open - recovery evidence absent | ### Supporting artifact build sequence 1. **M01-A02 · Cyber responsibility matrix** — Produce a bounded, reviewable cyber responsibility matrix from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M01-I09, M01-I11 and address M01-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples #### M01-A02 · Cyber responsibility matrix **Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work. **Criterion demonstrated:** M01-EC02 **Why this row is included:** The canonical M01-A02 route maps M01-EC02. The row visibly ranks all four required risk families using the supplied scenario evidence and distinguishes a provisional learner priority from an approved assessment. | Item ID | Supported evidence | Source input ID | Criterion or required state | Gap or learner proposal | Owner or reviewer | Status | | --- | --- | --- | --- | --- | --- | --- | | CYBER-RISK-01 | Learner-proposed priority order: 1 payment diversion from the new-bank request; 2 account takeover from credential entry, suspicious forwarding, and unfamiliar login; 3 evidence loss from a stale endpoint and unverified connected-share backups; 4 operational disruption where incident decision rules are absent. | M01-I01 (F01), M01-I02 (F02), M01-I03 (F03), M01-I05 (F05), M01-I07 (F07), M01-I10 (F10), M01-I11 (F11), and M01-I12 (F12) | Authorized owners confirm or revise the four-category order using documented impact, likelihood, dependency, and recoverability evidence. | Impact values, likelihood estimates, recovery objectives, current restore evidence, and approved prioritization are not supplied; the ordering is a learner proposal, not a completed risk assessment. | Finance/payment owner, security/identity owner, IT/recovery owner, and incident commander | Draft — authorized risk review pending | ### Stop / Go / Escalate | Decision | Rule | |---|---| | **Stop** | Stop payment, access, or recovery assurance claims when authoritative ownership, verification, inventory, or test evidence is absent. | | **Go** | Proceed to qualified review when assets/processes, sources, owners, impact rationale, and open questions are visible. | | **Escalate** | Escalate the payment request, identity compromise indicators, privileged former-contractor access, and recovery weakness to the designated finance/security/IT owners. | ### Completion test - [ ] Payment, email, identity, endpoint, privilege, supplier, log, and backup flows are mapped. - [ ] F09 and F11 are visible rather than hidden in secondary artifacts. - [ ] No compromise, containment, or recovery outcome is asserted. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M01-A01 | M01-EC01 | M01-I01 (F01) | A supplier-thread email requests an $84,600 payment to a new bank. | Anchor one element of the map to the supplied condition and label any inferred transition as a learner proposal. Cite M01-I01 (F01) in the row. | This is one evidence-backed starter entry, not a completed prioritized asset-and-process map or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M01-A01 | M01-EC01 | The packet does not supply the complete live records, approvals, or execution results needed to finish the prioritized asset-and-process map. | Without that evidence, the learner cannot truthfully satisfy M01-EC01 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M01-A01, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M01-I12:** What bounded decision can the Authorized system owner or qualified security specialist make from M01-I12, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M01-A01 · Prioritized asset-and-process map **Purpose:** Produce a bounded, reviewable prioritized asset-and-process map from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M01-I01, M01-I02, M01-I03, M01-I04, M01-I05, M01-I06, M01-I07, M01-I08, M01-I10, M01-I12, M01-I09, M01-I11 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M01-EC01:** Connects email, identity, supplier master, payment, endpoint, logs, backups, and vendors - **M01-EC03:** Names who may hold payment, contain accounts, preserve evidence, and escalate - **M01-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | 01A01R-01 | | | | | | Not started | | 01A01R-02 | | | | | | Not started | | 01A01R-03 | | | | | | Not started | | 01A01R-04 | | | | | | Not started | | 01A01R-05 | | | | | | Not started | | 01A01R-06 | | | | | | Not started | | 01A01R-07 | | | | | | Not started | | 01A01R-08 | | | | | | Not started | | 01A01R-09 | | | | | | Not started | | 01A01R-10 | | | | | | Not started | | 01A01R-11 | | | | | | Not started | | 01A01R-12 | | | | | | Not started | | 01A01R-13 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M01-I01, M01-I02, M01-I03, M01-I04, M01-I05, M01-I06, M01-I07, M01-I08, M01-I10, M01-I12). - [ ] Every mapped rubric criterion (M01-EC01, M01-EC03, M01-EC04) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M01-A02 · Cyber responsibility matrix **Purpose:** Produce a bounded, reviewable cyber responsibility matrix from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M01-I09, M01-I11 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M01-EC02:** Ranks payment diversion, account takeover, evidence loss, and operational disruption | Item ID | Supported evidence | Source input ID | Criterion or required state | Gap or learner proposal | Owner or reviewer | Status | | --- | --- | --- | --- | --- | --- | --- | | 01A02R-01 | | | | | | Not started | | 01A02R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M01-I09, M01-I11). - [ ] Every mapped rubric criterion (M01-EC02) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M01-A01 · Prioritized asset-and-process map | 13 | M01-EC01, M01-EC03, M01-EC04 | M01-I01, M01-I02, M01-I03, M01-I04, M01-I05, M01-I06, M01-I07, M01-I08, M01-I10, M01-I12, M01-I09, M01-I11 | | M01-A02 · Cyber responsibility matrix | 2 | M01-EC02 | M01-I09, M01-I11 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M01-EC01:** Connects email, identity, supplier master, payment, endpoint, logs, backups, and vendors - [ ] **M01-EC02:** Ranks payment diversion, account takeover, evidence loss, and operational disruption - [ ] **M01-EC03:** Names who may hold payment, contain accounts, preserve evidence, and escalate - [ ] **M01-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Module 2 — Contain identity risk **Task mode:** bounded-case-starter **Prompt:** Draft authorized account-protection and recovery steps that require a known-clean channel and administrator; do not execute containment from the training packet. **Deliverable:** An identity-containment checklist and access-review record template with every action, owner, authorization, time, and result field pending. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M02-I01 | case-fact | F03 | An employee entered a cloud password after opening the attachment. | | | M02-I02 | case-fact | F04 | The employee denied an unexpected push notification and reported to the office manager. | | | M02-I03 | case-fact | F05 | A new forwarding rule and unfamiliar-region login appear in administrative logs. | | | M02-I04 | case-fact | F06 | The manager advised a password change from the same possibly affected laptop. | | | M02-I05 | case-fact | F07 | Endpoint protection on the laptop last checked in eleven days ago. | | | M02-I06 | case-fact | F08 | Three accounts can change supplier banking details. | | | M02-I07 | case-fact | F09 | One privileged account belongs to a former contractor and lacks recorded multi-factor authentication. | | | M02-B01 | case-brief | 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. | | | M02-S01 | assignment-scope | F03, F04, F05, F06, F07, F08, F09 | Build a starter version of “An identity-containment checklist and access-review record template with every action, owner, authorization, time, and result field 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. | | ### Completion boundary Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, 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. ### Prerequisite check - [ ] Confirm F03-F09; record that the identity provider, affected account list, approved incident playbook, clean administrative workstation, session/token inventory, forensic direction, and containment results are not supplied. - [ ] STOP. If the identity provider, affected accounts, approved playbook, trusted workstation, session/token inventory, or forensic direction is missing or conflicts across F03–F09, route containment to authorized security leadership and the incident coordinator; do not claim approval or execute credential, session, mailbox, privilege, or device changes. ### Operating procedure 1. Open an incident-scoped checklist without changing live systems in the exercise. 2. Record credential entry, denied push, forwarding rule, unfamiliar login, same-laptop password advice, stale endpoint check-in, banking-change access, and former-contractor privilege. 3. Order evidence preservation and qualified triage before destructive actions. 4. Design identity actions for session/token revocation, credential reset from an approved clean path, MFA review, mailbox-rule review, and privileged-access review. 5. Add endpoint isolation/collection dependencies and out-of-band communication. 6. For every check, name required evidence, authorized owner, result as pending, and exception path. 7. Final-QC sequence, source citations, account scope, evidence preservation, owner authority, and no execution claims. ### Field-by-field guidance — M02-A01 | Field | What high-quality completion requires | |---|---| | Check ID | Use a stable identifier for the quality or control check. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Control or check | State one observable check in verb-first form. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Evidence required | Name the record or observation needed to pass the check. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Source input ID | Cite the exact Fxx or module input ID supporting the entry. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Owner | Name the authorized operating or specialist role. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Result | Record pending unless the packet explicitly supplies an observed result. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Exception or gap | Describe the missing or conflicting evidence and its consequence. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | | Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the checklist to coordinate identity containment while avoiding unsafe same-device changes and preserving evidence. | ### Completed supported example — M02-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | | ID-01 | Review and contain the affected cloud identity through the approved incident process. | Identity-provider audit/session evidence plus qualified incident-owner direction. | F03, F04, F05, F06 | Security/identity incident owner | Pending - no containment action or result is supplied. | Same possibly affected laptop was proposed for password change; approved clean administrative path is not supplied. | Blocked - qualified direction required | ### Completed known-gap example — M02-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | | ID-PRIV-02 | Review and disable or otherwise resolve obsolete privileged access only under approved authority. | Authoritative account ownership, HR/contractor status, access log, MFA record, and change evidence. | F08, F09 | Identity and access owner with HR/contract owner as applicable | Pending | One privileged account belongs to a former contractor and lacks recorded MFA; no approved action record is supplied. | Urgent review pending | ### Supporting artifact build sequence 1. **M02-A02 · Access-review record** — Produce a bounded, reviewable access-review record from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M02-I02, M02-I03, M02-I05, M02-I07 and address M02-EC02, M02-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples #### M02-A02 · Access-review record **Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work. **Criterion demonstrated:** M02-EC02 **Why this row is included:** The canonical M02-A02 route maps M02-EC02. This row sequences the required actions as a reviewable proposal and explicitly withholds any claim that revocation, review, or rotation occurred. | Record ID | Supported facts | Source input ID | Decision or action pending | Owner or reviewer | Evidence needed | Status | | --- | --- | --- | --- | --- | --- | --- | | CONTAIN-SEQ-01 | A cloud password was entered after an attachment opened; an unexpected push was denied; a new forwarding rule and unfamiliar-region login appear; a password change from the same possibly affected laptop was advised. | M02-I01 (F03), M02-I02 (F04), M02-I03 (F05), and M02-I04 (F06) | Learner-proposed authorized sequence: establish a trusted administrative path; revoke active sessions; review recovery factors and forwarding rules; then rotate affected secrets and document exceptions. No step is represented as executed. | Authorized security/identity incident owner | Identity-provider session and audit logs; recovery-factor inventory; forwarding-rule record; affected-secret inventory; approved clean administrative path; authorization; timestamps; and execution results. | Proposed containment sequence — authorization and results not supplied | #### M02-A02 · Access-review record **Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work. **Criterion demonstrated:** M02-EC03 **Why this row is included:** The canonical M02-A02 route also maps M02-EC03. The row exposes the stale privileged account and defines an authorized least-privilege decision path without disabling access or fabricating a completed review. | Record ID | Supported facts | Source input ID | Decision or action pending | Owner or reviewer | Evidence needed | Status | | --- | --- | --- | --- | --- | --- | --- | | PRIV-REVIEW-02 | Three accounts can change supplier banking details, and one privileged account belongs to a former contractor and lacks recorded multi-factor authentication. | M02-I06 (F08) and M02-I07 (F09) | Verify authoritative ownership and current business need, then propose the least-privilege correction or account disablement for authorized execution; no access change is represented as completed. | Identity and access owner with the authorized HR or contract owner and payment-process owner | Authoritative worker/contract status; account owner; business justification; current roles; sign-in and change logs; MFA record; approval; change ticket; and post-change evidence. | Urgent review — correction and execution not supplied | ### Stop / Go / Escalate | Decision | Rule | |---|---| | **Stop** | Stop ad-hoc password, mailbox, privilege, or endpoint changes from a possibly affected device or without evidence-preservation and authority. | | **Go** | Proceed only under the approved incident process using a trusted administrative path and traceable evidence. | | **Escalate** | Escalate suspected account compromise, privileged stale access, payment-system access, and unavailable clean administration to security leadership. | ### Completion test - [ ] Evidence preservation, session/token, credential, MFA, mailbox, privilege, endpoint, and communication checks are ordered. - [ ] F04-F09 all shape the checklist. - [ ] Every result stays pending unless directly supplied. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M02-A01 | M02-EC01 | M02-I01 (F03) | An employee entered a cloud password after opening the attachment. | Use the supplied condition to define one check, then mark the result pending until the required verification evidence exists. Cite M02-I01 (F03) in the row. | This is one evidence-backed starter entry, not a completed identity-containment checklist or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M02-A01 | M02-EC01 | The packet does not supply the complete live records, approvals, or execution results needed to finish the identity-containment checklist. | Without that evidence, the learner cannot truthfully satisfy M02-EC01 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M02-A01, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M02-I07:** What bounded decision can the Authorized system owner or qualified security specialist make from M02-I07, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M02-A01 · Identity-containment checklist **Purpose:** Produce a bounded, reviewable identity-containment checklist from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M02-I01, M02-I04, M02-I06, M02-I02, M02-I03, M02-I05, M02-I07 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M02-EC01:** Requires a known-clean channel and authorized administrator without asserting that either is available - **M02-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them | Check ID | Control or check | Evidence required | Source input ID | Owner | Result | Exception or gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | | 02A01R-01 | | | | | | | Not started | | 02A01R-02 | | | | | | | Not started | | 02A01R-03 | | | | | | | Not started | | 02A01R-04 | | | | | | | Not started | | 02A01R-05 | | | | | | | Not started | | 02A01R-06 | | | | | | | Not started | | 02A01R-07 | | | | | | | Not started | | 02A01R-08 | | | | | | | Not started | | 02A01R-09 | | | | | | | Not started | | 02A01R-10 | | | | | | | Not started | | 02A01R-11 | | | | | | | Not started | | 02A01R-12 | | | | | | | Not started | | 02A01R-13 | | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M02-I01, M02-I04, M02-I06). - [ ] Every mapped rubric criterion (M02-EC01, M02-EC04) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M02-A02 · Access-review record **Purpose:** Produce a bounded, reviewable access-review record from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M02-I02, M02-I03, M02-I05, M02-I07 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M02-EC02:** Sequences session revocation, recovery-factor and forwarding review, and secret rotation as proposed actions rather than completed events - **M02-EC03:** Flags the stale privileged account and least-privilege correction for authorized execution without disabling access | Record ID | Supported facts | Source input ID | Decision or action pending | Owner or reviewer | Evidence needed | Status | | --- | --- | --- | --- | --- | --- | --- | | 02A02R-01 | | | | | | Not started | | 02A02R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M02-I02, M02-I03, M02-I05, M02-I07). - [ ] Every mapped rubric criterion (M02-EC02, M02-EC03) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M02-A01 · Identity-containment checklist | 13 | M02-EC01, M02-EC04 | M02-I01, M02-I04, M02-I06, M02-I02, M02-I03, M02-I05, M02-I07 | | M02-A02 · Access-review record | 2 | M02-EC02, M02-EC03 | M02-I02, M02-I03, M02-I05, M02-I07 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M02-EC01:** Requires a known-clean channel and authorized administrator without asserting that either is available - [ ] **M02-EC02:** Sequences session revocation, recovery-factor and forwarding review, and secret rotation as proposed actions rather than completed events - [ ] **M02-EC03:** Flags the stale privileged account and least-privilege correction for authorized execution without disabling access - [ ] **M02-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Module 3 — Verify the payment request **Task mode:** bounded-case-starter **Prompt:** Create an independent communication and payment-change control that does not trust the suspect thread. **Deliverable:** A payment-hold decision record and out-of-band verification plan that marks the approved supplier contact identity and verification result not supplied. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M03-I01 | case-fact | F01 | A supplier-thread email requests an $84,600 payment to a new bank. | | | M03-I02 | case-fact | F02 | The letter's phone number differs from the approved supplier record. | | | M03-I03 | case-fact | F12 | No payment has been released and the incident sheet lacks operative decision rules. | | | M03-B01 | case-brief | 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. | | | M03-S01 | assignment-scope | F01, F02, F12 | Build a starter version of “A payment-hold decision record and out-of-band verification plan that marks the approved supplier contact identity and verification result not supplied.” 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. | | ### Completion boundary Complete a bounded starter and gap analysis using only CB01, F01, F02, 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. ### Prerequisite check - [ ] Confirm F01, F02, and F12; record that the approved supplier contact, original contract/order, banking-change request, call-back result, authority matrix, fraud review, and payment decision are not supplied. - [ ] STOP. If the approved supplier contact, original order, bank-change evidence, call-back result, authority matrix, or fraud review is missing or conflicts with F01/F02/F12, route the request to authorized finance, security, and procurement leadership; do not claim verification or approval, execute a bank-detail change, release payment, or declare fraud. ### Operating procedure 1. State the bounded decision as whether to keep the payment unreleased pending verification. 2. List the new-bank request and mismatched phone as evidence supporting a hold. 3. List uncertainty and operational tradeoffs without treating the email as proven fraud. 4. Compare hold-and-verify, reject, and release options; prohibit using contact details from the suspicious thread for verification. 5. Define an out-of-band verification plan using the approved supplier master and dual authorization. 6. Name the finance decision owner and security/procurement reviewers; keep approval pending. 7. Final-QC amount, evidence, options, verification source, owner authority, status, and no fraud conclusion. ### Field-by-field guidance — M03-A01 | Field | What high-quality completion requires | |---|---| | Decision | State one bounded proposed decision; never imply payment release, supplier verification, or fraud determination. | | Evidence for | List exact facts supporting the proposal with input/fact IDs. | | Evidence against | List uncertainty and contrary or missing evidence; do not infer fraud. | | Verification source | Name the independently retrieved approved source required; use Not supplied until evidenced. | | Verified contact | Record the approved contact only when supplied; otherwise Not supplied. | | Purchase/order match | Record the underlying order/invoice match or Not supplied. | | Bank-change evidence | Record authorized change evidence or Not supplied. | | Options and tradeoffs | Compare at least hold/verify, authorized reject, and unsupported release routes. | | Decision owner | Name the role with payment authority. | | Dual-authorizer roles | Name required roles, not invented people; leave authorization pending. | | Required approval | List procurement/security/payment approvals and preserve pending state. | | Decision timestamp | Use an exact supplied time or Not supplied; do not invent action time. | | Status | Use Proposed hold, Blocked, or Pending verification. | ### Completed supported example — M03-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Decision | Evidence for | Evidence against | Verification source | Verified contact | Purchase/order match | Bank-change evidence | Options and tradeoffs | Decision owner | Dual-authorizer roles | Required approval | Decision timestamp | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Propose continued non-release pending independent verification. | M03-I01 (F01): $84,600 request to a new bank; M03-I02 (F02): phone differs; M03-I03 (F12): no payment released. | The packet does not prove fraud or supply an approved supplier response. | Previously approved supplier record retrieved independently — record itself not supplied. | Not supplied | Not supplied | Not supplied | Hold and verify preserves funds; authorized rejection awaits evidence; release carries unverified-bank risk and is unsupported. | Authorized finance/payment owner | Two authorized payment roles — identities not supplied | Dual authorization plus security/procurement review pending | Not supplied | Proposed hold — verification pending | ### Completed known-gap example — M03-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Decision | Evidence for | Evidence against | Verification source | Verified contact | Purchase/order match | Bank-change evidence | Options and tradeoffs | Decision owner | Dual-authorizer roles | Required approval | Decision timestamp | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Do not release based on the email thread alone. | No payment has been released — M03-I03 (F12). | Approved call-back contact, purchase/order match, bank-change approval, supplier response, and operative decision rules are absent. | Approved supplier record — not included in packet | Not supplied | Not supplied | Not supplied | Request verification through the approved supplier record; preserve the mismatch and response without contacting anyone in this exercise. | Finance/payment owner | Not supplied | Verification and dual-authorization evidence | Not supplied | Blocked — evidence not supplied | ### Supporting artifact build sequence 1. **M03-A02 · Out-of-band verification plan** — Produce a bounded, reviewable out-of-band verification plan from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M03-I02 and address M03-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**. ### Stop / Go / Escalate | Decision | Rule | |---|---| | **Stop** | Stop release and any bank-detail change when independent verification and required authorization are absent or conflict. | | **Go** | Proceed only after out-of-band verification through an approved record and documented dual authorization. | | **Escalate** | Escalate suspected payment diversion, supplier-record mismatch, or pressure to bypass controls to finance/security/procurement leadership. | ### Completion test - [ ] Decision, evidence for/against, options, owner, approval, and verification path are explicit. - [ ] The record says suspicious/unverified rather than proven fraud. - [ ] No payment, contact, or approval is fabricated. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M03-A01 | M03-EC01 | M03-I01 (F01) | A supplier-thread email requests an $84,600 payment to a new bank. | List the supplied condition as decision evidence and keep the decision, authority, and approval status open. Cite M03-I01 (F01) in the row. | This is one evidence-backed starter entry, not a completed payment-hold decision record or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M03-A02 | M03-EC02 | The packet does not supply the complete live records, approvals, or execution results needed to finish the out-of-band verification plan. | Without that evidence, the learner cannot truthfully satisfy M03-EC02 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M03-A02, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M03-I03:** What bounded decision can the Authorized system owner or qualified security specialist make from M03-I03, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M03-A01 · Payment-hold decision record **Purpose:** Produce a bounded, reviewable payment-hold decision record from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M03-I01, M03-I02, M03-I03 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M03-EC01:** Requires independently retrieved, previously approved supplier contact information and explicitly records that the contact details are not included in the packet - **M03-EC02:** Separates identity confirmation, change approval, and payment release as pending authorized decisions - **M03-EC03:** Defines message-and-attachment preservation and no-further-interaction rules without claiming evidence was collected - **M03-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them | Decision | Evidence for | Evidence against | Verification source | Verified contact | Purchase/order match | Bank-change evidence | Options and tradeoffs | Decision owner | Dual-authorizer roles | Required approval | Decision timestamp | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 03A01R-01 | | | | | | | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M03-I01, M03-I02, M03-I03). - [ ] Every mapped rubric criterion (M03-EC01, M03-EC02, M03-EC03, M03-EC04) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M03-A02 · Out-of-band verification plan **Purpose:** Produce a bounded, reviewable out-of-band verification plan from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M03-I02 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M03-EC02:** Separates identity confirmation, change approval, and payment release as pending authorized decisions | Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status | | --- | --- | --- | --- | --- | --- | --- | | 03A02R-01 | | | | | | Not started | | 03A02R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M03-I02). - [ ] Every mapped rubric criterion (M03-EC02) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M03-A01 · Payment-hold decision record | 1 | M03-EC01, M03-EC02, M03-EC03, M03-EC04 | M03-I01, M03-I02, M03-I03 | | M03-A02 · Out-of-band verification plan | 2 | M03-EC02 | M03-I02 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M03-EC01:** Requires independently retrieved, previously approved supplier contact information and explicitly records that the contact details are not included in the packet - [ ] **M03-EC02:** Separates identity confirmation, change approval, and payment release as pending authorized decisions - [ ] **M03-EC03:** Defines message-and-attachment preservation and no-further-interaction rules without claiming evidence was collected - [ ] **M03-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Module 4 — Coordinate device action **Task mode:** bounded-case-starter **Prompt:** Replace improvised password changes with an authorized device and software response path. **Deliverable:** A device triage decision tree and approved-software baseline exception. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M04-I01 | case-fact | F03 | An employee entered a cloud password after opening the attachment. | | | M04-I02 | case-fact | F06 | The manager advised a password change from the same possibly affected laptop. | | | M04-I03 | case-fact | F07 | Endpoint protection on the laptop last checked in eleven days ago. | | | M04-B01 | case-brief | 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. | | | M04-S01 | assignment-scope | F03, F06, F07 | Build a starter version of “A device triage decision tree and approved-software baseline exception.” 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. | | ### Completion boundary Complete a bounded starter and gap analysis using only CB01, F03, F06, F07, 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. ### Prerequisite check - [ ] Confirm F03, F06, and F07; record that the device identifier, network location, endpoint telemetry, approved forensic playbook, clean device, evidence image, isolation status, and recovery authorization are not supplied. - [ ] STOP. If device identity, network location, telemetry, forensic playbook, trusted tooling, evidence image, or isolation status is missing or conflicts with F03/F06/F07, route the branch to authorized incident leadership and the forensic/endpoint owner; do not claim recovery approval or execute isolation, cleanup, rebuild, or return to service. ### Operating procedure 1. Start from the observed credential-entry event and the possibly affected laptop. 2. Branch first on qualified incident-owner direction and evidence-preservation requirements. 3. Replace same-laptop credential change with a trusted-path decision gate. 4. Branch on endpoint connectivity/check-in and availability of current telemetry. 5. Define proposed preserve, isolate, collect, analyze, rebuild, or return-to-service paths as authorized decisions, not completed actions. 6. Add exceptions for business criticality, remote device, unavailable tooling, and safety. 7. Final-QC source IDs, sequence, owner, evidence needed, exception path, and pending result. ### Field-by-field guidance — M04-A01 | Field | What high-quality completion requires | |---|---| | Element | Name the process node, asset, state, or transition. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | From or trigger | State the observable event that activates the path. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | To or outcome | State the proposed next state without implying execution. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | Evidence and source ID | Pair the observation with its exact supplied source ID. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | Owner | Name the authorized operating or specialist role. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | Open question | Record the unanswered question that prevents a final decision. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | | Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health. | ### Completed supported example — M04-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | Possibly affected laptop | Credential was entered after opening the attachment. | Preserve state and obtain qualified triage direction before containment or credential action. | F03, F06 | Security incident/device owner | Approved playbook, device identifier, trusted administrative path, and evidence-preservation method are not supplied. | Blocked - direction pending | ### Completed known-gap example — M04-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | Endpoint-telemetry branch | Endpoint protection last checked in eleven days ago. | Treat health as unknown; determine connectivity and approved evidence-collection path. | F07 | Endpoint/security owner | Current telemetry, agent state, isolation record, and forensic evidence are not supplied. | Open - device state unknown | ### Supporting artifact build sequence 1. **M04-A02 · Exception record against the approved-software baseline** — Produce a bounded, reviewable exception record against the approved-software baseline from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M04-I02 and address M04-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**. ### Stop / Go / Escalate | Decision | Rule | |---|---| | **Stop** | Stop same-device credential changes, destructive cleanup, rebuild, or return-to-service without qualified direction and preserved evidence. | | **Go** | Proceed through the approved branch only when device identity, trusted tooling, owner, and evidence method are confirmed. | | **Escalate** | Escalate unavailable telemetry, critical business dependencies, or suspected widespread compromise to incident leadership. | ### Completion test - [ ] Trusted-path, evidence-preservation, connectivity, telemetry, isolation, analysis, recovery, and exception branches are explicit. - [ ] The endpoint result remains unknown. - [ ] No device action or forensic conclusion is fabricated. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M04-A01 | M04-EC01 | M04-I01 (F03) | An employee entered a cloud password after opening the attachment. | Anchor one element of the map to the supplied condition and label any inferred transition as a learner proposal. Cite M04-I01 (F03) in the row. | This is one evidence-backed starter entry, not a completed device-triage decision tree or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M04-A01 | M04-EC01 | The packet does not supply the complete live records, approvals, or execution results needed to finish the device-triage decision tree. | Without that evidence, the learner cannot truthfully satisfy M04-EC01 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M04-A01, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M04-I03:** What bounded decision can the Authorized system owner or qualified security specialist make from M04-I03, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M04-A01 · Device-triage decision tree **Purpose:** Produce a bounded, reviewable device-triage decision tree from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M04-I01, M04-I02, M04-I03 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M04-EC01:** Preserves evidence before reimaging, deleting, or altering the affected device - **M04-EC03:** Addresses delayed endpoint status without claiming the product prevented compromise - **M04-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them - **M04-EC02:** Routes containment and forensic choices to qualified responders | Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status | | --- | --- | --- | --- | --- | --- | --- | | 04A01R-01 | | | | | | Not started | | 04A01R-02 | | | | | | Not started | | 04A01R-03 | | | | | | Not started | | 04A01R-04 | | | | | | Not started | | 04A01R-05 | | | | | | Not started | | 04A01R-06 | | | | | | Not started | | 04A01R-07 | | | | | | Not started | | 04A01R-08 | | | | | | Not started | | 04A01R-09 | | | | | | Not started | | 04A01R-10 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M04-I01, M04-I02, M04-I03). - [ ] Every mapped rubric criterion (M04-EC01, M04-EC03, M04-EC04) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M04-A02 · Exception record against the approved-software baseline **Purpose:** Produce a bounded, reviewable exception record against the approved-software baseline from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M04-I02 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M04-EC02:** Routes containment and forensic choices to qualified responders | Record ID | Supported facts | Source input ID | Decision or action pending | Owner or reviewer | Evidence needed | Status | | --- | --- | --- | --- | --- | --- | --- | | 04A02R-01 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M04-I02). - [ ] Every mapped rubric criterion (M04-EC02) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M04-A01 · Device-triage decision tree | 10 | M04-EC01, M04-EC03, M04-EC04, M04-EC02 | M04-I01, M04-I02, M04-I03 | | M04-A02 · Exception record against the approved-software baseline | 1 | M04-EC02 | M04-I02 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M04-EC01:** Preserves evidence before reimaging, deleting, or altering the affected device - [ ] **M04-EC02:** Routes containment and forensic choices to qualified responders - [ ] **M04-EC03:** Addresses delayed endpoint status without claiming the product prevented compromise - [ ] **M04-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Module 5 — Assess data, vendor, and recovery **Task mode:** bounded-case-starter **Prompt:** Map the data, vendor, and backup questions and design a representative restore test; do not access systems or perform restoration. **Deliverable:** A data-flow and vendor-register starter plus a restore-test plan with test execution and recovery results pending. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M05-I01 | case-fact | F05 | A new forwarding rule and unfamiliar-region login appear in administrative logs. | | | M05-I02 | case-fact | F10 | Nightly backups write to a connected network share. | | | M05-I03 | case-fact | F11 | The last recorded restore test was fourteen months ago and covered one folder. | | | M05-B01 | case-brief | 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. | | | M05-S01 | assignment-scope | F05, F10, F11 | Build a starter version of “A data-flow and vendor-register starter plus a restore-test plan with test execution and recovery results 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. | | ### Completion boundary Complete a bounded starter and gap analysis using only CB01, F05, F10, F11, 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. ### Prerequisite check - [ ] Confirm F05, F10, and F11; record that data categories, systems, vendors, contracts, administrators, retention, encryption, backup isolation, recovery objectives, and current restore results are not supplied. - [ ] STOP. If data scope, vendor access, contract terms, retention/encryption, backup isolation, recovery objectives, or restore evidence is missing or conflicts with F05/F10/F11, route the register to authorized security, privacy, vendor, and IT/recovery reviewers; do not claim compliance or recovery approval, execute notification, or assert recoverability. ### Operating procedure 1. Register administrative-log, email, supplier/payment, identity, endpoint, and backup data flows separately. 2. For each flow, state source, destination, data category, access role, retention/deletion state, and evidence ID. 3. Record the unfamiliar login and forwarding-rule observations without declaring a breach scope. 4. Map the connected network-share backup as a potential shared failure path, not a recovery guarantee. 5. Use the fourteen-month-old one-folder restore record to require a broader approved restore test. 6. Add vendor/contract, privacy, security, and recovery review gates where evidence is absent. 7. Final-QC flow completeness, owners, source citations, retention/access gaps, recovery dependence, and no compliance claim. ### Field-by-field guidance — M05-A01 | Field | What high-quality completion requires | |---|---| | Flow ID | Assign a stable training flow/register ID. | | Source system | Name only the supplied system or mark it Not supplied. | | Destination/vendor | Name the supplied destination/vendor or Not supplied; do not infer one. | | Data category | Classify the relevant data at a bounded level; label a proposed classification. | | Purpose | State the supplied or proposed processing/recovery purpose. | | Access roles | Record supplied access facts or Not supplied; do not invent identities. | | Retention/deletion | Record the evidenced rule or Not supplied. | | Contract/control evidence | Cite control/contract evidence or mark it Not supplied. | | Backup/recovery dependency | State the supplied recovery dependency and distinguish job status from verified restore. | | Source IDs | Cite exact module input and fact IDs. | | Owner/reviewer | Name the authorized system, privacy, vendor, recovery, or security role. | | Gap | Name the exact missing flow, contract, access, retention, or recovery evidence. | | Status | Use Open, Blocked, or Draft — review pending. | ### Completed supported example — M05-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Flow ID | Source system | Destination/vendor | Data category | Purpose | Access roles | Retention/deletion | Contract/control evidence | Backup/recovery dependency | Source IDs | Owner/reviewer | Gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | FLOW-EMAIL-01 | Administrative email logs | Forwarding destination not supplied | Potential message content and account metadata — proposed classification | Forwarding-rule purpose not supplied | Internal administrator has logs; broader access not supplied | Not supplied | Not supplied | Not established for this flow | M05-I01 (F05) | Security/email owner | Rule creator, destination, authorization, affected data, timestamps, and preserved-log location are not supplied. | Open — scope not supplied | ### Completed known-gap example — M05-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Flow ID | Source system | Destination/vendor | Data category | Purpose | Access roles | Retention/deletion | Contract/control evidence | Backup/recovery dependency | Source IDs | Owner/reviewer | Gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | FLOW-BACKUP-02 | Production data source not supplied | Connected network share — M05-I02 (F10) | Backup contents not supplied | Nightly backup | Not supplied | Not supplied | Not supplied | Last recorded restore test was 14 months ago and covered one folder — M05-I03 (F11). | M05-I02 (F10); M05-I03 (F11) | IT/recovery owner and security reviewer | Isolation, representative coverage, recovery objectives, restore evidence, and current control status are not supplied. | Blocked — recoverability not verified | ### Supporting artifact build sequence 1. **M05-A02 · Restore-test plan** — Produce a bounded, reviewable restore-test plan from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M05-I02, M05-I03 and address M05-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**. ### Stop / Go / Escalate | Decision | Rule | |---|---| | **Stop** | Stop vendor, privacy, or recovery assurance when flow, access, contract, retention, isolation, or restore evidence is missing. | | **Go** | Proceed to review when every material flow and dependency has an owner, cited source, and bounded evidence request. | | **Escalate** | Escalate suspected data forwarding, connected-backup exposure, and stale restore testing to security, privacy, IT/recovery, and management owners. | ### Completion test - [ ] Material sources, destinations, categories, access, retention, vendor, backup, and restore dependencies are represented. - [ ] F05/F10/F11 are all in the principal register. - [ ] No breach scope, compliance, or recoverability outcome is asserted. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M05-A01 | M05-EC01 | M05-I01 (F05) | A new forwarding rule and unfamiliar-region login appear in administrative logs. | Open a traceable register entry for the supplied condition and route the unresolved decision to the named authorized role. Cite M05-I01 (F05) in the row. | This is one evidence-backed starter entry, not a completed data-flow and vendor register or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M05-A01 | M05-EC01 | The packet does not supply the complete live records, approvals, or execution results needed to finish the data-flow and vendor register. | Without that evidence, the learner cannot truthfully satisfy M05-EC01 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M05-A01, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M05-I03:** What bounded decision can the Authorized system owner or qualified security specialist make from M05-I03, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M05-A01 · Data-flow and vendor register **Purpose:** Produce a bounded, reviewable data-flow and vendor register from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M05-I01, M05-I02, M05-I03 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M05-EC01:** Provides fields for data categories, access, retention, vendor contact, and contract questions while marking unavailable values not supplied - **M05-EC03:** Separates the reported green job status from verified recoverability | Flow ID | Source system | Destination/vendor | Data category | Purpose | Access roles | Retention/deletion | Contract/control evidence | Backup/recovery dependency | Source IDs | Owner/reviewer | Gap | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 05A01R-01 | | | | | | | | | | | | Not started | | 05A01R-02 | | | | | | | | | | | | Not started | | 05A01R-03 | | | | | | | | | | | | Not started | | 05A01R-04 | | | | | | | | | | | | Not started | | 05A01R-05 | | | | | | | | | | | | Not started | | 05A01R-06 | | | | | | | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M05-I01). - [ ] Every mapped rubric criterion (M05-EC01, M05-EC03) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M05-A02 · Restore-test plan **Purpose:** Produce a bounded, reviewable restore-test plan from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M05-I02, M05-I03 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M05-EC02:** Defines representative restoration evidence against proposed time and data expectations without claiming a test occurred | Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status | | --- | --- | --- | --- | --- | --- | --- | | 05A02R-01 | | | | | | Not started | | 05A02R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M05-I02, M05-I03). - [ ] Every mapped rubric criterion (M05-EC02) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M05-A01 · Data-flow and vendor register | 6 | M05-EC01, M05-EC03 | M05-I01, M05-I02, M05-I03 | | M05-A02 · Restore-test plan | 2 | M05-EC02 | M05-I02, M05-I03 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M05-EC01:** Provides fields for data categories, access, retention, vendor contact, and contract questions while marking unavailable values not supplied - [ ] **M05-EC02:** Defines representative restoration evidence against proposed time and data expectations without claiming a test occurred - [ ] **M05-EC03:** Separates the reported green job status from verified recoverability ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Module 6 — Run the incident **Task mode:** bounded-case-starter **Prompt:** 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. ### Supplied-input register | Input ID | Kind | Source record(s) | What the packet supplies | Where I used it | |---|---|---|---|---| | M06-I01 | case-fact | F01 | A supplier-thread email requests an $84,600 payment to a new bank. | | | M06-I02 | case-fact | F02 | The letter's phone number differs from the approved supplier record. | | | M06-I03 | case-fact | F03 | An employee entered a cloud password after opening the attachment. | | | M06-I04 | case-fact | F04 | The employee denied an unexpected push notification and reported to the office manager. | | | M06-I05 | case-fact | F05 | A new forwarding rule and unfamiliar-region login appear in administrative logs. | | | M06-I06 | case-fact | F06 | The manager advised a password change from the same possibly affected laptop. | | | M06-I07 | case-fact | F07 | Endpoint protection on the laptop last checked in eleven days ago. | | | M06-I08 | case-fact | F08 | Three accounts can change supplier banking details. | | | M06-I09 | case-fact | F09 | One privileged account belongs to a former contractor and lacks recorded multi-factor authentication. | | | M06-I10 | case-fact | F10 | Nightly backups write to a connected network share. | | | M06-I11 | case-fact | F11 | The last recorded restore test was fourteen months ago and covered one folder. | | | M06-I12 | case-fact | F12 | No payment has been released and the incident sheet lacks operative decision rules. | | | M06-B01 | case-brief | 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 | assignment-scope | 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. | | ### Completion boundary 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. ### Prerequisite check - [ ] 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. ### 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 — M06-A01 | Field | What high-quality completion requires | |---|---| | 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. | ### Completed supported example — M06-A01 **Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work. | Event ID | Date/time or not supplied | Observed fact | Source ID | Confidence | Evidence location/status | Decision/action pending | Owner/reviewer | Dependency | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | INC-EVT-01 | 9:12 a.m. (CB01) | Supplier-thread email requests $84,600 to a new bank; the letter phone differs from the approved supplier record; no payment has been released. | M06-B01 (CB01); M06-I01 (F01); M06-I02 (F02); M06-I12 (F12) | Confirmed observations; sender legitimacy and fraud determination not established | Original message, headers, attachment, and approved supplier record are not supplied/preserved in this exercise. | Authorized finance/security owner must decide verification, payment hold, and incident linkage. | Finance/payment owner with security and procurement reviewers | Approved supplier contact, purchase/order record, bank-change evidence, and decision log | Open — decisions pending | ### Completed known-gap example — M06-A01 **Reference only.** This row demonstrates how to preserve missing evidence without inventing a result. | Event ID | Date/time or not supplied | Observed fact | Source ID | Confidence | Evidence location/status | Decision/action pending | Owner/reviewer | Dependency | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | INC-EVT-02 | 9:26 a.m. (CB01) | Employee entered a cloud password after opening the attachment. | M06-B01 (CB01); M06-I03 (F03) | Confirmed observation; page ownership, credential use, and incident scope not established | Original browser, identity, device, and page evidence are not supplied; no preservation result is claimed. | Qualified incident owner must establish an authorized containment and evidence-preservation sequence. | Security incident owner | Trusted administrative path, identity logs, endpoint telemetry, device identifier, and action log | Blocked — evidence and action chronology pending | ### Supporting artifact build sequence 1. **M06-A02 · Tabletop inject plan** — Produce a bounded, reviewable tabletop inject plan from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I01, M06-I02, M06-I08, M06-I09 and address M06-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” 2. **M06-A03 · Incident decision register** — Produce a bounded, reviewable incident decision register from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I03, M06-I10, M06-I12 and address M06-EC02, M06-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” 3. **M06-A04 · After-action template** — Produce a bounded, reviewable after-action template from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I04, M06-I11 and address M06-EC01, M06-EC04. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” ### Completed supporting-artifact examples No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**. ### Stop / Go / Escalate | Decision | Rule | |---|---| | **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. | ### Completion test - [ ] 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. ### Secondary evidence-trace crosswalk The authored procedure and schema-exact examples above are the main teaching method. This compact crosswalk links the legacy starter and gap controls to the original packet. #### Legacy worked-starter trace | Artifact | Criterion | Input | Supported value | How to use it | Boundary | |---|---|---|---|---|---| | M06-A01 | M06-EC01 | M06-I05 (F05) | A new forwarding rule and unfamiliar-region login appear in administrative logs. | Enter the supplied condition as the factual basis of the record and preserve the pending decision or evidence gap. Cite M06-I05 (F05) in the row. | This is one evidence-backed starter entry, not a completed incident-record starter or an operational result. | #### Legacy known-gap trace | Artifact | Criterion | Missing evidence | Why it matters | Authorized owner or reviewer | Bounded next step | Status | |---|---|---|---|---|---|---| | M06-A02 | M06-EC02 | The packet does not supply the complete live records, approvals, or execution results needed to finish the tabletop inject plan. | Without that evidence, the learner cannot truthfully satisfy M06-EC02 or represent this artifact as complete. | Authorized system owner or qualified security specialist | Record the missing evidence in M06-A02, name the authorized reviewer, and leave the outcome pending; do not obtain or simulate the live record in this exercise. | Open — not supplied | ### Decision prompt **M06-I12:** What bounded decision can the Authorized system owner or qualified security specialist make from M06-I12, and what must remain pending until the missing evidence or approval is supplied? ### Artifact-build tables ### M06-A01 · Incident-record starter **Purpose:** Produce a bounded, reviewable incident-record starter from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M06-I05, M06-I06, M06-I07, M06-B01, M06-I01, M06-I02, M06-I03, M06-I04, M06-I08, M06-I09, M06-I10, M06-I11, M06-I12 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M06-EC01:** Uses the exact event times in citable CB01 and the F01 through F12 records while leaving action times, owners, and preserved-evidence results pending | Event ID | Date/time or not supplied | Observed fact | Source ID | Confidence | Evidence location/status | Decision/action pending | Owner/reviewer | Dependency | Status | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 06A01R-01 | | | | | | | | | Not started | | 06A01R-02 | | | | | | | | | Not started | | 06A01R-03 | | | | | | | | | Not started | | 06A01R-04 | | | | | | | | | Not started | | 06A01R-05 | | | | | | | | | Not started | | 06A01R-06 | | | | | | | | | Not started | | 06A01R-07 | | | | | | | | | Not started | | 06A01R-08 | | | | | | | | | Not started | | 06A01R-09 | | | | | | | | | Not started | | 06A01R-10 | | | | | | | | | Not started | | 06A01R-11 | | | | | | | | | Not started | | 06A01R-12 | | | | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M06-I05, M06-I06, M06-I07). - [ ] Every mapped rubric criterion (M06-EC01) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M06-A02 · Tabletop inject plan **Purpose:** Produce a bounded, reviewable tabletop inject plan from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M06-I01, M06-I02, M06-I08, M06-I09 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M06-EC02:** Lists legal, insurer, law-enforcement, customer, regulator, and supplier decision points without contacting them or predetermining outcomes | Step or milestone | Trigger or date | Evidence and source ID | Owner | Gate or threshold | Dependency or gap | Status | | --- | --- | --- | --- | --- | --- | --- | | 06A02R-01 | | | | | | Not started | | 06A02R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M06-I01, M06-I02, M06-I08, M06-I09). - [ ] Every mapped rubric criterion (M06-EC02) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M06-A03 · Incident decision register **Purpose:** Produce a bounded, reviewable incident decision register from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M06-I03, M06-I10, M06-I12 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M06-EC02:** Lists legal, insurer, law-enforcement, customer, regulator, and supplier decision points without contacting them or predetermining outcomes - **M06-EC03:** Defines proposed recovery verification, monitoring, credential-reset, and control-improvement owners without claiming execution | Entry ID | Issue or event | Evidence and source ID | Risk or impact | Owner | Bounded next step | Review point | Status | | --- | --- | --- | --- | --- | --- | --- | --- | | 06A03R-01 | | | | | | | Not started | | 06A03R-02 | | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M06-I03, M06-I10, M06-I12). - [ ] Every mapped rubric criterion (M06-EC02, M06-EC03) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### M06-A04 · After-action template **Purpose:** Produce a bounded, reviewable after-action template from cited packet evidence while exposing unsupported fields and required approvals. **Scoped case-fact inputs:** M06-I04, M06-I11 **Instructions:** Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.” **Mapped evidence criteria** - **M06-EC01:** Uses the exact event times in citable CB01 and the F01 through F12 records while leaving action times, owners, and preserved-evidence results pending - **M06-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them | Section or field | Purpose | Supported entry | Source input ID | Gap or learner proposal | Owner or reviewer | Status | | --- | --- | --- | --- | --- | --- | --- | | 06A04R-01 | | | | | | Not started | | 06A04R-02 | | | | | | Not started | **Completion checks** - [ ] Every supported entry identifies and cites at least one applicable scoped case-fact input (M06-I04, M06-I11). - [ ] Every mapped rubric criterion (M06-EC01, M06-EC04) is addressed in the artifact or a named evidence gap. - [ ] Unsupported fields remain “not supplied” or are explicitly labeled as a learner proposal. - [ ] The Authorized system owner or qualified security specialist is named for decisions or review; no approval or execution is implied. ### Artifact coverage map | Artifact | Expected rows | Mapped criteria | Scoped case-fact inputs | |---|---:|---|---| | M06-A01 · Incident-record starter | 12 | M06-EC01 | M06-I05, M06-I06, M06-I07, M06-B01, M06-I01, M06-I02, M06-I03, M06-I04, M06-I08, M06-I09, M06-I10, M06-I11, M06-I12 | | M06-A02 · Tabletop inject plan | 2 | M06-EC02 | M06-I01, M06-I02, M06-I08, M06-I09 | | M06-A03 · Incident decision register | 2 | M06-EC02, M06-EC03 | M06-I03, M06-I10, M06-I12 | | M06-A04 · After-action template | 2 | M06-EC01, M06-EC04 | M06-I04, M06-I11 | ### Decision and revision record | Decision or question | Supported observations with input IDs | Contradictory evidence | Learner proposal | Alternative | Evidence that would change the recommendation | |---|---|---|---|---|---| | | | | | | | ### Evidence-criteria checklist - [ ] **M06-EC01:** Uses the exact event times in citable CB01 and the F01 through F12 records while leaving action times, owners, and preserved-evidence results pending - [ ] **M06-EC02:** Lists legal, insurer, law-enforcement, customer, regulator, and supplier decision points without contacting them or predetermining outcomes - [ ] **M06-EC03:** Defines proposed recovery verification, monitoring, credential-reset, and control-improvement owners without claiming execution - [ ] **M06-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them ### Self-review note - What did I initially assume? - Which input contradicted or weakened that assumption? - What remains outside my role or authority? - What will I revise before asking for human feedback? ## Final packet review - [ ] Every material statement cites an input ID. - [ ] Every omitted record is marked **not supplied**. - [ ] Every designed control or template is marked **learner proposal**. - [ ] Every mapped criterion is addressed in its artifact or a named gap. - [ ] Contracted row counts and row IDs remain intact. - [ ] Specialist and decision-owner handoffs are explicit. - [ ] No simulated work is represented as a completed real-world action, approval, test, signature, or professional opinion.