Products

Regulation is no longer a silo: How Polarion Connects Traceability, Validation, and Evidence Across the Lifecycle

September 11, 2026 • 6 MIN READ
By Alexander Heyers

Compliance is becoming multidimensional

As products become more connected, updateable, and increasingly software-defined, compliance is becoming more complex as well. Software-defined does not simply mean that products contain more software. It means that functionality, behavior, interfaces, and even compliance-relevant characteristics are increasingly implemented, updated, and validated through software across the lifecycle. What many organizations once managed within relatively clear regulatory boundaries now therefore spans multiple dimensions, from product cybersecurity and operational resilience to product-generated data, sector-specific validation, and approval evidence.

Software-defined means that functionality, behavior, interfaces, and even compliance-relevant characteristics are increasingly implemented, updated, and validated through software across the lifecycle.

One useful way to understand this shift is to distinguish between horizontal regulations and sector-specific frameworks. Horizontal regulations such as the Cyber Resilience Act, NIS2, and the EU Data Act cut across industries and broaden the compliance baseline. Together, they extend expectations beyond product functionality alone, covering cybersecurity requirements for products with digital elements, organizational and operational resilience, and obligations related to data generated by connected products and services. For software teams, this has direct implications. Compliance increasingly influences how features are specified, how interfaces are designed, how security and data access are implemented, and how updates and changes are controlled over time.

At the same time, sector-specific frameworks continue to define how compliance must be interpreted and demonstrated in individual domains. To mention some examples for regulations and standards:

  • The machinery regulation [1] brings its own conformity and documentation expectations.
  • The international standard for safety, effectiveness and security for medical and health software [2] highlights the importance of integrating security activities into the software lifecycle.
  • And in automotive, the proposals for new regulations on Automated Driving Systems (ADS [3], [4]) reflect how connected and automated vehicles require more lifecycle-oriented approaches to validation and evidence.
Examples from regulations and standards for
multidimensional compliance landscape for software-defined products

For development organizations, these dimensions do not exist in isolation. They converge in real products, real engineering decisions, and real release processes. A modern software-defined product may need to address cybersecurity expectations, support operational resilience, handle data-related obligations, and still provide the sector-specific validation and documentation required for conformity assessment or homologation.

That is why the real challenge is no longer just understanding regulations one by one. It is turning them into connected engineering activities across the lifecycle — linking obligations to requirements, software architecture, implementation, verification, validation, release decisions, and evidence. In areas such as automotive, this also means supporting more advanced validation approaches, including simulation, while maintaining the traceability needed for homologation

Engineering lifecycle view

This is where flexibility becomes essential. Organizations need a way to manage multiple compliance dimensions without fragmenting their development and compliance processes. Polarion helps provide that foundation by connecting requirements, risks, tests, and evidence across the lifecycle in a way that can be adapted to different regulatory and sector-specific needs. Our earlier article on the Cyber Resilience Act [5] already showed this in a cybersecurity context, including support for structured risk analysis and traceability as well as managing the software bill-of-material in practice.

Two examples of connected compliance in practice

This multidimensional shift becomes especially visible in two current examples: the EU Data Act and the ongoing work concerning Automated Driving Systems (ADS) in automotive. They come from different contexts but point in the same direction: compliance is no longer just about interpreting requirements. It is about managing them across the lifecycle, with clear ownership, traceability, validation, and evidence. This matters even more for software-defined products, where functionality and compliance-relevant characteristics continue to evolve through software, connectivity, and change over time.

The EU Data Act: compliance reaches into product data and digital services

The EU Data Act expands the compliance conversation beyond product functionality and cybersecurity. For manufacturers of connected products and providers of related services, it raises important questions about access to and use of product-generated data, and about the responsibilities that come with enabling that access.

What makes this significant is that it is not just a legal issue. It has direct implications for how products and services are specified, designed, and managed. Organizations need to understand what data is generated, who should be able to access it, under what conditions, and how those obligations are reflected in product behavior, digital services, and internal processes.

In software-defined products, those obligations can quickly translate into implementation decisions. Enabling access to data as required by law may mean defining new software requirements, adding or adapting APIs and service interfaces, revisiting access-control models, handling permissions and identity flows, and introducing new verification steps to show that data can be accessed, shared, or restricted as intended. In other words, what begins as a regulatory obligation can quickly become a backlog, architecture, implementation, and test challenge.

That makes the challenge inherently cross-functional. Product management, engineering, architecture, cybersecurity, legal, and compliance need a shared understanding of what the requirements mean and where they apply. Without that, disconnected documents and siloed interpretations quickly become a risk.

A lifecycle-based approach helps turn these obligations into coordinated action. Requirements can be structured, connected to product and service definitions, linked to risks and implementation decisions, and traced through verification and change. In that sense, the Data Act is a strong example of how compliance now depends on connecting policy-level obligations to concrete development realities.

Automated Driving Systems regulation: lifecycle, simulation, and evidence for homologation

A similar pattern can be seen in automotive, where the ongoing work at UNECE [3] and China’s MIIT [4] for fully driverless Automated Driving Systems (ADS) reflects the growing importance of lifecycle-oriented compliance for connected and increasingly automated vehicles. The challenge is not only the technical sophistication of these systems, but also the need to show that development, validation, and change are being managed in a controlled and auditable way.

This becomes even more important in software-defined vehicles, where relevant behavior can evolve through software updates, configurable functions, connected services, and changing validation expectations. In that context, compliance and homologation are no longer just about a vehicle at one point in time. They increasingly depend on how software change across the lifecycle is managed, assessed, tested, and documented — from requirements refinement and scenario-based validation to release decisions and post-change evidence. For development teams, that means compliance must stay connected to software baselines, variants, test assets, simulation results, and release records

This is where traceability, lifecycle execution, and evidence become especially tangible. Requirements need to be connected to hazards, scenarios, system behavior, verification activities, and approval-relevant documentation. As validation approaches evolve, simulation also becomes more important as part of the broader evidence picture and the overall development and assurance process.

For organizations preparing for homologation or similar approval contexts, this creates a clear operational need: the ability to connect engineering decisions with the evidence required to support them. That includes maintaining consistency across requirements, changes, tests, validation assets, and review records over time.

What both examples have in common

The EU Data Act and the evolving work on Automated Driving Systems differ in scope and domain, but they point in the same direction. Both show that compliance is becoming more tightly connected to day-to-day product development and operational execution. Both require organizations to translate external obligations into structured internal requirements. And both make traceability, cross-functional collaboration, and evidence management far more important than in traditional siloed compliance models.

Software-Defined Product in context of ALM/PLM

This is where a solution such as Polarion together with a PLM like Teamcenter can provide real value. By connecting requirements, risks, verification, validation, and evidence across the lifecycle, Polarion helps organizations operationalize compliance across different regulatory and sector-specific contexts.

Rather than managing each new obligation as a separate process, teams can build on a connected foundation that supports both engineering efficiency and compliance readiness. For a more practical look at how this lifecycle-based approach can be applied in day-to-day development, see our companion article on compliance in practice [6].

References

Alexander Heyers
Presales Solution Consultant

Alexander Heyers has dedicated nearly 30 years to a diverse range of roles in software development and consulting projects. In his early career, his focus was primarily on all levels of the right side of a V-model. With the advent of agile methodologies, his perspective broadened to encompass all aspects of software development. For several years now, as a Principal PreSales Solution Consultant for Polarion, he has been supporting new and existing customers, primarily within the regulated environments of the Medical, Pharmaceutical, and Automotive industries. He actively works to raise awareness that concepts like HARA, TARA, or FMEA are indeed essential vocabulary for anyone involved in product development and compliance within these critical sectors.

What to read next:
This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/polarion/regulation-is-no-longer-a-silo-how-polarion-connects-traceability-validation-and-evidence-across-the-lifecycle/