Data Processing Agreement (DPA)

The Processor processes personal data to provide the pharmacy-compliance Services for the term of the main agreement, then for the period after it that §4.7 sets out: a month in which its registers and records are read-only and exportable, with deletion three months after the Controller's subscription ends.

Hosting and processing of pharmacy compliance records (controlled-drugs register, RP log, patient-safety, private prescriptions, HR) as configured by the Controller. See the Processor's record of processing activities (RoPA).

• Data: patient identifiers (name, address, DOB, NHS number), clinical/medication detail, staff personal + financial data (incl. encrypted salary/NI/bank/DBS).
• Special category: health data (CD register, patient-safety incidents, private Rx).
• Subjects: the Controller's patients and staff.

The Processor shall:

1. 1.
   Process only on the Controller's documented instructions (this DPA + the Service configuration), including for international transfers; notify the Controller if an instruction infringes data-protection law.
2. 2.
   Ensure persons authorised to process are bound by confidentiality.
3. 3.
   Implement appropriate technical & organisational measures (Schedule 1 / Art.32).
4. 4.
   Engage sub-processors only per §6.
5. 5.
   Assist the Controller with data-subject rights requests, DPIAs, and consultations, taking into account the nature of processing.
6. 6.
   Notify the Controller without undue delay (target: within 48 hours) on becoming aware of a personal-data breach, with the information the Controller needs to meet its Art.33/34 duties.
7. 7.

   At the end of the contract, follow this timeline, counted from the day the Controller's subscription ends:

   • for one month, the registers and records are read-only: they can be viewed and exported, but nothing new can be recorded in them. Staff records, rotas, training records and account administration stay available, so that the account can be wound down. The Controller's export, which includes its statutory registers and its audit trail, is how the personal data is returned;
   • after that month, no one can access the Controller's account;
   • three months after the subscription ends, the Processor deletes the personal data it processes for the Controller, including the audit trail. Billing records the Processor keeps as a controller for its own accounts are outside this DPA.

   Statutory retention is the Controller's responsibility. Records the law requires the Controller to keep (for example the controlled drugs register, the responsible pharmacist record and the private prescription register) are kept by the Controller for their statutory periods, using its export, which is its copy. The Processor does not keep them for the Controller after the deletion date.

8. 8.
   Make available information to demonstrate compliance and allow/contribute to audits.

The Controller warrants it has a lawful basis for the processing and for instructing the Processor, and is responsible for the accuracy of data it inputs.

The Controller provides general authorisation for the sub-processors listed in the PharmacyHUB privacy notice. The Processor will give advance notice of any intended addition/replacement and allow the Controller to object on reasonable grounds. Every sub-processor that processes application data does so in the UK/EU. Two may process data outside the UK/EU, and neither receives application data: the payments sub-processor (Stripe) processes only payment data, under its own transfer safeguards (see §7); and the demo-booking calendar (Calendly) holds only the booking details a prospective customer gives it, for which the Processor is the controller, in the United States under its own transfer safeguards.

Personal data is hosted in the UK/EU (Supabase eu-west-2 London; Vercel lhr1). No application data is transferred to a non-adequate third country. Payment data (billing name/address, card details, payer email for booking payments) is collected by Stripe on Stripe-hosted pages and is subject to Stripe's own transfer safeguards under its DPA. If any other transfer becomes necessary, an appropriate transfer mechanism (e.g. UK IDTA / SCCs) will be put in place first.

Liability is as set out in the main agreement. In the event of conflict on data protection, this DPA prevails.

• Tenant isolation: two-layer (application-level scoping + PostgreSQL Row-Level Security on a non-superuser role), with an automated conformance test.
• Access control: fail-closed role-based authorisation; per-request server-side session re-derivation; IP-gated branch access that fails closed on misconfiguration; scrypt password hashing and argon2id PIN hashing; public sign-up creates an account only once its email address is verified; staff and locums join an organisation only by its invitation; two-step sign-in (authenticator app) for head office, superintendents and PharmacyHUB's own administrators.
• Encryption: TLS in transit; AES-256-GCM field-level encryption of patient and staff sensitive data at rest. Each organisation's sensitive data is encrypted under a key derived for that organisation alone.
• Integrity/audit: per-organisation tamper-evident, append-only audit log (hash-linked, database-immutable), verified daily.
• Resilience: managed daily database backups, kept 7 days; documented DR/restore and rollback runbooks; single UK region (eu-west-2 / lhr1).
• Monitoring: centralised error monitoring; post-deploy health gating.
• Clinical safety: clinical risk management to DCB0129, with a hazard log and a Clinical Safety Case Report available on request.