What does control A.3.31 require?
Test information related to PII processing shall be appropriately selected, protected and managed.
This control sits within the Shared security controls annex (A.3) and addresses one of the most common causes of unnecessary PII exposure: copying production data into test and development environments. Test environments typically have weaker access controls, broader access, less monitoring and more transient infrastructure than production systems, making them a significant privacy risk if they contain real PII.
What does the Annex B implementation guidance say?
Annex B (section B.3.31) provides the following guidance:
- Prefer synthetic data — PII should not be used for testing purposes; false or synthetic PII should be used instead
- Apply equivalent controls when PII is unavoidable — Where the use of PII for testing purposes cannot be avoided, technical and organisational measures equivalent to those used in the production environment should be implemented to minimise the risks
- Risk assess when equivalent controls are not feasible — Where such equivalent measures are not feasible, a risk assessment should be undertaken and used to identify the selection of appropriate mitigating controls
- See also A.3.28: Application Security Requirements for related requirements
- See also A.3.29: Secure System Architecture and Engineering Principles for related requirements
The guidance establishes a clear hierarchy: synthetic data first, then production-equivalent controls if real PII is unavoidable, then risk-assessed mitigations as a last resort. This graduated approach acknowledges that some testing scenarios may genuinely require real data while making clear that this should be the exception rather than the rule.
How does this map to GDPR?
Control A.3.31 maps to the following GDPR article:
- Article 5(1)(f) — The integrity and confidentiality principle, requiring appropriate security of personal data including protection against unauthorised processing
Using real PII in test environments where security controls are weaker than production is a direct violation of Article 5(1)(f). Supervisory authorities have taken enforcement action against organisations that exposed personal data through inadequately secured test environments.
For the full GDPR-to-ISO 27701 mapping, see GDPR Compliance Guide.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clause 6.11.3.1 (protection of test data). The 2025 edition retains the core requirements as A.3.31 with the implementation guidance in B.3.31 now providing a clearer three-tier hierarchy for test data management: synthetic data, equivalent controls, then risk-assessed mitigations. See the Annex F correspondence table for the full mapping.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.3.31, auditors will typically look for:
- Test data policy — A documented policy specifying that synthetic or anonymised data must be used for testing, with a defined process for exceptional cases where real PII is required
- Synthetic data capability — Evidence that the organisation has tools or processes for generating realistic but fictitious test data
- Test environment security — Where real PII is used in testing, evidence that the test environment has security controls equivalent to production (access controls, encryption, logging, monitoring)
- Risk assessments — Where equivalent controls are not feasible, documented risk assessments identifying the risks and selected mitigating controls
- Test data lifecycle management — Evidence that real PII used in testing is removed or destroyed after the testing purpose is complete
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.27 Secure development life cycle | Test data management should be embedded in the development lifecycle |
| A.3.30 Outsourced development | Outsourced developers must not use real PII for testing |
| A.1.4.6 De-identification and deletion | De-identification techniques can create usable test data from production data |
| A.3.9 Access rights | Access to test environments containing real PII must be controlled |
| A.3.25 Logging | Access to PII in test environments should be logged |
Who does this control apply to?
A.3.31 is a shared control that applies to both PII controllers and PII processors. Any organisation that tests systems which process PII must manage test data appropriately. This is particularly important for SaaS providers, software houses and managed service providers where development and testing are ongoing activities rather than one-off projects.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Why choose ISMS.online for test data management?
ISMS.online provides practical tools for managing test information securely:
- Policy management — Publish test data policies with version control and staff acknowledgement tracking
- Risk assessments — Run targeted risk assessments for scenarios where real PII in testing is unavoidable, with documented mitigating controls
- Exception management — Track approved exceptions where real PII is used for testing, including justification, approval, security measures applied and data destruction confirmation
- Compliance monitoring — Monitor test environment compliance with your test data policy across development teams
- Evidence management — Store test data management evidence including synthetic data capability documentation, risk assessments and exception records for audit readiness
FAQs
When is it acceptable to use real PII for testing?
Real PII should only be used when synthetic data cannot adequately replicate the testing scenario. Common justifications include: testing data migration from a legacy system (where the data structure and content must be verified), diagnosing a production issue that cannot be reproduced with synthetic data, or performance testing where data volume and characteristics must match production. In all cases, a risk assessment must be performed, equivalent security controls should be applied, and the real PII must be removed from the test environment once the testing purpose is complete.
What techniques can be used to create synthetic test data?
Common techniques include: data generation tools that create realistic but fictitious records (names, addresses, identifiers); data masking or pseudonymisation that replaces real PII values with fictional ones while preserving data structure and relationships; data subsetting that takes a small sample from production and anonymises it; and data synthesis tools that use statistical models to generate data with the same distribution characteristics as production data. The approach should preserve the testing value of the data while eliminating the privacy risk.
What security controls are needed for test environments with real PII?
The standard requires controls equivalent to those in the production environment. This typically includes: the same access control model with the same authentication requirements; encryption at rest and in transit; logging and monitoring of all data access; regular access reviews; secure environment isolation from public networks; and data destruction procedures for when testing is complete. Many organisations find it simpler and less risky to invest in synthetic data capability rather than duplicating production security controls across multiple test environments.
