Security in TP Software: Data Residency, Encryption and AI Policy

Transfer pricing data is among the most sensitive a firm holds — and among the least protected by the firm’s usual security thinking, because it is not the firm’s own confidential data in the way the client list or the fee data is: it is the client’s pricing positions, the client’s related party structure, and the comparables analysis that shows how the client prices against the market. A leak of a TP file is a leak of the client’s audit position before the audit happens. This guide is the security review for TP software: what the data actually is and why it is sensitive, the residency and encryption questions, the access-control model, the AI data policy — the clause most contracts get wrong — and the due-diligence checklist to run before signature.

Why TP data is a special category

Property	Consequence
It is the client’s position, not the client’s records. The file contains the firm’s analysis of the client’s pricing — the tested party, the range, the conclusion, the adjustments	A disclosure gives a counterparty (the authority, a litigant, a competitor with the client’s data) the firm’s defence in advance
It is predictive of the dispute. The benchmarking annex, the override record and the risk views show where the position is strong and where it is thin	In a TPO proceeding or litigation, the filed position and the working analysis are both discoverable-adjacent; the working file’s existence and content matter
It is cross-entity. One file references the related party group — the structure, the margins, the jurisdictions	A single file disclosure exposes more of the group’s position than the one transaction it documents
It outlives the engagement. Prior-year files, the archives, the superseded versions	The data-retention question is a security question: what is kept, where, and who can reach it after the engagement closes

The practical upshot: the TP software is a processor of client confidential data in every jurisdiction’s data-protection vocabulary, even where the firm is the data controller — and the security review should be run on that footing, not on the “it’s just a database tool” footing.

Data residency: the questions

The residency question in an Indian practice has two layers — the legal layer and the practical one:

The legal layer (ask, in this order)

1. Where is the data at rest? The production storage location, named — not “in the cloud.” For an Indian firm’s client data, the working requirement is India data residency: the client’s TP data stored in India, so that the data sits under the Indian legal perimeter the firm’s own obligations assume.
2. Where is the data in transit to the processing? The compute location for the pipelines (the screening, the enrichment, the AI calls). Residency of the storage and residency of the processing are different questions; the answer must cover both, or the data leaves the perimeter at the processing step even where the storage is in-residency.
3. Where does the AI layer’s processing happen? This is the question the older contracts do not ask, because they were written before the AI layer. The screening model, the drafting model — where do the inference calls run, and does the client data cross a border to get the inference? A vendor that hosts the storage in India but runs the model inference elsewhere has answered question 1 and failed question 3.
4. The subprocessors. The storage provider, the model provider, the search provider — the list, the locations, and the change process (who is notified, on what timescale, before a new subprocessor touches the data).
5. The cross-border transfer mechanics, where any processing is outside-residency: the legal basis (the transfer mechanism in place), stated in the contract, not in a slide.

The practical layer

• The backup and the disaster-recovery copies — same perimeter as the primary, or the residency answer is the primary’s answer.
• The support access — the vendor’s own support engineers: do they see client data to serve a ticket, from where, under what logging?
• The exit — on termination, the data returns or is destroyed, with the certificate; the exit clause is where the residency story either holds or doesn’t, because it is the only point the firm can verify.

Encryption and the data lifecycle

The encryption questions, per lifecycle stage:

Stage	The question	The answer to require
In transit	How is the data moved (upload, API calls, the AI inference calls)?	TLS in transit, everywhere, including to the model provider — the inference call carrying the company text is a data transfer and gets the same treatment as the upload
At rest	How is the stored data encrypted, and who holds the keys?	Encryption at rest, with the key management stated — the key tenancy (who can decrypt, under what control) is the substance; “encrypted” without the key story is a label
In the working set	What does the analyst see, what does the reviewer see, what is logged?	The access model below — and the logging that shows who saw what
In the outputs	The reports, the exports, the audit packets — where do they go?	The same controls: the exported file is the client’s data in a new form; the download and the storage of the export follow the same rules as the source
In retention	The prior-year archives, the superseded versions	Retention on the same perimeter, with the access controls intact — the archive is not the escape hatch where the controls stop

The specific check that separates a real answer from a brochure answer: ask for the key tenancy (who holds the decryption keys and under whose control) and the support-access logging (the record of a support engineer’s session against client data). Both are answerable by a vendor that has actually built the control; both are evaded by one that has not.

Access control: the model the data needs

The TP practice has a role structure the software must mirror — the analyst who builds the study, the manager who reviews it, the partner who signs it off, the admin who manages the firm’s configuration — and the data isolation that multi-tenancy requires (the firm’s clients’ data isolated from other firms on the same platform). The review checks:

• Identity. SSO where the firm has it; otherwise the credential policy (the password standard, the lockout). MFA — the TOTP enrollment for the users, and the mandate policy (who must have it: at minimum the reviewer and the admin roles).
• The role model. The permissions per role, mapped to the practice’s roles: who can create, who can review, who can sign off, who can export, who can manage the firm settings. The sign-off is a recorded act by a named role — the workflow’s state machine (draft → review → sign-off → archive) is the access-control story for the study lifecycle.
• The tenant boundary. The firm’s data — every client, every study, every export — isolated from other tenants on the platform, enforced at the data layer, not the UI layer. The question to ask: “show me the isolation at the query level” (the tenant scope on the data access), because the UI isolation is the part a bug can remove.
• The audit log. Every access to client data — the reads, the exports, the sign-offs — logged with the identity, the time, and the object. The log is both the security artefact and the practice artefact (the audit trail the firm shows when asked who touched the file); a platform whose access log is not complete and exportable has failed both purposes.
• The session and the device basics. The session timeout, the concurrent-session policy, the support for the firm’s device management (where the firm runs one) — the unglamorous controls that the breach post-mortems actually implicate.

The AI data policy: the clause that must be in writing

The AI layer (the screening model, the drafting model) raises the data questions the base platform does not, and the answers must be contract clauses, not support answers:

Clause	The requirement
No training on firm data	The firm’s data — the client TP data, the tested party files, the study content, the overrides — is not used to train foundation models or any shared model, for the vendor or its model providers. Stated, scoped to all firm data, and surviving the contract’s general data-use terms
No cross-tenant inference	The inference for the firm’s study runs on the firm’s data only; the model does not see other tenants’ data in the same call, and the prompts/outputs are not pooled for improvement without the firm’s consent
Residency of the inference	Where the inference runs, per the residency questions above — the model provider’s location named in the subprocessor list
Retention of the AI artifacts	The prompts, the outputs, the screening runs: how long kept, where, and the deletion on the firm’s request (the evidence retention is the firm’s decision — the audit-packet retention policy — not the vendor’s default)
The model-change notice	Where the vendor changes the model (a new version changes the screening behaviour), the notice and the firm’s option to pin or re-validate — the model is part of the methodology’s environment, and a silent model change is a silent methodology change

The drafting note: the “no training” clause is commonly present in the vendor’s public AI policy and absent from the contract — or present in a form scoped to “personal data” (which the client’s corporate TP data is not). The clause must be scoped to the firm’s data, all of it, and the review should read the contract’s data-use section against the vendor’s AI policy page, because the two documents routinely disagree.

The vendor due-diligence checklist

Run before signature; re-run at renewal and at any material change (new model provider, new region, new feature with new data access):

1. The data map. A diagram of the client data’s path: upload → storage (location) → processing (location) → AI inference (provider, location) → outputs (where they land) → retention (where, how long) → exit (return/destruction). Every arrow a named system and a named location.
2. The residency answer. Per the five questions above — storage, transit, inference, subprocessors, the transfer mechanics — in writing.
3. The encryption answer. In transit, at rest, the key tenancy, the support-access logging — per the lifecycle table.
4. The access model. The roles mapped, the MFA mandate, the tenant isolation at the data layer, the access log (complete, exportable).
5. The AI policy, as contract clauses. Per the five clauses above — no training, no cross-tenant inference, the inference residency, the artifact retention, the model-change notice.
6. The certifications, read carefully. Where the vendor holds an independent attestation (the SOC 2 report, an ISO 27001 certificate): the scope (what the report covers — the platform, and whether the AI layer is in scope), the period, and the exceptions list. The certificate is the floor, not the answer; the questions above are still asked against it.
7. The incident path. The breach-notification obligation (the timescale, the content), the firm’s rights on notice, and the vendor’s own incident history in the last two years, asked about directly.
8. The exit. The termination data return/destruction, the certificate, the timescale — and the survival of the confidentiality and the data-use terms after exit.
9. The audit right. The firm’s right to audit (directly or by representative, on reasonable notice, with the report) — or, where the vendor refuses the direct audit, the attestation plus the questionnaire as the substitute, stated in the contract.

The order is deliberate: the data map first, because every later question is a question about the map. A vendor that cannot produce the map is answering from the brochure, and the brochure’s answers do not survive the first incident.

FAQ

What is the minimum security package an Indian firm should require? India residency for the client data (storage and processing), TLS in transit and encryption at rest with the key tenancy stated, the role model with MFA for the reviewer and admin roles, the tenant isolation at the data layer, the complete exportable access log, and the five AI clauses in writing. Everything else (the certifications, the audit right, the device management) is the reinforcement on top of that minimum.

Does the AI screening layer change the firm’s own data-protection obligations? The layer changes the vendor’s obligations (the no-training and the inference residency are the vendor’s duties, contracted), and it changes the firm’s review duties (the due-diligence scope grows by the AI questions). The firm’s own obligations to the client are unchanged in kind — protect the confidential data, control its access, limit its retention — and the AI layer is where those obligations are most easily breached unawares, which is why the clauses are contract terms rather than support answers.

How often should the due-diligence be re-run? At renewal, at any material change (new model provider, new processing region, a new feature that reads new data), and on any industry incident involving the vendor’s stack. The model-change notice clause exists precisely to make the “material change” event an event the firm hears about rather than discovers.

Where does the security review sit relative to the functional evaluation? In parallel, and the security failure is a veto that the functional strength does not override: the capability matrix can score a platform highly on the workflow and the data, and the residency or the AI clauses can still fail the review — because the sensitivity of TP data makes the security terms non-negotiable in a way the feature list never makes the features non-negotiable.