Data Protection Impact Assessment

1. Why we are doing a DPIA

1.1 The trigger

Article 35(1) of the UK GDPR requires a DPIA where processing is “likely to result in a high risk” to the rights and freedoms of natural persons. The ICO additionally requires a DPIA for any processing on the list of operations always requiring a DPIA.

For VetForms the relevant triggers are:

• systematic and extensive evaluation of personal information using automated processing (the validation engine, V-001 to V-012 and W-001 to W-005);
• large-scale combination of datasets in a way the data subject (the pet owner) would not necessarily expect, combining contact details, travel itinerary, and animal records;
• processing that feeds a regulated cross-border process (the AHC is presented to EU border authorities); and
• innovative use of technology in a sector (veterinary regulatory) where digital handling of owner data is not yet the norm.

We have therefore chosen to complete a DPIA before going live with any practice processing live owner data.

1.2 Why no statutory DPO

A statutory DPO is required under Article 37 UK GDPR where:

• the Processor is a public authority (not us);
• the core activity requires regular and systematic monitoring of Data Subjects on a large scale (not us — we operate per-certificate, not continuous); or
• the core activity is large-scale processing of special-category data (not us — animal health is not special category for humans).

Accordingly no DPO is mandatory. Responsibility sits with the sole proprietor, Josh Human, who will discharge DPO-equivalent duties (privacy by design, breach response, this DPIA, ICO liaison).

2. Describe the processing

2.1 Nature of the processing

VetForms is a multi-tenant SaaS application that lets a UK Official Veterinarian (OV) prepare, validate, and issue Animal Health Certificates (“AHCs”) for companion animals (dogs, cats, ferrets) travelling from Great Britain to the European Union. The flow is:

1. OV creates a practice account. Authentication is via Clerk. Practice administrator accepts the Terms and the DPA.
2. OV creates a draft certificate and, in most cases, generates a tokenised owner-collection link valid for 14 days.
3. Owner submits their details through /collect/[token]. The submission populates the certificate.
4. OV reviews, runs validation, corrects, and signs. A PDF is generated server-side by overlaying data onto the EU Annex IV template via pdf-lib; the PDF is stored in Vercel Blob and referenced from the database.
5. Certificate moves through statuses draft → owner_pending → ov_review → validated → generated → signed (or voided).
6. Audit log captures every state change with user, IP, and action.

2.2 Scope: what data, who, how much, where

2.3 Relationships with Data Subjects

• Owners have a direct relationship with their veterinary practice. They reach VetForms via a link sent to them by the practice. Our brand is visible in the form but the controller is the practice. Owners are typically the data subjects most at risk if a leak occurred.
• OVs and staffconsent to VetForms’s terms when they create an account. The relationship is contractual.
• Carriers and authorised persons typically do not interact with the service at all; their data is entered by the owner or the OV. They are unlikely to be aware their data is on the system unless the practice tells them.

2.4 Processors and locations

2.5 Technologies and processing methods

• TypeScript/Next.js application on Vercel; PostgreSQL on Neon; auth on Clerk; PDFs generated in-process with pdf-lib.
• Automated validation rules (V-001 to V-012, W-001 to W-005) evaluate field timing and consistency. They produce blockers and warnings; they do not make a binding decision (see §4.5).
• Owner tokens are random, single-use, time-limited (14 days), and tied to a specific certificate.
• Audit logging is server-side and append-only.

3. Consultation

Article 35(9) UK GDPR requires the Controller to seek the views of Data Subjects where appropriate. For this DPIA we propose:

4. Necessity and proportionality

4.1 Lawful basis

4.2 Is each processing operation necessary?

We do not collect data that is not used by the template, the validation rules, or the audit log. There is no analytics tracking of identified users in the product (see action P-1).

4.3 Is the data minimal for the purpose?

Reviewed against the database schema (src/db/schema.ts):

• No special-category data.
• No financial data (no current billing system).
• No marketing fields.
• Free-text fields (colour markings, address line 2) are minimised to what the certificate template asks for.

Action P-1: confirm no third-party analytics is loaded on /collect pages, and document this on the privacy notice.

4.4 How do we support Data Subject rights?

4.5 Article 22 — automated decision-making

The validation engine evaluates field-level rules and produces blockers/warnings in the UI. A blocker prevents PDF generation until resolved by the OV. This is automated processing, but it does not produce a decision with legal or similarly significant effect within the meaning of Article 22(1), because:

• a human OV is in the loop on every certificate and must consciously review, sign, and issue it;
• a blocker does not refuse to issue the certificate — it asks the OV to fix data or override; an override path exists in the product;
• the rules concern animal-eligibility-by-data-completeness, not a decision about a human person.

We will revisit this conclusion if the rules ever shift to denying issuance with no human override.

5. Risk register

Scoring uses ICO-style 1–5 for likelihood and impact (1 = remote / minor, 5 = near-certain / severe). Inherent risk = likelihood × impact before mitigation; residual risk = same after the mitigations listed in §6 are in place.

6. Measures to reduce risk

7. Outstanding actions to close before live

The DPIA cannot be signed off until the following are in place:

• A-1. Register Human Builds with the ICO and add the registration number to the privacy policy.
• A-2. Stand up vetforms.co.uk/privacy, vetforms.co.uk/terms, vetforms.co.uk/dpa, vetforms.co.uk/sub-processors as public pages.
• A-3. Implement the retention runner (M-5).
• A-4. Wire DPA click-through acceptance into the practice-creation flow and store the event in audit_logs.
• A-5. Document the business continuity plan (M-9).
• A-6. Owner consultation: usability test the /collect form with at least 5 owners and incorporate findings into the privacy notice wording.
• A-7. Independent legal review of the privacy policy, terms, DPA, and this DPIA.
• A-8. Penetration test of the multi-tenant boundaries (M-2) — even a light-touch internal test before pilot, full external test before scaling.

8. Outcome and sign-off

8.1 Residual-risk outcome

After the actions in §7 are complete and the measures in §6 are in place, the highest residual risk is R-9 (international transfer regime change), scored Medium. This is monitored rather than mitigated below Medium because it depends on UK government policy on data transfers, which is outside our control.

No residual risk is rated High. Prior consultation with the ICO under Article 36 UK GDPR is therefore not required.

8.2 Approval

Once signed, store this document with the version number and date. Re-review on material change to the processing, or no later than 27 May 2027.