How to prepare a privacy evidence pack for a business customer

Imagine a prospective customer sending a long privacy questionnaire and asking for proof that your business is compliant. Sending every policy you have may create more work without answering the real concern: how will their information be handled in the service they intend to buy?

Prepare an evidence pack around that service and data flow. Make each assurance traceable to something current and relevant, and state the limits without hiding them in a footnote.

Establish the scope of the request

Ask which service, deployment, data categories and activities the customer is assessing. Identify whether you determine purposes for a particular activity or process information on their behalf. The answer may differ across the service.

As of 22 October 2026, the relevant substantive DPDP duties are scheduled for 13 May 2027 under the commencement notification. The future section 8(1), 8(2) and 8(5) framework will address accountability, specified processor engagements and safeguards. Describe current controls and readiness work separately rather than claiming that a pack proves every future obligation is already met.

The customer’s procurement requirements may go beyond the statute. Distinguish an agreed contractual assurance from a universal legal requirement, and avoid giving an answer simply because a questionnaire expects a yes.

Build a short evidence index

For each important topic, list the document or record, the scope it covers, its date, the responsible owner and any relevant limitation. Useful categories may include the data-flow description, access process, incident escalation, retention approach, provider arrangements and results of relevant workflow checks.

Connect the evidence to the question. A general security policy can explain intent; a scoped access review can show that a particular control was checked. A contract can define responsibilities; it does not prove that every operational step has occurred. Explain those differences rather than treating all documents as interchangeable proof.

The future rule 6 identifies several safeguard categories. Use that structure where helpful, but do not imply that one certificate, test or vendor statement establishes the whole framework.

A hypothetical service-provider response

A small operations provider is asked how it limits access to a customer’s records. It supplies a short role description, the relevant contractual commitment and a sanitised sample showing how an account is approved, reviewed and removed. The sample uses a test identity and makes clear which service configuration it represents.

The provider also states a limitation: one legacy export route is being replaced, with an interim restriction and an accountable owner. The customer can now assess the actual arrangement and decide whether the remaining work is acceptable. A broad ‘fully compliant’ statement would have concealed that decision.

For a retention question, the provider explains which party determines the purpose and legal requirement, which actions the service can perform and what evidence it returns. It does not promise universal immediate deletion when restricted retention or other copies need separate treatment.

Share evidence without creating another disclosure

Review screenshots, logs and sample records before release. Remove unnecessary personal data, credentials and details unrelated to the customer’s question. Where a sensitive architecture document is genuinely needed, use an appropriate controlled sharing route and access agreement.

Do not send another customer’s incident record as proof of your response process. A synthetic exercise or a properly bounded, de-identified summary may demonstrate the method without exposing a third party. State what the evidence is and what it is not.

Check that the pack’s links work for the intended recipient and do not open a wider internal folder. A well-written assurance can be undermined by the way the supporting files are shared.

Keep claims current

Assign an owner to each reusable answer. Record when a control, provider or system change should trigger a revision. A questionnaire response copied from last year can become inaccurate even if the policy title remains unchanged.

If an assessment or certificate is included, state the assessed entity, scope, period and relevant exclusions. Do not present an expired or differently scoped artifact as proof of the current service. Where evidence is unavailable, explain the gap and the proposed next step.

Make the pack support a decision

End with the responsibilities the customer retains, dependencies in the proposed deployment and unresolved questions. A useful pack should help both parties decide what to configure, agree or test before real data enters the service.

Document volume alone gives the customer little assurance. A smaller pack with clear scope, current evidence and honest limitations gives the customer a stronger basis for trust than a collection of broad policies and unqualified claims.