Only some of the principles are configuration questions
The Personal Data Protection Act 2010 sets out seven personal data protection principles. The Department of Personal Data Protection describes them on its principles of personal data protection page: the General Principle, the Notice and Choice Principle, the Disclosure Principle, the Security Principle, the Retention Principle, the Data Integrity Principle and the Access Principle.
Read as a set, they divide unevenly when translated into technology. The Notice and Choice, Disclosure and Access Principles are obligations about what an organisation tells data subjects and what it does when they ask; no tenant setting produces a notice, secures a consent, or answers an access request on an organisation's behalf. The Data Integrity Principle, concerned with data being accurate, complete and up to date for the purpose it is processed for, is largely a question about the source systems that create the data rather than about the collaboration platform that stores copies of it.
Two principles do have a substantial configuration surface. The Security Principle, described as taking steps to ensure data is secure and not modified, misused, or given to unauthorised parties, maps onto classification and access control. The Retention Principle, that personal data is not kept longer than necessary, maps onto lifecycle controls. That is where Microsoft 365 configuration decisions genuinely bite, and it is also where a generic overview stops being useful.
SCSB's working position is that describing what a control does is legitimate and useful, while describing a configuration as compliance is neither. Nothing below establishes that any configuration satisfies the Act.
A label taxonomy is a naming decision that becomes an enforcement decision
Microsoft's documentation on sensitivity labels describes a label as customisable, stored in clear text in the item's metadata, and persistent, so it travels with the content. A single item carries one sensitivity label, though a document can hold both a sensitivity label and a retention label.
What a label can do is broader than most taxonomies assume. It can apply encryption that restricts which users or groups may perform which actions, apply headers, footers and watermarks, protect containers such as sites and groups by controlling privacy settings, external access and sharing, set the default sharing link type in SharePoint and OneDrive, and be applied automatically or recommended to the user through a policy tip. Labels also have a scope, chosen at creation, covering files and other data assets, emails, meetings, and groups and sites, and the groups-and-sites scope only becomes available once labels for containers have been enabled.
Two constraints shape the taxonomy more than any principle does. Order is priority: Microsoft states that the most restrictive label should sit at the bottom of the list and the least restrictive at the top, and that ordering governs the justification prompt when a user moves an item to a lower sensitivity. And size is a practical limit rather than a technical one: Microsoft notes that a tenant can hold well over a thousand labels, but that real-world deployments show effectiveness is noticeably reduced when users have more than about five main labels, or more than five sublabels under a main label.
That combination produces the most common design error in a privacy-driven rollout. Personal data is a category, not a sensitivity level, and building a label for each category of personal data an organisation holds produces a list users cannot navigate and will not apply accurately. The more workable decision is usually a small level-based taxonomy in which personal data sits at a defined level, with the category distinction carried by the policies that detect it rather than by the label a user has to choose. Microsoft's own guidance points the same way, suggesting starting from a small set of familiar level names and using sublabels to group similar variants.
Policy scope is the second decision, and simulation mode is how it is made safely
Microsoft's documentation on data loss prevention lists the locations a policy can be scoped to, including Exchange email, SharePoint sites, OneDrive accounts, Microsoft Teams chat and channel messages, managed devices, on-premises repositories and connected cloud app instances. Microsoft is explicit that each of these has different prerequisites: some, such as Exchange Online, are brought under a policy simply by configuring one, while others, such as on-premises file repositories, require the information protection scanner to be deployed first.
An applied sensitivity label can itself be a condition in a policy, which is the join between the two mechanisms and the reason the taxonomy decision has to be made before the policy decision rather than alongside it. A policy that keys on a label the organisation has not yet agreed on is a policy that will be rewritten.
Microsoft's recommended sequence is worth following rather than compressing. Policies should be deployed in simulation mode, where the configured actions are not applied, and evaluated before moving to more restrictive modes, so that the effect on legitimate work is understood before anything is blocked. Microsoft is candid that adoption may require changes to business processes and that user training matters as much as the policy configuration.
One documented limitation deserves to be stated plainly, because it defeats a common assumption. Microsoft notes that in SharePoint and OneDrive a policy scans existing items as well as new ones, but that for Exchange, new messages are scanned and previously existing email items stored in a mailbox or archive are not. An organisation planning a retrospective sweep of historic mail through this mechanism is planning something the documentation does not support.
Protection policies extend label enforcement, within documented limits
Microsoft Purview protection policies are worth understanding accurately rather than assuming. Microsoft documents them as policies associated with a sensitivity label that control access to labelled items, allowing the users and groups named in the policy to retain the permissions they already hold while blocking everyone else. The documented application is to items in Microsoft Fabric rather than to Microsoft 365 content generally; the associated label has to have been scoped to files and other data assets with access control configured; and the limits are specific, including a capped number of policies, a capped number of users and groups per policy, no support for guest or external users, and no support for administrative units.
The honest conclusion is that this is a targeted extension of label-driven access control to one data estate, not a general control across an organisation's Microsoft 365 content, and a design that assumes otherwise will not deliver what was planned. Confirm the current scope against Microsoft's documentation before relying on it.
Licensing is a design constraint, not an afterthought
Capability entitlement decides which parts of a design can actually run. Microsoft documents feature-level availability in the Microsoft Purview service description, and states that the requirements depend on the features used and that administrators also need a licence to manage sensitivity labels. Microsoft further documents that a Microsoft 365 E3 or E5 licence is required for sensitivity labels from Microsoft Purview Information Protection, and that applying labels to non-Microsoft 365 data sources and using protection policies requires pay-as-you-go billing to be set up in the organisation.
Pricing is a matter for Microsoft, and no figures appear here. The design consequence is what matters: a taxonomy whose enforcement depends on a capability the tenant is not entitled to is a plan that cannot execute, and the entitlement check belongs at the start of the design rather than at deployment. Where label and policy scoping is expected to follow organisational boundaries, note also that scoping to administrative units depends on Microsoft Entra ID configuration and on the accuracy of that membership.
Decisions to settle before configuring anything
- Which of the seven principles the organisation is actually trying to support through configuration, and which remain governance, notice and process obligations that no setting addresses.
- How few sensitivity labels can carry the distinction the Security Principle requires, and whether personal data is expressed as a level in the taxonomy or detected by policy conditions.
- Which locations are in scope for policy enforcement, and which of those carry prerequisites such as scanner deployment that add work before any policy applies.
- What the retention position for personal data is, expressed as a period and a starting point, so the Retention Principle has a concrete configuration rather than an intention.
- Which capabilities the tenant is entitled to under its current licensing, confirmed against Microsoft's documentation before the design depends on them.
- Who inside the organisation owns the taxonomy afterwards, since labels that are never revised drift away from how the business actually classifies its information.
When outside help may not be needed
An organisation with a small number of information types, no on-premises repositories, no requirement to enforce beyond Microsoft 365, and internal staff comfortable with administrative configuration can reasonably build a first taxonomy and a small set of policies directly from Microsoft's documentation. Starting narrow, running policies in simulation mode and expanding deliberately is a sound approach whether or not anyone is engaged to assist, and an organisation that follows it will learn more about its own data than any external assessment would tell it.
The work becomes worth scoping when several of the harder conditions coincide: encryption that must not break external collaboration, enforcement across repositories outside Microsoft 365, a taxonomy that has to survive contact with thousands of users, existing overlapping policies whose combined effect is not understood, or a licensing position that constrains the intended design. The trigger is the interaction between those factors rather than headcount.
What to do next
Confirm the current statutory position and any applicable guidance directly against the Department of Personal Data Protection's published material, and obtain legal advice on how the Act applies to the organisation's own processing. Where the requirement is to design and configure information protection within Microsoft 365, the Microsoft 365 implementation service can be discussed within an agreed scope.
General-information limitation
This article is general technical information about information protection configuration concepts in Microsoft 365. It is not legal advice, does not determine how the Personal Data Protection Act 2010 applies to any organisation, and does not confirm that any configuration makes an organisation compliant with the Act or any other requirement. Statutory requirements and Microsoft product capabilities are set by their respective publishers and change over time, and product feature names in this area are revised regularly, so treat the names above as a description of the mechanism and confirm the current position against the Act, the Department of Personal Data Protection, and Microsoft's documentation before implementation.
Microsoft, Microsoft 365, Microsoft Entra ID, Microsoft Purview, Microsoft Teams and SharePoint are trademarks of the Microsoft group of companies.