Data minimisation

UK GDPR Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purposes of the processing. The product holds against this principle in three ways: by limiting the structured fields collected to what supervision actually requires, by treating customer references as case-id strings rather than full identifiers, and by surfacing guidance against pasting special-category data into free-text fields.

What is collected

The exhaustive list of personal-data fields in the v1 surface, by entity:

User

Field	Subject	Reason
email	Principal-side staff or AR-individual	Sign-in identity, notification delivery
displayName	Principal-side staff or AR-individual	Audit attribution, UI presentation
role	Principal-side staff or AR-individual	RBAC scope
arId	AR-individual only	Scopes the AR-user’s reads to their own AR
lastLoginAt	Principal-side staff or AR-individual	Off-boarding cutover
status	Principal-side staff or AR-individual	Lifecycle: invited / active / suspended / off-boarded

No phone number, no address, no date of birth, no employment status, no demographic field. The UI does not request and the schema does not accept these fields in v1.

AppointedRep

Field	Reason
tradingName, legalName	Identification on the FCA Register and in supervisory artefacts
frn	FCA Register reconciliation
registeredOffice	SUP 12 record-keeping requirement
permissions	Scope of regulated activity
status	Lifecycle
appointedOn, lastAnnualReviewAt	Cycle planning
currentRiskScore, currentRiskBand	Risk triage signal
isSelfEmployed, supportsImportantBusinessService	PS22/11 and SYSC 15A flags

The AR is a firm, not an individual. Personal data of AR-individuals lives on the User row keyed by arId.

BreachReport, FileReview, MIReturn, AnnualReview, ConductEvent

These are the substantive supervisory records. Their structured fields are the regulatory artefacts (severity, category, period, metrics, findings, sign-off). Free-text fields exist for description, notes, signOffNotes, evidence, remediation, detail. Free-text policy below.

AuditEvent

Field	Reason
actorUserId, actorRole	Named-actor attribution
ip, userAgent	Repudiation defence
at	Server-assigned timestamp
prevHash, hash	Chain integrity

The IP and user-agent on an audit event are personal data of the actor (the principal-side user or AR-individual who took the action). They are retained for the same 10-year window as the event itself.

What is not collected

The following fields are deliberately excluded in v1, with the reasoning recorded so a future feature request faces the bar:

• Customer full names, dates of birth, addresses, account numbers, phone numbers, email addresses. Customer references in supervisory artefacts are case-id strings or other principal-firm-managed identifiers. The principal firm holds full customer records in its CRM or core system; the workspace references those records, not duplicates them.
• Vulnerable-customer indicators. Out of scope for v1. Documented as a planned post-v1 workflow with explicit Article 9 handling. The firm’s own vulnerable-customer policies operate alongside the workspace.
• Demographic data on AR-individuals or principal-side staff. Not a supervisory signal under SYSC 9 or PS22/11.
• Browser fingerprints, device fingerprints, beacon-style telemetry. Not used for the workspace’s stated purposes.
• Marketing or analytics cookies. None. Detail in PECR and cookies.
• Behavioural profiling of users. No Article 22 automated decision-making and no profiling-for-advertising.

A change to any of the above requires an updated DPIA, an updated sub-processor list (where the change involves a new processor), and a 30-day notice window to principal firms before the field becomes available.

Free-text policy

BreachReport.description, FileReview.notes, FileReviewFinding.evidence, FileReviewFinding.remediation, AnnualReview.signOffNotes, and ConductEvent.detail are free-text. The platform cannot prevent a user from pasting a customer’s full name and date of birth into a free-text field. The policy:

1. UI guidance. Each free-text field carries a hint reading “do not paste customer PII; reference customers by case ID.” The hint is part of the form layout and is visible above the field, not in tooltip-only form.
2. Pre-submit warning. A heuristic check runs on the client before submit: regex matches for date-of-birth shapes (\d{2}/\d{2}/\d{4}), national insurance numbers ([A-Z]{2}\d{6}[A-Z]), and 16-digit card-number-shaped strings raise an inline warning. The user can confirm and proceed; the warning is logged.
3. Server-side scrubbing on read for non-RBAC paths. The Sentry SDK’s beforeSend hook strips known PII shapes from error event payloads. The audit log itself is not scrubbed (it is the evidence layer) but is not transmitted off-platform other than to the durable copy.
4. Periodic spot-check. The principal firm is expected, in its DPIA mitigations and its annual self-assessment, to spot-check free-text fields for special-category data and to retrain users where appropriate.

The free-text fields are necessary because supervision is a narrative activity. A breach description that captures the chronology of a complaint, a file-review note that records the reviewer’s reasoning, and a sign-off note that records the director’s view are all evidence under SYSC 9. Removing the free-text capability would degrade the supervisory record beyond what minimisation requires.

Customer reference posture

When a file review references a specific customer case, the workspace stores caseRef (a string opaque to the workspace, meaningful in the principal firm’s CRM). The principal-side user looks the case up in their CRM if they need the underlying customer record; the workspace does not pull the customer record across.

This means the workspace’s evidential record is incomplete on its own: a regulator inspecting a file review sees the rubric findings, the reviewer’s notes, and the case reference, then resolves the case reference against the firm’s CRM to see the underlying customer file. This is intentional. It reduces the platform’s privacy exposure by an order of magnitude and aligns with the principal firm’s existing customer-data architecture.

Aggregations and analytics

The workspace computes aggregations (composite risk scores, breach activity heatmaps, file review completion rates, network-level KPI tiles). These aggregations are derived from the substantive records and do not introduce new personal data. The aggregations are visible only to authorised users within the tenant (RBAC matrix in threat model).

No platform-operator-side analytics on tenant data. The operator’s product analytics (page views, feature usage) are anonymised at source and do not transmit PII; the implementation is documented in sub-processors under the Vercel observability tooling.

Reviewing minimisation

The firm reviews data minimisation as part of its annual self-assessment under PS22/11. The platform operator publishes a change log of any field additions and runs a 30-day notice window. A field added for an explicit regulatory purpose (a new mandatory MI return metric, for example) is added with the regulatory citation in the change log entry.