Supplier cyber assessments: put the deepest review where failure hurts

A low-value supplier can hold the credentials that stop a high-value business process. A CISO who allocates assessment effort by annual spend can therefore give the lightest review to one of the organisation’s most consequential dependencies.

The alternative is not an exhaustive investigation of every supplier. It is a defensible way to decide which relationships need evidence, which need a practical test, and which can proceed with a modest baseline. That keeps assurance effort focused while giving procurement a predictable route to a decision.

Assess the supplied service, not the logo

Begin with what the supplier does in this relationship. The same company might sell an ordinary subscription to one department and administer production infrastructure for another. A group-wide approval cannot automatically cover both.

Establish the data it receives, the access it holds, the business process that depends on it and the time needed to replace it. Include support activity, temporary connections and subcontractors where they affect the service. Ask the business owner what stops if the supplier becomes unavailable, and the technical owner what an attacker could reach through its access.

The NCSC’s supply-chain guidance supports grouping relationships into risk profiles according to factors including operational disruption, threat, service type and information sensitivity. The practical consequence is to scale the depth of assurance to the relationship’s consequences, rather than sending everyone the longest questionnaire.

In a hypothetical example, a small engineering contractor maintains an integration that releases warehouse orders. It has standing administrative access and the internal team cannot readily operate the integration without it. Its fee may be modest, but privileged access and difficult substitution justify a deeper review. Reducing that access and documenting the integration might lower the risk more effectively than collecting another policy document.

Use tiers to change the work you commission

A tier is useful only if it changes the evidence required and the person who can accept the residual risk. A simple approach can distinguish three levels, with an override for an especially consequential access path or dependency.

• Limited exposure: no meaningful system access, little sensitive information and an easy replacement. Confirm the service boundary, an appropriate security baseline and an incident contact. Avoid requesting extensive evidence that will not change the decision.
• Material exposure: sensitive information, an important integration or a disruption that would require active business management. Review the controls relevant to that exposure, investigate significant exceptions and establish incident cooperation and recovery expectations.
• Critical dependency: privileged access, a business-critical service with a narrow recovery window, or a difficult replacement. Add technical scrutiny of the actual access path, evidence of recovery capability and a joint exercise where the consequences justify it. Require an accountable business decision on unresolved risk.

These are assessment choices, not universal certification categories. Do not average away a critical characteristic with several low-risk answers. A supplier with little personal data can still have destructive production access. Conversely, high spend does not automatically create the same technical exposure.

Ask for evidence of the control that matters

For privileged access, follow an authorised support session from request through approval, authentication, activity logging and revocation. For important data, examine the relevant service’s access controls, retention, export and deletion arrangements. For availability, ask what must be restored, by whom and with which dependencies.

An assurance report can reduce duplicated work, but inspect its service boundary, period, exceptions and customer responsibilities. A statement about the supplier’s corporate environment does not establish the security of every acquired product or subcontracted service. Where software development is the main exposure, use evidence from the product’s development lifecycle to direct the review.

Support deserves explicit attention. In its 3 November 2023 account of the support-system incident, Okta described unauthorised access to files that included HTTP Archive files containing session tokens, followed by customer session hijacking. The procurement lesson is specific: troubleshooting material can create an access path even when it is outside the application’s ordinary production data flow.

Ask how support uploads are screened for secrets, who can retrieve them, what access is logged and how exposed credentials or sessions would be invalidated. The relevant answer may require your own administrators to change their upload procedure as well as a supplier control. Assurance should reveal that shared responsibility.

Finish with a decision someone owns

Separate evidence received from conclusions reached. “Certificate supplied” is an activity; “the assessed service includes the privileged support path we rely on” is a finding. Missing evidence is uncertainty, not proof of failure, but a critical uncertainty can still prevent approval.

Use clear outcomes: accept the relationship within its agreed boundary; accept it subject to a specific remedy and deadline; restrict the proposed access or data until evidence improves; or reject the arrangement. Identify the business owner accepting the remaining exposure and the security owner validating the remedy. An unresolved issue should not vanish when procurement closes the purchase order.

Reassess when the relationship changes: new administrative access, a more sensitive dataset, an acquisition, a significant incident or increased dependence can all invalidate the original tier. Look across suppliers too. Several apparently substitutable services may rely on the same identity, hosting or integration provider.

Start with the supplier whose failure would create the hardest operational recovery. Set its tier from the actual dependency, then test the resilience questions a questionnaire cannot settle. That gives the assessment programme a concrete priority and the business an understandable reason for the extra scrutiny.