An IT supplier contract under NIS2 should go beyond a compliance statement, a generic security clause and a monthly availability target. It must translate service-related risk into clear accountability, measurable service levels, timely incident communication, access to evidence and a workable exit plan. The starting point is the criticality of the service and the actual allocation of control between the parties. Only then can the organisation determine which safeguards, deadlines, assurance rights and reporting obligations belong in the contract.
The contract as a risk control mechanism
A contract review should begin with a map of the organisation’s supplier dependencies, not a standard security clause template. For each supplier, identify the services, processes, systems, data and locations involved, then assess the consequences of unavailability or a security breach. Give priority to dependencies whose disruption could stop operations, prevent the organisation from meeting its commitments or impair incident response. Not every IT service requires the same level of contractual protection.
Supplier criticality should be determined through business impact and risk assessment, not merely by contract value. Particular attention is required where the organisation remains accountable for service continuity and incident handling, while the supplier controls technical information, event logs, backups or the environment needed to restore the service. The organisation should also appoint an owner for supplier-related risk. Without clear ownership, accountability remains fragmented across procurement, IT, security and the relevant process owner.
Contract terms should be designed around disruption scenarios: service failure, cyberattack, loss or corruption of data, supplier staff unavailability, disruption within the subcontractor chain and termination of the relationship. For each scenario, define the actions expected from both parties, their respective responsibilities, information flows and restoration conditions. These decisions determine availability targets, response and recovery times, documentation requirements and assurance rights.
A commitment to provide high availability does not establish how long a production control system may remain unavailable, when downtime measurement begins or who must provide the information required to assess an incident. Nor does it guarantee access to copies of event logs, information about subcontractors or the data needed to transfer the service securely. Such gaps usually become visible during a failure, when responsibilities can no longer remain implicit.
A reference to NIS2 or the applicable KSC requirements should conclude the analysis of risk and accountability, not replace the operational content of the contract. The broader governance context is explained in NIS2 for manufacturing companies: who is in scope, what obligations it introduces and how to prepare the organisation without treating it solely as an IT issue. Contract amendments should always reflect the organisation’s role, the criticality of the service and the actual allocation of control between the parties.
Scope of service and allocation of responsibilities
Responsibilities should be defined in a technical schedule rather than left within a broad description of the contract’s subject matter. The schedule should identify the assets and environments covered, categories of data, processing and service delivery locations, interfaces, support hours and exclusions. Without this information, it is impossible to establish precisely where the supplier’s responsibility ends, which event starts the SLA clock or who secures components at system boundaries.
Security controls should be expressed in terms of the required outcome, the responsible party and the evidence of completion, with technology-specific details maintained in controlled technical documentation. This reduces the risk of the contract becoming obsolete. A supplier’s standard control catalogue should be accepted only after it has been compared with the risks of the specific service and any gaps have been addressed. The responsibility matrix should distinguish between the control owner, the party performing the activity and the authority approving exceptions.
| Area | Customer | Supplier or subcontractor | Required evidence |
|---|---|---|---|
| Access and configuration | Approves roles and requirements | Grants, records and revokes access; maintains configuration | Access register, review records and change history |
| Updates, vulnerabilities and malware protection | Defines permitted maintenance windows and exceptions | Monitors, assesses and implements safeguards | Vulnerability report and register of updates and exceptions |
| Event logging | Defines the required scope and availability of records | Collects, protects and provides records | Sample records and confirmation of retention and access controls |
| Backup and recovery | Defines continuity requirements | Performs backups and recovery tests | Backup and recovery test reports |
| Data deletion | Approves the scope and deadline | Deletes data and copies using the agreed method | Deletion record or confirmation |
Where the supplier administers the environment, the contract should also govern privileged access, including segregation of duties, authentication methods, logging of administrative activity and prompt revocation of privileges following a role change or termination. A statement that backups are performed is insufficient if the customer does not know who encrypts them, where they are stored, who can restore them and which record confirms the result of a recovery test.
The supplier should maintain an up-to-date list of subcontractors that affect the service, including their roles and processing locations, and impose requirements on them that are no less stringent than those agreed with the customer. The contract must distinguish changes requiring prior approval from those requiring notification and reassessment of risk. A management system certificate may support this assessment, but it does not replace service-specific accountability. This relationship is explored further in NIS2 and ISO 27001: what certification provides and what may still be required for KSC compliance.
Security clauses that can be verified
A security clause becomes accountable only when it defines the expected outcome, scope, frequency, method of verification and process for handling exceptions. Expressions such as “in accordance with best practice” or “using due care” may supplement requirements, but they do not provide a sufficient basis for determining whether the supplier has fulfilled its obligation. For every control, identify the requirement owner, the evidence retention period and the party authorised to approve an exception.
Requirements structured in this way should cover, at a minimum, vulnerability and patch management, secure configuration, encryption, protection and retention of event logs, backups, recovery testing, change management and access control. The frequency of access reviews, recovery tests and reporting, as well as vulnerability remediation deadlines, should be derived from the service risk assessment. They should not be identical for every supplier.
Each exception should be recorded with its justification, remediation deadline, risk owner and compensating controls. Approval requires an assessment of whether those controls reduce the risk to a level accepted by the organisation.
A requirement to perform regular backups remains incomplete unless it identifies the data and systems covered, retention periods, protection against alteration or deletion, access rules and the frequency of recovery testing. It should also specify how the supplier reports a failed backup or test, who approves corrective action and which report confirms closure. Similarly, a vulnerability remediation obligation requires an agreed classification method, risk-based response times, rules for deferring updates and documentation of interim safeguards.
Evidence should be divided into information supplied periodically and information made available on request. The first category may include vulnerability summaries, patch reports, recovery test results and confirmation of access reviews. Following an incident, material change or identified exception, the organisation may require detailed test results, event logs, change history, exception registers and a corrective action plan. The scope, ownership and retention of these materials should be aligned with the principles described in NIS2 and KSC documentation before an inspection: which policies, registers and evidence are actually required.
Assurance rights should be proportionate and workable, including for cloud service providers. The first level may consist of document review and a clarification meeting; the next may use independent reports or agreed testing. An on-site audit can be reserved for elevated risk, a material incident or the absence of credible evidence. The contract should define notice periods, confidentiality, technical scope and the remediation of findings, without granting rights that cannot realistically be exercised in a shared environment.
SLAs for resilience, not availability alone
The SLA should derive from a business impact analysis rather than the supplier’s standard service catalogue. The process owner should first define the tolerable duration of disruption, acceptable data loss and the consequences of unavailability for production, customer service, settlements and legal obligations. These decisions then inform recovery time objectives, requirements for alternative services and contingency arrangements, and incident priorities. A monthly availability percentage does not establish whether a single outage at a critical time could interrupt the process for longer than the organisation can tolerate.
In addition to availability, the contract should specify the time allowed to acknowledge a ticket, begin diagnosis, restore functionality and remove the root cause. It should also establish the frequency of status updates, escalation levels and arrangements outside standard service hours. Response time is not recovery time, and activating a workaround does not mean that the underlying problem has been resolved. Separating these measures enables the operational team to understand when work can resume and the service owner to determine when the supplier must complete root-cause analysis and implement a permanent corrective action.
For a production process control system, a critical incident may require immediate escalation and continuous communication until contingency operations have been activated. The same technical fault in a training environment may justify a lower priority. Classification should therefore reflect business impact, not merely the technical description of the fault. Where reliable historical data exist, the organisation should consider actual response and recovery times, achieved availability and the number of recurring failures when setting thresholds.
The measurement mechanism should identify the data source, time zone, events that start and stop the clock, agreed service hours, maintenance windows and rules for changing an incident classification. Exclusions should be set out in a closed, verifiable list. They must not include events falling within the supplier’s responsibility. Alignment between these arrangements and actual operational readiness can be assessed through an NIS2 audit for a manufacturing company: how to assess whether the organisation is ready for the new obligations.
Service credits and nominal compensation do not restore a process or reduce the effects of downtime. More useful mechanisms include a requirement for a remediation plan, management escalation, additional resilience testing and a right to terminate where agreed service levels are persistently or repeatedly missed. Financial remedies may reinforce accountability, but they do not replace service recovery, root-cause removal and prevention of recurrence.
Incidents and reporting obligations
The contract should require the supplier to notify the customer without undue delay of any event that may affect the service, data, operational continuity or the customer’s security. Initial notification should not depend on full confirmation of the cause, extent of damage or legal classification of the event. The contractual deadline should leave the customer enough time to conduct its own assessment and meet any external reporting deadlines. It should reflect service criticality and the availability of a 24/7 point of contact, rather than the administrative convenience of either party.
The information flow should be divided into an initial alert, situation updates, a post-incident report and root-cause analysis. For each stage, specify the required information, approved channel, recipients, update frequency and escalation process if contacts cannot be reached. The initial communication should include, at a minimum, the detection time, affected assets and services, expected impact, actions taken, available technical indicators, an assessment of further propagation risk and the time of the next update. The contact list should include alternates and should be tested periodically, including outside normal working hours.
If the supplier detects unusual traffic in an environment supporting a critical application, it should alert the customer before determining conclusively whether a breach has occurred. The customer activates its own incident management process, appoints a decision owner, engages the response team and, where appropriate, the insurer, and determines who approves external reporting and customer communications. The supplier preserves the agreed logs and technical evidence and supports analysis, containment and scoping, but does not assume the customer’s regulatory accountability.
The clauses should also establish rules for preserving and disclosing evidence, protecting its integrity, documenting decisions and preparing information needed for notifications and subsequent root-cause analysis. External reporting deadlines, recipients and required content must be verified in each case against the current legal framework, the organisation’s status and the type of incident. Notification, decision, escalation and action records should be aligned with the guidance in NIS2 and KSC documentation before an inspection: which policies, registers and evidence are actually required, while the implementation schedule should be considered alongside NIS2 implementation following entry in the KSC register: an action plan to 3 April 2027.
Implementation, oversight and secure exit
Signing an amendment does not complete the supplier management process. The contract owner should periodically review SLA performance, incidents, exceptions, corrective actions, subcontractor changes and the currency of evidence demonstrating that requirements have been met. Oversight should be supported by a contract register containing, at a minimum, the renewal date, owner, service criticality and status of agreed safeguards. A declaration of compliance does not replace reports, test results or records demonstrating performance.
Before renewing a contract or making a material change to the service, reassess its criticality, technical and process dependencies, concentration of services with one supplier, feasibility of controls and the ability to move to an alternative solution. This review determines whether an amendment is sufficient or a new procurement process is required. If a strategic supplier refuses an audit or revised terms, the organisation should document the gap and decide whether to implement a compensating control, formally accept the residual risk or change supplier.
The exit plan must be workable before notice is given. It should cover the return and transfer of data in a usable format, migration support, continuity during the transition, revocation of access, deletion of copies and confirmation that these actions have been completed. Records required for legal, evidential and audit purposes should be retained. A practical test is to restore the data with another supplier and verify completeness, migration time and the ability to disable the former accounts.
The contract portfolio should be updated by starting with services that have the greatest business impact, while gaps should be prioritised according to consequence and urgency. The effectiveness of the agreed mechanisms should be tested through an incident exercise and an audit of a sample of evidence. Reviews of SLA performance, incidents, exceptions, corrective actions and exit tests will show whether the requirements work in practice or exist only as contractual wording.
The assessment scope can be aligned with NIS2 audit for a manufacturing company: how to assess whether the organisation is ready for the new obligations. The organisation’s obligations should also be determined with reference to its status, as discussed in The NIS2 Directive: who is in scope and which companies must meet the new requirements?
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
