Data masking

Plain-language summary

New in 2022: hiding, substituting or pseudonymising sensitive data, especially personal information, so that people and systems that do not need the real values — testers, analysts, support staff, reporting tools — work with masked versions instead.

What the clause is really asking

Organisations copy production data into test environments, analytics tools, spreadsheets and supplier systems all the time, and each copy multiplies the exposure. The control asks you to use data masking where your access control policy, other policies, business needs and legal obligations call for it. Masking covers a family of techniques: hiding part of a value (showing only the last four digits of an account number), substitution with realistic fake values, pseudonymisation (replacing identifiers with tokens that can be reversed only with a separately held key), anonymisation (irreversible), encryption and aggregation. The guidance asks you to weigh how strong the technique must be, whether masked data could be re-identified by combining it with other sources, and who may see unmasked values. Under POPIA, information de-identified so that it cannot be re-identified falls outside the Act, but data that can be linked back to a person remains personal information. The common misunderstanding is that masking is only for developers; in many organisations the larger exposure is report extracts sent to analysts, consultants and BI tools.

What auditors look for

Auditors ask where production data, especially personal information, is copied for testing, development, training, analytics or reporting, and then check what form it takes there. They open a test environment or a BI dataset and ask whether it contains real names, ID numbers, contact or bank details. They ask for the masking rules — which fields, which technique — and who approved them. They check what support and call-centre staff see on screen. Where pseudonymisation is used, they ask where the re-identification key is held and who can use it. The hard question: if your test system were breached tomorrow, would you have to notify the Information Regulator?

Typical evidence

Data masking standard or section of the access control policy; inventory of sensitive data fields and where they are copied; masking rules per environment or dataset; masking configuration in applications, databases or BI tools; approvals for any use of unmasked production data; key management records for pseudonymisation; re-identification risk assessments; test data management procedure.

How to comply — recommendations

List the places where copies of production personal information end up: test and training systems, report extracts, BI datasets, supplier uploads, spreadsheets emailed to consultants. For each, decide whether real values are needed. Where they are not, write masking rules in a one-page standard: which fields (ID numbers, bank details, contact details, salary or health data), which technique, and who may approve an exception. Use built-in features where they exist, such as dynamic data masking in databases, field-level security in the CRM and restricted columns in BI tools, and generate synthetic data for testing. Keep pseudonymisation keys separate from the data. Record any approved use of live data in testing, with an end date.

Common nonconformities

Unmasked production personal information in test or development environments; analytics datasets containing identifiers the analysis does not need; no rules defining which fields are masked or how; pseudonymisation keys stored with the data; support staff seeing full ID or account numbers without need; re-identification risk never considered; live data used in testing without approval.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.