UK GDPR

UK GDPR (the retained version of Regulation (EU) 2016/679 as it forms part of UK law, supplemented by the Data Protection Act 2018 and amended by the Data (Use and Access) Act 2025) is the applicable data-protection regime for any deployment of Lending Agent Oversight. This page maps the specific articles a principal firm needs to think about and explains how the platform’s architecture supports each.

Article 5: principles

UK GDPR Article 5(1) sets out six principles. Each maps to a design decision in the workspace.

Lawfulness, fairness, transparency (Article 5(1)(a)). Three lawful bases are in play, set out under Article 6 below. Transparency is delivered via the principal firm’s own privacy notice (the firm is the controller for AR-individual and customer data) and the workspace’s notification copy at sign-in and at first use of each surface.
Purpose limitation (Article 5(1)(b)). Personal data is used solely for supervisory oversight of the AR network and the audit-evidence functions that supervision requires under FCA SYSC 9, SUP 12, and SUP 15. It is not used for marketing, profiling for unrelated purposes, or data sharing beyond the named sub-processors.
Data minimisation (Article 5(1)(c)). AR contact details and customer references only. No structured customer PII collected. Detail in data minimisation.
Accuracy (Article 5(1)(d)). Live records are corrigible by the principal-side compliance officer (with audit-chain trail of every correction). Historical audit events are not editable; corrections take the form of a new event citing the prior. Article 16 rectification is handled through the firm’s wider data-subject-rights process.
Storage limitation (Article 5(1)(e)). Substantive entities retained 7 years from trigger; audit chain retained 10 years. The retention floor is set by SYSC 9, not by minimisation alone. Detail in retention.
Integrity and confidentiality (Article 5(1)(f)). TLS in transit, Postgres row-level security on tenant_id, append-only audit chain with SHA-256 hash linking, role-based access via session cookies plus TOTP, step-up authentication on terminal actions. Detail in tampering and replay.

Article 6: lawful basis

Three Article 6 bases apply, each to a different category of processing.

Article 6(1)(c) (legal obligation). The principal firm is bound by FCA SYSC 9.1.1R to maintain orderly records of its business activities. PS22/11 (December 2022) introduced enhanced principal-oversight duties, including specific record-keeping for self-employed AR-individuals. SUP 15.3 imposes notification obligations for material breaches. DISP 1 imposes complaints-data flow from AR to principal. Each of these is a UK legal obligation, and the workspace’s processing of AR records, breach reports, file reviews, MI returns, and audit events is necessary for the firm’s compliance with those obligations.

This is the basis for all substantive supervisory records and the audit chain.

Article 6(1)(b) (contract). Sign-in identity, role assignment, and notification preferences for principal-side staff and AR-individuals rest on the contract between the user and the principal firm (employment contract or AR contract).

Article 6(1)(f) (legitimate interests). The composite risk score (lib/risk-scoring.ts) and its inputs are computed for the principal firm’s internal triage. The score is the firm’s own signal; it is not used to make automated decisions affecting the AR or any customer. The legitimate interests are the firm’s own supervisory function and the regulator’s (and customer’s) interest in effective oversight. A balancing test sits in the DPIA the firm completes at adoption.

Article 22 (automated individual decision-making) does not apply. The risk score informs human judgement; off-boarding, FCA notification, and annual-review sign-off are all human decisions taken by named regulated individuals with step-up authentication recorded.

Article 9: special category data

The v1 surface does not process special category data. There are no health, racial, religious, political, biometric, or sex-life fields collected. File-review evidence and breach descriptions are free-text and could in principle contain such material if a principal-side user pasted it; the data minimisation guidance (data minimisation) instructs users to avoid this and the DPIA process the firm completes at adoption explicitly addresses the controls.

A planned post-v1 vulnerable-customer indicator workflow may introduce optional indicators that reveal health information. When that work lands, the lawful basis will be Article 9(2)(g) (substantial public interest) supported by Schedule 1 Part 2 of the DPA 2018. That is documented now so principal firms can scope it; it is not in v1.

Article 13: information at the point of collection

The principal firm’s privacy notice carries the Article 13 information for AR-individual and customer data. The platform operator’s notice carries Article 13 information for billing-side data the operator processes as a controller.

Article 13(1) and 13(2) require a specific list of items at the point of collection. The principal firm’s notice covers:

Identity and contact details of the controller (the principal firm) and the DPO if appointed.
Purposes of the processing and the lawful basis (Article 6(1)(c) for supervisory records; Article 6(1)(b) for contract administration; Article 6(1)(f) for risk scoring with the balancing test).
Recipients (the platform operator as processor; the named sub-processors; the FCA where notification or registration requires it; an FCA-auditor where the per-tenant flag is enabled).
Retention period (7 years for substantive records, 10 years for audit chain).
Subject rights as set out in Articles 15 to 22.
Right to lodge a complaint with the ICO.

The workspace surfaces a link to the principal firm’s notice on every AR-user-facing surface. The implementation chapter for principal firms (adoption path) provides a privacy-notice template the firm can adapt.

Articles 15 to 22: data subject rights

Each right is supportable from the data the workspace holds. The principal firm is the controller and is the recipient of the request; the workspace exposes the operational endpoints the firm uses to respond.

Article 15 (access). A subject access request is fulfilled by POST /api/subjects/export (principal-admin only), producing a JSON bundle plus a human-readable PDF of every record where the named subject’s email or user id appears, plus the audit events keyed to those records.

Article 16 (rectification). Live records corrigible by principal-side staff with audit trail of every correction. Historical audit events not editable; corrections take the form of a new event citing the prior.

Article 17 (erasure). Erasure is constrained by the SYSC 9 retention exemption under Article 17(3)(b). User-account PII (name, email) is tombstoned at off-boarding (POST /api/users/:id/off-board, principal-admin only, step-up required) by replacing with stable opaque tokens; foreign keys preserved for audit-chain integrity. Substantive supervisory records are retained under the legal-obligation exemption. The principal firm’s response to an erasure request explains this trade-off, citing SYSC 9 and the relevant SUP / DISP provisions.

Article 18 (restriction). Restriction is implemented by PATCH /api/users/:id with restricted: true, hiding the user from list views while preserving in storage.

Article 20 (portability). Portability applies to data the subject provided directly. The AR-user’s MI return submissions, breach reports, and account-profile fields qualify. The export is a JSON document delivered via the same subject-access endpoint.

Article 21 (objection). No marketing or unrelated profiling, so Article 21(2) is not meaningful. Article 21(1) objections to processing on legitimate-interests grounds (the risk score) are addressed via the firm’s DPIA balancing test; an objection that succeeds removes the AR from automated risk-score computation while preserving the substantive records on the legal-obligation basis.

Article 22 (automated decision-making, with the 22A to 22D amendments inserted by the Data (Use and Access) Act 2025). The workspace does not make decisions. Human review is built into every terminal action.

Article 25: data protection by design and by default

The design choices that satisfy Article 25 are documented across this chapter. The structured-only field set, the customer-PII-by-reference posture, the per-tenant RLS, the append-only audit chain, the step-up authentication on terminal actions, and the 7/10-year retention split with tombstoning at off-boarding all flow from this article. The DPIA page provides the formal assessment a firm adapts for its own deployment.

Article 28: processor obligations

The contractual relationship between the principal firm (controller) and the platform operator (processor) is governed by Article 28. The DPA template the operator signs with each principal firm covers:

Processing only on documented instructions from the controller.
Confidentiality commitments on persons authorised to process.
Article 32 security measures (set out in tampering and replay and rate limiting).
Sub-processor authorisation and flow-down, with the named list in sub-processors and a 30-day notification window for additions.
Assistance with subject-rights requests via the operational endpoints set out above.
Assistance with Articles 32 to 36 (security, breach notification, DPIA).
Deletion or return of personal data at end of services (subject to the SYSC 9 retention exemption for in-scope records).
Audit rights for the controller, including the SOC 2 Type II reports the operator commissions annually.

Article 32: security of processing

Technical and organisational measures appropriate to the risk are documented in the safety chapter: TLS, session cookies plus TOTP, Postgres RLS, append-only audit chain, SHA-256 hash linking, rate limiting, step-up authentication on terminal actions, 10-year off-platform durable copy under object lock. These are the Article 32 controls.

Article 33 to 34: breach notification

A personal-data breach (loss, alteration, unauthorised disclosure, unauthorised access) is reported by the platform operator to the affected principal firm within 24 hours of detection. The principal firm assesses and, where the breach is likely to result in a risk to the rights and freedoms of natural persons, notifies the ICO within 72 hours per Article 33. High-risk breaches require notification of affected data subjects per Article 34.

The platform operator’s incident response runbook covers detection, triage, controller notification, and remediation. Personal-data breach is itself a SUP 15.3.20R notifiable event for the principal firm where the data concerns customers.

SYSC 9 retention exemption

UK GDPR Article 5(1)(e) requires data to be kept no longer than necessary. Article 17(3)(b) carves out an exemption where processing is necessary for compliance with a legal obligation in UK law. FCA SYSC 9.1.1R imposes a record-keeping obligation on the firm; the relevant SUP and DISP provisions extend the retention horizon to seven years from the relevant trigger.

The platform’s seven-year retention on substantive records and ten-year retention on audit chain sits inside this exemption. The principal firm’s privacy notice and any erasure-request response explain the position. The retention page sets out the field-by-field schedule.