The ICO has approved a UK GDPR code of conduct for information sharing, and it gives suppliers a template to align to

The ICO has approved the Wales Accord on the Sharing of Personal Information (WASPI) UK GDPR Code of Conduct under Article 40 of the UK GDPR. The code is aimed at information sharing protocols across health, education, social care, safeguarding and public services.

Article 40 is the provision that allows sector codes of conduct to be approved as a way of showing how the UK GDPR applies in a particular context. The approval is a regulator-recognised standard for how sharing arrangements in these sectors should be structured and documented.

A code approved under Article 40 is useful to suppliers because it removes some of the guesswork about what a regulator-recognised approach looks like. Where a customer in one of these sectors asks for alignment to the code, a supplier can point to an approved document rather than negotiating a bespoke standard for each agreement.

The ICO has noted that more than 1,000 organisations are signed to the Accord. That matters commercially because a code with that level of take-up among public service bodies is likely to shape what those bodies expect from their suppliers and partners.

A supplier does not need to be in Wales to meet the effect. Where a public sector customer is signed to the Accord, its procurement and information governance teams may ask suppliers to work within the same templates and review practices, whatever the supplier’s own location.

Suppliers should check early whether each public sector customer is signed to the Accord, and whether it expects its data sharing agreements to follow the approved templates. That question is best asked at the start of a relationship, because retrofitting an existing agreement to a template is slower and more contentious than starting from one.

The code sets six requirements. Two are of particular contractual interest: the use of approved templates, and regular review of sharing arrangements. Approved templates standardise how data sharing agreements are written, which reduces drafting time and gives both sides a common starting point.

Regular review is the more demanding of the two. A sharing arrangement that is signed once and left alone will not meet a requirement for periodic review, so the contract needs to say who carries out the review, how often, and what happens to the arrangement if the review identifies a problem.

For suppliers, the practical step is to build review into the operating calendar: a named owner, a date and a record of what was considered. Without that record, a supplier that says it adheres to the code will struggle to evidence it, which is the very purpose for which adherence would be relied on.

The ICO has indicated that WASPI is expected to set up an independent monitoring body. It is not confirmed whether that body has been accredited, so suppliers should not assume the monitoring arrangements are in place.

Equally, the legal effect of adhering to the code has not been confirmed. It is not established what adherence means for regulatory penalties, or whether it can be relied on to give assurance about processor arrangements under Article 28. Adherence to an approved code is a way to evidence compliance, but a supplier should not present it as a defence or as a substitute for its own compliance work.

The sensible position is to treat adherence as helpful evidence and nothing more until the effect is clarified. A contract that quietly assumes adherence cures other obligations creates a gap that will only be discovered when something goes wrong, and by then the allocation of risk will already have been fixed.

Each of the three points affects risk allocation. Ownership of the review cycle determines who must act, and who is in breach if the review does not happen. Cost of change determines who pays if the code is revised and the sharing arrangement must be updated to match.

The third point, warranty or covenant, is the most important. A warranty is a statement of fact at a point in time, and a breach gives rise to a claim in damages. A covenant is a continuing promise, and it requires ongoing compliance for the life of the contract. A supplier that gives a covenant to adhere to a code that may change is taking on a moving obligation, and should price and limit it accordingly.

If the supplier takes on the covenant, it should seek a right to renegotiate or terminate where a change to the code makes continued adherence uneconomic. If the supplier gives a warranty, the contract should say the date at which it is given and whether it is repeated, so that the supplier is not exposed to later changes it cannot control.

The following is drafting advice, not a statement of any legal consequence of the code. It is intended to keep the supplier’s obligations clear while the position on adherence is still developing.

• Template alignment, use the code’s approved templates for the data sharing agreement where the customer is signed to the Accord, and record any agreed departures expressly.
• Review ownership, name the party responsible for each periodic review, set the frequency, and say what happens if a review is missed or finds a defect.
• Change cost, state who bears the cost if the code’s requirements change, and whether the supplier may recover it through a change control process.
• Warranty or covenant, choose deliberately between a warranty of adherence at signature and a continuing covenant, and cap the liability that attaches to either.
• No assumed effect, avoid wording that treats adherence as a defence or as satisfying separate obligations such as Article 28 processor terms, and keep those terms in the contract in their own right.