ISO 27001 Annex A 8.33: protect test data without exposing production

The security questionnaire asks the question you were hoping to skip: what data do your developers test on? The honest answer is a months-old production restore in staging, behind a login half the team shares, and the deal is waiting.

This guide covers ISO 27001 Annex A 8.33 for engineering leads, CISOs and compliance managers at UK software firms of 25 to 250 people. It covers what the control asks and how to run it with a fixture library, a masking script and a ticket type. It ends with how auditors sample test environments.

What does ISO 27001 Annex A 8.33 test information require?

Annex A 8.33 sets a default and an exception. By default, personal and sensitive data stays out of development and test, replaced by synthetic or anonymised datasets. Where a test truly needs live data, each copy gets its own authorisation. It also needs production-grade access controls, logged copying and use, masked sensitive fields and prompt deletion once testing ends.

The requirement is published as ISO/IEC 27001:2022 control A.8.33 test information, with implementation guidance in ISO/IEC 27002:2022 control 8.33 test information. Both start from one tension. Testing needs data that behaves like the real thing, and the real thing is usually the most sensitive material you hold.

The control does not ban production data. It prices it, and if that price feels heavy, the nudge towards synthetic data is the point.

In practice the default is a decision, not a document. Most functional testing needs the shape of the data, not the identity of the people in it, so the exception path should rarely open.

Three neighbouring controls supply the working parts:

• Environment boundary. A.8.31 establishes the separation between environments that A.8.33 presumes.
• Masking. A.8.11 covers hiding sensitive fields before data reaches test.
• Deletion. A.8.10 covers destroying the copy when testing ends.

The control also cuts the other way. Test data has to be trustworthy and protected from tampering, or the tests it feeds prove nothing. So the control is two-sided: it protects confidentiality by keeping live records out of soft systems, and integrity by keeping fixtures reliable.

Is a leaked staging database a UK GDPR personal data breach?

Yes. UK GDPR defines a personal data breach by what happened to the data, not where it was held, so a leaked test copy counts in full. "It was only staging" is no defence. The data keeps the sensitivity of its source, so a soft staging system carries production-sized liability.

Staging breaches follow a familiar pattern: a database full of real customer records, indexed by a search engine or lifted by an attacker who never had to touch production. The ICO guidance on anonymisation and pseudonymisation is the reference for when data stops being personal, and a raw test copy never gets there.

The incident does not need to be dramatic. An exposed snapshot, a database credential committed to a test config or a contractor's laptop holding an extract all count. The breach assessment starts from what the records contain, not the label on the environment.

Two audiences press on the 8.33 test information control:

• The regulator. A staging system usually carries weaker permissions than production, so a leak is more likely while the records are just as sensitive.
• Enterprise buyers. Due diligence increasingly asks what developers test on. Answering "a copy of production" without an authorisation and masking story stalls the security review.

There is a quieter cost too. Teams that test on stale or rushed, made-up data ship defects that realistic, properly engineered test data would have caught. The control that protects customers also improves the tests.

How do you manage ISO 27001 Annex A test information safely?

Make synthetic-first the house rule, then gate every exception with four controls: a named approver and expiry per copy, masking before the data moves, production-grade protection for the environment holding it, and a logged lifecycle ending in verified deletion. Each copy inherits its source's sensitivity, not the informality of its environment.

Start with the house rule. Generate datasets that mirror production's formats, volumes and edge cases without containing anyone's records. A seeded fixture library your team maintains, or a generation tool, covers most functional testing outright. It is a short build once the environment boundary from A.8.31 exists.

Where realism genuinely requires production data, put four controls on each copy:

1. Authorise per copy. A named approver, a recorded request stating what is copied and why, and an expiry date.
2. Mask before it moves. Scramble, de-identify or strip sensitive fields while keeping formats realistic, so the data still exercises the code.
3. Protect the holding environment to production standard. Role-based access, MFA, encrypted storage, periodic access review and logical separation from critical systems.
4. Log the lifecycle and verify deletion. Record who copied what, when and where, then confirm the wipe on test systems, snapshots and laptops.

A standing waiver to copy production isn't an exception path. It's a second production with weaker locks.

The ICO's guidance on privacy in the product design lifecycle describes access control that limits people, including internal users, to the information they need to see. It also suggests logging data interactions, such as who has accessed or modified data. NCSC guidance on securing development environments adds logical separation, which makes pivoting from a development system harder. It also recommends multi-factor authentication, so stolen credentials are harder to use.

Each control answers a different failure. Authorisation stops casual copies, masking limits what a leak exposes, protection makes the leak less likely, and logged deletion stops the copy outliving its purpose.

Five pitfalls quietly undo these controls:

• The Friday-afternoon production restore skips approval and masking, so the gate means nothing.
• Informal test environments with shared logins and weaker permissions undo the protection while holding equally sensitive data.
• Residual extracts on staging instances, snapshots and developer laptops outlive every deletion deadline.
• No trail of which environments hold real data turns the auditor's first question into archaeology.
• Over-engineering with an enterprise test-data-management platform, when a masking script, a fixture library and an approval step in your ticketing system deliver the control at this scale.

What counts as anonymisation, and what is just cosmetic masking?

Anonymised test data cannot be traced back to a person with reasonable effort, including by joining it with other available data. Swapping names while leaving postcodes and birth dates intact is cosmetic masking. Under UK GDPR, pseudonymised data stays personal data whenever separately held information can re-identify individuals.

The ICO guidance on anonymisation and pseudonymisation is blunt about the line. If individuals can still be identified using additional information you hold separately, the data is pseudonymised, not anonymised, and it stays personal data. Pseudonymisation still reduces exposure, so keep the key or lookup table out of the test environment and treat the dataset as personal data throughout.

Test a masked dataset before you trust it:

• Join it. Try linking it to your own production tables and to any other dataset an outsider could obtain.
• Inspect quasi-identifiers. Check postcodes, birth dates, job titles and rare combinations of attributes.
• Repeat the test. Re-identification risk shifts as outside data changes, so periodic testing is part of the control.

Masking that a determined join can undo is theatre, and UK GDPR doesn't grade for effort. When a dataset cannot pass those checks without losing the realism the test needs, synthetic data is the cleaner answer.

'It only reproduces on real data' is a bug report about your fixtures, not a licence to restore production.

How do you automate test data controls so nobody can dump production?

Treat the production-to-staging route as a pipeline. An automated job masks data in transit and becomes the only sanctioned path, with the manual dump technically disabled. A ticketing request captures approver, scope and expiry, classification scanning flags real personal data in non-production, and scheduled deletion jobs write their own receipts.

Masking in transit matters because unmasked data never lands in staging, even briefly. A mask-after-load approach leaves a window in which real records sit in a weaker system, and that window is what a leak exploits.

Four automations carry the control:

• Masking in transit. The only sanctioned route is a job that masks as it copies. Refreshes document themselves, and the manual path is closed by removing developers' permission to restore production snapshots into staging.
• Authorisation as workflow. A "copy production data" request type captures approver, scope and expiry. Expiring copies raise their own deletion tasks.
• Leak detection. Classification scanning over non-production stores flags real personal data where only synthetic data should exist. That catches the Friday restore within hours instead of at audit.
• Deletion with receipts. Scheduled destruction jobs, tied to each copy's expiry, write their own completion evidence.

If the register of live copies has to be reconstructed, nobody is running the control.

Much published guidance treats test data masking as a manual task: someone runs a script when asked, and nothing stops the next person skipping it. The pipeline reverses that default. The safe route is the easy one, the unsafe route is unavailable, and human judgement is reserved for the approval decision.

At 25 to 250 people this is a handful of scripts and a ticket type, not a new platform. The table shows what each automation catches and the evidence it leaves.

What audit evidence proves test information is controlled?

Auditors expect eight evidence types. Policy and training records show the rules exist and people know them. Authorisation records for each production copy, masking scripts with run logs, synthetic generation setup, access control evidence, audit logs and deletion records show the rules actually run.

Under ISO 27001:2022 Annex A 8.33 test information, each artefact should answer one auditor question. This list ties every type of evidence to what it proves:

1. Policy section. Proves the rules exist and developers can find them.
2. Authorisation records. Requester, approver, scope and expiry prove each copy was approved.
3. Masking scripts and run logs. Prove sensitive fields are masked in practice, not just in intent.
4. Synthetic generation setup. Tool configuration, schemas and sample output prove synthetic-first is real.
5. Access control evidence. RBAC configuration, MFA enforcement and access reviews prove the environment is protected.
6. Audit logs. Prove the trail of copying, access and use exists.
7. Deletion records. Prove copies were destroyed on schedule.
8. Training records. Prove developers and testers know the rules.

The pipeline from the automation section produces most of these as by-products. The ticket is the authorisation record, the job log is the masking evidence and the deletion receipt is the certificate. Only the policy and the training records need a person to write them.

How do auditors sample test environments, and when does a gap grade major?

The auditor picks a current test or staging database, asks what it contains, then traces any real data back to its authorisation, masking run and deletion schedule. Unmasked live personal data with no authorisation or protection grades major; a missing record, lapsed deadline or patchy logging grades minor, aggregating to major as a pattern.

The sampling runs in a predictable order:

1. Pick a database. The auditor chooses a current test or staging database and asks what is in it.
2. Trace the real data. Anything real is followed back to its authorisation, masking run and scheduled deletion.
3. Compare access. The access list for the test environment is set against production's.
4. Check a closed cycle. A recently finished test cycle is inspected for deletion evidence.
5. Ask about laptops. "How would you find a leftover production extract on a developer laptop?"

The evidence list is only half the audit. Sampling is where ISO/IEC 27001:2022 Annex A control 8.33 test information is actually tested, because it checks the live state of your environments against your records. The laptop question has no good improvised answer. You need a register of live copies, verified deletion across endpoints and a rule that extracts do not leave the pipeline.

The major case carries extra weight because it is probably a UK GDPR breach as well. Minors aggregate: three copies with thin records and a missed deadline start to look like a control nobody runs, and the grade follows the pattern.

What does a working test data discipline look like in two weeks?

Policy wording, an authorisation route and a masking script for your main datastore take one to two weeks, once the environment boundary from A.8.31 exists. The payoff is immediate, because security questionnaires ask what developers test on more often than auditors do. A clean answer keeps the security review moving.

To establish and administer an information security program that developers follow, write the test-data rules into your secure development policy. Then brief the people who decide at 5pm whether to pull a production dump. A standalone procedure is enterprise apparatus at this scale.

Ownership splits cleanly. A fractional CISO owns the approval policy: who may let production data leave its environment, and on what terms. That is a judgement call that needs security authority. GRC engineering builds the pipeline: masking as the only copy route, authorisation as workflow, scanning, and deletion jobs that write their own evidence.

The next questionnaire that asks what your developers test on gets a short, evidenced answer.

Frequently asked questions