Data protection impact assessment

Controller: SiteLens, a trading name of Alcyone AI Ltd, company 17060294 (England and Wales). Contact: privacy@sitelens.co.uk.

Version 1.0, 17 August 2026. Published at https://sitelens.co.uk/trust/.

Why a DPIA is mandatory here

Not "advisable". Article 35(1) requires one where processing is likely to result in a high risk, and the ICO's own list of processing requiring a DPIA is triggered twice over by what we do:

1. Data matching. We combine planning register data with Companies House, Land Registry, EPC, procurement notices and firm websites to build a joined view that none of those sources publishes on its own.
2. Invisible processing. The ICO's listed examples of invisible processing include the re-use of publicly available data, which is exactly our input. The people concerned did not give us their data and would not know we hold it unless we told them, which is why the Article 14 notice is load-bearing rather than decorative.

Either limb alone would require this. Both together, at the scale of a nightly pass over several hundred council portals, remove any argument that it is optional.

What is processed

Authoritative detail is in src/lib/data-class-register.ts and the generated Article 30 record; this section is the summary a reader needs to follow the risk analysis.

Volume context: several hundred council portals scraped nightly; applicant email exists on roughly 1.24% of applications.

Necessity and proportionality

Covered in the legitimate interests assessment (docs/legitimate-interests-assessment.md), which is the companion document to this one and states the purpose, the necessity argument and the balance. This DPIA addresses risk and mitigation.

Risks, and what actually mitigates each

Each risk is stated with the mechanism that reduces it and an honest residual. Where the mitigation is code, the file is named, because a DPIA whose mitigations cannot be pointed at is a wish list.

R1. A private individual's contact details are served to a customer who then markets to them

Severity: high. This is the risk that carries a PECR fine, and it lands on the sender rather than on us, which means our customer, which means our problem commercially and reputationally even where it is not ours legally.

Mitigations. The serving decision is one function (src/lib/serving-gate.ts), and the business-versus-individual question is decided by positive evidence of a firm rather than by a salutation, so an untitled "John Smith" is redacted. Applicant electronic channels additionally require a Companies House match AND a published name that reads as a business, with unknown resolving to redact (amended 2026-09-07: a second corroborating signal was previously required and was removed as unobtainable rather than protective, see docs/applicant-gate-minimum-2026-09-07.md). The presence flag that drives search and the digest embeds the identical predicate, so a surface cannot advertise a channel the response strips.

Residual: medium, raised from medium-low on 2026-09-07. The corporate test is a proxy and now rests on two predicates rather than three. A sole trader trading under a company name passes on a Companies House match and a business-shaped name alone, with no corroborating mailbox or landline, and would be an individual subscriber for reg 22 purposes. The same change leaves 472 served rows carrying a UK mobile, 157 of them as the only channel, where the removed landline test had been the only thing distinguishing those. We accept that residual because the alternative tested worse: redacting every applicant channel, which we did briefly, was a permanent over-restriction that also stopped us serving plainly corporate applicants.

R2. A person does not know we hold their data

Severity: high, and it is the risk *Experian* actually turned on.

Mitigations. An Article 14 notice at ingest, per person, carrying the source and whether it was public, the retention period, the recipient categories, the Article 14(2)(da) complaint right and, presented separately per Article 21(4), the objection right. Sent on an isolated identity so a notice pause cannot take down customer email, and recorded per address with the version of the copy sent.

Residual: medium. Two known gaps, both stated rather than smoothed over. The notice worklist requires a verified address, so a person whose address we never verified is not notified; that is a deliberate choice to protect the sending identity every other notice depends on, and it means "everyone is notified" is not true today. And the notice reaches an inbox, which is not proof of reading.

R3. An objection is not honoured, or is undone

Severity: high. Article 21(2) and (3) make it absolute, and a re-acquisition after suppression would be the clearest possible failure.

Mitigations. A never-expiring objection link needing no account. Suppression records are permanent by design and keyed on normalised identity rather than a display string, so a firm cannot return under a different spelling. The suppression is checked before re-enrichment, not only at serving. Proof of notice is retained through a suppression event with the address hashed, so we can still show what we sent without keeping the identifier.

Residual: low.

R4. Entitlement lags, so a cancelled customer keeps seeing contact data

Severity: medium.

Mitigation. Entitlement is resolved against the database on every request rather than from the JWT claim, so a cancellation takes effect immediately rather than at the end of the token window.

Residual: low.

R5. A processor mishandles data we sent them

Severity: medium. Twenty-three recipients, of which three are email verification providers outside the UK, and five are web search services, four publishing a United States location and one publishing none, that receive a firm's or supplier's name as a search query. Eight more were declared later the same day after every outbound call carrying a name, an address or a typed query was traced: two contact-data providers in the United States that receive a company director's name and the firm's web domain, only when a subscriber asks for a firm's contacts; four register lookups (Companies House and three professional and charity directories) that receive a firm's or applicant's name; a web-fetching service in Ireland that retrieves public council pages and firm websites and sees them in full; and the OpenStreetMap geocoder, which receives places customers type into search. All thirteen were declared on 2026-09-30 and had been receiving data before they were listed, which is itself the failure this risk describes. One is Stannp, the letter vendor, which would print and post in the UK for a letter feature that is not yet offered (see R7). It runs in Stannp's test mode, which posts nothing, but a test request carries the same fields as a live one and test requests made with real rows have already reached Stannp. It receives the applicant name, the site address and the letter body, which is the customer's own text. The postal path never selects the applicant's email address or telephone number. Printing would be in the UK; storage is in the EEA/EU under Stannp's DPA s.7.

Mitigations. The recipient list is in src/lib/subprocessors.ts and generated into the Article 30 record, so it cannot drift from what we tell people. The verification rotation was cut from sixteen providers to three specifically so the list could be stated honestly in a notice, and an unapproved provider is rejected in code rather than by convention. Verification providers receive an address and return a verdict; they receive no name, no scheme and no context.

Residual: medium. Three providers process in the United States under the UK Addendum to the EU SCCs. That is a real transfer risk that contract terms mitigate rather than remove.

R6. Scale of collection outruns the controls

Severity: medium, and it is the risk this codebase has actually realised more than once.

Mitigation. The class register plus a CI intake gate: a column that names, contacts or locates a person cannot merge without a recorded decision about its class, source, licence, basis and retention. Many separate changes add columns to this schema, and without the gate each would invent its own answer and the disagreement would be invisible because nothing fails.

Residual: low for new columns, medium for historical rows. Three row sweeps are outstanding at the time of writing (email open IP and user agent, and outreach free text on two tables). Until they run, the posture claim is true of new rows and not of the whole history. That is stated plainly here because a DPIA that omits its own backlog is worse than no DPIA.

R7. Data is used for a purpose we said it would not be

Severity: high, because it is the failure mode that would make every other statement in these documents untrue.

Mitigations. There is no dialler, template store, reply capture, contacted flag or audience builder, and adding one is a standing prohibition rather than a roadmap decision.

Amended 2026-08-23: a POSTAL send path is built but not offered. It runs in Stannp's test mode and dispatches nothing, and no customer can send a letter today. When it goes live, a printed letter to the applicant at the application site is fulfilled by Stannp under an Article 28 processor agreement. The prohibition that actually matters is unchanged and is now narrower and more precisely stated: no ELECTRONIC send path, because reg 22 covers electronic mail and post sits outside PECR entirely. The postal path carries no email address and no telephone number by construction, the customer chooses the recipient and writes the copy, every letter carries an Article 14 notice clause, and an objection suppresses the recipient across every customer and on the CSV export as well. The in-product CRM this risk is really about is still not built.

The CCOD licence forbids direct marketing use, and that restriction is encoded: CI fails if a CCOD-sourced class is given an electronic channel or an export. Case officer and tender buyer contacts are stored and shown on the record and are never placed in an export, a bulk shape or the reveal meter.

Residual: low technically, medium organisationally. The controls are code; the prohibition on building a CRM is a decision, and the DPIA's own note is that an in-product CRM will be the most tempting roadmap item we are ever offered.

Consultation

No DPO is appointed; the controller is a single founder and the threshold in Article 37 is not met. No data subject consultation has been carried out. The proxy used instead is the objection and complaint routes, whose volume and content are the feedback channel, and which are now recorded rather than only offered.

Outcome

The processing may proceed on the basis set out here. No residual risk is assessed as high after mitigation. The two items most likely to change that conclusion are the outstanding row sweeps (R6) and the unverified-address gap in the notice programme (R2), and both are named above rather than closed.

Review

Reviewed on any change to the class register, on any new recipient, and otherwise annually. Next scheduled review: 17 August 2027.