Data protection risk,on the record.

Most data protection impact assessments live as standalone Word documents - written once, filed, and forgotten. They capture intent on a single day, but rarely connect to the suppliers, systems and processing activities that actually create the risk. When the ICO asks what assessments exist and whether they are current, there is no register to point to.

E2ERisk turns the DPIA from a document into a live record. Screening triggers when processing appears high-risk under UK GDPR Article 35; risk is plotted on a likelihood-by-severity matrix; and every assessment is linked to the vendors, assets and ROPA entries behind it - so privacy risk and supplier risk stop living in separate worlds, and your DPO can produce a defensible, regulator-ready record on demand.

Built for UK public-sector data protection - customer-tenant deployment, UK data residency and an append-only audit trail. See the security model →

The reason most DPIAs add so little is that they sit apart from everything that creates the risk. A processing activity is described in one place, the supplier behind it recorded in another, and the technical controls in a third - so no single view ever shows whether the risk has actually been mitigated.

E2ERisk builds the DPIA on the same model as your suppliers, assets and processing records. Screening, risk scoring, mitigations and sign-off all reference the real entities behind the processing, so the assessment stays connected to the thing it is assessing.

Every identified risk is scored on the same likelihood-by-severity matrix your risk team already uses, rather than buried in narrative paragraphs. High-risk processing surfaces immediately, and each mitigation moves a risk towards an explicit residual position.

That makes the DPIA a working risk assessment rather than a compliance write-up - the DPO can see which processing activities still carry unacceptable residual risk, and where ICO consultation may be required.

When DPIAs live as standalone documents, the first problem is simply the register: nobody can say with confidence how many assessments exist, which are current, or which high-risk processing was never screened at all - yet the ICO expects a controller to produce exactly that picture on demand.

The deeper problem is disconnection. A supplier is onboarded, a new processing activity begins, and the DPIA that should have been triggered never is - because nothing links the supplier record to the screening step.

The assessment follows the ICO's own sequence - from the screening test that decides whether a DPIA is required at all, through necessity and proportionality, to formal DPO sign-off and, where residual risk stays high, consultation with the regulator.

Because each stage is a step in the platform rather than a heading in a document, nothing gets skipped: a processing activity cannot reach sign-off without a screening decision, a risk score and recorded mitigations behind it.

A generic privacy form asks generic questions. The ICO's DPIA template asks specific ones - about necessity, proportionality and the rights of data subjects - and an assessor expects to see answers in that shape. The comparison below shows what changes when the register is built for the regime rather than adapted to it.

The result is an assessment structured in the way the ICO expects, with the supplier and asset context behind every risk - not a tracker that records a DPIA was done, but the DPIA itself.

A single high-risk processing activity rarely touches just one obligation. The same assessment has to answer UK GDPR Article 35, the DPA 2018's high-risk provisions and the ICO's template - and, for suppliers, sit alongside Article 28 processor terms and Article 32 security measures.

E2ERisk maps one set of answers to all of them, so a DPIA written once becomes evidence against every framework that asks the same underlying question.

The point of putting the DPIA on the platform is what it lets you produce when asked. The assessment is aligned to UK GDPR Article 35 and the ICO template, linked to your Article 30 record of processing, and carries a built-in DPO sign-off - so a regulator request becomes an export, not a project.

Three things come out of the register, each in a form a regulator or a board already understands: the register itself, the risk picture behind it, and the per-DPIA report in the ICO's own structure.

One body of data protection evidence, mapped to every obligation a UK public-sector controller answers to - so the answer you give one framework holds up for the rest.