@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/copilot-data-readiness-protocol/references/workflow-and-output.md

@@ -0,0 +1,264 @@
+# Copilot Data Readiness Protocol — Workflow and Output Contract
+
+## Detailed Workflow
+
+### Phase 1: Oversharing Baseline
+
+**Trigger**
+An organisation is planning to enable Microsoft 365 Copilot for a new user
+population, or a periodic readiness review has been initiated.
+
+**Step 1.1 — Purview DSPM assessment**
+Run (or review the most recent) Microsoft Purview Data Security Posture
+Management (DSPM) Data Risk Assessment. Identify:
+- Sites with sensitive data exposed to broad audiences (EEEU, company-wide links)
+- Risky sharing links (Anyone links, organisation-wide links on sensitive sites)
+- Content frequently accessed by large audiences that contains sensitive data
+- Oversharing posture score
+
+If the DSPM assessment has not been run: stop. Require the data owner to
+initiate the assessment before this protocol proceeds.
+
+**Step 1.2 — SAM Content Management Assessment**
+Run (or review) the SharePoint Advanced Management (SAM) Content Management
+Assessment. Identify:
+- Sites with oversized audiences
+- EEEU usage at site or folder level
+- Broken permission inheritance (files or folders with unique permissions
+  broader than the parent site)
+- Inappropriate sharing (external sharing on internally-classified sites)
+- Inactive or ownerless sites
+
+**Step 1.3 — High-risk site inventory**
+Produce a ranked inventory of high-risk sites. Classify as:
+- Critical: sensitive content + EEEU or Anyone links
+- High: sensitive content + broad internal sharing
+- Medium: oversharing without confirmed sensitive content
+- Low: inactive/ownerless without confirmed sensitive content
+
+---
+
+### Phase 2: Interim Protections
+
+**Step 2.1 — SAM Restricted Content Discovery**
+For all critical and high-risk sites not yet remediated, apply SAM Restricted
+Content Discovery (RCD) to exclude them from Microsoft 365 Copilot discovery.
+Validate via Purview Auditing that Copilot is no longer surfacing content from
+these sites.
+
+**Step 2.2 — DLP for Copilot location**
+Configure (or confirm) Microsoft Purview DLP policies scoped to the Copilot
+location. These policies should exclude sensitive content from Copilot
+grounding. Validate policy coverage against the high-risk site inventory.
+
+**Step 2.3 — EEEU tenant-level check**
+Confirm whether EEEU is enabled at the tenant level in SharePoint. If yes:
+escalate to the SharePoint admin as a high-priority remediation item. Recommend
+disabling EEEU before Copilot enablement.
+
+---
+
+### Phase 3: Sensitivity Label Review
+
+**Step 3.1 — Label taxonomy check**
+Confirm that a sensitivity label taxonomy is configured and published in
+Microsoft Purview. Verify that labels are published to all users in the Copilot
+enablement scope.
+
+**Step 3.2 — Label coverage on high-risk sites**
+For critical and high-risk sites: assess the percentage of files that carry a
+sensitivity label. If label coverage is below the agreed threshold:
+- Draft labelling recommendations for the data owner.
+- Flag as a conditional readiness blocker (not a hard block if interim
+  protections are in place, but must be resolved before interim protections
+  are lifted).
+
+**Step 3.3 — Legacy IRM content**
+Identify any content using legacy Information Rights Management (IRM) protection.
+Flag for migration to Microsoft Purview sensitivity labels, as IRM-protected
+documents are not used in Copilot grounding.
+
+---
+
+### Phase 4: Permissions Remediation
+
+**Step 4.1 — High-risk site remediation tasks**
+For each high-risk site identified in Phase 1, produce a remediation task list:
+- Remove EEEU and company-wide sharing links
+- Rescope sharing links to approved users or groups
+- Correct broken permission inheritance at library and folder level
+- Confirm site ownership (assign or confirm a site owner)
+
+**Step 4.2 — SAM site access reviews**
+For sites where the data owner needs to manage access, initiate SAM site access
+reviews. Site owners review down to the file level and take the recommended
+actions.
+
+**Step 4.3 — Interim protection lifecycle**
+Once a site is fully remediated, remove the SAM RCD exclusion and Copilot DLP
+exclusion for that site. Validate via Purview Auditing that Copilot grounding
+now works as expected for that site.
+
+---
+
+### Phase 5: Gate 1 — Oversharing Remediation Sign-off
+
+**Required sign-off:**
+- Data owner confirms that all critical-risk sites are either remediated or have
+  accepted interim protections with a time-bound remediation commitment.
+- m365-copilot-readiness-governance-agent attests that the oversharing baseline
+  is established and the inventory is documented.
+
+If sign-off cannot be obtained: stop. Do not proceed to identity layer or DLP
+guardrails without this gate. This is a hard prerequisite for any Copilot
+enablement recommendation.
+
+---
+
+### Phase 6: Identity Layer Check
+
+**Step 6.1 — Conditional Access for Copilot users**
+Invoke m365-identity-zero-trust-agent to confirm:
+- Conditional Access policies enforce MFA for all Copilot-enabled users
+- Device compliance is required for access to Microsoft 365 Copilot workloads
+- No broad exceptions or exclusions exist for the Copilot user population
+
+**Step 6.2 — Identity layer gaps**
+If gaps are found: flag to the identity owner. Hold the Copilot enablement
+recommendation until m365-identity-zero-trust-agent confirms remediation.
+
+---
+
+### Phase 7: DLP Guardrails
+
+**Step 7.1 — DLP coverage validation**
+Confirm that Purview DLP policies:
+- Cover the Microsoft 365 Copilot location (Copilot interactions)
+- Are actively monitoring sensitive content interactions
+- Align with the sensitivity label taxonomy
+
+**Step 7.2 — Insider Risk Management**
+Confirm that Microsoft Purview Insider Risk Management (IRM) adaptive protection
+is configured to detect patterns of inappropriate or noncompliant Copilot usage
+and to automatically apply more restrictive policies to risky users.
+
+---
+
+### Phase 8: Gate 2 — Permissions Baseline
+
+Produce the permissions baseline document. This is the minimum viable sign-off
+before any Copilot enablement recommendation:
+
+| Metric | Status |
+|---|---|
+| DSPM assessment run | yes / no |
+| SAM assessment run | yes / no |
+| EEEU tenant-level status | enabled / disabled |
+| Critical-risk sites (open) | count |
+| High-risk sites (open) | count |
+| Sites with RCD interim protection | count |
+| Sensitivity label coverage (high-risk sites) | % |
+| DLP policy covers Copilot location | yes / no |
+| IRM adaptive protection configured | yes / no |
+
+---
+
+### Phase 9: Copilot Readiness Recommendation
+
+copilot-governance-maestro-agent reviews the permissions baseline and produces
+a per-user-group recommendation:
+- **Go**: oversharing baseline complete, interim protections in place or
+  remediated, identity layer confirmed, DLP guardrails active.
+- **Conditional-go**: enablement permitted for the user group with time-bound
+  remediation commitments for residual gaps.
+- **No-go**: critical prerequisites not met; Copilot must not be enabled.
+
+---
+
+### Phase 10: Human Confirmation
+
+Route the readiness recommendation to the data owner, security team, and Copilot
+programme owner for final sign-off. This protocol never enables Copilot
+autonomously.
+
+---
+
+## Decision Tree
+
+```
+Copilot enablement requested for user group
+  └── DSPM assessment run?
+        ├── No  → Stop; require data owner to run assessment
+        └── Yes → High-risk sites identified?
+                    └── Interim protections applied (RCD + DLP)?
+                          ├── No  → Apply RCD + DLP before continuing
+                          └── Yes → EEEU at tenant level?
+                                      ├── Yes → Escalate to SharePoint admin; flag as high priority
+                                      └── No  → Sensitivity label coverage meets threshold?
+                                                    ├── No  → Flag as conditional blocker; continue with interim controls
+                                                    └── Yes → Permissions remediation complete for critical sites?
+                                                                  ├── No  → Continue with RCD protection; set remediation timeline
+                                                                  └── Yes → Gate 1 sign-off obtained?
+                                                                                ├── No  → Stop
+                                                                                └── Yes → Identity layer gaps?
+                                                                                              ├── Yes → Hold; route to identity owner
+                                                                                              └── No  → DLP guardrails confirmed?
+                                                                                                            ├── No  → Hold; configure DLP
+                                                                                                            └── Yes → Gate 2 permissions baseline
+                                                                                                                          └── copilot-governance-maestro-agent readiness recommendation
+                                                                                                                                └── Human confirmation required
+```
+
+---
+
+## Output Contract
+
+### Readiness assessment record
+| Field | Type | Description |
+|---|---|---|
+| tenant_scope | string | User group or tenant segment assessed |
+| skill_id | string | `copilot-data-readiness-protocol` |
+| skill_version | string | `0.1.0` |
+| invoked_by | string | Agent or human who invoked this protocol |
+| assessment_date | ISO 8601 | Date of assessment |
+| dspm_assessment_status | enum | run / not-run |
+| sam_assessment_status | enum | run / not-run |
+| eeeu_tenant_level | enum | enabled / disabled / unknown |
+| critical_risk_sites_open | integer | Sites not yet remediated |
+| high_risk_sites_open | integer | Sites not yet remediated |
+| sites_with_rcd | integer | Sites with interim RCD protection |
+| label_coverage_rate | float | % of files on high-risk sites with sensitivity labels |
+| dlp_copilot_location | boolean | Whether DLP covers Copilot location |
+| irm_adaptive_protection | boolean | Whether IRM adaptive protection is active |
+| gate_1_status | enum | signed-off / not-signed-off |
+| gate_2_status | enum | baseline-complete / incomplete |
+| readiness_recommendation | enum | go / conditional-go / no-go |
+| open_questions | array | Unresolved questions |
+| do_not_do_list | array | Actions excluded from this protocol's scope |
+| timestamp | ISO 8601 | Protocol execution timestamp |
+
+### Gate verdicts
+| Gate | Verdict options |
+|---|---|
+| Oversharing remediation sign-off (Gate 1) | signed-off / not-signed-off |
+| Permissions baseline (Gate 2) | complete / incomplete |
+
+### Refusal record (when triggered)
+| Field | Description |
+|---|---|
+| refusal_reason | Which refusal trigger was hit |
+| escalation_target | Data owner / security team / SharePoint admin |
+| timestamp | ISO 8601 |
+
+---
+
+## Quality Assurance Notes
+- The oversharing baseline gate is unconditional. There is no path to a Copilot
+  enablement recommendation that bypasses Gate 1.
+- DSPM and SAM assessments must be run — estimated or anecdotal oversharing
+  assessments are not accepted as substitutes.
+- copilot-governance-maestro-agent's readiness recommendation is the final
+  cross-pillar artefact and cannot be bypassed by any individual agent or owner.
+- This protocol does not execute SharePoint sharing setting changes, DLP policy
+  changes, or Entra Conditional Access changes. All configuration changes
+  require the relevant service owner.

package/skills/cross-functional/data-classification-to-dlp-protocol/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: data-classification-to-dlp-protocol
+description: Use this skill when sensitive data must be discovered, classified with Microsoft Purview sensitivity labels, protected by Data Loss Prevention policies, and monitored for label adoption and DLP policy effectiveness across Microsoft 365 and Power Platform environments. Defines the end-to-end flow from data discovery through classification taxonomy design, sensitivity label deployment, DLP policy coverage, and adoption monitoring. Does not authorize the creation or modification of sensitivity labels, DLP policies, or auto-labeling policies; all production-impacting policy changes require human approval from the Purview compliance administrator and the data owner. Does not replace qualified information protection or compliance counsel.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Data Classification to DLP Protocol
+
+## Purpose
+This skill defines how sensitive data is discovered, classified using Microsoft Purview sensitivity labels, protected by Data Loss Prevention policies, and monitored for classification coverage and DLP effectiveness across Microsoft 365, Power Platform, and Dataverse environments. It ensures classification decisions are driven by a defined taxonomy before policies are deployed, that DLP coverage matches the taxonomy, and that label adoption is tracked over time. No agent creates or modifies sensitivity labels or DLP policies; those are production-impacting actions requiring the Purview compliance administrator and the data owner.
+
+## When to use
+- An organization needs to establish or review a sensitivity label taxonomy and map it to DLP policies across Microsoft 365 workloads.
+- DLP policy coverage gaps are suspected (workloads, data types, or locations not yet covered).
+- Label adoption rates need to be assessed and improvement actions identified.
+- A Power Platform or Dataverse environment needs to be assessed for data classification and DLP policy alignment.
+- A new data type (e.g., a new category of regulated personal data) needs to be classified and protected.
+
+## When NOT to use
+- Sensitivity labels or DLP policies are already deployed and fully validated — hand off to the Purview admin for ongoing monitoring.
+- The matter involves a suspected active data loss or exfiltration event — use the incident-to-remediation-protocol instead.
+- The classification requirement involves health, financial, or regulated data requiring specialist legal interpretation — escalate to the appropriate compliance or legal counsel first.
+- The Purview tenant is not yet configured — initial tenant configuration is a Purview admin task, not a protocol task.
+
+## Participating agents
+- `m365-copilot-readiness-governance-agent` — primary: assesses Microsoft 365 data classification readiness, sensitivity label taxonomy, and Copilot surface area data protection gaps
+- `power-platform-governance-dataverse-security-agent` — secondary: assesses Dataverse environment data classification, column-level security, and Power Platform DLP policy alignment
+- `m365-maestro-agent` — orchestrates cross-workload classification and DLP review; escalation path to Microsoft Purview information protection specialists (planned: purview-information-protection-specialist-agent)
+
+## Inputs required
+- List of data types in scope (e.g., customer PII, financial records, health data, intellectual property, confidential business data)
+- Workload scope (Exchange Online, SharePoint, OneDrive, Teams, Dataverse, Power Platform connectors)
+- Existing sensitivity label taxonomy (if any)
+- Existing DLP policies (if any)
+- Regulatory or contractual requirements driving classification (e.g., GDPR, HIPAA, internal policy)
+
+## Evidence required
+- Current sensitivity label list from Microsoft Purview Information Protection (exported summary)
+- Current DLP policy list and policy locations from Microsoft Purview (exported summary)
+- Label adoption report or usage data (if available)
+- Power Platform DLP connector policy list for in-scope environments
+- Data inventory or data map for in-scope workloads (if available)
+
+## Workflow
+
+1. **Ingest data types and requirements** — receive the list of data types and regulatory requirements; map each data type to a classification level (e.g., Public, Internal, Confidential, Highly Confidential, Restricted).
+2. **Review existing taxonomy** — compare the requested classification levels to the existing sensitivity label taxonomy; identify gaps (missing labels, overlapping scope, or outdated labels).
+3. **Taxonomy design recommendation** — recommend a sensitivity label taxonomy aligned to Microsoft Purview best practices (hierarchical labels, sublabels for sensitivity tiers, encryption settings per tier); do not create or modify labels — recommend for human Purview admin review.
+4. **Map labels to DLP coverage** — for each sensitivity label, identify which DLP policies cover it across which workloads; identify coverage gaps (labels with no DLP policy, workloads with no DLP policy, data types with no protective action).
+5. **Assess auto-labeling opportunity** — identify data types that qualify for auto-labeling (sensitive information types, trainable classifiers, exact data match); recommend auto-labeling policies; do not create policies.
+6. **Power Platform and Dataverse alignment** — assess Power Platform connector DLP policies for the in-scope environments; flag connectors that handle sensitive data but are not blocked or restricted by a DLP policy; assess Dataverse column security for fields containing sensitive data.
+7. **Escalation gate: classification taxonomy** — if the taxonomy is undefined, incomplete, or contradictory, pause and escalate to the data owner and compliance owner before proceeding to DLP policy review.
+8. **Escalation gate: DLP coverage** — if critical coverage gaps exist (regulated data types with no DLP policy or no protective action), stop and escalate to the Purview compliance administrator and the data owner for remediation.
+9. **Escalation gate: label adoption** — if label adoption is below the agreed threshold (defined by the compliance owner), flag as a risk item and escalate to the data owner for adoption improvement actions.
+10. **Assemble classification and DLP report** — compile: taxonomy gap list, DLP coverage map, auto-labeling opportunities, Power Platform DLP gaps, label adoption summary, and recommended next actions.
+11. **Hand off to compliance owner** — deliver report with a do-not-do list and open questions; require human sign-off before any label or policy changes are implemented.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Classification taxonomy | Taxonomy is undefined, incomplete, or contradictory | Pause; escalate to data owner + compliance owner |
+| DLP coverage | Regulated data type has no DLP policy or no protective action | Stop; escalate to Purview admin + data owner |
+| Label adoption | Adoption rate below threshold for regulated data types | Flag; escalate to data owner for adoption improvement |
+| Special-category data | Health, biometric, or sensitive personal data in scope | Confirm jurisdiction and privacy owner before proceeding |
+| Copilot surface exposure | Sensitivity label configuration affects Copilot data grounding | Escalate to m365-copilot-readiness-governance-agent for Copilot-specific DLP assessment |
+
+## Refusal triggers
+- A request is made to create, modify, or delete a sensitivity label or DLP policy without human Purview admin approval — refuse.
+- A request is made to remove encryption from a sensitivity label covering regulated data — refuse and escalate.
+- Credentials, tenant IDs, or personal data are requested to perform the classification assessment — refuse; work from sanitized taxonomy and policy summary signals only.
+- The classification taxonomy is being designed to evade a regulatory obligation (e.g., deliberately under-classifying regulated personal data) — refuse and escalate to compliance owner.
+
+## Handoff rules
+- Every handoff carries: taxonomy gap list, DLP coverage map, Power Platform DLP gaps, label adoption summary, escalations fired, open questions, and a do-not-do list.
+- No agent creates, modifies, or deletes sensitivity labels or DLP policies. Human Purview compliance administrator owns all policy changes.
+- Post-handoff, the Purview admin confirms planned policy changes and the data owner signs off on the taxonomy before implementation.
+
+## KPIs
+- Percentage of regulated data types with a defined sensitivity label and active DLP policy
+- Label adoption rate for regulated data types across in-scope workloads
+- Number of DLP coverage gaps identified and remediated per review cycle
+- Time from classification taxonomy approval to DLP policy deployment
+
+## References
+- [Learn about sensitivity labels — Microsoft Purview Information Protection](https://learn.microsoft.com/purview/sensitivity-labels)
+- [Learn about data loss prevention — Microsoft Purview](https://learn.microsoft.com/purview/dlp-learn-about-dlp)
+- [Implement information protection and data loss prevention with Microsoft Purview (training)](https://learn.microsoft.com/training/paths/purview-implement-information-protection-data-loss-prevention/)
+- [Power BI implementation planning: Information protection and DLP](https://learn.microsoft.com/power-bi/guidance/powerbi-implementation-planning-info-protection-data-loss-prevention-overview)

package/skills/cross-functional/data-classification-to-dlp-protocol/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "data-classification-to-dlp-protocol",
+  "name": "Data Classification to DLP Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Defines the end-to-end data protection flow from sensitive data discovery through Microsoft Purview sensitivity label taxonomy design, DLP policy coverage mapping, auto-labeling opportunity assessment, Power Platform and Dataverse DLP alignment, and label adoption monitoring. Enforces taxonomy completeness and DLP coverage gates before any policy recommendation proceeds to the Purview compliance administrator. Never creates or modifies labels or policies; all production-impacting changes require human sign-off from the Purview admin and data owner.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/purview/sensitivity-labels",
+    "https://learn.microsoft.com/purview/dlp-learn-about-dlp",
+    "https://learn.microsoft.com/training/paths/purview-implement-information-protection-data-loss-prevention/",
+    "https://learn.microsoft.com/power-bi/guidance/powerbi-implementation-planning-info-protection-data-loss-prevention-overview"
+  ],
+  "security_notes": "Protocol is recommendation and orchestration only — never an authorization to create, modify, or delete sensitivity labels, DLP policies, or auto-labeling policies. All production-impacting policy changes require explicit approval from the Purview compliance administrator and the data owner. Encryption settings on sensitivity labels covering regulated data must not be removed without legal and compliance owner review. Never requests credentials, tenant IDs, session tokens, or customer personal data to perform the classification assessment; works from sanitized taxonomy and policy summary signals only. Special-category personal data (health, biometric, genetic) triggers a jurisdiction and privacy owner confirmation gate. Deliberate under-classification of regulated personal data to evade regulatory obligations is a hard refusal trigger. Planned escalation target: purview-information-protection-specialist-agent (not yet built); current escalation routes to m365-maestro-agent.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/data-classification-to-dlp-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/data-classification-to-dlp-protocol/references/workflow-and-output.md

@@ -0,0 +1,211 @@
+# Data Classification to DLP Protocol — Detailed Workflow and Output Contract
+
+## Overview
+
+This document provides the step-by-step workflow, decision tree, and output contract for the `data-classification-to-dlp-protocol` skill. It is the reference for `m365-copilot-readiness-governance-agent`, `power-platform-governance-dataverse-security-agent`, `m365-maestro-agent`, and human Purview compliance administrators who need to understand the taxonomy gate, the DLP coverage mapping process, and the classification report format.
+
+---
+
+## Detailed Workflow
+
+### Phase 1 — Data Discovery and Scoping
+
+**Step 1.1 — Ingest data types and regulatory context**
+- Input: data type list (e.g., customer PII, financial records, health data, intellectual property)
+- Input: regulatory or contractual requirements (GDPR, HIPAA, PCI DSS, internal policy)
+- Map each data type to a regulatory obligation tier:
+  - Tier 1 (Restricted): special-category personal data, payment card data, health data — highest protection required
+  - Tier 2 (Highly Confidential): confidential business data, internal credentials, contracts
+  - Tier 3 (Confidential): internal business data with limited sharing scope
+  - Tier 4 (Internal): general internal use data
+  - Tier 5 (Public): publicly released data
+- Output: `data_type_register[]` with `data_type`, `regulatory_tier`, `applicable_regulations[]`
+
+**Step 1.2 — Scope workloads**
+- Identify which Microsoft 365 workloads and Power Platform environments are in scope
+- For each workload: confirm whether Microsoft Purview Information Protection labeling is enabled
+- Output: `workload_scope[]` with `service`, `labeling_enabled: true|false`, `dlp_policy_location_supported: true|false`
+
+---
+
+### Phase 2 — Taxonomy Review and Design
+
+**Step 2.1 — Review existing sensitivity label taxonomy**
+- Input: current sensitivity label list from Microsoft Purview (exported summary — no live query requiring credentials)
+- For each existing label: record `label_name`, `scope` (files, emails, meetings, schema assets), `encryption_configured: true|false`, `content_marking: true|false`, `sublabel_of`
+- Compare to data type register: identify gaps (data types with no matching label, overlapping label scopes, outdated label configurations)
+- Output: `taxonomy_gap_list[]` with `data_type`, `gap_type` (missing label, overlapping scope, outdated config), `recommended_action`
+
+**Step 2.2 — Taxonomy design recommendation**
+Microsoft Purview sensitivity label best practices applied:
+- Use a hierarchical label structure (parent label → sublabels for tiers)
+- Configure encryption for Tier 1 and Tier 2 labels using Azure Rights Management
+- Configure content marking (headers, footers, watermarks) for Tier 1–3 labels
+- Confirm auto-labeling compatibility for each label (sensitive information types, trainable classifiers, exact data match)
+- Output: `taxonomy_design_recommendation` with recommended label structure, encryption settings, and auto-labeling approach
+
+Note: taxonomy design is a recommendation only; do not create or modify labels — route to Purview compliance administrator for implementation.
+
+**Gate 1 — Classification Taxonomy Gate**
+```
+IF taxonomy_gap_list[] contains:
+  - Missing labels for Tier 1 or Tier 2 data types
+  - Contradictory label scopes (multiple labels covering same data without clear hierarchy)
+  - Labels without encryption for Tier 1 data types:
+  → PAUSE
+  → Escalate to: data owner + compliance owner
+  → Do NOT proceed to DLP coverage mapping until taxonomy gaps are resolved or explicitly accepted with risk note
+```
+
+---
+
+### Phase 3 — DLP Coverage Mapping
+
+**Step 3.1 — Map labels to DLP policies**
+For each sensitivity label:
+- Identify which DLP policies reference the label (via Content contains > Sensitivity labels condition)
+- Identify which workload locations are covered (Exchange, SharePoint, OneDrive, Teams, Devices, Copilot/Copilot Chat, Power Platform)
+- Record: `dlp_coverage_map[]` with `label_name`, `covered_locations[]`, `uncovered_locations[]`, `protective_action` (block, restrict, audit-only, warn), `policy_name`
+
+**Step 3.2 — Identify coverage gaps**
+Coverage gap types:
+- Regulated data type (Tier 1/2) with no DLP policy
+- DLP policy exists but protective action is audit-only for regulated data types (insufficient)
+- Workload location not covered (e.g., Devices or Teams not included in policy scope)
+- Power Platform connectors handling sensitive data not restricted by a connector DLP policy
+
+**Gate 2 — DLP Coverage Gate**
+```
+IF any Tier 1 or Tier 2 data type has:
+  - No DLP policy
+  - DLP policy with audit-only action (no block or restrict)
+  - Critical workload location not covered:
+  → STOP
+  → Escalate to: Purview compliance administrator + data owner
+  → Do NOT assemble final report until gaps are resolved or formally accepted with risk note by compliance owner
+```
+
+**Step 3.3 — Assess auto-labeling opportunity**
+- For each Tier 1 and Tier 2 data type: assess whether a sensitive information type (SIT), trainable classifier, or exact data match (EDM) configuration is available for auto-labeling
+- Output: `auto_labeling_opportunities[]` with `data_type`, `classifier_available: true|false`, `classifier_name`, `recommended_policy_type` (simulation first, then enforcement)
+
+---
+
+### Phase 4 — Power Platform and Dataverse Alignment
+
+**Step 4.1 — Power Platform connector DLP assessment**
+- `power-platform-governance-dataverse-security-agent` reviews:
+  - Connector classification in each in-scope environment DLP policy (Business, Non-Business, Blocked)
+  - Connectors handling Tier 1 or Tier 2 data that are classified as Non-Business or unclassified
+  - Environment groups and default DLP policies for tenant-level coverage
+- Output: `pp_dlp_gap_list[]` with `connector_name`, `current_classification`, `recommended_classification`, `risk_tier`
+
+**Step 4.2 — Dataverse column security assessment**
+- Review Dataverse column security profiles for fields containing sensitive data types
+- Flag fields with sensitive data that lack column-level security profiles
+- Output: `dataverse_security_gaps[]` with `table_name`, `column_name`, `data_type`, `column_security_enabled: true|false`
+
+**Gate 3 — Label Adoption Gate**
+```
+IF label adoption data is available AND adoption rate for Tier 1/2 data types is below threshold (defined by compliance owner):
+  → FLAG as risk item
+  → Escalate to: data owner for adoption improvement actions
+  → Record adoption gap in final report
+  → Do NOT treat low adoption as a passed state; it is an open risk
+```
+
+**Gate 4 — Special-Category Data Gate**
+```
+IF any Tier 1 data type is health, biometric, genetic, racial/ethnic origin, or other special-category:
+  → Confirm jurisdiction and privacy owner
+  → Do NOT proceed without jurisdiction confirmed
+  → Ensure applicable regulation (GDPR Art. 9, HIPAA) is reflected in label and DLP protective action
+```
+
+**Gate 5 — Copilot Surface Exposure Gate**
+```
+IF sensitivity label configuration affects Microsoft 365 Copilot or Copilot Chat data grounding:
+  → Escalate to: m365-copilot-readiness-governance-agent
+  → Ensure DLP policy for Copilot/Copilot Chat location is configured for Tier 1/2 labels
+  → Verify that Copilot cannot process files or emails with Tier 1 labels where the DLP policy blocks processing
+```
+
+---
+
+### Phase 5 — Report Assembly and Handoff
+
+**Step 5.1 — Compile classification and DLP report**
+```
+{
+  "report_id": "<uuid>",
+  "skill_id": "data-classification-to-dlp-protocol",
+  "skill_version": "0.1.0",
+  "data_types_assessed": <n>,
+  "taxonomy_gaps": <n>,
+  "dlp_coverage_gaps": <n>,
+  "pp_dlp_gaps": <n>,
+  "dataverse_security_gaps": <n>,
+  "auto_labeling_opportunities": <n>,
+  "gates_fired": ["Gate 1", "Gate 2", ...],
+  "report_status": "ready_for_review | blocked_pending_escalation",
+  "timestamp": "<ISO datetime>"
+}
+```
+
+**Step 5.2 — Attach do-not-do list**
+Every report includes:
+- Do not create, modify, or delete sensitivity labels or DLP policies without Purview compliance administrator approval.
+- Do not remove encryption from labels covering Tier 1 or Tier 2 data without legal and compliance owner review.
+- Do not deliberately under-classify regulated personal data to evade a regulatory obligation.
+- Do not treat audit-only DLP actions as sufficient protection for Tier 1 regulated data types.
+- Do not request credentials, tenant IDs, or personal data to perform the classification assessment.
+- Do not interpret this report as legal advice on regulatory compliance status.
+
+---
+
+## Decision Tree (Condensed)
+
+```
+Ingest data types + regulatory requirements
+  └─ Scope workloads
+       └─ Review existing taxonomy → identify gaps
+            └─ Gate 1: taxonomy complete? → No → PAUSE, escalate
+                 └─ Map labels to DLP policies → identify coverage gaps
+                      └─ Gate 2: DLP coverage for Tier 1/2? → No → STOP, escalate
+                           └─ Assess auto-labeling + Power Platform DLP + Dataverse security
+                                ├─ Gate 3: label adoption below threshold? → FLAG
+                                ├─ Gate 4: special-category data? → confirm jurisdiction
+                                ├─ Gate 5: Copilot surface exposure? → escalate to copilot-readiness agent
+                                └─ [All gates resolved] → Assemble report → Purview admin review + sign-off
+```
+
+---
+
+## Output Contract
+
+### Classification and DLP Report
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `report_id` | string (UUID) | Yes | Unique report identifier |
+| `skill_id` | string | Yes | Must be `data-classification-to-dlp-protocol` |
+| `skill_version` | string | Yes | Semantic version |
+| `data_type_register` | object[] | Yes | All data types with regulatory tier |
+| `taxonomy_gap_list` | object[] | Yes | Gaps in existing label taxonomy |
+| `taxonomy_design_recommendation` | object | Yes | Recommended label structure (not for direct implementation) |
+| `dlp_coverage_map` | object[] | Yes | Per-label DLP policy coverage |
+| `dlp_gap_list` | object[] | Yes | Coverage gaps requiring remediation |
+| `auto_labeling_opportunities` | object[] | Yes | Auto-labeling candidates |
+| `pp_dlp_gap_list` | object[] | Yes | Power Platform connector DLP gaps |
+| `dataverse_security_gaps` | object[] | Yes | Dataverse column security gaps |
+| `gates_fired` | string[] | Yes | Which gates fired |
+| `report_status` | enum | Yes | `ready_for_review` or `blocked_pending_escalation` |
+| `do_not_do_list` | string[] | Yes | Mandatory refusal items |
+| `open_questions` | string[] | Yes | Unresolved items for human judgment |
+| `timestamp` | string (ISO) | Yes | Report creation datetime |
+
+---
+
+## Audit Log Fields
+
+`report_id`, `skill_id`, `skill_version`, `invoked_by`, `data_types_assessed`, `taxonomy_gaps`, `dlp_coverage_gaps`, `gates_fired`, `report_status`, `timestamp`