How to Test Properly Without Exposing Real Data
ISO 27001 Control 8.33 Test information is about one simple truth:
Testing is essential – but if you use real data carelessly, your test environment can become your biggest security and privacy risk.
This control expects you to keep tests realistic and keep operational information safe. That means being very deliberate about:
- when you use real data
- how you protect it in test environments
- how you remove it afterwards
- and how you prove all of that to an auditor
What ISO 27001 Control 8.33 Actually Expects
In plain English, ISO 27001 Control 8.33 – Test information wants you to:
- Make sure test data is fit for purpose – realistic enough to give meaningful test results
- Avoid copying production / operational data into test by default
- Only use real operational data in test with explicit approval and strong controls
- Protect any operational information used in test as well as you protect it in production
- Make sure test data is removed or anonymised when you’re done
- Keep records so you can show who copied what, when, why and how it was protected
An auditor will typically ask:
- “What do you use as test data?”
- “Do you ever copy production data to test? If so, how is that controlled and protected?”
Your answers – and your logs – are what demonstrate this control.
Step 1 – Decide When You Really Need Real Data
The starting point is data minimisation:
- By default, plan to use:
- Synthetic data (generated test data), and/or
- Pre-prepared, sanitised test datasets
- Only consider using real operational data when:
- You genuinely need realistic edge cases or complex data relationships
- Synthetic data cannot adequately represent behaviour
- A risk-based decision supports it
Capture this in a short Test Data Policy that says:
- Synthetic or anonymised data is the default
- Any use of real data in test is an exception and needs approval
Step 2 – Prefer Synthetic and Dedicated Test Data
To align with Control 8.33, make synthetic or dedicated test data your standard:
- Build and maintain a dedicated test dataset
- Designed to cover common and edge cases
- Includes representative values, but not real personal / confidential data
- Use tools to generate data
- Data generation utilities for names, addresses, IDs, dates, transactions, etc.
- Scripts or fixtures that can be re-used across test environments
- Keep test data under change control
- So test results are reproducible
- And changes to test data are managed and documented
This gives you realistic testing without the risk of dragging production data everywhere.
Step 3 – Tight Rules for Using Operational Data in Test
Sometimes you will need real data. When you do, Control 8.33 expects you to treat it as a high-risk activity, not a casual copy-and-paste.
Put in place rules like:
1. Explicit authorisation each time
- Every use of real operational data in test must be:
- Requested (who, what, why, which systems)
- Risk assessed (especially for personal, client or payment data)
- Approved by an appropriate owner (e.g. data owner, system owner, DPO for personal data)
2. Data masking and minimisation
Before copying anything:
- Mask, anonymise or pseudonymise wherever possible:
- Remove or scramble names, emails, phone numbers, IDs, card details, etc.
- Consider tokenisation for sensitive identifiers
- Limit the scope:
- Only copy the subset of fields and records you really need
- Avoid full-database clones where a slice would do
3. Audit trails and traceability
- Log who copied what, from where to where, and when
- Record:
- The purpose of the copy
- Any masking or transformation applied
- When the test data will be removed
This gives you evidence that you’re not just casually spraying production data into test.
Step 4 – Apply Strong Security Controls in Test Environments
If operational data ends up in test, the test environment mustn’t be a “soft target”.
To align with Control 8.33 (and 8.31):
- Access control at least as strong as production
- Role-based access control (RBAC)
- Only those who genuinely need to see that data can access it
- No broad “everyone in dev can see everything” rights
- Environment separation
- Clear network and logical separation between production and test
- No casual backdoors from test into live systems
- Encryption in transit and at rest
- Same as production standards for any sensitive data
- Certificates and keys managed properly, not “test-only shortcuts”
- Logging and monitoring
- Log access to test data (reads, exports, admin access)
- Integrate logs with your central monitoring or SIEM where possible
- Storage integrity and tamper protection
- Protect test data against unauthorised modification
- Especially important if test outputs are used to make design or security decisions
The simple rule: if test contains real data, treat it like production from a security perspective.
Step 5 – Clean Up Test Data Properly
Test data – especially copied operational data – should not hang around indefinitely.
Implement:
- Time-bound usage
- Approvals should include how long data will be retained
- Make it clear that copies are temporary by default
- Secure deletion after use
- Apply your organisation’s secure deletion approaches (linked to Control 8.10)
- Remove data from:
- Databases
- File systems
- Snapshots and ad-hoc backups where applicable
- Minimal retention
- Keep only what’s genuinely needed, and only for as long as necessary
- Record deletion in your logs or ticketing system
This closes the loop so test environments don’t quietly become unofficial archives of real data.
Step 6 – Manage Third-Party and Cloud-Based Test Environments
If you test in the cloud or with third parties, the same principles apply – you just need to push them into your contracts.
Make sure you:
- Include test data handling in supplier contracts
- Rules for when and how operational data can be used in test
- Requirements for masking, access control, encryption and deletion
- Assess the provider’s security controls
- How they separate test and production
- How they monitor access and protect data
- Check regulatory fit
- GDPR, HIPAA, PCI DSS, or other sector-specific rules for using real data in test
- Data residency and cross-border issues if test environments are hosted overseas
Treat supplier testing environments as an extension of your own risk surface.
Typical Risks When Test Information Is Poorly Managed
If Control 8.33 isn’t implemented properly, you can easily end up with:
- Data breaches – test environments are often less secure and more accessible
- Regulatory non-compliance – especially where personal or payment data is involved
- Inaccurate testing – if data is unrealistic or gets tampered with
- Operational incidents – leftover test data causing confusion or logic errors
- Legal and financial impact – fines, claims and remediation costs
- Loss of customer trust – “we lost your data in a dev environment” is a hard message to recover from
Most of these risks are avoidable with a few sensible controls.
Quick Implementation Checklist for ISO 27001 Control 8.33
A straightforward way to gauge your readiness:
- You have a Test Data / Test Information Policy that defines when real data may be used in test.
- Synthetic or dedicated test datasets are the normal default for testing.
- Any use of operational/production data in test requires explicit authorisation (and is documented).
- When operational data is used in test, it is masked, minimised or anonymised wherever possible.
- Test environments that hold real data have access controls, encryption, logging and monitoring equivalent to production.
- All copies of operational data in test are time-limited and securely deleted when no longer needed.
- There is a full audit trail of when operational data is copied, who approved it, and when it was removed.
- Third-party and cloud test environments are covered by contracts and assessments that reflect these requirements.
- Test data handling is included in security awareness training for developers, testers and admins.
- Test information practices are reviewed periodically to keep up with legal, regulatory and business changes.
If you can show that you use realistic test data without casually exposing production information, and that any use of real data in test is controlled, logged and cleaned up, you’ll be in a strong position for ISO 27001 Control 8.33 – and significantly safer in day-to-day operations as well.
Explore the ISO 27001 Controls