ISO/IEC 27001:2022 Annex A 8.33 – Test Information focuses on protecting information used for testing, particularly when that information contains sensitive, confidential, personal, or business-critical data.
Testing is an essential part of software and system development. However, test environments can introduce security risks when organizations copy real production information into development, QA, staging, testing, or security-testing environments without appropriate controls.
For startups and SaaS companies, this is especially important because test environments may be accessed by:
- Developers
- QA teams
- Security testers
- External vendors
- Contractors
- Interns
- Automated testing tools
- CI/CD systems
The objective is simple:
Use test information safely and ensure that information used for testing is appropriately protected.
What Is ISO 27001 Annex A 8.33?
A.8.33 addresses the protection and appropriate management of information used for testing.
This can include:
- Application test data
- Database test data
- API test data
- Security testing data
- Performance testing data
- User acceptance testing data
- System integration testing data
- Disaster recovery testing information
- Test accounts
- Test files
- Configuration information
- Sample customer records
The organization should consider the sensitivity of the information and apply appropriate security controls.
Why Is Test Information Important?
Test environments are often less tightly controlled than production environments.
This can create several risks.
1. Exposure of customer information
A company may copy real customer records into a development or QA environment.
2. Unauthorized access
More people may have access to test environments than production.
3. Data leakage
Test databases may be copied to laptops, cloud storage, repositories, or third-party testing platforms.
4. Privacy violations
Personal information may be used for testing without appropriate safeguards.
5. Security testing exposure
Sensitive credentials or security configuration information may accidentally become part of test data.
6. Long-term retention
Test datasets may remain in environments long after testing has finished.
7. Third-party exposure
External developers or testing companies may gain access to sensitive test information.
What Is Test Information?
Test information is broader than just “test data.”
It may include any information used to validate or test systems.
Examples:
| Type | Example |
|---|---|
| Test data | Customer-like records |
| Test accounts | Dummy user accounts |
| Test credentials | Test API keys |
| Test files | Sample documents |
| Database data | Test records |
| API data | Request/response datasets |
| Security data | Vulnerability test cases |
| Configuration | Test environment settings |
| Performance data | Load-testing datasets |
| Integration data | Third-party integration records |
Real Data vs Synthetic Data
One of the most important considerations under A.8.33 is whether real production information is actually necessary for testing.
Preferred approach
Use:
- Synthetic data
- Dummy data
- Generated datasets
- Anonymized data
- Masked data
- Pseudonymized data
where appropriate.
Higher-risk approach
Copying production customer information directly into a development environment.
For example:
Production Database
|
| Direct Copy
v
Development Database
|
+--> Developers
+--> QA
+--> Vendors
+--> Test Tools
This can unnecessarily expand the number of people and systems with access to sensitive information.
A safer approach is:
Production Data
|
v
Approved Transformation
|
v
Masked / Anonymized Dataset
|
v
Test Environment
Or, where practical:
Synthetic Test Data
|
v
Test Environment
Does ISO 27001 Prohibit Production Data in Test Environments?
Not necessarily.
The control should not be interpreted as an absolute prohibition on using production information for testing.
There may be legitimate circumstances where realistic production data is required.
For example:
- Complex database migration
- Disaster recovery testing
- Large-scale performance testing
- Production incident investigation
- Compatibility testing
- Regulatory testing
- Specialized application testing
The organization should assess the need and apply appropriate safeguards.
When Real Production Data Is Required
If production data must be used for testing, consider:
- Business justification
- Risk assessment
- Data minimization
- Masking or anonymization where possible
- Restricted access
- Secure transfer
- Encryption
- Defined retention period
- Controlled copying
- Monitoring
- Secure deletion after testing
The objective is to avoid treating test environments as unrestricted copies of production.
How to Implement ISO 27001 A.8.33
Step 1 – Identify Test Information
Create an inventory of information used during testing.
For example:
| Test Information | Source | Sensitivity | Environment | Owner |
|---|---|---|---|---|
| Synthetic customer data | Generated | Low | QA | QA Team |
| Masked production data | Production | Medium | Staging | Data Owner |
| API test dataset | Generated | Low | Development | Engineering |
| Security test cases | Security Team | Confidential | Security Lab | CISO |
| Payment test data | Test provider | Controlled | Test | Engineering |
Step 2 – Classify Test Information
Apply the organization’s information classification rules.
For example:
| Classification | Example |
|---|---|
| Public | Public product information |
| Internal | Internal test documentation |
| Confidential | Business test data |
| Restricted | Personal, financial, security-sensitive information |
The classification should determine how the test information is protected.
Step 3 – Prefer Synthetic Test Data
Where realistic data is not required, generate synthetic data.
For example, instead of using:
Real Customer:
Name: Actual Customer
Email: Real Email
Phone: Real Phone
Address: Real Address
use:
Test Customer:
Name: Test User 001
Email: test001@example.test
Phone: 0000000000
Address: Test Address
Synthetic data should still be designed to provide meaningful test coverage.
Step 4 – Mask or Anonymize Sensitive Data
When realistic datasets are required, apply appropriate transformation.
Examples:
Original
Customer Name: Rahul Sharma
Email: rahul@example.com
Phone: +91 XXXXXXXX
Masked
Customer Name: TEST USER
Email: test001@example.test
Phone: +91 0000000000
The specific masking method should be appropriate to the data and risk.
Step 5 – Restrict Access
Test data should only be accessible to people who need it.
Consider:
- Individual accounts
- Role-based access
- MFA
- Least privilege
- Access reviews
- Vendor restrictions
- Temporary access
- Logging
Do not assume that test data is safe simply because it is not in production.
Step 6 – Protect Test Data During Transfer
When test information moves between systems, apply appropriate safeguards.
For example:
Source
↓
Encrypted Transfer
↓
Controlled Storage
↓
Test Environment
Avoid transferring sensitive test datasets through:
- Personal email
- Consumer file-sharing accounts
- Unapproved messaging applications
- Unencrypted storage
- Developer laptops without appropriate controls
Step 7 – Control Test Data in Cloud Environments
Cloud environments often contain multiple copies of test information.
Check:
- Object storage
- Database snapshots
- Backups
- Container volumes
- Logs
- Temporary files
- Developer machines
- CI/CD artifacts
- Test automation platforms
A test dataset may continue to exist even after the main database is deleted.
Step 8 – Control Test Data Retention
Define how long test information should be retained.
For example:
Testing Completed
↓
Review Retention Requirement
↓
No Longer Required?
|
v
Secure Deletion
↓
Deletion Evidence
Retention should be based on business, security, contractual, legal, and regulatory requirements.
Step 9 – Securely Delete Test Information
When testing is complete, information that is no longer required should be securely removed.
Consider:
- Database deletion
- Cloud storage deletion
- Snapshot deletion
- Backup handling
- Local copies
- CI/CD artifacts
- Temporary files
Where appropriate, maintain evidence of deletion.
Step 10 – Control Third-Party Testing
External testing companies, penetration testers, developers, QA providers, and SaaS testing tools may receive test information.
Before sharing sensitive information, consider:
- Vendor security assessment
- Confidentiality requirements
- Data processing requirements
- Access restrictions
- Encryption
- Data retention
- Secure deletion
- Subcontractor controls
- Incident notification requirements
This connects A.8.33 with supplier-related controls and A.8.30 – Outsourced Development.
Example – SaaS Startup
Consider a SaaS company developing a payroll application.
The production database contains:
- Employee names
- Email addresses
- Salary information
- Bank-related information
- Employer information
The development team wants realistic data for testing.
Poor approach
The complete production database is copied into the development environment.
Developers and external contractors can access it.
There is no masking or deletion process.
Better approach
The organization creates a controlled test dataset.
Production Data
|
v
Data Selection
|
v
Masking / Transformation
|
v
Test Dataset
|
v
Restricted Test Environment
The resulting data contains realistic structures without unnecessarily exposing actual sensitive information.
Security Testing Example
A penetration tester may need realistic application records.
Instead of providing a full production database, the organization can provide:
- Dedicated test accounts
- Synthetic customer records
- Test payment information
- Test API credentials
- Controlled test files
The tester receives only the information required to perform the assessment.
This follows the principle of minimum necessary access.
Test Information and AI Systems
Modern organizations may use AI tools during software testing.
Examples include:
- AI-powered code testing
- AI security scanners
- AI test-data generators
- External LLM services
- Automated QA platforms
Organizations should consider whether test information is sent to external AI or SaaS platforms.
Sensitive information should not be uploaded to external services unless the organization has assessed and approved the service and appropriate contractual and technical safeguards are in place.
Test Information and Logs
Test information can also appear in application and testing logs.
For example:
POST /customer
Name=Test User
Email=test@example.com
Phone=...
Logs may contain:
- Personal data
- Authentication information
- API tokens
- Request data
- Error messages
- Database information
Therefore, test information should be considered when designing logging and monitoring controls.
What Events Should Trigger a Review?
Review A.8.33 controls when:
| Trigger | Review |
|---|---|
| New application | Define test data requirements |
| New testing environment | Review access and data |
| Production data required for testing | Perform risk assessment |
| New vendor | Review third-party test data access |
| New testing tool | Assess where data is sent |
| Cloud migration | Review data copies and storage |
| New regulation | Review data handling |
| Security incident | Review test data exposure |
| Major application change | Review testing datasets |
| AI testing tool introduced | Review external data processing |
| Testing completed | Delete unnecessary data |
Startup Quick Summary
For most startups, the simplest approach is:
Use synthetic data whenever possible.
If realistic data is needed:
Mask or anonymize it.
Then:
Restrict access → Encrypt → Monitor → Define retention → Delete when no longer required.
The objective is to prevent a test environment from becoming an uncontrolled copy of the production environment.
Minimum Startup Implementation
A startup can implement A.8.33 with the following baseline controls:
1. Test data procedure
Document how test information is created, accessed, shared and deleted.
2. Synthetic data
Use synthetic or dummy data whenever practical.
3. Masking
Mask sensitive production information when realistic data is required.
4. Access control
Restrict test information to authorized personnel.
5. Secure transfer
Use approved and protected methods for transferring test information.
6. Retention
Define how long test information should be retained.
7. Secure deletion
Delete test information when it is no longer required.
8. Vendor control
Assess external testing providers that receive sensitive information.
9. Cloud storage review
Check databases, snapshots, backups and storage buckets for test-data copies.
10. Evidence
Maintain sufficient records to demonstrate that test information is controlled.
Test Information Register
A practical register can look like this:
| ID | Test Dataset | Data Type | Source | Sensitivity | Environment | Access | Retention | Owner |
|---|---|---|---|---|---|---|---|---|
| TEST-001 | Customer Test Data | Synthetic | Generated | Low | QA | QA Team | 90 days | QA |
| TEST-002 | Application Dataset | Masked | Production | Medium | Staging | Engineering | 30 days | Data Owner |
| TEST-003 | Security Dataset | Synthetic | Security Team | Low | Security Lab | Security Team | Project duration | CISO |
| TEST-004 | Integration Data | Synthetic | Generated | Low | Test | Engineering | 60 days | Engineering |
Production Data Usage Approval
If production data must be used for testing, consider maintaining an approval record.
| Item | Example |
|---|---|
| Dataset | Customer transaction data |
| Business justification | Production migration testing |
| Data owner | Application Owner |
| Risk assessment | Completed |
| Masking | Applied |
| Access | Restricted |
| Environment | Controlled staging |
| Retention | 14 days |
| Deletion | Required after testing |
| Approval | Data Owner + Security |
Audit Evidence for A.8.33
An auditor may look for:
Policies and procedures
- Test Information Policy
- Test Data Management Procedure
- Data Masking Procedure
- Data Retention Procedure
Test information
- Test data inventory
- Test data register
- Dataset classification
- Test environment records
Access control
- User access lists
- IAM configurations
- Access reviews
- MFA evidence
- Vendor access records
Data protection
- Masking evidence
- Anonymization procedures
- Encryption configuration
- Secure transfer evidence
Retention and deletion
- Retention requirements
- Deletion records
- Cleanup tickets
- Storage lifecycle rules
Third-party testing
- Vendor assessments
- Contracts
- NDAs
- Data processing agreements
- Security requirements
ISO 27001 A.8.33 Audit Checklist
| # | Audit Question | Evidence |
|---|---|---|
| 1 | Is test information identified and appropriately managed? | Test data register |
| 2 | Is synthetic data used where practical? | Test datasets |
| 3 | Is production data used for testing only when justified? | Approval/risk assessment |
| 4 | Is sensitive test information classified? | Data classification |
| 5 | Is access to test information restricted? | IAM/access matrix |
| 6 | Is test information protected during transfer? | Transfer/security controls |
| 7 | Is sensitive information masked or anonymized where appropriate? | Masking evidence |
| 8 | Are test datasets protected in cloud storage? | Cloud configuration |
| 9 | Are test data copies controlled? | Storage review |
| 10 | Is test information retained only as required? | Retention policy |
| 11 | Is unnecessary test information securely deleted? | Deletion evidence |
| 12 | Are third parties controlled when they receive test information? | Vendor assessment |
| 13 | Are test accounts and credentials protected? | IAM/secrets evidence |
| 14 | Are logs reviewed for sensitive test information? | Logging configuration |
| 15 | Are AI or external testing services assessed before sensitive data is shared? | Vendor/security assessment |
Common Mistakes
Mistake 1 – Copying the entire production database
This is one of the most significant risks.
Use synthetic, masked, or minimized datasets where possible.
Mistake 2 – Assuming test data is automatically safe
Data does not become non-sensitive simply because it is moved from production to testing.
Mistake 3 – No access restrictions
Developers, contractors, vendors and testers should not automatically receive access to all test information.
Mistake 4 – Test data remains forever
Old test databases, snapshots and files can become forgotten sources of sensitive information.
Mistake 5 – Ignoring backups
Deleting a test database does not necessarily delete copies in snapshots or backups.
Mistake 6 – Sharing data with external testing tools
Before uploading test information to an external SaaS, AI service or testing platform, assess how the provider handles the information.
Mistake 7 – Test credentials are reused in production
Test accounts, API keys and passwords should be separated from production credentials.
Policy vs Process vs Technical Control
| Area | Example |
|---|---|
| Policy | Test information must be appropriately protected |
| Procedure | Define how test data is created, approved, accessed and deleted |
| Technical Control | Masking, encryption, IAM and storage restrictions |
| Process Control | Production-data approval and test-data review |
| Monitoring | Access and data-transfer logs |
| Evidence | Test-data register, approvals and deletion records |
Relationship With Other ISO 27001 Controls
A.8.33 works closely with:
| Control | Relationship |
|---|---|
| A.8.25 Secure Development Life Cycle | Defines security throughout development |
| A.8.26 Application Security Requirements | Defines security requirements |
| A.8.29 Security Testing in Development and Acceptance | Requires appropriate security testing |
| A.8.31 Separation of Development, Test and Production Environments | Separates testing from production |
| A.8.32 Change Management | Controls changes resulting from testing |
| A.5.12 Classification of Information | Helps determine protection requirements |
| A.5.13 Labelling of Information | Supports identification of sensitive information |
| A.5.14 Information Transfer | Protects information during transfer |
| A.5.34 Privacy and Protection of PII | Relevant when personal information is used |
| A.8.3 Information Access Restriction | Restricts access to test information |
| A.8.10 Information Deletion | Supports secure deletion |
A.8.31 vs A.8.33
These controls are closely connected but address different risks.
| Control | Main Focus |
|---|---|
| A.8.31 | Separating development, test and production environments |
| A.8.33 | Protecting information used for testing |
Example:
A company has a separate staging environment.
A.8.31: Ensures the staging environment is appropriately separated from production.
A.8.33: Ensures the data used in staging is appropriately protected.
Both controls should work together.
A.8.29 vs A.8.33
These controls are also different:
| Control | Main Question |
|---|---|
| A.8.29 Security Testing | Are systems appropriately tested for security? |
| A.8.33 Test Information | Is the information used during testing appropriately protected? |
A penetration test may be required under A.8.29, while the test accounts, datasets and information provided to the tester need appropriate protection under A.8.33.
Practical Implementation Model
A startup can implement A.8.33 using the following model:
TESTING REQUIREMENT
|
v
What data is needed?
|
+----------+----------+
| |
v v
Synthetic Data Real Data Needed?
| |
| Risk Assessment
| |
| Mask / Anonymize
| |
+----------+----------+
|
v
Restricted Access
|
v
Secure Transfer
|
v
TESTING
|
v
RETENTION REVIEW
|
v
Secure Deletion
Useful Resources
Organizations implementing A.8.33 may benefit from maintaining:
- Draft Test Information Security Policy —
[Insert Document Link] - Test Data Management Procedure —
[Insert Document Link] - Test Data Classification Template —
[Insert Document Link] - Production Data Usage Approval Form —
[Insert Document Link] - Test Data Register —
[Insert Document Link] - Data Masking Checklist —
[Insert Document Link] - Test Data Retention & Deletion Checklist —
[Insert Document Link] - Third-Party Test Data Sharing Checklist —
[Insert Document Link]
Final Takeaway
ISO 27001 Annex A 8.33 is about protecting information used during testing.
For most startups, the practical approach is:
Use synthetic data where possible. If real data is required, minimize, mask or anonymize it, restrict access, protect it during transfer and storage, define retention, and securely delete it when testing is complete.
A test environment should never become an uncontrolled copy of production simply because it is called “test.”
The goal is not to prevent realistic testing.
The goal is to enable realistic testing without unnecessarily exposing sensitive information.