A.8.33 Test information: requirements and evidence

What A.8.33 test information asks for and why test data leaks

A.8.33 Test information asks an organization to select, protect and manage the information it uses for testing, so that tests are meaningful and the operational information behind them stays protected. In plain terms, the control expects you to decide deliberately what goes into a test environment, to guard it as carefully as the data warrants, and to control how it is handled from the moment it is copied in until it is removed. An auditor will look for a documented decision about test data, not just a test environment that happens to work.

The risk is easy to create and hard to see. A developer restores a production database to reproduce a bug, a vendor receives a sample extract to debug an integration, or a QA team loads a file of real customer records to check reports. Test systems are often less controlled than production: they may lack the access reviews, logging, encryption and monitoring applied to live systems, they are cloned to laptops and shared sandboxes, and they are rarely included in backup or deletion schedules. Personal data copied this way can bring privacy obligations along with it, which is why the control sits alongside A.8.11 Data masking and A.8.31 Separation of development, test and production environments.

The difficulty is usually process, not technology. Teams under delivery pressure reach for the quickest copy, and no one owns the question of which dataset is approved for which purpose. Before your next assessment, confirm three things with the system owners: which sources may feed test environments, which transformations (masking, pseudonymization or synthetic generation) are required first, and who records the deletion when testing ends. Your evidence will be the approval record, the transformation method and the deletion record for each copy, so start by listing every place test data currently lives.

Which test environments and test data A.8.33 covers

A.8.33 applies wherever testing uses information, so the scope starts with an inventory of every place test data lives or is touched. The cards below cover the environments, data sources, endpoints and third parties that auditors expect to see in that inventory, along with the decisions that change how much work the control requires.

Non-production environments

Staging, QA, performance and integration environments are the core of A.8.33 scope. Each one needs a named owner, a documented data source and a record of what was loaded into it and when. Performance environments are often overlooked because they are sized to resemble production, which makes them the most likely place for a full copy of live records to sit. Confirm that each environment appears in the asset inventory and the Statement of Applicability entry for A.8.33.

Test datasets and seed files

Test datasets, fixtures, database dumps and seed scripts carry the same information risk as the environments that load them. A dump taken for debugging can persist in a shared drive long after the bug is fixed. Treat each dataset as an information asset with an origin, a classification and a deletion date, and check that the repository holding seed files does not contain production extracts.

Developer and tester endpoints

Laptops and workstations used for testing often hold local database copies, exported reports or screenshots containing customer records. These copies sit outside the environments that the team manages centrally, so they are easy to miss in scoping. Ask whether developers may download production extracts at all, how local copies are encrypted and removed, and whether the endpoint controls under A.8.1 apply to them.

Vendor-hosted test tenants

Software-as-a-service vendors often provide sandbox or test tenants that are loaded with customer data during onboarding or support escalations. These tenants are third-party information locations even when no one in the organization administers them. Include them in scope, confirm the contract allows the data to be used for testing, and record who requested each copy and when it was removed.

Live data and exception approval

The most consequential scoping decision is whether live or operational data is ever permitted in a test environment. Organizations that allow it need a written exception process, a named approver who is independent of the requesting team, a time limit on the exception and an access list for the copy. Organizations that prohibit it should say so in policy and check for drift through periodic reviews of environment contents.

Synthetic data generation

Where live data is not permitted, synthetic data is the usual replacement, and its generation method is in scope. Record which tool or script generates the data, what rules prevent generated records from matching real individuals, and whether the generator itself is restricted to approved users. Synthetic data also needs a documented validation step so that testing remains representative of production behavior.

How an auditor tests A.8.33 test information

This table sets out how an assessor typically tests each part of A.8.33, from selection rules for test data to deletion after testing, with the evidence requested and the findings seen most often. Read it as a trace: the assessor picks a few test environments, follows the data back to its production source, and checks each step against a record. The main takeaway is that a missing approval record for copied production data is one of the most frequent gaps, and it is cheap to prevent if the record is created before the copy is made.

Area	Assessor procedure	Evidence requested	Common findings
Test data selection rules	Read the documented rules for what may enter test environments and check whether they name data types, synthetic data preference and owner sign-off. Compare the rules with the test data actually found.	Written test data policy or procedure, version history, and the owner or role that approves it.	Rules exist but do not say when production data is allowed, or the policy is not known to the engineers who build test sets.
Approval record for production data	Pick a sample of test environments and ask whether any production data was copied in. For each copy, ask for the approval given before the copy was made.	Dated approval with the requester, data owner, purpose, data fields, and the environment that received the copy.	No approval record exists for copied data, or approval was given after the copy was loaded. This is a frequent finding.
Protection in non-production systems	Check whether test environments apply controls comparable to what protects the source data, such as access restriction, encryption and masking of personal fields. Confirm who can reach the test copy.	Access lists for test environments, masking or anonymization method used, and configuration evidence for storage and transfer.	Test environments have broader access than production, contain unmasked personal data, or are reachable from less controlled networks.
Traceability from source to test	Trace a sampled dataset from its production source through the copy process to the test environment, confirming the path matches what was approved.	Data extraction logs, transfer records, job or pipeline history, and the link between the approval and the copy.	The copy cannot be traced to a source, or the transfer path differs from the approved one. Logs are often missing or incomplete.
Deletion after testing	Check whether test data is removed when testing ends, and whether the deletion is recorded. Look for stale copies left in backups, snapshots or developer workstations.	Retention or disposal rule for test data, deletion tickets or pipeline output, and a list of environments with their removal dates.	Copies persist months after testing, no deletion record exists, or copies sit in snapshots and laptops outside the documented process.
Relevance of test information	Ask whether the test data is selected to suit the testing purpose and whether synthetic or reduced datasets were considered first.	Test plans or test case descriptions that tie the dataset to the objective, and any record of alternatives considered.	Full production extracts are used for convenience when a smaller or synthetic set would meet the test objective, with no justification recorded.
Sampling approach	The assessor usually samples a few test environments rather than every one, then traces data for each sampled environment from source to deletion.	A complete inventory of test environments so the assessor can select samples and you can show coverage.	No inventory exists, so the organization cannot show which environments it has or which copies to trace.

Implementing A.8.33 in sequence

This sequence turns A.8.33 from a policy statement into a chain of artifacts: what test environments exist, what data they hold, the rules that govern that data, the technical controls that enforce those rules, and the deletion and review records an auditor can sample. Each step names the output that closes it.

Inventory test environments and their data
Start by listing every non-production environment that receives or generates data, including shared QA stacks, staging, sandboxes, developer laptops, CI runners and contractor-owned test systems. For each one, record the owner, the data sources that feed it, whether personal or confidential data is present, and how long copies persist. The output is a test environment register that the rest of the sequence refers to. It is done when the owning team has signed off that no environment is missing from the list.
Write the test data policy
Draft a test data policy that states which sources may be used for testing, when production data may be copied and under what conditions, and which masking, pseudonymization or synthetic generation rules apply. Name the roles that approve exceptions, such as the data owner and the security function, and set retention limits for each data category. Management approves the policy and it is published to engineering and testing teams. The output is an approved policy with an exception log template.
Define masking and synthetic data methods
For each data category the policy allows in test use, document the method that makes it safe: masking rules for fields such as names, account numbers and contact details, or a generator that produces synthetic records with realistic structure but no real individuals. Record which tool or script performs each method and who verifies its output. The output is a masking and generation specification, reviewed against the data classification the organization already uses. Confirm with the data owner which techniques satisfy the legal rules that apply to your records.
Enforce restrictions in pipelines and access
Turn the policy into technical controls. Block restores of production database backups into test environments at the infrastructure or database level, restrict who can move data between environments, and require masking jobs to complete before any dataset is promoted. In source control, protect the branches that hold test fixtures so that only approved roles can merge changes, using a mechanism such as GitLab protected branches, and run static analysis such as Semgrep in CI to catch hard-coded credentials or real-looking data in fixtures. The output is configuration evidence: pipeline definitions, access policies and branch protection settings.
Control data loads and approvals
Require a request, an approval and a log entry each time production-derived data is loaded into a test environment. The request should state the environment, the dataset, the purpose, the masking method applied and the planned deletion date. Keep the approvals and load logs in a system the security function can query. The output is a sample set of approved requests that matches the load records, which is what an assessor will test first.
Run deletion after each test cycle
Delete test data when the testing purpose ends or when the retention limit in the policy is reached, whichever comes first. Use a documented deletion method for each storage type, including databases, object storage, snapshots, container volumes and developer machines, and extend it to backups and copies held by contractors. Record who deleted what and when. The output is a deletion log and, for sensitive datasets, a confirmation from the environment owner that the copy no longer exists.
Review the register and policy periodically
Repeat the inventory on a fixed schedule set by the organization, compare it to the register, check that exceptions were closed, and sample recent test environments for leftover production-derived data. Update the policy when new systems or data types appear. The output is a dated review record with findings, owners and corrective actions. Keep this record with the policy so that an assessor can see the control operating over time, not only at the point of design.

Evidence that passes A.8.33 test information

An assessor testing A.8.33 looks for a chain of evidence: a rule for what may enter test environments, a record of what actually did, and proof that test data was removed afterward. The cards below cover the artifacts that connect those points, and each one should be refreshed on a schedule rather than rebuilt before an audit.

Test data policy

A written policy that states which data may be used in testing, who approves exceptions, and which environments count as test environments. It should name the owner, the approval roles and the review date. Check that the policy matches what engineers do: if the policy bans production copies but pipelines still restore them, the gap is the finding. Review it at a fixed interval and after any change to hosting or testing tooling, and keep the dated versions.

Register of test environments and datasets

An inventory listing each test environment, its hosting location, its owner and every dataset loaded into it, with the source of that dataset and its classification. Assessors use it to trace a test system back to its origin. Keep the register current by generating it from infrastructure-as-code state or the CI/CD configuration where possible, and reconcile it against the actual environments each quarter so that forgotten staging copies do not appear only in an audit sample.

Approval records for production-derived data

Where production data is used for testing at all, a signed approval that names the dataset, the business reason, the personal or sensitive data elements involved, the approver and an expiry date. Without such records, any production copy is an unauthorized transfer. Store the approvals in a ticketing or GRC system linked to the dataset ID in the register, so that an assessor can follow one dataset from request through to deletion.

Masking and data generation procedures

Documented methods for producing test data: masking or pseudonymization scripts, synthetic data generators and the rules they follow. Record the version of each script and the fields it covers, and test that masked output does not still contain identifiers. Keep a sample of the before and after checks as proof. Related expectations sit under A.8.11 Data masking, so cross-reference the two controls rather than duplicating the procedure.

Access settings on test systems

Exports or screenshots showing who can reach each test environment, how their access is granted and whether accounts are reviewed. Test systems holding copied data often have looser access than production, which assessors notice. Pull these settings from the identity provider or directory on a schedule, and keep the access review sign-offs with dates so the evidence shows the review happened in practice.

Deletion logs and certificates

Records showing that test data was removed when its approved use ended, including the dataset ID, the deletion method, the date and the person or pipeline that ran it. Where a hosting provider or contractor deletes data, obtain their written confirmation. Pipeline logs that tie each deletion to an expiry date are stronger evidence than a manual checklist, and they should be retained so a sample can be traced end to end.

What meeting A.8.33 test information costs

This table lists the cost components of meeting A.8.33 and who is paid for each, marking whether the cost is one-time or recurring. Use the drivers column to see what pushes each cost up, and the open-source column to separate license spend from engineering and upkeep effort. No price figures are given because none are supplied; ask for the figures in a written scope.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Policy and procedure writing	Internal compliance lead, or an external consultant if hired	One-time, then reviewed periodically	Number of test data categories and teams that need rules; reuse of existing data policies lowers effort
Data discovery and classification	Internal data owners, engineers, or an implementation partner	One-time initial pass, then recurring as systems change	Number of systems and databases, volume of personal data, and how many copies exist outside production
Masking or synthetic data tooling	Engineering team for build and tuning; vendor or open-source maintainer for updates	Setup is one-time; tooling upkeep recurs	Number of environments, data complexity, and whether masking must preserve referential integrity across systems
Engineering time for enforcement	Platform and DevOps engineers, often through a partner-led build	One-time build, recurring maintenance	Number of environments and pipelines that promote data; access controls and deletion jobs needed per environment
Open-source license spend	Usually none for the software itself; support contracts are optional	Recurring only if paid support is bought	Choice of community or commercially supported releases; self-hosting removes per-seat license fees
Evidence upkeep	Internal control owner, with engineering support for logs and records	Recurring at each review cycle	Frequency of test refreshes, number of test environments, and how evidence is collected automatically
External review	Independent reviewer or partner, if commissioned	Optional, usually recurring if done each cycle	Scope of review, number of environments sampled, and whether the reviewer is independent of the implementer
Auditor sampling time	Certification body or auditor, billed under its own agreement	Recurring at each audit	Number of test environments and data copies the auditor samples, and how quickly records can be produced

How GitLab and Semgrep support A.8.33 evidence

A.8.33 is largely about whether test information is chosen, protected and removed on purpose, and that needs records as well as rules. The two open-source tools below can generate change history and scanning output for test code and fixtures, which an assessor can sample. They do not decide what test data is allowed or who approved it, so the policy and approval steps still have to be defined and kept by the organization.

Protected branches on test fixtures

Protected branches in GitLab Community Edition (MIT) let maintainers restrict which roles can push or merge to a branch. Apply them to branches that hold test fixtures, seed scripts and test environment configuration, so that changes to test information reach the branch only through a reviewed merge request. Ask which roles should hold merge rights on each protected branch and who owns that list.

Blocking direct pushes

Setting push access to no one on a protected branch blocks direct pushes, so every change to test information must come through a merge request. This gives a single path where a reviewer and an approval record can be shown for each change. Confirm that the merge request approval rules in your own GitLab configuration match the approvers named in your test data procedure.

Force pushes kept disabled

Force pushes rewrite history, which can remove the record of who changed a fixture and when. Keeping force pushes disabled on protected branches, unless an exception is explicitly allowed, protects that history. Check whether any exceptions exist, who approved them and whether they are recorded in the change log.

Change evidence from repository history

The protected branch settings, merge request approvals and commit history together show who changed test information, who approved the change and when it was merged. Export or retain these records as evidence for an assessor sampling A.8.33. Ask your auditor which periods and branches they will sample, so the retained history covers them.

Scanning test code for production data

Semgrep Community Edition (LGPL-2.1-only) scans code in supported languages, including Python, Java, JavaScript, TypeScript and Terraform, using community or custom rules. Custom rules can flag references to production hostnames, production database connection strings or real-looking identifiers in test code. Write and tune these rules for your own stack, and confirm which patterns indicate production data in your environment.

Running scans in CI/CD

Semgrep can run inside CI/CD pipelines to scan repositories on each change, so a test file that references production data is flagged before it merges. Pair this with the protected branch rules so that the scan result is a required check for merge. Decide whether a failed scan blocks the merge or only raises a finding, and record that decision in your procedure.

Who owns A.8.33 and what an implementation partner handles

Your organization owns A.8.33. Ownership means the test information policy exists, someone with authority approves what data may enter test environments, and named data owners answer for each dataset that is copied or generated. Your team also decides when test data is deleted and who confirms that deletion happened. These are management decisions tied to your risk appetite and legal obligations, so they cannot be delegated to a consultant or a tool.

Test data policy: Written rules on which data types may be used for testing, which must never be used, and who may approve exceptions.
Approval decisions: A named approver who signs off each request to copy production or personal data into a test environment, with the reason and duration recorded.
Data owners: Accountable individuals for each source dataset, who confirm classification and whether masking or synthetic data is required.
Deletion accountability: A named role that owns the deletion deadline for test copies and receives proof that deletion occurred.
Risk acceptance: Documented decisions when a business need forces use of sensitive data in testing, with compensating controls.

Before relying on any policy, check that it names owners by role, sets a review date and matches your Statement of Applicability entry for A.8.33.

Where organizations fall short on test data and how to close it

Test environments are where production data most often escapes its controls, usually by convenience rather than intent. The gaps below recur across organizations preparing for A.8.33 Test information, and each one comes down to a decision that was never written down, an owner who was never named or a deletion step that was never recorded. Each card names a closure step and the evidence an assessor would expect to see once it is in place.

Production dumps restored without approval

Engineers often copy a production database into staging to reproduce a bug or load test, and nobody records who approved it or what personal data it contained. Require a written request for every production-derived dataset, naming the purpose, the data fields, the approver and an expiry date. Evidence: approved request tickets matched against restore logs from the staging database platform, with any unmatched restore treated as an exception.

Test environments missing from inventory

Short-lived test clusters, preview deployments and vendor sandboxes frequently never reach the asset register, so no one can say what data they hold. Discover them from cloud accounts and the deployment pipeline rather than relying on teams to self-report, and tag each one with an owner and data classification. Evidence: a reconciled inventory export showing every non-production environment with an owner, a classification and a date of last review.

Personal data leaking into test logs

Test runs write request bodies, customer identifiers and error payloads into logs and CI artifacts, where access is far wider than in the source system. Set log redaction rules for known personal data fields, restrict artifact retention, and scan pipeline output for patterns such as email addresses or national identifiers. Evidence: redaction configuration under version control and scan reports from recent pipeline runs showing findings were fixed or accepted.

Undocumented deletion after test cycles

Test datasets are often left in place after a release cycle ends, so copies of production data outlive the reason they were created. Set a deletion deadline when the dataset is approved, delete it through a scripted or ticketed step, and keep the record. Evidence: deletion records or tickets for each approved dataset, plus storage snapshots confirming the data is gone. Ask your team how deletion is verified, not only requested.

Vendor test tenants outside policy

SaaS vendors, integration partners and consultants often receive copies of data for testing in tenants that the organization does not control or review. Check contracts and onboarding forms for any test tenant that receives real data, and confirm the vendor's deletion terms apply to it. Evidence: the supplier list annotated with test tenant use, contract clauses covering test data and written confirmation of deletion at the end of each engagement.

Test data without a named owner

When no one is accountable for a test dataset, nobody reviews whether it is still needed or still appropriate. Assign an owner for each dataset who approves access, reviews it at a set interval and signs off its deletion. Evidence: a dataset register listing owner, purpose, source system, access group and review date, with review sign-offs on file.

Questions buyers ask about A.8.33 test information

How much effort does A.8.33 test information take to meet?

A.8.33 is usually a narrow control in effort terms, but the work spreads across several teams. The effort depends on how many test environments exist, how many of them hold copies of operational data, and how well test data is already documented. Most of the work is one-time: inventorying test environments, setting rules for what may enter them, and cleaning up existing copies. What recurs is the discipline of selecting test data under those rules, reviewing exceptions and confirming deletion after each test cycle. Ask any partner to size the work from a written list of your environments, data sources and test pipelines, and to state which items are one-time and which recur.

Can our team satisfy A.8.33 without outside help?

Yes, a capable internal team can meet A.8.33 without an implementation partner, provided it has clear ownership and access to the people who control production data. The organization owns its controls, so policy, approval rules and deletion evidence must come from inside. Outside help is most useful when environments are complex, when test data flows through many pipelines, or when the team lacks time to build and document the controls. A partner can prepare systems and evidence, but it does not decide whether the control is effective. An independent certification body makes that decision if you pursue certification. Ask any firm to separate its deliverables from the decisions that remain yours.

What does A.8.33 need from engineering and data owners?

Engineering supplies the technical controls, and data owners decide what may be used for testing. Engineers must describe how test environments are provisioned, how data is copied or generated, and where the copies live. Data owners must approve which datasets can be used, under what conditions, and for how long. Together they should agree on the approval path for any request to copy production data, the masking or reduction steps required before use, and the owner of deletion after testing. Without named owners on both sides, exceptions pile up and the evidence becomes hard to reconstruct. Confirm these roles in writing before work starts.

How long does it take to get A.8.33 evidence ready?

The timeline depends on the state of your test environments and on how quickly owners can agree rules. Evidence grows from a few concrete artifacts: a written test data policy, an inventory of test environments and data sources, approval records for any production-derived data, masking or generation procedures, and deletion records. Teams with well-documented pipelines can assemble these faster than teams that must first discover where copies exist. Ask a partner for a fixed-scope timeline built from a written inventory, and confirm which items depend on decisions by your data owners, since those are often the slowest. Certification timing is set by the certification body, not by the implementation work.

Does synthetic data satisfy A.8.33 test information?

Synthetic data can meet the intent of A.8.33 when it is generated for testing and does not carry operational information, but it is not automatically compliant. The control asks that test information is appropriately selected, protected and managed, so the question is whether the generated data is fit for the test and whether its generation process is controlled. Synthetic data that is derived from production records can still leak sensitive patterns, so its origin and generation method must be documented. Some teams combine synthetic data with masked subsets for complex scenarios. Confirm with your assessor how they will judge derived or statistically similar data before you rely on it as your sole approach.

What will an auditor sample when testing A.8.33?

An auditor typically samples recent test environments, test data sets and the approvals behind them, then checks whether the stated rules were followed. Expect requests for the test data policy, the list of environments that hold data, examples of approvals for production-derived data, evidence of masking or generation, and records showing deletion after testing. The auditor will also look for consistency between documents and what systems actually contain, so an environment missing from the inventory is a common finding. Prepare by running a sampling exercise yourself, choosing recent test cycles and tracing each one from request to deletion. Certification decisions rest with an independent certification body, and the auditor's sample is its own choice.

What should we ask a partner about A.8.33 before hiring?

Ask for a written scope that lists the environments, data sources and pipelines covered, along with the deliverables and the dates agreed before work begins. Ask which outputs are policy documents, technical configurations, inventories and evidence templates, and which decisions stay with your owners. Ask how the partner will handle copies of production data found during discovery, and how those copies will be removed and recorded. Ask whether the partner will test the controls it builds, and how it separates that work from any certification decision. Finally, ask for a quote that follows from the written scope, with one-time and recurring items shown separately. DeployOpen works from a fixed written scope and does not publish a price list.

How DeployOpen prepares test data controls for an audit

DeployOpen works on A.8.33 Test information as part of a fixed-scope engagement inside the client's own infrastructure. We help define which test data sources are allowed, how they are protected and how test data is removed after use, and we prepare the records an auditor will ask to see. The organization keeps ownership of its controls, and independent auditors and certification bodies issue any reports or certificates.

How we scope

Agree in writing which test environments, datasets and tools fall under A.8.33 Test information
Record which production or personal data sources are prohibited from copying into testing
Define named owners for approving test data requests and for signing off deletion

How we build

Configure self-hosted test environments that stay separate from production networks and accounts
Set up data masking or synthetic data generation pipelines where the agreed scope requires them
Add repository checks, for example Semgrep in CI/CD, that flag production data or secrets in test code

How we hand over

Deliver a written test data procedure covering selection, protection, approval and deletion steps
Provide an evidence register listing data requests, approvals, masking records and deletion logs
Document the configuration and walk the client team through how to maintain the controls

How we support

Offer ongoing support and upgrades as a retainer after handover, if the client wants it
Re-check test environments and data flows when systems change or new test tools are added
Confirm with your auditor which evidence formats they accept before the assessment begins