ISO 27001 control 8.33 does not ban production data in tests, but it asks you to select, protect and manage test information, especially when it is sensitive. Safer routes are synthetic or masked data. If you do use real data, restrict access and document why.
What the control says
Control 8.33 requires organizations to select, protect and manage test information. The care rises with the sensitivity of the data. Documentation is recommended: a secure development policy for smaller and mid sized companies, or a procedure for using test information for larger ones.
Options compared
| Option | Risk | Notes |
|---|---|---|
| Synthetic data | Low | Built from rules, no real person involved |
| Masked or anonymized copy | Low to medium | Larger companies may use sample generation software to create de-characterized copies |
| Subset of production | Medium | Only with strong access limits |
| Full production copy | High | Needs a clear reason and tight protection |
Smaller companies may rely mainly on strict access control. Larger ones may add tools that generate anonymized copies of production data.
Steps to put in place
- Define criteria for choosing test data.
- Define how it is prepared, for example masking steps.
- Define how it is protected from unauthorized access.
- Record who approved any use of real data.
- Delete test copies when the test ends.
- Train developers on all of the above.
Evidence an auditor can check
Auditors may check whether information used for testing is properly selected and protected. Useful items:
- The written criteria in your policy
- A sample test dataset with its masking method
- Access list for the test environment
- A ticket showing approval when real data was used
- Evidence that old copies were removed
A note on privacy law
Real personal data in test systems can raise legal duties beyond ISO 27001. This post covers the control only. Ask your privacy lead about your own obligations.
A practical default for small teams
If you have no tooling for anonymizing data, start with synthetic fixtures checked into the repository. They are safe to share, easy to reset and need no access reviews. Reserve any real data for rare cases such as reproducing a production bug, and then use the smallest slice for the shortest time. Write that rule into the policy in two sentences, and the evidence trail becomes a handful of tickets rather than a standing risk.
Quick check
Is masked data always safe?
Not always. Weak masking can leave people identifiable, so test the method and keep access limited anyway.
Does the control apply to staging?
Yes. Any environment that holds test information is in scope, including staging.
Where tooling helps
Safeguard offers compliance and evidence automation and policies that can keep records of test data rules. Choosing and masking the data is your team's work. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
