EU compliance, explained
Practitioner-grade articles on CRA, NIS2, AI Act, DORA, RED. Written by NexCyber regulatory engineering. Open access — no gate, no sign-up required.
DORA and NIS2: running one compliance programme when both apply
A financial entity can be regulated under both DORA and NIS2 simultaneously — DORA as a financial entity under Regulation (EU) 2022/2554, and NIS2 as an essential entity in the banking or financial market infrastructure sector under Directive (EU) 2022/2555. W
Read articleSBOM under the Cyber Resilience Act: format, depth, signing, and update cadence
CRA Annex I requires a machine-readable SBOM for every product with digital elements. Learn format requirements, depth, signing, update cadence, and procurement leverage.
Read articleRED Article 3(3): cybersecurity requirements for IoT and radio equipment from August 2025
RED Article 3(3)(d)(e)(f) cybersecurity for IoT and radio equipment is in force from 1 August 2025. Learn scope, ETSI EN 303 645 compliance path, and CRA overlap strategy.
Read articleNIS2 implementation guide: 8 steps for essential and important entities
NIS2 is in force. Essential and important entities must comply now. This guide covers the 8 implementation steps: scope confirmation, risk assessment, Article 21 measures, and incident notification.
Read articleNIS2 and CRA: what overlaps, what doesn't, and how to manage both
NIS2 and CRA share 6 core obligations. Learn how to run one compliance programme for both regulations, which obligations overlap, and where they diverge.
Read articleDORA TLPT: threat-led penetration testing requirements for financial entities
DORA requires significant financial entities to conduct TLPT every 3 years. Learn scope, TIBER-EU alignment, tester requirements, and how TLPT results feed your ICT risk framework.
Read articleCRA Article 14: the vulnerability reporting workflow manufacturers need by September 2026
CRA Article 14 requires manufacturers to notify ENISA of actively exploited vulnerabilities within 24 hours. Learn the full 24h/72h/14-day workflow and what must be operational by 11 September 2026.
Read articleCRA penalties: maximum fines, violation tiers, and how exposure is calculated
CRA penalties reach €15M or 2.5% of global turnover for essential requirement violations. Learn the three penalty tiers, what triggers each, and how to calculate your maximum exposure.
Read articleAudit-ready evidence for CRA: what to prepare and how to structure it
CRA requires technical documentation, SBOM, CVD policy, and a vulnerability log. Learn what evidence auditors and market surveillance authorities expect and how to structure it.
Read articleAI Act Article 5: prohibited AI practices in force since February 2025
AI Act Article 5 prohibited AI practices have been in force since 2 February 2025. Learn the 8 banned use cases, the penalties, and what counts as a prohibited system.
Read articleAI Act and CRA: what overlaps for AI products with digital elements
AI systems that are also products with digital elements must comply with both the AI Act and CRA. Learn where obligations overlap, where they diverge, and how to run one programme.
Read articleBuilding a defensible evidence trail
A trail that connects obligation to control to proof is what makes compliance defensible.
Read articleWhat an auditor actually checks
A short list of the questions behind most audit findings — and how to pass them.
Read articleWhat is a Trust Passport ?
A shareable, verifiable view of your product's compliance posture — what it carries and who it is for.
Read articleWhat is an MRCC ?
The Machine-Readable Compliance Certificate — what it attests, what it does not, and how it is verified.
Read articleKeeping documentation audit-ready
Audit-ready is a state, not a sprint — how to keep documentation continuously presentable.
Read articlePreparing for a cybersecurity audit
What auditors look for and how to walk in with evidence already organised.
Read articleSetting a sustainable update cadence
How often to ship security updates and how to balance routine and emergency releases.
Read articlePost-market monitoring
Conformity is continuous — how to monitor a product in the field and feed findings back.
Read articleHandling an actively exploited vulnerability
An exploited vulnerability is the highest-pressure case — a calm, evidenced response protects users and compliance.
Read articleNIS2 incident reporting: the 24-hour, 72-hour and one-month sequence
NIS2 Article 23 requires essential and important entities to report a significant incident in three stages: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month of the notificat
Read articleCRA incident reporting: the obligation that binds fifteen months early
Article 14 of the Cyber Resilience Act applies from 11 September 2026. The rest of the regulation applies from 11 December 2027.
Read articleAssembling the technical documentation pack
The CRA requires technical documentation — what goes in the pack and how to keep it audit-ready.
Read articleKeeping evidence fresh
Evidence decays — why freshness matters and how to avoid a readiness drop at the worst moment.
Read articleUsing third-party attestations
When an external attestation is worth obtaining and how it strengthens your evidence base.
Read articleMapping evidence to obligations
Evidence only counts when it is tied to the obligation it satisfies — how to map cleanly.
Read articleEvidence admissibility and grades
Why two products with the same uploads can have very different readiness — admissibility explained.
Read articleWhat counts as evidence
Compliance is proven, not asserted — what qualifies as evidence and how it is graded.
Read articlePrioritising gaps by risk and deadline
Not all gaps are equal — a simple way to decide what to fix first.
Read articleBuilding a remediation plan that survives an audit
A remediation plan is your roadmap and your evidence of intent — how to make it credible.
Read articleOne evidence set, several regulations: what actually maps and what doesn't
Most organisations facing more than one EU cybersecurity regulation build a separate programme for each, and produce the same artefacts several times over. They do not need to. The regulations were drafted at different times for different purposes, but they co
Read articleWhat your readiness score means
How readiness is calculated, why evidence affects it, and how to move it in the right direction.
Read articleReading a gap analysis
How to interpret gaps, prioritise them and turn them into a credible remediation plan.
Read articleScoping your product correctly
Good scoping makes the rest of compliance tractable — how to define the product boundary and context.
Read articleHow a NexCyber assessment works
From product profile to a readiness result — what the deterministic assessment does and how to read it.
Read articleLogging and monitoring for resilience
What to log and monitor so you can detect, report and prove handling of security events.
Read articleEmbedding security in your SDLC
Where security controls fit across the development lifecycle so conformity is a by-product, not a project.
Read articleThreat modelling basics
A lightweight approach to threat modelling that fits real engineering teams.
Read articleRunning a product cybersecurity risk assessment
A repeatable method to assess and document product risk — the analytical core of CRA technical documentation.
Read articleDefining a security update and support period
The CRA expects security updates over a defined support period — how to set and communicate yours.
Read articleCoordinated vulnerability disclosure (CVD)
How to receive and handle externally reported vulnerabilities responsibly and to expectation.
Read articleStanding up a vulnerability-handling process
The CRA requires a process to find, triage and fix vulnerabilities — here is a workable shape.
Read articleHow to build and maintain an SBOM
A software bill of materials is the backbone of vulnerability handling — how to produce one and keep it useful.
Read articleSecure-by-default configuration
Why default settings matter for conformity and what 'secure by default' actually requires.
Read articleSecure-by-design in practice
Turning the secure-by-design principle into concrete engineering practices you can evidence.
Read articleCE marking for products with digital elements
What CE marking means under the CRA, what must be in place before you affix it, and the declaration of conformity.
Read articleImportant or critical: what CRA Annex III and Annex IV actually change
The Cyber Resilience Act sorts products with digital elements into three groups, and the group decides how you are allowed to prove conformity — not what the security requirements are.
Read articleWhat counts as a product with digital elements under the CRA
A product with digital elements is a software or hardware product — and its remote data processing solutions — whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.
Read articleThe GDPR security baseline: what Article 32 requires, and what it deliberately does not say
GDPR Article 32 requires controllers and processors to implement technical and organisational measures ensuring a level of security appropriate to the risk. It deliberately prescribes no checklist — the standard is contextual, judged against the state of the a
Read articleWhat is RED Article 3(3): the cybersecurity rules already binding on connected devices
RED Article 3(3) is the part of the Radio Equipment Directive (2014/53/EU) that lets the Commission activate additional essential requirements. Delegated Regulation (EU) 2022/30 activated three of them — points (d), (e) and (f) — for internet-connected radio e
Read articleWhat is DORA: scope, the five pillars, and what it actually requires
DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — is the EU's single rulebook for how financial entities manage information and communication technology risk. It applies from 17 January 2025.
Read articleWhat is the EU AI Act: four risk tiers, six roles, and a staggered calendar
The AI Act — Regulation (EU) 2024/1689 — is the first comprehensive law governing artificial intelligence systems. It entered into force on 1 August 2024 and applies in phases, not all at once.
Read articleWhat is NIS2: who it covers, the ten measures, and why the board is named
NIS2 — Directive (EU) 2022/2555 — is the EU's baseline cybersecurity law for organisations that operate critical or important services. It replaced the 2016 NIS Directive and had to be transposed into national law by 17 October 2024.
Read articleWhat is the Cyber Resilience Act: scope, obligations, and the dates that bind
The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first EU law to impose cybersecurity requirements on products themselves, as a condition of placing them on the EU market. It entered into force on 10 December 2024.
Read articleSBOM vs Evidence vs MRCC — what's the difference ?
Three artifacts often confused. We clarify the SBOM (technical inventory), Evidence (audit trail), and the MRCC (machine-readable readiness attestation).
Read articleEssential or important under NIS2: same duties, different supervision
NIS2 sorts in-scope organisations into essential and important entities. The classification is decided by two things only: which annex your sector is in, and how big you are.
Read articleAI Act risk tiers: how a system is classified, and why the model is not the answer
The AI Act sets four tiers. The tier attaches to the system in its context of use, not to the underlying model.
Read articleDORA ICT third-party risk: the register, the contracts, and the oversight regime
DORA Articles 28 to 30 require every in-scope financial entity to know exactly which technology providers it depends on, to record those dependencies in a register of information, to assess concentration risk before signing, and to include a prescribed set of
Read articleRED cybersecurity requirements — what changed
The Radio Equipment Directive's cybersecurity provisions, the EN 18031 harmonised-standards series, and CE-marking implications for connected radio products.
Read articleThe Evidence Trust Layer — proving compliance, not just claiming it
Why verifiable, current evidence — not assertions — is the foundation of a trustworthy readiness attestation.
Read articlePost-launch compliance : obligations don't stop at CE marking
Vulnerability handling, incident reporting, substantial-modification triggers, and when a readiness attestation should be re-issued.
Read article