Deployment model summaries

Microsoft Purview deployment models — Markdown collection

Six consolidated guides based on Microsoft’s deployment-model overview, retrieved 7 September 2026. Each guide combines its introduction and all deployment steps, with meaningful image content converted to searchable text, tables or Mermaid diagrams.

Detailed review completed 7 September 2026: all 30 source pages, 11 source tables (51 data rows) and seven image assets were compared with this collection. The main deployment content was already present; detail-level omissions and a diagram-interpretation ambiguity were corrected. See the review findings and page-by-page coverage.

Choose a model

The numbers follow Microsoft’s overview order. These are alternative or complementary deployment patterns, not six mandatory phases of one deployment.

Microsoft describes these engineering-authored models as scenario-based guidance drawn from proven deployments for IT/security professionals and compliance officers. They provide a starting configuration for a business need, with feature references for implementation detail. New administrators can start with Learn about Microsoft Purview.

What is included

• 30 source pages: the overview, six introductions and all 23 step pages.
• Seven distinct image assets: six blueprints plus the separate secure-by-default thumbnail. Repeated appearances are consolidated.
• Image-only activities, outcomes, product ownership markers, estimates and architecture details.
• Configuration examples, limits and timing values, with examples distinguished from required settings.
• Source coverage and image register, including source metadata and image fingerprints.
• Supporting references, retaining the original links to feature documentation, licensing and examples.

The lightweight model’s image appears only on the overview; it is included here despite the empty blueprint section on its introduction page. No directly linked PDF was found in the collected article bodies. The overview’s additional Copilot blueprint guide remains a supporting link outside this six-model conversion.

How content was converted

This is a consolidated, reworded technical reference, not a verbatim archive. Repeated navigation, summaries and blueprint appearances are consolidated. Each deployment step links to its original Microsoft page, and each reconstructed blueprint links to its original image.

Mermaid-capable Markdown viewers render the diagrams directly. Their accompanying text/tables retain the deployment meaning in viewers without Mermaid support. No remote image needs to load to read the converted technical content.

Source differences preserved

These differences are recorded rather than silently corrected. Conversion notes are editorial explanations, not additional Microsoft requirements. Product limits, licensing names and preview status are retained as stated by the collected model pages; they are not independently refreshed deployment advice.

Terminology

For a later refresh, start with the source and image register, recheck all six introductions and 23 steps, compare the image fingerprints, and revisit the recorded discrepancies. Supporting feature pages can then be converted as a separate collection without obscuring the boundary of these six models.

Conversion checks

All six guides, 23 step anchors, 30 source-page entries and seven image mappings were checked. Local links and table structures passed validation. All six Mermaid diagrams rendered successfully and were visually reviewed; the rendered collection showed no horizontal overflow at a 1440-pixel viewport. The detailed label-settings and eight-scenario tables were also inspected visually. These checks validate the conversion, not the behavior of the Microsoft services described.

1. Secure by default with Microsoft Purview

Collection index · Microsoft introduction

Converted 7 September 2026. This is a consolidated, reworded technical reference, with diagram content reconstructed below. Microsoft’s example configurations and source-specific caveats are distinguished from conversion notes. See source coverage.

Purpose, audience and prerequisites

Use default sensitivity labels to protect ordinary work immediately, then teach users how to handle justified exceptions. This complements manual and automatic classification instead of waiting for users to classify every file correctly. Library defaults provide a route to scale, but site labels and file labels require separate configuration.

The model assumes administrators understand Information Protection, Data Loss Prevention (DLP) and Insider Risk Management (IRM). Its scope is a staged deployment pattern, not a complete project plan or exhaustive product manual. Confirm licensing for default library labeling, automatic labeling, DLP and IRM/Adaptive Protection through the source’s subscription reference.

The introductory example permits gradual adoption: start with Confidential/All Employees on SharePoint plus external-sharing DLP, expand document defaults while email inherits attachment labels, and add encryption later. Protection therefore need not be introduced everywhere in a single change.

In the first milestone, the source leaves other workloads at General. It highlights protection that travels with documents; integration with Office, Acrobat Reader, Teams, Power BI and Defender for Cloud Apps; Copilot interaction protection; and extension to Azure/AWS data. The blueprint closely follows Microsoft’s internal labeling strategy, linked in supporting references.

Blueprint converted from images

Sources: full blueprint, IMG07 and overview thumbnail, IMG01. They describe the same progression. The full image is dated 4 May 2025.

flowchart LR
    F["Foundational<br/>Defaults and new content"] --> M["Managed<br/>Priority and highly sensitive content"]
    M --> O["Optimized<br/>Historical estate and automation"]
    O --> S["Strategic<br/>Operations and wider data sources"]

The arrows reproduce stage order, not a promise that every organization can meet these estimates. Image colors distinguish stages; shield/diamond/hourglass icons encode stage, activity and effort, respectively.

Step 1 — Default labeling and protection

Source page

Label taxonomy

Confidential and Highly Confidential each have All Employees, Specific People and Internal exception children. All Employees refers to the organization-wide audience configured in the label; Specific People lets authors choose recipients; Internal exception accommodates processes that cannot use encryption while retaining sharing restrictions.

The source’s top-level Highly Confidential description says to share only with named recipients, even though its example children include All Employees. Preserve this tension when adapting the taxonomy.

Recommended settings, separated into readable tables

The following are the source’s example settings, not a universal taxonomy. F = files/other data assets, E = email, M = meetings, S = sites. “Anonymous links blocked” means the source’s Anyone with the link restriction.

Conversion notes: The Highly Confidential/Internal exception footer appears inconsistent with its parent. The source’s descriptions of permission levels and the explicit Co-Author setting are not identical; the table above preserves the actual setting rather than inventing a resolution. The table allows Private/Public, while the accompanying rollout guidance recommends Private by default. Review these differences before implementation.

User-facing descriptions retained from the source table

These descriptions supplement the settings above; they do not resolve the source’s permission-wording differences.

Default behavior and operational choices

• Documents: Confidential / All Employees. For existing SharePoint files, the source uses service-side conditions covering .pptx, .docx, .xlsx and .pdf.
• Email: General, with inheritance from labeled attachments enabled separately.
• Sites/Teams: prefer private sites with organization-shareable links rather than public discoverability. Specific people links offer a tighter default.
• Use intuitive names and aim for at most five parents with five children each. Publish specialized labels only to the relevant audience.
• Avoid mixing ambiguous names such as Confidential, Restricted and Internal. Configure default sharing-link types through site sensitivity labels to distinguish General and Confidential collaboration sites.
• Use labels as DLP conditions. Existing content already shared in a prohibited way can generate alerts and policy tips.
• Encryption/file watermarking, site privacy/Conditional Access and data-source permissions are different protections for different asset types; a label does not imply identical behavior everywhere.

Ten prerequisite checks

The source counts Teams/site enablement and mismatch notices together, and IRM analytics/indicators separately: these are the same ten source prerequisites regrouped for readability.

Exception training and priority traps

Train users on external sharing, choosing OneDrive versus a collaboration site, relabeling, encryption-incompatible add-ins and downgrade justification. Examples in the source distinguish a single file relabeled General, a partner collaboration site using General, and an Excel add-in requiring Internal exception.

In the partner-site example, an uploaded Confidential file stays protected; the notified owner can move the file or change its label. Training also explains why defaults protect information and how site/file labeling affects sharing.

A General library default cannot replace an already higher-priority Confidential / All Employees client label. Conversely, an Internal exception child placed above All Employees may not count as a downgrade and may avoid a justification prompt. Review ordering and justification together. Container labeling alone must not be presented as automatic file-label inheritance.

Expected result: published labels, document/email defaults, exception training and DLP controls for confidential sharing.

Step 2 — Protect priority and highly sensitive content

Source page

1. Prioritize leadership sites and locations identified by Content Explorer, reports or Graph queries. If the default is already Confidential/All Employees, concentrate on content needing higher protection.
2. Configure both the site label and each library’s default file label. Site owners can perform these tasks; administrators also have site-management controls.
3. Use client recommendations for lower sensitive-data thresholds, retaining user review. Use service policies for SharePoint/OneDrive files at rest and email in transit; these can also evaluate extension, size and document properties.
4. For All credentials, the source specifies Highly Confidential / Specific People on clients and Highly Confidential / All Employees for service-side policies. Preserve this use-case-specific difference from Step 1’s general table.
5. Add Content is not labeled conditions to Endpoint/Exchange DLP. For Office/PDF files and relevant endpoint actions such as cloud upload, users must classify content before sending it.
6. Enable behavioral detection for label downgrading, downloads, obfuscation and exfiltration. Start with a test Adaptive Protection policy and tune triggers/thresholds. An action merely audited for an ordinary user can be blocked for an elevated-risk user.

The source prioritizes site context before SIT-only classification: for the selected priority sites, use a service policy to apply Confidential / All Employees to Office/PDF extensions and cover existing files. Client recommendations also let users report inappropriate suggestions. The Adaptive Protection example specifically audits sharing of General files for ordinary users and blocks the same sharing for a high-risk user.

Expected result: priority content protected, fewer unlabeled outbound files and protection responsive to user risk.

Step 3 — Expand to the Microsoft 365 estate

Source page

Classification strategy

The numeric thresholds are examples, not mandatory or default values. A Confidential client default lets advanced classification focus on Highly Confidential exceptions. New/edited files and historical files need different coverage.

The source also offers a General Office-client default followed by Confidential / All Employees when saving into an appropriately configured SharePoint library. It refers to 300+ SITs and progressive addition of SITs/classifiers. For service policies, examples include template properties, filename prefixes, file size and leadership authors; for Highly Confidential content at rest, it often recommends higher thresholds than on clients to reduce false positives.

Reduce false positives using higher confidence/counts, corroborating SITs with AND, custom SITs, narrower regex patterns and word boundaries. Trainable classifiers can add document context, for example financial content plus credit-card detection. Consider EDM and document fingerprints for DLP. This page states that EDM and document fingerprinting are unavailable for auto-labeling; retain that source-scoped limitation and check the linked product reference for current workload support.

Scaling site and library configuration

The source names Set-PnPTenantSite -SensitivityLabel for sites and the REST property DefaultSensitivityLabelForLibrary for library defaults. These are reference identifiers, not a supplied executable script. Its library example links to a third-party article, retained in references.

Expected result: broader historical coverage and repeatable administration without assuming that a site label automatically relabels every existing file.

Step 4 — Operations and wider protection

Source page

Extend the taxonomy carefully for multi-tenant/trusted-domain collaboration, security-group-only tented projects, employees versus vendors, and regional requirements. Publish specialized labels only to the relevant people. Unpublishing a project label prevents new use but does not remove existing protection.

The multi-domain example is @contoso.com + @adventureworks.com, using Confidential and/or Highly Confidential encrypted labels. A tented-project example is a merger or acquisition. The user-segmentation examples include full-time employees, vendors, offshore teams and country/region teams; publish regional labels to the relevant users and align container/library defaults.

For on-premises file shares/SharePoint Server, the source points to the Information Protection scanner. It also describes migration into correctly defaulted SharePoint locations. BYOK and Double Key Encryption are outside this model’s detailed scope: the former concerns key ownership/rotation; the latter targets a small highly sensitive subset and affects collaboration.

The source describes protection beyond Microsoft 365 for Azure SQL Database, Blob Storage, ADLS Gen2 and Amazon S3 as public preview. Examples include deny-all-except storage policies and restricting labeled sensitive SQL columns. This is the status stated by the source, not an independently refreshed availability claim.

The storage example retains access for data security administrators when overly sensitive content enters a storage account; SQL policies can specify who retains access to a labeled column. The page also dates the unified Microsoft Purview portal’s general availability to July 2024, bringing former Azure Purview and Microsoft Purview experiences together.

Source discrepancies to retain

• Default container labels, library defaults and historical auto-labeling are separate tasks.
• The general auto-labeling table and the credentials-specific instruction differ for Highly Confidential/Specific People.
• The Highly Confidential/Internal exception footer and permission-description wording require validation.
• The narrative’s phrase about advanced classifiers is narrower than its subsequent discussion of EDM/fingerprinting. Model 6 distinguishes the techniques explicitly.
• Preview status and capacity limits may age independently of the blueprint image.

All supporting links for this model

2. Prevent data leaks to shadow AI

Collection index · Microsoft introduction

Converted 7 September 2026. Consolidated and reworded from the introduction, four steps and their shared blueprint. Source terminology and coverage differences are recorded explicitly.

Purpose and prerequisites

Shadow AI means AI services used without organizational approval, visibility or governance. The model addresses leakage, compliance exposure and reputational risk while retaining a path for approved AI use.

Administrators should understand Purview DLP, Defender for Cloud Apps, Entra Internet Access and Intune. The introduction names those four product families for subscription review; later steps also use IRM, Adaptive Protection, Audit, Communication Compliance, Data Lifecycle Management (DLM) and eDiscovery. Follow the source licensing reference and workload-specific references rather than assuming a single license covers the entire model.

Blueprint converted from the image

IMG02: original blueprint, dated 18 July 2025. The superscript product key is important and is preserved here:

flowchart LR
    D["Discover apps and interactions"] --> B["Block unsanctioned access"]
    B --> P["Protect data in sanctioned apps"]
    P --> G["Govern captured interactions<br/>Microsoft Edge in the blueprint"]

The image is an ordered deployment roadmap, not a packet-flow architecture. It supplies no effort estimates. Its final two columns specifically mention Microsoft Edge; do not remove that qualifier when reusing the diagram.

Step 1 — Discover applications and interactions

Source page

1. In Defender for Cloud Apps, filter the catalog by App category → Generative AI. Inspect risk scores and usage trends, then classify apps as sanctioned or unsanctioned according to organizational policy.
2. Use DSPM for AI reports and Activity Explorer to investigate interactions, not just whether a domain was visited.
3. Configure distinct discovery policies for the following signals.

Use this stage to establish a baseline before introducing blocks. Risk scores inform sanctioning; they do not replace the organization’s approval decision.

Expected result: an app inventory, observable interactions and an initial picture of risky AI usage.

Step 2 — Restrict unsanctioned access

Source page

The page warns that managed-network blocking does not prevent access from unmanaged devices or personal networks. Its later Intune section addresses managed installations; it must not be interpreted as closing every unmanaged access route.

Expected result: coordinated organizational, identity and device restrictions with verified enforcement.

Step 3 — Protect content sent to approved applications

Source page

The examples for consumer destinations are ChatGPT, consumer Microsoft Copilot, DeepSeek and Google Gemini. These are examples in the source, not a complete support list.

For Endpoint DLP, simulate first, inspect Activity Explorer and tune false positives before enforcement. Keep location, sensitive-content conditions and restrictive actions explicit in the policy.

Source reconciliation: The blueprint says “block” for network-provider protection, whereas the step’s Network Data Security section describes detection. This conversion preserves the distinction; it does not upgrade detection into a guarantee of blocking. Also, an encrypted file and plaintext copied out of an authorized application are different data paths. Do not turn the source’s broad encryption wording into a claim that encryption alone prevents every paste operation.

Expected result: layered controls for encrypted artifacts, endpoint transfers and supported browser prompts, plus network visibility.

Step 4 — Govern captured AI interactions

Source page

The source says auditing is normally enabled, but asks administrators to verify it. Keep collection, retention and legal holds distinct: an audit event is not interchangeable with a retained full-content record.

Coverage note: The article uses broad language about “all” interactions, while its diagram is narrower and the linked capability pages determine supported applications, locations and content collection. This document does not infer universal capture of every third-party prompt. Validate the relevant application/location support before using these statements as deployment acceptance criteria.

Expected result: a governed lifecycle and investigation path for the interaction records covered by the configured services.

All supporting links for this model

3. Secure and govern Microsoft 365 Copilot agents

Collection index · Microsoft introduction

Converted 7 September 2026. Consolidates the introduction, four steps and shared image. Grounding-data controls and interaction controls are kept separate.

Purpose and prerequisites

Agents can use organizational knowledge, including SharePoint and Dataverse. The model addresses excess access, unintended disclosure and stale answers by protecting both knowledge sources and the subsequent interaction lifecycle.

The intended administrator understands Information Protection, DLP, IRM, DLM and Compliance Manager. The introduction also lists Communication Compliance and eDiscovery among the capabilities requiring subscription review. Step 4 adds Data Security Investigations (DSI). Consult the source licensing link and the capability references for the features actually deployed.

The model is a staged implementation pattern. Its outcomes are objectives for configured controls, not a claim that all labeled data is automatically excluded from every agent.

Blueprint converted from the image

IMG03: source image, dated 26 August 2025.

flowchart LR
    D["Discover risks"] --> K["Protect grounding data"]
    K --> I["Protect interactions"]
    I --> G["Govern interaction records"]

The image uses SPO for SharePoint Online, DLM for Data Lifecycle Management, IRM for Insider Risk Management, CC for Communication Compliance, DSI for Data Security Investigations and CM for Compliance Manager. No effort estimate is shown.

The grounding-data outcome in the image and introduction is stronger than the qualified table above: it states that sensitive grounding information is not used as a knowledge source. That is the source’s deployment objective; the selected policies and supported sources determine which content is actually excluded.

Step 1 — Discover risk and gaps

Source page

Auditing is usually active already, but the source explicitly calls for verification. Discover and remediate knowledge-source exposure before broad agent rollout.

Expected result: a baseline for access, sensitive content, risky use and regulatory gaps.

Step 2 — Protect grounding data

Source page

1. Apply appropriate sensitivity labels to supported SharePoint and Dataverse sources. The page describes responses respecting user permissions and displaying the most restrictive label among referenced content. See Model 1 for the labeling deployment pattern.
2. Use DLM policies on SharePoint sites and OneDrive accounts used for grounding. Set retention/deletion periods to the organization’s requirements so obsolete material can be removed appropriately.
3. Create a custom DLP policy at the Microsoft 365 Copilot location. Match selected labels, such as Highly Confidential, and restrict processing of matching files.
4. Simulate the restriction first and inspect affected files in Activity Explorer before enforcement.
5. Configure Dataverse data policies for the supported knowledge-source scenario.
6. Add SharePoint/OneDrive oversharing DLP for anonymous/“anyone” links, including labeled and unlabeled content.

Source caveat: The page’s Dataverse data-policy section links to the general Copilot DLP article and supplies no detailed Dataverse procedure. This conversion retains that gap rather than inventing portal steps or treating all agent connectors identically. Lifecycle deletion must also be reconciled with the organization’s retention obligations; the source does not specify a universal “stale” age.

Expected result: controlled grounding sources, lifecycle management and explicit processing restrictions.

Step 3 — Protect interactions

Source page

The source describes automatic inheritance and conversation-level protection. Preserve the distinction between sensitivity displayed in a conversation, the permissions on source files, and the DLP restriction selected for the workload.

Specifically, the page says a label is displayed for the entire conversation, informs users of its sensitivity, and has its associated protection policies enforced on the conversation. These are the page’s claims; the verification procedure above checks the displayed label and does not by itself demonstrate enforcement of every protection. Its risky-AI examples include attempts to access sensitive content and exfiltration through prompts.

Source caveat: This page discusses sensitive prompts not being used in web queries alongside file-processing restrictions. Those should not be collapsed into one configuration switch; the linked Copilot DLP reference defines which conditions/actions cover each case. The conversion does not infer that every reference restriction automatically configures prompt inspection.

Expected result: visible source sensitivity, restricted processing for matched references and detection of risky agent use.

Step 4 — Govern interaction records

Source page

Compliance Manager appears in both initial discovery and ongoing governance. The image places it in the final stage; the step pages use it throughout. Both placements are retained.

Expected result: retained records, operational review, investigation and ongoing governance for the supported agent interactions.

Reading the model correctly

• Permission to read a file and permission for Copilot to process it are separate decisions in the source’s DLP example.
• Labeling, connector/workload support, retention and prompt inspection are not interchangeable features.
• The original image’s absolute outcome wording is a deployment objective, not proof that every sensitive grounding item is excluded.
• The source supplies no rollout-duration estimate or comprehensive per-agent support matrix; none is invented here.

All supporting links for this model

4. Deploy and use Data Security Posture Management

Collection index · Microsoft introduction

Converted 7 September 2026. The source image is a capability/data-flow diagram, not the same four-column roadmap used by several other models. Its architecture and operating cycle are therefore represented separately.

Purpose and prerequisites

DSPM combines data-security signals to reveal exposed sensitive assets, risky activity and recommended policy changes. It brings together Information Protection, DLP and IRM; Security Copilot provides an optional investigation experience.

The model assumes familiarity with those Purview solutions. Check the source subscription reference, including Security Copilot entitlement if used. A labeling schema improves the analysis but is not a DSPM prerequisite in Step 1. The four steps end in a recurring monthly review cycle rather than a one-time configuration milestone.

Blueprint — architecture converted to Mermaid

IMG04: original DSPM image. It has no visible revision date or effort estimate.

flowchart LR
    subgraph Inputs["Analytics inputs"]
        DLP["Data Loss Prevention"]
        IP["Information Protection"]
        IRM["Insider Risk Management"]
    end
    DLP --> DSPM["DSPM<br/>Correlated data-security context"]
    IP --> DSPM
    IRM --> DSPM
    DSPM --> Discover["Discover<br/>Trends and analytics reports"]
    DSPM --> Protect["Protect<br/>Recommendations for DLP and IRM"]
    DSPM --> Investigate["Investigate<br/>Security Copilot"]

The bottom ribbon in the image shows this operating sequence:

flowchart LR
    A["Opt in to analytics"] --> B["Evaluate insights and act"]
    B --> C["Investigate with Security Copilot"]
    C --> D["Create recommended policies"]
    D --> E["Track posture through reports and trends"]

Security Copilot remains optional in the step pages even though it appears in the image ribbon. The monthly repeat instruction comes from the prose, not an inferred arrow in the image.

The source architecture uses connecting lines between capability groups. Arrowheads in the reconstruction express the logical input/output interpretation; they are not evidence of network direction, a direct API integration, or a required execution order between Discover, Protect and Investigate.

Step 1 — Establish foundations

Source page

Do not turn the recommendation to configure labels into a mandatory DSPM enablement condition. Likewise, omitting Security Copilot does not remove the report/recommendation portions of this model.

Expected result: a prioritized classification/risk context and, if chosen, investigation access.

Step 2 — Access and analytics

Source page

Roles stated by the model

Select the least privileged role appropriate to the task. This is the model’s list, not a newly validated complete role matrix.

Enablement sequence

1. Opt in to DSPM to enable DLP and IRM analytics together, or enable those analytics independently.
2. Confirm each solution’s settings show analytics enabled.
3. Confirm the automatic initial scan has begun.
4. Allow up to three days for the initial scan, as stated in the page.

Expected result: appropriate access and a baseline analysis in progress.

Step 3 — Reports, trends and recommendations

Source page

Use filtering, review and export to assess the findings. The page says recommendations older than 30 days are removed and recommends reviewing them at least every 30 days. A recommendation’s absence after that interval is not evidence that the underlying risk was remediated.

Open Reports for the two analytics reports; the historical trends are on Overview. The source compares the unprotected-assets report with Content Explorer while describing its scope as the entire data estate.

Expected result: an understood risk baseline and prioritized actions rather than an unread dashboard.

Step 4 — Act and investigate

Source page

Policy creation and timing

Open Recommendations, select a finding, choose DLP or IRM policy creation, complete the guided settings, review and submit. Existing policies can be updated instead. The source says policy creation takes minutes and a triggering event takes about 24 hours to take effect. The policies then appear in their respective solution pages; further recommendations may follow.

Investigation entry points

• Choose Show Users Involved in a recommendation and ask follow-up questions.
• Open Security Copilot from the DSPM page for a broader user/activity investigation.
• Example investigation topics from the source: external sharing of sensitive files; cloud uploads during the preceding week; a particular user’s data activity over the preceding 30 days. These are reworded topics, not an exact prompt transcript.

Monthly operating cycle

Review reports/trends → reassess recommendations → create or update DLP/IRM policies → investigate flagged activity → evaluate residual risk. Repeat monthly and use the results to tune controls.

Timing reference

These values are retained from the model; consult current product documentation for a live deployment.

All supporting links for this model

5. Lightweight guide to mitigate data leakage

Collection index · Microsoft introduction

Converted 7 September 2026. This model has three, not four, steps. Its blueprint is present on the overview page but absent beneath the introduction’s blueprint heading; the overview image is included in the conversion below.

Purpose and prerequisites

Establish a small set of label, sharing and audit controls, then extend into endpoint protection, classification and adaptive enforcement. The staged Good / Better / Best approach is intended to reduce initial configuration effort while allowing later expansion.

Administrators should understand Information Protection and DLP; the final stage adds IRM and Adaptive Protection. Licensing names below reproduce the model’s statements, not an independently verified entitlement assessment. Consult the source subscription reference before deployment.

Blueprint converted to a comparison table

IMG05: original overview image. No revision date is printed.

The image footnote says effort must be adapted to tenant size and organizational complexity. These are suggested efforts, not guaranteed elapsed delivery times or values to add into a fixed project schedule.

flowchart LR
    G["Good<br/>Labels, baseline DLP and Audit"] --> B["Better<br/>Custom detection and endpoint coverage"]
    B --> X["Best<br/>Encryption, historical labeling and adaptive controls"]

Step 1 — Good: foundational controls

Source page

Configuration distinction: Enabling SharePoint/OneDrive label support, applying a site label and setting a library’s default file label are separate operations. The source’s inheritance wording should not be read as automatic propagation merely because the tenant feature was enabled.

Expected result: visible labels and defaults, baseline external-sharing protection, and auditing.

Step 2 — Better: custom classification and endpoint coverage

Source page

Custom SIT examples from the page

Configure names/descriptions, confidence, primary element, character proximity and supporting evidence; save/publish the SIT.

Workload configuration

Image/prose difference: The Better column depicts automatic client labeling, but the step explicitly starts with recommendations. Use the step’s initial rollout setting and retain automatic application as the broader goal shown by the image.

Source detail to verify: The Teams section lists label-based detection together with message-location conditions, and the email section mentions attached/linked files broadly. The applicable workload reference determines supported combinations; this conversion does not invent support for every condition in every location.

Expected result: organization-specific detection, user-facing labeling recommendations and broader DLP coverage.

Step 3 — Best: encryption and adaptive improvement

Source page

Apply service labeling to historical SharePoint/OneDrive files and Exchange messages in transit; this is distinct from client labeling of new/edited content. Apply encryption to the intended high-sensitivity classifications and test authorized-user access and business-process impact.

Expected result: encryption where selected, greater historical classification coverage and risk-sensitive DLP/access decisions.

Source-specific cautions

• The licensing tiers above are the article’s wording. “Or above” is not a feature-by-feature license comparison.
• The image describes the maturity destination; the step pages contain the actual initial recommendation/simulation choices.
• The 7-day labeling option and 15-day email-DLP option belong to different policy workflows.
• A sensitivity label alone does not enable encryption, and a container label alone does not relabel all stored documents.

All supporting links for this model

6. Reduce false positives with SITs and advanced classifiers

Collection index · Microsoft introduction

Converted 7 September 2026. The image compares four classification approaches. Tables preserve this comparison without implying that every document must pass through all four technologies.

Purpose and prerequisites

Reduce incorrect detections while maintaining coverage of sensitive information. False positives create alert fatigue, investigation costs, unnecessary access restrictions and reduced user trust. The guide assumes familiarity with DLP and Purview classification.

Blueprint — image converted to a comparison table

IMG06: original classifier blueprint. The image has no visible revision date. Effort values are the blueprint’s estimates, not fixed service timings.

Scenario selection — all eight source scenarios

PII means personally identifiable information; PHI means protected health information; OCR means optical character recognition; LoB means line of business.

The customer/patient row’s employee-ID example is retained as a source oddity; choose an identifier that actually corresponds to the intended population.

Step 1 — Pattern-based detection

Source page

Map the sensitive data types and their locations before selecting classifiers. Start with built-in SITs, clone and customize where appropriate, or create a custom SIT when no existing definition fits. Include necessary variants in one definition: a date-of-birth pattern may need both DD/MM/YYYY and MM/DD/YYYY.

Use on-demand classification against a limited, representative sample to iterate. For broad PII coverage, a DLP rule can combine SSN, driving-license and passport SITs with OR. This is a coverage choice; requiring corroborating evidence with AND, as in Model 1, serves a different purpose.

Primary element choices

Precision controls

• Add supporting evidence: DOB or DateOfBirth near a date helps distinguish birth dates from email timestamps.
• The model recommends 300 characters of proximity for a new custom SIT. Avoid unlimited document-wide proximity; for large tabular content it points to the PowerShell RelaxProximity option.
• Assign higher confidence to restrictive patterns with stronger corroboration, and lower confidence where evidence is weak or absent.
• Refine included/excluded text, patterns, prefixes and suffixes.
• Use the SIT test function and Content Explorer to inspect actual matches.
• Submit match/nonmatch feedback for SharePoint and OneDrive items. Sending Microsoft a redacted item is an optional additional feedback step.

Expected result: usable SIT definitions with a measured feedback loop, not simply a larger list of patterns.

Step 2 — Exact Data Match

Source page

Upload a sample file to define the EDM schema through the provided automation. Identify columns for primary values and corroborating evidence. Choose a strongly patterned primary field, such as an SSN or payment-card number, and map it to a suitably restrictive SIT.

A loose primary SIT can generate excessive candidate matches, causing throttling/timeouts and missed detections. The source identifies these specific hazards:

Configure punctuation/delimiter normalization where appropriate. For example, +11234567890, (+1) 123 456 7890 and +1 123-456-7890 should match the same reference phone number when those differences are intentionally ignored.

Expected result: known values detected precisely, with deliberate normalization and confidence settings.

Step 3 — Trainable classifiers

Source page

1. Evaluate Microsoft’s pretrained classifiers against representative content. Use a suitable one directly in policies.
2. If its accuracy or coverage is insufficient, create a custom classifier with varied positive and negative examples.
3. Build positive samples from correctly identified documents, remove false matches and add relevant documents found manually.
4. Use unrelated material and the original classifier’s false matches as negative examples. Include the organization’s vocabulary, names and document variations.
5. Review match/nonmatch feedback continuously. For an inaccurate custom classifier, the source recommends removing and recreating it with a larger, better-curated dataset.
6. Combine a TC with a SIT when both document context and a precise pattern are needed.

The step’s hybrid example pairs the pretrained Business Context classifier with a custom SIT identifying contract amounts above $100K. The image describes a contract classifier more generally. Preserve the example’s intent, but verify the classifier name in the current catalog before configuring a policy; this conversion does not silently substitute a different classifier.

Expected result: contextual detection supported by representative samples and, where useful, pattern-based corroboration.

Step 4 — Document fingerprinting

Source page

Start with a small number of known, valuable or highly sensitive documents/templates. A full match detects an identical version; a high match tolerates limited differences. Partial matching supports modified templates and excerpts.

Example thresholds from the page

These percentages are an example configuration, not universal defaults. Raise the minimum match threshold when false positives dominate; lower it when legitimate variants are missed. Inspect real matched items before adjusting.

Choose exact matching for structured critical documents where variation must not be accepted. Otherwise, a high percentage can be more useful than 100%: PDF conversion, added headers/footers and file-format upgrades can alter a document enough to break an exact match.

For the exact-match case, the source specifically instructs setting the high confidence level value to exact. This is a separate configuration choice from the example’s 90% high-confidence threshold; selecting high confidence alone must not be read as selecting an exact match.

Expected result: known documents recognized at a consciously chosen tolerance, with false negatives considered alongside false positives.

DLP tuning across all four approaches

A classifier match is an input to a policy decision. Increase the minimum instance count when isolated/trivial matches should not trigger action. Use a lower count, including a single occurrence, when the data’s sensitivity requires it. In Content Explorer, review data types, locations, occurrence counts and confidence together. Select and combine technologies by scenario rather than assuming one method is universally best.

Source-specific cautions

• Effort estimates are separate from product limits, confidence percentages and match counts.
• The source’s dictionary limit, language-matching advice, classifier name and PowerShell option are preserved as published; linked feature references are the place to check current applicability.
• Requiring full names as corroboration does not imply that All Full Names is a good EDM primary element.
• No exact sample-size requirement for custom classifiers is given in these model pages; none has been invented here.

All supporting links for this model

Supporting references

Collection index · Model-page and image coverage

These links are extracted from the article bodies. Repeated model navigation is covered by SOURCES.md; the remaining references are deduplicated within each model. Link labels retain the source’s terminology. A listing does not mean that the target’s full contents were converted or its current feature claims verified.

Overview

The Secure and Govern Microsoft 365 Copilot blueprint short link resolved during collection to foundational deployment guidance. It is additional reading beyond the six selected models.

1. Secure by default with Microsoft Purview

Converted guide

The secure-by-default blueprint’s footer also prints a deployment-guide short link. This is an image-embedded reference in IMG01/IMG07, separate from the article-body links below.

2. Prevent data leaks to shadow AI

Converted guide

3. Secure and govern Microsoft 365 Copilot agents

Converted guide

4. Deploy and use Data Security Posture Management

Converted guide

5. Lightweight guide to mitigate data leakage

Converted guide

6. Reduce false positives with SITs and advanced classifiers

Converted guide

Deployment conversion review — 7 September 2026

Collection index · Source register · Supporting references

The collection was substantially accurate, but its summaries did omit some source detail. All six guides have now been reviewed against the live Microsoft deployment models and amended where needed. No entire model, deployment step, source table, scenario row or blueprint activity was missing. No further material conversion discrepancy was identified after the corrections below. This conclusion concerns fidelity to these deployment models; it does not resolve contradictions within Microsoft’s guidance or independently certify product behavior.

Scope and evidence

The review covered the overview, six introductions and all 23 step pages: 30 pages total. It included 11 HTML tables with 51 data rows, seven distinct image assets representing six blueprints, all accompanying qualifiers and numeric values, and the 96 unique supporting article-body URLs with their per-model source-page attribution.

Each article was read in full through the Microsoft Learn MCP and compared with its consolidated guide. Raw HTML was independently fetched to verify tables, image/link inventories and publisher metadata. All seven images were visually inspected, including both secure-by-default resolutions. Their SHA-256 hashes exactly match the original source register; all source pages retain the recorded March/June 2026 metadata. The four classification methods were checked as alternatives/combinations, and the DSPM architecture was checked separately from its operating sequence.

The original conversions are preserved in originals. The evidence manifest records fetched page URLs, metadata, hashes, headings, images and links. Source HTML, MCP Markdown and source images are stored alongside it. Article procedures were treated as material to review, not instructions to change a tenant or execute deployment actions.

Corrections and clarifications

Page-by-page comparison

“Pass” means no substantive conversion change was needed for that page. “Expanded” means the corresponding detail was restored or clarified as described above. Page names and direct source URLs are mapped in SOURCES.md.

Image comparison

Source issues retained for implementation review

These are issues in the source guidance, not remaining conversion omissions:

• Secure by default: conflicting user-description/permission wording, the Highly Confidential/Internal exception footer, named-recipient versus All Employees wording, and different general/credential-specific auto-labeling choices. Container, library and historical-file labeling remain separate operations.
• Shadow AI: image network blocking versus step-page detection; broad claims about encryption/paste protection and capture of all AI interactions; unmanaged-access limitations. The conversion preserves source claims and qualifiers without promising universal enforcement.
• Copilot agents: no detailed Dataverse data-policy procedure; conversation-level protection assertions; file-processing restrictions described alongside prompt/web-query restrictions. A displayed sensitivity label alone does not validate all of these behaviors.
• DSPM: labels and Security Copilot are recommended/optional despite appearing in the foundational path. Role names and processing timings are retained as model statements.
• Lightweight: image automatic client labeling versus initial recommendations in the step; Teams label/condition support; attached-or-linked-file inheritance claims; source licensing names. None is silently rewritten into a newly verified product entitlement or support matrix.
• False positives: Business Context classifier name; employee-ID example in the customer/patient row; source-specific dictionary/proximity values; exact matching versus percentage confidence examples.

The wider product documentation, license entitlements, API behavior and third-party examples were not recursively reviewed. Preview status and limits may differ from current product documentation. Decorative imagery, repeated navigation and repeated summaries are intentionally consolidated.

Validation and review artifacts

The validation results record local file/anchor checks, source coverage, article-reference attribution, source tables and image fingerprints. The render results record Mermaid rendering and horizontal-overflow checks for the six updated guides at a 1440-pixel viewport. The rendered files provide HTML and screenshots for visual inspection.

The conversion diff compares the preserved original Markdown with the reviewed collection. These are documentation checks; no Microsoft tenant configuration was executed or tested.

Source coverage

Collection index

Retrieved 7 September 2026 from Microsoft Learn. Coverage: 30 pages (overview + six introductions + 23 steps) and seven distinct image URLs. Repeated blueprint appearances were consolidated; the secure-by-default thumbnail and full-resolution image are separate source assets for the same blueprint.

All 30 live pages carried ms.date 2026-03-31 and updated_at 2026-06-15T22:35:00Z in their HTML metadata. These are the publisher’s metadata values, not proof that every configuration detail or diagram was revised then. Visible image dates are recorded separately.

The detailed conversion review re-fetched all 30 pages and seven images on 7 September 2026 and confirmed those metadata values and all seven image fingerprints. Original conversion files, fetched HTML, Learn MCP Markdown, images and the retrieval manifest are retained under Resources/purview-review-2026-09-07/ for comparison. Raw HTML is authoritative for links: the Learn MCP Markdown response omits the overview’s supplementary Copilot blueprint link, which is present in HTML and retained in REFERENCES.md.

Overview

Microsoft Purview deployment models supplies the six-model selection, navigation and overview images. Its model index is reproduced structurally in the collection index.

1. Secure by default with Microsoft Purview

2. Prevent data leaks to shadow AI

3. Secure and govern Microsoft 365 Copilot agents

4. Deploy and use Data Security Posture Management

5. Lightweight guide to mitigate data leakage

6. Reduce false positives with SITs and advanced classifiers

Image register

Every distinct image was inspected visually. Meaningful activities, outcomes, effort, ownership markers and architecture relationships are transcribed in the destination guide. Repeated branding and decorative icons are not reproduced as raster assets.

ID	Original asset	Appears on	Conversion	Visible date
IMG01	IMG01.png	Overview	Stage/activity/outcome/effort table + stage flow	Thumbnail; see full image
IMG02	IMG02.png	Overview; Introduction; Step 1; Step 2; Step 3; Step 4	Product marker key + ownership/activity/outcome table + stage flow	18 July 2025
IMG03	IMG03.png	Overview; Introduction; Step 1; Step 2; Step 3; Step 4	Activity/outcome table + acronym key + stage flow	26 August 2025
IMG04	IMG04.png	Overview; Introduction; Step 1; Step 2; Step 3; Step 4	Architecture Mermaid + context table + operating-sequence Mermaid	None
IMG05	IMG05.jpg	Overview	Good/Better/Best table + effort + stage flow	None
IMG06	IMG06.png	Overview; Introduction; Step 1; Step 2; Step 3; Step 4	Technology/activity/outcome/effort comparison table	None
IMG07	IMG07.png	Introduction; Step 1; Step 2; Step 3; Step 4	Full version of IMG01; same conversion	4 May 2025

Image fingerprints

SHA-256 fingerprints identify the exact image bytes inspected. They can help detect source-image changes during a later refresh.

IMG01/IMG07 also contain a deployment-guide URL in their footer; this image-embedded link is now retained separately from the article-body reference tables.

Boundaries of this conversion

• All model introductions and step pages linked from the overview are included.
• No direct PDF asset was linked from the collected article bodies. The broader Copilot blueprint link leads to another documentation guide; it is retained in supporting references, outside these six models.
• Supporting product documentation, licensing pages and third-party examples remain links. They have not been recursively converted or independently reconciled with the deployment-model guidance.
• Editorial notes identify inferred distinctions, source inconsistencies and missing procedures. They are not presented as additional Microsoft requirements.
• This is a consolidated, reworded reference, not an archived verbatim copy. Source navigation and repeated summaries/images are consolidated while configuration facts and examples are retained.