Vendorapp › OpenVMO
OpenVMO. The vendor management office for companies that don’t have one.
OpenVMO is an open standard for setting up and running vendor management at a startup. It sets out 11 domains and 47 practices, scaled by five maturity levels that follow company stage, from a seed company’s first vendor register to a scale-up’s tested exit plans. It is free to use under CC BY 4.0, every practice can be met with a spreadsheet, and it maps to SOC 2, ISO 27001, NIS2 and DORA.
Open standard, CC BY 4.0 · Free, no sign-up · Works with a spreadsheet · Maps to SOC 2, ISO 27001, NIS2, DORA
The short answer
What OpenVMO is.
A vendor management office (VMO) is whoever in a company makes sure its vendors are known, checked, contracted, watched and cleanly exited. Large companies have a team for it. Startups have a founder, an operations lead or a security engineer doing it alongside everything else, usually for the first time, usually because an auditor or an enterprise customer asked.
OpenVMO tells that person what to do, in what order, and how much is enough for the stage the company is at. It is a standard rather than a guide: each practice has an ID, an outcome, the evidence that shows it is done, and the level at which it becomes expected. That makes a programme something you can assess, and a level something you can claim honestly.
If you remember one thing: start with one register, an owner and a tier for every vendor. Every other practice hangs off that, and you can do it this afternoon.
Why it exists
Nothing open was built for startups.
The existing material falls into four groups, and each misses the startup in a different way. Industry frameworks and questionnaires for third-party risk are mostly paid or membership-only, and written for enterprises with dedicated teams. The free government frameworks, such as NIST’s supply-chain guidance and the US interagency guidance for banks, are written for federal agencies and financial institutions. Regulations such as NIS2 and DORA say what must be evidenced, not how a 20-person company should run it. And the open baselines that do exist set requirements for suppliers, not for how a buyer runs its own programme.
OpenVMO fills that gap: an open, stage-scaled operating model for the buyer side, small enough to fit on one page, with a crosswalk to the frameworks startups are actually audited against.
The framework
11 domains, 47 practices.
| Domain | What it covers | Practices |
|---|---|---|
| GOV: Governance and ownership | A policy, a named owner for every vendor, and someone accountable for the programme. | 6 |
| INV: Vendor inventory | One register of every vendor that receives money, data or access. | 5 |
| INT: Intake and onboarding | A route for anyone to request a vendor, with checks before data or access is granted. | 4 |
| TIER: Risk tiering | Every vendor gets a tier from a five-question rubric, so effort goes where risk is. | 3 |
| DD: Due diligence | Baseline checks for everyone, and security and privacy checks in proportion to tier. | 5 |
| CON: Contracts | Contracts on file, renewals tracked, and a security clause set for Tier 1 and 2. | 5 |
| MON: Ongoing monitoring | Reviews on a cadence set by tier, expiring assurance tracked, and events acted on. | 5 |
| FP: Fourth parties and supply chain | Know the vendors behind your Tier 1 vendors, and where they overlap. | 4 |
| INC: Third-party incidents | Log vendor incidents, plan for them, and know your own notification deadlines. | 4 |
| EXIT: Offboarding and exit | Close relationships cleanly, and plan the exit from critical vendors before you need it. | 3 |
| MET: Metrics and reporting | A handful of measures, a yearly self-assessment, and evidence on demand. | 3 |
Ten domains follow the vendor lifecycle from policy to exit; the eleventh, metrics and reporting, cuts across all of them. Each domain page lists its practices, what good looks like at each level, how to do it with a spreadsheet, common mistakes and the crosswalk.
Principles
Ten principles behind every practice.
Proportionate by default
Effort scales with risk tier and company stage. Treating every vendor the same is a failure, not a strength.
Register first
You cannot manage what is not listed. Every other practice hangs off one register.
One owner per vendor
Every relationship has a named business owner. The vendor management office coordinates; it does not own every vendor.
Evidence over assertion
A practice is in place only when a dated record shows it was performed, not when a tool is capable of performing it.
Lifecycle, not snapshot
Intake, due diligence, contract, monitoring and exit are one loop, and the exit is designed at the start.
Reuse before you ask
Prefer existing assurance (SOC 2 reports, ISO certificates, trust centres, published subprocessor lists) over bespoke questionnaires.
Tool-neutral
Every practice can be met with a spreadsheet, a shared drive and a calendar. Tools speed things up; they are never a prerequisite.
Write once, map many
One programme should satisfy SOC 2, ISO 27001, NIS2 and DORA customer due diligence. The crosswalk is part of the standard.
Both sides of the table
Startups are buyers and suppliers. Running your own programme well also makes it easier to answer your customers’ vendor reviews.
Open and versioned
The standard is published openly, with version numbers and a change log, and anyone can propose changes.
Maturity
Five levels, tied to stage and to the events that move you up.
| Level | Typical stage | What pulls you here |
|---|---|---|
| Level 0: Unaware | Pre-seed, under 10 people | None yet. |
| 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. |
| 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. |
| 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. |
| 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. |
Funding stage is only a proxy. A seed company selling to European banks needs Level 3 practices early; a Series B company with no regulated customers may be well served at Level 2. The maturity page lists exactly which practices each level requires, and how to claim one.
Getting started
Reach Level 1 in a day.
- Build the registerDownload the register template and fill it from the last twelve months of card and bank statements, then your single sign-on app list.
- Name an owner for every vendorThe person whose team uses the vendor owns it. No blanks.
- Tier every vendorAnswer the five rubric questions for each one. Most will be Tier 3, and that is the point.
- Add contracts and renewal datesLink each contract and put every notice deadline in a shared calendar.
- Sign the policyFill in the two-page policy template, have a founder approve it, and set up an intake form for new vendors.
That covers the Level 1 practices except offboarding, which you start using the next time a vendor goes. Everything you need is on the templates page.
Using the standard
Licence, conformance and versions.
| Topic | Details |
|---|---|
| Licence | The text, guidance and document templates are CC BY 4.0: use, adapt and redistribute them, commercially or not, with attribution to OpenVMO. The register template, register schema, measures sheet and crosswalk are CC0 1.0, so tools can import them with no conditions. |
| Claiming a level | "Self-assessed at OpenVMO v1.0 Level 2 on <date>" means every practice with a minimum level of 2 or lower is evidenced. The claim is all-or-nothing per level, with no percentages. |
| Versions | Versions are numbered. Changes to required practices or levels raise the major version; added guidance, optional checks and crosswalk columns raise the minor version. A claim always names the version it was made against. |
| Stewardship | OpenVMO was written and is maintained by Vendorapp. The standard is vendor-neutral: no practice requires Vendorapp or any other product. |
| Suggesting changes | Email support@vendorapp.cowith "OpenVMO" in the subject. Practitioners, auditors and tool makers are especially welcome. |
FAQ
Common questions.
Is OpenVMO free?
Yes. The standard and every template are free, with no sign-up. The text is CC BY 4.0 and the machine-readable files are CC0.
Do I need Vendorapp to use it?
No. Every practice can be met with a spreadsheet, a shared drive and a calendar. Vendorapp is one way to implement it, and the mapping page says plainly where it does and does not cover a practice.
How does it relate to SOC 2, ISO 27001, NIS2 and DORA?
OpenVMO is not a replacement for any of them. It is an operating model for the vendor parts of all of them. The crosswalk maps each practice to the related SOC 2 criteria, ISO 27001:2022 controls, NIS2 articles, DORA articles and NIST CSF 2.0 outcomes, so one programme can serve several audits.
Which level should we aim for?
The one your next trigger demands. A first enterprise questionnaire calls for Level 1. A SOC 2 or ISO 27001 audit calls for Level 2. Regulated customers in NIS2 or DORA scope call for Level 3.
How is this different from a vendor questionnaire?
A questionnaire is what you send a vendor. OpenVMO is how you run your own programme: which vendors to ask, what to accept instead of a questionnaire, what to put in the contract, and what to do afterwards.
Can we certify against it?
Not at present. Conformance is by self-assessment. You can publish a self-assessed level, and auditors and customers can check the evidence behind 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.