Vendorapp › OpenVMO › Maturity model
The OpenVMO maturity model. Do what your stage needs, and no more.
OpenVMO has five maturity levels, from Level 0 (nothing in place) to Level 4 (a dedicated team with tested exit plans). Each practice has a minimum level, and a level is reached when every practice at or below it is evidenced. This page explains what moves a company up, lists every practice each level adds, and shows how to self-assess.
Open standard, CC BY 4.0 · Free, no sign-up · Works with a spreadsheet · Maps to SOC 2, ISO 27001, NIS2, DORA
How levels work
Events move you up, not just funding rounds.
Each level lists a typical stage, but the stage is a proxy. What really moves a company up is a trigger: the first enterprise security questionnaire, the first audit, the first regulated customer. When a trigger arrives, the practices for that level are what the asker will expect to see.
| Level | Typical stage | Triggers | Effort |
|---|---|---|---|
| Level 0: Unaware | Pre-seed, under 10 people | None yet. | None |
| Level 1: Foundational | Seed, 10 to 30 people, 20 to 60 vendors | Your first enterprise security questionnaire, your first DPA request, or the first person who is not a founder buying software. | About a day to set up, then one or two hours a month |
| Level 2: Managed | Series A, 30 to 150 people, 60 to 200 vendors | A SOC 2 or ISO 27001 audit, enterprise contracts with security schedules, or your first regulated customer. | A part-time lead, roughly a fifth of one person |
| Level 3: Defined | Series B, 150 to 500 people, 200 to 600 vendors | Customers in NIS2 or DORA scope, your own NIS2 scope, ISO surveillance findings, or vendor spend above roughly $5–10M a year. | Half to one person, plus tooling |
| Level 4: Optimised | Series C and beyond, or preparing to list | SOX or internal-controls-over-financial-reporting work, your own DORA or NIS2 obligations, or a dedicated procurement function. | A dedicated team |
Level 1
Level 1: Foundational. 10 practices added.
One register with an owner and a tier for every vendor, contracts and renewal dates on file, a two-page policy signed by a founder, an intake route, and an offboarding checklist that actually gets used.
| Practice | Domain | Outcome |
|---|---|---|
| GOV-1 | Governance | A vendor management policy exists, is approved by a founder or executive, and is reviewed at least once a year. |
| GOV-2 | Governance | Every vendor in the register has a named business owner who answers for the relationship. |
| INV-1 | Inventory | One register holds every vendor that receives money, data or access. |
| INV-2 | Inventory | Every entry records at least the fields in the OpenVMO register schema: name, domain, service, owner, lifecycle state, tier, data, access, contract and renewal date. |
| INT-1 | Intake | There is a known way to request a vendor, and the request records purpose, data, access and the business owner. |
| TIER-1 | Tiering | 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. |
| DD-1 | Due diligence | Every vendor gets baseline checks: legal entity, website domain, and a sanctions or denied-party check where your jurisdiction requires one. |
| CON-1 | Contracts | Contracts and order forms are stored against the vendor in the register. |
| CON-2 | Contracts | Renewal and notice dates are tracked, with an alert at least one notice period before each deadline. |
| EXIT-1 | Offboarding | An offboarding checklist runs whenever a vendor relationship ends: access, single sign-on, API keys and webhooks revoked; data return or deletion requested and confirmed; final invoices settled; assets returned; register updated with the date and reason. |
Level 2
Level 2: Managed. 23 practices added.
Approval gates that scale with tier, proportionate due diligence with the evidence stored, a contract clause set for Tier 1 and 2, assurance expiry tracking, vendors in your incident plan, and an evidence pack you can produce on demand.
| Practice | Domain | Outcome |
|---|---|---|
| GOV-3 | Governance | A vendor management lead is named, part-time is fine, with written responsibilities. |
| GOV-4 | Governance | The company states what vendor risk it will and will not accept, for example "no Tier 1 vendor without SOC 2, ISO 27001 or compensating controls". |
| GOV-6 | Governance | The roles of security, legal, finance and privacy in vendor decisions are written down. |
| INV-3 | Inventory | At least once a year the register is checked against the finance ledger, card spend, single sign-on apps, DNS and email records, and expense tools. |
| INV-4 | Inventory | Each vendor carries a lifecycle state (proposed, active, suspended, offboarding, offboarded), and offboarded vendors are kept, not deleted. |
| INT-2 | Intake | Approvals scale with the vendor’s tier: the owner alone for Tier 3, plus security and privacy for Tier 1 and 2, plus finance above a spend threshold. |
| INT-3 | Intake | No production data or system access is given before the vendor is tiered and its required due diligence is complete. |
| INT-4 | Intake | Vendors found outside the intake route are put through it after the fact. |
| TIER-2 | Tiering | A vendor’s tier is reconsidered when something material changes: new data, a new integration or a change in scope. |
| DD-2 | Due diligence | Tier 1 vendors provide assurance reports (SOC 2 Type II, an ISO 27001 certificate verified with the issuer, or a penetration test summary) or answer a standard questionnaire. Tier 2 vendors get a trust-centre or certificate check. Tier 3 needs nothing beyond baseline. |
| DD-3 | Due diligence | Any vendor processing personal data has a data processing agreement, a lawful transfer mechanism and a subprocessor list on file. |
| DD-4 | Due diligence | Findings and accepted risks are recorded with an owner and an expiry date. |
| CON-3 | Contracts | Tier 1 and 2 contracts include the OpenVMO clause set: data processing agreement, breach notification window, assurance or audit rights, subprocessor change notice, data return and deletion at exit, and termination assistance. |
| CON-4 | Contracts | Where a contract does not meet the clause set, the gap is recorded as an accepted risk. |
| MON-1 | Monitoring | Vendors are re-reviewed on a cadence set by tier. The default is Tier 1 every year and on any event, Tier 2 every two years, and Tier 3 at renewal. |
| MON-2 | Monitoring | Expiry dates of certificates, SOC 2 reports and bridge letters, and DPAs are tracked and chased before they lapse. |
| MON-3 | Monitoring | Breach news, a sanctions listing, an acquisition or a material change in scope triggers a review. |
| FP-1 | Fourth parties | For every Tier 1 vendor, the subprocessor or fourth-party list is obtained and stored, from a public list, the DPA annex or on request. |
| FP-2 | Fourth parties | Subprocessor change notifications are received and reviewed. |
| INC-1 | Incidents | There is a way to log vendor incidents with severity, impact and actions taken. |
| INC-2 | Incidents | Tier 1 vendors are named in your incident response plan with security contacts and notification windows. |
| INC-3 | Incidents | Each vendor incident is assessed for your own notification duties under GDPR, NIS2 and customer contracts. |
| MET-3 | Metrics | An evidence pack (register, policy, tiering, diligence, contracts, reviews, offboarding) can be produced on demand for auditors and customers. |
Level 3
Level 3: Defined. 12 practices added.
Register reconciled to spend and single sign-on, critical functions flagged, fourth parties known for Tier 1, a concentration view, SLA reviews, a vendor scenario in your annual exercise, exit plans for Tier 1, and leadership reporting.
| Practice | Domain | Outcome |
|---|---|---|
| GOV-5 | Governance | Once a year the programme is reviewed and the results are reported to the board or leadership team. |
| INV-5 | Inventory | Every quarter the register is reconciled to spend and to single sign-on, and gaps are fixed. |
| TIER-3 | Tiering | Vendors that support a critical or important function, in the sense used by DORA and the EBA, are flagged. |
| DD-5 | Due diligence | Where relevant, extra checks cover financial viability, ESG, the vendor’s use of AI and model providers, and concentration. AI checks apply from Level 2 when vendors process customer data with AI. |
| CON-5 | Contracts | Where you sell to regulated customers, their required terms (for example DORA Article 30 or NIS2 supplier requirements) flow down to the vendors that support them. |
| MON-4 | Monitoring | Tier 1 commercial relationships have a periodic review of performance against the agreed service levels. |
| MON-5 | Monitoring | You know which vendors, or shared fourth parties, support more than one critical service. |
| FP-3 | Fourth parties | Material shared dependencies, such as a single cloud region or identity provider behind several critical vendors, are identified. |
| INC-4 | Incidents | At least one exercise a year includes a vendor outage or vendor breach scenario. |
| EXIT-2 | Offboarding | Tier 1 and critical vendors have an exit plan: the alternative, how data moves, and how long a switch would take. |
| MET-1 | Metrics | A small set of measures is reported to leadership at least once a year: vendors with an owner and a tier, Tier 1 vendors with current assurance, renewals missed, overdue reviews, offboardings with confirmed deletion, vendor incidents, and time from request to approval. |
| MET-2 | Metrics | The programme is self-assessed against OpenVMO once a year and the result is shared internally. |
Level 4
Level 4: Optimised. 2 practices added.
Spend-to-register reconciliation is automated, monitoring is continuous, exit plans are tested, the register can be exported in regulator formats, and the programme itself gets external assurance.
| Practice | Domain | Outcome |
|---|---|---|
| FP-4 | Fourth parties | Where regulation requires it, the full subcontracting chain is recorded for vendors supporting critical functions. |
| EXIT-3 | Offboarding | Exit plans for critical functions are tested or desk-reviewed. |
Self-assessment
How to assess yourself and claim a level.
- Pick the level you are claimingUsually the one your next trigger demands, for example Level 2 ahead of a SOC 2 audit.
- List every practice at or below itLevel 2 means all Level 1 and Level 2 practices. Use the tables above.
- Find the evidence for each oneA dated record that the practice was performed. A tool that could perform it does not count on its own.
- Fix the gaps, or claim the level belowThe claim is all-or-nothing. One missing practice means the lower level.
- Record and date the claimWrite it as "Self-assessed at OpenVMO v1.0 Level 2 on 30 October 2026", keep the evidence with it, and repeat yearly.
Being honest about a lower level is worth more than claiming a higher one you cannot evidence. Auditors and enterprise customers ask for the evidence, and the metrics and reporting domain is about being able to produce it.
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.