UK Data Processing Agreement for Web Development: What NHS Buyers Need to Check

Yes, where the agency acts as a processor and processes personal data on behalf of your organisation, an Article 28 contract is required. The contractual requirement exists because the controller remains responsible for determining why and how the personal data is processed, while the processor acts on the controller's documented instructions.

The important point is that calling a document a "DPA" does not establish the relationship. You need to understand what the agency actually does with personal data.

A web agency is commonly a processor when it handles personal data for your organisation while following your instructions.

For example, an agency may:

The precise role depends on the actual processing arrangement. Contract wording should reflect the real data flow rather than simply applying a standard supplier template.

A contractual label does not determine whether an organisation is a controller or processor. The practical question is who determines the purposes and means of processing for the relevant activity.

An agency may have its own controller responsibilities for certain processing it performs independently. Those activities should therefore be assessed separately rather than automatically placing every activity under the DPA.

Getting the roles right at procurement stage helps establish:

During healthcare implementations, we find that role clarity becomes much easier when the procurement team maps the actual website data flow before reviewing contract language.

A practical procurement record can show the website, CMS, database, hosting provider, agency, integrations, support tools, and any other organisation that may receive or access personal data.

The safest operational approach is to have the relevant contractual controls in place before the agency begins processing personal data on your behalf.

That timing matters because website development often involves personal data before launch. Waiting until the production website is ready can leave migration, testing, debugging, or support activity outside the intended contractual framework.

Before personal data enters the agency's environment

Consider every environment where the agency might handle personal data:

A project can therefore involve processor activity even when the public website is still unavailable to patients.

Before granting access to existing systems

Review access before providing agency credentials for:

The access decision should follow the contractual and security assessment, not precede it.

Why "we will sign it before launch" can be too late

Personal data may already have been accessed during migration, troubleshooting, testing, or support. A website development contract that only considers production processing can therefore miss important processing activity earlier in the project.

The better approach is to identify when processing actually starts and ensure the contractual framework is ready before that point.

The practical procurement sequence

This sequence also creates a clearer audit trail for procurement, information governance, and technical teams.

Article 28 requires specific contractual terms between controllers and processors. ICO guidance identifies requirements covering processing details, documented instructions, confidentiality, security, subprocessors, data subject rights, assistance, end-of-contract arrangements, and audits.

The DPA should be specific enough to describe your actual website project rather than simply reproducing generic GDPR wording.

The agreement should identify what processing is taking place and how long it will continue.

For a website project, consider whether the relationship covers only development or also includes hosting, maintenance, technical support, migrations, backups, and ongoing administration.

Describe the activities the agency will perform.

Examples include:

Clear descriptions reduce ambiguity when responsibilities change during delivery.

Identify the categories relevant to the project.

Depending on the website, this may include:

The DPA should reflect the data the agency can actually access, rather than only the data expected on the public-facing website.

Specify who the information relates to.

For healthcare projects, categories may include:

The DPA should make the controller's role clear, including documented instructions and relevant governance responsibilities.

The controller should also understand what information it can request from the processor to demonstrate that contractual obligations are being met.

A web agency rarely operates every technical service itself. Your DPA therefore needs to address organisations that the agency uses to process personal data on your behalf.

What counts as a subprocessor in website development?

Potential subprocessors can include:

The important question is not whether the supplier calls another organisation a "vendor". Ask whether that organisation processes personal data for the agency's service to you.

Prior authorisation

Article 28 requires the processor to obtain the controller's prior authorisation before engaging a subprocessor. The arrangement may use specific or general written authorisation, with requirements around notification of intended changes where general authorisation is used.

Your procurement team should therefore understand how the agency proposes to introduce new subprocessors.

Flow-down contractual obligations

A processor using a subprocessor must put appropriate contractual data protection obligations in place with that subprocessor.

For an NHS buyer, the practical question is whether the agency can demonstrate that the same relevant protection continues through the supplier chain.

Agency accountability

The agency remains responsible to the controller for the subprocessor's compliance with the relevant Article 28 obligations.

That makes subprocessor visibility an important procurement issue rather than an administrative detail.

What an NHS buyer should request

Ask for:

An NHS buyer should test the contract against the actual operating model of the supplier. A DPA that looks complete on paper can still leave important technical questions unanswered.

Check whether the agreement restricts the agency to documented instructions.

Ask:

Article 28 requires processors to process personal data according to the controller's documented instructions, unless UK law requires otherwise.

Identify everyone who may have access to personal data.

The assessment should cover employees, contractors, developers, support personnel, and other individuals working on the account.

Confidentiality obligations should be supported by practical access controls. A contractual restriction has limited value if unnecessary users retain access to production information.

The DPA should connect contractual requirements with appropriate technical and organisational measures.

For a healthcare website, examine controls such as:

The agency should be able to explain how these measures operate in the environments used for your project.

Ask how the agency will notify your organisation if it discovers a personal data breach.

Clarify:

Article 28 requires processors to assist controllers with obligations relating to personal data breaches and other relevant compliance duties.

The agency may need to help locate, export, correct, restrict, or delete information.

Your contract should establish how such requests reach the technical team and what information the agency can provide to support your response.

Where a Data Protection Impact Assessment is required, the agency should be able to provide useful technical information.

That can include:

The agency does not replace your DPO or information governance function. Its role is to provide the technical information needed for the controller's assessment.

Ask what evidence the agency can provide about its Article 28 responsibilities.

ICO guidance states that processors must provide information needed to demonstrate compliance and allow for audits or inspections by the controller or its appointed auditor.

For procurement, this can translate into practical evidence such as security documentation, relevant assurance reports, subprocessor information, access procedures, and documented policies.

An overseas development team creates an additional question that procurement teams sometimes miss. The issue is not simply where your website database is hosted.

The relevant question is whether personal information is sent or made accessible to a separate organisation outside the UK.

Agency location is not the only question

Ask:

ICO guidance states that making UK-held personal information accessible to a separate organisation outside the UK can constitute a restricted transfer. Remote access can therefore be relevant even where the underlying data remains on UK servers.

India example

Suppose an NHS organisation uses a web agency based in India for development or technical support. If that separate organisation can access personal information held on UK systems, the arrangement may constitute a restricted transfer.

The fact that the database remains physically hosted in the UK does not by itself remove the transfer issue. ICO guidance specifically uses an Indian IT support company accessing UK-hosted information as an example of a restricted transfer.

What mechanisms may be relevant

Depending on the circumstances, the organisation may need to consider:

The appropriate mechanism depends on the actual transfer and recipient. ICO guidance states that restricted transfers must be covered by an applicable transfer mechanism or exception.

The three questions to ask

ICO's current guidance uses this three-step approach when assessing whether a restricted transfer exists.

Based on our healthcare IT experience, overseas access should be mapped during supplier assessment rather than discovered after development credentials have already been issued.

Healthcare websites can involve information that requires additional protection under UK GDPR. The DPA should identify these data flows accurately without attempting to replace the controller's wider legal assessment.

Identify special category data

Depending on the service, a website may process:

Whether particular information is special category data depends on the circumstances and what the information reveals.

Do not rely on the DPA as the lawful basis

A DPA controls the processor relationship. It does not create the controller's lawful basis for processing personal data.

The healthcare organisation remains responsible for determining the appropriate legal basis and, where relevant, the additional requirements for special category data.

For teams reviewing the relationship between Article 9 requirements and website architecture, the same principle applies: identify the data flow first, then assess the relevant legal requirements.

Define the data flow

A useful technical map can include:

Website → CMS → Database → API → CRM or patient system → Hosting → Support systems

The actual architecture will vary, but the exercise helps reveal where personal information can enter, move, be stored, or be accessed.

Prevent unnecessary data exposure

Production patient information should not automatically become development test data.

Where possible, use synthetic or appropriately de-identified information for development and testing. Restrict support access, apply least-privilege controls, and retain appropriate logs for privileged activity.

Project termination is part of the processor relationship, not an administrative task for the final week of delivery.

Article 28 requires the contract to address the controller's choice to have personal data deleted or returned at the end of processing, subject to applicable legal retention requirements. Existing copies must also be addressed.

Return or deletion

Define what happens to:

The agreement should establish who decides whether information is returned or deleted and how completion is evidenced.

Backups

Backups require specific attention because deletion may not occur instantly across every backup cycle.

ICO guidance recognises that immediate deletion from backups may not always be technically practical, provided appropriate safeguards apply and the data is subsequently deleted in accordance with an appropriate retention cycle.

Your DPA should therefore address backup retention rather than simply stating "data will be deleted".

Developer laptops and local environments

Offboarding should consider local databases, downloaded exports, screenshots, logs, temporary files, repository copies, and other project artefacts.

A technical handover should confirm that unnecessary copies are removed and that remaining access is justified.

Access removal

Project closure should include removal or review of:

While building patient-facing healthcare platforms, we treat access removal as part of the technical project lifecycle rather than a separate administrative exercise.

Use the following checklist during procurement or supplier review.

The checklist is most useful when procurement, information governance, and technical teams review it together. A contractual answer should be tested against the supplier's actual development and support model.

Use direct questions during supplier evaluation rather than relying solely on the agency's standard contract.

A strong supplier should be able to answer these questions in operational terms. Vague responses often indicate that the contractual documentation has not been connected to the actual delivery model.

Qrolic Health approaches DPA requirements from the technical implementation side, working alongside client legal, information governance, procurement, and DPO teams rather than presenting itself as a legal adviser.

Contract before processing

Processing boundaries should be established before access is granted to relevant systems or data.

Data-flow visibility

The website, hosting environment, APIs, databases, support tools, integrations, and third-party services should be mapped so the contractual scope reflects the technical architecture.

Healthcare-specific implementation

Healthcare workflows can involve patient accounts, forms, referrals, appointment information, clinical integrations, and other sensitive information. These flows require appropriate technical controls and clear responsibilities.

International access

Development, support, hosting, and subprocessor locations should be considered together. Overseas access can create transfer considerations even when information remains hosted in the UK.

Project exit

Data return, deletion, backup handling, credential removal, and technical handover should form part of the project plan.

Our healthcare platform work, including projects such as Herexa Health, IPPF, and RxHere, provides practical experience of systems involving patient-facing workflows, integrations, and controlled data flows. Those examples should not be treated as evidence of any specific client's contractual or legal compliance.

For NHS organisations evaluating NHS compliant website design and development, the DPA should be reviewed alongside the proposed technical architecture and delivery model.

A DPA should not be treated as a document that remains unchanged throughout a long supplier relationship.

Review the arrangement when:

A change in technical architecture can change the processing relationship even when the supplier itself remains the same.

Regular review also gives procurement and information governance teams an opportunity to confirm that the DPA still matches the actual service.

A UK data processing agreement for web development is not simply a document to sign before a website launches. It forms part of the contractual control framework governing how a web agency processes personal data on your behalf.

For NHS organisations, the practical assessment should extend beyond the wording of Article 28. You need visibility into development environments, production access, hosting, integrations, subprocessors, international access, security, data subject rights, backups, deletion, and project exit.

The strongest procurement process connects these contractual requirements with the technical architecture from the beginning. That approach helps your legal, information governance, procurement, and digital teams evaluate the supplier against the way the website will actually operate.

When the contract and technical implementation tell the same story, supplier governance becomes much easier to manage.