Vendorapp › OpenVMO › Risk tiering
Risk tiering in OpenVMO.
Tiering is what makes the programme proportionate. Five questions about data, access, impact, customer exposure and regulatory role place each vendor in Tier 1, 2 or 3, and the tier decides how much diligence, contract protection and monitoring it gets.
Open standard, CC BY 4.0 · Free, no sign-up · Works with a spreadsheet · Maps to SOC 2, ISO 27001, NIS2, DORA
Why it matters
What this domain is for.
Without tiers, you either check every vendor in depth and never finish, or check none properly. Auditors look for a documented, consistent method. "We assess based on risk" is not one.
Risk tiering is one of the 11 domains of the OpenVMO framework, an open standard for running vendor management at a startup. Each practice below has a minimum maturity level: you only need the practices at or below the level you are aiming for.
Practices
The 3 TIER practices.
Every vendor tiered
Every vendor is tiered with the published rubric, using two lenses: the data and access it has, and how critical it is to the business. Evidence: A tier and the rubric answers for every register entry.
Re-tier on change
A vendor’s tier is reconsidered when something material changes: new data, a new integration or a change in scope. Evidence: Dated tier changes in the register, with the reason.
Critical functions flagged
Vendors that support a critical or important function, in the sense used by DORA and the EBA, are flagged. Evidence: The flag in the register, and the list of functions it relates to.
A practice counts as in place only when a dated record shows it was performed. A tool that could perform it does not count on its own.
By stage
What good looks like at each level.
| Level | What good looks like |
|---|---|
| Level 1: Foundational | Every vendor tiered once with the five-question rubric, answers recorded. |
| Level 2: Managed | Tiers revisited whenever data, access or scope changes. |
| Level 3: Defined | Critical and important functions identified and the vendors behind them flagged. |
| Level 4: Optimised | Tiering is checked against spend, access logs and incidents, and the rubric is tuned from the results. |
With a spreadsheet
Doing it without any special tool.
- Add five rubric columns (Q1 to Q5) and a formula that takes the highest tier.
- Expect roughly 10% Tier 1, 30% Tier 2 and 60% Tier 3 at Series A.
- If more than a quarter of your vendors are Tier 1, the rubric is being applied too cautiously.
Common mistakes
Where teams usually go wrong.
- Tiering by spend. A free analytics script on your login page can matter more than a large consultancy.
- Tiering once and never revisiting when a vendor gets a new integration.
- Calling everything high risk to be safe, which makes the tiers meaningless.
Crosswalk
How this maps to the frameworks you are audited against.
| Framework | Related requirements |
|---|---|
| SOC 2 (Trust Services Criteria) | CC9.2, CC3.2 |
| ISO/IEC 27001:2022 | A.5.19, A.5.21 |
| NIS2 and Implementing Regulation 2024/2690 | Art. 21(3) |
| DORA | Art. 28(4); Art. 3(22) (critical or important function) |
| NIST CSF 2.0 | GV.SC-04 |
The mapping is informative, not legal advice: it points to where each framework deals with the same topic. The full mapping for every practice is on the crosswalk page.
Templates
Templates for this domain.
- Risk-tiering rubric (Markdown): Five questions, one page. Take the highest answer and that is the vendor’s tier.
- Vendor register (CSV): The register with every OpenVMO minimum field as a column, plus two example rows. Open it in any spreadsheet.
All OpenVMO templates are on the templates page.
Previous domain: Intake and onboarding. Next domain: Due diligence.
Run OpenVMO with a spreadsheet, or with a tool.
Every practice can be met with the free templates. If you would rather not maintain the register by hand, Vendorapp implements most of OpenVMO and has a free plan.