What DORA and NIS2 require (briefly)
DORA (Digital Operational Resilience Act) targets the financial sector and requires provable operational resilience including IT third-party risk. NIS2 extends cybersecurity obligations to many more sectors (critical infrastructure and beyond). Both demand documented processes, defined response times and provable management of service providers.
For hardware that means: maintenance must be demonstrably governed — with contracts, SLAs and escalation paths an auditor can check.
Why maintenance is a compliance topic
Failing hardware without secured maintenance is an operational risk — exactly what DORA and NIS2 address. What matters is not whether the vendor or a third party maintains it, but that maintenance is documented, backed by defined SLAs and provable.
The regulations require risk management and evidence, not a specific contract partner.
Documentation & SLA evidence
Auditors want to see: which systems are under maintenance? What response and recovery times apply? How is spare-parts supply secured? How do escalation and incident documentation work? A good maintenance contract provides this evidence by default.
Gap-free coverage of the critical fleet is essential — including hardware operated past EOSL.
Third-party maintenance & compliance
Third-party maintenance is compliant as long as the contract covers the required elements: defined SLAs, original spare parts, documented processes and, on request, chain-of-custody evidence. Audit-ready TPM contracts are usually accepted by auditors without discussion.
The advantage: even EOSL hardware the OEM no longer maintains can be kept in compliant, provable operation this way.
Audit preparation: the short checklist
First: install-base list of critical systems with maintenance status. Second: contracts with defined SLAs to hand. Third: proof of spare-parts supply. Fourth: documented escalation and incident processes. Fifth: coverage evidence for EOSL systems too.
Document these five points cleanly and you go into the audit relaxed.