The Annex Is Not the Strategy: Allocating Data Risk After the DUAA

Commercial contracts have a familiar habit. The data protection schedule sits at the back, cross-refers to a privacy policy, repeats statutory language and is signed off late. The privacy policy then becomes the place where data strategy is assumed to live. That assumption is increasingly unsafe. The Data (Use and Access) Act 2025 has altered several working assumptions in UK data law, and the contract is where those changes must be converted into operational terms.

A privacy policy is a transparency notice addressed to individuals. It explains processing in general terms and can be changed unilaterally. A commercial contract is a risk allocation between counterparties. It should state who may do what, with which data, for which purpose, on what evidence, at whose cost and with what consequence when things go wrong. Treating the first as a substitute for the second leaves the deal without a data strategy.

Notice is not allocation

The Act, which received Royal Assent in 2025, creates a more explicit recognised legitimate interests route, adjusts subject access and international transfer tests, and changes the governance of the Information Commissioner's Office. None of that removes the need for a lawful basis or for a contract that says which party is responsible for what. If anything, greater flexibility in the statutory framework makes contractual discipline more important, because flexibility without allocation becomes ambiguity.

A privacy policy will not tell a supplier whether it may use customer data to improve its own products. It will not tell a customer whether it must notify individuals before a change of purpose. It will not allocate the cost of a subject access request that spans two organisations. Those are contract questions. As drafting teams review templates in 2026, the data schedule should be read as part of the commercial bargain, not as an appendix to the policy.

Permitted purposes need operative language

Many data schedules define permitted purposes by reference to the services and then add broad phrases such as business improvement, analytics or compliance. Those phrases are where disputes begin. A better approach is to define permitted purposes by reference to specific processing activities, data categories and recipient groups. If analytics is permitted, say whether it may be used for supplier product development, whether outputs must be aggregated, and whether the supplier may retain derived data after termination.

The Act's emphasis on reasonable and proportionate processing does not replace purpose limitation. It gives context to it. A contract should still identify the boundary between the deal and the supplier's own ambitions. Where the boundary may move, use a change control mechanism with defined notice, assessment and approval. A general right to vary the privacy policy is not a substitute for a negotiated variation of the data terms.

Consent fallbacks and the problem of drift

Where consent is the chosen basis, the contract should say who obtains it, how it is evidenced, how often it is refreshed and what happens when it is withdrawn. A common weakness is a clause requiring the customer to obtain consent without saying what the supplier must do with the evidence or how processing will stop if consent falls away. Another is a fallback that allows the supplier to switch to legitimate interests unilaterally. That is not a fallback; it is a change of deal.

Consent withdrawal can also trigger operational consequences. The contract should address deletion, suppression, onward notification to sub-processors and the treatment of derived data. If the parties intend to rely on a statutory exception or recognised legitimate interest in some circumstances, the contract should identify the circumstances and the assessment responsibility. The privacy notice can explain the position to individuals; the contract must make it work between the parties.

Research and re-use are not a general licence

The Act supports research and re-use within conditions. That does not mean that any secondary use labelled research is permitted. Contracts should define what counts as research, who approves the scope, how data is minimised or pseudonymised, where outputs may be published and what happens to the underlying data at the end. Re-use often creates a tension between the supplier's desire for a broad licence and the customer's need to control regulatory and reputational risk.

A useful drafting technique is to separate the processing permission from the commercial licence. The data schedule can permit a defined research use while the IP clause governs ownership of outputs and the liability clause addresses misuse. If the parties cannot agree the research boundary, a pilot with a defined data set and a fixed review date is usually safer than a broad permission with an uncertain scope.

Security, audit and evidence

Security schedules often promise appropriate technical and organisational measures and then list controls that are difficult to test. The contract should connect the promise to evidence. That means naming the standards or certifications relied on, the frequency of independent testing, the incident notification timetable and the route for remediation. Audit rights should specify whether they are desk-based, remote or on-site, how much notice is required, who bears the cost and how confidentiality is protected.

The Act changes regulatory oversight, but it does not reduce the value of contractual assurance. A customer that cannot inspect or obtain evidence is relying on trust. A supplier that faces unlimited audit rights may accept them and then qualify them in practice. The balanced outcome is a proportionate audit regime with clear triggers, such as a material incident or a failed certification, and a lighter annual assurance process in ordinary circumstances.

Transfers, roles and the data protection test

International transfers remain a contract issue even where the statutory test changes. The contract should identify the transfer mechanism, the destination, the role of each party and the responsibility for onward transfers. It should also address what happens if the mechanism is invalidated or the regulatory position changes. A clause that simply asserts compliance with applicable law is not a transfer solution; it is an aspiration.

Role allocation deserves similar care. Controller, processor and joint controller labels should match the facts, not the template. Where roles are mixed, the contract should separate the processing activities rather than apply one label to the whole relationship. That separation matters for liability, subject access, breach notification and termination.

Exit, liability and the post-termination gap

Data clauses are often silent at the point of exit. The contract should say whether data is returned, deleted or retained, in what format, within what period and with what certification. It should address backups, legal holds and transition assistance. If the supplier needs to retain data for regulatory reasons, the contract should identify the retention basis and the protections that continue to apply.

Liability is the final test of whether the data schedule is real. A general cap or a broad consequential loss exclusion can swallow a data breach claim before the parties reach the specific obligations. Consider whether the data schedule needs its own liability regime, a specific indemnity for third-party claims or a higher cap for security failures. Regulatory fines are not always insurable or indemnifiable, but the contract can still allocate investigation costs, remediation costs and notification expenses.

A drafting discipline, not an annex

The Data (Use and Access) Act 2025 is not a reason to rewrite every data schedule from scratch. It is a reason to stop treating the privacy policy as the contract's data strategy. The policy tells individuals what the organisation says it does. The contract should tell the counterparties what they may do, what they must prove and what happens when they fail. In 2026, that distinction is not technical. It is the difference between a data clause that survives a dispute and one that merely accompanies the deal.