From DPIA to FRIA to CRA Risk Assessment: One Risk-Assessment Engine for Three EU Regimes

Three EU regimes now ask you to write down what could go wrong, who it hurts and what you did about it. Most firms are building three separate assessment processes to answer what is largely the same question three times.

A regulated product firm shipping into the EU in 2027 can find itself owing three risk assessments for the same system. A data protection impact assessment under GDPR Article 35, because the system processes personal data at scale. A fundamental-rights impact assessment under Article 27 of the AI Act, because the system is high-risk and the deployer is in scope. And a cybersecurity risk assessment under Annex I of the Cyber Resilience Act, because the thing is a product with digital elements. Each has its own template, often its own owner, and — left to run separately — its own version of the truth. That last part is the problem.

The three assessments are the same shape

Read the three provisions side by side and the structural overlap is hard to miss. A DPIA under Article 35(7) must contain a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to the rights and freedoms of natural persons, and the measures envisaged to address those risks. The AI Act’s FRIA under Article 27 asks the deployer to describe the processes in which the high-risk system will be used, the categories of persons likely to be affected, the specific risks of harm to them, the human-oversight measures in place, and what happens when a risk materialises. The CRA requires the manufacturer to perform a cybersecurity risk assessment that identifies the risks to the product and feeds the essential requirements across design, development and maintenance.

Strip the labels and each is the same skeleton: describe the thing and its context, identify who or what is exposed, identify the risks, record the mitigations, keep it current. The vocabularies differ — data subjects, affected persons, product and users — but the underlying record is one asset, one context, one risk register and one set of controls. Maintaining three parallel documents of that shape guarantees they drift. It is the same failure mode I have written about with reconciling DAC8, CARF and CRS reporting: separate pipelines for overlapping obligations do not stay reconciled, they diverge the moment one is updated and the others are not.

Where they genuinely diverge

The engine only works if you are honest about where the regimes are not the same, because those differences are exactly what a supervisor will test. Three matter.

The protected interest differs. A DPIA is concerned with risks to the rights and freedoms of natural persons arising from processing personal data. A FRIA reaches wider, to fundamental rights generally — non-discrimination, dignity, access to services — not only privacy. The CRA assessment protects the security of the product and, through it, its users and networks. A single risk can appear in all three registers, but framed against a different interest each time, and the framing changes the mitigation you record.

The obligated party differs. The DPIA is the controller’s. The CRA risk assessment is the manufacturer’s. The FRIA sits with the deployer, and only certain deployers — public bodies, private providers of public services, and deployers of specific high-risk systems such as creditworthiness and life or health insurance pricing. One organisation can hold all three roles for one system, or only one of them. The engine has to know which role it is speaking in, because that decides which artefact is even owed.

The clock differs. These are not one deadline. CRA reporting obligations under Article 14 apply from 11 September 2026 and the main manufacturer obligations from 11 December 2027. AI Act deployer obligations for high-risk systems, Article 27 among them, land in August 2026. The DPIA obligation has been live since 2018 and must be reviewed when the risk changes. A shared engine does not collapse these into one date; it lets one input change ripple into whichever assessments are affected. The full sequence is worth mapping against the 2026-2028 EU digital-law deadline calendar before you commit an architecture.

One record, three views

The design that holds up is a single canonical assessment record — system, context, affected parties, risks, mitigations, ownership — with a thin projection layer that renders the artefact each regime expects. You capture a risk once, tag it with the interests it touches, and let each view pull the fields that regime cares about. The record below is deliberately minimal; the point is the shape, not the field list.

from dataclasses import dataclass, field
from enum import Enum

class Interest(Enum):          # which protected interest a risk touches
    PRIVACY = "privacy"        # GDPR
    FUNDAMENTAL_RIGHT = "fundamental_right"  # AI Act (incl. privacy)
    PRODUCT_SECURITY = "product_security"    # CRA

@dataclass
class Risk:
    summary: str
    interests: set[Interest]           # a risk can touch more than one
    affected: str                      # data subjects / affected persons / users
    likelihood: str                    # e.g. low / medium / high
    severity: str
    mitigation: str                    # the control, recorded once
    oversight: str = ""                # human-oversight note (FRIA)

@dataclass
class Assessment:
    system: str
    purpose: str                       # systematic description of use
    controller_role: bool = False      # owes a DPIA
    deployer_in_scope: bool = False    # owes a FRIA (Art. 27 categories)
    manufacturer_role: bool = False    # owes a CRA risk assessment
    risks: list[Risk] = field(default_factory=list)

    def view(self, interest: Interest) -> list[Risk]:
        # project the common register onto one regime's protected interest
        return [r for r in self.risks if interest in r.interests]

    def owed(self) -> list[str]:
        # only emit the artefacts this organisation actually owes
        out = []
        if self.controller_role:      out.append("DPIA (GDPR Art. 35)")
        if self.deployer_in_scope:    out.append("FRIA (AI Act Art. 27)")
        if self.manufacturer_role:    out.append("CRA risk assessment (Annex I)")
        return out

The view() projection is the whole idea: the DPIA renders the privacy-tagged risks with necessity and proportionality; the FRIA renders the fundamental-rights risks with the oversight and complaint fields Article 27 asks for; the CRA view renders the product-security risks and feeds the essential-requirements mapping. One control edited in the register updates every view that references it, so the assessments cannot silently disagree about the same mitigation.

Where the collisions actually bite

The overlap is sharpest for AI-enabled products, where the CRA and the AI Act land on the same object and their assessments have to be reconciled rather than run in ignorance of each other — a problem worth taking on its own terms, as I have set out on where the CRA and AI Act assessments collide. The engine helps here precisely because it forces one description of the system that both regimes read from. And it keeps the CRA side honest: the Annex I assessment is a live, risk-based exercise, not a form, a point I have laboured over in reading CRA Annex I as a risk assessment rather than a checklist.

What a shared engine does not do is decide scope for you. It will not tell you whether you are a deployer in an Article 27 category, or whether your product falls into a CRA importance class. Those are legal determinations that gate whether an artefact is owed at all, and they belong at the top of the record as deliberate flags, not as inferences the code makes. Get the flag wrong and the engine will confidently emit — or omit — the wrong document.

The prize is not fewer assessments. You still owe every one you are obliged to produce, and each must stand on its own when a supervisor, a notified body and a data protection authority ask separately. The prize is that they are reconcilable — three views of one defensible record, rather than three documents that happened to describe the same system on three different days and no longer quite agree. Build three templates and you are budgeting, from day one, for the day they contradict each other in front of someone entitled to ask why.