Most eligibility products were built for a simple story: send us the data, we tell you the answer. That story is easy to sell and hard to defend when the ICO asks why a whole customer file lived on a vendor's disk for three years after the check completed.
Imagine a council housing team that holds tenant records in a case management system. A new policy requires annual reconfirmation of eligibility for a discount scheme. A vendor offers a cloud API: upload tenant details, receive a score. The DPIA now covers a new processor, a new sub-processor in another country, and a new breach notification path. The question was binary. The data movement was not.
The wrong shape
Traditional hosted checks look like this: your app uploads identity and context, a remote engine scores it, you store the vendor's reference ID. Personal data crossed a boundary twice before anyone got a yes or no.
Why the record should stay
Boundary control. Your DPIA already names your systems. Adding a full copy elsewhere reopens assessment and procurement.
Breach surface. Every extra store is another breach notification path and another access review cycle.
Purpose limitation. The question is narrow. Shipping the whole record overshoots purpose and trains teams to treat PII export as normal.
Minimisation is not a setting you toggle in a dashboard. It is a decision not to copy data you do not need to copy.
What crosses the boundary instead
In a privacy-preserving design, the artefact that leaves your host is small and verifiable: a signed outcome, a timestamp, a policy version, and a method identifier. Verifiers validate the signature. Auditors trace the decision. Nobody needs a second copy of the tenant file to agree the discount applied correctly.
Scenario: annual discount reconfirmation
- Input: fields already in case management (tenancy start, household size, income band).
- Process: prove on council host against published policy.
- Output: signed eligible or not eligible stored beside the case.
- Data sent to vendor: none of the underlying record.
AffixIO is built for prove-on-host: the engine runs where the relationship already lives, and the outside world receives a signed outcome. Start at Product, then read Security and How it Works.
On the host
The prove step
Where AffixIO fits in a privacy-preserving architecture
Privacy-preserving eligibility is a placement decision. AffixIO is the process that reads the record where it already lives and exports only the answer.
- StaysYour record
- Runs hereOn-host prove
- LeavesSigned attribute
It runs on your infrastructure, next to the database or case system that holds the file. It evaluates the policy locally. Nothing in that flow requires shipping the underlying record to AffixIO as a hosted warehouse.
What stays on the host
- The file. Prove-on-host keeps the DPIA boundary you already wrote.
- The fields. Only the inputs the policy names are read. The rest is unused.
- The review path. SDK and API surfaces on Developers are there for security review, not for exporting dossiers.
- The signature keys. Verifiers check outcomes. They do not collect a second copy of the person.
What the gate receives
- Yes, no, or a narrow attribute. That is the purpose limitation in practice.
- A verifiable signature. Traceability without a parallel ID store.
- A smaller breach surface. There is no extra warehouse to patch because you built one.
- Nothing of the record. If a downstream system is copied, the source file was never there.