Program design
Vendor tiering that changes the workflow
If every tier gets the same questionnaire, review date, and approval path, the tiers are decoration. A useful model changes the work.
Start with impact, not vendor fame
A recognizable vendor is not automatically low risk, and a small vendor is not automatically immaterial. Tiering should begin with the relationship: what service is delivered, which data is handled, what access exists, and what happens if the service fails.
Ask for observable business context before asking security questions. This keeps inherent risk separate from the quality of a vendor's controls.
Make each tier operationally different
- Critical: full assessment, evidence review, named executive decision, and event-driven monitoring.
- High: focused assessment, security owner approval, annual review, and tracked treatment for material findings.
- Moderate: scoped questionnaire, business owner decision, and review based on contract or material change.
- Low: lightweight intake, ownership record, and review when service or data exposure changes.
Use escalation rules instead of exceptions by email
A low-tier vendor can become high risk when scope changes. A moderate vendor can require executive acceptance when one finding is severe enough. Define those escalation conditions in the workflow so analysts do not have to negotiate process on every review.
Measure whether tiers reduce effort
Track assessment length, analyst time, overdue reviews, and the number of vendors escalated after intake. A useful model spends less effort on immaterial relationships while increasing scrutiny where the business consequence is real.