# 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.

<!--
Guidance: How to use this template
- Use it when the Statement of Applicability marks A.8.11 or A.8.12 as
  applicable, or when customers ask how you stop their data leaking into
  test systems, personal mailboxes or AI tools.
- Fill first: section 3 (which classification levels and data types
  trigger masking and DLP), then the technique table in section 4 and
  the channel table in section 7. Classification comes from
  `data/data-classification-policy`; without it, DLP rules have nothing
  to match.
- Main pitfall: buying a DLP product and switching on blocking on day
  one. Rules that block normal work get disabled within a week. Run in
  monitor mode, measure false positives, then enforce (section 9).
- Second pitfall: calling pseudonymised data "anonymous". Pseudonymised
  personal data is still personal data under laws such as the GDPR.
- Related templates: `data/data-classification-policy`,
  `isms/information-labelling-handling-procedure`,
  `isms/information-transfer-policy`, `isms/secure-development-policy`,
  `isms/security-monitoring-procedure`, `isms/endpoint-device-byod-policy`,
  `isms/saas-productivity-security-baseline`, `ai-data/ai-usage-policy`,
  `compliance/dpia`, `compliance/personal-data-breach-assessment`,
  `security/cryptography-standard`, `isms/cryptographic-key-register`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: DLP rule sets change often. Keep the rule catalogue (section 8) as a controlled annex with its own version so that rule tuning does not force re-approval of the whole standard. -->

| Field | Value |
|---|---|
| Document ID | [DOC-ISMS-062] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-engineering-lead] |
| Approvers/reviewers | [@isms-manager], [@ciso], [@dpo], [@hr-lead], [@head-of-engineering] |
| Last updated | YYYY-MM-DD |
| Effective from | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.11, A.8.12); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD |
| Inputs | [Data classification policy], [Asset inventory DOC-ISMS-012], [Risk register DOC-ISMS-016], [DPIA reference] |
| Rule catalogue version | [DLP-RULESET v1.0, YYYY-MM-DD] |
| Related documents | [Information transfer policy DOC-ISMS-043], [Security monitoring procedure DOC-ISMS-064], [Secure development policy DOC-ISMS-065] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Standard owner | [@security-engineering-lead] | [Prepared] | YYYY-MM-DD |
| Data protection officer | [@dpo] | [Privacy review completed] | YYYY-MM-DD |
| HR or employee representative consultation | [@hr-lead] | [Consulted, where required] | YYYY-MM-DD |
| Top management sponsor | [@ciso] | [Approved / Approved with changes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@owner] | First draft |
| 1.0 | YYYY-MM-DD | [@owner] | Approved for issue; DLP in monitor mode |
| 1.1 *(Example)* | YYYY-MM-DD | [@owner] | Rules DLP-RUL-001 and 004 moved to block after tuning period |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose, scope and authority](#1-purpose-scope-and-authority)
- [2. Roles and responsibilities](#2-roles-and-responsibilities)
- [3. Data in scope and triggers](#3-data-in-scope-and-triggers)
- [4. Masking, pseudonymisation and anonymisation techniques](#4-masking-pseudonymisation-and-anonymisation-techniques)
- [5. Test and non-production data](#5-test-and-non-production-data)
- [6. Pseudonymisation secrets and re-identification risk](#6-pseudonymisation-secrets-and-re-identification-risk)
- [7. DLP channels and coverage](#7-dlp-channels-and-coverage)
- [8. DLP rule catalogue](#8-dlp-rule-catalogue)
- [9. Deployment and tuning](#9-deployment-and-tuning)
- [10. DLP alert and incident handling](#10-dlp-alert-and-incident-handling)
- [11. Privacy and staff monitoring](#11-privacy-and-staff-monitoring)
- [12. Exceptions](#12-exceptions)
- [13. Size tiers](#13-size-tiers)
- [14. Records and evidence](#14-records-and-evidence)
- [15. Control mapping](#15-control-mapping)
- [16. References](#16-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and authority

<!-- Guidance: State the outcomes: sensitive data is shown only to those who need it, copies outside production are de-identified, and unauthorised outbound movement is detected or stopped. Questions: Which environments, channels and staff groups are covered? Pitfall: scoping DLP to e-mail only while staff move files through sync clients, chat and AI assistants. -->

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

<!-- Guidance: DLP touches security, privacy, HR and the business. Name who may see alert content, because DLP alerts contain the very data you are protecting. Auditors check that alert reviewers are authorised and trained. -->

| Role | Responsibilities |
|---|---|
| Standard owner [@security-engineering-lead] | Maintains this standard and the rule catalogue; runs tuning reviews; reports metrics |
| Information owners | Define which data types need masking or DLP protection; approve unmasked access and rule exceptions for their data as risk owners, within the approval limits in section 12 |
| Engineering leads | Implement masking in applications, pipelines and test data provisioning per section 5 |
| DLP analysts (security team or managed service) | Triage alerts within the service levels in section 10; only named, trained analysts may view alert content |
| Data protection officer [@dpo] | Reviews techniques against privacy law, reviews the monitoring impact (section 11), advises on breach assessment |
| HR lead [@hr-lead] | Handles cases where an alert indicates possible misconduct, under `isms/security-disciplinary-process` |
| ISMS manager [@isms-manager] | Links rules to risks and the SoA; follows audit findings; includes metrics in the measurement programme |

## 3. Data in scope and triggers

<!-- Guidance: Map each sensitive data type to the controls that apply. Questions: Which data types can be detected by pattern (card numbers), by fingerprint (contract templates) or only by label? Pitfall: DLP rules based on regular expressions alone, which miss documents without obvious patterns and flood analysts with false matches. -->

| Data type | Example identifiers | Classification | Masking required where | DLP detection method |
|---|---|---|---|---|
| Customer personal data *(Example)* | Name, e-mail, phone, address, customer ID | Confidential | Support tools, analytics, logs, non-production | Label plus pattern plus exact data match on customer table |
| Special category or health data *(Example)* | Diagnosis, appointment reason, patient identifier | Restricted | Everywhere outside authorised clinical roles | Label plus exact data match; block outbound |
| Payment card data *(Example)* | Primary account number | Restricted | Display shows last four digits at most; never in logs | Pattern with checksum validation |
| Credentials and secrets *(Example)* | API keys, private keys, tokens | Restricted | Never displayed; redacted in logs | Secret patterns in code, chat and paste sites; see `security/secrets-management-standard` |
| Source code and designs *(Example)* | Repository content, CAD files, OT programs | Confidential | Not applicable | Fingerprint and location rules; repository visibility monitoring |
| Commercial documents *(Example)* | Contracts, price lists, board papers | Confidential | Not applicable | Sensitivity label and document fingerprint |

## 4. Masking, pseudonymisation and anonymisation techniques

<!-- Guidance: Pick the weakest technique that still meets the use case: less transformation keeps utility, more transformation lowers risk. Record for each use which technique applies and whether the result is still personal data. Pitfall: hashing e-mail addresses without a secret and calling it anonymised; anyone with a list of addresses can reverse it. -->

| Technique ID | Technique | How it works | Reversible? | Still personal data? | Typical use |
|---|---|---|---|---|---|
| MSK-TEC-001 | Static redaction | Replace the value with a fixed token such as `***` | No | Usually yes if other identifiers remain | Logs, exports to third parties |
| MSK-TEC-002 | Partial masking | Show part of the value (last four digits, first letter) | No | Yes | Support screens, receipts |
| MSK-TEC-003 | Dynamic masking | Mask at query or display time based on the user's role | Yes for authorised roles | Yes | Production support and analytics tools |
| MSK-TEC-004 | Keyed pseudonymisation | Replace identifier with a keyed hash (HMAC) or token from a vault | Only with the key or vault | Yes (pseudonymised) | Analytics joins, data science, data shared between teams |
| MSK-TEC-005 | Format-preserving encryption | Encrypt so the output keeps the format | Yes with the key | Yes | Legacy systems that validate formats |
| MSK-TEC-006 | Substitution with synthetic values | Replace with realistic fake values from a generator | No | No for the substituted fields, check the rest | Test and demo data |
| MSK-TEC-007 | Generalisation and suppression | Reduce precision (age bands, postcode prefix), drop rare values | No | Depends on re-identification risk assessment | Statistics, research extracts |
| MSK-TEC-008 | Aggregation with thresholds | Publish counts only above a minimum cell size | No | Normally no, if thresholds are adequate | Dashboards, external reports |
| MSK-TEC-009 | Fully synthetic data | Generate a data set with similar statistics but no real records | No | Normally no; test for memorised records | Model training, vendor testing |

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

<!-- Guidance: This section is where A.8.11 meets A.8.33 (test information) and A.8.31 (separation of environments). Questions: Who can copy production data to staging? Is the copy masked before it leaves production? Pitfall: masking done in the test environment after the copy, so the unmasked copy already sat there. -->

- **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.

```mermaid
flowchart LR
  A["Production database"] --> C{"Every column has a masking rule?"}
  C -- No --> D["Stop pipeline and alert data owner"]
  C -- Yes --> B["Masking job inside production boundary"]
  B --> E["Masked data set"]
  E --> F["Integrity and leakage checks on sample"]
  F --> G["Staging and test environments"]
  F --> H["Analytics with keyed pseudonyms"]
```

## 6. Pseudonymisation secrets and re-identification risk

<!-- Guidance: Pseudonymisation is only as strong as the separation of the key or mapping table. Questions: Who holds the HMAC key or token vault? Could an analyst combine the data with public sources to re-identify? Pitfall: storing the token mapping table in the same database as the pseudonymised data. -->

- **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

<!-- Guidance: List every route data can leave by and state whether DLP monitors it, blocks it, or relies on another control. Gaps are acceptable when the risk is recorded. Auditors look for a coverage table that matches the real tooling. -->

| Channel ID | Channel | Control approach | Coverage *(Example)* | Residual gap and compensating control |
|---|---|---|---|---|
| DLP-CHN-001 | Corporate e-mail outbound | Gateway or suite DLP: inspect content and labels, encrypt or block | All mailboxes | Personal webmail blocked by web filtering (A.8.23) |
| DLP-CHN-002 | Cloud storage and file sharing | Suite DLP and sharing policy: block external sharing of Restricted labels | All tenants | Shadow storage services detected by cloud access broker logs |
| DLP-CHN-003 | Collaboration and chat | Suite DLP on messages and attachments to external guests | Internal and guest channels | Screenshots of chat not detectable |
| DLP-CHN-004 | Endpoint (copy to USB, print, upload in browser, clipboard) | Endpoint DLP agent on managed devices | Managed laptops | Unmanaged devices limited to browser access without download |
| DLP-CHN-005 | Web uploads and generative AI tools | Secure web gateway and browser controls; approved AI tools only per `ai-data/ai-usage-policy` | Managed devices and network | Phone cameras; awareness training |
| DLP-CHN-006 | Source code platforms | Secret scanning, push protection, repository visibility alerts | All repositories | Code pasted elsewhere; covered by DLP-CHN-005 |
| DLP-CHN-007 | Databases and APIs | Query volume anomalies, export limits, database activity monitoring | Production databases | Insider with legitimate bulk access; access reviews |
| DLP-CHN-008 | Removable media and printing | Blocked by default; allowed for named roles with encryption | Managed devices | Paper: clear desk policy (`isms/clear-desk-clear-screen-policy`) |

## 8. DLP rule catalogue

<!-- Guidance: Keep each rule specific: data type, channel, condition, action, owner. Start in Monitor, then move to Warn (user notified, may override with justification), then Block. Pitfall: one broad rule with many conditions that nobody can tune. -->

| Rule ID | Data type | Channel | Condition | Mode | Action on match | Owner |
|---|---|---|---|---|---|---|
| DLP-RUL-001 *(Example)* | Payment card data | E-mail, file sharing | 5 or more valid card numbers to an external recipient | Block | Block, notify sender, alert analyst | [@security-engineering-lead] |
| DLP-RUL-002 *(Example)* | Customer personal data | File sharing | Restricted or Confidential label shared to personal domains | Warn | User justification required, logged | [@privacy-lead] |
| DLP-RUL-003 *(Example)* | Health data | All | Exact data match on patient identifiers, 10 or more records | Monitor (tuning) | Alert analyst | [@privacy-lead] |
| DLP-RUL-004 *(Example)* | Credentials | Code platform, chat | Secret pattern detected | Block | Block push or message, open secret rotation ticket | [@platform-lead] |
| DLP-RUL-005 *(Example)* | Any Confidential label | Generative AI tools | Upload to an unapproved AI service | Block | Block, show approved tool list | [@security-engineering-lead] |
| DLP-RUL-006 *(Example)* | Source code | Endpoint | Copy of repository folder to USB or personal cloud sync | Monitor | Alert analyst | [@eng-lead] |

## 9. Deployment and tuning

<!-- Guidance: Measure precision before enforcing. Questions: What share of alerts are true positives? How many alerts can the team triage per week? Pitfall: enforcing rules with high false positive rates, which teaches staff to override warnings without reading them. -->

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.

| Rule | Tuning period *(Example)* | Alerts | True positives | False positives | Benign true positives | Precision | Decision |
|---|---|---|---|---|---|---|---|
| DLP-RUL-001 | Weeks 1 to 4 | 40 | 37 | 3 | 0 | 92.5% | Move to Block |
| DLP-RUL-003 | Weeks 1 to 4 | 120 | 30 | 60 | 30 | 33.3% | Stay in Monitor; add exact data match and exclude the approved hospital transfer channel |

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

<!-- Guidance: A DLP alert is a security event. Decide when it becomes an incident and when it is a possible personal data breach. Pitfall: alerts reviewed weekly in bulk, so a real exfiltration is seen days late. Auditors sample alerts and check triage times and outcomes. -->

| Severity *(Example)* | Examples | Triage time | Escalation |
|---|---|---|---|
| High | Block of Restricted data to external party, bulk export of health data | Within 1 hour in business hours, next morning otherwise | Incident lead per `compliance/incident-response-plan` |
| Medium | Warn override with weak justification, repeated attempts | 1 business day | Information owner |
| Low | Single monitor-mode match | 5 business days | Batch review |

```mermaid
flowchart TD
  A["DLP alert raised"] --> B["Analyst triage within severity time"]
  B --> C{"True positive?"}
  C -- No --> D["Label false positive and feed tuning"]
  C -- Yes --> E{"Data actually left the organization's control?"}
  E -- No --> F["Close as blocked event, coach user if needed"]
  E -- Yes --> G["Open incident in register DOC-ISMS-021"]
  G --> H{"Personal data involved?"}
  H -- Yes --> I["Personal data breach assessment with DPO"]
  H -- No --> J["Contain and recover per incident response plan"]
  I --> J
  G --> K{"Possible misconduct?"}
  K -- Yes --> L["Refer to HR under disciplinary process"]
```

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

<!-- Guidance: DLP inspects staff communications. Questions: Is the monitoring necessary and proportionate? Were staff told? Is a DPIA needed? Does local law require consulting employee representatives? Pitfall: analysts browsing alert content out of curiosity. Auditors and regulators check transparency notices, DPIA and access logs. -->

- **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

<!-- Guidance: Common exceptions are approved bulk transfers to customers or regulators and real data in test for a defect. Each one needs an owner, a reason and an expiry date. -->

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).

| Exception ID | Statement or rule | Reason | Compensating control | Residual score | Expiry |
|---|---|---|---|---|---|
| DLP-EXC-001 *(Example)* | DLP-RUL-003 | Nightly schedule export to a hospital customer over the managed transfer service | Transfer by managed file transfer with encryption and recipient allow list | 4 Low | YYYY-MM-DD |
| DLP-EXC-002 *(Example)* | MSK-STD-005 | Reproduce defect affecting one customer tenant | Minimised data set, 2 named engineers, deletion after 14 days | 6 Medium | YYYY-MM-DD |

## 13. Size tiers

<!-- Guidance: Show what is proportionate. Most small companies get enough DLP from their productivity suite plus endpoint management; dedicated platforms belong to larger or regulated organizations. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Main risk | Customer analytics data (as processor) copied to test or personal tools | Patient-related scheduling data leaving to unapproved channels; health data in test | Designs, OT programs and commercial data across 6 sites in 4 countries |
| Masking | Masking pipeline for staging built into the data platform; dynamic masking in the support console | Keyed pseudonymisation for analytics; synthetic data for demos to hospitals | Central data platform policies; pseudonymised HR data for group reporting |
| DLP | Suite DLP on mail and file sharing, secret scanning, endpoint controls via device management; alerts reviewed by the 0.5 FTE ISMS manager and one engineer | Suite DLP plus endpoint DLP; 3-person security team triages; DPIA completed | Dedicated DLP platform, cloud access broker, regional analysts, works council consultation where required |
| Tuning cadence | Quarterly | Monthly | Monthly per region, central rule board |

## 14. Records and evidence

<!-- Guidance: List the records that prove masking and DLP operate, and register them in `isms/control-evidence-matrix` against A.8.11 and A.8.12. -->

| Record | Proves | Owner | Location *(Example)* | Retention *(Example)* |
|---|---|---|---|---|
| Masking rule inventory per data set | MSK-STD-005, 007 | Engineering leads | Masking pipeline repository | Life of the system |
| Masking pipeline test results | Fail-closed behaviour works | Engineering leads | CI pipeline records | 1 year |
| Unmasking access logs | MSK-STD-002 | Standard owner | Central logging | 1 year |
| Re-identification risk assessments | MSK-STD-010 | DPO | DPIA register | Life of the processing plus 3 years |
| DLP rule catalogue with versions | Rules defined and approved | Standard owner | ISMS document store | 3 years |
| Tuning reviews and precision figures | Section 9 | Standard owner | Tuning review notes | 3 years |
| Alert triage records | Section 10 | DLP analysts | DLP console export, ticketing system | 1 year, longer if linked to an incident |
| Alert content access reviews | DLP-STD-004 | DPO | Quarterly review records | 3 years |
| Exception records | Section 12 | ISMS manager | Exception register | 3 years after expiry |

## 15. Control mapping

<!-- Guidance: Use short labels you wrote, consistent with the SoA, not official control text. -->

| Control (ISO/IEC 27001:2022 Annex A) | Sections |
|---|---|
| A.8.11 data masking (new in 2022) | 3 to 6 |
| A.8.12 data leakage prevention (new in 2022) | 7 to 11 |
| A.5.12 information classification | 3 |
| A.5.14 information transfer | 7, 12 |
| A.5.34 privacy and PII protection | 6, 11 |
| A.8.33 test information | 5 |
| A.8.31 separation of environments | 5 |
| A.8.16 monitoring activities | 10 |
| A.8.23 web filtering | 7 (DLP-CHN-001, 005) |

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

<!-- Guidance: Recheck editions at each review. -->

| Reference | Edition and status (checked 2026-11-01) | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current; https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Controls A.8.11, A.8.12 and related |
| ISO/IEC 27002:2022 | Current; https://www.iso.org/standard/75652.html | Control guidance |
| ISO/IEC 27559:2022 | Current; https://www.iso.org/standard/71677.html | De-identification framework |
| ISO/IEC 29100:2024 | Current; https://www.iso.org/standard/85938.html | Privacy framework |
| ISO/IEC 27701:2025 | Current; https://www.iso.org/standard/85819.html | Privacy information management |
| NIST SP 800-188, De-Identifying Government Datasets: Techniques and Governance | Final, September 2023 | De-identification techniques |
| Regulation (EU) 2016/679 (GDPR) | Articles 4(5), 32, 33, 35 | International example |
| Related templates | `data/data-classification-policy`, `isms/information-transfer-policy`, `isms/secure-development-policy`, `isms/security-monitoring-procedure`, `compliance/dpia`, `compliance/personal-data-breach-assessment`, `isms/control-evidence-matrix` | |

## 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.