If your company sells SaaS to US enterprise customers, you probably have SOC2. If you’re now looking at the EU market, you’ve probably started hearing about the Cyber Resilience Act. At some point, the question comes up: how much of what we already have carries over?
The honest answer is: less than you’d hope, but more than zero. SOC2 and the CRA operate in different regulatory universes, built for different purposes, enforced by different mechanisms. Where they touch, the overlap is real and worth understanding. Where they diverge, the gaps are significant and non-negotiable.
What SOC2 actually is
SOC2 is an auditing framework developed by the American Institute of CPAs (AICPA). It defines five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory one. An independent CPA firm audits your controls and issues a report you share with customers and prospects.
The output is a private document. Your clients get it under NDA as part of vendor due diligence. There’s no public registry, no EU authority, no CE marking, and no legal obligation to have it at all. Companies pursue SOC2 because their enterprise buyers require it, not because a regulator mandates it.
There are two report types. A Type I confirms your controls are designed correctly at a point in time. A Type II, which enterprise buyers typically require, confirms those controls operated effectively over an observation period of six to twelve months.
What the CRA actually is
The Cyber Resilience Act is an EU regulation. It applies to products with digital elements placed on the EU market, covering hardware and software alike: connected devices, standalone applications, firmware, operating systems, and more. The obligation sits on the manufacturer, and compliance is mandatory before the product reaches the market.
The CRA is enforced through the same conformity framework that governs CE marking. Products within scope must carry the CE marking and be backed by a signed EU Declaration of Conformity. Market surveillance authorities can pull non-compliant products. Fines run up to €15 million or 2.5% of global annual turnover.
Full compliance is required by December 11, 2027. The vulnerability reporting obligations to ENISA start earlier, in September 2026.
The main differences
SOC2 certifies how your organization manages security. The CRA certifies that your product is secure.
A company can hold SOC2 Type II and still ship a product with no update mechanism, undisclosed third-party dependencies, and no documented support period. SOC2 wouldn’t flag any of that, because SOC2 doesn’t evaluate product architecture. The same gap applies to ISO 27001: organizational security certification doesn’t translate into CRA compliance for any specific product.
The geographic scope diverges just as completely. SOC2 exists to satisfy US buyers. The CRA regulates access to the EU market. A company with strong SOC2 controls and no CRA compliance cannot legally place covered products in the EU after December 2027.
Where SOC2 gives you a running start
SOC2 Type II requires a level of security maturity that directly accelerates CRA work. The overlap is most useful in four areas.
Risk management documentation. SOC2 requires formal risk assessments. The CRA requires a documented threat assessment for each specific product. The methodologies aren’t identical, but companies that have run SOC2 risk cycles already know how to structure, document, and maintain this kind of analysis. Applying that process at the product level is additional work, though it builds on a foundation that already exists.
Incident response procedures. SOC2 requires organizations to detect, respond to, and learn from security incidents. The CRA adds external reporting on top: manufacturers must notify ENISA within 24 hours of detecting an actively exploited vulnerability, with a more detailed report due within 72 hours. If your incident response process already runs on documented playbooks with clear escalation paths, you’re adding a regulatory reporting step to a process that already functions.
Vendor and supply chain controls. SOC2’s Common Criteria include vendor risk management. Companies that have gone through a Type II audit have inventoried their third-party dependencies and assessed supplier security. The CRA’s Software Bill of Materials requirement pushes further, demanding a machine-readable inventory of product components in formats like CycloneDX or SPDX. The vendor discipline transfers; the SBOM format is a new output.
Secure development practices. If your SOC2 scope included Processing Integrity, your engineering team already documents controls around code quality and system behavior. The CRA requires evidence that security was addressed during the product’s design phase, traceable to the product architecture. Teams with mature development controls cover that ground faster than teams starting from scratch.
What SOC2 doesn’t cover
Several CRA obligations have no equivalent in SOC2.
The CE marking and EU Declaration of Conformity are product-level regulatory instruments. They give the manufacturer legal responsibility for the product’s conformity and create obligations with public consequences. SOC2 produces a private audit report shared under NDA. The two serve entirely different functions and one cannot substitute for the other.
The declared support period is a CRA-specific obligation. Manufacturers must define and publish how long they will provide security updates for each product, with a default expectation of at least five years. Buyers must receive this information before purchase. SOC2 has no equivalent concept.
Post-market surveillance requires manufacturers to monitor products in the field, cooperate with EU market surveillance authorities, and take corrective action when problems emerge. In serious cases, that means recalls. SOC2 covers a defined observation period. CRA obligations run for the lifetime of the product and extend to a public authority with enforcement powers.
A note on the CISO
SOC2 doesn’t formally require a Chief Information Security Officer. In practice, companies pursuing Type II at any serious scale typically have one, whether full-time, fractional, or virtual, because the governance complexity demands executive ownership.
The CRA has no CISO requirement either. It does require that someone inside the organization owns product security as an ongoing responsibility through the product’s entire supported lifetime.
Companies where a CISO already drives the SOC2 program tend to absorb that expectation faster, because the governance infrastructure is already in place.
What this means if you’re preparing for the EU market
SOC2 is a genuine asset going into CRA compliance work. The documentation discipline, the risk management processes, and the incident response foundations all reduce the effort required. Companies without any security framework face a longer road.
The product-level obligations are where the real work sits. CE marking, the EU Declaration of Conformity, the SBOM, the support period, and post-market surveillance don’t map to anything in SOC2 and can’t be shortcut.
If you want to understand exactly where your current security posture lines up against what the CRA requires for your specific product,get a quoteand we’ll work through it together.
