Ghani Governance · Microsoft Purview DLP
Microsoft Purview DLP policy examples for UK data
Published
Microsoft Purview includes ready-made DLP policy templates for UK data, including U.K. Personally Identifiable Information (PII) Data, U.K. Financial Data and U.K. Access to Medical Reports Act. They detect National Insurance numbers, NHS numbers, U.S./U.K. passport numbers, card numbers and SWIFT codes. Each template pairs a low-count rule that notifies with a high-count rule that blocks, with override and business justification. UK bank sort codes need a custom sensitive information type.
Which UK DLP policy templates does Microsoft Purview include?
Purview has six templates named for UK law or UK data. Each one has two rules: a low-count rule for 1 to 9 matches in content shared with people outside your organisation, and a high-count rule for 10 to 500 matches. According to Microsoft’s list of what the DLP policy templates include, the templates detect the following:
| Template | Sensitive information types it looks for |
|---|---|
| U.K. Personally Identifiable Information (PII) Data | U.K. National Insurance Number (NINO); U.S. / U.K. Passport Number |
| U.K. Data Protection Act | NINO; U.S. / U.K. Passport Number; SWIFT Code |
| U.K. Access to Medical Reports Act | U.K. National Health Service Number; NINO |
| U.K. Personal Information Online Code of Practice (PIOCP) | NINO; NHS number; SWIFT Code |
| U.K. Financial Data | Credit Card Number; EU Debit Card Number; SWIFT Code |
| U.K. Privacy and Electronic Communications Regulations | SWIFT Code |
The default actions are the same for all six. The low-count rule sends a notification. The high-count rule blocks access to the content, sends a notification, allows an override with a business justification and sends an incident report. The templates cover Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, devices, instances and on-premises repositories. Microsoft states that the templates are starting points you can customise.
A template name is not legal advice. The “U.K. Data Protection Act” template does not make an organisation compliant with UK GDPR or the Data Protection Act 2018. It is a detection rule set. We cover the legal side on UK GDPR and data privacy.
What do the UK sensitive information types actually match?
DLP policies are only as good as the sensitive information types (SITs) inside them. Knowing how each UK type is detected explains most false positives.
National Insurance number (NINO)
Two letters, six digits and a final letter A, B, C or D, written with or without spaces or dashes. There is no checksum. A match is high confidence only when a keyword such as “national insurance number” or “NI number” appears within 300 characters; the pattern alone is medium confidence. Microsoft Learn: NINO definition.
NHS number
Ten digits in a 3-3-4 pattern, with optional spaces. It has a checksum, and a match needs the checksum plus a keyword within 300 characters, such as “NHS”, “patient number” or “date of birth”. Microsoft Learn: NHS number definition.
Payment card numbers
The Credit Card Number type uses the Luhn checksum and checks the number formats of the major card brands. It does not flag the reserved numbers banks use for testing. Microsoft Learn: credit card number definition.
Other UK types
Purview also ships U.K. Unique Taxpayer Reference Number (10 digits, no checksum), U.K. driver’s licence number, U.K. electoral roll number and U.K. physical addresses. None of them is in the UK templates by default, so add them yourself where they matter. Microsoft Learn: SIT entity definitions.
What this means in practice: NINO and UTR patterns have no checksum. Product codes, reference numbers and other strings that look similar can therefore trigger them. Base any rule that blocks on high-confidence matches, which need a keyword nearby. Keep medium-confidence matches for audit or a policy tip.
How do you protect UK bank details in Purview DLP?
You use a custom sensitive information type. Purview’s built-in list includes International Banking Account Number (IBAN), SWIFT Code and a U.S. bank account number type. When we checked the list on 19 October 2026, it had no U.K. sort code or U.K. bank account number type. Payroll files and supplier forms often hold sort codes and account numbers without an IBAN, so a policy built only on templates will miss them.
A custom type combines a regular expression with a keyword list and a confidence level. Purview uses the Boost.RegEx 5.1.3 engine. Microsoft support can’t write the patterns for you (Microsoft Learn: create a custom sensitive information type). For UK bank details, a sensible design is:
- a primary pattern for a sort code next to an account number. GOV.UK’s bank details pattern treats a sort code as 6 digits and an account number as 6 to 8 digits. Banks usually print the sort code as three pairs of digits (HSBC UK), so allow spaces and hyphens;
- a keyword list such as “sort code”, “account number”, “acc no” and “BACS”, required for high confidence;
- testing against real, approved sample files before the type is used in a blocking rule.
Five example DLP policies for UK organisations
These are example starting designs, not settings from a client engagement. Each one uses conditions and actions documented in Microsoft’s DLP policy reference. Adjust the scope, thresholds and exceptions to your own processes before you enforce anything.
1. HR records shared outside the organisation
Starts from: U.K. PII Data. Locations: Exchange, SharePoint, OneDrive. Rule: high-confidence NINO shared with people outside the organisation. A policy tip for 1 to 9 matches; block with override and business justification for 10 or more. Exception: your payroll bureau’s domain, using the Exchange condition “Recipient domain is”.
2. Occupational health and medical reports
Starts from: U.K. Access to Medical Reports Act. Rule: NHS number or NINO shared externally. Block external sharing for any count unless the recipient is an approved provider domain. Medical reports are special category data, so a single record matters.
3. Card data in email and chat
Starts from: U.K. Financial Data. Locations: Exchange and Teams. Rule: credit card numbers in messages to external recipients. Block with no override at low counts, because card numbers should not travel in email or chat at all.
4. Payroll and supplier bank details
Starts from: a custom UK bank details type (above) plus IBAN. Rule: audit only for the first run, then a policy tip, then block with override. Bank-detail fraud usually starts with a changed account number, so pair this with your payment-change process.
5. Copying personal data off managed devices
Starts from: U.K. PII Data, extended to devices. Rule: NINO files copied to USB, printed or copied to the clipboard on onboarded Windows devices. For these activities DLP supports Allow, Audit only, Block with override and Block. Start with Audit only.
When one item matches more than one policy, Purview applies the most restrictive actions. Where the override options differ, “no override” wins over “allow override”. Plan your policies as a set, not one at a time.
Should a UK DLP policy show a policy tip or block?
Start with a policy tip, and move to block once the matches are clean. A policy tip tells the user, as they work, that the item conflicts with a policy. You can let them override with a business justification, which is logged in the DLP reports. You can also let them report a false positive (Microsoft Learn: notifications and policy tips). Those justifications and false-positive reports are the best tuning data you will get.
Test before you enforce. In simulation mode, a policy runs as if it were enforced, but nothing is actually enforced. Matches appear on a separate dashboard. A simulation can run for up to 15 days. In SharePoint and OneDrive it evaluates existing items as well as new and changed ones. In Exchange, Teams and devices it evaluates only items that are new during the simulation. Results are kept for 30 days (Microsoft Learn: DLP simulation mode).
| Situation | Suggested action |
|---|---|
| New policy, unknown match volume | Simulation mode, then audit only |
| Legitimate business use exists (for example payroll) | Policy tip, or block with override and business justification |
| Data should never leave by this route (for example card numbers in email) | Block, no override |
| Detection has no checksum and no keyword nearby | Audit or policy tip only |
How these examples fit a Purview DLP implementation
Templates and examples are where design starts, not where it ends. A full Microsoft Purview DLP implementation begins with the information that matters to you, the routes that are actually risky and what a legitimate process looks like. Then it tests the policies before they block anyone. Labels make DLP rules more precise; see sensitivity labels and information protection. If your written data-handling or acceptable use policy needs to drive the rules, start with Policy to Purview design.
Related pages
- Microsoft Purview DLP implementation: our DLP service and indicative ranges
- Sensitivity labels and information protection: classification that DLP rules can use
- UK GDPR and data privacy: the legal obligations behind the templates
- Insider Risk Management: when DLP alerts point to a person, not a process
- Microsoft 365 Copilot data security: DLP for AI prompts and responses
Sources: Microsoft Learn, GOV.UK Design System and HSBC UK pages linked above, checked on 19 October 2026. Product behaviour changes, so check Microsoft’s current documentation before you configure anything.
Book a discovery workshop
A scoping conversation about what you need to protect, what is already configured, and what must not break.