Comply guides

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a regulation setting cybersecurity requirements for products with digital elements on the Union market. Article 14 applies from 11 September 2026; full application is 11 December 2027. This page is not legal advice and does not start a clock.

The CRA (Regulation (EU) 2024/2847) names five economic-operator roles — manufacturer, authorised representative, importer, distributor, and open-source software steward — with different Chapter II duties. This page does not classify YOU. It is not legal advice and does not start a clock.

A product with digital elements is a software or hardware product and its remote data processing solutions, including components placed on the market separately (Article 3(1)). Class (default, important I/II, critical) changes the Article 32 path, not Article 71 dates. Not legal advice. Does not start a clock.

Standalone SaaS and cloud services designed outside a manufacturer's responsibility are generally outside the CRA (Regulation (EU) 2024/2847) and may sit under NIS2. A remote data-processing solution integral to a product with digital elements can be in. This page is not legal advice and does not start a clock.

If the CRA applies, Annex I Part II of Regulation (EU) 2024/2847 requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy and a contact address for reporters. That duty is not Article 14. This page is not legal advice and does not start a clock.

Regulation (EU) 2024/2847 Article 13(13): manufacturers keep technical documentation and the EU declaration of conformity for at least 10 years after placing on the market or the support period, whichever is longer. This page is not legal advice and does not start a clock.

A CRA readiness checklist groups Regulation (EU) 2024/2847 duties by area: scope, essential requirements, vulnerability handling, reporting, documentation, and conformity assessment, against Article 71 dates. Article 14 applies from 11 September 2026; full application is 11 December 2027. This page is not legal advice and does not start a clock.

The CRA final report is Article 14's third rung: no later than 14 days after a corrective or mitigating measure is available on the actively-exploited track, or within one month after the 72-hour incident notification on the severe-incident track. Those two deadlines are not one number.

Annex I Part II of Regulation (EU) 2024/2847 sets manufacturer vulnerability-handling duties: document components including an SBOM, remediate without delay, test, a coordinated-disclosure policy, and a contact address. This page is not legal advice and does not start a clock.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers, where it applies, to remediate vulnerabilities without delay, including by security updates, during a support period of at least five years unless expected use is shorter. This page is not legal advice and does not start a clock.

Walk this table: is it an actively exploited vulnerability or a severe incident, are you the responsible manufacturer, has the clock started, which rung is due, and where does it go. This tree is not legal advice and does not start a clock.

Article 64 of Regulation (EU) 2024/2847 sets three administrative-fine ceilings (EUR 15 000 000 or 2,5 %, EUR 10 000 000 or 2 %, EUR 5 000 000 or 1 %). Those are statutory maxima, not typical fines. This page is not legal advice and does not start a clock.

This is an illustrative, fictional Article 14 actively-exploited-vulnerability walkthrough: awareness at T0, a 24-hour early warning, a 72-hour notification, remediation, and a 14-day final report. It is not a real incident, not legal advice, and does not start a clock.

Under the CRA, an 'actively exploited vulnerability' is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Article 3(42)). This page is not legal advice and does not start a clock.

ShipReady Metrics maps signed-in surfaces to Regulation (EU) 2024/2847 Article 14 and Annex I: the CRA reporting ladder, vulnerability intake, SBOM, and evidence collection. It prepares named-reviewer drafts. A named human still submits. This page is not legal advice and does not start a clock.

A vulnerability management program checklist groups the operational building blocks — asset inventory, scan coverage, ownership, remediation SLAs, prioritization signals, exceptions, evidence, and reporting cadence — against named framework sources. Not legal advice; it does not determine that any control, standard, or SLA applies to YOU.

A vulnerability is a weakness in software, configuration, or process. An exploit is code that abuses that weakness. Risk combines exploitability with the value and exposure of the specific asset — the same CVE can be near-zero risk on one system and severe on another.

A CVE is a unique identifier for one publicly disclosed vulnerability. A CWE classifies the type of underlying software weakness — a category, not an instance. A CVSS score rates the severity of a specific vulnerability using a standardized formula. All three come from different programs and answer different questions.

CISA's KEV catalog lists CVEs with reliable evidence of active exploitation. As of last verification, CISA Binding Operational Directive 26-04 (issued 10 June 2026) is current, having revoked BOD 22-01's flat 14-day rule for risk-tiered FCEB timelines. For everyone else, KEV is guidance, not a mandate.

A defensible triage order checks confirmed exploitation (CISA KEV) first, then exploitation probability (FIRST EPSS) and asset exposure, treating CVSS severity as one input, not the sole sort key. CISA's SSVC offers a structured alternative. Not legal advice; it does not determine that any framework applies to YOU.

Severity (CVSS) rates how bad a flaw would be if exploited. Exploitability (EPSS, CISA KEV, CISA/FIRST SSVC) rates whether anyone is actually doing that. A high CVSS score with no exploitation signal is not automatically urgent. This page is not legal advice and does not score YOUR findings.

There is no single legal deadline for every organization. CISA BOD 26-04 (10 June 2026) sets risk-tiered timelines, but only for US federal civilian agencies. PCI DSS v4.0.1 sets 30 days for critical patches, entity-defined for the rest. Most organizations must set their own windows. Not legal advice.

A remediation SLA is a documented, risk-tiered commitment your organization sets and defends — not a number handed down by a framework. NIST SP 800-40r4, SOC 2, ISO/IEC 27001:2022, and PCI DSS all expect a defined process; none states your day-counts for you. This page is not legal advice.

A software bill of materials (SBOM) is a machine-readable inventory of a software product's components, typically in SPDX or CycloneDX format, generated from a build rather than by hand. It lets a vulnerability in a shared component be traced to every place it ships. Not legal advice.

An end-of-life (EOL) dependency is a runtime, library, or OS package that no longer receives security fixes, whether or not a CVE has been published against it yet. Find them by checking your inventory against vendor lifecycle pages, using endoflife.date as a fast community-maintained index. Best-practice guidance, not legal advice.

Detecting vulnerable open-source packages is software composition analysis (SCA): matching the components you actually ship — direct and transitive — against advisory feeds like OSV, the GitHub Advisory Database, and NVD. A match is not proof of exploitability. This page is not legal advice.

Handling a zero-day is emergency triage: mitigate now, patch, or isolate, chosen by whether a fix exists and whether exploitation is confirmed. Confirmed exploitation hands off to incident response, not just to vulnerability management. Not legal advice; does not start a reporting clock.

Proving remediation means producing evidence a fix actually landed — a rescan, a version confirmation, or a control test — tied to the finding with a timestamp. A ticket marked 'done' is not evidence. This page describes what auditors typically expect as best practice, not a guarantee. Not legal advice.

Tracking accepted risk means recording every not-fixed-now finding as a time-boxed, owner-signed exception, not a silent skip. The record needs a named owner, a justification, any compensating control, and an expiry date. This page describes best practice and framework expectations, not a guarantee. Not legal advice.

ShipReadyMetrics ranks open findings by a fixed order: actively exploited (CISA KEV) first, then most overdue, then severity, then exploitation probability (FIRST EPSS), enriched with CVSS. It does not patch anything, does not determine legal applicability, and does not prove absence of risk. Not legal advice.

Vulnerability management is the continuous program of discovering, assessing, prioritizing, remediating, verifying, and reporting security weaknesses across systems and software. It is not a one-time scan, a pen test, or an audit. This page is not legal advice.

SOX compliance work in IT centers on IT general controls (ITGC): the access, change, and operations controls behind Sarbanes-Oxley §302 and §404. Teams collect evidence that these controls operate, test them, evaluate any deficiencies, and produce the workpapers an external auditor reviews.

The EU AI Act (Regulation (EU) 2024/1689) is the first comprehensive AI law. It classifies AI systems by risk — unacceptable (banned), high-risk, limited, and minimal — and places the heaviest obligations on providers and deployers of high-risk systems, phased in between 2025 and 2027.

ISO/IEC 42001:2023 is the first international standard for an AI management system (AIMS). It gives organizations a certifiable framework to govern how they develop and use AI responsibly — using the same Plan-Do-Check-Act structure as ISO 27001, plus AI-specific Annex A controls and an AI system impact assessment.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, sector-agnostic framework for identifying and managing the risks of AI systems. It is organized around four functions — Govern, Map, Measure, and Manage — and a set of trustworthiness characteristics a system should exhibit.

The Colorado AI Act (Senate Bill 24-205) is a state consumer-protection law governing high-risk artificial intelligence systems — those that make, or are a substantial factor in making, a consequential decision about a consumer. It requires developers and deployers to use reasonable care to protect consumers from algorithmic discrimination.