DPIA template
A data protection impact assessment under UK GDPR Article 35 is required where processing is likely to result in a high risk to the rights and freedoms of natural persons. Adoption of Lending Agent Oversight will not always trigger Article 35 (the workspace processes employment-relationship data on a clear legal basis with mature controls), but the ICO recommends running a DPIA as a matter of good practice for any large-scale processing of supervisory data, and the platform’s design assumes one is run.
This page is the template the principal firm completes at adoption. The platform operator can review the firm’s draft on request as part of the implementation playbook (adoption path). The template tracks the ICO’s seven-step DPIA framework.
1. Identify the need for a DPIA
Section titled “1. Identify the need for a DPIA”The principal firm records:
- The trigger for the assessment. Adopting a new system that processes the personal data of every AR-individual in the network, with audit-chain retention of 10 years, is a typical Article 35 trigger.
- The scope of the assessment (the workspace’s full surface, or a specific phase of rollout if the firm is piloting).
- Whether the processing is likely to require Article 35 prior consultation with the ICO. For the v1 surface, prior consultation is not expected because the residual risk is low, but the firm documents its position.
2. Describe the processing
Section titled “2. Describe the processing”Nature, scope, context, purpose
Section titled “Nature, scope, context, purpose”| Item | Entry |
|---|---|
| Nature of processing | Collection, storage, structuring, analysis, and disclosure to authorised users of supervisory records about ARs and AR-individuals. Append-only audit chain. |
| Scope | All AR-individuals in the firm’s network. All principal-side staff. Customer references (no structured customer PII). |
| Context | Adoption follows FCA authorisation as a principal firm under FSMA s.39 and is mandated indirectly by SYSC 9 (record-keeping), SUP 12.6 (continuing obligations), and PS22/11 (enhanced principal oversight). |
| Purpose | Compliance with FCA record-keeping and notification obligations; supervision of AR conduct; evidence of effective oversight for regulator inspection and enforcement. |
Data flows
Section titled “Data flows”The firm reproduces the diagram from data flow or describes the equivalent flows specific to its deployment.
Data subjects, data, retention
Section titled “Data subjects, data, retention”| Subject | Data | Retention |
|---|---|---|
| AR-individuals | Email, name, AR ID, role-relevant facts, MI return submissions, breach reports filed | 7 years after last regulated activity, then tombstoned |
| Principal-side staff | Email, name, role, sign-in metadata | 7 years after last regulated activity, then tombstoned |
| Customers (referenced) | Case reference only; no structured PII | Same as parent record |
| Audit subjects | Actor, action, IP, user-agent, timestamp | 10 years from event timestamp |
3. Consultation process
Section titled “3. Consultation process”The firm records who was consulted and on what basis. Typical consultees:
- The firm’s DPO (if appointed under DPA 2018 Part 4) or the privacy lead.
- The firm’s Senior Manager with SMF16 (Compliance Oversight) responsibility.
- An AR-side representative or a representative sample of ARs, where the AR’s view of the workspace is material to the assessment.
- The platform operator (the workspace vendor), which provides the technical reference materials and confirms factual claims about the system.
- The ICO, where prior consultation under Article 36 is required.
4. Lawful basis and proportionality
Section titled “4. Lawful basis and proportionality”The firm completes a per-purpose lawful-basis table. The default for Lending Agent Oversight:
| Purpose | Lawful basis | Note |
|---|---|---|
| Maintenance of supervisory records | Article 6(1)(c) (legal obligation: SYSC 9, SUP 12, SUP 15, DISP 1, PS22/11) | Floor: 7 years for substantive records, 10 years for audit chain |
| Sign-in identity, role assignment | Article 6(1)(b) (contract) | Employment contract or AR contract |
| Composite risk score | Article 6(1)(f) (legitimate interests) | Balancing test below |
| Cookies (session only) | PECR Regulation 6(4) (strictly necessary) | No analytics or marketing cookies |
Special category data: not processed in v1. The firm confirms its position and the controls that prevent free-text fields from receiving Article 9 data.
Article 6(1)(f) balancing test for the risk score
Section titled “Article 6(1)(f) balancing test for the risk score”Three-part test:
- Purpose test. The legitimate interest is the firm’s supervisory function under SYSC 9, SUP 12, and PS22/11, and the regulator’s and customer’s interest in effective oversight. The interest is grounded in regulation and is supportable.
- Necessity test. A composite signal informed by complaints density, breach severity, file-review score, time since last review, and MI anomaly is materially more useful than the alternative (manual periodic review). The score is not used for automated decisions; it informs human triage.
- Balancing test. The AR-individual’s reasonable expectations include being supervised by the principal firm under PS22/11. The score’s inputs are facts about the AR’s regulatory record, not about the individual. The score is visible to the AR via their own audit log. An Article 21 objection is supported (the AR can be removed from automated risk-score computation while substantive records remain on the legal-obligation basis).
5. Risk assessment
Section titled “5. Risk assessment”The firm enumerates risks to data subjects and rates each on likelihood and severity. The default risk register for adoption of Lending Agent Oversight:
| Risk | Likelihood | Severity | Net |
|---|---|---|---|
| Insider abuse: principal-side actor manipulates findings against an AR | Low | High | Medium, mitigated by audit chain immutability and AR-side audit visibility (see insider threat) |
| Audit-chain tampering by external attacker via compromised session | Very low | High | Low, mitigated by hash chain + daily integrity check + 10-year off-platform durable copy |
| Cross-tenant data leak via application bug | Very low | High | Low, mitigated by Postgres RLS + handler-level tenant check (fail-closed) |
| Credential stuffing on AR-user sign-in | Medium | Medium | Medium, mitigated by per-IP rate limit + per-email lockout (10 fails per email per hour) |
| Sub-processor compromise (Postmark, Sentry, Vercel, Postgres provider) | Low | Medium | Low, mitigated by EU-region preference, DPAs in place, 24-hour controller notification |
| Subject access request response failure (60-day window missed) | Low | Medium | Low, mitigated by /api/subjects/export endpoint plus ticket workflow |
| Free-text fields receive special-category data | Medium | Medium | Medium, mitigated by user training and the field-level guidance in data minimisation |
| Off-boarding leaves identifiable data outside the tombstoning window | Low | Low | Low, mitigated by automated tombstoning at users.status = off-boarded |
| International transfer compliance failure | Very low | Medium | Low, mitigated by UK/EU-region defaults and UK SCCs for any incidental US transfer (see sub-processors) |
The firm adapts the register to its specific deployment and records its own likelihood / severity ratings.
6. Mitigations
Section titled “6. Mitigations”For each medium-or-higher residual risk, the firm records the specific mitigation. The default:
- Insider abuse: monthly review of the audit log by the SMF16 or by an independent compliance function. Quarterly attestation by the senior management function that no out-of-band edits to the supervisory record have been requested or made.
- Credential stuffing: per-tenant TOTP requirement on AR-user sign-in (a per-tenant flag; the default is password-only, the firm’s choice to enable). Recommended for any firm with 50+ AR-users.
- Free-text fields: training at adoption (covered by the firm’s privacy training). Periodic spot-check of breach descriptions and file-review notes for special-category data.
- All other risks: rely on the platform’s documented controls and the operator’s SOC 2 Type II report.
7. Sign-off and integration
Section titled “7. Sign-off and integration”The firm’s DPO (or privacy lead) signs the DPIA. The Senior Manager with SMF16 responsibility countersigns. The DPIA is held in the firm’s records and reviewed annually as part of the firm’s annual self-assessment under PS22/11, or more often if the platform’s processing changes materially.
The DPIA references the firm’s privacy notice (which carries the Article 13 information for AR-individuals) and the firm’s Article 28 DPA with the platform operator.
What the platform operator provides
Section titled “What the platform operator provides”The operator provides, on request:
- The current sub-processor list (sub-processors).
- The most recent SOC 2 Type II report.
- The data-flow diagram and the API surface table.
- Confirmation of any change to processing (sub-processor addition, retention change, region change) with a 30-day notice window.
- A factual sign-off on the DPIA section dealing with the platform’s own controls.
The operator does not sign the DPIA itself; the controller’s DPIA is the controller’s record.