Skip to content

Control 4.7 Verification & Testing Playbook

Microsoft 365 Copilot Data Governance - FSI Verification Bundle

Control: 4.7 - Microsoft 365 Copilot Data Governance Pillar: 4 - SharePoint & Content Governance (embedded M365 Copilot scope) Regulatory References: SEC 17a-4(f), FINRA 4511 / 3110 / 25-07 (Reg Notice 24-09 supervisory expectations for generative AI), SOX 302/404 (ICFR over AI-assisted disclosures), GLBA 501(b) / Reg S-P 30-day breach notification, FFIEC IT Handbook (AIO/Operations), OCC 2011-12 / Fed SR 11-7 (Model Risk Management), CFTC 1.31, NYDFS 23 NYCRR 500 (.07/.11/.16), NIST AI RMF 1.0 (Govern/Map/Measure/Manage), NIST SP 800-53 Rev. 5 (AC-3/AC-4/AC-6/AU-2/AU-12/SC-7/SC-13/SI-4/PM-9) Last UI Verified: April 2026 Governance Levels: Baseline, Recommended, Regulated

Regulatory hedging notice. This playbook documents verification procedures that support compliance with the regulations listed above. Successful execution of all tests does not by itself guarantee or ensure compliance. Each US financial services organization must validate that its specific regulatory obligations, supervisory commitments (including any FINRA Reg Notice 24-09 attestations or SEC examination undertakings), state-level requirements, and contractual obligations to clients and counterparties are met. The maturity ratings and pass thresholds in this document are calibrated against tenant-specific baselines captured in PRE-04 and PRE-07; do not adopt them as absolute targets without organization-specific recalibration. Generative AI behavior is non-deterministic; verification gives statistical assurance, not deterministic proof. Microsoft service surfaces, Graph API shapes, audit schemas, and portal paths change without notice - re-verify against the Last UI Verified date in the header of every cycle.

Subprocessor caveat. Microsoft 365 Copilot may, at Microsoft's option and within the boundaries documented in the Microsoft Products and Services Data Protection Addendum (DPA), invoke third-party model providers (including Anthropic) as subprocessors for selected reasoning workloads. FSI tenants must (a) confirm acceptance of the current subprocessor list under their Enterprise Agreement, (b) ensure that residency, prompt-logging, and customer-data-not-used-for-training commitments extend to those subprocessors, and (c) re-attest at every renewal. SOV-01 through SOV-03 below verify per-cloud parity but do not by themselves confirm subprocessor acceptance - that is a procurement and legal artefact captured in PRE-02.

What this playbook catches

  • M365 Copilot licenses assigned to users in restricted business units, branches, or representative populations whose communications are subject to FINRA 3110/3120 supervision but who have not been added to the supervisory review scope (LIC-01, LIC-02, LIC-03)
  • Encryption-protected (sensitivity-labelled, IRM, double key, or customer key) content surfacing in Copilot grounding when the label policy explicitly excludes Copilot reasoning - the highest-risk false positive in any FSI deployment (LABEL-01 negative test, LABEL-02, LABEL-03)
  • Data Loss Prevention (DLP) policies for Copilot interactions running in Test / Test with notifications / Report-only mode beyond the 30-day pilot grace window, leaving sensitive prompts and responses unsanctioned (DLP-01, DLP-02, DLP-03)
  • Restricted SharePoint Search (RSS) configured with ApplicableToAllSites set to $False or with site allow-lists that drift from the approved Copilot-eligible site inventory between cycles (RSS-01, RSS-02, RSS-03)
  • Endpoint DLP for Copilot-on-Edge running in audit instead of enforce mode, allowing copy-paste and screenshot exfiltration of Copilot output to unmanaged surfaces (EDLP-01, EDLP-02, EDLP-03)
  • Copilot Pages (Loop component) and Notebooks created by Copilot users that fall outside the Microsoft Purview retention scope - SEC 17a-4(f) and FINRA 4511 require comprehensive capture of business records irrespective of the surface they are authored on (PAGES-01, PAGES-02, NOTEBOOKS-01, NOTEBOOKS-02, NOTEBOOKS-03)
  • Multi-geo tenants where Copilot grounding crosses an OST or PDL boundary into a non-permitted region, breaching client residency commitments and, for non-US affiliates of US registrants, potentially triggering host-country data export obligations (MULTIGEO-01, MULTIGEO-02, MULTIGEO-03)
  • Negative-control synthetic prompts (NEG-01, NEG-02, NEG-03) that prove the guardrails actually fire under attack conditions, not just under happy-path observation
  • Sovereign-cloud parity gaps (SOV-01, SOV-02, SOV-03) where Commercial-tenant configurations have not been mirrored into GCC, GCC High, DoD, or 21Vianet tenants - a chronic source of cross-tenant regulatory drift in firms with US plus non-US operations
  • DLP-to-Sentinel and DLP-to-Reg-S-P breach-notification routing failures that would prevent the firm from meeting the GLBA Reg S-P 30-day notification clock for a Copilot-mediated incident (IR-01, IR-02, IR-03)

What this playbook does NOT claim

  • Does not certify that any specific Copilot response is free of hallucinations, fabricated citations, or model-introduced bias - that is the function of human supervisory review under FINRA 3110 and 25-07, not technical verification
  • Does not replace OCC 2011-12 / Fed SR 11-7 model risk management documentation, model inventory entries, ongoing performance monitoring, or independent model validation
  • Does not satisfy FINRA Reg Notice 24-09 supervisory procedure attestation by itself - that requires written supervisory procedures, named principal sign-off, and supervisor training records held outside this technical playbook
  • Does not cover Copilot Studio, custom agents, declarative agents, or third-party Copilot-branded extensions - those are governed by control 4.8 and Pillar 1 / 2 controls for agent identity, action allow-listing, and connector governance
  • Does not validate Microsoft's underlying foundation-model behaviour, training data lineage, or subprocessor (including Anthropic) operational controls - those are vendor-attested artefacts retrieved through the Microsoft Service Trust Portal and reviewed under control 1.5
  • Does not, on its own, prove that retained Copilot interactions are SEC 17a-4(f) WORM-immutable - that depends on the underlying Purview retention lock, lock-policy, and Preservation Lock configuration verified separately under control 4.5

Section 0 - Pre-flight blockers (BLK-01 through BLK-07)

A verification cycle MUST NOT proceed past Section 1 if any of the following blocking conditions is true. Each blocker is a fail-closed gate; the validator (Section 6) exits with code 2 if any blocker is unresolved at cycle start. Document blocker resolution or formal exception (with named accountable principal and expiry date) before re-running.

BLK-01 - No documented Copilot scope of authorisation

The firm must hold a current, signed scope-of-authorisation memorandum that names: (a) the legal entities, business lines, branches, and representative populations authorised to use M365 Copilot; (b) the data classifications (public, internal, confidential, regulated, MNPI) those users may surface through Copilot; (c) named accountable principal under FINRA 3110(a)(2); (d) effective date and review cadence (not greater than 12 months). Absence of this memorandum, or expiry of the review date, is a hard blocker. Verification cannot meaningfully evaluate "is the configuration aligned with intent" if the intent is not documented.

BLK-02 - Tenant not on a supported Microsoft 365 Copilot service plan

Confirm via the Microsoft 365 admin centre or Get-MgSubscribedSku that the tenant holds an active Microsoft 365 Copilot service plan SKU (Microsoft_365_Copilot family) and that license counts are non-zero. Trial, expired, or partially-provisioned SKUs produce inconsistent grounding behaviour and yield false negatives across the LIC, LABEL, and RSS namespaces. Block until renewed or until the trial has converted to a paid SKU.

BLK-03 - Unified Audit Log (UAL) ingestion not healthy

Run Search-UnifiedAuditLog -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) -RecordType CopilotInteraction -ResultSize 1 and confirm at least one record returns within the tenant baseline UAL latency captured in PRE-04. If UAL is unhealthy, every evidence item that depends on CopilotInteraction, LabelApplied, DlpRuleMatch, or FileAccessedExtended records is unreliable. Do not proceed until UAL latency is back inside the PRE-04 baseline plus 2 sigma.

BLK-04 - Sensitivity-label taxonomy not promulgated to all in-scope users

Confirm via Purview Get-Label and Get-LabelPolicy that the production label taxonomy is published to all groups containing Copilot-licensed users, and that the per-policy RetryDistribution value shows fewer than 1 percent of targeted users in failed-distribution state. A user without an applied label policy cannot have content correctly excluded from Copilot grounding and the LABEL family will produce false passes.

BLK-05 - Restricted SharePoint Search (RSS) decision not ratified

The firm must hold a current decision (governance committee minute, change-advisory-board approval, or equivalent) on whether RSS is engaged tenant-wide (ApplicableToAllSites = $True) or in selective allow-list mode. The default Copilot configuration grounds against any SharePoint content the asking user can already access, which for many FSI tenants exceeds the intended Copilot-eligible scope. Without a ratified decision, the RSS namespace cannot meaningfully assert pass/fail.

BLK-06 - Microsoft Purview retention coverage gap for Copilot surfaces

Confirm that Purview retention policies are explicitly extended to: (i) Teams chat (Copilot prompts and responses are persisted as Teams 1:1 chat-equivalent records under user mailboxes), (ii) SharePoint and OneDrive (for Copilot Pages, Loop components, and Notebooks), (iii) Exchange (for Copilot-in-Outlook drafts and summaries), and (iv) the dedicated CopilotInteraction retention scope where licensed. Any of these missing is a hard blocker because SEC 17a-4(f) and FINRA 4511 require capture of business records irrespective of authoring surface.

BLK-07 - Sovereign tenant configuration drift from Commercial baseline

For firms operating Commercial plus any of GCC, GCC High, DoD, or 21Vianet, confirm that the most recent SOV-01 parity scan (Section 4) recorded zero unresolved deltas in the LIC, LABEL, DLP, RSS, and EDLP control families. Drift between sovereign and Commercial tenants is a chronic source of cross-tenant regulatory exposure - permit the cycle to proceed only if an exception with named accountable principal and remediation deadline is on file.

Section 1 - Verification cadence matrix (11 areas x 3 cycles)

# Verification area Daily Weekly Monthly Quarterly Cycle owner Reviewer Grace window
1 Copilot license assignment (LIC) Drift delta vs prior day Reconcile against HRIS-of-record and supervisory population Full re-attestation by business-line manager Independent compliance audit M365 Service Owner Compliance Principal (FINRA 3110(a)(2)) 24 hours daily, 5 business days monthly
2 Sensitivity-label exclusion of encrypted content (LABEL) Negative-test prompt LABEL-01 Label-policy distribution health check Re-publish label policy targeting Taxonomy review with Legal/Privacy Information Protection Lead Data Protection Officer 4 hours daily, 1 business day monthly
3 DLP-for-Copilot enforcement (DLP) Sample 50 prompts vs DLP rule fire log Tune false-positive ratio against PRE-04 baseline Rule-set re-attestation; remove orphans Rule-set business review with line owners DLP Engineering Lead Compliance Principal 8 hours daily, 3 business days monthly
4 Restricted SharePoint Search scope (RSS) Allow-list delta vs prior day Re-scan ApplicableToAllSites and IncludedSiteIds Re-attest site allow-list with Records Mgmt Records-management committee ratification SharePoint Platform Owner Records Management Officer 24 hours daily, 5 business days quarterly
5 Endpoint DLP for Copilot-on-Edge (EDLP) Enforce-mode confirmation per managed device Aggregate enforcement coverage by device-state Recompute coverage vs licensed user population Coverage attestation to Audit Committee Endpoint Engineering InfoSec Operations 12 hours daily, 5 business days quarterly
6 Copilot Pages and Loop retention (PAGES) New-page count vs retention scope Spot-check 25 pages for retention label Re-validate retention scope expression Records-management deep dive on samples Records Management Compliance Principal 8 hours daily, 1 business day monthly
7 Copilot Notebooks and OneNote retention (NOTEBOOKS) New-notebook count vs retention scope Spot-check 25 notebooks for retention label Re-validate retention scope expression Records-management deep dive on samples Records Management Compliance Principal 8 hours daily, 1 business day monthly
8 Multi-geo grounding boundary (MULTIGEO) Cross-region grounding event count Per-PDL grounding heat-map Re-attest per-PDL Copilot eligibility list Privacy review of cross-border flows Multi-geo Service Owner Privacy Office 4 hours daily, 1 business day monthly
9 Negative-control synthetic suite (NEG) Run NEG-01, NEG-02, NEG-03 fixtures Trend pass-rate vs PRE-07 baseline Refresh fixture corpus with new attack patterns Red-team review and fixture rotation Compliance Engineering InfoSec Red Team 4 hours daily, 5 business days quarterly
10 Sovereign-cloud parity (SOV) Drift indicator vs Commercial baseline Per-tenant drift report Per-tenant remediation plan Cross-tenant governance committee Tenant Governance Lead Sovereign Compliance Officer 24 hours daily, 5 business days monthly
11 Incident-response routing (IR) DLP-to-Sentinel route health End-to-end synthetic incident drill Reg S-P 30-day-clock readiness review Tabletop with Incident Response and Legal SOC Manager CISO and General Counsel 8 hours daily, 5 business days monthly

Cadence rules.

  1. The "Daily" cycle is rolling 24 hours; the validator (Section 6) accepts evidence dated within the prior 26 hours to absorb scheduling jitter and timezone seams.
  2. The "Weekly" cycle anchors on the firm's chosen close-of-business day (typically Friday US-Eastern or Sunday for global desks) and must be completed before market open the following business day.
  3. The "Monthly" cycle anchors on the last business day of the month and must complete within 5 business days after month-end. SOX 302/404 ICFR sub-certifications consume the monthly attestation; missing the 5-day window forces a 302 certifier exception note.
  4. The "Quarterly" cycle must complete within 15 calendar days after quarter-end to align with Form 10-Q and FOCUS Report timelines.
  5. Grace window expiry without remediation OR documented exception is itself a finding (FIND-CADENCE) raised at the next cycle and tracked through closure.

Section 2 - Pre-flight gates (PRE-01 through PRE-07)

PRE- gates run automatically at the start of every cycle. They establish that the verification environment is fit for assertion. A failed PRE- gate halts the cycle and surfaces a fail-closed exit code 2 from the validator.

PRE-01 - Tenant identity and service plan confirmation

Resolve (Get-MgOrganization).Id, (Get-MgOrganization).VerifiedDomains, and the active Microsoft 365 Copilot SKUs from Get-MgSubscribedSku. Pin tenant ID, primary verified domain, sovereign cloud (Commercial / GCC / GCC High / DoD / 21Vianet), and SKU GUIDs into the cycle metadata. This artefact is the anchor that downstream evidence files reference; a mismatch between PRE-01 metadata and any evidence file's tenantId field is automatic fail.

Pass criteria. Tenant ID matches the firm's authoritative tenant register; sovereign cloud matches BLK-07 ratification; at least one Microsoft 365 Copilot SKU is in enabled state with consumedUnits greater than zero.

Evidence. pre-01-tenant.json containing {tenantId, primaryDomain, cloudInstance, subscribedSkus[]}.

PRE-02 - Subprocessor list acknowledgement

Confirm the firm has a current acknowledgement (signed or workflow-recorded) of Microsoft's published Online Services Subprocessor List inclusive of any model-provider subprocessors (e.g., Anthropic) invoked by Copilot reasoning. Acknowledgement age MUST be less than 365 days OR less than the time since the most-recent Microsoft subprocessor-list update (whichever is shorter). Procurement-of-record holds the source artefact.

Pass criteria. Acknowledgement date is more recent than max(now - 365d, lastMicrosoftSubprocessorUpdate).

Evidence. pre-02-subprocessors.json with {acknowledgementDate, subprocessorListVersion, signedBy, evidenceLocation}.

PRE-03 - Audit log connector and Sentinel ingestion health

Confirm the Microsoft 365 -> Microsoft Sentinel connector (or equivalent SIEM connector) is connected, has ingested at least one OfficeActivity and one CopilotInteraction record in the last 60 minutes, and that the Sentinel data-connector page reports zero unresolved health alerts for the M365 connector family.

Pass criteria. Last-ingestion timestamp on OfficeActivity table within 15 minutes; on CopilotInteraction within 30 minutes; data-connector health is Healthy.

Evidence. pre-03-siem.json with KQL output of last-ingestion times plus connector health.

PRE-04 - Tenant baseline measurement (UAL latency, DLP rule-fire rate, label distribution)

Capture the tenant baseline numerics that downstream tests are evaluated against. The baseline is the trailing 30-day median for each metric, plus 2-sigma upper bound. Numerics include: UAL ingestion latency for CopilotInteraction; DLP rule-fire rate per 1,000 prompts (per rule); sensitivity-label-application latency on new SharePoint and OneDrive items; multi-geo grounding cross-region rate. These are tenant-baselined; the playbook does not assert absolute numeric thresholds.

Pass criteria. Each metric has at least 21 of the last 30 days populated; baseline file is signed and date-stamped.

Evidence. pre-04-baseline.json with {metric, p50, p95, sigma, sampleCount, windowStartUtc, windowEndUtc} per metric.

PRE-05 - Privileged role and break-glass posture

Confirm that the cycle runner identity holds only the least-privilege roles required for read-only assertion (Global Reader, Compliance Reader, SharePoint Reader, Security Reader). Break-glass accounts must not have logged in within the cycle window. Any privileged-role escalation during the cycle window must be paired with a corresponding ticket reference.

Pass criteria. Cycle runner role set is a subset of the approved least-privilege bundle; zero unmatched break-glass logins; any escalation has matching ticket.

Evidence. pre-05-iam.json with {cyclePrincipal, roles[], breakglassLoginEvents[], escalations[]}.

PRE-06 - Change-control freeze status

Confirm that no in-flight change request affects Copilot, Purview labelling, DLP, RSS, or EDLP configuration during the cycle execution window. Changes mid-cycle invalidate the assertion because the configuration sampled at the beginning of the cycle differs from the configuration in production at the end.

Pass criteria. Zero open CRs in the listed scope with a planned implementation window overlapping the cycle window; OR named exception with control owner sign-off.

Evidence. pre-06-change-freeze.json with {cycleWindowUtc, openCrs[], exceptions[]}.

PRE-07 - Synthetic fixture integrity and baseline pinning

Confirm that the synthetic test fixture corpus (the canary documents, canary identities, canary prompts, canary regulated-data strings) is intact: SHA-256 hash of each fixture file matches the value pinned in the previous quarterly fixture-rotation record. Confirm that all numeric thresholds used in the cycle are sourced from the PRE-04 baseline file produced in this cycle (not stale, not hard-coded). Numerics MUST be tenant-baselined; numeric thresholds copy-pasted from another tenant or from this playbook are an automatic fail.

Pass criteria. All fixture file SHA-256 values match prior quarterly pin; PRE-04 baseline file is the one produced in this cycle; no hard-coded numeric thresholds detected by the validator's Test-NumericProvenance function.

Evidence. pre-07-fixtures.json with {fixtureFile, expectedSha256, observedSha256, baselineRefId}.

Section 3 - Processing and propagation windows

Microsoft 365 Copilot evidence has documented service-side latency that must be respected to avoid false negatives. The validator (Section 6) refuses to assert pass on a test whose evidence falls inside the noise-window for that signal.

Signal Typical service-side latency Validator wait-window before asserting Tenant-specific override
CopilotInteraction UAL record 30-60 minutes PRE-04 p95 plus 30 minutes If PRE-04 p95 > 60 min, raise FIND-LATENCY
LabelApplied UAL record 5-30 minutes PRE-04 p95 plus 15 minutes n/a
DlpRuleMatch for Copilot policy location 10-45 minutes PRE-04 p95 plus 20 minutes n/a
Restricted SharePoint Search effective change Up to 24 hours 26 hours after Set-SPOTenantRestrictedSearchMode Document any sub-24h change as exception
Sensitivity-label policy distribution 1-24 hours 26 hours after Set-LabelPolicy n/a
Endpoint DLP policy distribution to managed device 30-90 minutes after device check-in 4 hours after policy publish AND device check-in observed n/a
Multi-geo PDL change Up to 72 hours for full propagation 76 hours after Set-SPOSiteDataLocation n/a
Retention policy effective on new Copilot Pages 1-7 days 8 days after publish for new-content claim n/a
Sentinel analytic rule fire Near-real-time, max 5 minutes after source ingestion PRE-03 connector latency plus 10 minutes n/a

Note. Latency values are illustrative ranges drawn from Microsoft Learn at the time of UI verification. Each tenant MUST measure its own latency under PRE-04 and use that local baseline; do not adopt the table values as absolute.

Section 4 - Test catalog (33 tests across 11 namespaces)

Each test uses the 7-field format: Test ID / Trigger / Steps / Expected / Evidence / Failure mode / Owner. Test IDs are stable; do not renumber. Adding a new test requires a quarterly fixture-rotation entry.

Namespace LIC - Copilot license assignment

LIC-01 - License assignment vs supervisory population reconciliation

  • Test ID: LIC-01
  • Trigger: Daily at 06:00 tenant-local; on-demand after any HRIS movement event
  • Steps: (1) Enumerate users with the Microsoft 365 Copilot service plan via Get-MgSubscribedSku and per-user Get-MgUserLicenseDetail. (2) Pull the supervisory-scope population of-record from the firm's HRIS or surveillance system (FINRA 3110 covered persons). (3) Compute three sets: Licensed-NotInSupervisory, InSupervisory-NotLicensed-ButLicenseEligible, Licensed-AndInSupervisory. (4) Cross-reference Licensed-NotInSupervisory against the BLK-01 scope memorandum exclusion list.
  • Expected: Zero entries in Licensed-NotInSupervisory that are NOT on the BLK-01 exclusion list. Any positive count is FIND-LIC-01-DRIFT.
  • Evidence: lic-01-reconciliation.json containing the three sets, the SHA-256 of the HRIS extract, and the SHA-256 of the BLK-01 memo as ratified.
  • Failure mode: A registered representative gains Copilot access without being added to supervisory review scope. Surveillance under FINRA 3110/3120 incomplete; potential Reg Notice 24-09 finding.
  • Owner: M365 Service Owner; reviewer Compliance Principal under FINRA 3110(a)(2).

LIC-02 - License-deprovisioning closure SLA

  • Test ID: LIC-02
  • Trigger: Daily; on-demand after any termination, transfer, or leave-of-absence event
  • Steps: (1) Pull the prior 24h HRIS termination/transfer events. (2) For each event, query Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Change user license'" for a matching license-removal event. (3) Compute time-to-deprovision (delta seconds). (4) Cross-reference against the firm's deprovisioning SLA (typically same-day for terminations).
  • Expected: All termination events have a corresponding Copilot-license-removal event within the firm-defined SLA. Transfers have license re-evaluation against the new role's eligibility.
  • Evidence: lic-02-deprovisioning.json with {hrisEventId, eventType, eventUtc, deprovisionUtc, deltaSeconds, slaSeconds, status}.
  • Failure mode: Terminated employee retains Copilot access after departure, breaching access-management baselines (NIST AC-2) and creating a record-retention gap because the residual session may not be captured against the correct identity.
  • Owner: Identity Engineering; reviewer Compliance Principal.

LIC-03 - Group-based license inheritance integrity

  • Test ID: LIC-03
  • Trigger: Weekly on the close-of-business reconciliation cycle
  • Steps: (1) Enumerate all groups assigning the Copilot SKU via Get-MgGroup -Filter "assignedLicenses/any()". (2) Pull membership of each group via Get-MgGroupMember. (3) For each member, validate that they hold the assigned SKU and that the SKU is not in disabled or error state. (4) Compare the group-derived population against the LIC-01 Licensed-AndInSupervisory set; investigate any delta.
  • Expected: Group-derived population equals direct-assignment population plus group-inheritance population, with no orphaned error or pendingProvisioning states older than the PRE-04 baseline propagation window.
  • Evidence: lic-03-group-inheritance.json with {groupId, memberCount, licenseSuccess, licenseError, orphanedAge}.
  • Failure mode: Stale group membership or orphaned license-assignment errors create unnoticed access drift. Drift compounds across cycles; quarterly compliance audit (Section 1) is too late to detect.
  • Owner: Identity Engineering; reviewer M365 Service Owner.

Namespace LABEL - Sensitivity-label exclusion of encrypted content (negative tests are critical)

LABEL-01 - Encrypted content blocked from Copilot grounding (NEGATIVE TEST - critical)

  • Test ID: LABEL-01
  • Trigger: Daily at 07:00 tenant-local; immediately after any Set-LabelPolicy change
  • Steps: (1) Locate the canary document in PRE-07 fixtures labelled with the firm's "Highly Confidential / Encrypted" sensitivity label, where the label policy explicitly sets EnableCustomPermissions = $True and the protection template excludes the Copilot service principal. (2) From a canary identity that has Copilot license AND has read-access to the canary document under normal label-protected access (i.e., the user can open the document), submit the canary prompt that asks Copilot to summarise the file. (3) Capture the Copilot response. (4) Pull the CopilotInteraction UAL record for the prompt; pull the LabelApplied and FileAccessed records for the document.
  • Expected: Copilot response MUST NOT contain the canary phrase planted in the document. The CopilotInteraction record MUST show groundingFiles empty OR explicitly excluded with reason EncryptionLabel. NO false-positive grounding on encrypted content.
  • Evidence: label-01-encrypted-negative.json with {canaryDocId, labelId, prompt, responseExcerpt, canaryPhrasePresent (must be false), groundingFiles[], exclusionReason}. Hash of the response capture.
  • Failure mode: Critical. Encrypted content surfaces in Copilot grounding, leaking client confidential or MNPI through reasoning to a population broader than the encryption was intended to permit. SEC Reg S-P, GLBA, and contractual confidentiality breach in a single failure.
  • Owner: Information Protection Lead; reviewer Data Protection Officer and Compliance Principal.

LABEL-02 - Label policy distribution health

  • Test ID: LABEL-02
  • Trigger: Weekly
  • Steps: (1) Enumerate published label policies via Get-LabelPolicy. (2) For each policy, retrieve the distribution status via the Purview policy-distribution endpoint. (3) Compute per-policy distribution-success ratio across the targeted user population. (4) Cross-reference any user in failed-distribution state against the LIC-01 licensed population; users in both sets are high-priority remediation.
  • Expected: Distribution-success ratio greater than 99 percent across all in-scope policies; zero overlap between failed-distribution users and Copilot-licensed users older than the PRE-04 baseline.
  • Evidence: label-02-policy-health.json with {policyId, targetUserCount, successCount, failedUsers[], copilotLicensedAndFailed[]}.
  • Failure mode: Copilot-licensed user receives no label policy; user-applied labels never fire; LABEL-01 exclusion is bypassed because there is no label to evaluate.
  • Owner: Information Protection Lead.

LABEL-03 - Default label and downgrade-justification audit

  • Test ID: LABEL-03
  • Trigger: Monthly
  • Steps: (1) Pull the prior month's LabelChanged UAL records where oldLabel was higher-classification than newLabel (downgrade events). (2) For each downgrade, capture the user-supplied justification. (3) Sample 50 events; the Compliance Principal reviews justifications for legitimacy. (4) Tally events by user and by site; flag outliers (greater than baseline plus 2-sigma justifications per user per month).
  • Expected: All sampled justifications are business-legitimate; no statistical outliers (or outliers explained); no patterns of just-in-time downgrade immediately followed by Copilot prompts on the downgraded content.
  • Evidence: label-03-downgrade.json with {eventId, user, oldLabel, newLabel, justificationText, copilotPromptWithin1h (boolean), reviewerVerdict}.
  • Failure mode: Users learn that downgrading a label permits Copilot grounding and exploit the workflow to surface protected content; a slow-burn pattern that quarterly review is unlikely to catch without baseline.
  • Owner: Compliance Principal; reviewer Information Protection Lead.

Namespace DLP - Data Loss Prevention for Copilot interactions

DLP-01 - Sampled prompt match against DLP rules (must be in ENFORCE mode)

  • Test ID: DLP-01
  • Trigger: Daily at 08:00 tenant-local
  • Steps: (1) From Get-DlpCompliancePolicy and Get-DlpComplianceRule, enumerate all rules whose Locations include the Copilot location. (2) Confirm each rule's Mode is Enable (enforce). Any rule in TestWithNotifications, Test, or ReportOnly past the 30-day pilot grace window is FIND-DLP-01-MODE. (3) Pull a sample of 50 CopilotInteraction records from the prior 24h that contain regulated-data patterns (SSN, account number, MNPI markers from the firm's classifier list). (4) For each, confirm a corresponding DlpRuleMatch event with Action of Block, BlockAccess, or BlockOverride (per policy intent).
  • Expected: Zero rules in non-enforce mode past grace window. Every regulated-data prompt produces a matching DlpRuleMatch with the policy-intended action. Pass-rate against the sample MUST exceed the PRE-04 baseline minus 2-sigma.
  • Evidence: dlp-01-sampled.json with {ruleId, mode, modeAgeDays, sampleSize, matchCount, matchRate, baselineRate, baselineSigma, status}.
  • Failure mode: Critical. DLP rules sit in Report-only past the pilot, surfacing sensitive data through Copilot with no enforcement and no user notification - the highest-volume cause of Copilot-related data exposure in published incident reviews.
  • Owner: DLP Engineering Lead; reviewer Compliance Principal.

DLP-02 - False-positive ratio tuning

  • Test ID: DLP-02
  • Trigger: Weekly
  • Steps: (1) Pull the prior 7 days of DlpRuleMatch events for Copilot location. (2) Cross-reference against the user-submitted false-positive override events (where users invoked override-with-business-justification). (3) Compute false-positive ratio per rule. (4) Compare against PRE-04 baseline plus 2-sigma; rules outside band are candidates for tuning. Tuning changes flow through normal change-control (PRE-06).
  • Expected: Per-rule false-positive ratio inside PRE-04 baseline plus 2-sigma; any rule outside band has an open tuning ticket.
  • Evidence: dlp-02-fp-ratio.json with {ruleId, fireCount, overrideCount, fpRatio, baselineRatio, baselineSigma, ticketRef}.
  • Failure mode: Untuned rules generate alert fatigue; users normalise overrides; legitimate matches are dismissed alongside false positives.
  • Owner: DLP Engineering Lead.

DLP-03 - Override-with-justification audit

  • Test ID: DLP-03
  • Trigger: Monthly; sample drawn quarterly for compliance review
  • Steps: (1) Pull the prior month's user overrides on Copilot DLP rules. (2) Stratify by user, by rule, and by data classification of the matched prompt. (3) Sample 50 overrides; reviewer reads the user-supplied justification and rates legitimacy on a 3-point scale (legitimate / questionable / improper). (4) Aggregate verdict; questionable and improper drive user coaching; improper drives potential FINRA 3110 finding.
  • Expected: Less than 5 percent improper overrides; less than 15 percent questionable; per-user override count inside PRE-04 baseline plus 2-sigma.
  • Evidence: dlp-03-overrides.json with {eventId, user, ruleId, justification, classification, verdict, action}.
  • Failure mode: Override pattern reveals systemic policy gap or training need; left undetected, becomes a supervisory finding.
  • Owner: Compliance Principal; reviewer DLP Engineering Lead.

Namespace RSS - Restricted SharePoint Search scope

RSS-01 - ApplicableToAllSites confirmation (must be $True for tenant-wide RSS)

  • Test ID: RSS-01
  • Trigger: Daily at 09:00 tenant-local; immediately after any Set-SPOTenantRestrictedSearchMode change
  • Steps: (1) Run Get-SPOTenantRestrictedSearchMode to retrieve current mode and IncludedSiteIds. (2) Cross-reference against the BLK-05 ratified decision: tenant-wide RSS requires Mode -eq 'Enabled' and ApplicableToAllSites -eq $True; allow-list mode requires Mode -eq 'AllowList' with IncludedSiteIds matching the approved Copilot-eligible inventory. (3) Compute set delta vs prior-day capture; any delta requires PRE-06 change-ticket reference.
  • Expected: Current configuration matches BLK-05 ratification. Zero unexplained delta vs prior day. If tenant-wide RSS is in effect, ApplicableToAllSites MUST be $True.
  • Evidence: rss-01-mode.json with {mode, applicableToAllSites, includedSiteIds[], priorDaySha256, currentSha256, changeTickets[]}.
  • Failure mode: Critical. RSS misconfigured to permit Copilot grounding against the entire SharePoint estate when intent was an allow-list, exposing legacy regulated content to Copilot-mediated retrieval.
  • Owner: SharePoint Platform Owner; reviewer Records Management Officer.

RSS-02 - Allow-list site eligibility re-attestation

  • Test ID: RSS-02
  • Trigger: Monthly
  • Steps: (1) From the RSS-01 IncludedSiteIds list, retrieve each site's metadata via Get-SPOSite -Identity <url>: classification, retention label, sensitivity label, owner, last-activity. (2) For each site, the named site owner re-attests Copilot eligibility against the BLK-01 scope memorandum. (3) Sites failing re-attestation are removed from RSS allow-list within 5 business days.
  • Expected: 100 percent of allow-list sites have a current attestation (within 35 days); zero sites with classification above the scope memorandum permits.
  • Evidence: rss-02-attestation.json with {siteId, ownerUpn, classification, attestationUtc, attestationStatus}.
  • Failure mode: Allow-list rots; sites repurposed for regulated content remain in Copilot grounding scope long after their data classification changed.
  • Owner: SharePoint Platform Owner; reviewer Records Management Officer.

RSS-03 - Newly-created sites default-exclusion confirmation

  • Test ID: RSS-03
  • Trigger: Daily
  • Steps: (1) Enumerate sites created in the prior 24 hours via Get-SPOSite plus CreatedTime filter. (2) Confirm each new site is NOT present in the RSS allow-list (allow-list mode) OR is captured by the tenant-wide RSS scope (tenant-wide mode). (3) For tenant-wide mode, additionally confirm the new site does not carry an exclusion override that re-permits Copilot grounding.
  • Expected: Newly-created sites default to the firm's intended Copilot posture (excluded in allow-list mode; included with no override in tenant-wide mode unless explicitly excluded by labelling).
  • Evidence: rss-03-new-sites.json with {siteId, createdUtc, classification, rssStatus, overrideExists, status}.
  • Failure mode: New sites created during cycle window inherit unintended Copilot-eligibility, exposing nascent confidential workspaces to Copilot retrieval.
  • Owner: SharePoint Platform Owner.

Namespace EDLP - Endpoint DLP for Copilot-on-Edge

EDLP-01 - Edge enforce-mode confirmation per managed device

  • Test ID: EDLP-01
  • Trigger: Daily at 10:00 tenant-local
  • Steps: (1) From Microsoft Intune or Configuration Manager, enumerate managed devices with Edge installed. (2) Pull the Endpoint DLP policy assignment via Get-DlpEndpointPolicy (or Purview portal export). (3) Confirm that, for each managed device hosting a Copilot-licensed user, the Endpoint DLP policy targeting Copilot-on-Edge is in Enforce mode. (4) Cross-reference any device in Audit mode against the change-control system for active pilot exemptions.
  • Expected: 100 percent of managed devices in scope are in Enforce mode for Copilot-on-Edge; zero devices in Audit mode without an open pilot ticket.
  • Evidence: edlp-01-enforce.json with {deviceId, userUpn, edgeVersion, policyMode, ticketRef, status}.
  • Failure mode: Critical. Audit-mode Endpoint DLP allows copy-paste, screenshot, and print exfiltration of Copilot output to unmanaged surfaces with no enforcement signal.
  • Owner: Endpoint Engineering; reviewer InfoSec Operations.

EDLP-02 - Coverage ratio: licensed users vs covered devices

  • Test ID: EDLP-02
  • Trigger: Weekly
  • Steps: (1) Cross-reference the LIC-01 licensed-user population against the EDLP-01 covered-device list. (2) Compute coverage ratio: licensedUsersWithAtLeastOneEnforceModeDevice / totalLicensedUsers. (3) Investigate any user with zero covered devices (BYOD, unmanaged personal device, gap in MDM enrolment).
  • Expected: Coverage ratio greater than 98 percent; uncovered users have an active enrolment ticket OR a documented exception (e.g., Citrix-only access, no local Edge).
  • Evidence: edlp-02-coverage.json with {licensedUserUpn, coveredDeviceCount, exceptionStatus}.
  • Failure mode: Licensed users without enforce-mode endpoints become the path-of-least-resistance for exfiltration.
  • Owner: Endpoint Engineering.

EDLP-03 - Egress-to-unmanaged-surface event capture

  • Test ID: EDLP-03
  • Trigger: Daily
  • Steps: (1) Pull the prior 24h EndpointDlpRuleMatch events for the Copilot-on-Edge policy. (2) Stratify by action type: BlockClipboard, BlockPrint, BlockScreenCapture, BlockUpload. (3) Reconcile blocked event count against PRE-04 baseline plus 2-sigma; investigate spikes (potential incident) and dips (potential policy regression).
  • Expected: Event volume inside PRE-04 baseline plus 2-sigma; zero unexplained dips below baseline minus 2-sigma.
  • Evidence: edlp-03-egress.json with {action, count, baselineCount, baselineSigma, status}.
  • Failure mode: Silent regression in Endpoint DLP rule fires goes undetected because monthly volume looks "normal" without baseline.
  • Owner: InfoSec Operations.

Namespace PAGES - Copilot Pages and Loop component retention

PAGES-01 - Retention scope active for Copilot Pages

  • Test ID: PAGES-01
  • Trigger: Daily
  • Steps: (1) Pull the prior 24h Copilot Pages creation events from the audit log (SharePointFileOperation records with ItemType of Page and UserAgent indicating Copilot origin). (2) For each new page, query the assigned retention label via Get-SPOFileRetentionLabel (or equivalent Graph endpoint). (3) Confirm the page falls within the retention scope intended for Copilot-authored content (typically the firm's "Business Records / Communications" retention policy).
  • Expected: 100 percent of new Copilot Pages have a retention label corresponding to the intended retention scope; zero pages in NoLabel or OptedOut state.
  • Evidence: pages-01-retention.json with {pageId, createdUtc, retentionLabelId, retentionScope, status}.
  • Failure mode: Copilot Pages used for client-meeting notes, deal-team discussions, or research synthesis fall outside the retention scope; SEC 17a-4(f) and FINRA 4511 record-keeping gap; potential supervisory finding.
  • Owner: Records Management; reviewer Compliance Principal.

PAGES-02 - Loop component retention propagation

  • Test ID: PAGES-02
  • Trigger: Weekly
  • Steps: (1) Sample 25 Loop components created in the prior 7 days from Copilot prompts (Loop components surface as fluid-framework files in the Loop app and as embeds in Teams chat). (2) For each, confirm both the source Loop file AND any chat-embed copy carry the intended retention label. (3) Confirm the Loop file site is not on the RSS exclusion list (which would create a partial-coverage anomaly).
  • Expected: All sampled Loop components and their embed copies carry the intended retention label; zero components in unexpected sites.
  • Evidence: pages-02-loop.json with {loopFileId, embedLocations[], retentionLabelId, siteRssStatus, status}.
  • Failure mode: Loop component captured in chat as a "live document" but the source-of-truth file is in an unretained site; record retrieval at e-discovery returns inconsistent versions.
  • Owner: Records Management.

PAGES-03 - Page-deletion supervisory review

  • Test ID: PAGES-03
  • Trigger: Monthly
  • Steps: (1) Pull the prior month's Copilot Pages deletion events. (2) For each deletion within the retention period, confirm a supervisory-justified deletion record exists (or the deletion is overridden by retention lock and the file persists in the preservation hold library). (3) Sample 25 deletions for compliance review.
  • Expected: Zero in-period deletions without retention lock OR supervisory justification record.
  • Evidence: pages-03-deletions.json with {pageId, deletedUtc, retentionLockActive, justificationRef, reviewVerdict}.
  • Failure mode: User deletes a Copilot-authored business record before retention period elapses; retention lock should override deletion but a configuration gap may permit it.
  • Owner: Records Management; reviewer Compliance Principal.

Namespace NOTEBOOKS - Copilot Notebooks and OneNote retention

NOTEBOOKS-01 - Loop and Notebook retention propagation (multi-surface)

  • Test ID: NOTEBOOKS-01
  • Trigger: Daily
  • Steps: (1) Enumerate Copilot Notebooks created in the prior 24 hours via Graph (/me/onenote/notebooks plus tenant-wide variant). (2) For each notebook, query the assigned retention label and the parent OneDrive or SharePoint site. (3) Confirm the notebook is captured by at least one Purview retention policy whose scope includes Copilot-authored content. (4) For Notebooks containing Loop components, repeat the multi-surface check from PAGES-02.
  • Expected: 100 percent of new Copilot Notebooks have an applied retention label; multi-surface Loop content carries consistent labels across surfaces.
  • Evidence: notebooks-01-retention.json with {notebookId, parentSiteId, retentionLabelId, loopComponents[], status}.
  • Failure mode: Copilot Notebooks become a parallel records system unaddressed by the retention regime - the surface most-likely to be missed because Notebooks are a relatively new authoring artefact.
  • Owner: Records Management.

NOTEBOOKS-02 - Sensitive-content classifier coverage

  • Test ID: NOTEBOOKS-02
  • Trigger: Weekly
  • Steps: (1) Pull the prior 7 days of SensitiveInfoTypeMatch records scoped to OneNote and Notebook surfaces. (2) Reconcile against the LIC-01 licensed-user population. (3) Confirm classifier processing is occurring (non-zero scan counts) on Notebooks owned by Copilot-licensed users.
  • Expected: Non-zero classifier activity on Notebooks of Copilot-licensed users in the period; zero users with zero classifier activity AND non-zero notebook activity.
  • Evidence: notebooks-02-classifier.json with {userUpn, notebookCount, classifierScanCount, status}.
  • Failure mode: Notebooks bypass classifier scanning, leaving sensitive content un-labelled and out-of-scope for DLP.
  • Owner: Information Protection Lead.

NOTEBOOKS-03 - Cross-tenant Notebook sharing audit

  • Test ID: NOTEBOOKS-03
  • Trigger: Monthly
  • Steps: (1) Pull the prior month's external sharing events on Notebooks owned by Copilot-licensed users. (2) For each external recipient, confirm the recipient is on the firm's permitted-counterparty list (B2B partner, audit firm, regulator). (3) Sample 25 events for compliance review.
  • Expected: Zero external sharing to unpermitted recipients; all permitted external sharing has a documented business purpose.
  • Evidence: notebooks-03-sharing.json with {notebookId, recipient, recipientDomain, permittedListed, businessPurpose, verdict}.
  • Failure mode: Notebook shared externally with sensitive content surfaced via Copilot grounding; client-confidentiality breach.
  • Owner: Compliance Principal.

Namespace MULTIGEO - Multi-geo grounding boundary

MULTIGEO-01 - Cross-region grounding event detection

  • Test ID: MULTIGEO-01
  • Trigger: Daily for multi-geo tenants only
  • Steps: (1) Pull the prior 24h CopilotInteraction records. (2) For each, resolve the user's preferred data location (PDL) via Get-MgUser -Property preferredDataLocation and the grounding-file site's data location via Get-SPOSite -Identity <url>. (3) Compute cross-region grounding events: userPdl != siteDataLocation. (4) Cross-reference against the firm's permitted cross-region matrix (some firms permit all-EU-to-all-EU but block EU-to-US, etc.).
  • Expected: Zero cross-region events outside the permitted matrix; per-PDL cross-region rate inside PRE-04 baseline plus 2-sigma.
  • Evidence: multigeo-01-cross-region.json with {eventId, userUpn, userPdl, siteId, siteRegion, permittedByMatrix, status}.
  • Failure mode: Critical. EU-resident user grounds Copilot against US-resident site; potential GDPR cross-border transfer issue and breach of client data-residency commitments.
  • Owner: Multi-geo Service Owner; reviewer Privacy Office.

MULTIGEO-02 - PDL change reconciliation

  • Test ID: MULTIGEO-02
  • Trigger: Weekly
  • Steps: (1) Pull the prior 7 days of Update user directory-audit events where preferredDataLocation changed. (2) For each, confirm the change has an HR-validated business reason (employee relocation, internal transfer). (3) For each, confirm Copilot grounding behaviour after the change matches the expected new region.
  • Expected: All PDL changes have HR-validated business reason; post-change grounding matches new PDL within the documented 72-hour propagation window (Section 3).
  • Evidence: multigeo-02-pdl-change.json with {userUpn, oldPdl, newPdl, hrTicketRef, postChangeGroundingMatches, status}.
  • Failure mode: Unexplained PDL change permits cross-border data movement; potential insider-driven data exfiltration vector.
  • Owner: Multi-geo Service Owner.

MULTIGEO-03 - Site-region attestation

  • Test ID: MULTIGEO-03
  • Trigger: Monthly
  • Steps: (1) Enumerate all sites in scope of Copilot grounding (RSS allow-list or tenant-wide minus exclusions). (2) For each, confirm the site's data location matches the documented data-residency commitment for that site's content (client data, regulated data, etc.). (3) Sample 25 sites for residency-attestation review.
  • Expected: Zero sites with data location mismatched against documented commitment; all sampled attestations validate.
  • Evidence: multigeo-03-site-attestation.json with {siteId, dataLocation, residencyCommitment, attestationVerdict}.
  • Failure mode: Site provisioned in wrong region during Multi-geo rollout; remediation requires site move and may invalidate retention chains.
  • Owner: Multi-geo Service Owner; reviewer Privacy Office.

Namespace NEG - Negative-control synthetic suite

NEG-01 - Synthetic MNPI prompt rejection

  • Test ID: NEG-01
  • Trigger: Daily
  • Steps: (1) Submit the canary prompt from PRE-07 fixtures that asks Copilot to summarise a synthetic earnings draft labelled MNPI. (2) Capture response. (3) Confirm response refuses or scrubs the MNPI markers; confirm DLP rule fires; confirm CopilotInteraction record carries the rule-match annotation.
  • Expected: Response does not include MNPI canary phrases; DLP rule fired; rule mode is Enforce.
  • Evidence: neg-01-mnpi.json with {promptHash, responseHash, canaryPresent (must be false), dlpFired, ruleMode}.
  • Failure mode: MNPI surfaces in Copilot output to a population beyond the deal team; insider trading and Reg FD exposure.
  • Owner: Compliance Engineering; reviewer InfoSec Red Team.

NEG-02 - Synthetic PII prompt rejection

  • Test ID: NEG-02
  • Trigger: Daily
  • Steps: (1) Submit canary prompt embedding synthetic SSNs, account numbers, and DOBs from PRE-07 fixtures. (2) Capture response. (3) Confirm DLP rule fires with Block action; confirm response is scrubbed or blocked.
  • Expected: Response does not echo PII; DLP rule fired in Enforce mode.
  • Evidence: neg-02-pii.json with {promptHash, responseHash, piiEchoed (must be false), dlpFired}.
  • Failure mode: PII echoed in Copilot output; GLBA Reg S-P breach; potential 30-day notification requirement.
  • Owner: Compliance Engineering.

NEG-03 - Synthetic prompt-injection adversarial

  • Test ID: NEG-03
  • Trigger: Daily
  • Steps: (1) Submit the canary adversarial prompt from PRE-07 fixtures that attempts to induce Copilot to (a) ignore prior policy instructions, (b) ground against an excluded site, (c) reveal a synthetic encrypted-canary phrase. (2) Capture response. (3) Confirm none of the three induction attempts succeed.
  • Expected: Zero successful inductions; CopilotInteraction record reflects normal grounding scope.
  • Evidence: neg-03-injection.json with {promptHash, responseHash, induceA (false), induceB (false), induceC (false)}.
  • Failure mode: Prompt-injection bypasses guardrails; broader red-team finding triggered.
  • Owner: InfoSec Red Team; reviewer Compliance Engineering.

Namespace SOV - Sovereign-cloud parity

SOV-01 - Per-cloud configuration parity scan

  • Test ID: SOV-01
  • Trigger: Daily for firms with multiple sovereign tenants
  • Steps: (1) For each tenant (Commercial, GCC, GCC High, DoD, 21Vianet), pull the configuration manifest for: LIC SKUs and assignment policy, LABEL policies and protection templates, DLP policies and rule modes, RSS mode and IncludedSiteIds, EDLP policies and modes. (2) Compute per-control-family delta vs Commercial baseline. (3) Any delta NOT explicitly captured in the firm's per-cloud variance register (which documents legitimate cloud-by-cloud differences) is FIND-SOV-01-DRIFT.
  • Expected: Zero unregistered deltas; all registered variances are dated and signed by the sovereign-compliance officer.
  • Evidence: sov-01-parity.json with {tenantId, cloud, controlFamily, deltaCount, registeredVariances[], unregisteredDeltas[]}.
  • Failure mode: Critical. Commercial-tenant hardening not mirrored to GCC High; cleared-personnel users on GCC High get weaker controls than commercial peers; cross-tenant audit finding inevitable.
  • Owner: Tenant Governance Lead; reviewer Sovereign Compliance Officer.

SOV-02 - Sovereign-cloud feature-availability gap log

  • Test ID: SOV-02
  • Trigger: Monthly
  • Steps: (1) Pull Microsoft's published feature-availability matrix for the sovereign clouds in scope. (2) For each Copilot-related capability used in Commercial, confirm availability in each sovereign cloud. (3) Where a feature is unavailable, document the compensating control (manual process, reduced-scope deployment, or formal exception).
  • Expected: All Commercial Copilot capabilities have either parity in sovereign clouds OR a documented compensating control with sovereign-compliance-officer sign-off.
  • Evidence: sov-02-feature-gap.json with {capability, commercialAvailable, sovereignCloud, sovereignAvailable, compensatingControl, signoffRef}.
  • Failure mode: Sovereign cloud lacks a Copilot capability assumed by other controls; compensating control absent; partial deployment to sovereign cloud creates expectation gap.
  • Owner: Sovereign Compliance Officer.

SOV-03 - Cross-tenant evidence consolidation

  • Test ID: SOV-03
  • Trigger: Monthly
  • Steps: (1) For each tenant in scope, retrieve the prior month's evidence pack archives. (2) Confirm each pack carries the per-cloud cloudInstance field correctly. (3) Confirm SHA-256 manifests are valid in each pack. (4) Generate a cross-tenant consolidated index for audit-committee submission.
  • Expected: All sovereign-tenant evidence packs are present, intact, and indexed; consolidated index hash is published.
  • Evidence: sov-03-consolidated.json with {cloud, packPath, manifestValid, packSha256}.
  • Failure mode: Sovereign-tenant evidence missed in audit prep; auditor finding for incomplete control-evidence chain.
  • Owner: Tenant Governance Lead.

Namespace IR - Incident response routing

IR-01 - DLP-to-Sentinel route plus Reg S-P 30-day clock readiness

  • Test ID: IR-01
  • Trigger: Daily route-health check; weekly end-to-end synthetic incident drill
  • Steps: (1) Confirm Sentinel analytic rule "Copilot DLP - High Severity" is enabled and last-fired timestamp is within PRE-04 baseline. (2) Submit a synthetic high-severity DLP event via NEG-02 fixture. (3) Confirm: (a) DLP rule fires within Section 3 propagation window; (b) Sentinel incident is created with severity High; (c) PagerDuty / ServiceNow ticket is created via the SOAR playbook; (d) the Reg S-P 30-day clock-start workflow is triggered with an automated GLBA-incident memo draft routed to General Counsel.
  • Expected: All four steps complete within the firm-defined SOC SLA (typically 15 minutes from rule fire to GC notification).
  • Evidence: ir-01-route.json with {drillId, dlpFireUtc, sentinelIncidentUtc, ticketUtc, gcNotifyUtc, slaMet}.
  • Failure mode: Critical. DLP fires but Sentinel incident does not surface to SOC; GLBA 30-day clock starts unmonitored; firm misses Reg S-P notification window.
  • Owner: SOC Manager; reviewer CISO and General Counsel.

IR-02 - Tabletop exercise execution and findings closure

  • Test ID: IR-02
  • Trigger: Quarterly
  • Steps: (1) Run a tabletop scenario based on a plausible Copilot-mediated data exposure (encrypted-content leakage, MNPI surfacing, multi-geo cross-border grounding). (2) Document IR team response, decisions, and elapsed times. (3) Capture findings; route through change-control. (4) Reverify findings closure at next quarterly cycle.
  • Expected: Tabletop completed within scheduled quarter; findings logged; prior-quarter findings closed or have closure ETA.
  • Evidence: ir-02-tabletop.json with {drillUtc, scenarioRef, participants[], findings[], priorFindingsClosed[]}.
  • Failure mode: Tabletop findings pile up uncovered; firm enters real incident with known unmitigated gaps.
  • Owner: CISO; reviewer General Counsel.

IR-03 - Supervisory escalation drill (FINRA 3110 / Reg Notice 24-09)

  • Test ID: IR-03
  • Trigger: Quarterly
  • Steps: (1) Inject a synthetic supervisory-trigger Copilot event (e.g., Copilot output containing forward-looking statement to retail audience). (2) Confirm the surveillance system raises an alert. (3) Confirm the alert is routed to the named principal under FINRA 3110(a)(2). (4) Confirm the principal's review-and-disposition action is recorded in the supervisory-evidence repository. (5) Confirm the disposition is retained per the firm's supervisory record schedule.
  • Expected: Alert raised; routed; reviewed; disposition recorded and retained; cycle time inside the firm-defined supervisory SLA.
  • Evidence: ir-03-supervisory.json with {drillId, alertUtc, principalUpn, reviewUtc, dispositionUtc, retentionConfirmed, slaMet}.
  • Failure mode: Supervisory alert never reaches named principal; FINRA Reg Notice 24-09 attestation breaks; potential AWC.
  • Owner: Compliance Principal; reviewer Surveillance System Owner.

Section 5 - Sovereign-cloud parity matrix

Capability Commercial GCC GCC High DoD 21Vianet Notes
Microsoft 365 Copilot service plan Generally available Generally available Generally available Limited Not available 21Vianet operated by independent partner; consult Microsoft for current status
CopilotInteraction audit record type Yes Yes Yes Yes Yes (subject to operator) Schema parity expected; verify with PRE-03
Sensitivity labels with encryption Yes Yes Yes Yes Yes DoD requires FIPS 140-2 validated cipher suites
DLP for Copilot location Yes Yes Yes Yes Yes Per-cloud rule shapes may differ; SOV-01 catches drift
Restricted SharePoint Search Yes Yes Yes Yes Verify availability Allow-list semantics identical across clouds
Endpoint DLP for Copilot-on-Edge Yes Yes Yes Yes Verify availability Edge channel availability differs per cloud
Microsoft Purview retention for Copilot Yes Yes Yes Yes Yes Retention lock and Preservation Lock available across clouds
Sentinel ingestion Yes Yes Yes Yes Verify Sentinel availability and pricing differ per cloud
Subprocessor list including model providers Yes (Microsoft public list) Yes (per GCC DPA) Yes (per GCC High DPA) Yes (per DoD DPA) Operator-published PRE-02 acknowledges per-cloud list
FedRAMP authorization scope High (commercial baseline) Moderate (GCC) / High (GCC High) High plus DoD IL4/IL5 DoD IL5 Out of scope (operator-attested) Confirm current ATO state at the Microsoft Service Trust Portal

Per-cloud variance register. Maintain a register at evidence/sovereign/variance-register.json listing each known legitimate cloud-by-cloud difference (capability, cloud, reason, compensating control, signoff). SOV-01 reads this register to differentiate registered variance from unregistered drift.

Section 6 - Evidence pack and validator

6.1 Evidence pack layout

evidence/4.7/<cycleId>/
  pre-01-tenant.json
  pre-02-subprocessors.json
  pre-03-siem.json
  pre-04-baseline.json
  pre-05-iam.json
  pre-06-change-freeze.json
  pre-07-fixtures.json
  tests/
    lic-01-reconciliation.json
    lic-02-deprovisioning.json
    lic-03-group-inheritance.json
    label-01-encrypted-negative.json
    label-02-policy-health.json
    label-03-downgrade.json
    dlp-01-sampled.json
    dlp-02-fp-ratio.json
    dlp-03-overrides.json
    rss-01-mode.json
    rss-02-attestation.json
    rss-03-new-sites.json
    edlp-01-enforce.json
    edlp-02-coverage.json
    edlp-03-egress.json
    pages-01-retention.json
    pages-02-loop.json
    pages-03-deletions.json
    notebooks-01-retention.json
    notebooks-02-classifier.json
    notebooks-03-sharing.json
    multigeo-01-cross-region.json
    multigeo-02-pdl-change.json
    multigeo-03-site-attestation.json
    neg-01-mnpi.json
    neg-02-pii.json
    neg-03-injection.json
    sov-01-parity.json
    sov-02-feature-gap.json
    sov-03-consolidated.json
    ir-01-route.json
    ir-02-tabletop.json
    ir-03-supervisory.json
  manifest.sha256       # SHA-256 of every file above, line-per-file
  module.sha256         # SHA-256 of the validator PowerShell module used for this cycle
  attestation.json      # 3-signature hash-chain attestation (Section 7)

6.2 JSON Schema sketch (fsi-4.7-evidence.schema.json)

The evidence pack root is a single JSON file cycle.json that references the evidence directory above. Schema (excerpt):

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://fsi-agentgov.example/schema/fsi-4.7-evidence.schema.json",
  "title": "FSI Control 4.7 Evidence Pack",
  "type": "object",
  "required": ["controlId", "version", "cycleId", "tenant", "windowUtc", "preflight", "tests", "manifest"],
  "properties": {
    "controlId": { "const": "4.7" },
    "version":   { "const": "v1.4" },
    "cycleId":   { "type": "string", "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{6}Z-(daily|weekly|monthly|quarterly)$" },
    "tenant": {
      "type": "object",
      "required": ["tenantId", "primaryDomain", "cloudInstance"],
      "properties": {
        "tenantId":      { "type": "string", "format": "uuid" },
        "primaryDomain": { "type": "string", "format": "hostname" },
        "cloudInstance": { "enum": ["Commercial", "GCC", "GCCHigh", "DoD", "21Vianet"] }
      }
    },
    "windowUtc": {
      "type": "object",
      "required": ["startUtc", "endUtc"],
      "properties": {
        "startUtc": { "type": "string", "format": "date-time" },
        "endUtc":   { "type": "string", "format": "date-time" }
      }
    },
    "preflight": {
      "type": "object",
      "required": ["pre01", "pre02", "pre03", "pre04", "pre05", "pre06", "pre07"],
      "additionalProperties": false,
      "patternProperties": {
        "^pre0[1-7]$": {
          "type": "object",
          "required": ["status", "evidenceFile", "sha256"],
          "properties": {
            "status":       { "enum": ["pass", "fail", "exception"] },
            "evidenceFile": { "type": "string" },
            "sha256":       { "type": "string", "pattern": "^[A-Fa-f0-9]{64}$" },
            "exceptionRef": { "type": "string" }
          }
        }
      }
    },
    "tests": {
      "type": "array",
      "minItems": 33,
      "maxItems": 33,
      "items": {
        "type": "object",
        "required": ["testId", "status", "evidenceFile", "sha256", "completedUtc", "ownerUpn"],
        "properties": {
          "testId":        { "type": "string", "pattern": "^(LIC|LABEL|DLP|RSS|EDLP|PAGES|NOTEBOOKS|MULTIGEO|NEG|SOV|IR)-0[1-3]$" },
          "status":        { "enum": ["pass", "fail", "exception", "skipped"] },
          "evidenceFile":  { "type": "string" },
          "sha256":        { "type": "string", "pattern": "^[A-Fa-f0-9]{64}$" },
          "completedUtc":  { "type": "string", "format": "date-time" },
          "ownerUpn":      { "type": "string", "format": "email" },
          "findingId":     { "type": "string", "pattern": "^FIND-" },
          "exceptionRef":  { "type": "string" }
        }
      }
    },
    "manifest": {
      "type": "object",
      "required": ["manifestSha256", "moduleSha256", "fileCount"],
      "properties": {
        "manifestSha256": { "type": "string", "pattern": "^[A-Fa-f0-9]{64}$" },
        "moduleSha256":   { "type": "string", "pattern": "^[A-Fa-f0-9]{64}$" },
        "fileCount":      { "type": "integer", "minimum": 41 }
      }
    },
    "attestation": { "$ref": "#/$defs/attestation" }
  },
  "$defs": {
    "attestation": {
      "type": "object",
      "required": ["cycleSha256", "priorCycleSha256", "signatures"],
      "properties": {
        "cycleSha256":      { "type": "string", "pattern": "^[A-Fa-f0-9]{64}$" },
        "priorCycleSha256": { "type": "string", "pattern": "^([A-Fa-f0-9]{64}|GENESIS)$" },
        "signatures": {
          "type": "array",
          "minItems": 3,
          "maxItems": 3,
          "items": {
            "type": "object",
            "required": ["role", "principalUpn", "signedUtc", "signatureValue"],
            "properties": {
              "role":           { "enum": ["preparer", "reviewer", "approver"] },
              "principalUpn":   { "type": "string", "format": "email" },
              "signedUtc":      { "type": "string", "format": "date-time" },
              "signatureValue": { "type": "string", "minLength": 64 }
            }
          }
        }
      }
    }
  }
}

This schema is envelope-compatible with the FSI evidence packs for controls 1.14, 1.19, and 1.21; the attestation $ref is the same shape used elsewhere so a single audit-side validator can consume packs from any of these controls.

6.3 PowerShell validator skeleton (fail-closed)

#requires -Version 7.4
#requires -Modules @{ModuleName='Microsoft.Graph'; ModuleVersion='2.20.0'}, @{ModuleName='ExchangeOnlineManagement'; ModuleVersion='3.4.0'}

[CmdletBinding()]
param(
    [Parameter(Mandatory)] [string] $CyclePath,
    [Parameter(Mandatory)] [string] $SchemaPath
)

# Exit codes:
#  0 = pass (all gates and tests pass or have valid exceptions)
#  1 = fail (one or more tests failed; cycle is recorded but findings are open)
#  2 = blocked (BLK-* unresolved, PRE-* failed, schema invalid, manifest tamper, or fixture-integrity failure)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
$global:ExitCode = 2

function Write-CycleLog {
    param([string]$Level, [string]$Message)
    $entry = @{ ts = (Get-Date).ToUniversalTime().ToString('o'); level = $Level; msg = $Message } | ConvertTo-Json -Compress
    Add-Content -Path (Join-Path $CyclePath 'validator.log') -Value $entry -Encoding UTF8
}

function Test-Blocker {
    # Iterates BLK-01..07 from the BLK ledger; any unresolved blocker fails closed.
    $ledger = Get-Content (Join-Path $CyclePath 'blockers.json') | ConvertFrom-Json
    foreach ($b in $ledger.blockers) {
        if ($b.status -ne 'resolved' -and $b.status -ne 'exception') {
            Write-CycleLog -Level 'ERROR' -Message "Blocker $($b.id) unresolved"
            return $false
        }
    }
    return $true
}

function Test-Preflight {
    # Iterates PRE-01..07; uses the preflight schema fragment.
    foreach ($pre in @('pre01','pre02','pre03','pre04','pre05','pre06','pre07')) {
        $file = Join-Path $CyclePath ($pre.Insert(3,'-') + '-*.json')
        $found = Get-ChildItem -Path $file -ErrorAction SilentlyContinue | Select-Object -First 1
        if (-not $found) { Write-CycleLog -Level 'ERROR' -Message "Preflight $pre missing"; return $false }
        $obj = Get-Content $found.FullName | ConvertFrom-Json
        if ($obj.status -ne 'pass' -and $obj.status -ne 'exception') {
            Write-CycleLog -Level 'ERROR' -Message "Preflight $pre status $($obj.status)"
            return $false
        }
    }
    return $true
}

function Test-NumericProvenance {
    # Refuses hard-coded numeric thresholds in test evidence files; numerics must trace to PRE-04 baseline.
    $baseline = Get-Content (Join-Path $CyclePath 'pre-04-baseline.json') | ConvertFrom-Json
    $ok = $true
    Get-ChildItem -Path (Join-Path $CyclePath 'tests') -Filter '*.json' | ForEach-Object {
        $obj = Get-Content $_.FullName | ConvertFrom-Json
        if ($obj.PSObject.Properties.Name -contains 'baselineRef' -and $obj.baselineRef -ne $baseline.baselineId) {
            Write-CycleLog -Level 'ERROR' -Message "Numeric provenance broken in $($_.Name)"
            $ok = $false
        }
    }
    return $ok
}

function Test-Manifest {
    $manifest = Get-Content (Join-Path $CyclePath 'manifest.sha256')
    foreach ($line in $manifest) {
        $parts = $line -split '\s+', 2
        if ($parts.Count -lt 2) { continue }
        $expected = $parts[0]
        $relPath  = $parts[1]
        $full     = Join-Path $CyclePath $relPath
        if (-not (Test-Path $full)) { Write-CycleLog -Level 'ERROR' -Message "Manifest missing file $relPath"; return $false }
        $observed = (Get-FileHash -Path $full -Algorithm SHA256).Hash.ToLower()
        if ($observed -ne $expected.ToLower()) {
            Write-CycleLog -Level 'ERROR' -Message "Manifest hash mismatch on $relPath"
            return $false
        }
    }
    return $true
}

function Test-ModuleHash {
    $expected = Get-Content (Join-Path $CyclePath 'module.sha256') | Select-Object -First 1
    $observed = (Get-FileHash -Path $PSCommandPath -Algorithm SHA256).Hash.ToLower()
    if ($observed -ne $expected.ToLower()) {
        Write-CycleLog -Level 'ERROR' -Message "Validator module hash mismatch (possible tamper)"
        return $false
    }
    return $true
}

function Test-Schema {
    # External call to a JSON Schema validator (e.g. Test-Json on PS 7.4+ with -Schema parameter).
    $cycle = Get-Content (Join-Path $CyclePath 'cycle.json') -Raw
    if (-not (Test-Json -Json $cycle -SchemaFile $SchemaPath)) {
        Write-CycleLog -Level 'ERROR' -Message "Schema validation failed"
        return $false
    }
    return $true
}

function Test-AttestationChain {
    $att = Get-Content (Join-Path $CyclePath 'attestation.json') | ConvertFrom-Json
    if ($att.signatures.Count -ne 3) { return $false }
    # Validate role distinctness
    $roles = $att.signatures.role | Sort-Object -Unique
    if ($roles.Count -ne 3) { return $false }
    # Hash-chain to prior cycle
    $priorPointer = $att.priorCycleSha256
    if ($priorPointer -ne 'GENESIS') {
        $priorPath = Join-Path (Split-Path $CyclePath -Parent) $priorPointer
        if (-not (Test-Path $priorPath)) { Write-CycleLog -Level 'ERROR' -Message "Prior-cycle hash $priorPointer not resolvable"; return $false }
    }
    return $true
}

# ---- Main -----------------------------------------------------------------

try {
    if (-not (Test-Blocker))            { exit 2 }
    if (-not (Test-Preflight))          { exit 2 }
    if (-not (Test-NumericProvenance))  { exit 2 }
    if (-not (Test-Manifest))           { exit 2 }
    if (-not (Test-ModuleHash))         { exit 2 }
    if (-not (Test-Schema))             { exit 2 }
    if (-not (Test-AttestationChain))   { exit 2 }

    # Iterate test results from cycle.json; any 'fail' yields exit 1.
    $cycle = Get-Content (Join-Path $CyclePath 'cycle.json') | ConvertFrom-Json
    $failed = $cycle.tests | Where-Object { $_.status -eq 'fail' }
    if ($failed.Count -gt 0) {
        Write-CycleLog -Level 'WARN' -Message "$($failed.Count) tests failed; cycle recorded with open findings"
        exit 1
    }

    Write-CycleLog -Level 'INFO' -Message "Cycle pass; all preflight, manifest, schema, and tests green"
    exit 0
}
catch {
    Write-CycleLog -Level 'FATAL' -Message $_.Exception.Message
    exit 2
}

The validator is fail-closed: any unhandled exception, any tamper indicator, and any unresolved BLK or PRE gate yields exit code 2. Exit code 1 is reserved for cleanly-recorded test failures with intact provenance; auditors expect to see exit-1 cycles archived alongside exit-0 cycles to evidence the firm's control posture over time.

Section 7 - Three-signature hash-chain attestation

Each cycle produces an attestation.json carrying three distinct-role signatures over the cycle hash plus a pointer to the prior cycle's hash, forming an append-only chain.

{
  "controlId": "4.7",
  "version": "v1.4",
  "cycleId": "2026-04-30T140000Z-monthly",
  "cycleSha256": "<hex64 of canonicalised cycle.json>",
  "priorCycleSha256": "<hex64 of prior cycle.json, or GENESIS>",
  "signatures": [
    {
      "role": "preparer",
      "principalUpn": "compliance.engineer@example.com",
      "signedUtc": "2026-05-03T14:11:02Z",
      "signatureValue": "<base64 detached signature>"
    },
    {
      "role": "reviewer",
      "principalUpn": "info.protection.lead@example.com",
      "signedUtc": "2026-05-03T15:42:18Z",
      "signatureValue": "<base64 detached signature>"
    },
    {
      "role": "approver",
      "principalUpn": "compliance.principal@example.com",
      "signedUtc": "2026-05-03T17:08:55Z",
      "signatureValue": "<base64 detached signature>"
    }
  ]
}

Hash-chain rules.

  1. The priorCycleSha256 field MUST resolve to the SHA-256 of the most-recent prior cycle of the same cadence (daily chains to daily, monthly chains to monthly).
  2. The very first cycle of a chain uses GENESIS as priorCycleSha256.
  3. The three roles MUST be distinct natural persons; the same UPN cannot occupy two roles in the same cycle.
  4. The approver role MUST be the FINRA 3110(a)(2) named principal (or written-supervisory-procedure designee) for the affected business line.
  5. Signature material is detached (e.g., S/MIME or PGP) over the canonicalised cycle.json bytes; the signature is verifiable by any party holding the signer's public key without retrieving any other artefact.
  6. A break in the chain (missing prior cycle, hash mismatch, role collision) is itself a finding (FIND-CHAIN) and triggers a re-attestation of the affected cycle.

Section 8 - Anti-patterns (paired to detecting test)

# Anti-pattern Why it is wrong Detected by
1 Copilot license assigned by direct-action without group inheritance Bypasses HRIS-driven group assignment; license assignment becomes invisible to LIC-01 reconciliation LIC-01, LIC-03
2 Termination workflow does not call the M365 license-removal API Terminated employee retains Copilot session capability past departure LIC-02
3 DLP for Copilot left in TestWithNotifications past the 30-day pilot Sensitive prompts and responses go through with notification only; no enforcement DLP-01
4 Sensitivity-label policy targets only pilot users, not the full Copilot-licensed population Encrypted-content exclusion bypassed for non-piloted users LABEL-01, LABEL-02
5 Just-in-time label downgrade immediately followed by Copilot prompt Indicates user-side workflow to surface protected content via Copilot LABEL-03
6 RSS configured tenant-wide without ratified governance decision Configuration drift between intent (allow-list) and effect (tenant-wide), or vice versa RSS-01
7 Allow-list site never re-attested after content classification changes Site repurposed for regulated content remains Copilot-eligible RSS-02
8 Newly-created site inherits unintended Copilot eligibility on day-zero Default-permit semantics expose nascent confidential workspaces RSS-03
9 Endpoint DLP for Edge in audit mode tenant-wide Copy-paste, screenshot, and print exfiltration unenforced EDLP-01
10 Endpoint DLP coverage gap on BYOD or unmanaged devices Licensed user becomes the path-of-least-resistance for exfiltration EDLP-02
11 Copilot Pages used for client meeting notes without retention label SEC 17a-4(f) and FINRA 4511 record-keeping gap PAGES-01, PAGES-02
12 Copilot Notebooks created outside any retention scope New surface bypasses retention; auditor finds parallel records system NOTEBOOKS-01
13 Notebook external sharing not monitored for unpermitted recipients Confidential content shared externally; client confidentiality breach NOTEBOOKS-03
14 Multi-geo cross-region grounding without permitted-matrix governance EU-resident user grounds against US-resident site; GDPR exposure MULTIGEO-01
15 PDL change without HR-validated business reason Insider-driven cross-border movement vector MULTIGEO-02
16 Synthetic negative-control suite never executed under enforcement "It works in audit-mode" provides no assurance about enforce-mode behaviour NEG-01, NEG-02, NEG-03
17 Sovereign tenant deployment lags Commercial baseline configuration Cleared-personnel users get weaker controls than commercial peers SOV-01
18 Sovereign-cloud capability gap not paired to a compensating control Implicit assumption that all clouds match Commercial; assumption is wrong SOV-02
19 DLP-to-Sentinel route never end-to-end tested under synthetic load Real incident is the first drill; Reg S-P 30-day clock starts unmonitored IR-01
20 Supervisory escalation alert never reaches the named principal FINRA Reg Notice 24-09 attestation breaks; potential AWC IR-03
21 Numeric thresholds copy-pasted from another tenant without local baseline False sense of "passing" against irrelevant numerics PRE-04, PRE-07 (validator Test-NumericProvenance)
22 Validator module modified mid-cycle without hash re-pin Tamper-undetectable mid-cycle change to assertion logic PRE-07 (validator Test-ModuleHash)
23 Three-signature attestation collapsed to one signer with role-pivot Defeats separation-of-duties intent; auditor red flag Section 7, validator Test-AttestationChain
Control / playbook Why it links to 4.7 verification Reference
1.5 - DLP and sensitivity labels PRE-02 / LABEL-01..03 / DLP-01..03 inherit label taxonomy and DLP rule shapes from 1.5 1.5 control
1.7 - Comprehensive audit logging and compliance UAL records consumed by every namespace originate in 1.7 audit configuration 1.7 control
1.11 - Conditional Access and phishing-resistant MFA LIC-01..03 reconciliation depends on the access-posture established under 1.11 1.11 control
1.14 - Data minimisation and agent scope control RSS-01..03 and the BLK-01 scope memorandum align to 1.14 minimisation principles 1.14 control
1.19 - eDiscovery for agent interactions DLP-01..03 evidence preservation and IR-01 routing share eDiscovery substrate with 1.19 1.19 control
1.21 - (Pillar 1 verification reference) Verification envelope, JSON Schema, and validator pattern derive from the 1.21 gold-standard playbook family 1.14 verification
2.1 - Managed Environments BLK-06, PAGES-01, NOTEBOOKS-01 rely on the environment scope provisioned under 2.1 2.1 control
2.6 - Model risk management (OCC 2011-12 / SR 11-7) NEG-01..03 and IR-03 outputs feed the model-risk inventory maintained under 2.6 2.6 control
4.5 - SharePoint security and compliance monitoring RSS, PAGES, NOTEBOOKS retention assertions inherit monitoring posture from 4.5 4.5 control
4.6 - Grounding scope governance RSS-01..03 inherits site-eligibility decisions captured under 4.6 grounding governance 4.6 control
4.8 - Item-level permission scanning for agent knowledge sources LABEL-01 negative-test outcomes feed the item-level permission scan inventory under 4.8 4.8 control
4.9 - Embedded file content governance NOTEBOOKS-03 external-sharing and PAGES-02 Loop checks consume the embedded-content register under 4.9 4.9 control

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