Przejdź do treści

NIS2 and Supply Chain Security: How to Assess IT Providers, Integrators and Subcontractors

13 min czytania Systemy zarządzania

Supply chain security does not begin with sending the same questionnaire to every supplier. First, the organisation must identify which providers its processes depend on, what access they receive and what impact could result from an outage, incident or delayed response. Only then can it define a proportionate assessment scope, evidence requirements, contractual controls and ongoing monitoring. Otherwise, the organisation is checking whether documentation is complete rather than managing the actual risks associated with IT services, integrators and subcontractors.

Suppliers as part of organisational resilience

Supplier risk is not determined solely by vulnerabilities in the supplier’s systems or the maturity of its technical safeguards. It arises primarily where an external service, workforce, software product or infrastructure component is essential to the continuity of an organisational process. The level of oversight should therefore be driven not by contract value, supplier size or the category of service purchased, but by the consequences of service unavailability, loss of confidentiality, compromised data integrity or a delayed incident response.

The process should begin with clear ownership. The business process owner identifies the dependency and determines its operational significance. The information security function assesses exposure, procurement incorporates requirements into selection criteria and contracts, and IT verifies access scope and technical arrangements. The organisation must also specify who rates the risk, approves exceptions to requirements, oversees contractual performance and coordinates cooperation during an incident. Without this allocation of responsibility, the supplier questionnaire becomes an ownerless document and risk is dispersed across organisational functions.

A small integrator retaining remote privileged access to a production environment may create greater exposure than a large office services provider, despite having a much lower contract value. An outage, compromise of a technical account or unavailability of the integrator’s personnel could stop production directly or obstruct recovery. Enhanced due diligence should therefore focus on suppliers linked to critical processes, those with remote or privileged access, organisations processing important information, and parties involved in incident response or operational recovery.

Only after these dependencies have been identified can the process be aligned appropriately with NIS2 requirements concerning risk management, supply chain security and management accountability, taking account of the scope established by the applicable national legislation. Senior management should not replace technical assessment. It should, however, approve supplier classification principles, risk ownership arrangements and the process for accepting exceptions. Useful measures include the number of critical processes dependent on external services and the number of suppliers with privileged or remote access. The broader management context for these decisions is discussed in NIS2 in management practice: translating requirements into decisions, accountability and genuine organisational resilience.

Segmentation by impact and access

A standard questionnaire issued to every supplier does not produce a risk-proportionate assessment. Segmentation should combine the impact of service unavailability, the type of information processed, the level of access granted, the potential for an incident to propagate into the organisation’s environment, and the ease with which the supplier can be replaced. Classification should be based on the period for which the process can operate without the service, as established through business impact analysis, together with the number of dependent processes and locations. Contract value and supplier size may provide supporting context, but they do not describe technical dependencies, maximum tolerable downtime or the cost of replacing the service securely.

Thresholds for basic assessment, enhanced assessment and audit should be tied to measurable criteria. An audit may be warranted where a supplier failure would exceed the tolerable interruption period, where the supplier has privileged access, or where replacement would require significant technical change. Enhanced assessment is appropriate where access is restricted but still material, where protected information is processed, or where there are downstream dependencies. Other suppliers may be subject to a basic assessment, provided they do not create an accumulation of risk.

Supplier profile Key criterion Assessment level Minimum evidence
Critical service Impact of disruption and tolerable downtime Enhanced assessment or audit Business continuity plan, recovery parameters, recovery test results and incident notification arrangements
Access to the environment Extent of privileges and potential for incident propagation Enhanced assessment or audit Access register, authentication method, activity logs and access revocation procedure
Software or component Impact of vulnerabilities and updates on the process Basic or enhanced assessment Update, vulnerability management, support and incident notification arrangements
Subcontractor without system access Impact on process delivery and downstream dependencies Basic or enhanced assessment Scope of responsibility, replaceability, resource continuity and oversight of further subcontractors

Assessment of an HR system provider should emphasise information classification, permissions and data recovery. An industrial automation integrator should be assessed primarily in relation to remote access, configuration changes and its ability to provide support after an incident. A maintenance subcontractor may have no access to systems, yet its unavailability could stop a process because essential parts, expertise or documentation are unavailable. Dependencies between IT systems, operational technology and production continuity are discussed in more detail in NIS2 for manufacturing companies: who is in scope, what obligations apply and how to prepare without treating the subject as an IT-only issue.

Classification cannot remain unchanged throughout the relationship. It should be repeated after changes to service scope, access, architecture, subcontractors, processed information or process criticality, and should also be reconfirmed periodically even when contractual terms have not changed. This enables the level of due diligence to reflect actual exposure and demonstrates that supply chain oversight is based on impact assessment rather than an administrative division of suppliers.

Evidence, not declarations

A supplier assessment should examine how controls operate, not merely whether policies and procedures exist. Questions should address access, vulnerability and change management, backups, event monitoring, incident response, business continuity, personnel security and oversight of subcontractors. A response such as “we have implemented a procedure” is insufficient if it does not identify the control owner, operating frequency, method of recording results and treatment of exceptions. Generic materials that do not relate to the contracted service, its location or delivery environment are another warning sign.

The minimum evidence set should be defined for each supplier class before the assessment begins. For lower-risk suppliers, responses from the responsible process owner supported by current documents and sample records may be sufficient. As criticality increases, the organisation should expect test results, operational records, control performance measures and independent assessments. For critical services, a technical interview, remote assessment or on-site audit may be appropriate. The selected method should depend, among other factors, on whether controls can be verified without access to infrastructure and on the consequences of relying on an inaccurate declaration. Relevant records may include the date and outcome of the most recent recovery test for a material service and vulnerability remediation times against the supplier’s defined severity levels.

A statement that backups are performed clearly illustrates the difference between assurance and evidence. It does not explain whether backups are segregated from the production environment, who can delete them, how often restoration tests are carried out or what happened during the latest test. Nor does it establish who is responsible for restoring the complete service: the infrastructure provider, application vendor, integrator or customer. Adequate evidence should therefore include not only a description of the arrangements, but also a record of the most recent test, the data and functions restored, identified nonconformities and confirmation that the causes of any failures were addressed. An evasive response can often be recognised by the absence of dates, scope, accountability or a clear link between the evidence and the specific service.

A management system certificate is valuable supporting evidence, but it does not remove the need for due diligence. Its scope, validity period, covered locations and services should be verified against the subject of the procurement. Certification of a corporate headquarters may not include the data centre, support team or subcontractor responsible for a critical part of the service. A certificate may form part of a basic assessment. Where the dependency is critical, however, it should be supplemented with operational evidence and, where significant gaps remain, an audit. This connection between safeguards and process accountability is also presented in TISAX for management system representatives and quality engineers: integrating information security with business processes; security should not remain confined to IT documentation.

The contract as a control mechanism

A contract with a critical supplier should translate the risk assessment into obligations that can be performed and verified. A confidentiality clause alone is not sufficient. Provisions should cover event notification, access to information required to assess impact, supplier participation in analysis and operational recovery, maintenance of agreed safeguards, change management and the use of further subcontractors. Availability, recovery and retention parameters should also be agreed for the specific service and aligned with business process requirements rather than relying solely on the supplier’s standard service description.

It is essential to appoint an owner for negotiating security requirements and to define approval thresholds for contractual exceptions. Procurement may manage the contracting process, but it should not decide independently whether limitations of liability, refusal of audit rights or unrestricted subcontracting are acceptable. Depending on the risk, such exceptions require assessment by the process owner, information security, business continuity and legal functions. Where a dominant supplier will not accept customer-drafted terms, the decision should not be reduced to unconditional acceptance of the supplier’s template. The organisation may assess compensating controls, reduce the service scope, strengthen monitoring or formally accept the risk with a documented rationale and named owner.

A requirement to notify the organisation “without undue delay” has limited operational value unless it specifies the notification channel, minimum information requirements, contact points and authorised decision-makers. The agreed notification period must leave the organisation sufficient time to assess the event and meet its own obligations. As a minimum, the supplier should provide a description of the event, identify affected services and data, explain the known or anticipated impact, describe containment measures and specify when the next update will be issued. The contract should also govern access to technical records and the participation of relevant specialists in root cause analysis and service recovery.

Similarly, an audit right does not in itself provide effective control. If the agreement does not define audit triggers, access to evidence, protection of confidential information, costs and timeframes for agreeing and completing corrective actions, the clause may prove unenforceable precisely when an incident occurs. The scope of the clauses should reflect supplier criticality and service replaceability. An excessive catalogue of requirements that nobody subsequently monitors creates the appearance of control while increasing contract administration costs. Useful measures include the number of exceptions requiring formal risk acceptance and the on-time completion rate for contractual commitments.

The cost of amending contracts is not limited to legal work. It also includes supplier reassessment, negotiations, audits, monitoring of agreed parameters and implementation of additional safeguards. These dependencies should be included in the budget discussed in How much does NIS2 and uKSC implementation cost? Building a budget for audits, documentation, training and safeguards without costly mistakes. A contract serves its purpose only when the organisation has appointed an owner for oversight, retains evidence that obligations are being met and has defined how to respond when a service changes or ends.

Oversight after contract signature

An initial assessment quickly becomes outdated when the service scope, solution architecture, supplier ownership, processing location, subcontractors or level of access to systems and information changes. Oversight should therefore include periodic reviews at a frequency determined by service criticality, together with event-driven reassessments. Suppliers with a high impact on operational continuity require more frequent review than easily replaceable providers without privileged access.

The monitoring cycle should have an owner, escalation thresholds and defined records. Reviewing service delivery metrics alone is not enough. These metrics should be considered alongside incident information, continuity and recovery test results, corrective action status, subcontractor changes and signs of deterioration in the supplier’s operational capability. Out-of-cycle reassessment should be triggered by events including:

  • a material change in service scope or access;
  • relocation of processing activities;
  • a change of subcontractor affecting service delivery;
  • repeated breaches of service parameters;
  • failure to close a nonconformity by the agreed deadline;
  • an event indicating inadequate response capability.

A supplier assessed positively when the contract was signed may move to a new data centre or outsource part of the service one year later. The supplier name and stated service scope may remain unchanged, while technical dependencies, processing location, recovery arrangements and access to evidence have changed. Without a mechanism for reporting such changes, the organisation is monitoring a historical risk profile rather than the current one. Useful measures include the number of changes in scope, access or subcontractors requiring reassessment, the number of incidents and service parameter breaches, and the percentage of corrective actions closed within the agreed timeframe.

An identified nonconformity does not necessarily require immediate termination of the relationship. The decision should consider the impact of the nonconformity, the time needed to address it, the ability to replace the service and the risks associated with transition. The organisation may require corrective action, implement compensating controls, accept the risk temporarily with a defined review date, restrict access or activate a supplier replacement plan. Each route requires a decision owner, deadline, closure criterion and evidence confirming effectiveness rather than merely task completion.

The effectiveness of the overall mechanism should be reviewed periodically using records, response exercises and evidence that the organisation can make decisions when risk changes. A useful reference for planning this review is NIS2 audit in a manufacturing company: how to assess whether the organisation is ready for the new obligations. The audit should confirm not only that a review schedule exists, but also that warning signs lead to escalation, nonconformities are closed against defined criteria and supplier risk remains linked to the continuity of organisational processes.

An audit-ready supplier assessment programme

A supplier oversight programme is audit-ready when it operates as a single decision-making mechanism rather than as a collection of questionnaires, clauses and fragmented registers. At a minimum, it should include a supplier register showing process and technical dependencies, segmentation criteria, decision-making roles, requirements for each class, evidence assessment, contractual controls, monitoring, escalation and exit arrangements. The audit programme and risk register should use the same classifications, ownership roles and acceptance criteria.

Where resources are limited, the pilot group should be selected from suppliers supporting critical processes, holding privileged access or proving difficult to replace. The scope can then be extended according to risk level and the results of the initial assessments. Attempting to cover the entire supplier base at once usually increases administrative cost without delivering proportionate value. Senior management should approve the assessment sequence, remediation plan and budget, and decide on risks that exceed delegated operational authority.

During an audit, a coherent decision trail is more persuasive than an extensive procedure: the supplier classification, rationale for requirements, evaluated evidence, appropriate contract terms, monitoring and nonconformity records, and formal risk acceptance or corrective action decision. Readiness can be measured through the proportion of suppliers classified and assessed under the programme, completion of the critical supplier assessment schedule, and the number of risks without an owner, response deadline or approved decision.

Normative and legal references should complete the process design rather than replace its logic. NIS2 requirements should be translated into responsibilities, criteria, records and verifiable evidence, taking account of the applicable national implementing legislation and the extent to which it covers the organisation. A sector-specific example of this approach is ISO 19443 — a route into the Polish nuclear supply chain, where supplier qualification and oversight contribute directly to the organisation’s ability to meet requirements safely.

Rate this post
Udostępnij:
Ekspert BBQuality

Masz pytania? Porozmawiajmy.

Bezpłatna konsultacja – bez zobowiązań.

Umów konsultację