CSDDD, DORA, and NIS2: What New Contract Compliance Obligations Mean For Your Organisation

I spoke about this at Contract Management Day in Antwerp this month. The conversations before and after the session confirmed what I have been hearing across the governance, risk and compliance (GRC) and contract lifecycle management (CLM) space for the past two years: the awareness of this shift is growing, but the operational response has not kept pace.

What Contract Obligations Do CSDDD, DORA, and NIS2 Impose?

CSDDD, DORA, NIS2, the AI Act, and the EU Anti-Corruption Directive all impose specific contract obligations and broader regulatory requirements on organisations. Together, they require contract managers to embed binding conduct commitments, audit rights, operational resilience provisions, and compliance clauses into supplier agreements. When a regulator reviews to see if the due diligence programme is substantive, the contract record is the primary evidence.

Some frame this as a legal drafting concern, something for counsel to resolve at the clause level, but the issue is more structural than that. Across all five instruments, the practical consequences for how compliance is owned and managed are significant.

CSDDD requires in-scope companies to obtain contractual assurances from direct business partners covering human rights and environmental commitments, with those assurances cascading through the supply chain and backed by verification measures. Companies must also establish grievance mechanisms accessible to affected workers and communities, and maintain the right to suspend or ultimately terminate a relationship where adverse impacts cannot be remedied, though termination is explicitly a last resort, not a trigger clause. These are binding obligations under a directive whose transposition deadline is July 2028 and whose compliance date is July 2029.

DORA mandates specific provisions in ICT third-party contracts concluded by financial entities: full service descriptions, performance standards with quantitative targets, incident notification requirements, audit and access rights, and exit provisions. These are enforceable requirements under a regulation already in force.

NIS2 extends cybersecurity risk management into supplier relationships, though its contractual requirements are less prescriptive than DORA’s. For financial entities subject to both, DORA prevails where requirements overlap.

The AI Act introduces mandatory written agreement requirements between providers of high-risk AI systems and third-party suppliers of AI tools, services, or components integrated into those systems, covering the information, technical access, and assistance necessary for regulatory compliance. This obligation applies to high-risk AI systems as classified under Annex III, with the main provisions entering into force in August 2026.

The EU Anti-Corruption Directive adds a further dimension for organisations with EU operations: the liability framework for legal persons extends to failures of supervision, which in practice means that contractual relationships with third parties who engage with public officials require documented due diligence and oversight. Member states have until 2028 to transpose the directive.

Across these instruments, the contract is the primary mechanism through which regulatory obligations are allocated, evidenced, and enforced. That repositions contract management as a compliance-critical function, distinct from the question of where ultimate legal accountability sits, which remains with the entity’s management body.

How Has the Contract Manager’s Role Changed Under New EU Regulations?

Contract management compliance obligations have expanded significantly beyond what most job descriptions still describe, drawing contract managers into work that spans supplier risk screening before the contracting stage, regulatory clause libraries, and active coordination between legal, procurement, and risk teams.

The traditional picture of the role (drafting agreements, maintaining the repository, tracking renewals, supporting legal and procurement requests) is already incomplete. In the organisations ahead of this shift, those who have developed regulatory literacy and GRC fluency are operating as trusted risk stewards rather than purely as contract administrators.

Why Does the Gap Between CLM and GRC Create Compliance Risk?

Most organisations run a CLM platform and a GRC platform that rarely connect. CLM handles drafting, negotiation workflows, approval routing, and renewal tracking. GRC manages risk registers, policy compliance, regulatory change monitoring, third-party screening, and audit management. This separation is where compliance risk accumulates, and it is where regulators will look first.

When a supplier’s risk profile deteriorates, that information sits in the GRC system without being automatically reflected in the CLM platform. An obligation tracker flags a missing CSDDD clause, but no one is checking whether the contracts currently in negotiation meet the requirement. A policy update changes what due diligence demands, and the contracts in flight do not reflect the new standard. The people I spoke with in Antwerp described this as a workflow problem. I think it is more precisely a visibility problem: the information exists, but it never reaches the person making the contracting decision in time to change it.

What looks like a technology problem is, in most organisations, more fundamentally a governance decision. The question organisations need to ask is not which tools are available but what the governance process requires, and whether systems support it.

When contract records carry a live risk profile, with visible third-party screening results, flagged compliance obligations, and audit documentation, the contract manager has the context needed to make defensible decisions at every stage. Obligation monitoring that responds to regulatory change, not only to missed deadlines, moves the function from reactive to continuous. We see this connection being made at the governance level first, in the organisations ahead of this shift, where the decision to connect these systems is treated as a structural one rather than a technology procurement: the process defines the system, not the other way around.

What Does AI Accelerate in Contract Compliance and What Must Stay Human?

The systems gap described above is exactly where AI makes the most immediate difference. AI is useful in contract compliance work: screening suppliers at volume, monitoring risk signals continuously, detecting regulatory changes and mapping their contractual implications, flagging clause-level gaps across large contract populations.

In contract management specifically, AI can surface missing CSDDD clauses, flag ICT agreements that fall short of DORA requirements, and track obligation fulfilment across a supplier portfolio at a scale no team can manage manually, which is genuinely useful. I have also seen it create a false sense of coverage where a gap is flagged, the flag is logged, and no one asks whether the response was adequate. The audit trail is there; the substantive decision behind it often is not.

What AI cannot do is make the risk appetite decision, carry accountability when something goes wrong, or resolve a novel ethical question where there is no prior pattern to draw from. The contract manager’s judgment on what exposure is acceptable and what the organisation should commit to remains a human responsibility.

Building a defensible AI programme means ensuring the reasoning behind a decision is recorded before it is acted on, that every output is logged, and that results are verified against the organisation’s GRC data. That standard applies equally to the tools your organisation deploys and to the contracts you sign with suppliers who use AI in delivering their services.

Has the Regulatory Framework Already Settled Where GRC Belongs in Contract Management?

The question of whether GRC belongs in contract management has effectively been settled by the regulatory framework itself. It is already there, whether or not the organisational structure has caught up to reflect it.

The question is how quickly your organisation recognises it and acts on it. The organisations embedding GRC thinking into the contract lifecycle now will build compliance positions they can demonstrate to regulators.

CSDDD’s revised timeline under Omnibus I simplification package, published February 2026, gives large EU companies until 2029, and that gap between now and enforcement is more usefully understood as a preparation window than as a reason to defer. The organisations that treat 2026 and 2027 as the years to build a defensible programme are the ones that will have it operational and tested when enforcement arrives. Those that do not will be building it under regulatory pressure, and the difference will be apparent to the competent authorities examining them.

If you are working through how CSDDD, DORA, or NIS2 obligations are affecting your contract function, the conversation is worth having.

Frequently Asked Questions

What contractual obligations does CSDDD impose on companies?
Under CSDDD (Directive 2024/1760), in-scope companies must obtain contractual assurances from direct business partners covering human rights and environmental commitments, with those assurances cascading through the supply chain and backed by verification measures. Contracts must include audit rights, grievance mechanisms accessible to affected workers and communities, and the right to suspend or terminate a relationship where adverse impacts cannot be remedied. The transposition deadline is July 2028, with large EU company compliance required by July 2029 under the revised timeline introduced by Omnibus I.

What specific contract provisions does DORA require for ICT third-party agreements?
DORA (Regulation 2022/2554), in force since January 2025, mandates that financial entities include specific provisions in contracts with ICT third-party service providers: full service descriptions, quantitative performance standards, incident notification requirements, audit and access rights, and exit provisions. These are enforceable regulatory requirements under EU law, not recommended clauses, and financial entities are expected to have reviewed existing ICT agreements for compliance. Where NIS2 obligations overlap, DORA prevails for financial entities subject to both.

How has the contract manager’s role changed under the new EU regulatory framework?
The combined effect of CSDDD, DORA, NIS2, and the AI Act is that contract management has become a compliance-critical function. Contract managers are now expected to be involved before negotiation begins, ensuring regulatory clause requirements are incorporated, that supplier risk profiles inform contract terms, and that obligations are tracked beyond signature. In the organisations ahead of this shift, those with regulatory literacy and GRC fluency are operating as risk stewards rather than purely as contract administrators, which is a meaningful change in how the function is positioned relative to legal, procurement, and risk teams.

Why does the gap between CLM and GRC systems create compliance risk under CSDDD and DORA?
Most organisations manage contracts in a CLM platform and risk and compliance in a separate GRC system, with little or no live connection between them. When a supplier’s risk profile changes, or when a regulatory update introduces new contractual requirements, that information rarely reaches the person making contracting decisions in time to change the outcome. Under CSDDD, DORA, and NIS2, regulators will examine the contract record as primary evidence of a substantive compliance programme, which means a gap between what the GRC system knows and what the contract reflects is precisely the kind of failure that creates regulatory exposure.