Secure by Default sounds great - here is why most orgs should not start there

Microsoft published a Secure by Default deployment model as an alternative to the traditional crawl-walk-run approach. The core idea is simple: instead of deploying labels with no protection and gradually adding restrictions, you start with protection on by default and train users to manage exceptions.

The model has four phases:

Phase 1 - Foundational. Deploy a standard label taxonomy with Confidential - Internal as the default label for files. Every new document gets labelled Confidential automatically. DLP blocks external sharing and anyone-links on Confidential content from day one. Emails default to General.

Phase 2 - Managed. Target your most sensitive SharePoint sites. Apply default library labels so files inherit the site's sensitivity. Turn on auto-labelling for credentials. Enable DLP for unlabelled content and Adaptive Protection through Insider Risk Management.

Phase 3 - Optimised. Expand auto-labelling across the entire M365 estate. Client-side recommendations for sensitive content. Service-side auto-labelling at scale using contextual conditions like file type, site, and document properties. Retroactively label existing sites.

Phase 4 - Strategic. Operational monitoring, expand beyond M365 to Azure SQL, blob storage, and AWS S3. Lifecycle management for sites. Accountability chains for site owners.

Microsoft recommends this approach for all organisations, not just new tenants. The later phases explicitly cover retroactive labelling of existing content and migrating historical SharePoint sites. Their position is clear: this is the starting point for most customers.

The big shift from traditional approaches is that users are trained on when to remove protection rather than when to add it. If someone needs to share externally, they downgrade the label and provide justification. The default is locked down.

If you are standing up a new tenant or a new business unit with no existing content, this approach is excellent.

No existing sharing patterns to break. There are no files already shared externally, no links users rely on, no established workflows that assume open access. You are starting clean.

No change management debt. Users learn the secure way from day one. They never experience the "before" state, so there is nothing to unlearn. Downgrading a label feels normal because it is the only process they have ever known.

Label adoption is instant. When the default label is Confidential, your labelling coverage hits near-100% on day one. No need to run campaigns asking people to please label their documents.

DLP is immediately effective. Because every file has a label, DLP policies that key off labels work immediately. You do not spend months waiting for label coverage to catch up.

This is also aligned with how Microsoft runs their own tenant. They deployed secure by default internally and it works well for them. But Microsoft also has a dedicated team to manage exceptions, a mature security culture, and the resources to handle the transition. Most organisations do not.

Most organisations reading this are not greenfield. They have years of SharePoint sites, established sharing patterns, external collaboration workflows, and users who have never seen a sensitivity label. Deploying Secure by Default into that environment is a different proposition entirely.

Existing external shares start breaking. Phase 1 turns on DLP to block external sharing of Confidential content. The default label only applies to new or re-saved documents, not retroactively to everything. But the moment someone opens and saves an existing file, it picks up the Confidential label and DLP kicks in. Users who have been sharing files externally for years find their workflows breaking one document at a time. Support tickets ramp up fast.

Business processes that rely on open sharing stop. Marketing sharing brand assets with agencies. HR sharing benefits information with external providers. Finance sharing reports with auditors. All of these become blocked-by-default scenarios that require users to know how to downgrade a label - a concept they have never encountered before.

Encryption breaks line-of-business applications. The model recommends adding encryption to the Confidential - Internal label. Many third-party tools, legacy apps, and integrations cannot handle encrypted files. The model acknowledges this with an Internal Exception sublabel, but users need to know it exists and when to use it. On day one, they do not.

Change fatigue is real. If your users have never used sensitivity labels, asking them to simultaneously learn what labels are, understand a taxonomy, know when to downgrade, handle DLP policy tips, and manage encryption exceptions is too much cognitive load at once. People disengage and start looking for workarounds.

The helpdesk is not ready. Your support team needs to understand label precedence, DLP override workflows, encryption troubleshooting, and how to advise users on which label to pick. That knowledge does not exist yet because you just deployed.

Existing content creates noise. When you apply default library labels to SharePoint sites in Phase 2, every file in those libraries gets labelled on next access. Files that were appropriately shared externally now have a Confidential label and trigger DLP. You spend weeks triaging false positives instead of building your programme.

The Secure by Default model and crawl-walk-run are not mutually exclusive. The smart play is to use Secure by Default as your target state and crawl-walk-run as your path to get there. But before you touch the Purview portal, there is groundwork that has nothing to do with IT.

Align the taxonomy to your data handling policy first.

Your sensitivity labels are not an IT invention. They should map directly to the classification levels in your organisation's data handling policy. If that policy says you have Public, Internal, Confidential, and Restricted data, your labels should mirror those tiers. If the policy does not exist yet, that is your first job - work with your data protection team to create one.

Within each classification level, sublabels define the intended audience and apply different protection accordingly. Confidential - Internal keeps content encrypted for internal use. Confidential - External allows controlled sharing with named external parties. You may also need exception sublabels - for example, one that removes encryption for cases where line-of-business apps cannot handle it. The classification stays the same, but the access controls change based on who needs the content.

At the container level, SharePoint sites and Teams get a site label that sets the baseline classification. Files created in that site inherit the classification by default through library labels. Users can still apply a more specific sublabel to individual files when the audience differs from the site default.

This is not just an IT rollout.

You need three groups involved from the start. Data protection or compliance to validate that the taxonomy aligns with policy and regulatory requirements. Communications to help craft the messaging, training materials, and user guides that explain what labels mean in plain language. IT to handle the technical deployment. If IT designs the labels in isolation, they will not reflect how the business actually thinks about data, and users will not understand them.

Start with crawl - audit and educate (weeks 1 to 6)

Deploy the Secure by Default label taxonomy - it is well designed. Publish it to all users with a default label of General, not Confidential. Deploy DLP in audit mode with policy tips enabled.

Policy tips are gentle nudges that appear inline while users work. Nothing is blocked or logged as a violation. The user sees a suggestion and decides what to do. This is your chance to start teaching people about data handling before any enforcement exists.

Build policy tips around real scenarios your users will hit:

• A document labelled General or Public but DLP detects sensitive information types inside it - show a tip suggesting a more restrictive label like Confidential.
• A file labelled for internal use only but the user is about to share it externally - show a tip reminding them to review the label before sharing.
• An email with a Confidential attachment being sent to an external recipient - show a tip pointing to your internal data handling policy.

None of these block the user. They just guide people towards the right behaviour as they work. You are building muscle memory before enforcement exists. Use the audit data from this phase to understand where sensitive content flows and which business processes rely on open sharing.

Move to walk - warn with override (weeks 6 to 12)

Escalate from passive tips to warn with override. Users now see a warning they must actively acknowledge, but they can still proceed with a business justification. Start switching high-sensitivity SharePoint sites to default Confidential labels. Leave general collaboration sites on General for now.

Use this phase to build your exception process. The helpdesk learns by handling real override requests. Users are already familiar with policy tips from the crawl phase, so the warnings are not a surprise - just a step up. Review override reasons regularly. If the same justification keeps appearing, the policy is too broad or the business process needs a formal exception.

Arrive at run - secure by default (weeks 12 and beyond)

You have data, trained users, and a working exception process. But run does not mean flipping the switch for everyone on the same day. Stagger the rollout.

Start with a pilot group - a department or business unit that had the fewest overrides during the walk phase. Switch their file default to Confidential - Internal and turn on DLP block actions for that group. Monitor for a couple of weeks. How many support tickets come in? Are the exceptions manageable? Does anything break that your testing missed?

Once the pilot is stable, expand to the next group. Prioritise departments that handle the most sensitive data - Finance, Legal, HR. They benefit most from enforcement and their data is the highest risk if left unprotected.

Roll out to the wider organisation in waves. There is no reason to do this all at once. Each wave gives you a chance to catch issues before they affect the whole business. Add encryption where your testing showed it does not break critical workflows - and stagger that separately if needed, because encryption creates a different set of support issues to DLP blocks.

For new SharePoint sites and Teams created from this point forward, apply Secure by Default from the start. New sites have no legacy sharing patterns to break. This is where the greenfield advantage kicks in - use it for all new content while gradually migrating existing content.

You arrive at the same end state Microsoft recommends. The difference is you got there without a big bang, without overwhelming your helpdesk, and without users losing trust in the tooling on day one.

Weeks 1 to 2 - Align and build foundations

• Map your label taxonomy to your data handling policy with your data protection team
• Define sublabels per classification level based on intended audience (Internal, External, plus any exception sublabels you need)
• Brief communications team on upcoming rollout and agree on user messaging
• Deploy the label taxonomy with sublabels and set default label to General for files and emails
• Turn on DLP for labelled content in audit mode with policy tips enabled
• Enable sensitivity labels for SharePoint and OneDrive
• Enable co-authoring for labelled files
• Turn on audit logging and DLP analytics

Weeks 3 to 6 - Educate with policy tips

• Configure policy tips: suggest stricter labels when DLP detects sensitive content in General or Public files
• Configure policy tips: remind users to review labels before sharing internally-labelled content externally
• Review DLP audit results weekly to understand sharing patterns
• Identify SharePoint sites with the most sensitive content (use data explorer)
• Start labelling priority sites (HR, Finance, Legal, Executive) as Confidential
• Brief IT support on labels, DLP tips, and the exception process

Weeks 6 to 12 - Warn with override

• Escalate DLP from policy tips to warn-with-override
• Deploy default library labels on priority sites
• Enable client-side auto-labelling recommendations for Highly Confidential (credentials)
• Train users with targeted communications
• Monitor override rates - if over 80%, your policies are too broad

Weeks 12 to 14 - Enforce with pilot group

• Select a pilot department (ideally the fewest overrides during walk phase)
• Switch file default to Confidential - Internal for the pilot group
• Turn DLP block actions on for external sharing of Confidential content
• Monitor support tickets and exceptions for 2 weeks
• Apply Secure by Default to all new sites from this point

Weeks 14 to 20 - Roll out in waves

• Expand enforcement to the next group (Finance, Legal, HR - highest-risk data first)
• Add encryption to Confidential - Internal per wave (after verifying no LOB app breakage)
• Enable Adaptive Protection with Insider Risk Management
• Continue wave-by-wave until org-wide coverage

Weeks 20+ - Expand

• Service-side auto-labelling for existing content at scale
• Retroactively label remaining SharePoint sites
• DLP for unlabelled content on endpoints
• Expand to non-M365 data sources

Microsoft's Secure by Default model is the right destination. For greenfield tenants, it is also the right starting point. For everyone else - and that is most organisations - getting there requires the discipline of crawl-walk-run.

The organisations that succeed with Purview are not the ones that deploy the most aggressive policies on day one. They are the ones that build understanding, gather data, and earn user trust before tightening the controls. You can arrive at the same secure-by-default posture without the day-one disruption.

Start with the Secure by Default taxonomy. Deploy it the crawl-walk-run way. Apply secure-by-default to all new content immediately. Migrate existing content gradually. Within a quarter, you are in the same place - with happier users and fewer support tickets.