EU CRA Security Support Periods with ISO 27001

It is 08:20 on a Tuesday and the product owner of a connected B2B gateway receives a message from a regulated customer: “Please confirm the security support period for firmware version 4.6, the vulnerability response SLA, and whether the device will remain eligible for security updates during our five-year service contract.”

By 09:00, procurement has forwarded a DORA due diligence questionnaire. By 10:15, legal asks whether the advertised support period is consistent with customer contracts. By 11:00, the CISO is pulled into a NIS2 supplier-risk review because the product is used by a managed service provider in the EU. After lunch, privacy asks whether an unsupported API library in the product could affect personal data security under GDPR.

The uncomfortable truth appears quickly. The company has a roadmap, a patch process, a release calendar and a customer support portal, but it does not have governed security support period evidence.

That gap matters. Under the EU Cyber Resilience Act, the security support period is not just a product label. It is a lifecycle commitment that affects vulnerability handling, update availability, supplier dependency management, customer communication, contractual representations and post-market monitoring. For SaaS vendors, device manufacturers, software publishers, cloud suppliers and ICT service providers, the support period becomes a compliance object that auditors and regulated buyers will test.

The practical answer is not another disconnected compliance spreadsheet. The answer is to govern the security support period inside an ISO/IEC 27001:2022 information security management system, then map the same evidence to NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-style audit expectations.

That is the Clarysec operating model: use the ISMS as the evidence engine, use enforceable policies to define responsibilities, use Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to build traceability, and use Zenith Controls: The Cross-Compliance Guide Zenith Controls as the cross-compliance compass.

Why the security support period is now an audit object

A security support period answers a simple question: for how long will the manufacturer provide security updates, vulnerability remediation, mitigation guidance and related customer support for a product or product version?

In practice, that answer depends on many moving parts:

• Product architecture and maintainability
• Third-party component and open source dependency support
• Supplier and cloud service commitments
• Vulnerability intake, triage, remediation and disclosure processes
• Release engineering and testing capacity
• Customer contract terms and regulatory obligations
• Incident response and service-recipient notification pathways
• Evidence retention and approval records

If a manufacturer promises five years of security support, but a critical cryptographic library reaches unsupported status after three years, the support period becomes a risk decision. If a customer is a financial entity subject to DORA, the same support period becomes part of ICT third-party assurance. If the product processes personal data, unsupported software may become part of GDPR security-of-processing accountability. If the product supports an essential or important entity under NIS2, lifecycle security becomes a supply-chain security issue.

NIS2 makes this governance angle explicit. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and receive training. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, secure acquisition, secure development and maintenance, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene, cryptography, access control, asset management and authentication. Article 23 adds staged significant incident reporting obligations.

DORA creates a similar pressure for financial entities. It requires ICT risk management, digital operational resilience testing, incident management and ICT third-party risk governance. DORA Article 28 covers ICT third-party risk management principles, and Article 30 requires written contractual arrangements with clear service descriptions, security measures, incident assistance, audit rights, termination rights and exit arrangements.

GDPR adds the privacy layer. If the product processes personal data, controllers and processors need appropriate technical and organisational measures under Article 32, contractual clarity under Article 28, and breach assessment and notification readiness under Articles 33 and 34.

This is why the CRA security support period must be governed like an ISMS control family, not handled as an isolated product-management field.

ISO 27001 as the control backbone for CRA security support periods

ISO/IEC 27001:2022 is valuable because it is scalable, risk-based and management-system oriented. It requires the organization to define context, interested parties, scope and interacting processes, then translate legal, regulatory and contractual requirements into risk assessment, risk treatment, operational controls and evidence ISO/IEC 27001:2022.

For security support period governance, this means the organization should:

1. Identify products, versions, modules, cloud services and dependencies in scope.
2. Identify interested parties, including customers, regulators, distributors, importers, integrators, processors, subprocessors, incident response partners and suppliers.
3. Record legal, regulatory and contractual support obligations.
4. Assess risks that could prevent support commitments from being met.
5. Select controls for vulnerability management, secure development, supplier assurance, incident management, business continuity, privacy and documented information.
6. Create Statement of Applicability notes that explain why controls apply.
7. Review the support period when architecture, supplier dependencies, threat exposure or customer commitments change.

Zenith Controls identifies three topic-related ISO/IEC 27002:2022 controls as central anchors for this governance problem: 5.31 Legal, statutory, regulatory and contractual requirements, 8.8 Management of technical vulnerabilities, and 8.25 Secure development life cycle. They are not the only controls involved, but they are the governance spine.

The key is traceability. A product support period should be traceable from obligation to risk scenario, from risk scenario to selected controls, from controls to policy requirements, and from policy requirements to evidence.

Zenith Blueprint, Risk Management phase, Step 13, describes this traceability discipline directly:

“Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.”

Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability Zenith Blueprint

For a CRA security support period, the Statement of Applicability should not merely say “vulnerability management applies.” It should explain that vulnerability management applies because the company has CRA lifecycle commitments, NIS2 secure development and supply-chain expectations, DORA customer due diligence demands, GDPR security obligations where personal data is processed, and contractual support promises.

From support promise to governed lifecycle

A manufacturer-defined security support period should pass six governance tests.

First, it must be defined. The organization needs a standard taxonomy, such as active support, security-only support, extended support, limited support and unsupported. Each status should explain update availability, vulnerability handling, customer communication and escalation paths.

Second, it must be risk-assessed. Five years of support for a cloud-managed SaaS product with controlled update channels is different from five years for an embedded device with field constraints, third-party chip dependencies and customer-managed deployment windows.

Third, it must be approved. Product, security, legal, privacy, customer support and accountable management should approve the baseline period and exceptions.

Fourth, it must be communicated. Customers should understand support start date, end date, update method, vulnerability reporting channel, remediation expectations, end-of-support consequences and available extension options.

Fifth, it must be monitored. Dependencies change. Suppliers discontinue libraries. Vulnerabilities appear. Customer environments shift. Support-period governance must include component lifecycle monitoring, supplier review, vulnerability feeds, patch logs, release testing and incident learnings.

Sixth, it must be evidenced. If an auditor, regulator or regulated customer asks for proof, the organization should show the compliance register, product support register, risk assessment, SoA mapping, vulnerability register, patch records, supplier reviews, release approvals and customer notices.

Clarysec policies make this practical. The Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy requires:

“All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).”

Source: Legal and Regulatory Compliance Policy, Policy Implementation Requirements, clause 6.2.1 Legal and Regulatory Compliance Policy

For SMEs, the equivalent discipline starts with a simpler register. The SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME states:

“The GM must maintain a simple, structured Compliance Register listing:”

Source: Legal and Regulatory Compliance Policy-sme, Governance Requirements, clause 5.1.1 Legal and Regulatory Compliance Policy - SME

A support-period commitment should be in the compliance register if it is driven by law, customer contract, sector regulation or regulated buyer expectation. It should not live only in release notes or marketing copy.

Build a CRA security support period register in one workshop

Imagine a SaaS vendor that sells a connected analytics appliance to EU logistics providers and financial-sector clients. The product includes an embedded agent, a cloud API, a mobile admin app and several open source libraries. Sales wants to promise five years of security support for each major appliance version.

The CISO can run a focused workshop with product, engineering, legal, privacy and supplier management.

Step 1: Create the support-period register

Create one row per product version and include:

• Product and version
• Release date
• Support start date
• Standard security support end date
• Extended support option
• Update delivery method
• Vulnerability disclosure channel
• Critical patch target
• Data processing role, such as controller, processor or both
• Critical suppliers and components
• Customer sectors impacted
• Risk owner
• Approval date
• Evidence location

This register becomes documented information under the ISMS. Zenith Blueprint, ISMS Foundation and Leadership phase, Step 6, gives the document-control expectation:

“Documents should have proper identification (a title, perhaps a document number or unique identifier, an author), an appropriate format, and review & approval for adequacy prior to use.”

Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, ISMS Foundation and Leadership phase, Step 6: Documented Information and Building the ISMS Library Zenith Blueprint

Clarysec’s Enterprise PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy applies similar evidence principles to privacy documentation:

“[All] The Privacy Lead / PIMS Manager MUST assign a document identifier, owner, version number, approval status, effective date, and review date in REG12 before publishing PIMS documented information.”

Source: PIMS Documented Information Evidence Management Policy, Creation, approval, versioning, and publication, clause 4.2.1 PIMS Documented Information Evidence Management Policy

Even if the support-period register is not a privacy document by default, the same discipline applies: owner, version, approval, effective date and review date.

Step 2: Link support promises to risk treatment

For each product version, create risk scenarios such as:

• A critical vulnerability is discovered in a supported version, but engineering capacity is unavailable.
• A third-party component becomes unsupported before the declared security support period ends.
• A supplier changes hosting location or subcontractor and affects update delivery.
• A vulnerability affects personal data and triggers privacy breach assessment.
• A regulated financial customer requires evidence of ICT third-party resilience.

ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 provide the planning engine: identify risks, assess likelihood and consequences, assign risk owners, select treatments, compare selected controls against Annex A, produce the Statement of Applicability and obtain approval of residual risk.

For the risk “unsupported component before support end date,” the risk record should include ISO/IEC 27002:2022 controls 5.31, 8.8 and 8.25, plus supplier controls such as 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, and 5.22 Monitoring, review and change management of supplier services.

Step 3: Set vulnerability and patch evidence rules

A support period is credible only if vulnerability management works during that period.

The SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME sets an aggressive requirement for urgent exposure:

“Critical patches must be applied within 3 days of release, especially for internet-facing systems”

Source: Vulnerability and Patch Management Policy-sme, Policy Implementation Requirements, clause 6.1.1 Vulnerability and Patch Management Policy - SME

It also requires audit-ready records:

“A patch log must be maintained and reviewed during audits and incident response activities”

Source: Vulnerability and Patch Management Policy-sme, Governance Requirements, clause 5.4.1 Vulnerability and Patch Management Policy - SME

For enterprise environments, the Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy requires:

“A centralized Vulnerability Management Register must be maintained by the Security Operations Team and reviewed monthly by the CISO or delegated authority.”

Source: Vulnerability and Patch Management Policy, Governance Requirements, clause 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, Controls in Action phase, Step 19, explains the operational expectation behind ISO/IEC 27002:2022 control 8.8:

“Stay informed about new security bugs (via vendor alerts, CVE feeds, etc.) for your software and hardware. Assess which are relevant (do we use this software? how critical is the bug?) and promptly apply fixes or mitigations.”

Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 19: Technological Controls I Zenith Blueprint

Every supported product version needs a vulnerability evidence trail: intake, relevance analysis, severity, affected versions, remediation plan, fix release, mitigation guidance, customer communication and closure approval.

Step 4: Connect secure development to support duration

Security support starts before release. It depends on development practices that make the product maintainable.

The SME Secure Development Policy-sme Secure Development Policy - SME states:

“Components must be updated regularly when security patches are released. If a critical vulnerability is identified, the component must be upgraded or replaced immediately.”

Source: Secure Development Policy-sme, Policy Implementation Requirements, clause 6.6.3 Secure Development Policy - SME

The SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME requires contracts and requirements to:

“specify obligations for vulnerability disclosure, response times, and patching.”

Source: Application Security Requirements Policy-sme, Governance Requirements, clause 5.3.2 Application Security Requirements Policy - SME

If the company promises support until 2031, the architecture must support maintainable updates, dependency replacement, secure build pipelines, regression testing and emergency releases. ISO/IEC 27002:2022 controls for secure development, secure architecture, secure coding, security testing, outsourced development, environment separation and change management become support-period enablers.

One evidence set for CRA, NIS2, DORA and GDPR

The same support-period evidence can satisfy different regulatory conversations, but each framework asks the question differently.

Supplier dependency is often where support commitments fail. The Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy requires:

“Supplier Dependency Register: The VMO shall maintain an up-to-date register of all critical suppliers, including details such as services/products provided; whether the supplier is sole-source; available alternate suppliers or substitutability; current contract terms; and an assessment of the impact if the supplier were to fail or be compromised.”

Source: Supplier Dependency Risk Management Policy, Implementation Requirements, clause 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, Controls in Action phase, Step 23, warns that auditors will inspect supplier agreements and supplier monitoring evidence:

“Auditors will review sample contracts or service agreements. They’re looking for explicit information security clauses, such as breach notification timelines, access restrictions, data processing obligations, encryption requirements, or audit rights.”

Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 23: Organizational controls Zenith Blueprint

For DORA customers, this is critical. Contracts for ICT services supporting critical or important functions need clear service descriptions, subcontracting conditions, security measures, incident assistance, audit and inspection rights, termination rights and transition arrangements. A supplier that cannot support those commitments may prevent the manufacturer from making a credible support-period promise.

Control crosswalk for audit-ready support period governance

This crosswalk lets security, legal, product and sales teams speak one language. The support-period register is not just CRA evidence. It is supplier assurance for NIS2, third-party assurance for DORA, security-of-processing support for GDPR and a governance artifact for ISO 27001 certification.

The privacy angle: when unsupported becomes unsafe

Security support period governance is not only a cybersecurity issue. If the product stores, transmits or processes personal data, unsupported software can become a privacy risk.

GDPR applies to processing in the context of an EU establishment and can also apply to non-EU organizations offering goods or services to individuals in the EU or monitoring their behavior. It defines personal data broadly and treats a personal data breach as a security breach causing accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to processed personal data.

For support-period governance, privacy teams need to know which product versions process PII, which systems are still supported, and whether vulnerabilities affect confidentiality, integrity or availability of personal data.

Clarysec’s Enterprise PII Security Access Control Policy PII Security Access Control Policy requires:

“[Both] The System Owner / Application Owner MUST record vulnerability assessment coverage for systems processing PII in REG12 at least quarterly and after material technical change.”

Source: PII Security Access Control Policy, Secure configuration and vulnerability management, clause 4.7.4 PII Security Access Control Policy

The Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy adds ongoing monitoring for high-risk privacy relationships:

“[All] The Vendor / Procurement Owner MUST monitor active high-risk processor and subprocessor relationships quarterly and other active PII processor and subprocessor relationships annually against due diligence conditions, contract status, assurance status, open issues, and review dates in REG08.”

Source: Processor Subprocessor Third Party Privacy Management Policy, Ongoing monitoring, assistance, disclosure interface, and exit, clause 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

When a vulnerability becomes an incident, the Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy requires multi-framework trigger assessment:

“[Conditional] The Privacy Lead / PIMS Manager MUST evaluate applicable legal, sectoral, financial-sector, cybersecurity, contractual, customer, and service-recipient reporting triggers for each high-impact PII incident and record the applicability outcome in REG01, REG08, and REG10.”

Source: PII Incident Breach Management Policy, Classification and breach assessment, clause 4.2.6 PII Incident Breach Management Policy

This is the practical overlap between CRA support commitments, NIS2 incident communication, DORA major ICT incident handling and GDPR breach accountability.

How auditors test the same support-period process

A strong support-period governance process should survive multiple audit styles. The evidence does not change much, but the auditor’s lens does.

NIST CSF 2.0 is useful as a communication layer because its GOVERN Function includes legal, regulatory, contractual and privacy obligations, risk management objectives, risk appetite, roles, policies and oversight. Its supply-chain outcomes cover supplier strategy, criticality, contracts, due diligence, monitoring, incident coordination and end-of-relationship provisions.

COBIT and ISACA-style auditors often focus on governance design: who owns the decision, what process is defined, what metrics show performance, how exceptions are approved, and how continual improvement is handled.

Clarysec’s Enterprise Information Security Policy Information Security Policy captures the auditability principle:

“All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.”

Source: Information Security Policy, Policy Implementation Requirements, clause 6.6.1 Information Security Policy

That is the sentence every security support period should be able to satisfy.

Extend, shorten or end support without creating false assurance

The hardest governance moments are not at product launch. They happen when reality changes.

You may need to extend support because regulated customers depend on the product, migration is not feasible, or a sector customer has contractual continuity needs. You may need to shorten or restrict support because a supplier withdraws security maintenance, a component becomes impossible to patch, a platform reaches technical limits, or the product architecture cannot safely support a vulnerability class.

A controlled support-period change should include:

• Change trigger, such as supplier end-of-life, critical vulnerability, customer contract or regulatory change
• Impacted products, versions, customers and sectors
• Personal data and critical-service impact analysis
• Supplier and component feasibility review
• Risk assessment and residual risk decision
• Updated support-period register
• Updated customer notice and contractual position
• Updated SoA notes where controls or obligations change
• Management approval and review date

The Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy is useful when the change is vulnerability-driven:

“A remediation or mitigation plan shall be developed for all confirmed vulnerabilities. Implementation of the fix shall be prioritized based on severity. For example, critical vulnerabilities shall be fixed or mitigated within 14 days where feasible, or sooner where active exploitation is detected, while lower-severity issues shall be addressed within a reasonable timeframe.”

Source: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clause 6.6 Coordinated Vulnerability Disclosure Policy

If a full fix cannot be delivered immediately, compensating controls, disabled functionality, increased monitoring or customer configuration guidance may be acceptable temporarily, but the decision must be documented and communicated.

Practical Clarysec checklist for support-period readiness

Use this checklist before publishing or renewing any CRA security support period commitment.

• Is the product and version listed in the support-period register?
• Is the support end date approved by product, security and accountable management?
• Are legal, regulatory and contractual drivers mapped in the compliance register?
• Is the support-period risk scenario included in the risk register?
• Are controls mapped in the Statement of Applicability, including 5.31, 8.8 and 8.25 where applicable?
• Are critical suppliers and components mapped in the supplier dependency register?
• Is there evidence that components can be patched or replaced during the support period?
• Are vulnerability intake, triage, remediation and disclosure responsibilities defined?
• Are critical patch SLAs aligned with policy and customer contracts?
• Are patch logs, release records and vulnerability decisions retained?
• Are personal-data systems covered by vulnerability assessment evidence where PII is processed?
• Are customer notices, support statements and contractual terms consistent?
• Is there a process to extend, shorten or end support with risk approval?
• Are management reviews receiving support-period risk, supplier, vulnerability and incident inputs?
• Can evidence be produced within 48 hours for a customer audit or regulator inquiry?

The Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy reinforces management-review discipline for privacy programs:

“[Both] Top Management MUST review PIMS nonconformity, corrective action, monitoring result, audit result, privacy risk, supplier assurance, and interested-party change inputs in REG12 during each management review.”

Source: PIMS Monitoring Audit Improvement Policy, PIMS management review, clause 4.3.5 PIMS Monitoring Audit Improvement Policy

For security support period governance, the same review rhythm should apply across the ISMS: vulnerabilities, patch performance, supplier assurance, customer commitments, incidents, support exceptions and corrective actions should feed management review.

Make the security support period defensible

The EU Cyber Resilience Act changes the psychology of product security. It pushes manufacturers and software providers to think beyond release day. The security support period becomes a lifecycle promise that must be engineered, governed, monitored and evidenced.

For CISOs, the lesson is clear: do not let the support period sit only in product marketing. For compliance managers, do not build a separate CRA evidence silo. For auditors, test whether support commitments are traceable to risk, controls, suppliers, incidents and documented approvals. For business owners, remember that a credible support period can become a market advantage, especially when selling to NIS2-regulated sectors, DORA financial entities and privacy-sensitive customers.

Clarysec helps organizations operationalize this through:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint for building ISMS traceability, documented information, SoA mapping and audit readiness
• Zenith Controls: The Cross-Compliance Guide Zenith Controls for mapping ISO/IEC 27002:2022 controls to NIS2, DORA, GDPR, NIST CSF 2.0 and audit expectations
• Enterprise and SME policy packs for vulnerability management, secure development, legal compliance, supplier dependency, privacy evidence and incident response
• Practical registers and evidence workflows that turn support-period promises into auditable governance

Your next step is simple: pick one flagship product version and build its security support-period evidence file. Map the obligation, approve the support period, test the vulnerability process, validate supplier dependencies, confirm customer communication and retain the records.

If you can defend one product, you can scale the model. If you cannot defend one product, the gap is not documentation. It is governance.

Download the Zenith Blueprint, use Zenith Controls to map your evidence, or request a Clarysec readiness assessment to turn CRA security support periods into audit-ready ISO 27001 governance.