Duty of care in practice: what NIS-2 requires of companies
The NIS-2 Directive (EU) 2022/2555 changes cybersecurity duties for a large number of companies in Europe. It covers so-called essential and important entities in sectors such as energy, transport, health, digital infrastructure, manufacturing, food and digital services. In Germany transposition runs through national laws, with the Federal Office for Information Security (BSI) shaping supervision. Software vendors supplying such companies notice early: customers ask about security measures, supply chains and evidence.
At its core NIS-2 requires appropriate diligence in risk management. Article 21 obliges entities to take appropriate and proportionate technical, operational and organisational measures. These include policies on risk analysis and information system security, incident handling, business continuity, supply chain security including security-related aspects of relationships with suppliers, security in acquisition and development of systems, assessment of the effectiveness of measures, and cryptography and access control. Under Article 20 management bodies bear direct responsibility for approving and overseeing these measures.
For daily practice this means: diligence must be demonstrable. Having measures is not enough, you must show they apply and work. That is where the term evidence comes in: reliable data and documents proving to an auditor, a supervisor or your own management that a duty was taken seriously. Evidence is neither a certificate nor a seal but the material from which proofs are built.
How does the digital signature fit in? Signed documents are in many processes the point where responsibility is formalised: contracts with service providers, data processing agreements, policies acknowledged by employees, approvals of security concepts, acceptance of measures. If these transactions run digitally and traceably, a trace picture arises that evidences diligence: who confirmed what when, in which version, with which identification? That is evidence for the duty of care.
The one hard distinction of this article: an audit trail proves that something happened. It does not prove that it was sufficient. NIS-2 asks for both. A company can prove gaplessly that every employee acknowledged the security policy and still have an unsuitable policy. The signature supplies the first proof, not the second. Confusing the two risks equating quality of evidence with quality of measures.
Equally clear: there is no NIS-2 certification for signature APIs, and we claim none. Neither Sign2x nor any other vendor can give you a seal fulfilling your due diligence duties. What we can deliver is a building block: a signing flow that logs processes in a structured way and puts the data in your own hands. How you use this data for audits remains your task and that of your security and compliance team.
What the audit trail can do: evidence from signing transactions
A signature audit trail arises from the events a signing flow produces per transaction: created, sent, opened, identified, signed, declined, expired, revoked. With time, role, reference and document checksum a chain results that makes a process reconstructable. The API delivers the data by webhook to your system, where it sits in your data store, independent of a vendor's portal. How to design that cleanly technically is described in webhook state management for e-signature events.
What can this chain evidence in the NIS-2 context? First, taking responsibility: management bodies and responsible persons confirmed concepts, policies or risk decisions, with date and person. That supports the proof that management met its responsibility under Article 20 without replacing it. Second, supply chain relationships: contracts with ICT service providers, security annexes and data processing agreements were concluded in proper form, in which version and by whom. Third, training and acknowledgement: employees noted policies, and acknowledgement is attributable.
Fourth, integrity: because the signature is bound to the document version, you can show a policy was confirmed in exactly this version. Later changes are detectable. Fifth, time reference: you can show when measures were decided and confirmed, for instance relative to an incident or an audit. Sixth, consistency: if all relevant transactions run through the same flow, the data situation is uniform, easing reports and audits. Seventh, exportability: you can prepare evidence for third parties without collecting screenshots in a foreign portal.
For the trail to deliver this, it needs a good schema. Minimum fields are transaction ID, event type, UTC time, acting role, document hash and signature level. With AES and QES the identification result is added. Use your own identifiers for tenant, document type and business context so you can filter events later, such as “all acknowledgements of the information security policy in the third quarter”. Without such references you have data but no ability to answer.
For choosing the signature level: SES or AES suffices for many internal acknowledgements and contracts, QES only where form or requirements demand it. Sign2x supports SES, AES and QES. We are not a QTSP, QES runs through a partner QTSP such as Sign8. Important for your evidence is to record and justify the chosen level per document type. Help with classification is in AES vs QES via API.
The hosting question also belongs in the evidence chain. Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. For supply chain security that is clearly nameable information: location, operator and legal framework can be recorded in your supplier documentation. Why location alone is not enough is explained in Cloud Act vs data sovereignty. It is a statement about operations and jurisdiction, not a certification of your product.
What it does not replace: naming limits honestly
An audit trail is only one element of security management. It does not replace risk analysis. Whether your measures are appropriate depends on which risks you identified, assessed and treated. That is a substantive process with expertise that cannot be replaced by logs. Nor does it replace technical safeguards: encryption, access control, hardening, monitoring, vulnerability management and contingency exercises must work independently.
It also does not replace incident reporting. Article 23 requires multi-stage reporting of significant incidents to the competent authority, with an early warning within 24 hours, a notification within 72 hours and a final report. A signature trail can help with reconstruction if an incident affects document processes, but it triggers neither detection nor assessment nor reporting. For that you need your own processes and responsible people.
It further does not replace supplier assessment. That a contract with a service provider was signed cleanly says nothing about whether the provider works securely. Assessing vendors, including security questionnaires, certificates, audits and contracts with security requirements, remains a task of its own. The signature proves that contracts were concluded, not that they are fulfilled. Guidance on information security requirements is available from the BSI, and for EU-wide perspectives from ENISA.
And it does not replace legal advice. Which duties apply to your company, whether you are an essential or important entity, which deadlines you must observe and what national transposition looks like, you clarify with legal counsel and your compliance. We explain technology, not the legal situation in an individual case. Anyone asking whether a particular measure is “NIS-2-compliant” gets the counter-question by what standard and by whom that is assessed, because no such seal exists.
Finally it does not replace a culture of diligence. Evidence arises from processes that are lived. If policies are only signed and never read, the trail is formally complete and substantively empty. Auditors spot that quickly, and more importantly an incident does too. Use the signature as part of a process creating understanding, for instance with short training before acknowledgement and room for questions.
Working with DORA: two regimes, one evidence foundation
Many companies affected by NIS-2 are subject to other regimes at the same time. Financial entities must meet DORA (EU) 2022/2554, which as sector-specific law on digital operational resilience takes precedence over general rules. For ISVs serving both worlds a common foundation pays: if your event stock is structured, you can use it equally for DORA proofs on the ICT supply chain and for NIS-2 proofs on due diligence.
The differences lie in focus. DORA targets ICT risk and the minimum contractual content that Article 30 sets for ICT third-party providers. NIS-2 targets cybersecurity measures and supply chain security more broadly. Common to both is the expectation that you can evidence what you promised. DORA Article 30 and the signature audit trail shows how the same events serve supply chain proofs. The principle is identical: separate promise and proof and provide for the proof.
In practice you design an evidence schema once and use it for both regimes. Events are stored, tagged with tenant and document type references and made exportable. Per regime you define queries and reports: for DORA, for example, contracts with ICT service providers and their locations, for NIS-2, for example, policy acknowledgements and supplier contracts with security annexes. The data basis stays the same, the view changes.
One warning: do not mix the regimes in communication. When a customer asks about DORA, do not answer in NIS-2 wording, and vice versa. Both regimes have their own terms, duties and responsibilities. Your advantage arises not from blending them but from a common technical foundation and precise answers per regime. An overview of sovereignty in the supply chain is in Open Sovereign Cloud for the e-signature API.
Checklist for ISVs: preparing NIS-2-adjacent evidence
The list below is not legal advice. It helps design the technology so that NIS-2-related customer questions can be answered without haste.
- Inventory document types: which transactions in your product are diligence-relevant, such as supplier contracts, policy acknowledgements, approvals?
- Set levels: assign SES, AES or QES per document type and record the justification.
- Define the event schema: transaction ID, event type, UTC time, role, document hash, level, identification result.
- Persist events: store webhook events in your own data store, idempotently and with history.
- Assign references: tenant, document type and business context for later reports.
- Test export: check whether you can prepare evidence for third parties completely and traceably.
- Document the supply chain: record hosting on OSC and the partner QTSP role in your documentation.
- Communicate limits: state clearly that the trail delivers evidence and replaces no certification.
Once you have worked through these points a sound basis stands. Further orientation is offered by the developer hub with documentation and sandbox, the help centre for terms and the use cases page for practical examples. The Sign2x quiz supports a first classification of your situation, and more articles are in the Sign2x blog. For a conversation about your situation use contact.
Discuss NIS-2 evidence with us
Related articles: AML-ready signature API for ISVs and QTSP partners for ISVs. Legal basis of the signature levels in the eIDAS Regulation.
Frequently asked questions
Is there a NIS-2 certification for signature APIs?
No. NIS-2 provides no certification for signature APIs. An audit trail supplies evidence for diligence proofs but replaces neither risk analysis nor technical measures.
What does a signature audit trail prove in the NIS-2 context?
That certain transactions took place: acknowledgements, approvals, contract conclusions, with time, role and document version. It does not prove that the underlying measures were sufficient.
Does the trail replace incident reporting?
No. It can help with reconstruction but triggers neither detection nor assessment nor reporting. You need your own processes for that.
How do NIS-2 and DORA relate on evidence?
Both expect provable commitments. A shared event schema serves as the data basis from which you generate separate queries and reports per regime.
Where is Sign2x hosted and is it a QTSP?
On the Open Sovereign Cloud (OSC) from T-Systems. Sign2x is not a QTSP, for QES the qualification runs through a partner such as Sign8.
