/
PKB Pre-Deployment Assessment

Patients Know Best Resource Hub | Deploy | Developer | Trust Centre | Manual | Research | Education | Release Notes

PKB Pre-Deployment Assessment

Respondent Guide

A practical guide for Information Governance, Data Protection and related assurance teams

 

Purpose of this guide

This guide expands the original Pre-Deployment Assessment form into a practical completion guide. It keeps the form's original sections and questions, but explains what each question is intended to establish, the level of detail expected, and the kinds of evidence or wording that can help a respondent provide a useful answer.

The assessment is completed once per deployment, before go-live, to support PKB's due diligence. The form asks respondents to answer fully, explain any inapplicable questions, and avoid leaving questions blank. Please note that the form cannot save a partial draft, although submitted responses can be edited later via the confirmation-page link.

Please answer the assessment in relation to the PKB deployment or project. Where you reference an organisation-wide policy, certification, control or framework, ensure that it actually applies to the system, environment or processing covered by this assessment. If its scope is limited or only partly applicable, explain that distinction.

The assessment will normally be completed or coordinated by someone responsible for Data Protection, Information Governance, Privacy, or Security. Some questions may require input from technical, security, legal or project colleagues. One coordinated response should be submitted on behalf of the organisation.

Quick-start: before you open the form

The quickest way to complete the assessment is to gather the information below first. Most answers should already exist in your organisation's IG/DP, security, architecture, procurement or project documentation.

  • Project or deployment description, including what the integration or processing is intended to achieve.

  • The organisation's legal entity, jurisdiction and relevant data-protection contact.

  • The population affected and the countries in which data subjects are located.

  • Where the data will be hosted or otherwise stored at rest, including relevant cloud/service providers.

  • The data flow or integration method and the categories/types of data involved.

  • Privacy notice, lawful basis and special-category condition information, where applicable.

  • DPIA status and any related project documentation.

  • Retention arrangements, DSAR process, security controls, access controls and encryption arrangements.

  • Applicable certifications, accreditations or assurance frameworks.

  • Any secondary uses, analytics, research, AI/model development, product improvement or other uses outside the primary stated purpose.

  • The consent mechanism and withdrawal process, if consent is being relied upon.

How much detail is expected?

The assessment is intended to support due diligence, not to reproduce an entire DPIA, RoPA, security architecture or privacy notice. Provide enough information for a reviewer to understand the process and determine whether further evidence or clarification is needed.

  • Be specific about the processing rather than using broad labels such as 'health data' or 'personal data'.

  • Where another document contains the detail, reference it rather than copying it wholesale (for example, 'See DPIA section 4.2' or 'Noted in PID').

  • If a question does not apply, enter 'N/A' and briefly explain why. Please do not leave it blank.

  • If a control exists but is not yet fully implemented, say so and give the current status or planned completion point rather than describing the intended future state as though it were already operational.

  • Where your organisation is outside UK/EU GDPR scope, explain the equivalent legal or regulatory framework where relevant rather than assuming GDPR terminology applies.

  • Use plain language. The reviewer may not have specialist technical or system-specific knowledge.

A useful answer pattern

For many questions, a strong answer can follow this simple pattern:

  • What applies — identify the control, arrangement or decision.

  • How it works — give a short description of the practical implementation.

  • Evidence/reference — point to the relevant policy, DPIA, certification or project document where useful.

  • Exceptions — explain anything unusual, incomplete or not applicable.

Section 1 — Basic Information

This section establishes the identity, legal context, geographic scope and high-level nature of the processing activity. The form describes it as collecting basic information about the Processing Activity undertaken by the respondent organisation. Think of this section as answering: Who is undertaking the processing, where are they operating, whose data is involved, where does it reside, and what is the deployment intended to do?

 

1. Completed by

What this question is asking: Identify the person completing the assessment and their professional role.

How to answer: Provide your name and job title/role. Ideally use a role that makes clear your involvement in the assessment, such as DPO, IG Lead, Privacy Manager, Security Lead or Project Owner.

Example: ‘Jane Smith — Data Protection Officer.’

Helpful checks before submitting:

  • Use a named individual rather than a generic team name.

  • The person named here should be able to clarify the answers if PKB has follow-up questions.

 

2. Contact email address

What this question is asking: Provide a reliable contact route for assessment queries.

How to answer: Use your organisational email address and, where appropriate, an address that will remain monitored through the deployment period.

Example: ‘privacy@organisation.example’

Helpful checks before submitting:

  • Check that the mailbox is actively monitored.

  • Avoid personal/non-organisational addresses unless there is a specific reason.

 

3. Organisation name

What this question is asking: Identify the organisation undertaking the processing or deployment.

How to answer: Give the organisation's recognised operating name. If the contracting party or legal entity differs, explain that in Question 5.

Example: ‘Example Health Technologies Ltd.’

Helpful checks before submitting:

  • Use the name that appears in relevant contractual/project documentation.

 

4. Organisation address

What this question is asking: Identify the organisation's principal or relevant business address.

How to answer: Provide the organisation's address. This is particularly useful where the organisation operates across several jurisdictions.

Example: ‘123 Example Street, Amsterdam, Netherlands.’

Helpful checks before submitting:

  • If multiple offices are relevant, identify the principal address and explain any material jurisdictional distinction.

 

5. Legal entity

What this question is asking: Clarify whether the organisation name is different from the legal entity responsible for the processing.

How to answer: Provide the registered legal entity where it differs from the organisation name/address. This may be relevant for subsidiaries, parent companies, trading names or group structures.

Example: ‘Example Trading Ltd is the trading name; Example Holdings Ltd is the contracting/legal entity.’

Helpful checks before submitting:

  • If the legal entity is the same as the organisation name, say 'Same as organisation name'.

  • If responsibility is split across group companies, briefly explain which entity undertakes the processing.

 

6. Legal jurisdiction

What this question is asking: Identify the jurisdiction(s) in which the organisation operates for this processing activity.

How to answer: State the relevant country and, where material, the applicable regional legal jurisdiction. This is not necessarily the same as the location of the data subjects.

Example: ‘England and Wales; UK GDPR applies.’

Helpful checks before submitting:

  • Consider whether different entities or processing operations are subject to different regimes.

  • If GDPR does not apply, identify the relevant local framework where known.

 

7. Citizen / Data Subject location

What this question is asking: Identify where the people whose data is processed are located or ordinarily reside.

How to answer: Give the geographic scope of the affected population. If global, say so and identify any important regional distinctions.

Example: ‘UK; Netherlands; or Global.’

Helpful checks before submitting:

  • Do not confuse data-subject location with hosting location.

  • If only a defined cohort is affected, describe it rather than simply saying 'global'.

 

8. Data hosting / storage location(s)

What this question is asking: Identify where the data is hosted/stored at rest.

How to answer: State the country/region in which the relevant data is stored. If a cloud provider is used, identify the relevant hosting region(s), not merely the provider's headquarters.

Example: ‘UK (London) cloud region.’

Helpful checks before submitting:

  • Consider backups, disaster-recovery copies and replicated storage where they materially change the geographic footprint.

  • If data can be transferred elsewhere, address that in the relevant transfer/security documentation.

 

9. Sub-processors and hosting providers

What this question is asking: Identify third-party service providers involved in hosting or processing the data.

How to answer: List relevant sub-processors or hosted service providers, particularly where the processing involves cloud infrastructure such as GCP, AWS or Azure. Distinguish infrastructure hosting from other vendors where useful.

Example: ‘Google Cloud Platform — hosting/infrastructure.’

Helpful checks before submitting:

  • If the answer is a long formal sub-processor list, reference the authoritative list and identify the providers relevant to this deployment.

  • Do not omit a provider merely because it does not directly interact with the data subject.

 

10. Assessment date

What this question is asking: Record when the assessment was completed.

How to answer: Use a clear date format, preferably day month year.

Example: ‘7 January 2019.’

Helpful checks before submitting:

  • Use the date on which the assessment is actually completed/reviewed.

 

11. Project/deployment description

What this question is asking: Provide a concise description of what is being deployed and what processing it will perform.

How to answer: Describe the activity in business/clinical terms rather than technical implementation detail. Explain what the deployment does, who it serves, and the main reason for processing the PKB data.

Example: ‘Clinical trial recruitment using selected patient information; or patient-driven AI to support multi-step health journeys.’

Helpful checks before submitting:

  • Avoid vague descriptions such as 'integration' or 'data processing'.

  • Mention the principal use case, affected population and broad outcome.

  • If there are materially different processing purposes, identify them rather than hiding them in a generic description.

 

Section 2 — Data Asset

This section concerns the data asset received from, or accessed through, PKB and then processed by the respondent organisation. The form notes that answers may already be captured in a Project Initiation Document or similar document, in which case respondents can reference it.

The key question is: What data are you accessing, how are you accessing it, and which people does it relate to?

 

12. Data access / integration method

What this question is asking: Describe how the organisation will access or receive data from PKB.

How to answer: Give a high-level description such as FHIR integration, API integration or Web GUI access. The form explicitly does not require a detailed technical architecture.

Example: ‘FHIR/API integration.’

Helpful checks before submitting:

  • Name the access mechanism rather than describing the whole software stack.

  • If there are multiple access routes, list each one.

 

13. Data types

What this question is asking: Identify the nature and specific types of information being processed.

How to answer: Start with the broad classification (for example personal data, special category data, anonymised data or deidentified data), then specify the actual information involved. Avoid using only 'health data'.

Example: ‘Personal data and special category health data — diagnoses, measurements, test results and appointment information.’

Helpful checks before submitting:

  • State whether data is identified, pseudonymised/deidentified or anonymised as relevant.

  • For health data, identify meaningful categories such as diagnoses, medications, observations, results, appointments or care plans.

  • If only anonymised data is received, state that and describe the dataset sufficiently to understand the scope.

 

14. Categories of data subjects

What this question is asking: Describe the groups or cohorts of data subjects represented in the dataset.

How to answer: Identify the intended cohort, preferably with useful specificity.

Example: ‘Patients with type 2 diabetes participating in the programme.’

Helpful checks before submitting:

  • Where relevant, describe age group, patient cohort, service-user group or other defining characteristic.

  • Do not provide individual names or identifiers in the assessment.

 

Section 3 — Data Protection, Information Governance and Security Assurance

This is the substantive due-diligence section. It asks how the organisation manages processing in line with common data protection, security, and accountability requirements. The form states that where GDPR does not apply, or a condition is not relevant, respondents should mark the item as N/A or provide a short explanation.

A useful way to approach this section is to answer from the organisation's existing governance evidence. The form is not asking you to create a new policy for the deployment; it is asking you to explain what arrangements already govern it.

 

15. Data protection authority registration

What this question is asking: Identify the organisation's data-protection supervisory registration where applicable.

How to answer: For UK organisations, provide the ICO registration number. If your organisation is registered with another supervisory authority, provide the equivalent registration/ID. If the processing is outside GDPR catchment, state N/A and explain if useful.

Example: ‘ICO registration: Z1234567’

Helpful checks before submitting:

  • Use the registration relevant to the organisation undertaking this processing.

  • If registration is not applicable, explain why rather than leaving the answer blank.

 

16. Data Protection Officer / privacy lead details

What this question is asking: Identify the person or function responsible for data-protection oversight.

How to answer: Provide the DPO's name and contact details where a DPO is appointed. If GDPR does not apply and there is no DPO, identify the senior person responsible for privacy/data protection for the processing.

Example: ‘John Stones, Data Protection Officer — Tel: 0800 000 000 - Address: DP Dept, Floor 3, HQ House, London Road, London - Email: dpo@example.org’

Helpful checks before submitting:

  • Use a monitored organisational contact route.

  • If a group DPO is responsible, clearly identify the group arrangement.

 

17. Privacy notice / transparency information

What this question is asking: Show how data subjects are informed about the processing.

How to answer: Provide the URL of the relevant privacy notice. The notice should cover the processing being undertaken. If it does not, explain what privacy information is provided instead and how it reaches data subjects.

Example: https://example.org/privacy-notice

Helpful checks before submitting:

  • Check that the linked notice actually covers the relevant processing rather than merely being a generic corporate privacy statement.

  • If the processing is not yet live, identify the notice that will apply at go-live, if available.

 

18. Purposes of processing

What this question is asking: Describe why the organisation processes the data.

How to answer: Summarise the specific purposes in language consistent with the organisation's privacy information and records of processing. Avoid broad statements such as 'service improvement' unless that is genuinely the purpose and is sufficiently explained.

Example: ‘To identify eligible participants for a clinical research programme and support recruitment.’

Helpful checks before submitting:

  • List distinct purposes if there is more than one.

  • Consider whether analytics, research, AI/model development, product improvement or other secondary activities constitute separate purposes.

  • The ICO emphasises that purposes should be specified, documented and reflected in privacy information.

 

19. Lawful basis and special category condition

What this question is asking: Identify the Article 6 lawful basis for each relevant purpose and, where special category data is processed, the separate Article 9 condition. These are distinct requirements: an Article 6 basis does not by itself authorise special category processing.

How to answer: State the applicable Article 6 lawful basis for each purpose. Where special category data is processed, also state the relevant Article 9 condition and any additional national-law requirement where applicable. If different purposes use different bases or conditions, map them separately. If UK/EU GDPR does not apply, describe the equivalent legal authority or basis.

Example: ‘Article 6(1)(e) public task; Article 9(2)(h) provision of health or social care, where applicable.’

Helpful checks before submitting:

  • Do not simply state 'GDPR' or 'consent' without explaining what processing the basis covers.

  • If different purposes use different bases, map the basis to each purpose.

  • The ICO notes that the appropriate lawful basis depends on the purpose and relationship with the individual and should be determined and documented before processing begins.

 

20. Withdrawal mechanism

What this question is asking: Explain how an individual can withdraw consent where consent is the lawful basis.

How to answer: Only complete this where consent/explicit consent is relied upon. Describe how withdrawal works in practice, who receives the request, how quickly it is actioned, and what happens to data already processed where relevant.

Example: ‘Individuals can withdraw through the account settings or by contacting the DPO; withdrawal is recorded and future processing relying on consent is stopped.’

Helpful checks before submitting:

  • Make sure withdrawal is as easy as giving consent.

  • Explain any consequences or limitations, such as processing that has already taken place or processing relying on another lawful basis.

  • Consent should not be selected merely because it is convenient; the ICO says consent must reflect the true nature of the relationship and purpose.

 

21. Data Protection Impact Assessment (DPIA)

What this question is asking: Establish whether the processing has been assessed for data-protection risks and the current status of that assessment.

How to answer: Use the status that accurately reflects the deployment: (1) completed, with reference/date where available; (2) considered but determined not to be required, with a brief explanation; or (3) in progress, with the current status. Where another equivalent privacy impact assessment applies, identify it.

Example: ‘Yes — DPIA completed and approved by the DPO; reference DPIA-2026-014.’

Helpful checks before submitting:

  • Do not rely solely on a generic corporate DPIA if the deployment creates materially different risks.

  • If a DPIA is in progress, say so and state its status rather than answering 'yes' as if it were complete.

 

22. Data minimisation

What this question is asking: Explain how the organisation limits the data accessed or retained to what is necessary for the stated purposes.

How to answer: Describe the practical controls: restricted fields, cohort filtering, date ranges, role-based access, selective API scopes, exclusion of unnecessary identifiers, or equivalent measures.

Example: ‘Only HbA1c results and relevant demographic information for the defined cohort are accessed; unrelated clinical records are excluded.’

Helpful checks before submitting:

  • Tie the minimisation decision directly to the stated purpose.

  • If the integration technically makes a broader dataset available, explain what controls prevent unnecessary use or access.

  • The ICO describes minimisation as data that is adequate, relevant and limited to what is necessary.

 

23. Data retention and deletion

What this question is asking: Explain how long the data is retained and why.

How to answer: State the retention period or rule, the event that starts the retention clock where relevant, and what happens when the period expires. The arrangement should be consistent with what is communicated to data subjects.

Example: ‘Identifiable data is retained for the duration of the programme plus 12 months for audit and support, after which it is securely deleted or anonymised.’

Helpful checks before submitting:

  • Distinguish between active data, backups and derived datasets where relevant.

  • If retention varies by data type, state the different periods.

  • Avoid 'indefinitely' unless there is a documented and justified basis for doing so.

 

24. Data subject rights / DSAR process

What this question is asking: Explain how the organisation handles data-subject rights requests, including Subject Access Requests (DSARs), in relation to this processing.

How to answer: Describe the process for receiving, verifying, triaging, responding to and recording requests. Where relevant, explain how requests concerning data received from or accessed through PKB are identified, routed or coordinated, particularly where PKB and the respondent have different controller/processor roles.

Example: ‘DSARs are received by the Privacy Team, identity is verified, the request is logged, relevant systems are searched, exemptions are assessed and a response is issued within the applicable statutory timeframe.’

Helpful checks before submitting:

  • Include a link/reference to the relevant procedure if appropriate.

  • Consider access, rectification, erasure, restriction, objection and portability where relevant to the processing.

  • Do not assume that every right applies in exactly the same way to every processing activity.

 

25. Security certifications, accreditations and assurance frameworks

What this question is asking: Identify independent or formal assurance frameworks relevant to the deployment.

How to answer: List certifications, accreditations and frameworks that genuinely cover the relevant organisation, system or processing. Examples in the original form include SOC II, ISO 27001:2022, Cyber Essentials Plus, DSPT, DTAC and MHRA.

Example: ISO/IEC 27001:2022; SOC 2 Type II; Cyber Essentials Plus.

Helpful checks before submitting:

  • State the scope where it matters — a certification may cover a particular service or environment rather than the whole organisation.

  • Do not list certifications simply because the organisation holds them if they do not cover this processing.

  • If none apply, state 'none' as requested by the form.

 

26. Access controls

What this question is asking: Explain who can access the data and how access is restricted.

How to answer: Describe the main access-control model: RBAC, named-user access, privileged access management, least privilege, MFA, approval workflows, periodic access reviews, or equivalent controls. Explain which roles can see identified or sensitive data.

Example: ‘Role-based access control; only authorised clinicians can access identified clinical data; administrative staff have access only to operational metadata.’

Helpful checks before submitting:

  • Distinguish application access from database/infrastructure access.

  • Mention privileged/admin access where material.

  • If access is unrestricted, say so explicitly rather than implying controls exist.

 

27. Encryption

What this question is asking: Describe protection of data at rest.

How to answer: Focus primarily on data-at-rest encryption, as requested by the original form. State the encryption approach where known, including the relevant service/storage layer. If data is not encrypted at rest, say so.

Example: ‘AES-256 encryption at rest using cloud-provider managed encryption keys.’

Helpful checks before submitting:

  • If customer-managed keys or key rotation are relevant, mention them.

  • Do not substitute a statement about TLS/in-transit encryption for the requested at-rest answer.

  • If different storage layers have different arrangements, explain the material differences.

 

28. Incident management and personal data breach response

What this question is asking: Explain how security or personal-data incidents involving the processing are identified, managed and escalated.

How to answer: Give a concise summary of the incident-management framework, including detection, triage, containment, investigation, notification/escalation and lessons learned where relevant.

Example: ‘Incident Management Procedure aligned to ISO/IEC 27035 and internal data-breach response procedures; incidents are escalated to the DPO where personal-data breach criteria may be met.’

Helpful checks before submitting:

  • Reference an existing procedure/framework where available.

  • Mention regulatory/customer notification processes if they are relevant.

  • If no procedure exists, state 'no procedure' as requested by the form.

 

29. Further or secondary uses of the data

What this question is asking: Identify any current or anticipated use of the data beyond the primary purposes described earlier.

How to answer: State whether the data is or may be used for additional purposes such as research, analytics, service or product improvement, AI/model development or training, benchmarking, commercial analysis, or creation of derived datasets. For each additional use, briefly describe the purpose and relevant governance or legal basis where applicable. If there are no further uses, say so explicitly.

Example: ‘No secondary use; data is used solely for the stated clinical service purpose.’

Helpful checks before submitting:

  • Do not assume a use is 'secondary' only because it is not patient-facing. Internal analytics can still be a separate purpose.

  • If a secondary use exists, describe it clearly rather than treating it as incidental.

  • Check consistency with the purposes and privacy notice. The ICO notes that reuse for a new purpose must be considered against purpose limitation and lawful-basis requirements.

 

30. Citizen / data subject benefit

What this question is asking: Explain what benefit the processing provides to the people whose data is involved.

How to answer: Describe the direct benefit, indirect/system-level benefit, or explain honestly if there is no direct citizen benefit. This is a substantive explanation rather than a marketing statement.

Example: ‘Direct benefit: earlier identification of eligible patients and faster access to a relevant clinical service. Indirect benefit: improved population-level research evidence.’

Helpful checks before submitting: 

  • Be realistic and specific.

  • Distinguish direct individual benefit from benefits to a wider patient population or health system.

  • If there is no direct benefit, saying so is preferable to overstating benefits.

 

31. Consent quality and assurance

What this question is asking: Explain how the organisation has assured itself that any consent relied upon is valid, appropriately obtained, recorded and capable of withdrawal.

How to answer: Complete this only where Article 6(1)(a) consent and/or Article 9(2)(a) explicit consent, or an equivalent consent requirement under applicable law, is relied upon. Describe how the mechanism has been assessed for freely given, specific, informed and unambiguous consent; where explicit consent is required, explain how the higher standard is met. Address granularity, presentation, recording/evidence and withdrawal, and reference any DPO, legal, external or user-testing review.

Example: ‘Consent mechanism reviewed against the organisation's GDPR consent checklist and approved by the DPO; wording and withdrawal mechanism were also subject to legal review.’

Helpful checks before submitting:

  • Explain how consent is freely given, specific, informed and unambiguous, and how it is recorded.

  • Where explicit consent is required for special-category processing, ensure the mechanism meets the higher standard.

  • The EDPB's 2026 consent guidance describes valid consent as requiring cumulative criteria including genuine choice/control and specificity.

 

Final review before submission

Before submitting, check the assessment for internal consistency. Reviewers will often get more value from a short, coherent set of answers than from lengthy answers that contradict one another.

  1. The project/deployment description matches the stated purposes of processing.

  2. The data types and data categories match what the deployment actually accesses.

  3. The geographic scope matches the stated hosting/data-location arrangements.

  4. The lawful basis matches the purposes and any special-category processing.

  5. The privacy notice covers the processing described in the form.

  6. The DPIA status is accurate and relates to this deployment where a DPIA is required or appropriate.

  7. Data minimisation is described in practical terms rather than simply stating 'we comply with GDPR'.

  8. Retention periods are consistent with the privacy information and operational reality.

  9. Security, access-control and encryption answers describe the actual production environment, not only planned controls.

  10. Any secondary uses are disclosed and consistent with the purposes/privacy information.

  11. Consent and withdrawal answers are completed only where consent is actually relied upon.

  12. Every N/A answer includes a brief explanation.

  13. Any referenced document is identifiable enough for the reviewer to locate it.

Common answer-quality problems to avoid

  • Using 'GDPR compliant' as the answer to a question that asks for a specific control or legal basis.

  • Saying 'health data' without identifying the relevant categories of health information.

  • Listing a cloud provider without stating the relevant hosting/data location.

  • Describing encryption in transit when the question specifically asks about encryption at rest.

  • Calling additional use 'analytics' without explaining what the analytics are for.

  • Answering 'consent' without identifying the purpose, consent mechanism and withdrawal route.

  • Saying 'N/A' without explaining why the question does not apply.

  • Describing controls that are planned rather than controls that are actually in place.

  • Providing a generic corporate privacy notice when it does not cover the deployment.

  • Giving a certification name without considering whether its scope actually covers the relevant system or processing.

Useful external references

These references are intended as supporting guidance rather than as additional requirements of the PKB assessment.