How do I assess my suppliers' cybersecurity?

The underlying problem

A company's cybersecurity does not end at its own systems. We depend more and more on third parties with access to our data, our systems, our applications or our operations.

The pattern repeats itself: an organisation invests in a firewall, MFA, training and backups, and the incident walks in through the VPN of the supplier who maintains the ERP, through software compromised at source, or through the SaaS platform hosting the CRM with every customer record in it. The campaign against Salesforce instances that started with tokens leaked on GitHub is a recent example of the latter.

The named cases confirm it. In Spain, Mango reported in October 2025 that customer contact data had been exposed through an external marketing supplier, and Iberia confirmed in November unauthorised access to a repository managed by a technology provider. Outside Spain, SolarWinds, Kaseya and MOVEit are still the reference cases. None of them needed thousands of intrusions: compromising one supplier was enough, and the trust relationship did the rest.

The practical conclusion is that this affects any organisation with a supplier holding a password to its systems, whatever its size.

First, definitions: TPRM, VRM and SCRM

You will see these three acronyms everywhere, used interchangeably. They do not mean the same thing.

One clarification first: TPRM and VRM are market terms, not standard terms. No ISO standard defines them. The standards talk about supplier relationships and supply chain. Even so, the distinction is useful in practice.

The relationship is one of concentric circles: VRM ⊂ TPRM ⊂ Enterprise Risk Management (ERM), with SCRM cutting across all three.

What the standards say (and what already binds you)

ISO/IEC 27001:2022 — Annex A, the five supplier controls

This is the most recognisable anchor in the Spanish market, and what your customers will ask you for.

There is a nuance about A.5.23 that tends to slip by. In the cloud the contract is not negotiated: you sign it as it is. The only real leverage is choosing well before signing and having the exit sorted out. That is why the procurement and termination processes weigh as much as the questionnaire.

ISO/IEC 27036 — the full development

When A.5.19–A.5.23 fall short, the ISO/IEC 27036 series is the specific development:

• 27036-1:2021 — overview and concepts.
• 27036-2:2022 — requirements. Defines the full lifecycle of the relationship: planning, selection, agreement, operation and termination.
• 27036-3:2023 — hardware, software and services supply chain.
• 27036-4:2016 — cloud services.

The most valuable contribution of part 2 is treating the supplier relationship as a lifecycle rather than an onboarding formality. That idea structures everything that follows.

NIST — useful even if you never certify

CSF 2.0 (2024) introduced the GV.SC — Cybersecurity Supply Chain Risk Management category inside the Govern function. With ten subcategories, it is the largest in the whole framework. Placing it under governance, rather than identify or protect, tells you the level at which NIST expects these decisions to be taken: the board, not the technical team.

SP 800-161r1 (2022, with a November 2024 erratum) is the reference guide for C-SCRM. Exhaustive and dense, written for organisations with a formal programme.

SP 1326 (July 2026) is the most practical addition: a quick-start due diligence guide for ICT suppliers that brings SP 800-161r1 down to something executable, structured around five components: foreign ownership and control (FOCI), provenance, resilience, foundational cyber-secure practices and supply chain tiers.

The regulatory part

NIS2 (Directive EU 2022/2555), article 21.2.d. Supply chain security is one of the ten mandatory minimum measures. Article 21.3 spells out that you have to take into account the specific vulnerabilities of each direct supplier and the quality of their security practices, all of it under a proportionality principle tied to size and risk.

The cascade effect. This is what actually reaches the SME. If you are not an essential or important entity but you sell to one that is, the questionnaire is coming, and with a deadline.

In Spain the transposition is still pending. The draft Cybersecurity Coordination and Governance Act was approved by the Council of Ministers in January 2025 and has still not been published in the official gazette. The European Commission has already issued a reasoned opinion over the delay. Waiting for the law before starting makes little sense, because customers are not waiting. There is more on this in NIS2 in Spain 2026: what already binds you.

DORA (Regulation EU 2022/2554), applicable to financial entities since January 2025, is today the most demanding framework: mandatory prior due diligence (art. 28), a register of information covering every ICT arrangement, concentration risk assessment (art. 29) and a fixed set of minimum contractual clauses (art. 30). Its article 28.1.a sums up the whole point: the entity remains fully responsible for compliance at all times, even when the service is outsourced.

The method: seven phases

Here is everything above translated into a process that fits an SME with no dedicated security team. Click any of them to jump to the detail:

Phase 1 — Third-party inventory

No inventory, no programme. It is the most tedious phase and also the one that conditions the rest.

It is worth cross-checking at least three sources, because none of them is complete on its own:

1. Accounting. Suppliers with recurring invoices.
2. Systems. Who has an account, a VPN, remote access, an API integration or an app connected to your Microsoft 365 or Google Workspace tenant. This is where shadow IT shows up.
3. The teams. Ask every area lead who they work with externally. Third parties usually surface that appear on neither of the two lists above.

For each third party you need four minimum data points: what service they provide, what they access, what data they handle and who owns the relationship internally. That last field decides whether the programme survives: a supplier with no internal owner is a questionnaire nobody will chase.

Phase 2 — Tiering by criticality

Assessing everyone the same way is unworkable and counterproductive: it eats time, wears down the supplier relationship and dilutes attention away from the ones that really matter.

Five tiering criteria:

• Access. Do they have access to internal systems? Is it privileged? Permanent or occasional?
• Data. Do they handle personal data, special categories, confidential information or intellectual property? Do they store it or only view it?
• Operational criticality. If they disappear tomorrow, how long can operations hold? Is there an alternative?
• Interconnection. Is there a permanent technical integration (API, VPN, SSO, identity federation)?
• Concentration and substitutability. How many critical processes depend on the same supplier? How much would migrating cost?

With that, three tiers:

Document the tiering criteria, not just the outcome. The day a customer, an auditor or a regulator asks why a supplier is classified as low, the answer has to be a written criterion.

Phase 3 — Due diligence

The minimum domains of the questionnaire, with their anchor in the standards:

Two criteria separate a real assessment from a formality.

The first is asking for commitments rather than intentions. «Do you manage vulnerabilities?» is always answered yes and tells you nothing. «Within what timeframe do you fix a critical vulnerability, and how do you measure it?» produces an answer you can use, compare and put in a contract.

The second is asking for evidence only from critical suppliers, and only the evidence you will actually review: a certificate, a policy, a pentest report with the sensitive detail stripped out, the result of a restore test. Requesting thirty documents nobody will open hollows out the process and burns your credibility with the supplier.

There are also standard questionnaires that save you from starting from scratch: the SIG from Shared Assessments and the CAIQ from the Cloud Security Alliance for cloud services. Adapting one of those to your context is usually more efficient than writing your own from zero.

Phase 4 — Contract (A.5.20)

What is not in the contract is not enforceable. Minimum clauses for a critical supplier:

• Specific, measurable security requirements, avoiding formulas along the lines of «shall apply appropriate measures».
• Incident notification with an explicit deadline (24, 48 or 72 hours) and a defined channel.
• Prior authorisation or notification of subcontracting.
• Right to audit or, failing that, periodic delivery of evidence.
• Data location and international transfer conditions.
• Processor agreement (art. 28 GDPR) where personal data is involved.
• Return and certified destruction of data on termination, with format and deadline.

The last one is the least frequently signed and the one that prevents the most trouble.

Phase 5 — Handling the results

The returned questionnaire is the starting point of the analysis, not the end of it. With the answers in hand, four outputs should follow:

1. Identified risks, assessed by likelihood and impact on your business, not on the supplier's.
2. Control gaps: what should exist given their tier and does not.
3. An action plan with an owner and a date, agreed with the supplier.
4. A formal, traceable decision: accept, accept with conditions, require mitigation before contracting, or reject.

Phase 6 — Monitoring and reassessment

A supplier's risk changes without notice: corporate transactions, a change of cloud provider, a breach, an expanded service, support moved to another country.

The sustainable minimum includes three elements:

• Periodic reassessment according to the tier (table in phase 2).
• Off-calendar reassessment triggers: a public security incident, a change of ownership, an expansion of the service scope, a change of subcontractors.
• Light monitoring through news alerts on critical suppliers. Zero cost and, sometimes, information before it reaches you through the official channel.

Phase 7 — Exit

GV.SC-10 exists for a reason. When the relationship ends:

• Revoke every access, technical ones included: API keys, certificates, service accounts.
• Recover the data in a usable format and demand a destruction certificate.
• Dismantle integrations and remove firewall and VPN rules.
• Document the closure.

Old supplier accounts still active are, in my experience, among the most frequent findings of any access review, and among the easiest for an attacker to use.

The most common mistakes

How to start at zero cost

If you are starting from scratch, do not try to build the whole programme:

1. List your third parties in a spreadsheet, cross-checking the three sources from phase 1. There is an Excel template ready for exactly that.
2. Mark the ones with access to systems or data. There are usually far fewer than expected.
3. Of those, pick the five most critical and start with them only.
4. Review who holds active access and should not. It is free, it takes an afternoon and it is the best return on the list.
5. Send a short questionnaire to those five. Ten or fifteen well-chosen questions beat a hundred badly sent ones.

Once that loop works, widen it. A twenty-supplier programme that survives is worth far more than a two-hundred-supplier one abandoned in month two.

Assessing suppliers does not have to be complicated

The difficulty is rarely in knowing what to ask, but in running the process: preparing the questionnaire, sending it, chasing answers, reviewing evidence, analysing results and keeping a record that holds up when someone asks.

That administrative load is what makes most supplier assessment programmes fold by the third round.

So I built ACBSEC · Basic VRM Form, a basic VRM questionnaire tool you can send to your suppliers.

Has a customer sent you a security questionnaire and you do not know where to start? Write to me and we can go through it together, no strings attached.