Software due diligence for Compliance departments

Modern software is not written from scratch. Every enterprise application incorporates hundreds or thousands of open source components and third-party libraries. For Compliance departments, this poses a critical challenge: how do you assess and document the risks of a software supply chain you don't directly control?

This article provides a practical guide for legal, GRC and Compliance Officers on how to perform software due diligence in the context of the new European regulatory framework.

The new paradigm: software as regulatory risk

Traditionally, Compliance departments focused on financial, legal, and privacy risks. Software was the exclusive responsibility of IT. This separation is no longer viable in the current regulatory environment.

The convergence of IT and regulatory compliance has occurred for several reasons. First, software now handles critical business processes that directly affect compliance with financial regulations, data protection laws, and industry-specific requirements. Second, the supply chain attacks of recent years have demonstrated that software vulnerabilities can have systemic impacts that extend far beyond the IT department. Third, and most directly relevant, new regulations like CRA and NIS2 explicitly place software security within the scope of organizational compliance obligations.

Why software is now a Compliance risk

The regulatory framework has evolved to recognize software as a source of organizational risk that requires formal governance. CRA Article 8 and NIS2 Article 21 establish direct legal obligations for software supply chain due diligence. These are not recommendations or best practices—they are enforceable requirements with significant penalties for non-compliance.

The penalty regime is substantial: up to 15 million euros under CRA or 10 million euros under NIS2 for serious infringements. These figures are designed to be material even for large organizations. Furthermore, NIS2 introduces the possibility of personal liability, allowing the suspension of executives responsible for violations. This changes the risk calculus significantly—it is no longer just the organization's money at stake.

Beyond penalties, regulators now expect organizations to maintain documented evidence of their assessment processes. This means that Compliance departments must be able to demonstrate not only that software is compliant, but also that appropriate processes were followed to verify compliance.

The transitive dependency risk

One of the most challenging aspects of software risk management is the concept of transitive dependencies. When your development team includes a library in your application, that library typically depends on other libraries, which in turn depend on others. A 2025 industry study revealed that the average software project has 847 transitive dependencies—components included indirectly through other libraries.

Each of these dependencies represents a potential source of risk. Some may contain known security vulnerabilities with published CVE identifiers. Others may use licenses that are incompatible with commercial use or impose unexpected obligations. Many come from projects that have been abandoned by their maintainers and no longer receive security updates. In some cases, the origin of the code cannot be verified with confidence.

The Compliance department cannot be expected to personally review 847 components. But it can and must ensure that appropriate processes and tools exist to identify these dependencies and assess their risks systematically.

CRA Article 8: due diligence obligations

Article 8 of the Cyber Resilience Act establishes specific due diligence obligations for manufacturers regarding third-party components. While the primary addressees are product manufacturers, these obligations have implications for any organization that develops software, including internal applications.

The due diligence requirements are comprehensive but achievable with appropriate processes and tooling. The manufacturer must identify all components integrated into the product, documented through a complete SBOM. Security assessment must verify that components meet essential requirements—this does not necessarily require reviewing source code, but it does require assessing the security posture of components. Vulnerability management processes must monitor and remediate component vulnerabilities throughout the product lifecycle. License compatibility analysis must verify that all component licenses allow the intended use.

NIS2 Article 21: supply chain management

The NIS2 Directive complements the CRA with organizational security obligations that extend to the supply chain. While CRA focuses primarily on product requirements, NIS2 addresses how organizations should manage their supplier relationships.

NIS2 Art. 21(2)(d): Supply chain security

Article 21(2)(d) of NIS2 requires entities within scope to implement specific measures for supply chain security. These requirements apply regardless of whether the organization is a software manufacturer—any essential or important entity under NIS2 must manage the security of its supply chain.

The required security policies for relationships with direct suppliers must define expectations for security practices and establish mechanisms for verification. Risk assessment of the supply chain must consider both the security practices of suppliers and the criticality of supplied components. Contractual security requirements with suppliers provide legal mechanisms to enforce security expectations. Continuous monitoring of supplier compliance ensures that initial assessments remain valid over time.

For Compliance departments, this means that software procurement processes must incorporate security assessment criteria, contracts must include appropriate security clauses, and ongoing monitoring must verify that suppliers maintain their security posture.

What to assess: the four dimensions of software due diligence

A complete software due diligence process must cover four distinct dimensions. Each dimension addresses a different category of risk, and weaknesses in any dimension can create significant exposure for the organization.

1. Security vulnerabilities

Security vulnerabilities represent the most immediately visible risk category. Publicly disclosed vulnerabilities with CVE identifiers provide a starting point for assessment, but the analysis must go deeper.

The assessment should identify known CVEs in the component and its dependencies, examining not just direct dependencies but the full transitive tree. Severity assessment using CVSS scores helps prioritize remediation efforts—critical and high severity vulnerabilities require immediate attention, while medium and low severity issues can be addressed in normal development cycles. The assessment must verify whether patches or corrected versions are available and practical to apply. The component's vulnerability history provides insight into the maintainer's security practices—a component with a long history of vulnerabilities that were addressed promptly may be less risky than one with no reported vulnerabilities but no apparent security process.

2. Software licenses

License compliance often receives less attention than security, but the risks are equally real. Incorrect license compliance can result in litigation, mandatory source code disclosure, or loss of the right to use essential components.

The assessment must identify the license type for each component. Permissive licenses like MIT, Apache 2.0, and BSD impose minimal obligations and are generally compatible with commercial use. Copyleft licenses like GPL require careful analysis—depending on how the component is used, they may require disclosure of your own source code. Proprietary licenses may impose restrictions on use, modification, or distribution.

The Blue Oak Council provides a useful categorization scheme that groups licenses by their obligations:

• Platinum/Gold: Permissive licenses without significant restrictions (MIT, Apache 2.0, BSD)
• Silver: Permissive licenses with some conditions that require attention
• Bronze: Weak copyleft licenses (LGPL, MPL) that require specific handling
• Lead: Strong copyleft licenses (GPL) that require careful legal analysis

Attribution obligations must be documented and satisfied—many open source licenses require acknowledgment in product documentation or user interfaces.

3. Project health

A component's current security status is only part of the picture. The project's health indicates whether the component will continue to be maintained and whether vulnerabilities will be addressed promptly.

Assessment of project health should examine recent development activity including commits, releases, and issue responses. A project that has not had a commit in two years is likely abandoned. The size and diversity of the maintainer community affects sustainability—a project dependent on a single maintainer is vulnerable to that individual's availability. Response time to issues and vulnerability reports indicates how quickly security problems will be addressed. The repository status should be verified—some projects are explicitly archived or marked as deprecated.

4. Provenance and trust

The final dimension concerns the origin and integrity of the component. Supply chain attacks like the SolarWinds incident have demonstrated that even trusted components can be compromised.

Assessment should verify the source code origin through established channels. Artifact integrity should be validated through checksums and, where available, cryptographic signatures. The history of the maintainer or maintaining organization provides context for trust assessment. Presence in official package registries (npm, PyPI, Maven Central) provides some assurance of legitimacy, though it is not a guarantee.

Documentation for Notified Bodies

Products with digital elements classified as Class I or Class II require evaluation by Notified Bodies. The Compliance department must prepare documentation packages that support these evaluations.

The required documentation builds on the due diligence processes described above. A complete SBOM in standard format (SPDX 2.3, CycloneDX 1.5) provides the foundation. A vulnerability report documenting identified CVEs and remediation actions shows ongoing security management. License analysis with verified compatibility demonstrates intellectual property compliance. A third-party component risk assessment summarizes the evaluation of external dependencies. A documented component selection and evaluation procedure shows that appropriate processes exist. Vulnerability monitoring records demonstrate ongoing vigilance.

The documentation must be sufficient for the Notified Body to understand the manufacturer's processes and verify that they meet CRA requirements. Incomplete or poorly organized documentation can result in delays, requests for additional information, or negative assessments.

NIS2 templates: 24h alerts, 72h notification, 1-month report

NIS2 establishes a three-phase incident notification process that creates specific deadlines for communication with authorities. Compliance departments must have processes and templates ready to meet these deadlines.

Phase 1: Early warning (24 hours)

The early warning must be submitted within 24 hours of becoming aware of a significant incident. This is a short timeline that requires pre-prepared templates and clear escalation procedures.

The early warning should include the date and time of incident detection, a preliminary description of the incident, an initial assessment of impact, an indication of suspected malicious origin if applicable, and a description of initial containment measures adopted.

The goal at this stage is to alert authorities rapidly, not to provide a complete analysis. Completeness is sacrificed for speed.

Phase 2: Incident notification (72 hours)

The incident notification, due within 72 hours, provides more detail than the early warning while recognizing that investigation is still ongoing.

This notification should update the early warning with additional information discovered, provide a more detailed assessment of impact, document identified indicators of compromise (IoCs), describe ongoing remediation measures, and note cross-border impact if applicable.

Phase 3: Final report (1 month)

The final report, due within one month, provides a comprehensive account of the incident after investigation is substantially complete.

This report must include a detailed description of the incident, identification of the root cause, documentation of implemented remediation measures, analysis of lessons learned, and an improvement plan to prevent recurrence.

Documentary retention requirements

CRA: 10-year retention

Article 31(13) of the CRA requires keeping technical documentation for 10 years from the date a product is placed on the market. This extended retention period reflects the long operational lifecycles of many products with digital elements, particularly in industrial contexts.

The 10-year requirement has significant implications for document management systems. Documentation must remain accessible and readable over this period, even as technology platforms change. The integrity of documentation must be preserved to support any future audits or investigations. Organizations must maintain the ability to retrieve documentation for specific product versions, not just the current version.

The documentation subject to this requirement includes SBOM for each product version, vulnerability analysis reports, remediation decision records, and component assessment documentation. For organizations with large product portfolios, this represents a substantial document management challenge.

How EMETHRA helps Compliance departments

EMETHRA provides the tools that Compliance teams need to efficiently manage software due diligence. The platform addresses both the technical challenges of component analysis and the documentation requirements of the regulatory framework.

Automated due diligence

Manual analysis of software dependencies is impractical at scale. EMETHRA automates the core due diligence activities, providing complete transitive dependency analysis with one click. The platform identifies CVEs across all dependency layers, including transitive dependencies that are often invisible. License categorization according to the Blue Oak Council scheme simplifies compliance assessment. Project health evaluation for open source projects provides insight into sustainability risks.

Audit-ready documentation

Generating documentation for auditors and Notified Bodies requires specific formats and comprehensive content. EMETHRA produces SBOM in standard formats including SPDX (ISO 5962:2021) and CycloneDX 1.5. Vulnerability reports are prioritized by CVSS severity to focus attention on the most critical issues. License analysis includes assessment of commercial compatibility. Automatic NOTICE.txt generation supports attribution compliance for open source licenses.

Evidence for regulators

When regulators or auditors request evidence, organizations must be able to provide it promptly and in appropriate formats. EMETHRA generates Annex VII technical documentation automatically, reducing manual effort. Analysis history demonstrates continuous monitoring rather than point-in-time assessments. Exportable PDF reports support formal audit processes. Built-in retention meets CRA requirements without requiring separate archive systems.

---

Regulatory references:

• CRA Article 8 - Due diligence
• NIS2 Article 21 - Risk management measures
• Blue Oak Council - License List
• SPDX ISO 5962:2021