Copilot Readiness for Life Sciences: What Purview Protects, and What It Doesn’t

Microsoft describes a sensitivity label as information stored in clear text in the metadata for files and emails, which is precisely why third-party apps and services can read it. That single design decision explains most of what Purview can and cannot do. A label travels with the content wherever it is saved or stored, and each item that supports labels can carry exactly one.

Because the label is metadata rather than an access decision, the label by itself enforces nothing. Enforcement arrives from one of four other places: encryption applied by the label through the Azure Rights Management service, content markings applied by Office clients, container settings applied to a site or group, or some separate policy — data loss prevention, Copilot DLP, retention — that uses the label as a condition. Microsoft supports marking-only labels explicitly, describing the mode as labelling content without using any protection settings. A marking-only label is a clear-text tag. It is useful for reporting and for driving other policies, and it stops nobody.

Label scope is chosen when the label is created and determines both which settings you can configure and whether users see the label in a given application. The scopes are files and other data assets, emails, meetings, and groups and sites. The last of these only becomes available once container labelling has been enabled in the tenant, which is a separate one-time step that many organisations never complete.

Label priority is positional and matters in two places: it drives the justification prompt when a user downgrades a label, and it resolves auto-labelling conflicts, where Microsoft documents that the last sensitive label is selected and then, if applicable, the last sublabel. It matters a third time in Copilot, where inheritance onto generated content also follows the highest-priority rule.

There are hard tenant limits worth knowing before a taxonomy workshop. More than a thousand labels are technically supported, but a maximum of 500 applies when the label configures encryption specifying users and permissions. Microsoft’s field guidance is far tighter than the technical ceiling: real-world deployments show effectiveness is noticeably reduced when users have more than five main labels or more than five sublabels per main label, and some applications cannot display all labels when too many are published to the same user.

One behaviour surprises almost every administrator. If you delete a sensitivity label from the Purview portal, the label is not automatically removed from content and any protection settings continue to be enforced on content that had that label applied. Deleting a label is a portal cleanup action, not a decryption action.

A label is an assertion about content. Only encryption, a container setting, or a separate policy turns that assertion into a control.

These are label policy settings, not label settings, and conflating them produces rollouts that either annoy everyone or protect nothing. A default label applies to unlabeled documents, Loop items, emails, meeting invitations, new containers and Power BI content. Mandatory labelling blocks save, send or create until the user chooses. Justification on downgrade prompts the user and writes their reason into Activity Explorer.

Microsoft attaches an explicit warning to the first of these: it is usually not a good idea to select a label that applies encryption as a default label to documents. The reason is downstream breakage rather than user irritation, and it is covered in detail later on this page. The warning attached to mandatory labelling is about behaviour: without user training, these settings can result in inaccurate labelling, and they can frustrate users with frequent prompts. Both warnings come from the product documentation, not from a critic.

Justification on downgrade is on by default for files, emails and meetings, and is not available for groups and sites. In Office applications the prompt fires once per app session; in the Information Protection client it fires per file. This is a prompt, not a block. It creates an audit record and a friction point. It does not prevent a determined user from moving a document down a tier, which is the correct design — but it means the compliance value depends entirely on somebody owning the review of those events.

Label policies themselves have priority, with the highest order number winning on a setting conflict, and Microsoft asks you to allow up to 24 hours for label and policy changes to replicate. That replication window is the single most common cause of a control test that appears to fail. Test after the window, not during it.

Microsoft’s naming guidance is worth adopting verbatim because it removes an argument from the taxonomy workshop. It recommends label names that are self-descriptive and highlight relative sensitivity clearly, noting that Confidential and Restricted may leave users guessing which label is appropriate while Confidential and Highly Confidential are clearer about which is more sensitive. The company also documents its own pilot lesson: it originally used a label named Internal, found there were legitimate reasons for a document to be shared externally, and shifted to General.

This is the single most misreported area in third-party write-ups about Purview, and getting it wrong changes both the design and the licence bill. Client-side automatic labelling runs in the Office client as the user edits or composes. Service-side automatic labelling runs in the service, over data at rest in SharePoint and OneDrive and data in transit through Exchange. They are configured in different places and they behave differently.

Only the client-side mechanism can recommend a label and let the user accept or reject it; Microsoft states that in both recommend cases the user decides whether to accept or reject the label. Only the service-side mechanism supports simulation, PDFs, images and optical character recognition, nested AND/OR/NOT rule logic, location restriction, labelling of incoming external mail, and the removal of an existing label in SharePoint or OneDrive. Client-side labelling depends on the Office application version; service-side labelling does not.

The Exchange caveat is the one most summaries omit and it changes the scope of a mailbox remediation plan entirely. Microsoft writes that for Exchange, service-side auto-labelling does not include emails at rest, meaning mailboxes. Turning on service-side automatic labelling does not retro-label the archive. Similarly, DLP does not scan or match previously existing email items stored in a mailbox or archive.

There is a second scoping limit with the same shape. Auto-labelling applies your selected sensitive information types only to content created or modified after those information types were created or modified. Static back-catalogue files are simply not seen. Reaching them requires on-demand classification, which is a separate operation and a separate planning conversation.

One accuracy limit is specific to life sciences. Intellectual property, CMC documentation and discovery data are exactly the content that needs trainable classifiers rather than pattern-matching sensitive information types, and Microsoft documents that automatic labelling is not supported for Office for the web when the conditions include trainable classifiers. If a meaningful share of your authoring happens in the browser, that gap is structural rather than a tuning problem.

Tuning happens through confidence levels and instance counts rather than through the choice of classifier. Microsoft’s own worked example escalates by count: recommend a lower Confidential sublabel at one to nine matches, a broader Confidential sublabel at ten or more, and escalate to Highly Confidential at three to nine high-confidence matches or ten or more low-confidence matches. Failures have a specific home in the portal — the policy’s labelled items tab, failed view — and a policy with no visible failures is not the same as a policy that matched what you intended.

Content markings — headers, footers, watermarks — are cosmetic and reversible, and they carry their own limits: watermarks cap at 255 characters and headers and footers at 1,024, with Excel capped at 255 including invisible formatting codes. Encryption is the setting that actually decides who can open a file. It also introduces every hard dependency in the system.

Microsoft is explicit that encryption prerequisites are not validated when you configure them: when you configure encryption settings, there is no check to validate that these prerequisites are met. Azure Rights Management must be activated. Network reachability must exist. Entra cross-tenant access settings and Conditional Access must not block the flow. Exchange must be configured for Azure Rights Management, and Microsoft spells out the consequence if it is not — users cannot view encrypted emails or encrypted meeting invitations on mobile phones or in Outlook on the web, encrypted emails cannot be indexed for search, and Exchange Online DLP cannot be configured for Rights Management protection.

There are two encryption modes and the difference matters enormously downstream. Admin-defined permissions assign permission levels or custom usage rights at label-configuration time. User-defined permissions let the user decide at the point of protection. The second mode looks flexible and breaks two things: Copilot cannot process unopened files in SharePoint or OneDrive protected that way, and label inheritance is not supported when the encryption is configured for user-defined permissions.

A further behaviour catches teams that route protected documents through email. When an encrypted mail or meeting invitation carries unencrypted Office attachments, those attachments automatically inherit the same encryption settings, and Microsoft states that you cannot turn off this encryption inheritance. That is usually what you want and occasionally a surprise, particularly for a submission package assembled from mixed sources.

The usage rights inside a label are not decoration either. The right that governs whether an AI assistant can summarise content is EXTRACT, shown in the portal as copy and extract content. It becomes the central mechanism in the Copilot section below.

Data loss prevention is a policy engine with conditions and actions applied to locations. The supported locations are Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, Defender for Cloud Apps instances, Windows 10 and 11 and recent macOS devices, on-premises repositories, Fabric and Power BI workspaces, and Microsoft 365 Copilot in preview. Conditions can include a sensitivity label, a sensitive information type, or a retention label. Actions run from a policy tip through block with override and justification to a hard block or quarantine at rest.

One operational detail about DLP evidence catches investigations out. DLP alerts are available in the Microsoft Defender portal for six months, but only for 30 days in the Purview DLP alerts dashboard. If your incident process reads the Purview dashboard, your effective retention is a month.

Data Lifecycle Management and Records Management are two solutions sharing three mechanisms: retention policies, retention labels, and retention label policies, plus email archiving. Retention policies are the location-scoped cornerstone; retention labels are the exception mechanism for individual items. Microsoft directs regulated record-keeping specifically to the second solution: if you need to manage high-value items for business, legal or regulatory record-keeping requirements, use retention labels with records management. For a life-sciences company, that sentence decides where the trial master file conversation belongs.

The licensing line runs straight through the middle of this. Basic org-wide and location-wide retention policies are E3-class. Adaptive policy scopes — the query-driven scoping most enterprises actually want — are E5-class only, as are auto-applied retention labels, trainable-classifier-driven retention labels, and every setting that makes a retention label a record: event-based retention start, disposition review, mark as record or regulatory record, and automatic label change at the end of a period.

Insider Risk Management is detection and investigation, not prevention, and it is E5-class throughout. It is built pseudonymised by default with role-based access controls and its own audit log. Several policy templates are directly relevant to life sciences: data theft by departing users, data leaks including priority and risky users, risky AI usage, risky agent usage, risky browser usage, and the security policy violation set. There is also a patient data misuse template in preview, which requires the Microsoft 365 HR connector plus a healthcare-specific data connector and scores behaviour inside electronic health record systems. Forensic evidence is a separate opt-in capacity add-on sold in units of 100 GB per month.

Audit deserves its own note because it is frequently over-promised in control narratives. Audit (Standard) is E3-class and now explicitly includes audit for Microsoft Copilot interactions, though those records only generate when Copilot is licensed and in use. Audit (Premium), with one-year retention, custom retention policies, crucial events and a high-bandwidth Management Activity API, is E5-class, and ten-year retention requires a further add-on.

Service-side automatic labelling carries published ceilings, and at biotech scale at least one of them usually binds. A tenant can automatically label a maximum of 100,000 files per day. A tenant can hold a maximum of 100 automatic labelling policies. In the portal, each policy can target up to 100 explicitly included or excluded locations, with the default of all locations exempt from that count.

The limit that stops projects is the simulation ceiling. Simulation supports a maximum of four million matched files, and Microsoft states that if more than this number of files are matched from an auto-labelling policy, you cannot turn on the policy to apply the labels. A broadly scoped first policy across a mature SharePoint estate will hit that ceiling, and the remedy is to narrow the rule or the location scope rather than to request an exception.

A second constraint is geographic rather than numerical: Microsoft notes that automatic labelling is not currently available in all regions because of a backend Azure dependency. Confirm availability for your tenant region before the design assumes it.

Identity-side limits belong in the same planning conversation because access model work usually accompanies labelling work. A single Entra tenant can have a maximum of 15,000 dynamic membership groups; the body of a membership rule cannot exceed 3,072 characters; you cannot mix users and devices in one dynamic group; and you cannot manually add or remove a member of a dynamic group, because the rule is the only source of truth. Microsoft also advises minimising the use of match or contains operators because they degrade processing time.

One identity risk is worth stating explicitly, because it is the mechanism by which a carefully designed access group quietly stops meaning anything. Microsoft writes that the security of a dynamic group’s membership depends on who can modify the attributes referenced in the rule, and notes that some on-premises attributes might be configured with permissions that allow users to modify their own values. If a user can edit the attribute, the user can edit themselves into the group. Microsoft’s structural answer is that role-assignable groups already prevent this risk by requiring assigned rather than dynamic membership.

Teams reach for simulation expecting the behaviour of a database transaction that can be rolled back. It is closer to a live read-only pass with side effects, and Microsoft documents each of them.

It is not silent: simulation still generates activity alerts. If your alert policy is unscoped, the first simulation run will mail a large volume of notifications to the compliance team, and the second-order effect is that people start ignoring the channel. Scope or temporarily disable the alert policy for the simulation window, and record that you did.

A newly created policy cannot be managed for roughly 24 hours while the backend provisions, with turn on, edit and delete greyed out. A duplicated policy lands in simulation by default and does not tell you. Both behaviours produce the same support ticket, which is that the policy appears to be doing nothing.

Most importantly, simulation shows the result of a single policy, and the enforced result can differ from any single policy’s simulation because label priority resolves conflicts between policies at enforcement time. Exchange results are additionally not reproducible, because simulation evaluates mail sent and received during the run rather than a fixed corpus.

Practical parameters: a run targets 12 hours to complete, the portal displays a maximum of 100 items per site, and the CSV export ceiling is 50,000 records. Microsoft’s recommended pattern is to start with one SharePoint site or a single library, widen iteratively, and use the run to estimate production runtime rather than to prove correctness.

Simulation answers how many and roughly which. It does not answer what will actually happen when three policies and a label hierarchy interact.

Encryption is the only label setting that controls access, so a team under pressure often reaches for it first. Microsoft’s SharePoint and OneDrive documentation contains the most complete published account of what that costs, and reading it before the design workshop is the cheapest hour available to a project.

Files labelled and encrypted before the tenant enabled sensitivity labels for SharePoint and OneDrive are never recognised; the documented remedy is to download those files and upload them again to their original location. Labels that set user access to content to expire on anything other than never, and labels using Double Key Encryption, cannot be processed at all — those documents are not returned in search results even if they are updated, and the label, along with all of its sublabels if it is a parent, does not display in Office for the web. With Hold Your Own Key and Double Key Encryption, coauthoring, eDiscovery, DLP and search all fail together.

Three breakages are specific enough to predict the affected documents in a biotech. An encrypted Office file larger than 12 MB that is copied or moved to a different site can no longer be processed by SharePoint. Files containing Power Query data, data stored by custom add-ins, custom XML parts, a bibliography, or a SharePoint Document ID cannot be processed when labelled and encrypted from Office desktop applications. In practice that reads as every Excel model with a data connection, every Word document produced with a reference manager, and every document uploaded into a Document-ID-enabled library.

Collaboration and automation degrade too. For encrypted documents, printing, downloading, exporting and creating a copy are not supported in Office for the web. Office desktop and mobile applications do not support coauthoring for files labelled with encryption by default; that requires a separate enablement step. An application or service using a service principal name that downloads an encrypted file and uploads it again with a label applying different encryption settings receives an upload failure — Microsoft’s own worked example is Defender for Cloud Apps changing a label from Confidential to Highly Confidential. External-tenant guests cannot open user-defined-permission files in Office for the web even when the label grants access to their home-tenant group.

Reversing the decision is not clean either. Microsoft warns that turning the feature off later produces a mixed protection state, and that this mixed protection state can result in higher administrative overheads with help desk incidents to investigate the inconsistent behaviour, and might also be a problem for compliance requirements.

Removal policies behave counter-intuitively for the same underlying reason as automatic labelling. Simulation matches every file meeting the conditions, but on activation the service only re-evaluates files whose state has recently changed, so untouched files are skipped and on-demand classification is required to force a re-scan. A removal policy cannot override an encrypting label, a conflicting apply-policy beats a remove-policy, and removing a label that applies encryption also removes the encryption — intentional, and frequently surprising to administrators expecting unlabelled but still protected. Cross-tenant migration has its own trap that matters for biotech acquisitions and CRO transitions: after cross-tenant migration, the source-tenant label often is not recognised in the target tenant.

The most useful planning number in Microsoft’s documentation is not a limit. It is an observation about where the effort goes: Microsoft customers indicate that approximately 50% of an information protection project is business focused rather than technical, so end-user training and communication are critical to success.

The mechanics Microsoft recommends are modest and specific. Publish new labels to a few test users first, wait at least an hour, and verify the label behaviour before widening; wait at least a day before making a label available to more users. Create a working virtual team rather than assigning the rollout to one administrator. Test and tailor label names and tooltips with the people who will apply them, rather than with the people who designed them.

Ship a custom help page through the label policy learn-more URL. This is a small detail with a disproportionate effect: without it, users do not get the corresponding menu option in the Office sensitivity button at all, so the moment of confusion has no exit.

For pilots, Microsoft suggests using credit-card numbers as the training classifier even in organisations that do not process them, because the concept of these being sensitive items that need protection is easily understood by users. Production classifiers then move to what actually matters — trainable classifiers for intellectual property, exact data match for subject and employee data — once the mechanism itself is understood.

Microsoft’s current deployment model inverts the traditional advice and is worth reading in full before committing to a sequence. Its premise is that crawl-walk-run approaches stall on three specific things: defining the label taxonomy, concerns about encryption affecting users and line-of-business applications, and limited adoption through manual labelling. Its answer is to secure by default at the all-employees tier, derive file labels from site labels to reach scale quickly, train users to update labels for sharing exceptions instead of teaching them when to protect, use automatic labelling only for higher-sensitivity escalations, accelerate DLP, and use insider risk to spot suspicious labelling behaviour. Its milestone ladder puts a SharePoint default label without encryption first, extends the default to all files second, and adds encryption third.