Project Baselines & Release Management in ThreatZ: Snapshot, Compare, and Freeze Your CSMS Projects

Automotive cybersecurity management under ISO/SAE 21434 and UNECE R155 is not a one-time activity. It is a continuous process that spans the entire vehicle lifecycle, from concept through production to decommissioning. As cybersecurity engineering teams iterate on threat analyses, update risk assessments, add new security controls, and respond to emerging vulnerabilities, they need a reliable mechanism to capture the state of their work at critical milestones. Without this capability, demonstrating compliance progress to auditors, comparing security posture across releases, and maintaining immutable audit evidence becomes an exercise in manual documentation and spreadsheet archaeology.

This tutorial explains how ThreatZ implements project baselines and release management to solve these challenges. We cover the complete workflow from creating your first release snapshot through comparing baselines and freezing projects for audit immutability, giving you a practical foundation for integrating baselines into your CSMS process.

Why Project Baselines Matter for Automotive Cybersecurity

A project baseline is a point-in-time snapshot of your entire cybersecurity project. Think of it as a versioned release that captures every asset, threat, risk assessment, control, requirement, and compliance metric at the moment it was created. Baselines serve three critical purposes in the automotive cybersecurity lifecycle.

Audit Trail and Compliance Evidence

ISO/SAE 21434 Clause 6 requires organizations to maintain work products that demonstrate cybersecurity activities were performed according to the defined processes. UNECE R155 Annex 1 requires evidence of ongoing cybersecurity management throughout the vehicle lifecycle. Baselines provide timestamped, immutable evidence that your project reached specific compliance milestones. When an auditor asks to see the state of your TARA at the time of type approval, you can present the exact baseline rather than attempting to reconstruct it from change logs.

Progress Tracking and Continuous Improvement

CSMS certification requires demonstrating continuous improvement. By comparing baselines across releases, teams can quantify exactly how their security posture has evolved: how many new threats were identified, how risk scores changed, how many additional controls were implemented, and whether compliance scores improved. This quantitative evidence is far more compelling than narrative descriptions of improvement activities.

Change Control and Accountability

In regulated industries, knowing what changed between two states is as important as knowing the current state. Baseline comparison provides a structured diff across all project dimensions, making it immediately clear what was added, removed, or modified between any two releases. This supports formal change control processes and helps teams understand the security impact of engineering decisions.

Key takeaway: Baselines transform your cybersecurity project from a living document that changes daily into a series of versioned releases with clear audit trails, each representing a verified state of your security analysis.

How ThreatZ Implements Baselines as Release Snapshots

In ThreatZ, baselines are implemented as releases. Each release captures a complete snapshot of your project at a specific point in time. When you create a release, ThreatZ records the current values of all project metrics, captures the state of every module, and assigns an auto-incremented version number.

Auto-Versioned Releases

Every release receives an automatic version number following a sequential pattern: v1.0, v2.0, v3.0, and so on. This auto-versioning eliminates debates about version numbering schemes and provides a clear chronological ordering of baselines. Each release also accepts a description field where teams can document the purpose of the baseline, such as "Pre-type-approval TARA freeze" or "Post-vulnerability-response update Q1 2026."

The release creation process is intentionally simple. Navigate to your project, open the Releases panel, and click Create Release. ThreatZ automatically captures the current state of the entire project, assigns the next version number, records the timestamp, and stores the snapshot. The entire operation completes in seconds, regardless of project size.

Tracked Metrics Across 12+ Dimensions

Each release snapshot captures a comprehensive set of metrics that together represent the complete security posture of your project at that moment. ThreatZ tracks the following metrics in every baseline:

These metrics are captured automatically and cannot be manually edited within the baseline, ensuring the integrity of the snapshot as audit evidence.

Module Snapshots Across 7 Modules

Beyond aggregate metrics, each release captures detailed state information from all seven ThreatZ modules. This means the baseline preserves not just summary counts but the full context of the cybersecurity analysis across the entire platform.

1. System Modeling — All assets, components, interfaces, data flows, and trust boundaries as defined at the time of release. This captures the system architecture that forms the foundation of the entire analysis.
2. Threat Modeling — Complete threat catalogs, STRIDE mappings, attack trees, threat scenarios, and their linkages to assets and interfaces. Preserves the analytical reasoning behind each identified threat.
3. Risk Assessment — All risk evaluations including attack feasibility ratings, impact assessments, risk levels, and risk treatment decisions. This is often the most scrutinized module during audits.
4. Risk Treatment — Security goals, cybersecurity requirements, controls, claims, and their traceability chains. Demonstrates how identified risks are addressed through specific countermeasures.
5. SBOM — Software Bill of Materials including all components, versions, licenses, and known vulnerabilities at the time of release. Critical for vulnerability management evidence.
6. Validation & Testing — Test cases, test results, coverage metrics, and verification evidence. Shows that security requirements were validated through appropriate testing activities.
7. Monitoring — Active monitoring configurations, detection rules, and incident response procedures. Documents the post-production cybersecurity monitoring setup.

Key takeaway: Module snapshots ensure that baselines capture the full depth of your cybersecurity analysis, not just summary statistics. An auditor can drill into any module within a baseline to examine the detailed work products as they existed at that release.

Baseline Comparison: Measuring What Changed

Creating baselines is valuable on its own, but the real power emerges when you compare them. ThreatZ provides two comparison modes that serve different analytical needs.

Release-to-Release Comparison

Select any two releases and ThreatZ generates a side-by-side comparison showing the metric values from each release alongside the calculated deltas. For each of the 12+ tracked metrics, you see the value in Release A, the value in Release B, and the absolute and percentage change between them.

This comparison mode is ideal for tracking progress over time. For example, comparing v1.0 (initial TARA) against v3.0 (post-penetration-testing update) might reveal that threats increased from 45 to 78 (demonstrating deeper analysis), controls grew from 30 to 62 (showing improved treatment), and the compliance score rose from 64% to 91% (confirming progress toward certification). These quantitative deltas tell a compelling story of continuous improvement that auditors can verify independently.

Baseline vs. Current State Comparison

The second comparison mode lets you compare any historical baseline against the current live state of the project. This is particularly useful during active development when you want to understand how much has changed since the last formal release. If your v2.0 baseline had 50 threats and the current project has 67, you know that 17 new threats have been identified since the last release and it may be time to create a new baseline.

This mode also serves as a pre-release review tool. Before creating a new release, compare the current state against the last baseline to review all changes that will be captured in the new snapshot. This supports a formal review process where designated reviewers examine the deltas before approving the new release.

Project Freezing: Immutability for Audit Evidence

Baselines capture a snapshot of your project, but the project itself remains editable. For situations where you need to guarantee that the project state cannot be modified — such as during a type approval audit or after a formal release to production — ThreatZ provides project freezing.

How Freezing Works

When you freeze a project, ThreatZ transitions it to a read-only state. All editing capabilities are disabled across every module. Team members can view and export all project data, but no modifications are permitted. The freeze is tied to a specific release, establishing a clear link between the immutable project state and the baseline snapshot.

Freezing is an explicit action that requires appropriate RBAC permissions. It is not applied automatically, giving teams full control over when immutability is enforced. The freeze timestamp and the identity of the user who performed the freeze are recorded in the audit log, providing accountability for this critical action.

Unfreezing for the Next Cycle

Projects do not remain frozen forever. When the audit is complete or when the team needs to begin the next development cycle, an authorized user can unfreeze the project to restore full editing capabilities. Like freezing, unfreezing requires specific RBAC permissions and is recorded in the audit log.

The unfreeze operation does not modify the existing baseline. The frozen release snapshot remains intact as historical evidence regardless of subsequent changes to the project. This separation between the live project and its historical baselines ensures that audit evidence is preserved even as the project evolves.

RBAC Controls for Freeze and Unfreeze

Not every team member should be able to freeze or unfreeze a project. ThreatZ enforces role-based access control on these operations. Typically, only Project Owners and designated Compliance Officers have the permissions required to freeze or unfreeze projects. This prevents accidental freezes that block team productivity and unauthorized unfreezes that could compromise audit evidence integrity.

The RBAC configuration for freeze/unfreeze operations is managed at the organization level, allowing security teams to define policies that match their governance requirements. Organizations can also require approval workflows where a freeze request must be approved by a second authorized user before it takes effect.

Key takeaway: Project freezing provides the immutability guarantee that auditors require. Combined with RBAC controls, it ensures that only authorized personnel can lock and unlock project state, with full accountability through audit logging.

Tier Availability

Project baselines and release management are available on the Professional and Enterprise tiers of ThreatZ. The Team tier does not include baseline functionality, as it is designed for teams beginning their cybersecurity journey who may not yet need formal release management processes.

Practical Workflow: End-to-End Baseline Management

Here is the recommended workflow for integrating baselines into your CSMS process. This workflow aligns with the continuous improvement cycle required by ISO/SAE 21434 and UNECE R155.

Step 1: Create a Release

When your project reaches a significant milestone — such as completing the initial TARA, finishing a risk treatment cycle, or preparing for an audit — create a new release. Navigate to the Releases panel, add a descriptive label (e.g., "Initial TARA Complete — Pre-Design Review"), and confirm. ThreatZ captures the complete project snapshot and assigns the next version number automatically.

Step 2: Review Metrics

After creating the release, review the captured metrics to verify they reflect the expected state. Confirm that asset counts, threat numbers, risk scores, and compliance percentages match your expectations. This review step catches any last-minute changes that may have been made between the team's final review and the baseline creation.

Step 3: Compare with Previous Baselines

If this is not your first release, compare the new baseline against the previous one. Review the deltas across all metrics and verify that changes align with the work performed during the cycle. Document any unexpected changes for follow-up investigation. This comparison report can be exported as part of your audit evidence package.

Step 4: Freeze the Project

If the release represents a formal milestone that requires immutability — such as a type approval submission or a production release gate — freeze the project. Confirm that all team members are aware the project will be locked for editing. The freeze takes effect immediately and is visible to all project participants.

Step 5: Conduct the Audit or Review

With the project frozen and the baseline created, conduct your audit or formal review. Auditors can access the frozen project to examine all work products in their immutable state. The baseline metrics provide a quantitative summary, while the module snapshots provide the detailed evidence. Comparison reports demonstrate continuous improvement since previous baselines.

Step 6: Unfreeze and Begin the Next Cycle

After the audit or review is complete, unfreeze the project to begin the next development cycle. The existing baselines remain preserved as historical records. Continue your cybersecurity activities — identifying new threats, updating risk assessments, adding controls — and create the next release when the cycle is complete.

Supporting CSMS Continuous Improvement and Audit Evidence

The baseline and release management workflow directly supports several CSMS requirements. For continuous improvement evidence, the series of baselines with their tracked metrics provides a quantitative record of how your cybersecurity posture has evolved over time. Auditors can see exactly when improvements were made, what changed, and by how much.

For change management, baseline comparisons serve as formal change records. Each delta between releases represents documented changes to the cybersecurity analysis, supporting the change control requirements of ISO/SAE 21434 Clause 6.4.4.

For configuration management, frozen releases tied to specific project states provide the configuration identification and configuration status accounting required by automotive quality management systems. The release version number serves as the configuration item identifier, and the freeze mechanism ensures configuration control.

For post-production monitoring, baselines created at production release gates establish the reference state against which post-production changes are measured. When a vulnerability response requires updating the TARA, comparing the new state against the production baseline clearly documents what changed and why.

Key takeaway: Baselines are not just a nice-to-have feature. They are a fundamental building block of a mature CSMS that can demonstrate compliance, track improvement, and provide the audit evidence required by ISO/SAE 21434 and UNECE R155.

Standards Alignment

Project baselines and release management are not merely a convenience feature — they directly address specific clauses and requirements across multiple automotive cybersecurity standards and regulations. Understanding these alignments helps teams position baselines as first-class compliance artifacts rather than optional project hygiene.

ISO/SAE 21434 Clause 6: Cybersecurity Management System

ISO/SAE 21434 Clause 6 requires organizations to establish, implement, maintain, and continually improve a Cybersecurity Management System (CSMS). A core requirement is the production of documented evidence that cybersecurity activities were planned, executed, and reviewed according to defined processes. Baselines serve as auditable artifacts that demonstrate this evidence at specific points in time. Each baseline captures the state of all work products — from threat models to risk treatment decisions — providing auditors with timestamped proof that the CSMS produced tangible, verifiable outputs.

ISO/SAE 21434 Clause 6.4.4 (Change Management): The standard requires that changes to cybersecurity work products be managed through a controlled process. Baseline comparisons provide a structured, quantitative record of what changed between any two points in time, directly satisfying this clause.

UNECE R155 Annex 1 Part A: Systematic Processes

UNECE R155 Annex 1, Part A requires vehicle manufacturers to demonstrate that systematic processes are used to manage cybersecurity risks throughout the vehicle lifecycle. Release snapshots provide verifiable process evidence that analysis was conducted systematically at defined milestones rather than as ad hoc, undocumented activities. When a Technical Service audits the CSMS for type approval, frozen baselines demonstrate that the manufacturer's cybersecurity processes produce consistent, repeatable outputs.

UNECE R156: Software Update Management Systems (SUMS)

R156 requires controlled software configuration management as part of the Software Update Management System. Baselines directly support this requirement by tracking the complete software state at each release point. When an OTA update modifies the software configuration of a vehicle, comparing the pre-update and post-update baselines provides the configuration change evidence that R156 demands. This is particularly critical for demonstrating that software updates do not introduce new cybersecurity risks without appropriate analysis.

EU Cyber Resilience Act (CRA) Article 10

The EU CRA Article 10 requires manufacturers to document the cybersecurity posture of products with digital elements throughout their lifecycle. Baselines capture this posture at each release, creating a chronological record that satisfies the CRA's documentation requirements. As the CRA applies to a broad range of connected products beyond vehicles, organizations using ThreatZ for automotive and non-automotive product lines benefit from a unified baseline approach across their portfolio.

Supporting Type Approval Evidence Packages

Type approval under R155 requires vehicle manufacturers to submit evidence packages to Technical Services demonstrating CSMS compliance. Baselines are ideally suited for this purpose because they capture the complete project state in an immutable, timestamped format. A typical type approval evidence package built from baselines includes:

• Initial TARA baseline — Demonstrating comprehensive threat identification and risk assessment at the concept phase
• Risk treatment baseline — Showing that identified risks were addressed with appropriate controls and requirements
• Pre-production baseline — Capturing the final security posture before vehicle production begins
• Baseline comparison reports — Demonstrating continuous improvement across the analysis lifecycle
• Frozen project state — Providing immutable evidence that the submitted analysis has not been retroactively modified

Key takeaway: Baselines are not just internal project management tools. They are compliance artifacts that directly map to specific requirements in ISO/SAE 21434, UNECE R155, R156, and the EU CRA. Building baselines into your workflow means you are simultaneously building your audit evidence package.

OEM & Tier-1 Workflows

Baselines and release management integrate into the operational workflows of both OEMs and Tier-1 suppliers across the vehicle development lifecycle. Understanding how baselines map to industry-standard program milestones helps teams embed them naturally into existing processes rather than treating them as additional overhead.

OEM Release Gates and Vehicle Program Milestones

OEM vehicle programs progress through well-defined gates: Concept (architecture definition), Development (detailed engineering), Pre-Production (validation and testing), SOP (Start of Production), and Post-Production (field monitoring and updates). ThreatZ baselines align to each gate:

Tier-1 Delivery Evidence

Tier-1 suppliers are increasingly required to deliver cybersecurity documentation packages alongside their ECU or software deliveries. Baseline snapshot exports provide a standardized, self-contained evidence package that demonstrates the supplier's cybersecurity analysis was conducted rigorously. This documentation supports OEM supplier cybersecurity questionnaires and assessments mandated by TISAX and ISO/SAE 21434 Clause 7 (distributed cybersecurity activities). A Tier-1 supplier can export a frozen baseline and deliver it to the OEM as part of the component acceptance process, providing traceable evidence of security analysis without exposing proprietary implementation details.

Audit Preparation and Technical Service Coordination

When preparing for a CSMS audit by a Technical Service (for R155 type approval) or an internal audit (for ISO/SAE 21434 compliance), frozen baselines demonstrate process maturity in a way that living, constantly-changing projects cannot. Auditors can examine the baseline created at a specific milestone, verify that the metrics reflect the expected analysis depth, and compare it against previous baselines to confirm continuous improvement. The immutability of frozen baselines gives auditors confidence that the evidence has not been modified after the fact.

Change Management Across ECU Software Versions

When an ECU software version is updated — whether for feature additions, bug fixes, or vulnerability remediation — comparing the pre-update and post-update baselines provides a structured impact analysis. This comparison reveals whether the update introduced new assets, changed the threat landscape, altered risk scores, or affected compliance status. This baseline-driven change management process supports the R155 post-production monitoring requirements (Article 7) and provides the evidence trail needed for R156 software update campaigns.

Homologation and Continuous Improvement

R155 CSMS certificates are issued for a maximum of three years, after which manufacturers must demonstrate continued compliance for renewal. Baseline metrics provide quantitative evidence of continuous improvement between type approval renewals. By comparing the baseline at the time of initial certification against the current baseline, manufacturers can demonstrate that their cybersecurity posture has not degraded and ideally has strengthened through ongoing threat monitoring, vulnerability management, and process refinement.

Key takeaway: Baselines bridge the gap between cybersecurity engineering activities and OEM/Tier-1 operational workflows. They provide the structured evidence that vehicle program gates, supplier assessments, type approval audits, and post-production monitoring all require.