Use a risk-based cadence. Critical vendors should be reassessed more often, while lower-risk vendors can be reviewed annually. Reassessment should also be triggered by breaches, expired certifications, material changes in the vendor’s data access, or significant control changes. The goal is to keep the risk view current, not archival.
Why This Matters for Security Teams
Vendor reassessment is not a paperwork exercise. It is the control that keeps third-party risk tied to current business reality rather than the last questionnaire cycle. A vendor can move from low risk to high risk quickly if it gains new data access, changes hosting, introduces subcontractors, or suffers a security incident. Current guidance from OWASP Non-Human Identity Top 10 also highlights that machine-to-machine access often expands silently, which makes stale reviews especially dangerous when vendors operate APIs, service accounts, or automation on behalf of the organisation.
The main failure is treating reassessment as a calendar event only. That approach misses the moments when the vendor’s actual exposure changes, which is when the control matters most. Security teams also underestimate how quickly contractual scope can drift from technical scope, especially when procurement records are not synced with security reviews. In practice, many security teams encounter vendor risk only after an incident, a failed audit, or a customer complaint, rather than through intentional ongoing monitoring.
How It Works in Practice
Most organisations decide reassessment timing by combining inherent risk, data sensitivity, connectivity, and concentration of dependence. High-impact vendors usually get shorter review cycles because they can affect availability, confidentiality, or regulatory obligations if they fail. Lower-impact vendors can be reviewed less often, but they still need event-driven triggers so the risk picture stays current. This is consistent with the intent of CISA supply chain risk guidance, which treats vendor risk as dynamic rather than static.
A practical reassessment programme usually includes both scheduled and trigger-based reviews:
- Set a baseline cadence by risk tier, such as quarterly for critical suppliers and annually for lower-risk suppliers.
- Trigger an immediate review after a breach, ransomware event, major outage, or control failure.
- Reassess when the vendor’s certifications expire or their assurance evidence changes materially.
- Reassess when the vendor gains new access to sensitive systems, production data, or privileged interfaces.
- Reassess when ownership, subcontracting, hosting region, or service architecture changes.
Security teams should also connect reassessment to technical signals, not just procurement updates. If a vendor uses API keys, service accounts, or federated access, changes to those credentials can be a leading indicator that the vendor’s operational risk has changed. The most mature programmes link vendor review to identity governance, because third-party access often behaves like a non-human identity footprint once integrations are live. That is especially important where vendors automate actions through privileged workflows or managed integrations.
Where possible, the reassessment should answer three questions: has the vendor’s exposure changed, has the control evidence changed, and has the business dependency changed. If all three remain stable, a reassessment can often wait. These controls tend to break down in fast-moving SaaS environments because product releases, integrations, and delegated access can change faster than the vendor review cycle.
Common Variations and Edge Cases
Tighter reassessment cycles often increase operational overhead, requiring organisations to balance continuous visibility against review fatigue. That tradeoff becomes more visible in environments with hundreds of low-value suppliers, where annual reassessment for all vendors creates workload without improving decisions. Best practice is evolving toward risk-tiering, event-based alerts, and evidence reuse so teams can focus on material changes rather than repeating the same review.
Edge cases matter. A vendor with little direct data access may still be critical if it supports payroll, incident response, or production uptime. Conversely, a vendor with broad theoretical access may be less risky if technical segmentation, scoped permissions, and monitored integrations sharply limit what it can actually do. Reassessment should therefore reflect actual privilege and data flow, not contract labels alone.
Another common exception involves outsourced platforms that bundle many subprocessors. In those cases, organisations should treat subprocessor changes as reassessment triggers even if the primary contract has not changed. If the vendor acts as an automated integration partner, service account governance becomes part of vendor review, and identity controls should be checked alongside the traditional questionnaire. The NIST Cybersecurity Framework remains useful here as a baseline for governance, but it must be adapted to vendor-specific exposure and business criticality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-03 | Third-party risk governance requires repeat review based on changing supplier exposure. |
| MITRE ATT&CK | T1195 | Supply chain compromise is a core reason to reassess vendors after incidents or trust shifts. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Vendor service accounts and API access can behave like non-human identities that drift over time. |
| NIST AI RMF | If vendors run AI services, risk and monitoring should reflect model and data changes. | |
| DORA | Article 28 | ICT third-party oversight demands ongoing reassessment of critical providers and dependencies. |
Review critical ICT providers on a recurring basis and after material incidents or service changes.
Related resources from NHI Mgmt Group
- How should organisations govern third-party access in a vendor risk policy?
- How accountable are organisations for third-party access when a vendor is breached?
- How should organisations govern third-party identity access more tightly?
- How can organisations secure third-party privileged access in hybrid environments?
