Should your developer copy real customer records into testing?

Approve a dataset for a named test

The default answer should be no to a wholesale copy. A test environment can expose records to different people, exports and logging tools, even when the application looks identical. Ask the developer to name the defect or change, describe the expected result and list the fields needed to reproduce it. Approval to modify the application does not settle which customer records may be used. Record that decision separately before extraction.

Consider an illustrative change to sibling discounts. Invented families, linked student records, enrolment dates and fee states can exercise the calculation without real parent telephone numbers or student notes. Include awkward cases such as a cancelled enrolment and siblings joining different classes. If the developer says only live records trigger the fault, ask what relationship or historical state the invented examples lack. Recreate that feature first; convenience alone is a weak reason to import a production database.

Use G3 as a named benchmark

Hong Kong Government IT Security Guidelines G3, version 10.1 (July 2024), section 16.3, printed page 104, prohibits production data for testing and says to avoid operational databases containing personal or classified information. Its unavoidable-use provisions require documented review and Information Owner approval, de-personalisation of personal data, removal or unrecognisable modification of classified information, and clearing the data immediately after testing. Protection must match classification.

This is a version-specific government control benchmark, not a claim about the latest G3 edition. The Digital Policy Office distinguishes government requirements from guidance available for industry reference. The request process below is our editorial recommendation for SMEs; adopting it is neither a statutory rule in itself nor certification of PDPO compliance. Have the person responsible for privacy assess any unresolved question about the proposed use before authorising a real-data extract.

Compare substitutes before approving an extract

Synthetic records take effort to design but let the team share repeatable examples without reproducing real families. A production-derived sample may preserve an obscure failure, yet brings access and deletion work with it. Replacing names is not proof of anonymity: a rare class, attendance pattern or free-text comment can still identify someone. Stable replacement identifiers can preserve family links, but retained lookup keys can reconnect the sample to people. Review the actual output, including attachments and hidden export columns, before it leaves the controlled preparation area.

• Use invented records when the test concerns layout, validation or known business rules.
• Use generated volume with stated limitations for load testing; do not copy every student just to obtain enough rows.
• Consider a reviewed, transformed minimum sample only when a documented test need remains unmet. Defer the affected test if safeguards cannot be demonstrated.

A test-data request the owner can decide on

Copy this form into the change request and complete it for one dataset and one purpose. The developer proposes the technical minimum; the centre names the accountable business approver. A response such as “all fields, all developers, until launch” needs revision. Identify the dataset version so approval cannot silently cover a later, larger export. Conditions should be checkable before transfer, not promises to tidy things up once testing ends.

Check the boundary and close the request

Before import, demonstrate that test emails and messages cannot reach families and that payment actions cannot charge real accounts. Restrict access to the named users and check what error logs capture. Keep screenshots and support tickets free of identifying records. A separate database with production integrations still connected does not provide the boundary the request assumes. If the developer cannot show these controls, keep the dataset out while the environment is corrected.

At completion, reconcile the approved copy list with deletion records for the database, exports, developer downloads, attachments and test backups. Ask for timestamps, the responsible person and a check that the copies are no longer accessible; preserve evidence of the action without preserving customer rows. If a backup cannot be cleared on the promised schedule, do not describe the request as fully closed. Resolve that retention constraint before approving the dataset, or choose synthetic data instead.

For the next application change, send the request form with the brief and ask for the proposed synthetic cases before agreeing to any export. Use the broader personal-data guide to connect this decision to existing access and retention requirements. If commissioning development support, include dataset preparation and cleanup evidence in the work scope so responsibility is agreed alongside the feature work.