Workdays Left
—
until Nov 30, 2026
Work Streams
5
WS1 – WS5
Outputs Complete
0/0
0%
Work Streams Approved
0
of 5
In Progress
0
work streams
AI-Assisted Engineering
Operating Assumption
Not a standalone deliverable
Progress by Artifact
SOW No. 3 — Engagement 2 Scope Summary
Discovery Policies were created in February 2026. SOW No. 3 scope is to evaluate those policies across all channels and proceed with net-new SIT builds. Five work streams carry Engagement 2 through November 30, 2026.
"SIT library is mature, validated, and expanded with net-new types mapped to CNC data domains."
Outcome Commitment — WS1: SIT Library Maturation
"Exception workflows are documented, auditable, and operated consistently across teams."
Outcome Commitment — WS2: Exception Management
"Quarantine queues are tuned, SLAs are met, and false-positive rates are measurably reduced."
Outcome Commitment — WS3: Quarantine Optimization
"Reporting is automated, AI-assisted where applicable, and ready for executive consumption on a recurring cadence."
Outcome Commitment — WS4: Reporting & Automation
"DLP policy scope covers all priority channels; channel coverage gaps are closed or formally accepted."
Outcome Commitment — WS5: DLP Expansion
⚠️
AI-Assisted Engineering — Operating Assumption, Not a Deliverable
AI-Assisted Engineering is an operating assumption embedded throughout SOW No. 3 work streams — it is not a standalone contracted deliverable. AI tooling (Microsoft Security Copilot, AI Builder, automation pipelines) accelerates SIT validation, exception triage, quarantine analysis, and reporting cadence. Without AI-assisted engineering, project deliverables could be delayed. If AI tooling becomes unavailable or loses authorization during the engagement, the Engagement Lead must be notified immediately so timeline expectations can be reset with leadership.
- Microsoft Security Copilot — alert triage acceleration, KPI enrichment, investigation summarization. Pay-as-you-go. Required for WS4 automation targets.
- AI Builder (Power Platform) — custom classification models extending SIT coverage. Note: AI Builder credits retire November 1, 2026 and migrate to Copilot Credits — plan accordingly.
- Automation pipelines — Power Automate / Logic Apps for exception routing, quarantine release workflows, and reporting triggers. Required for WS2 and WS3 SLA targets.
Work Stream 1 · SOW No. 3
SIT Library Maturation & Net-New SIT Development Validation
Discovery Policy Evaluation · All Channels · Net-New SIT Builds · Validation Testing
Not Started
Work Stream Context
Discovery Policies created February 2026 are the baseline. WS1 evaluates those policies across all channels, identifies coverage gaps, and executes net-new SIT builds to close them. All new SITs go through full validation testing before promotion to enforcement.
Work Stream Scope
- Evaluate all February 2026 Discovery Policies across Exchange, SharePoint, OneDrive, Teams, Endpoint, and Cloud App channels
- Identify SIT coverage gaps — data domains with no detection coverage or inadequate confidence thresholds
- Design and build net-new SITs for priority CNC data domains (PHI, PCI, member PII, claims data)
- Run full validation test cycle for each net-new SIT: true positive, false positive, confidence band testing
- Promote validated SITs to enforcement-ready status with documented confidence thresholds
- Maintain SIT library versioning — each SIT has a version record, test results, and promotion log
- AI-assisted SIT validation (Security Copilot / AI Builder) where tooling is available
Work Stream Outputs — Checklist
- Discovery Policy evaluation report — all channels assessed, coverage gaps documented Output
- Net-new SIT backlog prioritized — ranked by data domain risk and coverage gap severity Decision
- Net-new SITs built and unit-tested (true positive / false positive / confidence band) Output
- SIT validation test results documented per SIT — pass/fail thresholds recorded Output
- Validated SITs promoted to enforcement-ready with confidence thresholds set Config
- SIT library version register updated — version, test date, owner, promotion status per SIT Output
- Stakeholder sign-off: Security Engineering + Compliance on net-new SIT roster Decision
Notes / Status Update
→ Non-Standard Policy Dev module (SIT engineering, SIT-Pak methodology)
Work Stream 2 · SOW No. 3
Exception Management
Exception Workflows · Override Governance · RACI · Audit Trail · SLA Enforcement
Not Started
Work Stream Context
Exception management is the operational layer between policy enforcement and business continuity. Without a governed exception process, overrides accumulate silently and audit defensibility erodes. WS2 builds the full exception lifecycle — request, review, approve/deny, track, expire.
Work Stream Scope
- Define exception types: policy override, label override, quarantine release, user justification bypass
- Build the exception request-to-resolution workflow with RACI at each stage
- Define SLA targets per exception type (e.g., Critical override: 4 hours; Standard: 2 business days)
- Establish exception expiration and renewal process — no permanent exceptions without Director sign-off
- Configure audit trail requirements — every exception must produce a reviewable evidence record
- Integrate exception data into Splunk reporting (WS4 dependency)
- AI-assisted exception triage where Security Copilot is available
Work Stream Outputs — Checklist
- Exception taxonomy defined — all exception types cataloged with risk classification Output
- Exception request-to-resolution workflow documented (end-to-end, all branches) Output
- RACI matrix for exception lifecycle — requester, reviewer, approver, auditor roles defined Decision
- SLA targets set per exception type; breach escalation path documented Config
- Exception expiration and renewal process built — auto-expiry configured in system Config
- Audit trail validation — exception evidence records confirmed reviewable in Purview/Splunk Output
- Exception KPI feed live in Splunk — volume, SLA adherence, override-by-policy trending Output
- Director of Information Security sign-off on exception governance policy Decision
Notes / Status Update
→ DLP module (policy enforcement, override architecture)
→ Splunk Reporting (exception KPI feed integration)
Work Stream 3 · SOW No. 3
Quarantine Optimization
Queue Tuning · False-Positive Reduction · SLA Enforcement · Release Workflows · Metrics
Not Started
Work Stream Context
Quarantine queues are the frontline of DLP enforcement. Untuned queues generate excessive false positives, cause business disruption, and erode engineer and end-user trust in the controls. WS3 systematically reduces false-positive rates, enforces release SLAs, and establishes measurable queue health metrics.
Work Stream Scope
- Baseline quarantine queue volume, false-positive rate, and aging per policy
- Identify top false-positive sources — SIT over-matching, misconfigured thresholds, user behavior patterns
- Execute tuning cycle: adjust confidence thresholds, add exclusions, refine SIT patterns where needed
- Define and configure quarantine release workflows (authorized reviewer → release decision → audit record)
- Set SLA targets for quarantine review and release; configure breach alerting
- Establish quarantine queue health KPIs — feed into WS4 reporting
- Document tuning decisions — every threshold change logged with business justification
Work Stream Outputs — Checklist
- Quarantine queue baseline report — volume, false-positive rate, aging, per-policy breakdown Output
- Top false-positive sources identified and ranked by volume impact Output
- Tuning cycle executed — confidence thresholds and exclusions adjusted; re-test results documented Config
- False-positive rate reduction measured post-tuning (target: ≥30% reduction from baseline) Output
- Quarantine release workflow documented and configured (reviewer → decision → audit trail) Config
- SLA targets set for quarantine review/release; breach alerting configured Config
- Quarantine health KPI feed live in Splunk (WS4 dependency) Output
- Tuning decision log maintained — all threshold changes documented with justification Output
Notes / Status Update
→ DLP module (quarantine architecture, policy enforcement modes)
Work Stream 4 · SOW No. 3
Reporting, Automation & AI-Assisted Engineering
Splunk Dashboards · Power Automate · Security Copilot Integration · Executive Reporting · Recurring Cadence
Not Started
Work Stream Context
Reporting without automation is a manual burden that degrades over time. WS4 builds self-sustaining reporting pipelines, automates recurring delivery, and integrates AI-assisted engineering where Security Copilot and automation tooling are available. AI-Assisted Engineering is an operating assumption — without it, reporting automation targets may slip.
Work Stream Scope
- Mature existing Splunk dashboards — incorporate WS1 SIT metrics, WS2 exception KPIs, WS3 quarantine health
- Build Power Automate / Logic Apps workflows for recurring report delivery (20th–25th monthly cadence)
- Integrate Security Copilot AI enrichment into KPI tiles and alert summaries where licensed
- Build executive-ready reporting package: slide deck template, auto-populated from Splunk data
- Automate exception routing (WS2) and quarantine breach alerting (WS3) via Power Automate
- Document all automation flows — owner, trigger, output, failure handling
- Note: AI Builder credits retire November 1, 2026 → migrate to Copilot Credits before that date
Work Stream Outputs — Checklist
- Splunk dashboards updated — WS1/WS2/WS3 KPI feeds integrated and validated Config
- Monthly reporting automation built — Power Automate flow delivers report package 20th–25th Config
- Executive reporting template auto-populated from Splunk — tested against live data Output
- Security Copilot AI enrichment integrated into KPI tiles (if licensed) — enrichment field documented Output
- Exception routing automation live (WS2 dependency) — Power Automate flow documented Config
- Quarantine breach alerting automation live (WS3 dependency) — trigger, recipient, SLA documented Config
- All automation flows documented — owner, trigger, output, failure handling per flow Output
- AI Builder credit retirement plan confirmed — migration to Copilot Credits before November 1, 2026 Decision
Notes / Status Update
→ Splunk Reporting Architecture (dual-ingestion model, KPI marts, dashboards)
→ DSPM module (KPI matrix, AI roadmap)
Work Stream 5 · SOW No. 3
DLP Expansion — Policy Scope & Channel Coverage
Channel Coverage Gap Closure · Endpoint DLP · Cloud App · Teams · Net-New Policy Builds
Not Started
Work Stream Context
Discovery Policies created February 2026 established baseline Exchange/SharePoint/OneDrive coverage. WS5 evaluates those policies across all remaining channels — Endpoint, Teams, Cloud Apps — and builds net-new DLP policies to close confirmed coverage gaps. Channel coverage gaps not closed must be formally accepted by the Director of Information Security.
Work Stream Scope
- Evaluate February 2026 Discovery Policies against all channels: Exchange, SharePoint, OneDrive, Teams, Endpoint DLP, Microsoft Defender for Cloud Apps
- Produce channel coverage matrix — policy mapped to channel, SIT mapped to policy, enforcement mode documented
- Identify coverage gaps — channels with no policy, policies in audit-only mode with no enforcement roadmap
- Build net-new DLP policies for priority coverage gaps (leveraging WS1 validated SITs)
- Stage new policies: Audit → Warn → Block sequence with dwell-time gates between each mode
- Formally accept or close all identified coverage gaps — no gap left undocumented
- Update HIPAA/HITECH regulatory mapping for each new policy
Work Stream Outputs — Checklist
- Channel coverage matrix complete — all channels assessed against all Discovery Policies Output
- Coverage gap register produced — gap, channel, risk level, remediation owner, target date Output
- Net-new DLP policies built for priority gaps (Endpoint, Teams, Cloud Apps) using validated SITs from WS1 Config
- New policies staged through Audit → Warn → Block sequence with documented dwell-time gates Config
- All coverage gaps formally closed or formally accepted — no undocumented gaps remaining Decision
- HIPAA/HITECH regulatory mapping updated for all new policies Output
- DLP expansion summary delivered to Director of Information Security — coverage before/after comparison Output
- New policy KPI feeds live in Splunk (WS4 dependency) — enforcement events, block rates, false positives Output
Notes / Status Update
→ DLP module (policy architecture, channel coverage, enforcement modes)
→ Non-Standard Policy Dev (net-new policy build methodology)
SOW No. 3 — Engagement Notes & Cross-Stream Dependencies
Cross-stream dependency map: WS1 (SIT validation) gates WS5 (new DLP policies require validated SITs). WS2 and WS3 (exception + quarantine) feed KPI data into WS4 (reporting automation). WS4 automation targets assume AI-Assisted Engineering is operational — if Security Copilot or Power Automate access is lost, notify the Engagement Lead immediately for timeline reassessment. SOW No. 3 end date: November 30, 2026.