Data Masking and DLP Standard Template (ISO/IEC 27001 A.8.11, A.8.12)

Data Masking and Data Leakage Prevention Standard: [Organization name]

Technical standard for two controls added to Annex A in 2022: data masking (A.8.11) and data leakage prevention (A.8.12) of ISO/IEC 27001:2022 + Amd 1:2024, with guidance from ISO/IEC 27002:2022. It sets when and how to mask, pseudonymise or anonymise data, the rules for test and non-production data, which channels data leakage prevention (DLP) covers, how DLP rules are deployed, tuned and handled as security events, and the privacy limits on monitoring staff. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

• 1. Purpose, scope and authority
• 2. Roles and responsibilities
• 3. Data in scope and triggers
• 4. Masking, pseudonymisation and anonymisation techniques
• 5. Test and non-production data
• 6. Pseudonymisation secrets and re-identification risk
• 7. DLP channels and coverage
• 8. DLP rule catalogue
• 9. Deployment and tuning
• 10. DLP alert and incident handling
• 11. Privacy and staff monitoring
• 12. Exceptions
• 13. Size tiers
• 14. Records and evidence
• 15. Control mapping
• 16. References
• Standard and licence note

1. Purpose, scope and authority

This standard applies to all information classed Confidential or Restricted under data/data-classification-policy, and to all personal data, wherever it is stored or processed inside the ISMS scope ([DOC-ISMS-002]). It covers:

• Masking (A.8.11): deciding who sees full values and who sees a reduced or transformed version, so that support staff, analysts, developers, log readers and test environments get only the detail their task needs (sections 3 to 6).
• Data leakage prevention (A.8.12): knowing every route by which sensitive data can leave the organization's control (mail, sharing links, chat, browser uploads, AI assistants, USB, print, bulk database exports) and, for each route, choosing whether to watch it, warn the user, block it or rely on another control (sections 7 to 11).

It applies to employees, contractors and suppliers using organization-managed devices, accounts and services. Personal devices are covered only inside managed containers defined in isms/endpoint-device-byod-policy.

2. Roles and responsibilities

3. Data in scope and triggers

4. Masking, pseudonymisation and anonymisation techniques

Rules:

1. MSK-STD-001: Logs and error messages must not contain Restricted data or credentials in clear; apply MSK-TEC-001 at the logging library (see security/security-logging-standard).
2. MSK-STD-002: Staff who do not need full identifiers see masked values by default (MSK-TEC-002 or 003). Unmasking is a privileged action that is logged, in line with the access control policy (isms/access-control-policy).
3. MSK-STD-003: Data is described as anonymised only after a documented re-identification risk assessment (section 6). Otherwise it is treated as pseudonymised personal data.
4. MSK-STD-004: Unsalted or unkeyed hashes of low-entropy identifiers (e-mail, phone, national ID) are not an approved masking technique.

5. Test and non-production data

• MSK-STD-005: Production personal or Restricted data must not be copied to development, test, staging, demo or vendor environments unless masked or substituted (MSK-TEC-004, 006, 007 or 009) inside the production boundary before the copy.
• MSK-STD-006: Where real data is unavoidable (for example reproducing a defect that only occurs with one customer's data), the information owner approves in writing (with the department head, or higher, where the residual risk requires it under section 12), the data set is minimised, access is limited to named people, the copy is deleted within [14] days, and the approval is recorded as an exception (section 12).
• MSK-STD-007: Masking pipelines are code: they are reviewed, version-controlled and tested to fail closed (a column added to a production table without a masking rule stops the pipeline).
• MSK-STD-008: Data shared with suppliers for testing or support follows isms/information-transfer-policy and the supplier agreement.

6. Pseudonymisation secrets and re-identification risk

• MSK-STD-009: Keys for keyed hashing, tokenisation and format-preserving encryption are managed under security/cryptography-standard and recorded in the cryptographic key register ([DOC-ISMS-070]). They are stored separately from the pseudonymised data and accessible to a separate role.
• MSK-STD-010: Before data is released as anonymised, or shared outside the organization in pseudonymised form, a re-identification risk assessment considers: direct identifiers removed, indirect identifiers (dates, locations, rare attributes), linkable external data, the recipient's capability and motive, and the release model (public, controlled sharing, internal only). Record the result in the DPIA (compliance/dpia) where one is required.
• MSK-STD-011: Re-identification of pseudonymised data is permitted only for the purposes recorded in the record of processing (compliance/gdpr-ropa) and is logged.

ISO/IEC 27559:2022 gives a framework for de-identification of personal data, and NIST SP 800-188 (September 2023) describes de-identification techniques and governance; use either as a reference for the assessment method.

7. DLP channels and coverage

8. DLP rule catalogue

9. Deployment and tuning

Every new rule follows these stages:

1. Monitor for at least [4] weeks: alerts only, no user impact.
2. Review: analysts label each alert true positive, false positive or benign true positive (real data, legitimate business purpose).
3. Tune: adjust thresholds, add exact data match or exclusions for approved business flows.
4. Warn for at least [2] weeks where user justification is useful.
5. Block when precision is at or above the target and the business owner agrees.

Tuning measure: precision = true positives / (true positives + false positives). Target for blocking rules: [90%] or more.

In the example, DLP-RUL-003 precision is 30 / (30 + 60) = 33.3%; benign true positives (approved flows) are excluded from the precision formula and handled by adding the flow to the rule's allow list.

Review all active rules at least quarterly, and when a new channel, SaaS service or data type is introduced.

10. DLP alert and incident handling

Outcomes are recorded in the incident register (isms/incident-register) and, for personal data, in the breach assessment (compliance/personal-data-breach-assessment). Legal notification deadlines (for example 72 hours to the supervisory authority under GDPR Article 33 where a notifiable breach occurs) run from awareness, so High alerts cannot wait for a weekly review.

11. Privacy and staff monitoring

• DLP-STD-001: Staff are informed of DLP monitoring in the acceptable use policy (compliance/acceptable-use-policy) and the employee security handbook (isms/employee-security-handbook), including what is inspected, why, and who can see results.
• DLP-STD-002: A DPIA (compliance/dpia) is carried out before deploying content inspection of staff communications where privacy law requires one; employee representatives are consulted where local law or agreements require it.
• DLP-STD-003: DLP collects the minimum needed: rule matches and metadata by default; full content capture only for High severity rules and kept no longer than [90] days unless part of an open incident.
• DLP-STD-004: Access to alert content is limited to named DLP analysts, logged, and reviewed quarterly. Private or special category content seen incidentally is not used for any other purpose.
• DLP-STD-005: DLP is not used for productivity monitoring or performance management.

12. Exceptions

Exceptions use security/security-exception-request. Each records the rule or statement affected, the data and volume, the business reason, compensating controls, the residual risk score (1 to 25, per compliance/risk-methodology), approver and expiry date. Each exception is approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019). Critical residual risk is not approvable as an exception: treat it or stop the activity. Maximum duration is 12 months for Low or Medium and 6 months for High; at expiry the exception is reassessed, and a renewal is a new decision (DOC-ISMS-122 section 7). Real data in test is further limited to [14] days (MSK-STD-006).

13. Size tiers

14. Records and evidence

15. Control mapping

As international examples, GDPR Article 4(5) defines pseudonymisation and Article 32(1)(a) names pseudonymisation and encryption as possible security measures. Record the laws that bind you in the legal register ([DOC-ISMS-014]).

16. References

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A controls A.8.11 and A.8.12) and ISO/IEC 27002:2022, with references to ISO/IEC 27559:2022 and ISO/IEC 29100:2024. Control numbers are cited with short labels written for this template; no text, tables or definitions from ISO or IEC standards are reproduced, and you need the official standards to implement and audit the controls. NIST SP 800-188 is a US government work. EU legal texts are cited by article only. The techniques table, rules and examples are original. Check the current editions and the law that applies to you before use. This is a documentation format, not legal advice.

Template licence: MIT.