Tier suppliers and components by the damage a failure or compromise would cause, then match review depth to the tier. Three tiers are enough for most organizations: critical, important and routine. Without tiers, either everything gets a heavy review or nothing does.
Why tiering is a governance step
CSF 2.0 outcome GV.SC-04 says suppliers are known and prioritized by criticality. NIST SP 800-161 Rev. 1 refers to criticality analysis as an input to which controls apply, and points to NIST IR 8179, a criticality analysis process model for prioritizing systems and components. You do not need that full model to start, but the principle is the same: you cannot treat everything as equally important.
Criteria to score
For each supplier or component, ask five questions.
- Does it handle authentication, secrets, payments or customer data?
- Does it run with high privilege or sit in the build pipeline?
- Is it exposed to the internet or to untrusted input?
- Could we replace it within a sprint if it failed?
- How many products or services depend on it?
Score each question as low, medium or high, and use the highest answer as a guide rather than adding numbers. A single high on question one or two is usually enough to make something critical.
Three tiers and what each gets
| Tier | Examples | Intake | Monitoring | Exception authority |
|---|---|---|---|---|
| Critical | Auth libraries, build tools, cryptography, widely shared base images | Review group, documented assessment | Continuous, owner named | Review group or executive |
| Important | Frameworks for customer-facing services | Automated checks plus spot review | Continuous | Review group |
| Routine | Internal tooling, development utilities | Automated checks | Periodic | Team |
These are illustrative. Tune them to your environment.
Steps
- Export a component inventory from your repositories and builds.
- Group by service and tag each service by business criticality.
- Apply the five questions to the shared components, starting with those used in many services.
- Assign tiers and record the reason in one line.
- Publish the tier rules, so teams can self-classify new additions.
- Revisit tiers when a service changes exposure or a component's role changes.
Edge cases
- Transitive dependencies. A small package pulled into an authentication path inherits that path's criticality.
- Dev dependencies. These rank lower for runtime risk, but build tools can still be a route for tampering.
- A supplier with many products. Tier the product, not the company.
Common mistakes
- Tiering by vendor size or brand rather than by function.
- Doing it once. Tiers drift.
- Building a spreadsheet nobody owns. Assign a maintainer.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the shared components that appear across many services, since they are first in line for a higher tier.
Safeguard's asset discovery and SBOM and dependency scanning produce the inventory this method starts from, and a free scan shows how that inventory looks for one project.
Quick check
How many tiers do we need?
Three is usually enough. More tiers add process without adding clarity.
Do open source packages get tiered too?
Yes. They are suppliers without contracts, and often the most widely shared.
Sources
Last reviewed: 19 October 2026.
