Use of Production Data in Non-Production and Testing Environments

The engineering and QA teams copy a full or partial snapshot of the production database — containing real customer names, contact details, and transaction history — into development, staging, and testing environments to validate new features and debug issues realistically.

1. Does the use of live personal data in non-production environments constitute a separate processing activity under DPDP?
2. What risks arise from personal data being present in environments with weaker access controls than production?
3. What is the compliant approach to enabling realistic testing without exposing live personal data?
    

Not permissible as a routine practice.

Production data was collected for the purpose of delivering the live service to customers. Copying it into test and development environments — which typically have broader engineer access, weaker monitoring, and are sometimes hosted on lower-security infrastructure — is a new processing activity with no lawful basis, regardless of the good-faith engineering purpose behind it.

• Weaker controls than production — Test and staging environments are frequently accessible to a wider set of engineers, contractors, and interns than the production system, and are less rigorously monitored, logged, and patched — making them a disproportionately attractive breach target relative to the value the organisation gets from using real data there.
• Persistence beyond the test cycle — Data copied for a single testing exercise routinely remains in lower environments indefinitely, refreshed periodically with new production snapshots, with no corresponding deletion of the customer records no longer relevant.
• Third-party and offshore access — Where development or QA is outsourced or performed by contractors, live customer data in a test environment may be processed by parties who have no direct relationship with, or obligation to, the organisation's customers.
• No purpose limitation applied — Customers whose data appears in a test environment have not consented to their information being used to validate unrelated features, debug defects, or train new engineers — a purpose entirely distinct from the service they signed up for.

1. Mandate data masking or synthetic data for all non-production environments. Implement a data masking pipeline that anonymises or pseudonymises production data before it reaches test or staging, or generate synthetic datasets that mirror production characteristics without containing real personal data.
2. Restrict any remaining real-data use to a narrow, approved exception process. Where masking genuinely cannot replicate a defect (e.g., encoding issues specific to certain names), require DPO sign-off, a defined and short retention window, and immediate deletion after the specific debugging exercise.
3. Apply production-equivalent access controls to any environment holding real data. Any environment retaining real personal data — even temporarily — must meet the same access control, logging, and monitoring standard as production, not a relaxed development standard.
4. Audit lower environments periodically. IT should run a periodic audit of all non-production environments to detect real personal data that has persisted beyond its intended testing window and purge it.

DPDP Risk Summary