CyberSec Update #37 – Supplier Risk Assessment | KWKR

CyberSec Update: Counterparty Risk Categories – Why Themis Needs Scales, Not Just a Sword

Themis carries two symbols. The sword, because the law must be capable of enforcement. But in the other hand, she holds scales, because before imposing a sanction, one must first weigh what is at stake. Justice without scales would be mere force; with scales, it becomes a measure.

In the previous edition of our series, we discussed the cybersecurity clause as a contractual “border wall” between an organisation and its counterparty. This time, we continue the discussion by looking at how to build counterparty risk categories in practice, so that cybersecurity requirements are strict where necessary and proportionate where possible. In other words, how to assess risk before reaching for the sword.

Why a Single Cybersecurity Clause Does Not Work for Everyone

A supplier providing a one-time software licence and an industrial control systems integrator do not create the same level of risk. Applying identical obligations to both can lead to two undesirable outcomes:

• smaller businesses may be unable to meet requirements designed for critical infrastructure, resulting in higher costs or exclusion from procurement procedures;
• for high-risk suppliers, cybersecurity requirements may be diluted to a common denominator that provides insufficient protection.

The solution is risk categorisation, where requirements are determined by the level of risk rather than imposed uniformly on all suppliers.

A Four-Tier A–D Risk Model in Practice

A simple, modular framework based on four risk categories often proves effective. Categories are assigned proportionately to the supplier’s level of access to systems, data and infrastructure.

• Category A – Basic: counterparties with no significant access to systems or data.
• Category B – Extended: entities such as construction contractors with access to premises and construction supervisors.
• Category C – Technical Extended (ICT/OT): suppliers delivering ICT services, processes or industrial automation solutions.
• Category D – Critical: high-risk suppliers, including smaller organisations providing cybersecurity services.

Categories B and C together represent an “extended” level of risk, with Category B focused on physical access and Category C on technical access.

How Requirements Should Differ Between Categories

Risk categories should directly influence the scope and intensity of obligations. Examples include:

• certification, such as ISO/IEC 27001, for Categories B, C and D, supported by transition mechanisms and compliance reporting options;
• minimum technical safeguards, including MFA, least-privilege access, account reviews, account deactivation and encryption, for Categories C and D;
• 24/7/365 monitoring for Categories C and D, while Categories A and B apply monitoring proportionate to the level of access;
• ICT asset inventories and Software Bill of Materials (SBOM) requirements for Categories C and D where necessary for supply chain risk management;
• social engineering, phishing or red team testing for Categories C and D, excluding suppliers providing only one-off licences, hardware or services without ongoing access;
• cyber liability insurance with minimum coverage levels adjusted according to risk category;
• supplier obligations flowing down the supply chain, particularly for ICT and OT providers.

Proportionality: Adjusting the Method, Not the Standard

This is one of the most frequently misunderstood aspects of supplier risk management.

The size of an organisation should not reduce the required level of cybersecurity. Instead, it may affect how compliance is demonstrated.

• SMEs may rely on simplified documentation instead of extensive governance frameworks.
• However, the level of cybersecurity required should always be determined by the assigned risk category, not by the size of the supplier.

This approach aligns with the principles of the NIS2 Directive, which takes into account the criticality of the entity, its size, and the likelihood and impact of incidents, as well as the proportionality requirements reflected in national cybersecurity regulations.

Who Assigns the Risk Category and When?

Several practical rules help avoid future disputes.

• The contracting authority or customer should assign the risk category based on the scope of access and the nature of the services.
• The category should ideally be determined before the contract is signed so that the supplier understands its obligations in advance.
• Variable elements such as reporting channels, RTO, RPO and escalation thresholds should be captured in project-specific parameters while leaving the main clause unchanged.

Where “Strictness” Begins: Technical Requirements and Sanctions

For suppliers assigned to the highest risk categories, contractual obligations should become progressively stricter in a predictable manner.

• ICT/OT requirements may be interpreted with reference to the ISA/IEC 62443 series of standards for industrial automation and control systems.
• Sanctions should be graduated, distinguishing between formal breaches, security breaches and critical breaches, with termination rights reserved for the most serious cases.

GDPR and Counterparty Risk Categorisation

Counterparty risk and personal data processing risk are separate, although closely related, considerations.

Article 32 of the GDPR also requires security measures to be proportionate to the level of risk. The higher the risk, the stronger the required safeguards. For this reason, minimum cybersecurity requirements set out in a cybersecurity clause should also serve as a baseline for personal data protection, alongside a separate Data Processing Agreement (DPA).

What Comes Next?

Themis carries scales for a reason. Fair judgement starts with assessment, not punishment.

A well-designed cybersecurity clause follows the same principle. Risk should be assessed first, and requirements should follow.

Categories A–D are not an exercise in bureaucracy. They are a practical mechanism for ensuring that cybersecurity measures remain proportionate while allowing valuable suppliers of all sizes to participate in projects.

In the next edition, we will go one step further and explore how to design project parameters and event mapping matrices so that incident classification and reporting timelines operate consistently across all counterparties.