A small team does not need a dashboard product. Track five things monthly in a spreadsheet: exploited vulnerabilities open on public services, age of the oldest critical, accounts without multi factor authentication, repositories with secret scanning on, and last tested backup restore. Review them for 30 minutes.
Why keep it small
Without a dedicated security person, metrics compete with product work. If collecting them takes a day, they will be skipped. Choose numbers that a script or a quick query can produce, and that map to actions an engineer can take.
The five measurements
1. Exploited vulnerabilities open on public services. List the internet facing services, then count findings that appear in a known exploited list. Target is zero. This is the single most urgent number.
2. Age of the oldest open critical. One number and one name. Review it every month and decide: fix, mitigate or accept with a date.
3. Accounts without multi factor authentication. Count for your identity provider, code host, cloud console and email. Target is zero for admin accounts first.
4. Repositories with secret scanning and dependency alerts on. Percentage of active repositories. Turning it on is often a setting, not a project.
5. Date of the last successful backup restore test. A backup that was never restored is a hope. Track the date, not the count of backups.
How to collect
Put the five numbers in a sheet with one row per month. Add a notes column for changes in scope. Fifteen minutes of querying and a few minutes of comparison is enough. Keep a link to where each number comes from.
The monthly review
Hold a 30 minute review with an engineering lead present. Ask three questions: what got worse, what is the next thing that could hurt us, and what will we do before next month? Write down one action with an owner.
What to add later
When these are steady, consider adding coverage of dependency scanning across repositories, time to fix by tier, and a count of third party services with access to production data. Follow a growth path rather than starting with twenty metrics. See the metric definition card when you add each one.
Tools
You can get most of this from settings pages and exports in tools you already use. If you want a starting point for dependency findings, a free scan shows vulnerable dependencies in a project, and Safeguard's CLI and IDE extensions can bring scanning closer to the developer.
Make it part of existing routines
Do not create a new ritual if you can attach this to one that exists. Many small teams have a monthly engineering all hands or a retrospective. Add a five minute slot with the five numbers and the one action. It is more likely to survive a busy quarter than a separate meeting.
If nobody wants to own it, rotate the job among senior engineers. Rotation spreads security awareness, and each person improves the collection script a little.
Quick check
Do we need to report these to anyone?
Report them to whoever owns engineering risk, even if that is the CTO. A short monthly note is enough.
What if the first month looks bad?
That is a baseline, not a verdict. Fix the exploited items first and watch the trend.
Last reviewed: 19 October 2026.
