Vendor tiering for third-party risk

The flat programme fails twice

Every third-party team works with a fixed budget of attention. When the programme is flat, that budget is spent in proportion to the number of vendors, not to the risk they carry.

At the low end, the result is over-assessment. Small suppliers receive long questionnaires that have little to do with what they actually touch, ignore them, get chased, and eventually return a document nobody reads. The process becomes an exchange of PDFs, and response rates sink with every campaign.

At the high end, the result is under-assessment. The provider your operations actually depend on answers the same generic questions as everyone else. Nothing about resilience, nothing about exit, no evidence requested, no monitoring between annual campaigns. The vendor most able to hurt you gets the scrutiny designed for the average.

The regulators already require proportionality

Proportionality is not a shortcut that regulators grudgingly tolerate. It is an obligation to calibrate, written into the regulations themselves:

NIS2 lists supply-chain security among the mandatory risk-management measures (Article 21(2)(d)), and Article 21(3) requires entities to take into account “the vulnerabilities specific to each direct supplier and service provider” and the overall quality of their products and cybersecurity practices. Supplier-specific means risk-based: a single uniform treatment cannot meet that requirement.
DORA makes the principle explicit for financial entities: third-party risk is managed “in light of the principle of proportionality”, taking into account the criticality or importance of the service concerned (Article 28(1)). The regulation then splits its own obligations along that line. Arrangements supporting critical or important functions require the full set of contractual provisions (Article 30(3)) and a documented exit strategy (Article 28(8)); the rest carry a lighter regime, and the register of information must distinguish the two (Article 28(3)). One nuance matters: whether an arrangement supports a critical or important function is a binary, function-level determination that Article 28(4) expects before the contract is signed. A tiering score organises the effort around that assessment; it does not replace it.
GDPR adds a third dimension: whether the vendor processes personal data as a processor (Article 28 GDPR) and where the data is hosted or accessed from (Chapter V and adequacy decisions) change the legal work a vendor requires, independently of its cyber posture.

Read together, the three regimes point to one mechanism, the one the industry calls tiering: assess every vendor, but let the depth of assessment follow the risk.

What a tiering score measures

To calibrate consistently, the tier has to come from a score, computed the same way for every vendor, at onboarding and again whenever the facts change. A workable intake score combines a small set of weighted axes: the business impact of the relationship (the dependency on the service and the access it holds to your systems and data), the compliance context (processor status, hosting and transfers), and what is known of the vendor's security posture at intake.

Two properties keep such a score honest. First, every answer carries a visible weight, so the score is explainable line by line. That matters when procurement, the DPO or an auditor asks why this vendor is treated as critical and that one is not. Second, the intake score is provisional by design: its job is to route the vendor to the right depth of assessment. It is the tier-appropriate assessment that then establishes the vendor's actual risk, not the intake declaration.

The tier is a routing decision, not a label

A tier that only colours a dashboard is decoration. The point of the tier is what it decides. Many programmes number their tiers, with Tier 1 for the most critical vendors down to Tier 3 for the low-stakes ones; others, SynapseRM among them, name the levels by risk instead. The naming matters far less than the consequences attached to each level. In a typical three-level configuration:

Low risk routes to a short questionnaire, a lightweight legal review, and a reassessment every 18 months.
Moderate risk routes to the standard questionnaire, requires the DPO in the loop, and moves the review to an annual cycle.
Critical risk routes to the in-depth questionnaire, enhanced DPO scrutiny, and continuous oversight rather than a periodic campaign.

Four things follow from the tier: how deep the questionnaire goes, who must look at the answers, how often the vendor is reassessed, and how closely it is watched in between. That is how a fixed team covers a growing vendor list: minutes of effort for the plant-watering company, real scrutiny for the core platform.

One refinement matters here: the tier sets the depth, not the content. Within a tier, the questionnaire itself is assembled for each vendor, driven mainly by four variables: how deeply the vendor is embedded in your environment, the criticality of what it supports, the type of data it handles, and the access and dependency it represents. Two critical vendors share the same review cycle and the same level of oversight, but a payment processor and a data centre operator do not answer the same questions.

What the score does not decide

An intake score is a routing instrument, and it is worth being explicit about its limits. It does not see your vendors' own suppliers, the fourth parties and subcontracting chains that DORA's oversight logic increasingly targets. It scores vendors one by one, so it will not by itself surface concentration risk, the moment three critical services quietly depend on the same provider. And like any automated classification, it needs governed exceptions: someone must be able to raise a vendor's tier on judgement, with the decision and its justification recorded. A tiering model that cannot be overridden, or whose overrides leave no trail, fails the same audit question either way.

How SynapseRM does it

Tiering in SynapseRM happens in the vendor intake form, not in a separate spreadsheet. Each question carries its weight on screen, and the score builds live across three axes: cyber security out of 55, business impact out of 25 and compliance out of 20, a split that is configurable to your method, like the tier thresholds themselves. The resulting tier spells out its consequences: which questionnaire, which review, which cycle. The same form, completed honestly, produces three very different follow-ups:

SynapseRM vendor tiering: low risk score of 10 out of 100, short questionnaire and review every 18 months (opens full size in a new tab) — The same intake form, three outcomes: low risk (10/100), moderate risk (40/100) and critical risk (60/100), each with its own questionnaire depth, review cycle and oversight level. Click an image to view it full size.

SynapseRM vendor tiering: moderate risk score of 40 out of 100, standard questionnaire, DPO required, annual review (opens full size in a new tab) — The same intake form, three outcomes: low risk (10/100), moderate risk (40/100) and critical risk (60/100), each with its own questionnaire depth, review cycle and oversight level. Click an image to view it full size.

The tier then drives the workflow. A questionnaire assembled for the vendor's profile goes out through the supplier portal with reminders handled by the platform; the required validators sign off on the record, and the next reassessment is scheduled by the cycle the tier dictates. When a reassessment or a portal update changes what is known about the vendor, the score is recomputed, and the tier and its follow-up move with it.

Proportionality, in the end, is a promise you make to the regulator: the effort follows the risk. Tiering is the mechanism that keeps the promise, and the score is the evidence that it was kept.