Building a Unified CSMS: Why ISO/SAE 21434, R155, R156, and CRA Belong in One Operating Model

The Problem with Parallel Compliance Tracks

Across the automotive industry, a familiar pattern has taken hold. One team manages ISO/SAE 21434 compliance. Another handles UNECE R155 type approval evidence. A third works on UNECE R156 software update processes. And now, with the EU Cyber Resilience Act approaching enforcement, yet another workstream is being spun up. Each team creates its own templates, maintains its own evidence repositories, runs its own review cycles, and reports to different stakeholders.

The result is predictable: duplicated effort, disconnected evidence, conflicting timelines, and — most critically — less real visibility into the organization’s actual cybersecurity posture. When four teams independently track risk, nobody has the complete picture. When four sets of documentation describe the same underlying processes in different formats, inconsistencies are inevitable. When four audit preparation cycles run in parallel, the organizational burden multiplies without a proportional increase in security.

This is what we call “audit theater” — PDFs, Excel sheets, and SharePoint folders that satisfy compliance checkboxes without reflecting reality. The documentation exists. The processes are described. But the living, breathing system that connects threat intelligence to engineering decisions to operational monitoring is absent.

There is a better way. Instead of treating ISO/SAE 21434, UNECE R155, UNECE R156, and the EU CRA as four separate compliance obligations, forward-thinking organizations are building one integrated operating model that serves all four frameworks simultaneously. This is not about cutting corners. It is about recognizing that these standards describe different facets of the same underlying reality: a Cybersecurity Management System that actually works.

The mistake is treating ISO/SAE 21434, R155, R156, and CRA as four parallel tracks. The winning approach is one connected operating model: risk → controls → evidence → monitoring → incident response → lessons learned → back into engineering.

Four Standards, One Reality

To build a unified operating model, you first need to understand what each standard actually demands — and more importantly, where they overlap. Each framework addresses a different dimension of automotive cybersecurity, but they all depend on the same foundational capabilities.

ISO/SAE 21434 — The Engineering Backbone

ISO/SAE 21434 is the engineering standard. It defines how cybersecurity should be integrated into every phase of the automotive product lifecycle, from concept and development through production, operations, and decommissioning. At its core, this standard drives four critical engineering activities:

• Threat Analysis and Risk Assessment (TARA): The systematic identification and evaluation of cybersecurity threats against vehicle systems. Clause 15 defines the methodology — asset identification, threat scenarios, impact assessment, attack feasibility, and risk determination. A well-executed TARA is the foundation upon which every other compliance activity builds.
• Secure design and implementation: Engineering practices that translate TARA findings into cybersecurity requirements, architecture decisions, and verified implementations. Clauses 9 through 11 cover the concept phase, product development, and cybersecurity validation.
• Verification and traceability: Demonstrable evidence that cybersecurity requirements have been implemented and verified. Every threat must trace to a cybersecurity goal, every goal to a requirement, every requirement to an implementation, and every implementation to a test result.
• Post-development lifecycle management: Clauses 12 and 13 address production cybersecurity, operations, maintenance, and decommissioning — ensuring that cybersecurity does not end at the development gate.

ISO/SAE 21434 also addresses organizational governance through Clause 5 (cybersecurity management), Clause 6 (project-dependent cybersecurity management), and Clause 7 (distributed cybersecurity activities across the supply chain). These organizational requirements align directly with what UNECE R155 expects from a certified CSMS.

Think of ISO/SAE 21434 as the engineering backbone: it produces the cybersecurity work products — TARA reports, cybersecurity specifications, verification results, and cybersecurity cases — that feed evidence into every other framework.

UNECE R155 — The Governance Framework

Where ISO/SAE 21434 focuses on engineering processes, UNECE R155 takes the governance and operational perspective. R155 establishes the regulatory requirement for a Cybersecurity Management System (CSMS) and makes CSMS certification a prerequisite for vehicle type approval in UNECE markets.

The regulation addresses several critical dimensions:

• CSMS certification: Before an OEM can obtain type approval for a new vehicle type, the OEM’s CSMS must be certified by an accredited technical service. This certification evaluates whether the organization has systematic processes for managing cybersecurity across the entire vehicle lifecycle.
• Continuous cyber risk management: R155 requires ongoing identification, assessment, and management of cybersecurity risks — not just at development time but throughout the vehicle’s operational life. This includes risks from suppliers, aftermarket components, and evolving threat landscapes.
• Post-production monitoring: Article 7 requires OEMs to monitor vehicles in the field for cybersecurity threats, assess newly discovered vulnerabilities, and take appropriate action. This is not a one-time activity but a continuous obligation.
• Incident response: Article 7.3 requires demonstrated capability to detect, assess, and respond to cybersecurity incidents affecting the vehicle fleet. Incident response plans must be exercised, not just documented.
• Supply chain management: Annex 1, Part B requires that cybersecurity risk management extends to suppliers. OEMs must ensure that components sourced from Tier-1 and Tier-2 suppliers meet cybersecurity requirements.

The critical point: without R155 CSMS certification, no vehicle type approval in UNECE markets. This makes R155 the regulatory gateway, and it consumes evidence produced by ISO/SAE 21434 engineering processes.

UNECE R156 — Software Update Discipline

UNECE R156 addresses a specific but critical dimension of vehicle cybersecurity: the management of software updates throughout the vehicle lifecycle. R156 requires a certified Software Update Management System (SUMS) and covers:

• Software version traceability: The ability to identify exactly what software is running on every vehicle, at every ECU level. This means knowing what you released, what changed, and why — with complete version history.
• Over-the-air (OTA) update governance: Processes and controls for managing remote software updates, including validation before deployment, rollback capabilities, and confirmation of successful installation.
• Release control: Formal processes for approving, testing, and deploying software updates, with documented impact assessments for each update — including cybersecurity impact.
• SBOM linkage: R156 fundamentally depends on knowing what software components are deployed in which vehicles. This connects directly to Software Bill of Materials (SBOM) management — the same SBOM data that serves ISO/SAE 21434 component identification and CRA supply chain transparency.

R156 is non-negotiable: you must know what you released, what changed, and why. Any organization that cannot trace its software releases to specific vehicle configurations has a fundamental gap that affects not just R156 compliance but the ability to assess vulnerability exposure and manage incident response effectively.

EU Cyber Resilience Act (CRA) — The Ecosystem Mandate

The EU Cyber Resilience Act extends the scope of cybersecurity obligations beyond vehicles to all products with digital elements placed on the EU market. For automotive organizations, the CRA introduces several important dimensions:

• Secure by design: Products must be designed with cybersecurity integrated from the outset, not bolted on afterward. This aligns with ISO/SAE 21434’s engineering lifecycle approach but extends it to all digital products, including development tools, testing equipment, and aftermarket components.
• Vulnerability handling: Article 11 requires manufacturers to actively handle vulnerabilities throughout the product’s expected lifetime, including coordinated vulnerability disclosure processes. This overlaps significantly with ISO/SAE 21434 Clause 13 and R155 Article 7.
• Supply chain responsibility: The CRA makes OEMs accountable for the cybersecurity of components sourced from Tier-1 and Tier-2 suppliers. Article 10.5 requires due diligence on third-party components, and organizations must be able to demonstrate that supplier components meet cybersecurity requirements.
• SBOM requirements: Article 10.6 requires manufacturers to identify and document components and dependencies in their products, including open-source components. This is fundamentally an SBOM requirement that aligns with R156 traceability and ISO/SAE 21434 component identification.
• Vulnerability disclosure obligations: Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours. This adds a regulatory reporting dimension to incident response that connects to R155 monitoring obligations.

With the CRA becoming effective from 2027, organizations must prepare now. The good news is that organizations already building ISO/SAE 21434 and R155-compliant processes have a significant head start — if those processes are connected rather than siloed.

The Connected Operating Model

The key insight behind a unified CSMS is that all four standards describe different views of the same continuous loop:

Risk → Controls → Evidence → Monitoring → Incident Response → Lessons Learned → Back into Engineering

Each step in this loop produces outputs that serve multiple standards simultaneously. The challenge is not doing more work — it is connecting the work you are already doing.

One TARA, Multiple Frameworks

Consider a single TARA assessment performed per ISO/SAE 21434 Clause 15. That same assessment produces:

• R155 evidence: The TARA results demonstrate systematic cyber risk identification and assessment as required by Annex 5. Auditors evaluating the CSMS can reference the same TARA outputs to verify that risk management is embedded in engineering.
• R156 traceability: TARA findings that affect software components create the link between cybersecurity risk and software update requirements. When a vulnerability is discovered in a deployed component, the TARA tells you the risk context and treatment strategy.
• CRA documentation: Article 10.2 requires a cybersecurity risk assessment for products with digital elements. A well-structured TARA satisfies this requirement directly, without creating a separate risk assessment document.

One analysis, four compliance frameworks satisfied. But this only works if the TARA is maintained as a living document that updates when threats change, vulnerabilities are discovered, or architecture evolves.

SBOM as a Shared Foundation

SBOM management is another area where a unified approach eliminates massive duplication:

• R156 (what’s deployed): The SBOM tells you exactly what software is running on which vehicles, enabling version traceability and update impact assessment.
• CRA (supply chain transparency): The same SBOM data satisfies Article 10.6 requirements for identifying and documenting components and dependencies.
• ISO/SAE 21434 (component identification): SBOM data feeds into TARA by identifying the software assets that need threat analysis and vulnerability monitoring.
• R155 (vulnerability correlation): SBOM data enables automated correlation of newly published CVEs against deployed components, supporting the post-production monitoring obligation.

Incident Response Feeds Engineering

The most powerful connection in the unified model is the feedback loop from incident response back into engineering. When an incident occurs or a vulnerability is discovered:

• The incident is assessed against the existing TARA (ISO/SAE 21434 Clause 13).
• The TARA is updated with new threat intelligence, potentially changing risk ratings and treatment decisions.
• Updated TARA findings flow into new cybersecurity requirements.
• Requirements drive software updates, governed by R156 processes.
• The update deployment is tracked through SBOM management.
• Post-production monitoring confirms the fix is effective (R155 Art. 7).
• The incident report feeds CRA vulnerability disclosure obligations (Art. 11).
• Lessons learned update the organizational knowledge base, improving future TARA quality.

This is the continuous improvement loop that transforms a document set into a living system.

Cross-Framework Activity Mapping

The following table maps common cybersecurity activities to the specific requirements they satisfy across all four frameworks. This is the foundation for eliminating duplicated work:

Each row in this table represents work that many organizations perform multiple times for different compliance teams. In a unified model, each activity is performed once and the outputs are mapped to every applicable standard.

Where Does Your CSMS Break First?

Where does your CSMS break first: engineering, operations, supplier collaboration, or reporting?

Before building a unified model, it helps to understand where existing CSMS implementations most commonly fail. In our experience working with OEMs and Tier-1 suppliers, the breakpoints fall into four categories:

Engineering Breakpoint

The most common engineering failure: TARA performed once during the concept phase and never updated. The initial threat analysis becomes a static document that is disconnected from runtime reality. New vulnerabilities are discovered, architectures evolve, threat actors develop new techniques — but the TARA remains frozen in time. When the TARA is stale, every downstream artifact that depends on it (cybersecurity requirements, verification plans, cybersecurity cases) is equally stale. The compliance evidence may look complete, but it no longer reflects the actual risk landscape.

Operations Breakpoint

Incident response plans that exist on paper but are never exercised. The plan describes roles, escalation paths, communication channels, and decision criteria — but nobody has actually practiced executing it. When a real incident occurs, the plan falls apart because assumptions about availability, communication speed, and decision authority do not match reality. The gap between documented response capability and actual response capability is only revealed under pressure, which is exactly when you cannot afford it.

Supplier Collaboration Breakpoint

No visibility into Tier-1 and Tier-2 cybersecurity posture. OEMs may have strong internal processes but cannot answer basic questions about their supply chain: Which suppliers have performed TARA on their components? What SBOMs have been delivered? How do suppliers handle vulnerability disclosures? What incident response capabilities exist at the supplier level? Without this visibility, the OEM’s CSMS has a fundamental blind spot that no amount of internal process maturity can compensate for.

Reporting Breakpoint

Evidence scattered across SharePoint, Excel, email threads, and individual engineers’ laptops. When audit time arrives, the organization spends weeks gathering, formatting, and reconciling evidence from disparate sources. Version conflicts emerge. Documents reference outdated processes. Traceability chains break because the threat model, requirements, and test results live in different systems with no linking mechanism. The evidence exists, but assembling it into a coherent compliance narrative requires heroic manual effort every time.

A unified operating model addresses all four breakpoints by connecting the data flows between engineering, operations, supplier management, and reporting into a single system of record.

From Document Set to Living System

A real CSMS is not a document set. It is a living system.

The distinction between a document-based CSMS and a living CSMS is the difference between passing an audit and actually managing cybersecurity risk. A document-based CSMS produces artifacts that describe what the organization intends to do. A living CSMS produces artifacts that reflect what the organization is actually doing, updated continuously as the risk landscape changes.

The Connected Data Model

In a living CSMS, every data element is connected. The model follows a single chain:

Threat → Risk → Control → Requirement → Test → Evidence → Report

When a new threat is identified, the model automatically surfaces which controls are affected, which requirements need updating, which tests need re-execution, and which compliance reports need revision. There is no manual reconciliation because the data is linked at the source, not assembled from disconnected spreadsheets at reporting time.

Continuous Improvement Through Baselines

A living system tracks baselines over time. You can compare your current TARA against last quarter’s baseline and see exactly what changed: new threats identified, risk ratings adjusted, treatments updated. You can compare your SBOM against the previous release and identify new components, removed dependencies, and version changes that require vulnerability assessment. These comparisons drive continuous improvement by making change visible and measurable.

Real-Time Compliance Visibility

Instead of preparing for audits by gathering evidence weeks in advance, a living CSMS provides real-time dashboards that show compliance status across all four frameworks simultaneously. Leadership can see coverage gaps, track remediation progress, and make informed resource allocation decisions without waiting for a periodic compliance report. When the audit arrives, the evidence is already organized, current, and consistent because it was generated from the same operational data that drives daily engineering decisions.

How ThreatZ Enables the Unified Model

ThreatZ provides the integrated platform that connects these data flows. TARA, SBOM, vulnerabilities, tests, incidents, and compliance evidence live in one place with full traceability between them. When a new CVE is published, ThreatZ correlates it against your SBOM, surfaces affected components, links to the relevant TARA threat scenarios, and flags which compliance frameworks are impacted. When you update a TARA treatment, the downstream requirements, tests, and compliance evidence update accordingly. This is the operational reality of a unified CSMS — not four separate tools with four separate data models, but one connected platform.

Practical Steps to Unify Your CSMS

Building a unified operating model is not an overnight transformation. It is a structured migration from siloed compliance workstreams to an integrated system. The following steps provide a practical roadmap:

1. Map your current workstreams: Before changing anything, document where ISO/SAE 21434, R155, R156, and CRA activities currently live. Identify every team, tool, template, and evidence repository involved. Map the overlaps — you will likely find that TARA, SBOM, vulnerability monitoring, and incident response are being performed (at least partially) by multiple teams for different compliance purposes. This overlap map is the blueprint for consolidation.
2. Consolidate evidence: Start with the highest-value consolidation: one TARA serving all frameworks, one SBOM serving all traceability needs, one incident register serving all response and reporting obligations. This does not mean creating a single monolithic document. It means establishing a single source of truth for each data type, with different views and export formats for different audiences and compliance requirements.
3. Establish the feedback loop: Connect the data flows that turn a static document set into a living system. Incidents must feed TARA updates. TARA updates must drive requirement changes. Requirement changes must trigger test re-execution. Test results must update compliance evidence. Define the triggers, responsibilities, and timelines for each connection in the loop. Without this feedback loop, you have a unified document set — not a unified operating model.
4. Automate compliance reporting: Once evidence is consolidated in a single source of truth, automate the generation of framework-specific reports. The same underlying data should produce an ISO/SAE 21434 cybersecurity case, an R155 CSMS evidence package, an R156 SUMS compliance report, and a CRA conformity assessment — each formatted to the expectations of the respective auditors and regulators. Manual report assembly from fragmented sources is the hallmark of a siloed CSMS.
5. Integrate supplier management: Extend the unified model to your supply chain. Tier-1 cybersecurity assessments should link directly to component TARA findings. Supplier-delivered SBOMs should feed into your central SBOM repository. Supplier vulnerability notifications should route into your incident management workflow. The supply chain is where many CSMS implementations have their largest blind spot — and where R155, CRA, and ISO/SAE 21434 all demand visibility.
6. Monitor continuously: Post-production monitoring is where R155 Article 7 and CRA Article 11 converge. Implement automated vulnerability correlation against your SBOM data. Establish monitoring dashboards that track vulnerability exposure across your deployed fleet. Define SLAs for vulnerability triage that satisfy both R155 and CRA timelines. Continuous monitoring is not an additional compliance burden — it is the mechanism that keeps your entire CSMS current.

Key Takeaways

• ISO/SAE 21434, UNECE R155, UNECE R156, and the EU CRA are not four separate compliance obligations. They are four views of the same underlying reality: a cybersecurity management system that connects engineering, governance, software management, and ecosystem accountability.
• The unified operating model follows one continuous loop: risk → controls → evidence → monitoring → incident response → lessons learned → back into engineering.
• One TARA assessment, maintained as a living document, feeds evidence into all four frameworks simultaneously.
• SBOM management is a shared foundation serving R156 traceability, CRA supply chain transparency, ISO/SAE 21434 component identification, and R155 vulnerability correlation.
• The four common CSMS breakpoints — engineering, operations, supplier collaboration, and reporting — are all symptoms of siloed compliance rather than connected processes.
• A real CSMS is not a document set. It is a living system that connects threat intelligence to engineering decisions to operational monitoring to continuous improvement.
• Organizations that build the unified model now will be prepared for CRA enforcement in 2027 without creating yet another parallel workstream.