Build the matrix product by product, not company by company. Start with a stable product identifier, intended purpose, market status and software or hardware boundary. Then test CRA scope and exclusions, map other CE-marking and sector laws, add non-CE digital regimes such as GDPR or the Data Act where relevant, record conformity routes and shared evidence, and assign review triggers. The matrix should function as the control layer that tells compliance teams which legal workstreams apply and when they need to be reopened.
Start With the Product, Not the Legal List
An applicability matrix is only reliable when every row is tied to a clearly defined product. Record a stable product identifier, commercial name, product family, hardware or software version, intended purpose, market status and manufacturer identity before evaluating legislation. A company-level matrix can hide differences between product lines that fall under very different EU rules.
Define the Product Boundary and Digital Architecture
Describe the hardware, software, firmware, companion applications, remote data processing, interfaces and relevant connected services that form the product being assessed. The same legal analysis can change when a cloud backend, mobile application, separately supplied component or remote service is inside or outside the regulated product boundary.
Record Intended Purpose and Reasonably Foreseeable Use
Intended purpose can determine whether sector-specific legislation applies and can affect the CRA cybersecurity risk assessment. Record the controlled intended-purpose statement, target users, operating environment and major functions. Avoid relying only on a marketing category such as healthcare, industrial, automotive or consumer because legal scope usually depends on more specific product facts.
Make CRA Scope the First Regulatory Decision
Record whether the product is a product with digital elements within CRA scope and why. Capture the relevant Article 2 and Article 3 reasoning, including connectivity, separately supplied components and manufacturer-responsible remote data processing where relevant. The matrix should link to the full scope analysis rather than trying to compress every legal fact into one cell.
Create a Separate Field for Express CRA Exclusions
CRA Article 2 expressly excludes specified products, including products to which the Medical Device Regulation, In Vitro Diagnostic Medical Devices Regulation and Regulation (EU) 2019/2144 on motor-vehicle type approval apply, together with certain aviation-certified products and marine equipment. Record the exact exclusion basis and the product configuration it covers instead of using a generic sector-regulated label.
Track Article 2(5) Limitations Separately From Express Exclusions
The CRA also contains a mechanism under Article 2(5) for limiting or excluding CRA application where other Union rules address the relevant cybersecurity risks and provide the same or a higher level of protection. A matrix should therefore have separate fields for express statutory exclusions and later delegated limitations so the two legal mechanisms are not confused.
Map Every Other Potentially Applicable EU Product Law
After the CRA decision, identify other product legislation based on the product's characteristics and intended purpose. Depending on the product, this can include machinery, radio equipment, electrical safety, electromagnetic compatibility, consumer product safety, medical-device, vehicle or other sector-specific law. Record both laws that apply and laws that were considered but ruled out where the boundary was genuinely relevant.
Separate CE-Marking Legislation From Other Digital Regulation
Not every relevant EU law is a CE-marking product law. GDPR, the Data Act, NIS2, DORA or product-liability rules can regulate data processing, entities, services, cybersecurity governance or civil liability without becoming part of the same CE-marking conformity route. A useful matrix identifies the law type so teams know whether the consequence is conformity assessment, operational governance, reporting, data rights, liability exposure or another obligation.
Record the Legal Role That Creates the Obligation
The same company can act as CRA manufacturer, importer or distributor, GDPR controller or processor, Data Act data holder, machinery manufacturer or another regulated economic operator. Record the relevant legal role for each law. This prevents teams from assuming that a company is subject to every obligation under a Regulation simply because the Regulation appears in the matrix.
Record the Conformity Route for Each Applicable Product Law
For laws requiring conformity assessment, record the applicable classification, assessment procedure, whether self-assessment is available, whether a notified body is required and which standards or specifications are relied upon. CRA Article 32 should remain a distinct field from machinery, radio or other conformity procedures even where one project team coordinates them.
Add a Single-Declaration and CE-Marking View
Where multiple applicable Union acts require an EU declaration of conformity, CRA Article 28 requires a single EU declaration covering those acts. The matrix should identify which acts must appear in that declaration and which require CE marking. One CE mark can represent conformity with several applicable acts, but the matrix should preserve the separate legal basis underneath it.
Map Shared Evidence Without Merging Legal Conclusions
Architecture diagrams, product specifications, SBOMs, supplier records, risk analyses, test reports and change records can support several workstreams. Add an evidence field showing which controlled record supports each law. Reuse the evidence where justified, but keep the legal conclusion for CRA cybersecurity, machinery safety, GDPR, product liability or other regimes separate.
Add Reporting and Post-Market Obligations
Applicability does not end at market placement. Record whether the law creates vulnerability reporting, incident reporting, safety reporting, data-breach notification, corrective-action, recall, post-market surveillance or authority-cooperation duties. This allows operational teams to know which legal workflows may be triggered by the same real-world event.
Track Support, Retention and Lifecycle Obligations
The matrix should identify CRA support-period commitments, technical-documentation retention, sector-specific post-market periods and other lifecycle duties. A product can stop being sold while remaining subject to security support, safety monitoring, documentation retention or liability-related evidence preservation.
Assign a Responsible Owner for Every Applicability Decision
Each legal conclusion should have a named owner or accountable function, such as product compliance, legal, privacy, product security, regulatory affairs or quality. Ownership should cover both the initial decision and later review. An unowned matrix quickly becomes a static spreadsheet whose statuses cannot be trusted.
Record the Legal Basis, Evidence and Review Date
For every yes, no, excluded or limited status, store the relevant Article, Annex, delegated act, guidance or other legal source, together with the supporting product facts and review date. This makes the matrix reviewable and reduces the risk that a historical conclusion survives after the underlying law or product has changed.
Use Explicit Change Triggers
The matrix should reopen when the product's intended purpose changes, a new remote service is added, a major software or hardware revision occurs, a product enters a new market channel, an EU law is amended, a new delegated act is adopted, a harmonised standard changes or a sector-specific classification changes. Product change control and regulatory change monitoring should feed the same review queue.
Keep Uncertainty Visible
Some products sit near legal boundaries. Use statuses such as review required or pending legal determination instead of forcing an immediate yes or no. Record the competing interpretations, missing facts, responsible reviewer and deadline. Visible uncertainty is safer than a false green status.
Use the Matrix as the Control Layer for the Wider Compliance System
The applicability matrix should point downstream to classification, cybersecurity risk assessment, technical documentation, conformity assessment, privacy analysis, safety records, supplier evidence and reporting procedures. It should not attempt to contain all of those records itself. Its job is to identify which legal workstreams apply to which product and keep that decision current.
Recommended Minimum Matrix Fields
A practical minimum record should contain product ID, product family and version, intended purpose, manufacturer identity, CRA scope status, Article 2 exclusion or limitation status, other applicable EU acts, regulated role under each act, conformity route, declaration and CE-marking requirements, evidence links, reporting duties, lifecycle obligations, decision owner, review date and change triggers. Additional fields can be added for standards, notified bodies, countries, suppliers or business units where useful.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.