Can real customer data be given to the development team during development and testing?

Conclusion: you can share it, but usually not the complete copy that directly identifies specific people.

For most custom software, mini-program and AI application projects, a three-tier arrangement is reasonable: daily development and integration use a dataset whose structure, volume and field relationships match production while identity information has been replaced; real data is used for reconciliation and acceptance only inside cloud accounts, networks and permissions you control, with limited fields, limited people and limited periods; and a full production database copy never enters the developer's local environment, personal computer or self-built test database.

This boundary is not a statement about trust. Under China's Personal Information Protection Law (PIPL) you are the personal information handler and the developer is the entrusted party; entrusted processing itself requires prior assessment, written agreement and ongoing supervision, and when an incident happens, liability does not shift automatically because "the vendor lost the data". Settling this before the project starts saves far more trouble than arguing about "can we export one database" at acceptance.

If the data involves sensitive personal information, or is itself a core business asset (customer lists, costs and quotations, supplier floor prices), the bar is one notch higher; the sections below address these separately.

First, separate three kinds of "giving data"

The same phrase points to three completely different things in a project.

Giving samples. Select a few dozen business records to confirm field meanings, status values and screen displays. The scope is small and can be checked by hand, so the risk is lowest, but it only solves "we don't understand the fields".

Giving an environment. Open a read-only account inside the client's cloud account or intranet, and let the developer connect remotely through a controlled channel, viewing queries live without keeping copies. This verifies query performance, encoding matches and reconciliation results against real data, but depends on the client's operations cooperation.

Giving a copy. Export the production database, clean it and import it into the developer's test environment, or simply hand over an Excel file. It is the least effort and the most dangerous: once it lands, the data exists simultaneously on developer laptops, test databases, backups, logs and chat histories, and afterwards it is hard to prove it was fully deleted.

The third is usually what actually needs negotiating. As long as permissions and time are controlled, most projects can accept the first two.

Fix the roles first, then the plan means something

Under PIPL, personal information means information related to an identified or identifiable natural person; anonymised information falls outside that scope (Article 4). The implication: as long as data can still be linked to a specific person through a combination of phone number, name, ID number, address, or order number plus time, it remains personal information, and "we masked it" is not the finish line.

Processing needs a legal basis (Article 13): consent, necessity for concluding or performing a contract, fulfilment of legal obligations, and so on. When customers order on your platform they consent to "processing their information to provide the service", not to "providing it to a third party for software development and testing". That is why handing production data to a developer usually lacks not a non-disclosure agreement but the legitimacy of the processing purpose itself.

Commissioned development is entrusted processing. The law requires you to agree with the entrusted party on purpose, duration, method, categories of information, protection measures and mutual rights and obligations, and to supervise their processing; the entrusted party may not process beyond the agreement, may not sub-entrust without consent, and must return or delete the data when the contract ends (Article 21). The entrusted party must also take necessary measures to keep the data secure and assist you in meeting your obligations (Article 59).

In addition, entrusted processing of personal information is one of the situations requiring a prior personal information protection impact assessment (Article 55, item 3). The assessment must cover whether processing is lawful, legitimate and necessary, the impact and risks to individuals' rights, and whether protection measures match the risk; reports and processing records must be kept for at least three years (Article 56).

Two further points are often overlooked: retention should be the shortest period necessary for the purpose (Article 19), and security measures include classified management, encryption and de-identification (Article 51). In other words, "we'll keep the test database in case we need it later" does not hold up legally.

It is also worth distinguishing: not all data is personal information. Internal org charts, inventory quantities, product costs and process parameters are trade secrets, not governed by PIPL, but they still should not flow out without boundaries — they are controlled through confidentiality clauses, access control and non-compete arrangements. List the two categories separately at project kickoff and later plans will not contradict each other.

An acceptable plan can produce six kinds of evidence

Whether a developer's data plan is mature is not judged by adjectives in a promise but by whether they can produce the following concrete materials.

1. A field-level data list with purposes. Which tables, which fields, for which development or testing activity, and whether each is necessary. If a field can be dropped, they should be able to explain why. The list is not "the whole database" but "what must be verified this time, therefore what is needed".

2. Who has access and how it is authorised. Down to individuals: who needs access, in what role, for how long, and how access is revoked when they leave. This matters especially for teams with high turnover — project staffing changes are normal, and the real question is whether permissions follow the person.

3. Environment and network boundary. Whose account holds the data, whether local downloads are allowed, whether screenshots or forwarding are permitted, and whether data can be re-imported into the developer's own analytics tools. Agreeing that "data never leaves the client's cloud account" is the most effective single rule, and also the one most often broken under schedule pressure, so specify who can approve exceptions.

4. Auditable records. Whether logins, queries, exports and batch operations are logged, whether the client can review the logs, and whether abnormal behaviour triggers alerts. Authorisation without logs is not authorisation.

5. Lifecycle. How long data is kept, how soon it is cleaned up after acceptance, how cleanup is demonstrated, and how it is returned or deleted at contract termination. The "may not retain" requirement in Article 21 needs a corresponding action in execution, not just a clause.

6. Subcontracting, sub-entrusting and incident notification. Whether the team outsources testing to external individuals or crowdsourcing, and whether sub-entrusting requires your consent; on a leak, tampering or loss, within how many hours the developer notifies you and what information they provide. The law requires the handler to remedy the situation immediately and notify regulators and individuals when a leak occurs or may occur (Article 57); you cannot learn about an incident earlier than the developer does, so the notification deadline must be shorter than the statutory one.

Teams that can answer all six usually also accept writing three or four of them into a contract annex; teams that can only say "trust us, we're professionals" have a risk that lies not in attitude but in mechanism.

The five places where de-identification most often fails

"We will de-identify the data" is the sentence heard most often and most in need of follow-up questions. These five failure modes recur in real projects.

One: treating pseudonymisation as anonymisation. The middle four digits of phone numbers are masked and names become "Zhang*", but order numbers, delivery addresses, order times, stores and amounts are all retained. Joining several tables on order number, or cross-checking address with time, easily re-identifies people. Anonymisation means irreversibility; if that cannot be achieved, treat the data as personal information.

Two: keeping join keys without consistent treatment. The same customer appears in three tables, the de-identification script generates three different fake names, data does not match during integration, and the developer comes back asking for "more realistic data". The correct approach is consistent mapping: the same entity gets the same fake value in every table, and relationships stay intact.

Three: de-identification breaks business constraints, so tests pass and production fails. Phone numbers changed to 11 digits with invalid check digits, ID numbers that break encoding rules, addresses replaced with "Some Road" that make shipping fees and regional rules compute incorrectly, bank account lengths changed so payment validation fails. De-identification rules must first pass business validation: uniqueness, length, format, check digits, amount totals, regional attribution. Otherwise the "safer" the test environment, the more dangerous the launch.

Four: free text and attachments are missed. Notes, ticket descriptions, customer service chats, scanned contracts, site photos, call transcripts — these fields often hold the most complete personal information and are the most easily skipped by scripts. They cannot be handled by bulk regular expressions; they need sampling review or whole-field replacement.

Five: derived data and logs are unmanaged. Exported spreadsheets, report caches, search indexes, backups, event logs, plus conversation records and vector stores in AI applications. If de-identification only covered the primary database and derived data is still in clear text, it effectively was not done.

The corresponding approach is not complicated: classify at field level first, then run a re-identification test on the de-identified result — ask someone unfamiliar with the business to try to identify specific individuals from the test data alone, and keep processing where they succeed; meanwhile set separate rules for free text and bring derived data under the same inventory.

Choosing between three data sources

Approach	Good for verifying	Cannot verify	Main risk	Cost
De-identified real data	Business processes, status transitions, screen display, most calculation rules	The few checks that depend on real distributions and real identifiers	Re-identification, broken rules	One-off de-identification and validation effort
Synthetic data	UI and interaction, exception branches, demos and training	Performance under real distributions, dirty data and edge cases	Too "clean", hides real problems	Generation and maintenance cost, easily drifts from the real business
Read-only, time-limited production access	Performance, encoding matches, reconciliation, real dirty data	Write flows and concurrency conflicts	Permission sprawl, screenshot exfiltration	Requires client operations cooperation and auditing

The usual order of choice: if de-identified data can do the job, do not request real access; if real data must be seen, use read-only plus time limits rather than a copy; only when something genuinely cannot be done in the client environment (for example, reproducing a specific write behaviour with dirty data) discuss a small, short-term, auditable copy, with cleanup agreed in advance.

Acceptance testing needs real data to be accurate — how to reconcile

This is the client's most practical concern: de-identified data working does not mean real data will work.

The workable approach is two-track acceptance, rather than choosing between "hand over everything" and "hand over nothing".

Verify rule correctness exhaustively with de-identified data. Business processes, status transitions, amount calculations and permission decisions do not depend on who placed the order, so de-identified data covers them. This track can be automated, repeated and regressed.

Verify real-world consistency with on-site read-only access and sampled reconciliation. Pick several real documents, query them live in the client environment and compare item by item with system output: amount totals, quantities, relationships, key statuses. The client chooses the sample and the developer does not know it in advance, avoiding cherry-picked cases.

Run a small real comparison before go-live. Run the old and new systems in parallel for a short period, compare results for the same batch of business, and explain each difference. This step is more convincing than any test report.

Acceptance criteria should state the discrepancy rate, coverage and exception handling, not "basically consistent". The reconciliation approach for historical data migration is similar and can be designed together with reconciling a legacy data migration.

Three extra questions for AI projects

With AI applications, the same boundary has three additional gaps that are easily missed.

Knowledge bases and vector stores. Once internal documents, contracts and support scripts enter a retrieval store, who can search, within what scope, and whether snippets contain personal information all need separate design. Originals staying inside the enterprise does not mean retrieved snippets stay inside — RAG keeps knowledge local, but matched content still leaves with the request; that flow is described in more detail in data flows when using an external LLM API.

Conversation logs and evaluation sets. Real conversations are the closest test material to the distribution, but using production conversations directly for evaluation or fine-tuning brings personal information into labelling, training and outsourcing. The reasonable practice is to de-identify before adding to the evaluation set, and manage the evaluation set itself under the data inventory with recorded versions.

The model provider side. Whether data is used for training, how long it is retained and in which region depends on the specific product, interface configuration and contract, and must be confirmed at selection time rather than asked after go-live.

Nine things to spell out in the contract and in execution

This does not need to be a long legal document; one annex covering the following nine points is enough.

1. Delivery method: which data is provided in what form (samples, read-only environment, de-identified dataset), explicitly excluding a complete production copy.
2. Fields and purposes: a field-level list and the development or testing activity each category supports.
3. People and authorisation: the list of people with access, approvers, validity period, and revocation when they leave.
4. Environment and account ownership: accounts are opened and owned by the client, the developer may not lend them or land data on personal devices.
5. Auditing: access and export logging, client review rights, alerting for abnormal behaviour.
6. Retention and deletion: retention period, cleanup after acceptance, return or deletion with evidence at contract termination.
7. Subcontracting and sub-entrusting: no sub-entrusting without written consent, and subcontractors are bound by the same terms.
8. Incident notification: the deadline for reporting an anomaly, what must be reported, and duties to remedy and cooperate with investigation.
9. Deliverable boundary: how source code, documents and test data are handled after handover, and that test data does not transfer with the deliverables.

How these nine sit alongside the rest of the contract can be reviewed together with the clauses that matter most in a custom development contract, so that price and schedule are not the only things negotiated.

After go-live, production access is the long-term risk

After acceptance, developers often still hold operations accounts, which is when the data boundary loosens most easily. Practical controls: route all production access through a controlled channel instead of direct database connections; require ticket-based requests with time-limited authorisation and automatic expiry; require two-person review for high-risk operations (bulk data changes, exports, deletions); default to read-only with separate approval for writes; disable accounts on the day a person leaves; review accounts and permissions quarterly and retest with privilege-escalation scenarios once a year.

This mechanism and job-level segregation of duties are two sides of the same thing. For how to divide business permissions and who may not hold which combination of roles, see separating request, approval, execution, review and export permissions; for whose account holds the data and whether switching teams gets blocked, see where custom project data is stored and handover.

In Rolling Water Technology's project process this starts from pre-sales: an interactive demo is used to align on requirements and flows first, without requiring real data; at kickoff the environment, accounts and data delivery method are confirmed and written into the project agreement; during deployment we help establish basic runtime monitoring and alerting so that abnormal access and system failures are visible. The point of these arrangements is not extra process but turning "data stays within its boundary" into an executable, checkable daily practice.

Five steps you can follow

Step one: classify first. Sort the data you plan to provide into three categories: personal information, sensitive personal information (biometrics, financial accounts, medical health, whereabouts, information on minors under 14, and so on), and trade secrets. Sensitive personal information may only be processed with a specific purpose, sufficient necessity and strict protection measures (Article 28); avoid it where possible.

Step two: ask about necessity item by item. What happens if this development task does not see this field? If there is no answer, drop the field. This is the most direct way to apply the "minimum scope" principle in Article 6.

Step three: ask the developer for a plan, not a promise. Require the six kinds of evidence above, especially environment ownership and cleanup. The level of detail in the plan generally reflects how many similar projects the team has done.

Step four: design two-track acceptance. Decide now which metrics are verified with de-identified data, which must be checked on site, and who chooses the sample.

Step five: acceptance means cleanup. Put test data cleanup, account revocation and permission review on the acceptance checklist; delivery is not complete until they are done.

Additional questions

If we only provide de-identified data, will the developer fail to deliver?

Two kinds of work are affected: edge cases that depend on real data distributions, and checks that depend on real identifiers. The former is mostly solved by preserving field relationships, volumes and abnormal samples; the latter relies on on-site read-only verification, which is a one-off but manageable cost. What actually fails is usually a project where the business rules were never clarified — that has nothing to do with whether the data is real.

The vendor says they have done this for years and never had an incident — can we relax?

Past record is a reference, not a substitute for mechanism. The cost of an incident falls on the data subjects and on you, so the basis for judgement should be verifiable access control, logs and cleanup processes, not years of cooperation.

If the data stays on our own servers and the developer connects remotely, is that not enough?

The boundary improves markedly, but it is not zero risk: remote accounts may be shared, screenshots and downloads may be unrestricted, and accounts may be forgotten after someone leaves. Make account ownership, per-person authorisation, activity logging and expiry-based revocation real, and read-only remote access genuinely is safer.

Sources

• Full text of the Personal Information Protection Law of the People's Republic of China, adopted at the 30th session of the Standing Committee of the 13th National People's Congress on 20 August 2021, effective 1 November 2021 (accessed 9 November 2026). This article cites Articles 4, 6, 13, 19, 21, 28, 51, 55, 56, 57 and 59.
• Related articles on this site are Rolling Water Technology's own content, describing engineering practice and methods; they are company statements, not third-party evidence.

This article offers data-boundary advice at the project execution level. Specific data classification, notice and consent arrangements, impact assessments and contract terms should be confirmed by your legal, information security and business owners together with the regulations of your industry; sensitive personal information or cross-border transfer should be assessed separately.