AI governance
Where your data goes is a scope clause, not a trust exercise
An integrator with engineers in five jurisdictions is, to a public-sector procurement reader, a cross-border data question before it is anything else. The answer belongs in the scope document, in three sentences, not in a reassurance on a call.
Executive summary
3
sentences a scope needs on data: where it is processed, where it is stored, and who can reach it
0
copies of client data that have to leave the premises for a remote engineer to do their job
Core conclusions
- A delivery team spread across jurisdictions is not itself a data-handling problem. An undocumented one is.
- The three facts a procurement reader needs — processing location, storage location, and who has access — are scope facts, and belong in the contract in plain words.
- Remote engineers work inside the client's environment, not on extracts of it. If a copy has to leave the premises, that is a decision to write down, not a convenience to assume.
Our own team is around fifteen people across Singapore, India, Indonesia, Hong Kong and Guangzhou. We put that on the website because it is true and because a buyer is entitled to know who will do the work. It also raises a question that a government or critical-infrastructure client will ask before any other: where, exactly, does our data go?
It is the right question, and the wrong way to answer it is on a call. The answer belongs in the scope document, where it can be read by the people who were not on the call, held against the delivery afterwards, and produced when an auditor asks.
What the question actually is
Under Singapore's Personal Data Protection Act, the Transfer Limitation Obligation requires an organisation moving personal data out of the country to make sure it receives a standard of protection comparable to the Act's. Public-sector bodies carry their own instruction sets on top of that, and a critical-infrastructure operator will usually have contractual obligations of its own that flow down to any vendor.
None of that is satisfied by an integrator being trustworthy. It is satisfied by three facts being stated and then being true: where the data is processed, where it is stored, and who can reach it. Everything else — the security controls, the access logs, the retention rules — hangs off those three.
The same question, answered two ways
| What a proposal usually says | What a scope clause says |
|---|---|
| We take data security very seriously | Client data is processed on the client's premises and stored by the client |
| Our offshore teams are fully vetted | Anything the integrator hosts is in Singapore-hosted environments only |
| Access is on a need-to-know basis | Named roles, the environment they reach it through, and the log that records it |
| We comply with the PDPA | No copy of client data leaves the premises unless this scope names the copy, the reason and the destination |
How it works without copying the data
The practical pattern is that the data does not move; the engineer's access does. A software engineer in India working on a warehouse integration reaches the system through the client's own environment, under the client's own access control, with the client's own logging recording what was touched. What they are working on is the system. What they are not holding is an extract of the client's records on a laptop in another country.
Development and testing run on synthetic data, or on a client-approved subset that the scope names. Where a genuine copy has to exist — a migration, a one-off analysis, an audit sample — it is written into the scope as a specific event with a destination and an end date, not left as a general permission.
That is how our own engagements are scoped, and it is why the team's geography and the data's location are two separate facts on our site rather than one worrying sentence.
What to write into the scope
- Processing location, as a place: on premises, or a named hosted environment in a named jurisdiction.
- Storage location and custodian: who holds the authoritative copy, and where.
- Access: which roles, through what environment, logged where — and whether that includes any engineer outside Singapore.
- Exceptions, individually: any copy that will leave the premises, why, to where, and when it is deleted.
- Retention and deletion at the end of the engagement, including the integrator's own working copies and backups.
An integrator who cannot write those five lines has not yet decided how the work will be done. That is worth knowing before the contract is signed rather than after.
