# Data lifecycle and software-service responsibilities A software service must account for the full processing activity. Controllers retain responsibility when they use suppliers. Processors also have direct duties. Contract labels cannot replace the legal tests for each role. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) **Scope:** England, with UK-wide law. **Evidence checked:** 19 October 2026. **Status:** evidence-checked synthesis; independent legal review remains open. The controls below have not been tested against a specific service. ## Assign roles by purpose | Role | Test and responsibility | |---|---| | Controller | Determines the purposes and means of processing. Establish the lawful purpose and the duties that follow. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001) | | Processor | Processes personal data on a controller's behalf. Follow documented instructions and the applicable direct duties. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) | | Joint controllers | Jointly determine purposes and means. Agree a transparent allocation of duties and make its essence available to individuals. People can exercise rights against each controller. [SRC-015](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-015) | | Separate controllers | Each determines its own purposes and means. Assess each disclosure and subsequent use; a processor agreement cannot replace that assessment. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) | A supplier can hold different roles for different purposes. A processor that determines purposes and means beyond its instructions becomes a controller for that processing. For example, independent reuse for model training needs a separate role and lawfulness assessment. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) Receiving records from a GP does not, by itself, make the recipient the GP's processor. Assess who determines the purpose and means of the recipient's use. Likewise, a service contract does not automatically make the contractor a processor. A supplier that only stores records on a controller's instructions may have a different role from a provider that determines an assessment purpose. These are role tests, not assigned roles for a particular service. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) For disclosures between separate controllers, assess each party's lawful grounds, confidentiality authority and responsibilities. Do not use Article 28 terms as a substitute for that assessment. Where parties jointly determine purposes and means, apply Article 26's arrangement requirements to their joint processing. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014), [SRC-015](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-015) A continuing separate-controller flow should have a data-sharing agreement that records the parties' responsibilities. Such an agreement is good practice, not universally compulsory merely because records are shared. The requester should establish which arrangement applies to its relationship with the provider, commissioner and suppliers. [SRC-099](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-099), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014), [SRC-015](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-015) ## Establish the supplier chain NHS England's supplier guidance places the NHS purchaser's check of a candidate supplier's latest annual DSPT status **before contract award**. The purchaser checks the legal entity, assessment year and published status against the contracted service. The supplier provides supporting evidence of service coverage and any applicable audit. A group or prime contractor's published status does not establish coverage of every participating organisation. [SRC-107](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-107), [SRC-082](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-082), [SRC-094](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-094) For a recruitment contractor receiving identifiable NHS GP records, the [recommended contract condition](https://healthcare-data-management-wiki.pages.dev/dspt/index.md#recommended-contract-condition) requires acceptable published status before first receipt. The contractor must maintain annual assurance and meet any earlier contractual or system-access milestone. The purchaser records its acceptance of the evidence; the GP practice separately decides whether to disclose. This is the proposed condition, not a finding about an existing contract. Where a controller uses a processor, Article 28 requires a binding written contract or other qualifying legal act. The controller must use processors that provide sufficient guarantees. The terms must cover: - Processing scope, duration, purpose, data types and people affected. - Documented instructions, including international transfers. - Confidentiality and appropriate security. - Subprocessor authorisation and equivalent contractual obligations. - Assistance with individual rights, incidents, impact assessments and consultation. - Return or deletion at service end, including existing copies, unless law requires storage. - Compliance information, audits and inspections. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) A processor needs prior specific or general written authorisation before appointing a subprocessor. General authorisation requires notice of additions or replacements and an opportunity to object. The initial processor remains liable to the controller for the subprocessor's contractual data-protection obligations. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) ## Map data before setting controls The following inventory is a practical way to support accountability, processing records, security and supplier management. It is not a statutory form. [SRC-005](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-005), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014), [SRC-016](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-016), [SRC-019](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-019) | Record in the data map | Include | |---|---| | Collection and disclosure | Provider sending the information, requester receiving it, each party's role, disclosure authority, collection grounds, purpose and necessary data fields. | | Production processing | Storage, analysis, search indexes, integrations and exports. | | Supporting copies | Backups, logs, test data, support tickets and administrator access. | | Derived information | Scores, inferred conditions, linked records and individual profiles. | | Service metadata | User identifiers, IP addresses, event history and appointment or document metadata. | | Supply chain | Each legal entity, role, hosting location, remote access and onward transfer. | | Exit | Retention trigger, deletion method, backup treatment and return obligations. | Metadata and derived information require classification too. They can be personal data even when separated from the main record. Some metadata reveals health status; deliberately inferred health status can be special-category data. A generic appointment alone does not necessarily reveal health. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-024](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-024) ## Determine assessment and governance duties A **data protection impact assessment (DPIA)** is required before processing likely to cause high risk. Article 35 expressly includes large-scale special-category processing. Other high-risk processing can also require one. It is not automatically required merely because one health record exists. [SRC-018](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-018) The ICO list also covers opportunity decisions involving special-category data. The [recruitment requester analysis](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md#does-the-recruitment-requester-need-a-dpia) applies that trigger to require a DPIA, unless an applicable legal exception is established. Identify the responsible controller; a processor may prepare the assessment but does not take over that responsibility. [SRC-018](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-018), [SRC-100](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-100), [SRC-101](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-101) If high risk remains without sufficient mitigation, Article 36 requires prior consultation with the regulator. The assessment should address necessity, proportionality, risks and safeguards. Revisit it when the risk changes. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-018](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-018) A **data protection officer (DPO)** is required for public authorities, subject to the judicial exception. Other controllers and processors need one where core activities involve regular and systematic monitoring on a large scale, or large-scale processing of special-category or criminal-conviction/offence data. The factual scale and core activities remain to be assessed. [SRC-017](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-017) Keep Article 30 processing records. The exemption for organisations with fewer than 250 people does not excuse relevant special-category processing. Record purposes, categories, recipients, transfers and, where possible, retention and security information. [SRC-016](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-016) ## Build safeguards into design and operation Article 25 requires controllers to implement data protection by design and by default. Defaults must limit collection, use, storage and accessibility to what each purpose needs. Article 32 requires both controllers and processors to provide security appropriate to risk. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-019](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-019) Article 32 addresses confidentiality, integrity, availability, resilience, restoration and regular testing. Encryption and pseudonymisation are expressly identified measures where appropriate. [SRC-019](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-019) Practical measures can include role-based access, multifactor authentication, logging, secure development, patching, recovery tests and controlled support access. Select and justify them against the risk. This list is an implementation interpretation, not a universal statutory product specification. Certification does not establish compliance with every applicable duty. [SRC-019](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-019) The requester should provide relevant security evidence before the provider sends information. The provider should take reasonable steps to check recipient security and resolve material differences before sharing. These checks support the disclosure decision; they do not transfer the recipient's own security duties to the provider. See the [recommended evidence pack](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md#what-should-accompany-the-request). [SRC-098](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-098) For online services likely to be accessed by children, check the specific Article 25 higher-protection requirements and their scope. A service audience has not been established here. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001) ## Make rights and complaints operational Articles 13 and 14 require privacy information, subject to their exceptions. Explain the actual purposes, legal bases, recipients, retention and relevant rights. Indirect collection does not automatically remove transparency duties. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001) Where the requester receives information as a controller, its transparency assessment must cover that receipt and its intended use. It cannot assume that the provider's privacy notice supplies everything required for the recipient's processing. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001) Support access and rectification, and applicable erasure, restriction, portability and objection rights. These rights have different conditions and exceptions. Do not promise unconditional deletion or portability for every record. Processors must assist controllers as required by Article 28. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) DUAA amended subject-access handling, including reasonable and proportionate searches and justified clarification pauses. The complaints duty requires an accessible route, acknowledgement within 30 days, appropriate investigation and an outcome without undue delay. Do not confuse a complaint acknowledgement with the deadline for a rights request. [SRC-006](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-006) For significant solely automated decisions, apply the additional restrictions and safeguards in the [legal framework](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md#automated-decisions-retain-strict-health-data-rules). ## Set retention and deletion rules by purpose Article 5 requires identifiable personal data to be kept no longer than necessary, subject to its safeguarded research and archiving provisions. It does not set one universal health-data retention period. Other applicable legal or sector duties can affect the period. [SRC-005](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-005) As a practical implementation, assign a retention reason, period or review trigger to each data class. Include exports, support copies, indexes and backups. Define how deletion becomes effective across the service and suppliers. Use the [NHS standards assessment](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md) where sector record rules may apply. [SRC-005](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-005), [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) At the end of processing services, Article 28 requires the processor to return or delete data at the controller's choice. Existing copies must be deleted unless domestic law requires storage. A contractual exit plan should make this verifiable. [SRC-014](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-014) ## Prepare for incidents A personal data breach includes loss, destruction, alteration, unauthorised disclosure or access. Availability and integrity failures can qualify without a malicious disclosure. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001) | Actor | Duty and threshold | |---|---| | Processor | Notify the controller without undue delay after awareness. [SRC-020](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-020) | | Controller: regulator notification | Notify without undue delay and, where feasible, within 72 hours of awareness, unless risk to individuals is unlikely. Explain delay; information can follow in phases. [SRC-020](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-020) | | Controller: affected people | Communicate without undue delay when high risk is likely, subject to Article 34 exceptions. [SRC-021](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-021) | | Controller: records | Document breaches, effects and remedial action, including cases not notified. [SRC-020](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-020) | Service contracts should enable timely escalation and preserve the evidence needed for assessment. Contractual or sector reporting duties may add requirements. See the [operating model](https://healthcare-data-management-wiki.pages.dev/operating-model/index.md). ## Assess international access and transfers UK GDPR does not impose a universal UK-only hosting requirement. Its international-transfer rules allow specified routes. Hosting location alone does not answer whether a restricted transfer occurs. Assess the entities, access arrangements, subprocessors and onward transfers. [SRC-001](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-001), [SRC-022](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-022), [SRC-025](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-025) For a restricted transfer, determine whether applicable UK adequacy regulations cover it. Otherwise, consider appropriate safeguards, such as the UK International Data Transfer Agreement, UK Addendum or binding corporate rules. An applicable Article 49 exception is a separate route. If no route applies, do not make the transfer. [SRC-025](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-025) Revised Article 46 requires a reasonable and proportionate assessment that the data-protection test is met. Protection after transfer must not be materially lower than the UK standard. The safeguards and assessment must address the actual transfer. [SRC-022](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-022) Additional restrictions may arise from a source-data agreement or NHS contract. Record them separately from the general statutory transfer rules. Actual destinations and contractual restrictions remain open in the [applicability assessment](https://healthcare-data-management-wiki.pages.dev/applicability/index.md). ## Related pages - [Research home and governing question](https://healthcare-data-management-wiki.pages.dev/index.md) - [Legal framework](https://healthcare-data-management-wiki.pages.dev/legal-framework/index.md) - [Confidentiality and secondary uses](https://healthcare-data-management-wiki.pages.dev/confidentiality/index.md) - [NHS standards and assurance](https://healthcare-data-management-wiki.pages.dev/nhs-standards/index.md) - [Operating model](https://healthcare-data-management-wiki.pages.dev/operating-model/index.md) - [Validation queue](https://healthcare-data-management-wiki.pages.dev/validation-queue/index.md)