A small team can prioritize vulnerabilities without a configuration database by keeping a one page spreadsheet of its services, with columns for owner, environment, exposure, data label, tier and controls. Fill in the top services first, apply cautious defaults to the rest, and update it when things change.
You are not alone in this
Many teams have no CMDB, or have one that nobody trusts. That is not a reason to rank findings by scanner score alone. A small, honest list beats a large, stale system.
NIST SP 800-40 Rev. 4 describes enterprise patch management as a process of identifying, prioritizing, acquiring, installing and verifying updates. You can follow that sequence at any scale. The prioritizing step needs only enough asset facts to change an order.
The one page sheet
Create a sheet with one row per service or application, not per server. For a small team, ten to forty rows is typical.
| Column | Values |
|---|---|
| Service | Name |
| Owner | Team or person on call |
| Environment | Production, staging, other |
| Exposure | Public, authenticated, internal, isolated |
| Data | Restricted, Confidential, Internal, Public |
| Tier | 1, 2, 3 |
| Controls | None, or named control and date verified |
Resist adding columns. Every column is a chore, and chores get skipped.
Steps
- List your production services from memory, then check against cloud accounts and repositories.
- Fill owner and exposure first, because they change what you do soonest.
- Label data and tier in a thirty minute conversation with whoever knows the business.
- Leave unknown cells blank, and treat blanks as the cautious choice.
- Link each finding to a service by name.
Defaults for what you do not know
- Unknown owner: the engineering lead owns it until someone else claims it.
- Unknown exposure: assume public.
- Unknown data: assume Confidential.
- Unknown tier: Tier 2.
Defaults that lean cautious keep unknown assets from being ignored.
A simple triage order
With the sheet in hand, sort findings this way:
- Anything known to be exploited, found on CISA's Known Exploited Vulnerabilities Catalog or similar evidence.
- Findings whose vulnerable code your application actually calls.
- Public facing services before internal ones.
- Restricted and Confidential data before the rest.
- Tier 1 before Tier 2 before Tier 3.
Do the top of the list this week, and put dates on the next group.
Grow only when it hurts
Move from a sheet to a tool when the sheet becomes a burden: too many services, several teams editing it, or a need for automatic ticket routing. Until then, simplicity wins.
A caution on spreadsheets
A shared sheet can be edited by anyone, and entries change without notice. Name one person as keeper, keep a change history, and review the sheet monthly. That is enough governance for a small team.
Where Safeguard fits
Safeguard offers asset discovery and reachability analysis, which can pre fill several of these columns. Safeguard also offers a free scan at gold.safeguard.sh/scan if you want to see your own dependency findings first.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how many findings fall away once code that is never called is set aside.
Quick check
Is a spreadsheet really enough?
For a small number of services, yes. Move to a tool when the sheet becomes hard to keep accurate.
What should I fill in first?
Owner and exposure. They change who acts and how fast.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
