Docs / Obsidian Mail Server / Compliance
Data loss prevention
Data loss prevention (DLP) keeps sensitive information such as card numbers, bank details, ID numbers and passwords from leaving the organization by email. A policy looks for that information in every message and its attachments, then reports, warns the sender, or stops the message. Policies are mail flow rules with a The message contains sensitive information condition; Data loss prevention is the quick way to create them.
Create a policy
- Open Data loss prevention and pick what to protect, for example Payment cards (PCI DSS).
- Check the kinds of information to look for. Hover over a kind to see what it matches.
- Leave Only in mail sent outside the organization on, unless colleagues may not send it to each other either.
- Choose How many before it counts:
1means a single card or ID number is enough. Raise it to catch only bulk data such as a spreadsheet of customers. - Choose What happens:
- Let it through, send an incident report: nothing changes for the sender; the people listed get a report.
- Let it through, tell the sender and send an incident report: the sender also gets a notice.
- Stop it, tell the sender why and send an incident report: the message is returned to the sender with the reason.
- Choose who gets incident reports. You are filled in; add a compliance mailbox or a group.
- To try it out first, check Test first: matches are only recorded in Track a message.
- Choose Create policy. New policies go to the top of the rule order, so they run before other rules.
To change a policy later (other kinds of information, other people, a different outcome), choose Edit; it opens in Mail flow rules.
What is detected
Every kind of information is validated, not just matched by its shape, so random numbers rarely count:
| Kind | Found when |
|---|---|
| Credit card number | 13-19 digits (spaces or dashes allowed) that pass the Luhn check and start like a known card brand |
| International bank account number (IBAN) | A country code, check digits and account number with a valid check |
| Passwords and secret keys | Private key blocks, cloud access keys and tokens, and password: ... written out |
| U.S. social security number | Written as 123-45-6789 in valid number ranges, or nine digits next to SSN |
| U.S. bank routing number (ABA) | Nine digits with a valid check digit next to routing or ABA |
| U.S. DEA registration number | Two letters and seven digits with a valid DEA check digit |
| U.S. national provider identifier (NPI) | Ten digits with a valid check digit next to NPI, provider or physician |
| U.S. Medicare beneficiary identifier (MBI) | Eleven characters in the official Medicare pattern, like 1EG4-TE5-MK73 |
| ICD-10 diagnosis code | Codes like E11.9 or J45.909 next to diagnosis, patient, ICD or other medical words |
| U.K. national insurance number | Like AB 12 34 56 C, with valid letters |
| U.K. NHS number | Ten digits with a valid check digit next to NHS or patient |
| Swedish personal identity number | YYMMDD-NNNN with a valid date and check digit (ten bare digits only next to personnummer) |
Confidence. A number that passes its check has medium confidence; with a supporting word nearby (card, Visa, IBAN, SSN, personnummer ...) it has high confidence. Policies created here count medium and high. In a rule you can require high confidence to be stricter, or accept low (card-like numbers of an unknown brand).
Where it looks. The subject, the message text, and attachments that contain text: plain text, CSV, HTML, Word, Excel and PowerPoint files, and attached emails. PDFs, pictures and encrypted files are not read.
HIPAA
The U.S. health information (HIPAA) template looks for the identifiers and codes that make email protected health information under the U.S. Health Insurance Portability and Accountability Act: social security numbers, Medicare beneficiary identifiers, provider (NPI) and DEA numbers, and ICD-10 diagnosis codes. Any one of them is enough; raise How many before it counts to catch only bulk data. A typical setup for a practice or clinic:
- Create the policy with Only in mail sent outside the organization and Stop it, tell the sender why and send an incident report, with reports going to your privacy officer.
- Start in test mode for a week and review what it finds in Track a message.
A DLP policy is one safeguard, not HIPAA compliance by itself. HIPAA also expects encrypted connections (see Certificates), access control and change records (see Administrators), keeping records (Journaling), and a business associate agreement with anyone who hosts the server for you.
Incident reports
An incident report is an email to the people you chose. It says which policy matched, who sent the message to whom, what the server did, and what was found. Found values are masked (********1111); the original message is attached, so treat incident reports as sensitive too.
Tips
- Start in test mode or with Let it through, send an incident report, look at what it finds for a week, then tighten it.
- Senders outside the organization are never sent notices; when a policy stops their message they get a non-delivery report with your reason.
- DLP does not replace encryption. It catches mistakes, like a card number pasted into a reply to a supplier.