Contracting for ICT Services

Contracting for ICT services under DORA is where expectations become rights. Selection and due diligence may reveal what a provider can do, but only the contract determines what the entity can require, inspect, and enforce when circumstances change. The contract therefore needs to cover security obligations, audit and access rights, reporting and cooperation during incidents, control over sub-outsourcing, data location and return, and assistance on exit. A contract that describes a service in commercial terms but stays silent on those points may look complete while leaving the entity without leverage at exactly the moment leverage is needed.

A card processing illustration makes the point concrete. A contract that promises payment processing in general terms leaves room for disagreement about which systems, which data, which service levels and which subcontractors are included. A precise definition names the function, the systems, the data categories in general terms, the locations involved, and the subcontractors that will support the work. Precision here is not legal decoration. It defines the scope of every other right in the contract, from audit to incident notification, and it prevents a dispute about whether a failing component was ever in scope at all.

Audit and access rights protect the entity's ability to verify, rather than merely trust, that controls operate as promised. Those rights may include access to relevant information, the ability to carry out audits directly or through an appointed party, and cooperation with supervisory access where applicable. The value of the right depends on its scope: access to a general assurance report is different from access to evidence about the specific system that supports the service. Negotiating scope before signature matters, because a provider that has already won the work has less reason to concede a broad right afterwards.

Incident provisions in the contract should focus on cooperation, not only on notification. The entity needs timely information about an incident affecting its service, clarity about what the provider is doing, and a route to obtain the detail needed for its own assessment and response. Roles, contact routes and information sharing should be agreed while relations are calm, since an incident is a poor moment to negotiate them. The incident notification guide in this cluster explains the operational side; the contract is what makes that operational cooperation an obligation rather than a courtesy.

Services and providers change during a contract, and the contract should say how change is handled. That includes changes to subcontractors, to system locations, to security arrangements, and to the provider's corporate structure where it affects the service. A common approach is to require notice of planned changes and, for changes that affect the service materially, a right to assess and in appropriate cases object. Without such terms, the entity may learn about a significant change only after it has taken effect, when its options have narrowed to accepting the change or attempting a disruptive exit.

Exit terms negotiated at the start set out what happens to data, what assistance the provider will give during transition, and how long that assistance lasts in general terms. They also address the return or deletion of data in line with applicable requirements and the handover of knowledge needed to run or move the service. Providers may resist detailed exit terms when the relationship is new, yet that is precisely when the entity has the most negotiating strength. A contract without exit terms does not remove the need to exit one day; it merely leaves the terms to be negotiated under pressure, when the provider knows the entity has little alternative. Without such terms, the entity may also face uncertainty about data formats and about whether provider staff will remain available to support handover.