Writing a customer success software disclosure policy without overpromising

What to take away

Start from the England scenario

Picture a Manchester software firm with 400 business customers. Its customer success team uses a platform that scores accounts, flags renewal risk and emails alerts to managers.

A customer asks what data feeds that score, and who sees it. If nobody can answer from a written policy, the fix is a disclosure policy that sits alongside your privacy notice.

Decide what the policy covers

A disclosure policy sets out four things: the data collected, what the platform does with it, who can see it, and what you tell customers.

Keep it separate from your privacy notice, which meets your legal duty to inform. This policy meets your commercial duty to be clear. The two should not contradict.

Map the data and the transfers

List every field the platform touches: contact details, usage logs, support tickets, renewal dates, sentiment notes. Mark which are personal data and which are commercial.

Then follow the data. If your platform stores or processes information outside the UK, you need a lawful transfer mechanism. The ICO's guidance on international transfers explains the safeguards, including adequacy regulations and the International Data Transfer Agreement.

Record the mechanism in the policy. A sentence such as "account data is processed in the EEA under the UK adequacy regulations" is enough for most readers.

Set the honesty rules

Disclosure policies fail when they promise more than the software can do. Write down what the platform measures and what it cannot.

If your health score is a statistical estimate, say so. If it cannot predict churn with certainty, say that too. The same discipline applies in procurement documents, where vendors such as Salesforce Service Cloud describe their capabilities. Describe yours as plainly.

For a wider view of where these obligations sit, see our guide to customer success software data protection, which covers retention periods and subject access requests.

Assign ownership and review

Name one person accountable for the policy. Give them a review date, at least annually, and a version number.

Changes to the platform, new subprocessors or a shift in hosting region should trigger an out-of-cycle review. Log each change in a short table.

If your organisation follows digital trust frameworks, map the policy to them. BSI's work on digital trust is a useful reference for structuring assurance around customer-facing services.

Worked example

A Leeds retention team runs a platform costing £1,200 a month, processing data on 8,000 customer contacts. The team drafts a two-page disclosure policy.

Before the policy, three account managers shared health scores with an external consultant in a spreadsheet. After it, scores stay in the platform and the consultant receives an aggregated report without personal data.

The legal review costs a one-off £900. The team estimates it saves around six hours a month in ad hoc customer queries, worth about £450 at an internal rate of £75 an hour. The figures are illustrative.

Common questions

Is a disclosure policy a legal requirement?

Not as a standalone document. UK GDPR requires you to inform people about processing through a privacy notice. The policy is one practical way to meet that duty consistently.

Does the policy need to cover data sent outside the UK?

Yes, if your platform transfers personal data abroad. Identify the transfer mechanism and state it in the policy.

How often should we review it?

At least once a year, and whenever the platform, subprocessors or hosting regions change. Record the review date and version.

Who should approve it?

The policy owner drafts it, a qualified adviser reviews it, and a senior manager signs it off. Individual cases still need a qualified adviser.

This is general guidance only, not advice on your circumstances. For the full picture, read our customer success software UK rules and compliance guide.