Vendorapp › OpenVMO › Third-party incidents
Third-party incidents in OpenVMO.
When a vendor has an incident, it often becomes yours. This domain makes sure vendor incidents are logged, your Tier 1 vendors are in your incident response plan, and you check whether a vendor’s incident starts your own reporting clock.
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.
A vendor breach can trigger your own deadlines: 72 hours under GDPR, 24 hours for an early warning under NIS2, or whatever your customer contracts say. Finding the vendor’s security contact during the incident is too late.
Third-party incidents 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 INC practices.
Vendor incident log
There is a way to log vendor incidents with severity, impact and actions taken. Evidence: The incident log, with entries for any vendor incidents in the period.
Vendors in the response plan
Tier 1 vendors are named in your incident response plan with security contacts and notification windows. Evidence: The incident response plan section listing Tier 1 vendors and contacts.
Own reporting duties assessed
Each vendor incident is assessed for your own notification duties under GDPR, NIS2 and customer contracts. Evidence: For each vendor incident, the recorded decision on whether you had to notify, and when.
Vendor scenario exercised
At least one exercise a year includes a vendor outage or vendor breach scenario. Evidence: The exercise record and the actions that came out of it.
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 | Not yet required, but keep your Tier 1 vendors’ security contacts somewhere you can find them. |
| Level 2: Managed | Vendor incidents logged, Tier 1 vendors in the response plan, notification duties checked every time. |
| Level 3: Defined | A vendor scenario in the annual incident exercise. |
| Level 4: Optimised | Joint exercises with critical vendors, and incident trends used in tiering and monitoring. |
With a spreadsheet
Doing it without any special tool.
- Add a "security contact" column for Tier 1 vendors.
- Keep a vendor incident tab: date, vendor, what happened, severity, your decision on notification, actions.
- Add a "vendor X is down or breached" scenario to your next tabletop exercise.
Common mistakes
Where teams usually go wrong.
- Treating a vendor breach as the vendor’s problem and missing your own deadline.
- Having no security contact for a Tier 1 vendor beyond its sales rep.
- Running incident exercises that never involve a third party.
Crosswalk
How this maps to the frameworks you are audited against.
| Framework | Related requirements |
|---|---|
| SOC 2 (Trust Services Criteria) | CC7.3–CC7.5, CC9.2 |
| ISO/IEC 27001:2022 | A.5.24–A.5.26 |
| NIS2 and Implementing Regulation 2024/2690 | Art. 21(2)(b); Art. 23 |
| DORA | Art. 17–19 |
| NIST CSF 2.0 | GV.SC-08 |
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.
- 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: Fourth parties and supply chain. Next domain: Offboarding and exit.
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.