What Trusq monitors
Trusq follows the official EU sources themselves — the Official Journal on EUR-Lex, the European Commission's digital-strategy publications, the European Data Protection Board, ENISA and the Court of Justice of the EU — not newsletters, aggregators or news noise. If it is not traceable to an official source, it does not enter the record.
This is the actual source register the engine polls — see per-source check times on what Trusq monitors.
What kinds of change Trusq detects
Every published update carries one of five types — the same taxonomy you see on the updates feed:
Regulatory change
New or amended law: regulations, directives, and the delegated and implementing acts that make them concrete.
Deadline
Application dates and reporting deadlines — including when an agreed change moves a date your programme was built around.
Guidance
Official guidance, codes of practice and templates that say how regulators expect the rules to be applied.
Case law
Court rulings — above all the CJEU — that change what the law means in practice.
Enforcement
Supervisory decisions, designations and infringement actions that show how the rules are actually enforced.
How a change becomes an action
01
An official source changes
A regulation lands in the Official Journal, the Commission issues guidance, a court rules, a supervisor acts. This happens continuously — and mostly outside anyone's weekly source-checking routine.
02
Trusq detects the signal
The monitoring engine polls the source register above on a recurring schedule and logs every check. Detection is automatic; nothing depends on someone happening to read the right page that week.
03
Trusq verifies and classifies it
Every signal is checked against the primary text before anything is published: the document, its reference and its dates. It gets one of the five types, an event date and a verified date — and where the status is provisional, an explicit status note. No source, no publication.
04
Trusq maps it to rules, roles and organisations
A verified change is mapped to the regulations it touches and to who has to act on it — compliance, legal, security, AI-governance and product roles, and the organisation types in scope. In the app, the same change is matched to the AI systems registered against the affected rules.
05
Trusq publishes practical checks, linked to the evidence
The result is an update your team can act on: what changed, why it matters, who is affected, what to check next and the key dates — with the official source and document reference attached, so every conclusion can be verified by you, your counsel or a regulator.
What your team gets out of it
Fewer manual source checks
The recurring “scan five official websites, just in case” routine becomes reading one verified feed.
A clear view of what actually changed
Each update states what changed in plain language, against the document itself — not a headline about it.
Faster internal briefing
Why-it-matters and who-is-affected are pre-written; a team briefing starts from the update instead of from a blank page.
A better handover to specialists
Legal, compliance, security and product teams get the same source-backed record to work from — counsel starts from the evidence, not from a rumour.
Early warning on deadlines and status-sensitive changes
Application dates, reporting clocks and not-yet-adopted agreements are tracked with their status made explicit — so plans move when the law moves, not before.
Support for AI-system and register work
Changes are mapped to affected rules and roles, which is the groundwork for keeping an AI-system register and its evidence current.
What Trusq does not do
- It is not legal advice, and it does not replace your counsel — it hands them a sourced, structured record to advise on.
- It does not certify compliance — no tool can; a competent authority or court always has the final say.
- It does not publish unverified changes — anything that cannot be traced to an official source stays out of the record.
- It does not summarise from a black box — every update links to the official document it reports, so you can check the conclusion against the text.
Three live examples from the feed
Not hypotheticals — these are published updates from the record, with their sources.
Regulatory change7 May 2026
A status-sensitive change, published with its caveat
The provisional agreement of 7 May 2026 moves the AI Act's high-risk deadlines — but a provisional agreement is not law. Trusq published this as a regulatory change with an explicit status note: every deferred date reads “as agreed, subject to formal adoption”, and that caveat stays until the amending regulation is in the Official Journal. The checks separate what stays on the current 2 August 2026 date from what can be re-planned — so nobody re-sequences a compliance programme on a date that is not yet law.
From the published checks
- Keep non-high-risk workstreams on the 2 August 2026 date — the deferral covers the high-risk requirements, not the whole Act
- Identify which of your systems fall in the Annex III track (December 2027) versus the embedded-product track (August 2028) under the agreed text
- Review whether any generative systems you placed on the market before 2 August 2026 rely on the content-marking postponement to 2 December 2026
Regulatory change17 Oct 2024
An implementing regulation, turned into operational checks
Implementing Regulation (EU) 2024/2690 replaces NIS2's open norms with a checkable control annex and numeric incident thresholds for digital-sector entities. Trusq translated the document into source-backed operational checks — am I covered, where are my control gaps against the annex, do my incident thresholds match the regulation's — each traceable to the EUR-Lex text a supervisor would cite.
From the published checks
- Confirm whether your services fall in the covered digital-entity categories
- Map your security controls to the annex's requirement areas and document the gaps
- Compare your incident-classification thresholds to the regulation's significance criteria (financial loss, unavailability durations, user impact, data compromise)
Regulatory change20 Feb 2025
Technical standards, translated into compliance checks
DORA's incident-reporting technical standards fix exact clocks and mandatory templates: an initial notification within 4 hours of classification and no later than 24 hours from awareness, an intermediate report within 72 hours, a final report within one month. Trusq turned that regulatory text into checks an incident-response and compliance team can run against their own playbook.
From the published checks
- Compare your incident playbook's timers to the RTS: 4 hours from major-incident classification and no later than 24 hours from awareness for the initial notification
- Prepare the 72-hour intermediate report flow, including the 'nothing changed' case and the update on recovery
- Confirm the final report can be produced within one month of the (latest) intermediate report
See it working
← How Trusq stays current