The Digital Services Act did something quietly radical. It took risk assessment, which most compliance regimes treat as a document, and attached it to an audit that has to be redone every year at the platform's own expense.
That pairing exposes a structural fact the compliance industry has spent a decade avoiding.
A risk assessment is not a report. It is a claim about the current state of a system. And the DSA governs systems that change weekly.
The annual systemic-risk assessment is not too demanding. It is the wrong unit of work. The DSA is the clearest illustration yet of a category shift that applies far beyond very large platforms: the durable form of a risk assessment is a continuous query over a source-grounded obligation graph, not a point-in-time snapshot you defend once and re-mint twelve months later.
What does the DSA actually require VLOPs to assess, and how often?
Start with the letter of it, because the letter is where the structural pressure lives.
The DSA requires very large online platforms and very large online search engines to diligently identify, analyse and assess any systemic risks in the Union stemming from the design or functioning of their service. It groups those systemic risks into four categories: the dissemination of illegal content, negative effects on fundamental rights, effects on civic discourse and electoral processes and public security, and effects on gender-based violence, the protection of minors, public health, and serious consequences to physical and mental well-being.
Then comes the cadence clause that most summaries skip.
The assessment is required at least once every year. But it is also required, in any event, prior to deploying functionalities that are likely to have a critical impact on the risks identified.
Read that second trigger carefully. The DSA already tells you the annual cadence is a floor, not the real obligation. The real obligation is event-driven. Ship a new recommender behavior, a new ad format, a new minors-facing feature, and the assessment is due again regardless of where you are in the calendar.
The mitigation duty inherits the same shape. Platforms must put in place reasonable, proportionate and effective mitigation measures, tailored to the specific systemic risks identified. Mitigation is defined by reference to the assessment. When the assessment moves, the mitigation obligation moves with it.
So the DSA's own text describes a living system. The annual report is just the moment that system is forced to hold still long enough to be photographed.
Why does a once-a-year systemic-risk report break the moment the platform changes?
Here is the mechanism, not the complaint.
A point-in-time assessment encodes three things at the instant it is written:
→ the state of the product → the state of the risk landscape → the state of the law
All three drift. The product drifts fastest. A platform at VLOP scale ships continuously, and every meaningful change to design, ranking, or moderation is a change to the exact object Article 34 tells you to assess. The moment engineering merges a feature with critical impact on an identified risk, the report on file describes a system that no longer exists.
This is not a diligence failure. It is a data-model failure. You cannot represent a moving quantity with a static artifact and expect it to stay true.
The industry's usual patch is cadence. Assess quarterly instead of annually. Assess monthly. But shrinking the interval does not fix the model, it just makes the snapshots blurrier and more expensive. You are still photographing a river and filing the photograph as if it were the river.
The DSA's event trigger is the tell. A regulator that writes "and in any event prior to deploying functionalities that are likely to have a critical impact" has already conceded that the annual boundary is arbitrary. The obligation is continuous. The annual report is a reporting artifact bolted onto a continuous obligation, and the gap between those two things is exactly where VLOP enforcement risk accumulates.
When enforcement arrives, the question is never "did you file a report." It is "was your posture accurate on the day the harm occurred." A snapshot cannot answer that question for any day except the one it was taken.
How is the DSA's independent-audit regime really an obligation-mapping problem?
The audit is where the snapshot model gets most expensive, and where its real nature becomes visible.
The DSA subjects VLOPs, at their own expense and at least once a year, to independent audits to assess compliance with the obligations set out in Chapter III. The independence bar is deliberately steep. Auditors must have no conflicts of interest, must not have provided non-audit services to the platform in the preceding twelve months, and must not be paid contingent on the result.
Sit with what that auditor is actually doing. They are not admiring your report. They are testing whether each obligation in Chapter III is met by evidence, and whether your assessment maps to the real design and functioning of the service.
That is an obligation-mapping exercise. Every audit question is of the form: this specific obligation, from this specific provision, is discharged by this specific evidence, as of this specific date.
A prose report is a terrible substrate for that exercise. It bundles dozens of obligations into narrative paragraphs, forces the auditor to reverse-engineer which sentence answers which duty, and offers no way to show that a given claim traces back to the actual legal text rather than to a compliance writer's paraphrase.
The independent auditor is, functionally, running a query against your obligation graph. If you do not have an obligation graph, they build one by hand from your documents, bill you for the reconstruction, and every reconstruction is a fresh chance for a finding.
The audit is not testing whether you wrote well. It is testing whether your obligations are individually addressable, individually evidenced, and individually traceable to source. The unit of compliance was never the report. It was always the obligation.
What happens when the same platform faces DSA, GDPR, AI Act, and NIS2 at once?
Now widen the lens, because no VLOP is only a VLOP.
The same platform is a data controller under the GDPR. If it deploys recommender or generative systems, it is a provider or deployer under the AI Act. If it operates critical digital infrastructure, it sits inside NIS2. Each regime demands its own risk assessment, its own governance evidence, its own periodic review.
Look at what those four regimes actually ask about, and the redundancy is severe. DSA systemic-risk assessment on recommender design overlaps with AI Act risk management for the same system. GDPR data protection impact assessments cover much of the fundamental-rights surface the DSA names explicitly. NIS2 security-risk management touches the same infrastructure the DSA calls the functioning of the service.
The obligations differ. The underlying facts do not. One recommender system generates evidence that four regulators want to see, each through its own vocabulary.
The snapshot model forces you to answer the same factual question four times, in four documents, on four review cycles, with four sets of drift. When the platform changes, all four go stale independently. You are now maintaining four out-of-date pictures of one system, and cross-framework compliance degenerates into reconciling four narratives that were never designed to agree.
This is the real cost, and it is structural. It does not come from the volume of regulation. It comes from modeling each regulation as a separate document instead of modeling the platform once and mapping it to every framework that touches it.
Answer once. Assess everything. That is not a slogan about convenience. It is the only data model in which four overlapping regimes stay mutually consistent as the underlying system moves.
Why treat risk assessment as a continuous query instead of an annual project?
Invert the whole thing.
Stop treating the risk assessment as an artifact you produce. Treat it as a query you run.
The inputs are already continuous. Your product state lives in your systems. The regulatory obligations are fixed text, updated when the law updates. The evidence that connects them is generated by your operations every day. A risk assessment is just the current answer to a standing question: given the platform as it exists right now, which obligations apply, and which are met.
When you model it that way, three things change:
→ The assessment is never stale, because it is computed on read, not written on a schedule → A product change updates the answer automatically, because the change is an input, not a separate reassessment project → The annual report becomes a rendering of the query on a given date, not a bespoke effort
This is the difference between a photograph and a live view. The DSA's annual filing does not go away. But it stops being the work. It becomes a timestamped snapshot of a continuous state you were maintaining anyway, which is exactly what the regulator wanted when they wrote the event trigger into Article 34.
Continuous risk assessment is not "assess more often." It is a different noun. The output is a queryable posture, and the audit pack is a query, not a project.
See how continuous compliance changes the unit of work.
How does source-grounded obligation mapping survive an independent DSA audit?
The continuous model only holds up under audit if every node in it is traceable. This is where source-grounding stops being a nice property and becomes the load-bearing one.
An independent DSA auditor, barred from having helped you write any of this, is going to test individual obligations against individual evidence. The strongest possible answer to any of their questions is a chain they can walk without trusting you:
→ this obligation → traced to a verbatim quote from the legal text → mapped to this canonical requirement → satisfied by this evidence → as of this timestamp
That is what source-grounded obligation mapping produces. Every obligation traced to a verbatim quote from the legal text, not to a paraphrase a vendor's model invented. No AI hallucinations, because the system is not asked to remember the law, it is asked to map to text it can cite.
The distinction matters most precisely at audit. A paraphrased obligation is a claim the auditor has to verify against the real regulation themselves. A source-grounded obligation is a claim that carries its own citation. One creates audit work. The other closes it.
This is also what makes cross-framework mapping honest. When a single piece of evidence is claimed to satisfy a DSA duty and an AI Act duty, an auditor can check whether both citations actually say what the mapping claims. Source-grounding is the only mechanism that keeps a one-to-many obligation map from becoming a one-to-many overreach.
A posture you can defend in front of a regulator, a board, or a plaintiff is not a posture that sounds confident. It is one where every assertion terminates in a quote from the instrument that created the obligation. That is the standard an independent audit imposes, and it is the standard a snapshot document almost never meets.
Aegis maps 245+ regulations across 28 jurisdictions this way, which is what makes the DSA's four systemic-risk categories a subset of a graph rather than a standalone project. Regulatory intelligence is the part that keeps the obligation text current as the instruments themselves change.
What should a VLOP or aspiring platform operationalize before the next audit cycle?
Concrete steps, in the order that reduces risk fastest.
First, decompose the report into obligations. Whatever your current DSA risk assessment is, break it into individually addressable duties. Each duty needs its own owner, its own evidence, and its own trace to source text. This is the change that makes an independent audit tractable, because it turns one narrative into a checklist the auditor can run.
Second, make product change an input, not a trigger for a project. The Article 34 event clause means a feature with critical impact reopens the assessment. If reopening means commissioning a new report, you will always be late. If it means the feature flows into a standing query, you are already current when the auditor arrives.
Third, map once across frameworks. Before you build a DSA process, a GDPR process, and an AI Act process in parallel, model the platform once and attach the frameworks to it. The overlap between these regimes is large enough that separate pipelines are pure waste, and the drift between them is a finding waiting to happen.
Fourth, ground everything in source. Every obligation you track should carry the verbatim quote it comes from. Do this before the audit, not during it, because during the audit it is the auditor's billable hour instead of your prepared record.
Fifth, treat the annual filing as a render, not a rebuild. When the underlying posture is continuous and source-grounded, the DSA's yearly report and its three-month public disclosure become outputs of a query you already maintain, not a season of work you dread.
The platforms that will handle the next audit cycle cheaply are not the ones with better report writers. They are the ones that stopped producing reports and started maintaining a graph. Risk assessment as a continuous query is the operational form of that shift.
FAQ: DSA systemic-risk assessment, audits, and enforcement
How often does the DSA actually require a systemic-risk assessment?
At least once a year is the floor. The binding trigger is event-driven: the DSA also requires assessment prior to deploying functionalities likely to have a critical impact on the risks already identified. In practice a platform that ships continuously has a continuous obligation, and the annual date is only the moment it is forced to publish.
Can an incumbent GRC platform's stored report satisfy an independent DSA audit?
A stored report satisfies the filing, not the audit. The independent auditor tests individual Chapter III obligations against individual evidence as of specific dates, and they are barred from having helped produce your materials. A prose report forces them to reconstruct the obligation map by hand. A source-grounded, queryable obligation graph gives them the map directly, with each duty traced to the legal text.
How does treating the DSA as one framework among many reduce VLOP enforcement risk?
Because the same platform is simultaneously governed by the GDPR, the AI Act, and NIS2, and those regimes ask about the same underlying facts in different vocabularies. Modeling the platform once and mapping it to every applicable framework keeps the four assessments mutually consistent as the system changes. Four separately maintained reports drift apart, and the gaps between them are exactly what enforcement finds.
What does "source-grounded" mean and why does it matter at audit?
It means every obligation is traced to a verbatim quote from the legal text rather than to a model-generated paraphrase. At audit this is the difference between a claim the auditor must independently verify and a claim that carries its own citation. It is also what prevents a cross-framework mapping from overstating what a single piece of evidence actually covers.
Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.
