Vendorapp › OpenVMO › Intake and onboarding
Intake and onboarding in OpenVMO.
Intake is the front door. Anyone in the company can ask for a new vendor, and the request captures enough to decide how much checking it needs before anyone hands over data or access.
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.
Most vendor risk enters through a credit card and a free trial. A light intake route turns that into a register entry and a tier on day one, instead of a surprise during the next audit.
Intake and onboarding 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 4 INT practices.
Defined intake route
There is a known way to request a vendor, and the request records purpose, data, access and the business owner. Evidence: The intake form or channel, and completed requests for recent vendors.
Approval scales with tier
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. Evidence: Approval records showing who approved each recent vendor, matching its tier.
No access before checks
No production data or system access is given before the vendor is tiered and its required due diligence is complete. Evidence: For a sample of vendors, the diligence date comes before the date access was granted.
Shadow IT caught and back-filled
Vendors found outside the intake route are put through it after the fact. Evidence: Register entries marked as back-filled, with their tier and checks completed.
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 | A simple request form or channel that captures purpose, data, access and owner. |
| Level 2: Managed | Approval gates that scale with tier, and no data or access until the checks are done. |
| Level 3: Defined | Intake connected to purchasing and identity, so a vendor cannot be paid or connected without a register entry. |
| Level 4: Optimised | Intake is part of procurement, with measured time from request to approval. |
With a spreadsheet
Doing it without any special tool.
- Use the eight-field OpenVMO intake form as a shared form that writes to the register.
- Ask finance to bounce any new recurring charge that has no register entry.
- Publish one sentence in the company handbook: "new vendors go through this form".
Common mistakes
Where teams usually go wrong.
- Making intake so heavy that people route around it. Tier 3 vendors should take minutes.
- Checking the vendor after the team has already uploaded customer data.
- Ignoring free tools. A free plan with customer data in it is a Tier 1 vendor.
Crosswalk
How this maps to the frameworks you are audited against.
| Framework | Related requirements |
|---|---|
| SOC 2 (Trust Services Criteria) | CC9.2, CC6.1 |
| ISO/IEC 27001:2022 | A.5.19, A.5.23 |
| NIS2 and Implementing Regulation 2024/2690 | CIR 2024/2690 Annex §5.1 |
| DORA | Art. 28(4) |
| NIST CSF 2.0 | GV.SC-06 |
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.
- Intake form (Markdown): Eight fields that capture what you need to tier a new vendor before anyone signs up.
All OpenVMO templates are on the templates page.
Previous domain: Vendor inventory. Next domain: Risk tiering.
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.