Portal Walkthrough — Control 3.4: Incident Reporting and Root Cause Analysis

READ FIRST — Scope, Sibling Routing, and Non-Substitution

This walkthrough is the portal-first operating manual for Control 3.4 — the central regulator-notification clock orchestrator for AI-agent-related cyber and operational incidents in a US Financial Services Institution (FSI). It connects detection and triage in Microsoft Defender XDR and Microsoft Sentinel to investigation in Microsoft Purview Insider Risk Management and eDiscovery (Premium), supervisory escalation in Communication Compliance, evidence and case management in SharePoint, time-bound notification choreography in Power Automate, and the firm's external regulator-notification matrix.

In scope (this file)

Topic	Where it lives
Defender XDR Unified Incidents queue, severity rubric, MITRE ATT&CK + ATLAS tagging	§2
Microsoft Sentinel Incidents and SOAR (Logic Apps) playbook wiring	§3
Purview Insider Risk Management — Cases (pseudonymized review, AI-agent-misuse templates)	§4
Purview eDiscovery (Premium) — legal holds, custodian notices, regulator-production export	§5
Purview Communication Compliance — Copilot-generated content supervisory escalation	§6
Microsoft 365 Service Health — Microsoft-side correlation before firm-side root-cause declaration	§7
SharePoint IR list — case fields, regulator notification matrix, legal-hold-aware site	§8
Power Automate notification flows — per-regulator timer countdowns, Teams adaptive cards	§9
Materiality determination workflow (SEC Form 8-K Item 1.05)	§10
OFAC sanctions screening for ransom payments	§11
Tabletop exercise harness (quarterly AI-specific scenarios)	§12
Regulator portal references (NYDFS, EDGAR, FINRA Firm Gateway, FTC, CISA, state AGs)	§13
Sovereign-cloud parity admonition and compensating manual register / matrix	§1, §14

Out of scope — routed to siblings

Topic	Route to
PowerShell automation, KQL hunting bundles, Graph notification stubs	powershell-setup.md
Verification queries, KPI definitions, examiner test scripts	verification-testing.md
UI anomalies, connector throttling, stale-state diagnostics	troubleshooting.md
Sentinel data-connector configuration and ingestion baselining	Control 3.9 — Microsoft Sentinel Integration
Insider risk policy authoring (upstream of cases)	Control 1.12 — Insider Risk Detection and Response
Supervisory review program (FINRA Rule 3110)	Control 2.12 — Supervision and Oversight
Audit-log retention and books-and-records	Control 1.7, Control 1.9

If the task at hand is not a portal-driven incident-management or regulator-notification action, stop and follow the routing above before continuing.

Non-Substitution

The Microsoft 365 tooling described in this walkthrough supports detection, triage, evidence preservation, and notification choreography. It does not replace any of the following firm-owned obligations:

• The written incident-response program required by NYDFS 23 NYCRR 500.16, the SEC Reg S-P 2024 amendments at 17 CFR §248.30(a)(3), the FTC Safeguards Rule at 16 CFR 314.4(h), and the FFIEC IT Handbook (Information Security and Business Continuity Management booklets).
• Supervisory review under FINRA Rule 3110 — see Control 2.12. Defender / Sentinel alerts about Copilot-generated content do not substitute for registered-principal review by a Series 24 / 9 / 10 / 26 / 51 / 53 principal as applicable.
• Legal hold and litigation preservation — issued and revoked by the General Counsel or designee through Purview eDiscovery (Premium); automated holds described in §5 are operational support, not legal sufficiency.
• Regulator notification filings — NYDFS Cybersecurity Portal, SEC EDGAR Form 8-K, FINRA Firm Gateway 4530, FTC online breach form, CISA portal (when CIRCIA effective), and state-attorney-general portals are filed by named human filers in Compliance, Legal, or the Privacy Office. Power Automate countdown timers (§9) inform filers — they do not file.
• Books-and-records retention required by SEC Rule 17a-3, 17a-4, and FINRA Rule 4511 — see Control 1.7 and Control 1.9.

Hedged language is used throughout this document — phrasing such as "supports", "helps meet", "aids in", and "required for" — to reinforce that final regulatory determinations rest with the firm's CCO, General Counsel, and named filers, not with Microsoft tooling.

Sovereign Cloud Availability (GCC / GCC High / DoD)

Several capabilities described in this walkthrough are not at parity in sovereign clouds at time of writing. Confirm against the Microsoft 365 sovereign roadmap and your tenant's release notes before each control execution.

Capability	Commercial	GCC	GCC High	DoD	Compensating control
Defender XDR Unified Incidents (cross-workload correlation)	GA	GA (parity may lag 30–90 days)	Limited	Limited	§1 manual incident register
Microsoft Sentinel SOAR (Logic Apps) playbooks	GA	GA	GA (subset of connectors)	GA (subset of connectors)	§1 manual notification matrix
Purview Insider Risk Management — Cases	GA	GA	Limited / staged	Not available	§1 manual case log
Purview eDiscovery (Premium)	GA	GA	Available	Available	None — verify SKU
Purview Communication Compliance (Copilot scope)	GA	GA	Limited	Not available	Manual supervisor sampling per Control 2.12
Power Automate premium connectors (Teams adaptive card, ServiceNow)	GA	GA	Subset	Subset	Email + manual ticket flow

Sovereign tenants execute the Manual Incident Register and Manual Notification Matrix in §1 as the primary evidence artifact for Control 3.4 until parity is confirmed. The portal sections below remain available to the extent the underlying capability is GA in your cloud.

Portal Navigation May Shift

Microsoft regularly updates portal blade names and navigation. Where this walkthrough cites a path such as Defender XDR → Investigation & response → Incidents, treat the path as descriptive, not authoritative. If a blade has moved, anchor on the page title and any documented telemetry node IDs rather than the breadcrumb. Capture the new path in troubleshooting.md so it can be promoted into the next revision.

Document Map

§	Section	Primary surface	Verification criterion
0	Pre-flight prerequisites and triage	All portals	VC-1 (roles, licenses, scope)
1	Sovereign-cloud variant — manual incident register and notification matrix	Manual worksheet	VC-2
2	Defender XDR Unified Incidents — triage, severity rubric, MITRE ATT&CK + ATLAS tagging	security.microsoft.com → Investigation & response → Incidents	VC-3
3	Microsoft Sentinel — Incidents and SOAR (Logic Apps) playbooks	Azure portal → Sentinel workspace → Incidents	VC-4
4	Purview Insider Risk Management — Cases	purview.microsoft.com → Insider risk management → Cases	VC-5
5	Purview eDiscovery (Premium) — legal hold and regulator-production export	purview.microsoft.com → eDiscovery → Premium	VC-6
6	Purview Communication Compliance — Copilot supervisory escalation	purview.microsoft.com → Communication compliance	VC-7
7	Microsoft 365 Service Health — Microsoft-side correlation gate	admin.microsoft.com → Health → Service health	VC-8
8	SharePoint IR list — case fields, notification matrix, legal-hold site	SharePoint admin center + IR site	VC-9
9	Power Automate — notification flows, per-regulator timers, Teams adaptive cards	make.powerautomate.com	VC-10
10	Materiality determination workflow (SEC 8-K Item 1.05)	Disclosure Committee — SharePoint + Teams	VC-11
11	OFAC sanctions screening for extortion / ransom payment	GC + Treasury workflow	VC-12
12	Tabletop exercise harness — quarterly AI-specific scenarios	Teams + SharePoint	VC-13
13	Regulator portal references — NYDFS, EDGAR, FINRA, FTC, CISA, state AGs	External portals	VC-14
14	Evidence capture, cadence, and examiner packet	All portals + Purview	VC-15

The numbering of regulator timers used throughout this walkthrough mirrors the Regulator Notification Matrix in Control 3.4. Detection and triage signals upstream of §2 are owned by Control 1.8 and Control 3.9; supervisory escalation downstream of §6 is owned by Control 2.12.

0. Pre-flight Prerequisites and Triage

Before opening any portal blade or declaring an incident, complete the pre-flight checks below. A failed pre-flight gate is itself an auditable finding and must be logged in the incident worksheet that anchors every Control 3.4 case.

0.1 Role elevation via Entra PIM

Every role used in this walkthrough must be activated through Microsoft Entra Privileged Identity Management (PIM) with a justification reference and, where required, dual approver sign-off. Session maximums of 4–8 hours are recommended; do not leave incident-response roles permanently assigned. Permanent assignment is itself a Control 3.4 finding under the principle of least privilege required by GLBA Safeguards 16 CFR 314.4(c).

Canonical role	Surfaces required for	Elevation recommendation
CISO (or Incident Commander delegate)	Defender XDR Incidents, Sentinel Incidents, Disclosure Committee invocation	8 h session, dual-approver for Sev-1 / Sev-2
Chief Compliance Officer (CCO)	NYDFS / FINRA / SEC notification gating, regulator-portal access	8 h session, justification = incident ID
General Counsel	Legal hold issuance, materiality determination, OFAC screening	8 h session, dual-approver
Privacy Officer	Reg S-P / GLBA / state breach evaluation, customer notification authoring	4 h session
AI Governance Lead	AI-agent-specific case ownership in Insider Risk Management, ATLAS tagging review	4 h session
Sentinel Admin	Sentinel automation rules, playbook bind, SOAR	4 h session, ticket justification
SOC Analyst	Defender XDR triage, Sentinel investigation graph, Cloud Apps drill-in	4 h session
Entra Security Admin	Identity-side containment (revoke sessions, disable accounts)	4 h session, dual-approver for tenant-admin scope
Power Platform Admin	Disable / quarantine compromised agents, environment isolation	4 h session
M365 Admin	Service Health correlation, Exchange / Teams content actions	4 h session
Purview Compliance Admin	IRM cases, eDiscovery (Premium) holds, Communication Compliance review	4 h session
Designated Series 24/66 Principal	Supervisory close-out for customer-facing Copilot incidents	4 h session
Business Continuity Officer	BCM invocation, FFIEC alignment	4 h session
Internal Audit (read-only observer)	Evidence-trail walk-through, post-incident review attestation	8 h session, read-only PIM role

Examiner Evidence Box — Role elevation

Capture for every Control 3.4 incident:

1. PIM activation history export (CSV) filtered to the incident window from initial detection (T0) through post-incident review (T+30 days at minimum, longer if extended notification timers are still running).
2. Ticket ID from the change / access-management system (ServiceNow, Jira, Azure DevOps).
3. Screenshot of the PIM "My roles" blade for each elevated principal showing active assignments and expiration timestamps.
4. Approver record where dual approval applied.

Store in the Purview-backed evidence library tagged Control=3.4, Incident=. Apply retention label FSI-AgentGov-6yr-WORM to help meet SEC 17a-4(f) recordkeeping expectations.

0.2 License and feature verification

1. In the Microsoft 365 admin center at https://admin.microsoft.com, confirm the tenant has active Microsoft 365 E5 (or E5 Security + E5 Compliance) and Microsoft 365 Copilot licensing across the in-scope user base. Open Billing → Licenses and screenshot the license inventory.
2. In Microsoft Defender XDR at https://security.microsoft.com, confirm Settings → Microsoft Defender XDR → General → Account shows the unified XDR experience enabled and onboarding status = Complete.
3. In Microsoft Sentinel (Azure portal → Microsoft Sentinel → select workspace), confirm at least the following data connectors are Connected (full configuration is owned by Control 3.9):
   • Microsoft Defender XDR
   • Microsoft Entra ID (sign-in logs, audit logs, risky users)
   • Microsoft 365 (Unified Audit Log)
   • Microsoft Defender for Cloud Apps
   • Microsoft Purview Information Protection
   • Power Platform inventory connector (Copilot Studio / Power Apps activity)
4. In Microsoft Purview at https://purview.microsoft.com, confirm:
   • Insider risk management → Settings → Analytics shows Enabled (or analytics-only mode for tenants in pilot).
   • eDiscovery → Premium is provisioned (E5 Compliance or eDiscovery & Audit add-on).
   • Communication compliance has at least one Copilot-scoped policy active (cross-ref Control 2.12).
5. In Power Platform admin center at https://admin.powerplatform.microsoft.com, confirm Tenant → Analytics settings → Admin analytics is On.
6. Record the tenant region and sovereign-cloud flag on the incident worksheet — this determines whether §1 compensating controls apply.

0.3 Authoritative-source readiness

Incident triage is only as reliable as the upstream signals that feed Defender XDR and Sentinel. Confirm the following before any Control 3.4 session:

Source	Owner	Readiness check
Unified Audit Log (UAL)	Purview Compliance Admin	Last ingestion timestamp ≤ 30 minutes; no ingestion-lag banner on Purview → Audit landing page
Entra sign-in logs	Entra Security Admin	Last record ≤ 5 minutes; risky-user list refreshed
Defender for Cloud Apps activity log	SOC Analyst	Connector status Healthy; activity count within ±10% of 7-day baseline
Power Platform admin analytics	Power Platform Admin	Last export ≤ 7 days; agent inventory matches Control 1.2 registry within ±2%
Agent registry (Control 1.2)	AI Governance Lead	Last attestation ≤ 30 days; owner field populated for 100% of registered agents
Sentinel data connectors	Sentinel Admin	All in-scope connectors Connected; ingestion delta ≤ 15 minutes
Service Health feed	M365 Admin	Health dashboard loads without error; advisory feed current

A failure in any row does not block declaring an incident, but must be logged as an evidentiary caveat on the incident worksheet — examiners may ask why a particular signal was unavailable during the window of interest, and the firm must be able to explain.

0.4 Pre-flight gate checklist

• Required roles activated via PIM and evidence captured (§0.1)
• Licensing and feature flags confirmed (§0.2)
• Authoritative-source freshness confirmed or exceptions logged (§0.3)
• Sovereign-cloud flag recorded on the incident worksheet
• Incident severity (Sev-1 / 2 / 3) provisionally assigned per §2.3 rubric
• Evidence library path and incident tag prepared in Purview
• ITSM ticket opened, incident commander named, and linked to the worksheet
• CCO and General Counsel placed on standby notice for any Sev-1 / Sev-2 candidate

Only proceed to §1 (sovereign) or §2 (commercial / GCC) after every box is ticked or a documented exception is approved by the Incident Commander.

Cross-Reference

Pre-flight role and licensing checks overlap with Control 2.25 §0 pre-flight. Where the same evidence has been captured for an in-flight 2.25 session, link that artifact rather than re-capturing — but do re-confirm the freshness of authoritative sources at incident T0.

1. Sovereign Cloud Variant — Manual Incident Register and Manual Notification Matrix

GCC High and DoD tenants (and occasionally GCC during staged rollouts) lack full parity for Defender XDR cross-workload correlation, Purview Insider Risk Management cases, and the Communication Compliance Copilot scope. Until parity is confirmed, the Manual Incident Register and Manual Notification Matrix below become the primary evidence artifacts for Control 3.4 in those tenants.

1.1 Manual Incident Register inputs

The register is a SharePoint list (or, where SharePoint columns are insufficient, a controlled Excel workbook on the IR site documented in §8). Every row represents one incident and carries the following columns at minimum:

Column	Type	Source / authority
IncidentId	Text (firm-prefixed, e.g., INC-FSI-2026-0042)	Incident Commander assigns at T0
DetectionTimeUtc	DateTime	Earliest signal timestamp from Defender XDR / Sentinel / IRM / SOC analyst observation
DetectionSource	Choice (Defender XDR / Sentinel / IRM / Comm Compliance / Service Health / Tip / Other)	SOC Analyst
Severity	Choice (Sev-1 / Sev-2 / Sev-3 / Sev-4)	Incident Commander per §2.3 rubric
MaterialityCandidate	Yes/No	CISO + General Counsel; triggers §10 if Yes
AgentInvolved	Yes/No	AI Governance Lead
AgentId	Text (links to Control 1.2 registry)	AI Governance Lead
Zone	Choice (Z1 Personal / Z2 Team / Z3 Enterprise)	AI Governance Lead
NPIRecordsAffected	Number	Privacy Officer
BooksAndRecordsImpact	Yes/No	CCO
SupervisorySystemFailure	Yes/No	Designated Series 24/66 Principal
PublicDisclosureThreshold	Yes/No	CISO + General Counsel
MITREATTACK	Multi-choice	SOC Analyst (cross-ref §2.4)
MITREATLAS	Multi-choice	AI Governance Lead (cross-ref §2.4)
RegulatorMatrixApplied	Yes/No	CCO (links to §1.2)
LegalHoldId	Text	General Counsel (cross-ref §5)
RootCauseStatement	Long text	Incident Commander at close-out
RootCauseTimestampUtc	DateTime	Used to start regulator clocks (§9)
EvidencePackUri	URL	Purview-backed library
CloseOutSignedBy	Person	Incident Commander + CCO

1.2 Manual Notification Matrix template

The matrix is a per-incident table that records, for every potentially applicable regulator clock, the determination, owner, and filing status. The matrix is updated at each materiality / scoping checkpoint and is the source of truth that the §9 Power Automate countdown timers mirror in commercial tenants.

Regulator clock	Trigger event	Statutory window	Owner (firm role)	Filed Yes/No	Filing receipt
NYDFS 23 NYCRR 500.17(a) — cybersecurity event notice	Determination of "cybersecurity event" reportable to Superintendent	72 hours from determination	CCO + CISO
NYDFS 23 NYCRR 500.17(c) — extortion-payment notice	Extortion payment made (any amount)	24 hours from payment	CCO + General Counsel
NYDFS 23 NYCRR 500.17(c)(2) — extortion-payment written description	Extortion payment	30 days from payment	CCO
Federal banking 36-hour rule (12 CFR 53.3 OCC / 225.302 Fed / 304.23 FDIC)	"Notification incident" determined	36 hours from determination	CISO + CCO
SEC Form 8-K Item 1.05	Materiality determination of cybersecurity incident (public-company FSIs)	4 business days from materiality determination	General Counsel + Disclosure Committee		EDGAR receipt
SEC Reg S-P 17 CFR §248.30(a)(4) customer notice	"Sensitive customer information" reasonably likely accessed/used	As soon as practicable, not later than 30 days after becoming aware	Privacy Officer + CCO
SEC Reg S-P §248.30(a)(5) service-provider notice	Service-provider unauthorized-access incident	72 hours from notice receipt	Privacy Officer
FINRA Rule 4530(a)	Reportable event under (a)(1)–(a)(7)	30 calendar days from knowledge	CCO via Firm Gateway
FINRA Rule 4530(d) quarterly statistical	Customer complaints quarterly aggregation	15 calendar days after end of calendar quarter	CCO
FTC Safeguards Rule 16 CFR 314.4(j)	Notification event ≥ 500 consumers	As soon as possible, not later than 30 days after discovery	Privacy Officer
State breach notification (NY GBL 899-aa, CA CCPA, MA 201 CMR 17, etc.)	State-specific trigger	Varies by state	Privacy Officer + General Counsel
CISA CIRCIA (when rule effective)	"Covered cyber incident"	72 hours (covered incident) / 24 hours (ransom payment)	CISO + General Counsel
NCUA 12 CFR 748.1(c) (CU-affiliated)	Catastrophic act / cyber incident	Per Part 748 schedule	CCO

1.3 Reconciliation logic and signing

For every open incident in sovereign tenants:

1. Update the register row at every state transition (detection → triage → containment → eradication → recovery → close-out).
2. Update the matrix at every checkpoint where a clock might start, advance, or close.
3. Dual-sign the closed register row and matrix (Incident Commander + CCO).
4. Render to PDF with the incident ID, tenant ID, sovereign-cloud flag, and signature block in the header.
5. Store in the Purview evidence library with retention label = 6 years WORM to help meet SEC 17a-4(f) recordkeeping expectations.

Examiner Evidence Box — Sovereign manual artifacts

Capture for every incident:

1. The dual-signed register row PDF (one PDF per incident).
2. The dual-signed notification matrix PDF.
3. CSV export of the register filtered to the calendar quarter.
4. Hash (SHA-256) of every PDF and CSV with timestamps.
5. Purview evidence-library URL and retention-label confirmation screenshot.
6. ITSM ticket ID and linked change record.

1.4 Commercial / GCC tenants

Commercial and GCC tenants with full Defender XDR and IRM parity execute §1.1 / §1.2 as a defense-in-depth quarterly reconciliation rather than as the primary artifact — confirm that every Defender XDR Sev-1 / Sev-2 incident from the quarter has a matching register row and matrix. Discrepancies are findings against Control 3.4 effectiveness and must be documented with root cause.

Cross-Reference

Sovereign-cloud connector parity is owned by Control 3.9. If a connector is unavailable in your sovereign cloud, route the corresponding manual reconciliation step here in §1; do not modify the §2–§9 procedures, which assume commercial / GCC parity.

2. Defender XDR — Unified Incidents Queue

The Microsoft Defender XDR Unified Incidents queue is the primary triage surface for Control 3.4 in commercial and GCC tenants. It correlates alerts across Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Defender for Cloud, and (where ingested) Microsoft Sentinel. For AI-agent incidents, ATT&CK + ATLAS dual-tagging makes Defender XDR the canonical "single pane" the SOC works from.

2.1 Navigation

1. Sign in to the Microsoft Defender portal at https://security.microsoft.com with a SOC role activated (SOC Analyst at minimum; Incident Commander for status changes).
2. In the left nav, expand Investigation & response → Incidents & alerts → Incidents.
3. The default view is Open incidents — last 7 days. Adjust the time window using the filter bar.

2.2 Triage UX — column set, filters, and row actions

Configure the incident queue once per analyst workstation; the column set and saved filter are evidence artifacts in their own right.

1. Click Customize columns (top-right). Required columns for FSI Control 3.4 use:
   • Incident name
   • Tags (must include Copilot, AgentId:*, Zone:*, NPI, BooksAndRecords where applicable)
   • Severity
   • Investigation state
   • Status (New / In progress / Resolved)
   • Assigned to
   • Categories
   • Impacted assets (devices, mailboxes, users, apps, and AI agents where the agent surface area is recognized)
   • Active alerts
   • Service sources (which Defender workloads contributed)
   • Detection sources
   • Data sensitivity (sensitivity-label coverage from Purview Information Protection — cross-ref Control 1.5)
   • First activity / Last activity
   • MITRE ATT&CK techniques
2. Click Filters → + Add filter and create the saved filter "FSI — Copilot / Agent Triage" with:
   • Tags contains Copilot OR AgentId:
   • Severity in (High, Medium)
   • Status in (New, In progress)
3. Save the filter and pin it to the queue header.

2.3 FSI severity rubric — beyond the Defender default

Defender XDR's default Sev (Informational / Low / Medium / High) is necessary but not sufficient for FSI Control 3.4. Apply the following overlay during triage; the resulting severity is what enters the §1 register and drives the §9 timer flows.

FSI Sev	Defender mapping	Triggers (any one is sufficient)	Clock-starting potential
Sev-1 (Critical)	High + escalation	NPI of ≥ 500 consumers reasonably likely accessed; supervisory-system failure for customer-facing Copilot; public-disclosure threshold met (8-K materiality candidate); active extortion demand; books-and-records integrity breached	All FSI clocks must be evaluated; CCO + GC + CISO immediate notify
Sev-2 (High)	High	NPI < 500 but > 0; Copilot agent acting on stale / poisoned context affecting external-facing communications; orphaned Z3 agent with active sessions; identity compromise of Sentinel / Defender / Power Platform Admin	NYDFS 500.17, Reg S-P, FINRA 4530(a) candidate; CCO notify within 4 h
Sev-3 (Medium)	Medium	Internal-only impact; Z2 agent misuse caught in IRM; supervisory escalation in Communication Compliance with no external send; failed but contained credential phishing	Internal SLA only; quarterly aggregation under 4530(d) candidate
Sev-4 (Low / Informational)	Low / Informational	Single-user Z1 incident; tabletop-style false positive; signal correlation only	Internal record; no regulator clock

The rubric is applied by the Incident Commander, with input from the SOC Analyst (technical severity), AI Governance Lead (agent-specific severity), Privacy Officer (NPI count), and CCO (regulator-clock potential). Document the application in the incident worksheet — examiners frequently ask why a particular incident was assigned a particular severity.

Rubric overrides require documented justification

A mismatch between the Defender XDR default severity and the FSI Sev assigned by the Incident Commander is permissible but must be justified in writing. The justification is captured in the incident worksheet (§1.1 row), in the Defender XDR incident comment (§2.6), and in the Sentinel incident comment (§3.4).

2.4 MITRE ATT&CK + MITRE ATLAS dual tagging

Defender XDR auto-tags incidents with MITRE ATT&CK techniques where the underlying alert engine produced a mapping. MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is not auto-tagged — Control 3.4 requires the AI Governance Lead to manually overlay ATLAS technique IDs for any incident involving a Copilot or Power Platform agent.

1. From the incident summary blade, scroll to the Attack story pane and click MITRE techniques.
2. Verify the auto-mapped ATT&CK techniques. Add or correct techniques via + Add technique if the mapping is incomplete.

3. Open the Comments and history tab and add an ATLAS overlay comment in the structured form below:

   ATLAS-OVERLAY v1
   Incident: <INC-ID>
   Agent involved: <AgentId>
   Zone: <Z1|Z2|Z3>
   Techniques:
     - AML.T0051 (LLM Prompt Injection)
     - AML.T0048 (External Harms)
     - AML.T0057 (LLM Data Leakage)
   Justification: <free text — link to evidence>
   Reviewed by: <AI Governance Lead UPN>
   Reviewed at (UTC): <ISO timestamp>
   

4. Re-save the incident; the comment is immutable in the audit trail.

2.5 Multi-source correlation review

Before assigning the incident to an analyst, walk the Attack story and Assets tabs to confirm that all expected sources contributed:

Expected source	What to verify
Defender for Endpoint	Process tree for any device-side maker / agent-runtime activity; suspicious child processes of Office, browser, or Power Platform host
Defender for Office 365	Mail-flow telemetry for any Copilot-generated outbound email; URL detonation hits
Defender for Identity	Lateral movement, golden-ticket-style anomalies near service-principal accounts
Defender for Cloud Apps	Anomalous OAuth grant to a Copilot Studio agent; data-exfiltration signal to unsanctioned cloud apps
Defender for Cloud	Azure resource-side activity for any Sentinel / Logic App / Power Platform connector
Microsoft Sentinel (where bidirectionally synced)	Custom KQL detections, watchlist hits, threat-intel matches
Microsoft Purview Information Protection	Sensitivity-label drift, downgrade events, label-removal anomalies

Any missing source (e.g., Defender for Cloud Apps shows no activity for an obviously cloud-active incident) is a data-integrity finding in its own right — open a sub-task to Control 3.9 and document on the worksheet. Do not silently proceed.

2.6 Assignment, status, and incident comments

1. Click Manage incident (top-right of the incident detail blade).
2. Set:
   • Incident name — prepend the firm incident ID (e.g., INC-FSI-2026-0042 — Copilot prompt-injection — sales BU).
   • Tags — confirm Copilot, AgentId:<id>, Zone:<n>, and any of NPI, BooksAndRecords, Supervisory, 8K-Candidate as applicable.
   • Assigned to — name the SOC Analyst at L2 minimum; the Incident Commander remains accountable.
   • Severity — set to the FSI Sev per §2.3 (override the default if needed).
   • Status — In progress once triage starts; Resolved only at full close-out (do not resolve before the §1 register is closed and the §9 timers are stopped).
   • Classification / Determination — leave open until close-out; on close set to True positive with a determination matching the root cause.
3. Click Save.

4. Add an opening comment in the Comments and history tab using the structured template below:

   OPEN-COMMENT v1
   Incident: <INC-ID>
   Detection T0 (UTC): <ISO timestamp>
   Triage T1 (UTC): <ISO timestamp>
   FSI Sev: <Sev-1|Sev-2|Sev-3|Sev-4>
   Sev rubric trigger(s): <NPI|BooksAndRecords|Supervisory|PublicDisclosure|Other>
   Materiality candidate (8-K): <Yes|No|TBD>
   Regulator clocks placed on standby:
     - NYDFS 500.17(a) 72h: <Yes|No>
     - Banking 36h:         <Yes|No>
     - SEC 8-K 4bd:         <Yes|No>
     - Reg S-P 30d:         <Yes|No>
     - FTC 30d:             <Yes|No>
     - FINRA 4530(a) 30d:   <Yes|No>
     - State BNs:           <Yes|No>
   Assigned analyst: <UPN>
   Incident Commander: <UPN>
   CCO standby notified at (UTC): <ISO timestamp>
   GC standby notified at (UTC): <ISO timestamp>
   Linked SharePoint case: <URI>
   Linked legal hold (if any): <Hold ID>
   

5. Subsequent state changes (containment achieved, eradication confirmed, recovery validated) must each receive a STATE-COMMENT follow-up using the same structure.

2.7 Linking to Microsoft Sentinel

If Sentinel is bidirectionally synced (recommended; see Control 3.9), Defender XDR incidents flow into Sentinel automatically with a back-link. Confirm the Microsoft Sentinel incident link appears in the Defender XDR incident summary header — clicking it opens the Sentinel incident in a new tab. If the link is missing, the bidirectional sync has degraded; open a Control 3.9 sub-task before continuing.

2.8 Bulk export for evidence

From the incidents queue:

1. Click Export (top-right) and choose CSV.
2. Rename to defender-incidents_<tenantId>_<incidentId>_<ISO-date>.csv.
3. Hash (SHA-256) and store both the CSV and the hash in the Purview evidence library tagged Control=3.4, Incident=.
4. Capture full-page screenshots of the queue (with the FSI saved filter applied) and the incident detail blade.

Examiner Evidence Box — Defender XDR triage

Capture for every incident:

1. Queue-state screenshot at incident open with the FSI saved filter applied.
2. Incident detail blade screenshot (Attack story, Assets, MITRE techniques tabs).
3. ATLAS overlay comment text (copy-paste from the audit trail).
4. Manage-incident screenshot showing FSI Sev, tags, and assignment.
5. Open-comment text and every subsequent state-comment.
6. CSV export hash and storage URI.

Cross-Reference

Detection content (analytic rules, hunting queries, custom Defender XDR detections) is configured under Control 1.8 and Control 3.9. Do not author new detections from this walkthrough — route detection-engineering changes through 3.9 and the firm's detection-as-code pipeline.

3. Microsoft Sentinel — Incidents and SOAR (Logic Apps) Playbooks

Microsoft Sentinel extends Defender XDR triage with automation rules, Logic Apps playbooks (SOAR), investigation graph, and long-window hunting. Control 3.4 uses Sentinel as the orchestration spine that fans incidents out to Power Automate notification flows (§9), Teams adaptive card escalations, SharePoint IR list updates (§8), and ITSM ticketing.

Connector configuration, workspace sizing, and analytic-rule authoring are out of scope for this walkthrough — see Control 3.9. The procedures below assume the workspace is healthy and bidirectional Defender XDR sync is on.

3.1 Navigation

1. Sign in to the Azure portal at https://portal.azure.com with Sentinel Admin activated (or SOC Analyst for read-only triage).
2. Search for Microsoft Sentinel and select the workspace named per the firm's naming convention (e.g., sent-fsi-prod-eastus2).
3. In the workspace blade, select Threat management → Incidents.

3.2 Reviewing the synced incident

For an incident that originated in Defender XDR (§2):

1. Locate the incident by Defender XDR incident ID or by the FSI tag set (Copilot, AgentId:<id>, Zone:<n>).
2. Click the incident to open the detail pane on the right.
3. Confirm the Provider name = Microsoft 365 Defender and the back-link to Defender XDR is present.
4. Click View full details to open the full incident page.

The Sentinel incident page exposes panes the Defender XDR view does not:

• Investigation graph — interactive graph of entities (users, hosts, IPs, files, AI agents via custom entity mapping) and their relationships.
• Bookmarks — analyst-flagged hunting query results pinned to the incident as evidence.
• Workbook deep-links — navigation to the workbook visualizations defined in Control 3.9.
• Activity log — every state and assignment change with timestamps, the audit-friendly view examiners look at.

3.3 Custom AI-agent entity in the investigation graph

Where the workspace has the optional AI Agent custom entity mapping configured (per Control 3.9 §6), the investigation graph displays the agent as a first-class node alongside users and devices. Confirm:

1. The agent node displays the canonical AgentId (matching the Control 1.2 registry).
2. Edges to user nodes represent identity relationships (owner, sponsor, maker, recent invokers).
3. Edges to data nodes represent connector-grounded data sources accessed in the incident window.
4. Hovering on the agent node reveals the Zone, sensitivity-label coverage, and last attestation date.

If any of those properties is missing, the agent inventory feed is stale — open a Control 3.9 sub-task.

3.4 Adding the incident comment with the Sentinel-side overlay

Sentinel comments are independent of Defender XDR comments and form a separate evidence trail. Add the following at incident open:

1. From the incident detail page, click Comments → + New comment.

2. Paste the structured template:

   SENTINEL-OPEN v1
   Incident (Sentinel): <Sentinel ID>
   Linked Defender XDR: <Defender XDR ID>
   Linked SharePoint case: <URI>
   Hunting bookmarks attached: <count>
   Workbook visualizations reviewed: <list>
   Custom AI Agent entity present: <Yes|No>
   Automation rules pending: <list of rule names>
   Playbook(s) pending invocation: <list>
   

3. Click Comment to save.

3.5 Automation rules — wiring incidents to playbooks

Sentinel automation rules are the trigger glue between incidents and Logic Apps playbooks. Control 3.4 expects the following rules to be already configured by the Sentinel Admin under Control 3.9. The procedure below verifies they are present and triggers a manual playbook run if needed.

Automation rule	Trigger	Action	Owner
AR-FSI-OpenIncident-Notify	When incident is created with tag Copilot or AgentId:	Run playbook PB-Notify-CISO-CCO-GC-Standby	Sentinel Admin
AR-FSI-Sev1-Escalate	When incident severity changes to High AND tag includes 8K-Candidate	Run playbook PB-Convene-Disclosure-Committee	Sentinel Admin
AR-FSI-NYDFS-72h-Standby	When tag NYDFS-Reportable added	Run playbook PB-Start-NYDFS-72h-Timer	Sentinel Admin
AR-FSI-Banking-36h-Standby	When tag Banking-Notification added	Run playbook PB-Start-Banking-36h-Timer	Sentinel Admin
AR-FSI-RegSP-30d-Standby	When tag RegSP-Customer-Notice added	Run playbook PB-Start-RegSP-30d-Timer	Sentinel Admin
AR-FSI-FINRA-4530a-Standby	When tag FINRA-4530a added	Run playbook PB-Start-FINRA-4530a-30d-Timer	Sentinel Admin
AR-FSI-FTC-30d-Standby	When tag FTC-Safeguards-Notice added	Run playbook PB-Start-FTC-30d-Timer	Sentinel Admin
AR-FSI-Containment-Verify	When status changes to In progress AND tag Containment-Achieved added	Run playbook PB-Update-SharePoint-IR-List	Sentinel Admin
AR-FSI-Close-Out	When status changes to Closed AND tag RootCause-Approved added	Run playbook PB-Close-Out-Notify	Sentinel Admin

Verify each rule is Enabled at Sentinel → Configuration → Automation → Active rules. A disabled rule is a finding; document on the worksheet and re-enable through the Control 3.9 change process.

3.6 Manually invoking a playbook

If a playbook needs to run before a tag-driven trigger fires (e.g., the analyst already knows the incident is NYDFS-reportable but the tag has not yet been applied):

1. From the incident detail page, click Actions → Run playbook (Preview).
2. In the playbook picker, search by name (e.g., PB-Start-NYDFS-72h-Timer).
3. Confirm the playbook's Permissions status = Permission granted for this Sentinel workspace; if not, the workspace's managed identity lacks the run-playbook role and must be remediated by the Sentinel Admin.
4. Click Run.
5. Confirm the run appears under Runs for the playbook with status Succeeded.

3.7 Reviewing playbook run logs

For each playbook invoked during an incident, capture the run log as evidence:

1. Navigate to Sentinel → Configuration → Automation → Active playbooks.
2. Select the playbook by name.
3. Click Open in Logic Apps to open the underlying Logic App in the Azure portal.
4. In the Logic App blade, click Runs history.
5. Filter by the incident time window, identify the relevant run, and click into it to view the per-action log.
6. Export the run JSON via ... → Download run JSON (or screenshot each action's input / output for evidence).
7. Store the JSON / screenshots in the Purview evidence library tagged Control=3.4, Incident=, Playbook=.

Logic App secrets in run logs

Playbook run logs may contain secrets in plain text (API keys, OAuth tokens, customer identifiers) if the Logic App was authored without secure inputs / outputs flags. Before exporting, confirm with the Sentinel Admin that the playbook's actions are configured with Secure Inputs and Secure Outputs turned on for any action that handles secrets. If a run log contains exposed secrets, the export itself becomes a data-handling event — route to General Counsel and consider an immediate secret-rotation action.

3.8 Hunting and bookmarks

For complex incidents, the SOC Analyst will run KQL hunting queries (defined in Control 3.9). Pin notable results to the incident as bookmarks:

1. From Threat management → Hunting, run the relevant query.
2. In the results pane, select the rows of interest.
3. Click Add bookmark.
4. In the Add bookmark dialog, enter:
   • Bookmark name — descriptive (e.g., INC-FSI-2026-0042 — Copilot prompt-injection — anomalous prompts).
   • Tags — incident ID and tag set.
   • Mapped entities — confirm the auto-mapped entities (account, host, IP, agent) are correct.
   • Incident — select the open incident to attach the bookmark to.
5. Click Save.
6. Confirm the bookmark appears under the incident's Bookmarks pane.

3.9 Closing the Sentinel incident

Sentinel close-out lags Defender XDR close-out by design — close Sentinel only after the §9 timers have either reached their statutory determination point or been documented as not applicable, and the §1 register row is signed.

1. From the incident detail page, click Manage → Status → Closed.
2. Set Classification → True Positive (or the applicable determination).

3. Add a closing comment with the structured template:

   SENTINEL-CLOSE v1
   Incident (Sentinel): <Sentinel ID>
   Linked Defender XDR: <Defender XDR ID>
   Root cause statement: <free text — link to RCA document URI>
   Root cause timestamp (UTC): <ISO>
   Notification timers — closed status:
     - NYDFS 500.17(a) 72h: <Filed at UTC | Not applicable, justification>
     - Banking 36h:         <Filed at UTC | Not applicable, justification>
     - SEC 8-K 4bd:         <Filed at UTC | Not applicable, justification>
     - Reg S-P 30d:         <Filed at UTC | Not applicable, justification>
     - FTC 30d:             <Filed at UTC | Not applicable, justification>
     - FINRA 4530(a) 30d:   <Filed at UTC | Not applicable, justification>
     - State BNs:           <Per state — list>
   Legal hold status: <Open | Released at UTC>
   Insider Risk case status: <Open | Closed | N/A>
   Communication Compliance escalations: <count, dispositions>
   SharePoint case URI: <URI>
   Disclosure Committee memo URI (if 8-K): <URI>
   Tabletop scenario applicable for next quarter: <Yes|No>
   Signed off by Incident Commander (UPN): <UPN at UTC>
   Signed off by CCO (UPN): <UPN at UTC>
   Signed off by GC (UPN): <UPN at UTC>
   

4. Click Apply.

Examiner Evidence Box — Sentinel orchestration

Capture for every incident:

1. Sentinel incident screenshot at open (full details page).
2. Investigation graph screenshot showing the AI agent custom entity (where present).
3. Open-comment and close-comment text.
4. List of automation rules that fired (with Logic App run IDs).
5. Playbook run JSONs (or per-action screenshots) for every invocation.
6. Bookmarks (if any) with their KQL query text and result snapshots.

Cross-Reference

Workspace health, ingestion baselines, KQL detection authoring, and playbook authoring are owned by Control 3.9. If a playbook is missing or fails repeatedly, route through 3.9; do not modify Logic App definitions from this walkthrough.

4. Microsoft Purview Insider Risk Management — Cases

Where the incident involves AI-agent misuse by an insider, anomalous prompt behavior that suggests an authorized user is exfiltrating data via a Copilot agent, or runaway agent behavior on stale context, Purview Insider Risk Management (IRM) is the investigation surface. IRM enforces a pseudonymized review workflow (default-on for the analyst role) and provides clean escalation paths into eDiscovery (Premium) for legal hold and regulator-production export.

Policy authoring (the upstream content for IRM alerts and cases) is owned by Control 1.12. Control 3.4 consumes IRM cases at the case-management blade level only.

4.1 Navigation

1. Sign in to the Microsoft Purview portal at https://purview.microsoft.com with Insider Risk Management Investigators or Insider Risk Management Analysts activated (the role determines whether usernames are pseudonymized in the UI).
2. From the left nav, expand Solutions → Insider risk management.
3. Select Cases in the secondary nav.

4.2 Pseudonymization — confirm before you click

IRM defaults to pseudonymized usernames for analyst-role users; investigator-role users see real UPNs. Confirm before opening any case:

1. Click the user-account dropdown (top-right) and select Account → Roles to confirm your active IRM role.
2. If you see real UPNs in the case list and your role is Analyst, the tenant has likely been configured with Privacy → Show usernames = On, which is a policy drift finding under Control 1.12 — open a sub-task before continuing.
3. Pseudonymized cases display synthetic identifiers (e.g., Anon_8a3f); the investigator role can resolve to real identities through a documented unmask flow that itself produces an audit record.

Unmask events are auditable

Resolving a pseudonymized identifier to a real UPN creates an audit record in Purview (Activity = IRMUnmask). Examiners may sample these records to confirm unmask was justified; capture the case ID and justification at every unmask.

4.3 Opening a case from an alert

When a Defender XDR / Sentinel incident is correlated with an IRM alert (e.g., the same impacted user appears in a Data leaks via Copilot policy alert):

1. From Insider risk management → Alerts, locate the alert by user identifier, severity, and date.
2. Confirm the Policy that fired matches an AI-agent-misuse policy template — typical templates configured under Control 1.12 include:
   • Data exfiltration via agent (Copilot Studio agent invoked unusual sensitive-content searches and exported)
   • Anomalous prompt behavior (sudden volume / pattern shift in Copilot prompts)
   • Sensitive-data interaction by departing user via Copilot (HR-leaver list correlated with Copilot activity in the 30-day window)
   • Agent acting on stale / poisoned context (anomalous grounding source diversity within an agent session)
3. Click Actions → Confirm alert and create case.
4. In the Create case dialog, enter:
   • Case name — prepend the firm incident ID (e.g., INC-FSI-2026-0042 — IRM — anon_8a3f — Copilot exfiltration).
   • Case description — link to the Defender XDR and Sentinel incident IDs and the SharePoint case URI.
   • Assigned to — name the Insider Risk Investigator (typically a CCO-designated investigator).
5. Click Create case.

4.4 Case workspace — Activity, Content explorer, User activity, Alerts

The case workspace exposes four primary tabs. Walk each in order:

1. Case overview — confirms severity, score, policy, and assignee. Add a structured comment via Activity timeline → Add note:

   IRM-OPEN v1
   Case: <Case ID>
   Linked incident: <INC-ID>
   Linked Defender XDR: <Defender XDR ID>
   Linked Sentinel: <Sentinel ID>
   Policy(ies) triggered: <list>
   Investigator: <UPN>
   Pseudonymization: <On|Off — investigator-role only>
   Linked legal hold (planned/issued): <Hold ID|Pending>
   

2. Alerts — every IRM alert correlated with this user / case. Cross-reference each alert against the §1 register row.

3. User activity — timeline of risk indicators (file downloads, label downgrades, USB use, Copilot prompt anomalies, etc.). Use the Filter pane to narrow to the incident window.
4. Content explorer — preview of the actual content involved (where the user role permits content view). Treat content view as a legal-hold-relevant action — confirm a hold is in place (see §5) before previewing sensitive content.

4.5 AI-agent-misuse case — required steps

For any case tagged as AI-agent-related, perform these additional steps:

1. From User activity → Filters, confirm the Application filter includes Microsoft Copilot, Copilot Studio, Power Apps, Power Automate, and Microsoft 365 Apps with Copilot. Without these filters, agent-specific signals will not surface.
2. Cross-reference the AgentId from the Defender XDR / Sentinel tags against the agent registry (Control 1.2) and confirm the registered owner / sponsor / maker UPNs map (after unmask) to the case subject. If they do not map, the case may be an unauthorized invocation rather than authorized-user misuse — escalate to the AI Governance Lead and consider a separate Defender XDR incident for the unauthorized-invocation thread.
3. Where prompt content is needed for the investigation, request it through eDiscovery (Premium) per §5; do not attempt to extract prompts from IRM Content explorer alone.

4.6 Escalation to eDiscovery (Premium)

When the case warrants legal hold and / or regulator-production export:

1. From the case workspace, click Actions → Escalate for investigation → Create eDiscovery (Premium) case.
2. In the Escalate dialog, enter:
   • eDiscovery case name — prepend the firm incident ID (e.g., INC-FSI-2026-0042 — eDiscovery — Copilot exfiltration).
   • Custodians — pre-populate from the IRM case subject (after unmask, via the documented unmask flow). Add the agent service principal as a custodian where the agent itself is a content source.
   • Scope — Exchange mailbox, OneDrive site, Teams chat, and SharePoint sites associated with the user; and Copilot interaction history (chat history container) for the in-scope user.
3. Confirm the Notify toggle is set to On so a hold notice is generated automatically — General Counsel reviews and releases the notice (§5.4) before it is sent.
4. Click Escalate.
5. Confirm the new eDiscovery (Premium) case appears with Status = Active and the IRM case shows the back-link.

4.7 Case close-out

1. From the case workspace, click Actions → Resolve case.
2. Enter the Resolution (e.g., Substantiated — supervisory action taken, Substantiated — referred to HR, Unsubstantiated — false positive, Substantiated — referred to law enforcement).

3. Add a closing note with the structured template:

   IRM-CLOSE v1
   Case: <Case ID>
   Linked incident: <INC-ID>
   Resolution: <enum from above>
   Resolution rationale: <free text — link to evidence>
   Linked eDiscovery case: <eDisco case ID|N/A>
   Linked legal hold: <Hold ID|Released at UTC|N/A>
   Supervisory escalation (Control 2.12): <Yes|No — if Yes, FINRA 3110 reviewer UPN and reviewed-at UTC>
   Closed by: <Investigator UPN at UTC>
   Reviewed by (CCO designee): <UPN at UTC>
   

4. Click Resolve.

Examiner Evidence Box — IRM case

Capture for every IRM-correlated incident:

1. Case overview screenshot at open and at close.
2. Open-note and close-note text.
3. Pseudonymization confirmation screenshot (analyst-role) or unmask audit record reference (investigator-role).
4. List of policies triggered with template versions.
5. eDiscovery (Premium) case ID and back-link confirmation (where escalated).
6. Resolution rationale and reviewer record.

Cross-Reference

AI-agent-misuse policy templates and tuning (false-positive analysis, indicator weights) are owned by Control 1.12. Recurring false positives observed in case work must be routed back to 1.12 for tuning; do not edit policy from this walkthrough.

5. Microsoft Purview eDiscovery (Premium) — Legal Hold and Regulator-Production Export

eDiscovery (Premium) is the surface where Control 3.4 issues legal holds, manages custodian preservation, captures hold-notice acknowledgments, and prepares regulator-production exports. The General Counsel (or designee) is the named owner of every hold; the Purview Compliance Admin executes the operational steps below.

5.1 Navigation

1. Sign in to the Microsoft Purview portal at https://purview.microsoft.com with eDiscovery Manager activated.
2. From the left nav, expand Solutions → eDiscovery → Premium.
3. Confirm the case from §4.6 (or create a new case if the hold is not IRM-originated — proceed to §5.2).

5.2 Creating an eDiscovery (Premium) case directly

For incidents that do not route through IRM (e.g., a Defender XDR-only correlated incident with an immediate hold need):

1. Click + Create a case.
2. Enter:
   • Case name — prepend the firm incident ID.
   • Case description — link to the Defender XDR and Sentinel incident IDs.
   • Case format — New case format (recommended; legacy classic eDiscovery is being retired).
3. Click Save.
4. Confirm the case appears in the cases list with Status = Active and Owner = .

5.3 Adding custodians and creating a legal hold

1. Inside the case, navigate to Data sources → + Add data sources → Add new custodians.
2. For each custodian:
   • Enter the UPN (or pick from the directory).
   • Confirm the auto-included data sources — Exchange mailbox, OneDrive site, Teams chat (1:1 and group). Add SharePoint sites and Teams team mailboxes explicitly where relevant.
   • For AI-agent incidents, additionally include the Copilot interaction history container (where surfaced) and the agent's Copilot Studio environment as a SharePoint site reference.
3. Click Next, review the data sources summary, and click Submit.
4. Navigate to Holds → + Create.
5. In the Create hold wizard:
   • Name and description — prepend the firm incident ID; description must reference the legal-hold notice ID issued by General Counsel.
   • Choose data sources — select the custodian set added above.
   • Conditions — leave blank for an unconditional hold (default; recommended for active incidents). Add date range or keyword conditions only if explicitly directed by General Counsel.
   • Review and create — confirm and click Submit.
6. Confirm the hold appears with Status = On and Hold start time populated.

Hold scope vs. retention scope

A hold created here preserves content for the duration of the hold and overrides any retention-policy deletion within scope. It does not create new retention obligations on its own — books-and-records retention is owned by Control 1.9. Confirm with General Counsel that the hold scope satisfies the litigation / regulator preservation expectation for this incident — examiners may probe scope choices.

5.4 Hold-notice acknowledgments

1. Navigate to Communications → + Create communication.
2. In the wizard:
   • Name and description — <INC-ID> — Legal Hold Notice — <Date>.
   • Communication template — select the firm-approved hold-notice template (configured in advance by General Counsel; if missing, route to General Counsel before proceeding).
   • Recipients — auto-populated from the custodian list.
   • Issuance, re-issuance, release notices — keep all three turned On so the system tracks acknowledgment, periodic re-issuance, and release.
   • Acknowledgment required — On. The custodian must acknowledge within the hold-notice deadline (typically 5 business days).
3. Click Send.
4. Track acknowledgment status under Communications → → Recipients. Non-acknowledgment after the deadline is a finding: route to General Counsel for follow-up; document the follow-up in the §1 register row.

5.5 Searches and review sets

For regulator-production preparation:

1. Navigate to Searches → + New search.
2. Configure the search query — KQL-style; typical queries:
   • For Reg S-P consumer notice: (c:c)(date>=YYYY-MM-DD)(date<=YYYY-MM-DD)(participants:"<custodian>")
   • For Copilot interaction history: include the Copilot interaction history scope and filter on the agent ID via metadata where supported.
3. Run the search; review statistics (item counts by location).
4. Click Actions → Add to review set → name the review set with the incident ID.
5. In the review set, apply review-set queries to triage to a producible set; tag responsive items with Tag → Responsive and privileged items with Tag → Privileged — Withhold (subject to General Counsel review).

5.6 Regulator-production export

1. From the review set, click Action → Export.
2. In the Export wizard:
   • Export name — <INC-ID> — <Regulator> — <Date>.
   • Export options — choose the production format the regulator requires (typically PDF + native + load file for SEC / FINRA productions; CSV summary for state AG productions).
   • Include — select Tagged as Responsive; exclude Tagged as Privileged.
   • Conditional access — leave defaults unless General Counsel directs otherwise.
3. Click Export.
4. Once the export job completes, download the export package via Exports → → Download package.
5. Hash the package (SHA-256), store the hash in the §1 register row, and transfer the package to the regulator-production secure-transfer location per the firm's regulator-production procedure (out of scope here).

5.7 Hold release

When the matter closes (incident closed AND no litigation pending AND General Counsel approves release):

1. Navigate to Holds → → Manage hold.
2. Toggle Status = Off.
3. Confirm a Release communication is sent to custodians (auto-generated if §5.4 was configured with Release notice = On).
4. Document hold-release in the §1 register row with the release timestamp and General Counsel UPN.

Examiner Evidence Box — eDiscovery (Premium)

Capture for every incident with a hold:

1. Case-creation screenshot.
2. Custodian list (CSV export from Data sources).
3. Hold-creation screenshot with Status = On and start time.
4. Hold-notice text and acknowledgment status export.
5. Search query text and statistics screenshot.
6. Review-set tag distribution screenshot.
7. Export-package SHA-256 hash and transfer-receipt confirmation.
8. Hold-release confirmation (where applicable) with General Counsel approval reference.

Cross-Reference

Audit-log retention sufficient to support eDiscovery searches is owned by Control 1.7; retention labels on Copilot interaction history are owned by Control 1.9. If a search returns zero results when results are expected, the issue is likely upstream in 1.7 / 1.9 rather than in eDiscovery.

6. Microsoft Purview Communication Compliance — Copilot Supervisory Escalation

Communication Compliance is the surface where Control 3.4 inherits supervisory escalations of Copilot-generated content that violates customer-communication policies. Examples include Copilot drafting an outbound email containing an unapproved performance projection, a non-compliant fee description, or a customer disclosure phrased outside the firm's compliance dictionary.

Policy authoring (the Communication Compliance scopes that include Copilot-generated content) and supervisory program design are owned by Control 2.12. Control 3.4 consumes Communication Compliance escalations at the alerts blade level only.

6.1 Navigation

1. Sign in to the Microsoft Purview portal at https://purview.microsoft.com with Communication Compliance Investigators activated.
2. From the left nav, expand Solutions → Communication compliance.
3. Select Policies → to confirm the policy that fired (cross-ref Control 2.12 for the configuration).
4. Select Alerts to review.

6.2 Reviewing a Copilot-content alert

1. Filter alerts by Policy = and Status = Pending.
2. Click into an alert to open the alert detail blade.
3. Confirm the Source is identified as Copilot-generated (where the policy includes the Copilot generated content condition; if the source is not identified, the policy may need tuning under Control 2.12).
4. Review the Message content with the analyst's pseudonymization defaults applied (same model as IRM §4.2).
5. If the content was sent externally (email departed the tenant), this is a higher-severity incident that may trigger Reg S-P customer notice (if NPI was disclosed) and / or FINRA 4530(d) customer-complaint statistical aggregation (if a complaint follows). Cross-reference into the §1 register row.

6.3 Disposition and escalation

For each alert, choose one of:

Disposition	Effect	Documentation requirement
Resolve	Alert closed; no further action	Reviewer note required
Notify the user	Auto-notification sent to the user	Reviewer note + retained notice text
Tag and notify	Custom tag applied + notification sent	Reviewer note + tag rationale
Escalate	Alert escalated to a designated escalator (typically the Designated Series 24/66 Principal)	Reviewer note + escalation reason
Escalate for investigation	Creates an Advanced eDiscovery case (parallel to §5)	Reviewer note + IRM / eDiscovery linkage
Remove message (where supported)	Soft-delete from the recipient mailbox	Reviewer note + General Counsel concurrence

For Control 3.4 active incidents, the typical disposition is Escalate for investigation with a back-link to the §1 register row.

6.4 Supervisory close-out by Designated Principal

Communication Compliance escalations involving registered persons require sign-off by the Designated Series 24/66 Principal (or applicable principal series for the line of business — Series 9/10, 26, 51, 53):

1. The escalator (typically the Communication Compliance Investigator) routes the escalation to the principal via Teams adaptive card (auto-generated by the §9 Power Automate flow PB-Escalate-To-Series24) or directly via the Purview UI.

2. The principal reviews the message, the user history, and the disposition options, then records the supervisory determination using a structured comment:

   SERIES24-REVIEW v1
   Alert: <Alert ID>
   Linked incident: <INC-ID>
   Reviewer (Series 24/66): <UPN>
   Determination: <Approved as sent | Required correction | Required clawback | Referred to HR | Referred to Compliance>
   Rationale: <free text>
   Linked supervisory file URI (Control 2.12): <URI>
   Reviewed at (UTC): <ISO timestamp>
   

3. The disposition is captured in the alert audit trail and mirrored into the firm's books-and-records system (Control 1.7 / 1.9).

Examiner Evidence Box — Communication Compliance

Capture for every incident with a Copilot-content escalation:

1. Alert-list screenshot filtered to the Copilot-scoped policy in the incident window.
2. Alert-detail screenshot for each escalated alert.
3. Disposition record with reviewer UPN.
4. Series 24/66 principal review comment text.
5. Cross-reference URI to the Control 2.12 supervisory file.

Cross-Reference

Communication Compliance policies are authored under Control 2.12. DLP and sensitivity-label scopes that interact with Copilot content are owned by Control 1.5. Recurring false positives must be routed to 2.12 for tuning.

7. Microsoft 365 Service Health — Microsoft-Side Correlation Gate

Before declaring a firm-side root cause for any Sev-1 / Sev-2 incident — and especially before initiating any regulator notification clock — the Incident Commander must check Microsoft 365 Service Health for any concurrent Microsoft-side advisory or incident that could explain the observed behavior. A regulator notification triggered by what turns out to be a Microsoft outage that the firm did not investigate is itself a finding under FFIEC Information Security and BCM expectations.

7.1 Navigation

1. Sign in to the Microsoft 365 admin center at https://admin.microsoft.com with Service Support Administrator or M365 Admin activated (read-only is sufficient for the check; status updates require Service Support Administrator).
2. From the left nav, expand Health → Service health.
3. The default view is All services.

7.2 Filtering for relevant services

For an AI-agent incident, the relevant service set is:

• Microsoft 365 Apps (Word, Excel, PowerPoint with Copilot)
• Microsoft Copilot
• Microsoft Teams
• Microsoft Purview
• Microsoft Defender XDR
• Power Platform (Copilot Studio, Power Apps, Power Automate)
• Exchange Online
• SharePoint Online
• Microsoft Entra ID

Click each service row to view active Issues and Advisories.

7.3 Recording the check as evidence

For each in-scope service:

1. Capture a screenshot of the service-detail blade showing the "Issues" and "Advisories" count (zero or non-zero) and the last-updated timestamp.
2. If the count is non-zero, click into each issue / advisory and:
   • Record the issue ID (e.g., MO123456).
   • Record the title and summary.
   • Record the user impact statement.
   • Record the scope (whether the firm's tenant is in the impacted set).
3. If a Microsoft-side issue plausibly correlates with the firm-side observed behavior, pause the clock-starting decision and document the correlation hypothesis in the §1 register row's RootCauseStatement field as provisional. Do not initiate regulator notifications based on a Microsoft-side issue without first ruling it out as the proximate cause.
4. If no Microsoft-side correlation is found, capture a screenshot showing zero issues / advisories for the in-scope services as the negative-evidence artifact.

7.4 Service Health history

For incidents whose detection T0 is more than 7 days in the past, also check the Service Health → History tab for the relevant period — Microsoft archives advisories after resolution and the firm needs the historical view for retrospective root-cause analysis.

Examiner Evidence Box — Service Health correlation

Capture for every Sev-1 / Sev-2 incident:

1. Service Health all-services screenshot at incident T0+1h, T0+24h, and at root-cause-determination.
2. Per-service screenshots for each in-scope service.
3. For any non-zero issue / advisory: issue ID, title, summary, user impact, scope, and the firm's correlation determination.
4. Negative-evidence screenshot where applicable.

Do not skip the Service Health gate

A regulator notification filed for what turns out to be a Microsoft-side outage (without the firm having first investigated and ruled out the Microsoft-side cause) creates examiner risk under FFIEC IT Handbook expectations and may also create class-action plaintiff risk. The Service Health gate is a five-minute check — do not skip it.

8. SharePoint Incident Response List — Authoritative Firm Record

The SharePoint IR list is the firm's authoritative incident record outside the security tools. It is the reference of truth for the §1 manual register, the source for the §9 Power Automate notification flows, and the artifact most frequently requested by examiners as the single-pane view of an incident.

8.1 Site setup (one-time)

1. Sign in to the SharePoint admin center at https://-admin.sharepoint.com with SharePoint Administrator activated.
2. Navigate to Sites → Active sites → + Create → Team site (no group) (or use a pre-provisioned IR site if the firm template exists).
3. Configure the site:
   • Site name — IR — Incident Response Register (use a stable, well-known name).
   • Privacy — Private.
   • Sensitivity label — apply the Highly Confidential — Restricted label (Control 1.5).
   • Owners — CISO, CCO, General Counsel (group), AI Governance Lead.
   • Members — Incident Commanders, SOC Analysts, Sentinel Admins, Privacy Officer, Disclosure Committee chair.
4. Mark the site as legal-hold-aware by:
   • Applying a Purview retention label to the site that requires retention for the books-and-records minimum (typically 6 years from item creation; confirm with General Counsel).
   • Adding the site to the standing eDiscovery (Premium) preservation maintained for IR records.
5. Confirm versioning is enabled at the list level (default: 500 major versions).

8.2 List creation

1. From the IR site home, click + New → List → Blank list.
2. Name — Incidents.
3. Add columns per the schema below (use + Add column for each; column types in parentheses):

#	Column	Type	Required	Notes
1	IncidentID	Single line of text	Yes	Format INC-FSI-YYYY-NNNN; see §1.2
2	Title	Single line of text	Yes	Short, factual
3	Severity	Choice	Yes	Sev-1 / Sev-2 / Sev-3 / Sev-4
4	Status	Choice	Yes	New / Triage / Investigating / Containing / Eradicating / Recovering / Closed
5	DetectionUTC	Date and time	Yes	T0
6	DeclarationUTC	Date and time	No	Sev-elevation timestamp
7	ContainmentUTC	Date and time	No
8	EradicationUTC	Date and time	No
9	RecoveryUTC	Date and time	No
10	ClosureUTC	Date and time	No
11	MaterialityDeterminationUTC	Date and time	No	8-K Item 1.05 trigger; see §10
12	MaterialityOutcome	Choice	No	Material / Not Material / Not Yet Determined
13	IncidentCommander	Person	Yes
14	LegalLead	Person	Yes	General Counsel designee
15	ComplianceLead	Person	Yes	CCO designee
16	BCMLead	Person	No	Business Continuity Officer
17	DefenderXDRIncidentID	Single line of text	No
18	SentinelIncidentID	Single line of text	No
19	IRMCaseID	Single line of text	No
20	eDiscoveryCaseID	Single line of text	No
21	LegalHoldID	Single line of text	No
22	AffectedAgentIDs	Multiple lines of text	No	One agent per line
23	AffectedUserCount	Number	No	For Reg S-P scope sizing
24	NPIDisclosed	Choice	No	Yes / No / Unknown
25	RootCauseStatement	Multiple lines of text	No	Provisional → Final
26	RegulatorNotificationsRequired	Multiple lines of text	No	One per line; see §1.3
27	RegulatorNotificationsSent	Multiple lines of text	No	One per line; ISO timestamp + filer UPN
28	EvidencePackageURI	Hyperlink	No	SharePoint folder URI
29	EvidencePackageSHA256	Single line of text	No
30	OFACScreeningOutcome	Choice	No	Not Applicable / Cleared / Hit — Escalated

1. Configure views:
   • All Active — filter Status ≠ Closed; sort by Severity ascending then DetectionUTC ascending.
   • Reg-Notice Watchlist — filter RegulatorNotificationsRequired ≠ blank AND Status ≠ Closed; sort by oldest DetectionUTC first.
   • Disclosure-Committee Queue — filter MaterialityOutcome = Not Yet Determined; ordered by oldest first.
   • Closed Last 30 Days — filter Status = Closed AND ClosureUTC within 30 days.

8.3 Per-incident folder convention

For each new IncidentID, create a sibling folder in the same site under Documents → Incidents → with sub-folders:

<IncidentID>/
    01-defender-xdr/
    02-sentinel/
    03-irm/
    04-edisco/
    05-comm-compliance/
    06-service-health/
    07-materiality/
    08-ofac/
    09-regulator-notices/
    10-bcm-comms/
    11-tabletop-references/
    99-final-evidence-pack/

Each sub-folder receives the screenshots and exports captured per the section's Examiner Evidence Box. The 99-final-evidence-pack/ folder is the consolidated, hashed package referenced in §14.

8.4 Permissions and audit

1. Confirm list-level permissions restrict edit to the IR site members; restrict delete to site owners only (custom permission level: IR-Contribute-NoDelete).
2. Confirm audit logging at the site is captured under Control 1.7 — every list edit must produce an audit record.
3. Confirm the site is included in the standing eDiscovery preservation per §8.1.

Examiner Evidence Box — SharePoint IR list

Capture annually plus per-incident:

1. Site permissions report (annual).
2. Retention-label assignment confirmation (annual).
3. List schema export (annual; CSV of column definitions).
4. Per-incident: list-item version history export from open through close.

9. Power Automate — Notification Flows and Per-Regulator Timer Countdowns

Power Automate provides the timer countdowns, internal SLA breach alerts, and Teams adaptive-card escalations that drive incident-response cadence. Flows here do not file regulator notices automatically — every regulator notice is a human-in-the-loop action by General Counsel or designee — but flows surface the deadline and route the approval.

9.1 Navigation

1. Sign in to Power Automate at https://make.powerautomate.com with Power Platform Admin activated and the IR-flows environment selected.
2. From the left nav, expand Solutions → IR Notification Flows (the firm-managed solution housing the flows below).

9.2 Flow inventory

The following flows are in scope. Each flow is created from a SharePoint trigger on the §8 Incidents list and emits one or more Teams adaptive cards plus list-item updates.

Flow name	Trigger	Action	Owner
IR-Timer-NYDFS-72h	List item created where RegulatorNotificationsRequired contains NYDFS-72h	Countdown to T0+72h; alert at T0+24h, T0+48h, T0+60h, T0+71h; final alert at T0+72h to General Counsel	Power Platform Admin
IR-Timer-NYDFS-24h-Ransom	List item updated where OFACScreeningOutcome = Cleared AND ransom-payment context	Countdown to T0+24h from extortion-payment decision; per-hour alerts after T+12h	Power Platform Admin
IR-Timer-Banking-36h	List item created where RegulatorNotificationsRequired contains Banking-36h	Countdown to T0+36h from Notification Incident determination; alerts at T0+12h, T0+24h, T0+30h, T0+35h	Power Platform Admin
IR-Timer-SEC-8K-4bd	List item updated where MaterialityOutcome = Material	Countdown to material-determination + 4 business days; alerts at +1bd, +2bd, +3bd, +3.5bd	Power Platform Admin
IR-Timer-RegSP-30d	List item updated where NPIDisclosed = Yes	Countdown to T0+30 days; alerts at T0+15d, T0+25d, T0+29d	Power Platform Admin
IR-Timer-RegSP-72h-FTC	List item updated where NPIDisclosed = Yes AND FTC notification required	Countdown to T0+72h; alerts at T0+24h, T0+48h, T0+71h	Power Platform Admin
IR-Timer-FINRA-4530a-30d	List item updated where RegulatorNotificationsRequired contains FINRA-4530a-30d	Countdown to triggering-event + 30 days; alerts at +15d, +25d, +29d	Power Platform Admin
IR-Timer-CISA-CIRCIA	List item updated where RegulatorNotificationsRequired contains CISA-CIRCIA	Countdown applicable per final rule effective date; placeholder until final rule is in effect	Power Platform Admin
IR-Card-Disclosure-Committee	List item updated where MaterialityDeterminationUTC is not blank for the first time	Adaptive card to Disclosure Committee distribution list; sets MaterialityOutcome = Not Yet Determined if blank	Power Platform Admin
IR-Card-Series24-Escalate	List item updated where Communication Compliance escalation linked	Adaptive card to Designated Series 24/66 Principal	Power Platform Admin
IR-Card-OFAC-Escalate	List item updated where ransom-payment context tagged	Adaptive card to General Counsel + Treasury for OFAC pre-screen (see §11)	Power Platform Admin

9.3 Walkthrough — IR-Timer-NYDFS-72h (representative pattern)

1. From the IR Notification Flows solution, click + New → Automated cloud flow.
2. Flow name — IR-Timer-NYDFS-72h.
3. Trigger — When an item is created (SharePoint).
   • Site Address — IR site URL.
   • List Name — Incidents.
4. Add a Condition — triggerOutputs()?['body/RegulatorNotificationsRequired'] contains NYDFS-72h. No branch — terminate.
5. Yes branch — add a sequence of Delay until + Send adaptive card to Teams chat actions:
   • Delay until addHours(triggerOutputs()?['body/DetectionUTC'], 24) → card to General Counsel: "NYDFS 72h clock at +24h. . Recommended action: confirm Covered Entity determination."
   • Delay until addHours(triggerOutputs()?['body/DetectionUTC'], 48) → card to General Counsel + CISO: "NYDFS 72h clock at +48h. Confirm draft notification status."
   • Delay until addHours(triggerOutputs()?['body/DetectionUTC'], 60) → card to General Counsel + CISO + CCO: "NYDFS 72h clock at +60h. 12 hours remain."
   • Delay until addHours(triggerOutputs()?['body/DetectionUTC'], 71) → card to General Counsel + CISO + CCO + AI Governance Lead: "NYDFS 72h clock at +71h. One hour remains."
   • Delay until addHours(triggerOutputs()?['body/DetectionUTC'], 72) → card to all-hands distribution: "NYDFS 72h DEADLINE REACHED. Capture filed-or-withheld determination in RegulatorNotificationsSent."
6. Add an Update item action (final) that appends an entry to RegulatorNotificationsSent capturing whether the 72h clock was met (manually filled by General Counsel; the flow simply marks the deadline-reached event).
7. Save and Test with a synthetic list item.

Flows do not file notices

The flows here are deadline-surface flows. They do not transmit anything to a regulator portal. Every regulator notice is filed by General Counsel (or designee) through the regulator's own portal (§13). Filing automation is explicitly out of scope and would create unacceptable legal exposure.

9.4 Run-history retention

1. From each flow's overview page, capture the 28-day run history weekly to a CSV stored in the IR evidence folder (the §8.3 08-ofac/ and 09-regulator-notices/ folders for the relevant flows).
2. Configure the host environment's Activity logging so flow runs land in Purview Audit (Control 1.7).

9.5 Secrets

Flows that send adaptive cards require no secrets. Any flow that integrates with external systems (e.g., a regulator-portal helper) must use Azure Key Vault references via the Power Platform connector — never inline secrets. See Control 1.11 for the platform identity model.

Examiner Evidence Box — Power Automate

Capture for every flow, monthly:

1. Flow definition export (zip from Export → Package).
2. 28-day run history CSV.
3. Last successful test-run record per flow.
4. Owner attestation that no inline secrets are used.

10. Materiality Determination — SEC 8-K Item 1.05 Workflow

For SEC registrants, Item 1.05 of Form 8-K requires disclosure of a material cybersecurity incident within four business days of the materiality determination (the determination date, not the discovery date, starts the clock). Control 3.4 operationalizes the determination through the Disclosure Committee, with General Counsel sign-off and a written memo retained in the IR site.

10.1 Trigger criteria

Initiate the materiality workflow when any of the following is true for a Sev-1 / Sev-2 incident:

• Confirmed unauthorized access to systems containing material non-public information.
• Confirmed exfiltration of customer NPI affecting a material number of customers (per the firm's pre-defined materiality threshold; consult General Counsel).
• Operational disruption affecting a material business line for more than the firm's pre-defined disruption-materiality window.
• Confirmed integrity compromise of an AI agent that produces customer-facing output for a material business line.
• Any incident with reasonably foreseeable material impact on the firm's operations, financial condition, or reputation.

The materiality threshold is firm-specific; the Disclosure Committee owns the threshold and reviews it annually. Implementation requires the firm's Disclosure Committee to ratify a written materiality framework that this workflow operationalizes.

10.2 Disclosure Committee meeting

1. The Incident Commander emails the Disclosure Committee chair (typically the General Counsel or CFO) with the §1 register row link and a one-page incident summary.
2. The chair convenes the Disclosure Committee within the firm's pre-defined response SLA (recommended: within 24 hours of trigger criteria being met).

3. The meeting agenda is recorded using the structured template:

   DISCLOSURE-COMMITTEE-MEETING v1
   Incident: <INC-ID>
   Meeting at (UTC): <ISO timestamp>
   Chair: <UPN>
   Attendees: <UPNs — must include CISO, CCO, GC, CFO or designees>
   Outside counsel present: <Yes — Firm | No>
   Materiality framework version reviewed: <vN.N>
   Facts presented:
     - <bullet list — what is known with confidence>
   Facts unknown:
     - <bullet list — what is unknown / under investigation>
   Reasonably likely impact assessment (qualitative + quantitative where available):
     - <text>
   Materiality determination: <Material | Not Material | Defer — re-convene at <UTC>>
   Determination rationale: <free text — link to evidence>
   Determined at (UTC): <ISO timestamp — this starts the 4-bd clock if Material>
   Next review (if Defer): <UTC>
   

4. The chair records the outcome in the §8 list MaterialityOutcome and MaterialityDeterminationUTC columns.

5. If the determination is Material, the §9 IR-Timer-SEC-8K-4bd flow auto-engages.

10.3 Drafting the 8-K Item 1.05

The 8-K drafting itself is a Legal / outside counsel / Investor Relations workstream and is out of scope for this walkthrough. From the IR-process side:

1. The Incident Commander provides the technical narrative (what is known, what is unknown, scope, impact, remediation status) to General Counsel using the firm's 8-K technical-narrative template.
2. The narrative is updated as facts evolve and re-shared with General Counsel within 24 hours of any material change.
3. The Incident Commander does not review or edit the 8-K text itself.

10.4 Amended 8-K (Item 1.05(c))

When facts change after an initial 8-K is filed, Item 1.05(c) requires an amended 8-K within four business days of when the firm becomes aware of the new facts. The firm's standing materiality framework should specify the categories of change that trigger amendment (e.g., material change in scope of impacted customers, identification of additional impacted business lines, attribution of the threat actor with material implications).

8-K is the regulator-facing artifact, not a substitute for OCC / Fed / FDIC notice

For dual-regulated firms (e.g., a bank holding company that is also an SEC registrant), the 8-K does not satisfy the 36-hour Notification Incident requirement to the primary banking regulator (12 CFR Part 53 / 304 / 225). The two clocks run independently and require independent filings.

Examiner Evidence Box — Materiality

Capture for every Sev-1 / Sev-2 incident (whether or not Material):

1. Disclosure Committee meeting record (structured template above).
2. Materiality framework version referenced.
3. Determination outcome with rationale.
4. Where Material: 4-bd clock-start UTC and confirmation of IR-Timer-SEC-8K-4bd engagement.
5. Where Defer: re-convene UTC and the eventual final determination record.

Cross-Reference

Model-risk implications of a Material AI-agent incident (e.g., model retirement triggers under SR 11-7) are owned by Control 2.6. A Material AI-agent integrity incident typically triggers MRM challenge re-validation in addition to disclosure obligations.

11. OFAC Sanctions Screening — Pre-Payment Gate for Extortion Demands

OFAC pre-payment screening is mandatory before any extortion / ransom payment

Making a ransom or extortion payment to a person, entity, or jurisdiction on the OFAC Specially Designated Nationals (SDN) List, in a comprehensively sanctioned jurisdiction (e.g., Iran, North Korea, Cuba, Syria, the Crimea / DNR / LNR regions of Ukraine), or otherwise blocked under an OFAC sanctions program, is a strict-liability violation of US sanctions law regardless of the payer's knowledge or intent. Penalties include civil penalties up to the greater of approximately USD 368,136 per violation or twice the transaction value (statutory amounts are inflation-adjusted; consult OFAC's current civil-penalty matrix), criminal penalties for willful violations, and reputational and licensing consequences. The OFAC 2020 advisory (updated September 2021) on "Potential Sanctions Risks for Facilitating Ransomware Payments" further articulates expected due diligence including timely reporting to OFAC, CISA, FBI, and Treasury FinCEN. No payment may be authorized without documented OFAC pre-screening and General Counsel approval. This walkthrough does not provide legal advice; consult sanctions counsel for every extortion-payment scenario.

11.1 Trigger

A pre-payment OFAC screening is initiated when all of the following are true:

1. The incident involves an extortion demand (e.g., ransomware encryption note, data-leak extortion, denial-of-service extortion).
2. The Incident Commander has documented the demand details (cryptocurrency address or payment instructions, demanded amount, deadline, communication channel, threat actor self-identification).
3. The CISO and General Counsel have begun considering payment as one option (which does not mean payment will be made).

The §9 IR-Card-OFAC-Escalate flow auto-fires the moment the §8 list item is tagged with the ransom-payment context.

11.2 Workflow

1. The General Counsel convenes the Sanctions Review with the following participants (recommended): General Counsel (chair), CCO, CISO, Treasurer, outside sanctions counsel, and the firm's third-party incident-response retainer (where one exists).

2. The Sanctions Review records the following using the structured template:

   OFAC-PRESCREEN v1
   Incident: <INC-ID>
   Convened at (UTC): <ISO timestamp>
   Chair (General Counsel): <UPN>
   Outside sanctions counsel: <Firm | None — explain>
   Demand details:
     - Cryptocurrency address(es): <list>
     - Demand amount: <amount + currency>
     - Demand deadline (UTC): <ISO>
     - Threat actor self-identification: <name / group / unknown>
   Attribution evidence reviewed: <bullet list>
   OFAC SDN List screening — addresses: <Cleared | Hit — details>
   OFAC SDN List screening — actor names / aliases: <Cleared | Hit — details>
   Comprehensively sanctioned jurisdiction nexus: <None | Possible — explain>
   OFAC Cyber-related sanctions program nexus (E.O. 13694 / 13757): <None | Possible — explain>
   Treasury FinCEN financial-institution-customer screening (where applicable): <Cleared | Hit>
   Determination: <Cleared to consider payment | Blocked — payment prohibited | Defer — additional inquiry needed>
   Determination rationale: <free text>
   Determined at (UTC): <ISO timestamp>
   Notifications planned (independent of payment decision): <OFAC | CISA | FBI | Treasury FinCEN | NYDFS-24h-Ransom | other>
   

3. The determination is recorded in the §8 list OFACScreeningOutcome column.

4. If Blocked, no payment may be authorized; the Incident Commander documents the decision and the firm's response continues without payment. Notifications proceed independent of the payment decision.
5. If Cleared, payment authorization remains a separate decision by the firm's executive leadership / board (per the firm's payment-authorization policy); a Cleared OFAC determination is necessary but not sufficient for payment.
6. In all ransom-extortion scenarios (regardless of payment), evaluate notifications to:
   • OFAC voluntary self-disclosure (where any sanctions-nexus risk is identified).
   • CISA under the firm's cyber-incident reporting practice (and CIRCIA when in effect).
   • FBI Internet Crime Complaint Center (IC3) and / or local field office.
   • Treasury FinCEN Suspicious Activity Report where the firm is a financial-institution covered person.
   • NYDFS within 24 hours of any extortion payment under 23 NYCRR 500.17(c) (separate from the 72-hour cybersecurity event notification).
   • State-level notifications per state-AG playbooks.

11.3 Sanctions screening tool

The screening itself is performed against the OFAC Sanctions List Search at https://sanctionssearch.ofac.treas.gov and any commercial sanctions-screening tool the firm maintains. Capture screenshots of every search performed (search term, date / time, result count, and full result text where any match is returned).

Screening is not legal advice

The OFAC Sanctions List Search produces search results; it does not produce a determination. The determination is a legal judgment by General Counsel and outside sanctions counsel based on the search results, the firm's broader knowledge, and the totality of available attribution evidence. Implementation requires an experienced sanctions-counsel relationship; firms without such a relationship should establish one before an incident occurs.

Examiner Evidence Box — OFAC pre-screen

Capture for every ransom-extortion incident:

1. Sanctions Review convening record with attendees.
2. Structured OFAC-PRESCREEN v1 template.
3. Sanctions Search screenshots (all queries, with timestamps).
4. Outside sanctions-counsel sign-off (email or memo).
5. Final determination and rationale.
6. Notifications planned and filed.

12. Tabletop Exercise Harness — Quarterly AI-Specific Scenarios

Tabletop exercises validate the IR plan against realistic scenarios, develop muscle memory across the cross-functional team, and produce examiner-evidence of program maturity. For Control 3.4, exercises are conducted quarterly with at least one AI-agent-specific scenario per quarter.

12.1 Cadence and ownership

Cadence	Type	Owner	Approver
Quarterly	Tabletop (2-3 hours, discussion-based)	AI Governance Lead	CISO + CCO + General Counsel
Annually	Functional exercise (4-6 hours, hands-on portal navigation)	CISO	Board Risk Committee
Biennially	Full-scale exercise (1-2 days, includes BCM activation)	Business Continuity Officer	Board Risk Committee

12.2 AI-specific scenario library

Rotate across the following scenarios (minimum one per quarter):

Scenario	Primary regulators in scope	Key controls exercised
Prompt-injection-driven exfiltration — A threat actor seeds a SharePoint document with hidden instructions that cause a Copilot agent to summarize NPI from adjacent files into a draft email destined for an external recipient.	NYDFS, Reg S-P, FTC, state BNs, FINRA 4530 if registered persons involved	1.5, 1.7, 1.8, 1.12, 2.12, 3.4
Hallucinated customer communication — A Copilot-drafted client email cites a non-existent prospectus footnote and quotes an inaccurate yield. Email was sent before supervisory review.	FINRA 2210 / 3110, SEC Marketing Rule	1.5, 2.12, 3.4
Runaway agent on stale context — A scheduled agent continues to act on a stale grounding source after the source was revised; produces materially out-of-date risk reports for trading desks.	FINRA 3110 supervisory failure; potential Material 8-K depending on impact	1.7, 1.9, 2.6, 2.12, 3.4
Orphaned-agent cascade — A maker leaves the firm; their orphaned Copilot agents continue to run and accumulate signals an attacker exploits to pivot. Cross-references Control 3.6.	NYDFS, Banking 36h, potential Material 8-K	1.11, 2.25, 3.4, 3.6
Insider exfiltration via Copilot — Departing financial advisor uses Copilot to collate client lists into a single export.	Reg S-P, state BNs, Protocol for Broker Recruiting if applicable	1.5, 1.12, 2.12, 3.4
Ransomware with extortion of agent training data — Threat actor encrypts and threatens to leak the firm's fine-tuning corpus (which contains NPI).	NYDFS-24h-Ransom, Reg S-P, FTC, OFAC pre-screen	1.7, 1.8, 1.9, 3.4 (incl. §11)
Third-party Copilot connector compromise — An ISV-provided Copilot connector is compromised upstream; the firm's data accessed via the connector is potentially exfiltrated.	Reg S-P, NYDFS third-party-service-provider provisions, banking 36h	1.5, 1.8, 2.6, 3.4
MRM-triggering integrity incident — A Copilot agent used in a credit-decisioning workflow is shown to drift outside its validated boundaries.	OCC 2011-12 / SR 11-7 escalation, fair-lending considerations	2.6, 3.4

12.3 Exercise structure

Each tabletop follows this structure:

1. Pre-read distribution (T-7 days) — scenario summary (1-2 pages), participant roles, expected duration, and the specific portal blades that will be referenced.
2. Scenario setup (15 min) — scenario lead reads the initial situation; clock T0 is established.
3. Injects (90-120 min) — scenario lead delivers 5-7 injects (new facts that change the picture) at intervals; participants respond by describing the actions they would take, the portal blades they would open, and the artifacts they would capture.
4. Materiality and notification decisions (20-30 min) — Disclosure Committee role-play; OFAC pre-screen role-play if scenario warrants.
5. Hot wash (20-30 min) — facilitated debrief; capture findings, follow-ups, and proposed plan changes.
6. After-action report (T+5 days) — written report with findings rated as Strength / Opportunity / Gap; Gap items become tracked work in the IR site.

12.4 After-action report template

TABLETOP-AAR v1
Exercise name: <name>
Date (UTC): <ISO>
Scenario: <library name + version>
Facilitator: <UPN>
Participants: <UPNs by role>
Duration (actual): <hh:mm>
Findings:
  - <ID>: <Strength|Opportunity|Gap> — <description>
    Owner: <UPN>
    Target close: <date>
    Linked control(s): <list>
Recommendations to plan:
  - <bullet list>
Approvals:
  - CISO sign-off: <UPN at UTC>
  - CCO sign-off: <UPN at UTC>
  - General Counsel sign-off: <UPN at UTC>

12.5 Evidence retention

Tabletop materials (pre-read, scenario script, inject log, AAR) are retained in the IR site under Documents → Tabletops → and are part of the standard examiner packet (§14). Examiners frequently sample tabletop materials to assess program maturity.

Examiner Evidence Box — Tabletops

Capture per exercise plus annually:

1. Annual exercise calendar with planned scenarios.
2. Per-exercise pre-read, attendance log, inject log, AAR.
3. Gap-finding tracker showing close-out status.
4. Board Risk Committee briefing materials referencing exercise outcomes (annual).

Cross-Reference

Tabletop scenarios that exercise orphaned-agent cascade should align with Control 3.6. Scenarios that exercise MRM escalation should align with Control 2.6. Scenarios that exercise supervisory escalation should align with Control 2.12.

13. Regulator Portal References

Filing notices is performed through regulator-operated portals. The portal references below are provided for orientation only; URLs and submission flows are subject to change without notice and the firm's General Counsel is responsible for confirming the current submission requirements at the time of filing.

Regulator	Portal	Filing artifact	Owner
NYDFS	DFS Cybersecurity Portal at https://myportal.dfs.ny.gov	23 NYCRR 500.17(a) Cybersecurity Event Notification (72h); 500.17(c) Extortion Payment Notification (24h) and Written Statement (30d); annual 500.17(b) certification / acknowledgment of noncompliance	General Counsel
SEC	EDGAR at https://www.sec.gov/edgar	Form 8-K Item 1.05 (4 business days from materiality); amendment via Item 1.05(c)	General Counsel + Outside Counsel + IR
SEC (Reg S-P)	Filing model varies by registrant type; consult counsel	Customer notice of unauthorized access or use of customer information (30 days as amended); Federal law-enforcement notice (FBI / Secret Service) and to the SEC at https://www.sec.gov per program	General Counsel
FINRA	Firm Gateway at https://firms.finra.org	Rule 4530(a) and 4530(d) reporting; Rule 4530(f) quarterly statistical aggregation of customer complaints	CCO + Designated Series 24/66 Principal
OCC	BankNet at https://www.banknet.gov	12 CFR Part 53 Notification Incident (36h to primary federal regulator)	General Counsel + CCO
Federal Reserve	E-Apps at https://www.federalreserve.gov and Reserve Bank contact	12 CFR Part 225 Notification Incident (36h)	General Counsel + CCO
FDIC	FDICconnect at https://www.fdicconnect.gov	12 CFR Part 304 Notification Incident (36h)	General Counsel + CCO
NCUA	NCUA Secure Mail and the Cyber Incident Notification page at https://ncua.gov	12 CFR Part 748 Cyber Incident Notification (72h, federally insured credit unions)	General Counsel + CCO (credit unions only)
CFTC	CFTC Portal at https://portal.cftc.gov	Notice obligations under Part 3, Part 23 (swap dealers), and the firm's specific registration program	General Counsel + CCO (for CFTC registrants)
FTC	Online complaint form at https://www.ftc.gov	Safeguards Rule notification (16 CFR 314.5 — 30 days for incidents involving 500+ consumers)	General Counsel
Treasury FinCEN	BSA E-Filing at https://bsaefiling.fincen.treas.gov	Suspicious Activity Report where applicable to financial-institution covered persons	BSA Officer
OFAC	OFAC Reporting at https://home.treasury.gov/ofac	Voluntary self-disclosure where sanctions-nexus risk identified; blocked-property reports	General Counsel + Outside Sanctions Counsel
CISA	CISA Incident Reporting at https://www.cisa.gov/report	Voluntary cyber-incident reporting today; CIRCIA reporting once final rule is in effect	CISO designee
State AGs	Each state operates its own portal or email channel	State breach-notification statutes (varies by state) — typically expedited for incidents involving state-resident NPI	General Counsel
State financial regulators	Each state operates its own portal	State-level licensing and consumer-protection notices (varies by state)	General Counsel + CCO

Portal references are not legal advice

The portal table above is a navigation aid. The firm's General Counsel is responsible for confirming the current submission portal, the current submission format, and the current substantive requirements at the time of filing. Regulator portals and procedures change. Do not rely on this table as authoritative legal guidance.

14. Evidence Capture, Cadence, and Examiner Packet

14.1 Per-incident evidence pack

For every Sev-1 / Sev-2 incident, the closure deliverable is a consolidated, hashed evidence pack stored at Documents → Incidents → <IncidentID> → 99-final-evidence-pack/ in the IR site. The pack consists of:

1. The §8 list-item version-history export (CSV).
2. All §1.3 register-row contents (PDF).
3. Defender XDR incident export (§2; structured comments included).
4. Sentinel incident export and automation-rule run logs (§3).
5. IRM case open / close exports (§4).
6. eDiscovery (Premium) case summary, hold list, hold-notice acknowledgments, search statistics, export-package SHA-256 hash (§5).
7. Communication Compliance disposition records (§6).
8. Service Health screenshots at T0+1h, T0+24h, root-cause-determination (§7).
9. Power Automate flow run-history CSVs spanning the incident window (§9).
10. Disclosure Committee meeting record (§10).
11. OFAC pre-screen record (§11) where applicable.
12. Regulator-notice copies and filing receipts (§13) where applicable.
13. Lessons-learned memo (signed by Incident Commander, CISO, CCO, General Counsel).

The pack is compressed to a single zip; SHA-256 is computed and recorded in the §8 list EvidencePackageSHA256 column. The pack is retained per the firm's retention schedule (typically 7 years for SEC / FINRA registrants, 6 years for banking, longer where litigation hold applies).

14.2 Standing examiner packet

For ad-hoc examiner requests (e.g., NYDFS DFS examination, FINRA Rule 1017 examination, OCC continuous monitoring), maintain a standing examiner packet that is refreshed monthly at Documents → Examiner-Packet/<YYYY-MM>/:

Artifact	Source section	Refresh cadence
IR plan (signed)	Out of scope here	Annually + on material change
IR site permissions report	§8.4	Monthly
§1 register full export	§1	Monthly
§8 schema export	§8.2	Monthly + on change
Power Automate flow inventory	§9.2	Monthly + on change
Flow run-history (28-day) for each flow	§9.4	Monthly
Disclosure Committee charter and materiality framework	§10	Annually + on change
OFAC sanctions-counsel relationship attestation	§11	Annually
Tabletop calendar + last 12 months AARs	§12	Quarterly
Regulator-portal access list (who has filer credentials)	§13	Quarterly
Cross-reference matrix to Controls 1.5/1.7/1.8/1.9/1.11/1.12/2.6/2.12/2.25/3.6/3.9	This file	Annually + on change

14.3 Cadence summary

Cadence	Activity
Continuous	§0 PIM activation per incident; §2 / §3 / §4 / §6 alert triage
Per incident	All sections relevant to the incident profile
Daily (during active incident)	§1 register update; §7 Service Health re-check; §9 flow-status review
Weekly	§9 flow run-history export
Monthly	§14.2 standing examiner packet refresh; §0 license-attestation refresh; §8.4 site permissions report
Quarterly	§12 tabletop exercise; §14.2 regulator-portal access review; §0 PIM eligibility review
Annually	§10 materiality framework review; §11 sanctions-counsel attestation; §12 annual functional exercise; full IR plan review and sign-off; §1 notification matrix review against current rules

Examiner Evidence Box — Annual program review

Capture annually for board reporting:

1. Year-over-year incident-volume and severity-distribution charts.
2. Mean time to detection / containment / closure per severity.
3. Regulator-notification on-time rate (target: 100%).
4. Tabletop completion rate and gap close-out rate.
5. Cross-control finding rate (incidents that triggered tuning in 1.5/1.7/1.8/1.9/1.12/2.12/2.25).
6. Board sign-off record on the annual IR program review.

Closing Decision Matrix — Portal vs PowerShell vs Graph

For Control 3.4 operations, choose the surface based on the action profile below.

Action profile	Surface	Why
Triage a live alert; make a containment / clock-start decision	Portal (this walkthrough)	Decisions require human judgment; portal provides full context (related entities, history, timeline)
Apply structured open / close comments on incidents and cases	Portal (this walkthrough)	Audit-trail attribution to the human reviewer is required
Author an IRM, eDiscovery, or Communication Compliance case	Portal (this walkthrough)	Wizard-driven flows enforce required fields
Review Service Health and capture screenshots	Portal (this walkthrough)	Microsoft does not expose a programmatic Service Health surface that meets evidence-capture requirements for Control 3.4
Bulk export incident metadata for monthly examiner packet	PowerShell (powershell-setup.md)	Repeatable, scriptable, hash-stable
Bulk export Sentinel run-log evidence	PowerShell (powershell-setup.md)	Repeatable, scriptable
Programmatic enrichment / cross-tenant or cross-cloud queries	Graph / REST APIs	Not covered in this walkthrough
Provision the §8 SharePoint list schema across additional environments	PowerShell or PnP PowerShell (powershell-setup.md)	Repeatable, drift-detectable
Validation testing per release	Verification testing (verification-testing.md)	Test cases and expected outcomes
Issue diagnosis	Troubleshooting (troubleshooting.md)	Common issues and resolutions

Final Readiness Checklist

Confirm every item before declaring Control 3.4 portal-side implementation Ready:

Roles and access

• All §0.1 PIM-eligible roles assigned to named individuals; activation requires MFA + justification + ticket reference.
• Standing eligibility reviewed quarterly; results recorded in the §14.2 examiner packet.
• Regulator-portal filer credentials documented for NYDFS, EDGAR, FINRA Firm Gateway, OCC BankNet, FDICconnect, FederalReserve E-Apps, FTC, FinCEN, OFAC, CISA, and applicable state portals.

Licensing

• §0.2 license matrix validated against current entitlements; gaps logged and tracked.

Data sources

• §0.3 authoritative-source readiness confirmed for Defender XDR, Sentinel, Purview Audit, IRM, eDiscovery (Premium), Communication Compliance, Service Health, the §8 SharePoint list, and the §9 Power Automate solution.

Configuration

• §1 manual register and notification matrix maintained as the sovereign-cloud / outage fallback.
• §2 Defender XDR custom view, FSI severity rubric, and structured-comment templates in place and known to SOC.
• §3 Sentinel automation rules deployed; run-history capture procedure documented.
• §4 IRM cases workspace permissioned; pseudonymization roles confirmed.
• §5 eDiscovery (Premium) standing case template configured; hold-notice template approved by General Counsel.
• §6 Communication Compliance Copilot-scoped policy fired test alert reviewed end-to-end with Series 24/66 disposition.
• §7 Service Health gate documented in IR plan as mandatory pre-clock-start step.
• §8 SharePoint IR list deployed with full schema; site is legal-hold-aware.
• §9 Power Automate flows deployed; 28-day run history exporting to the IR site.
• §10 Disclosure Committee charter and materiality framework approved; meeting template in use.
• §11 OFAC pre-screen workflow approved; sanctions-counsel relationship attested.
• §12 quarterly tabletop calendar published; AAR template in use.

Evidence and reporting

• §13 regulator-portal reference reviewed by General Counsel within the last 12 months.
• §14 per-incident evidence-pack convention in place; standing examiner packet refreshed within the last 30 days.
• Annual board sign-off record on file.

Cross-control alignment

• Recurring §2 / §3 false positives routed to Control 1.8 for tuning.
• Recurring §4 false positives routed to Control 1.12 for tuning.
• Recurring §6 false positives routed to Control 2.12 for tuning.
• DLP / sensitivity-label changes triggered by incident lessons-learned routed to Control 1.5.
• Audit-log retention sufficiency validated against incident-investigation needs per Control 1.7.
• Retention-policy adequacy for Copilot interaction history validated per Control 1.9.
• Identity controls (PIM, phishing-resistant MFA) per Control 1.11.
• Material AI-agent integrity incidents trigger MRM challenge re-validation per Control 2.6.
• Agent-365 console used for cross-tenant agent inventory and ownership lookups per Control 2.25.
• Orphaned-agent detection feed correlated into Sentinel per Control 3.6.
• Sentinel integration architecture maintained per Control 3.9.

---

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current