Cybersecurity clauses in contracts: ENS, NIS2 and DORA.

In a technology contract, you need to require five things: a valid certification or conformity declaration whose scope covers the service (ENS, the Spanish National Security Framework, or ISO 27001), incident notification with specific deadlines, a right of audit, verifiable documented evidence, and controlled subcontracting with an exit strategy. ENS, NIS2, DORA and the AI Act each add their own nuances, which I cover regulation by regulation below.

I review technology contracts from both sides of the table: the buyer's and the vendor's who wants to win a public tender. The pattern repeats itself: pages about pricing and service levels, followed by one generic paragraph on security that commits to nothing. That paragraph decides who foots the bill when there's an incident. Here's what criterion to demand, what evidence proves it, and what clause captures it.

Which cybersecurity clauses to require in a contract (quick answer)

If you can only negotiate five things, negotiate these:

• Demonstrable conformity. A valid certification or conformity declaration (ENS, ISO 27001) whose scope covers the contracted service, maintained for the entire term of the contract.
• Incident notification with deadlines in hours. Not "diligent notification" — hours from detection, a specific channel, and a minimum content for the notice.
• Right of audit. The ability to audit the vendor, directly or through a third party, and access existing audit reports.
• Documented evidence. Security policies, incident management procedures, business continuity tests and audit results, kept up to date periodically.
• Controlled subcontracting and an orderly exit. Prior approval of relevant subcontractors, return and certified deletion of your data, and an exit plan that keeps you from being locked in.

Everything else is a nuance of these five blocks depending on which regulation applies to you.

Why you're responsible for what your vendor signs

Outsourcing a service doesn't outsource the risk. That idea runs through the whole of Spain's cybersecurity regulation, and each framework states it in its own way:

• GDPR. Article 28 requires data processors that offer sufficient guarantees and a processing agreement with minimum content; Article 32 requires measures appropriate to the risk. If your processor fails, your company remains the one accountable to the AEPD (Spain's data protection authority).
• NIS2. The NIS2 directive requires essential and important entities to manage supply chain security: you must assess the risk introduced by your direct vendors.
• DORA. The DORA regulation makes ICT third-party risk a core obligation for financial entities, which must keep a register of their agreements with technology providers and include specific content in those contracts.
• ENS. Royal Decree 311/2022 also reaches private companies that provide services to the public sector, with specific measures on outsourcing external services and protecting the supply chain.

The consequence is the same across the board: "it was my vendor's fault" is not a defence before the regulator. The contract turns your legal responsibility into obligations you can enforce against the vendor.

Criteria, evidence and clauses by regulation: the master table

The table summarises what I look for when reviewing a contract: the criterion, the evidence that proves it, and the clause that captures it. Full sample wording follows below.

ENS clauses: conformity, category and scope of the declaration

ENS comes into play when the contract supports services for a public Administration: software, hosting, electronic offices, system maintenance. Tenders increasingly demand ENS conformity as a condition for contracting, and the obligation cascades down to the awarded vendor and its subcontractors. If you're on the vendor side, I cover this in my guide on ENS for public Administration vendors.

What the clause should cover:

• Conformity in the correct category. "Having ENS" isn't enough: the certification or declaration must match the category (BASIC, MEDIUM or HIGH) of the system the service supports.
• Scope that covers the service. The most common mistake: genuine certificates whose scope doesn't include the platform or data centre the service is actually delivered from.
• Maintained throughout the term. Renewing conformity and reporting immediately any loss, suspension or change of scope.

Sample wording: "The Vendor evidences its conformity with the Spanish National Security Framework (ENS, Royal Decree 311/2022) in category [BASIC/MEDIUM/HIGH] by means of a certification whose scope covers the services under this contract, and undertakes to keep it valid throughout its term, reporting within [X] business days any loss, suspension or modification of its scope."

NIS2 clauses: supply chain and incident notification

If your company is an essential or important entity under NIS2, your direct vendors are part of your risk analysis: the directive lists supply chain security among its mandatory measures. You also face strict deadlines for reporting significant incidents — an early warning within the first 24 hours and a notification within 72 — so your vendor needs to alert you well before that.

What the clause should cover:

• Measures proportionate to the risk. A commitment to apply measures consistent with what the regulation demands of you, not an open-ended "reasonable security".
• Notification in hours, not days. A deadline from detection that leaves you enough margin for your own early warning, with minimum content: what happened, what it affects, and what's been done.
• Cooperation in the investigation. Assisting with the incident analysis, preserving evidence, and providing whatever information the competent authority requests.

Sample wording: "The Vendor shall notify the Client of any security incident that affects or may affect the service within a maximum of [X] hours of its detection, through the designated channel, including a description, the systems affected and the measures adopted, and shall cooperate in the investigation and in any mandatory notifications to the authorities."

DORA clauses: critical ICT providers and exit strategy

DORA is the most contract-focused of the four regulations: it requires financial entities to keep a register of information on their agreements with ICT providers and sets out content those contracts must include. If you sell technology to banks, insurers or payment institutions, these requirements will show up at the negotiating table; for critical or important functions, the bar rises further.

What the clause should cover:

• Full description of the service. Functions covered, the locations it's delivered from, and where the data processed is located.
• Service levels and incident assistance. Measurable indicators and an obligation to assist whenever an incident affects the service.
• Access, inspection and audit rights. For the entity and, where applicable, for its supervisors.
• Exit strategy. Notice periods, assisted transition and data reversibility, without interrupting the function the service supports.

Sample wording: "Upon termination of the contract for any reason, the Vendor shall provide the assistance necessary for an orderly transition of the service over [X] months, including the return of data in a structured, commonly used format, the certified deletion of copies, and the maintenance of service levels throughout the transition."

AI Act clauses: technical documentation and use of AI systems

Regulation (EU) 2024/1689, the AI Act, applies on a phased basis; the bulk of obligations for high-risk systems land in August 2026, as I summarise in my guide to the AI Act obligations. For whoever's contracting, the problem is twofold: your vendor may be using AI without you knowing it, and you, as the deployer of the system, take on your own obligations around oversight and correct use.

What the clause should cover:

• Declaration of AI use. The vendor discloses whether the service incorporates AI systems, which ones and for what purpose, and reports any relevant changes.
• Documentation and instructions for use. For high-risk systems, the technical documentation and instructions the regulation requires, so you can meet your own obligations when deploying them.
• Support for human oversight. Activity logs, the ability to intervene, and traceability of decisions.

Sample wording: "The Vendor declares the artificial intelligence systems incorporated into the service in Annex [X], undertakes to keep that list up to date and, in respect of systems classified as high-risk under Regulation (EU) 2024/1689, to deliver the technical documentation and instructions for use necessary for the Client to meet its own obligations."

How to verify the evidence your vendor gives you

A well-drafted clause is worth nothing if you accept the evidence without checking it. Four quick checks:

• ENS certificate: cross-check it. ENS conformity is public and verifiable; I walk through how to check the list of ENS-certified companies step by step. Verify the entity, category, scope and validity.
• Accredited certification body. Verify that the body that issued the certificate is accredited by ENAC for that activity. A "certificate" from a non-accredited body is worthless paper.
• ISO 27001 with its scope and its SoA. Ask for the certificate and its Statement of Applicability (SoA): that's where you see which controls it actually applies. A certificate covering a different business unit or data centre doesn't protect you.
• Recent operational evidence. The latest audit report, recent continuity tests and an incident procedure with a review date. Undated documents say more by what they leave out.

Clause checklist by regulation

Use it as a final review before signing, ticking off only the regulations that apply to you.

ENS (the contract supports public sector services):

• ENS conformity in the category required by the tender or the system.
• Certification scope that covers the contracted service.
• Maintained conformity, with notice of any loss or change.
• ENS obligations passed through to subcontractors.

NIS2 (you're an essential or important entity):

• Security measures consistent with your own obligations.
• Incident notification in hours, through an agreed channel and content.
• Cooperation in the investigation and preservation of evidence.
• Vendor included in your supply chain risk analysis.

DORA (you're a financial entity, or you sell to one):

• Description of the service, functions covered and data location.
• Measurable service levels and incident assistance.
• Access, inspection and audit rights.
• Exit strategy with assisted transition and reversibility.
• Contract data ready for your ICT third-party register.

AI Act (the service incorporates or may incorporate AI):

• Declaration of the AI systems used and their purpose.
• Technical documentation and instructions for use for high-risk systems.
• Human oversight capability, logging and traceability.

Cross-cutting (GDPR and common sense):

• A data processing agreement if it processes personal data on your behalf.
• Subcontracting subject to authorisation, with obligations passed through.
• Return and certified deletion of the data at the end of the contract.
• Agreed consequences: penalties, termination, and recovery of any fines.

Mistakes when drafting cybersecurity clauses (and how to avoid them)

Contracts that fail tend to fail for the same reasons:

• Generic commitments with no metric. "The vendor will apply reasonable security measures" commits to nothing verifiable. Replace it with deadlines in hours, recovery objectives and audit frequency: what can't be measured can't be enforced.
• Accepting certificates without checking the scope. The certificate exists, it's valid, and it doesn't cover the service you're contracting. Always ask for the scope document and, for ISO 27001, the Statement of Applicability.
• Copying clauses from another sector without adapting them. Demanding a DORA-style exit strategy from a digital signage vendor drives up the price and wears down the negotiation. Every clause should respond to a real obligation of yours.
• Not agreeing on consequences. Without a penalty, a right of termination, or a way to recover fines caused by the vendor, the clause is decorative.
• Forgetting the subcontracting cascade. Your vendor complies, but its subcontractor doesn't. Obligations must be passed down in writing through the entire chain.
• Demanding more than the market can deliver. Asking for ENS HIGH category when BASIC is enough leaves the tender void or inflates its cost without any real security gain. The requirement should be calibrated to the actual risk.

Conclusion: a clause is only as good as its evidence

A technology contract without verifiable cybersecurity clauses transfers risk straight onto you: you answer to the regulator, and your vendor answers to no one. There's no need to reinvent anything: the five blocks covered in this article — conformity with scope, notification with deadlines, audit, evidence and an orderly exit — cover the vast majority of cases.

If you're preparing a tender, negotiating with a vendor, or you've just been asked for these clauses and don't know where to start, tell me about your case and we'll look at it together, no strings attached.

Does your company need to get certified to meet what these contracts demand? Take a look at my ENS consultancy service for companies that want to bid for or become suppliers to the public Administration.

Frequently asked questions about cybersecurity clauses in contracts

What criteria should I require for NIS2, DORA, ENS and AI Act compliance in contracts?

Four blocks: a valid certification or conformity declaration (ENS, ISO 27001), incident notification commitments with specific deadlines, a right of audit over the vendor, and documented evidence (SoA, audit reports, policies). Each regulation adds its own nuances: ENS requires the correct category, NIS2 requires supply chain management, DORA requires an exit strategy, and the AI Act requires technical documentation for AI systems.

What compliance evidence can I ask a vendor for?

An ENS conformity certificate (verifiable in the list published by the CCN), an ISO 27001 certificate with its Statement of Applicability, third-party audit reports, security and incident management policies, and business continuity test results. Always ask for the scope: a certificate that doesn't cover the contracted service is worthless.

Can I require ENS from a private vendor?

Yes, when the contract supports services for a public Administration: Royal Decree 311/2022 extends its requirements to private vendors that handle public sector information or systems, and tender specifications increasingly spell this out explicitly.

What happens if the vendor breaches the cybersecurity clauses?

It depends on what was agreed: penalties, termination of the contract, and recovery of any fines imposed on you because of it. That's why it pays to agree on verifiable metrics (notification deadlines in hours, RTO/RPO, audit frequency) rather than generic "reasonable security" commitments, which don't create anything enforceable.

Does an ISO 27001 certificate substitute for ENS conformity?

No. They're complementary frameworks but not equivalent: if the tender requires ENS, you need the ENS certification or conformity declaration in the applicable category. ISO 27001 can speed up the process because many controls overlap, but it doesn't replace it.

What incident notification deadline should I agree with a vendor?

Whatever lets you meet your own obligations: the GDPR gives you 72 hours to notify the AEPD, and NIS2 requires an early warning within the first 24 hours, so your vendor needs to alert you well before that. Agree on a deadline in hours from detection, with a designated channel and minimum content for the notice — not a metric-free "diligent notification".