Data loss prevention (DLP) is the Microsoft 365 feature most often paid for and least often used. The licence is there, Exchange and SharePoint are full of personal information, and nobody has written a policy because the first attempt is expected to block something important and flood the helpdesk.
It does not have to. Microsoft Purview DLP has a deployment model built for caution, and POPIA gives you a clear first target. This guide walks through one policy, for South African identity numbers, from design to enforcement, for an IT lead who holds the licence and has not yet used it. Our Microsoft 365 security page sets out how OAS runs this as part of a wider configuration review.
Why POPIA makes DLP a priority
Section 19 of POPIA requires a responsible party to secure the integrity and confidentiality of personal information under its control. It must take reasonable measures to identify all reasonably foreseeable internal and external risks, establish and maintain safeguards against them, regularly verify that the safeguards work, and update them as risks change, with due regard to generally accepted information security practices.
The Information Regulator has shown what that means in practice. Its enforcement notice to Dis-Chem, dated 31 August 2023, found contraventions of section 19 for failing to adequately monitor and detect unlawful access, of section 21 for having no written contract with the operator that held the data, and of section 22 for not notifying data subjects as soon as reasonably possible. Since 1 April 2025 those section 22 notifications go through the Regulator's online eServices portal; ITWeb reported at the launch that the Regulator had received more than 1,700 security compromise reports in its 2023 financial year.
DLP speaks directly to the "monitor and detect" part of section 19. An ID number sent to a personal email address, copied to a USB drive or pasted into a public AI site is a foreseeable internal risk, and a DLP policy is a documented, verifiable safeguard against it. Our guide to POPIA compliance in 2026 covers the rest of the Act.
Start with the South African ID number
Purview ships with a built-in sensitive information type for the South African identification number, so there is nothing to write. Microsoft's definition looks for 13 digits, with or without spaces: six digits in YYMMDD form, four digits, a single citizenship digit, an 8 or a 9, and a checksum digit. A high-confidence match requires three things within 300 characters of each other: the pattern, a passing checksum, and one of the keywords "Identity card", "ID" or "Identification". That combination keeps false positives low on documents full of other thirteen-digit numbers.
The ID number is the right first target for three reasons. Almost every South African organisation holds it, for staff at the least. A data subject cannot change it after a compromise. And the detection is precise, which matters more than coverage for a first policy. Account numbers, medical information and payroll data come later, once the team trusts the tool.
Choose the locations
A single Purview policy can cover Exchange, SharePoint, OneDrive, Teams, the Office applications, Windows and macOS endpoints, on-premises file shares and third-party cloud applications. Do not tick everything. For a first policy:
- Exchange Online: outbound mail to recipients outside the organisation containing an ID number.
- SharePoint and OneDrive: files containing ID numbers shared with people outside the organisation.
- Teams: chat and channel messages, if your firm shares client documents over Teams.
Endpoint DLP, which watches copying to removable media and network shares, printing, and the use of unapproved applications and browsers, including pasting into public generative AI sites, is a strong second phase. It needs device onboarding and its own tuning, so keep it out of the first policy.
Choose the actions
Each DLP rule carries an action. Microsoft documents four: allow (devices only, with audit data), audit only, block with override, and block. For external email and sharing of an ID number, block with override is the right end state: the user is stopped, sees why, and can proceed with a business justification that is written to the audit log. That log is the evidence that the safeguard is being verified, which is what section 19(2) asks for. Reserve outright block for cases with no legitimate business reason, such as sending a bulk file of ID numbers to a personal webmail address.
Roll it out without blocking anyone
Microsoft's deployment guidance gives a policy four states, and the discipline is to move through them in order.
- Keep it off. Build the policy, scope it, and have the information officer and the business owners review it before it does anything.
- Simulation mode. The policy records what it would have done without acting. Keep the scope broad: you want to see where ID numbers actually move. Review the simulation overview and Activity explorer, and tune the rule. A department that legitimately sends ID numbers to SARS or a medical scheme is a scope exclusion, not a reason to abandon the policy.
- Simulation with policy tips. Narrow the scope to a pilot group. Users see the tip and the notification email, but nothing is blocked. Collect their feedback and find the people who can explain the control to colleagues.
- Turn it on. Enforce, then watch the DLP alerts and Activity explorer for the first weeks. Microsoft sets no fixed duration for the simulation phases; the test is whether the control objectives are met and the false positives are understood.
Creating the policy needs membership of the Compliance administrator, Compliance data administrator, Information Protection, Information Protection Admin or Security administrator role group, or an equivalent granular role. Assign it deliberately and record who holds it.
Keep the evidence
A DLP policy earns its place under POPIA when it can be shown to work. Export the policy settings and simulation results at each stage, keep the alert history, and review the matches quarterly with the information officer. Pair the policy with Conditional Access and the detection and response in the Microsoft 365 E5 security stack, and one licence covers a good part of section 19. OAS configures Purview DLP as part of its Microsoft 365 reviews and runs the tuning and reporting afterwards.
Sources
- Information Regulator (South Africa): Enforcement notice, Dis-Chem Pharmacies Limited, SC 30/2022, dated 31 August 2023 and accessed 3 November 2026.
- Information Regulator (South Africa): POPIA section 22, Notification of security compromises, accessed 3 November 2026.
- ITWeb: InfoReg takes data breach reporting online, dated 8 April 2025 and accessed 3 November 2026.
- Microsoft Learn: Design and deploy a data loss prevention policy, accessed 3 November 2026.
- Microsoft Learn: South Africa identification number sensitive information type, accessed 3 November 2026.
- Microsoft Learn: Describe data loss prevention, accessed 3 November 2026.
Switch on the protection you already licence with Microsoft 365 security configured by OAS.