A spreadsheet as your vulnerability register: it works until it doesn't

Almost every company that starts managing vulnerabilities on purpose starts with a spreadsheet. That is not a mistake. It is the natural first step and for a while it genuinely works. Columns for the CVE, the server, severity, status and deadline, a handful of rows, one admin who knows what runs where. No tool is needed for that, and pushing such a person towards a platform would be selling a solution to a problem they do not have.

I have kept vulnerabilities in a spreadsheet myself and there is nothing shameful about it. It is only worth knowing where this model breaks, because it breaks quietly, with no error message, and it is usually discovered at the worst possible moment: during an audit.

Where a spreadsheet works well

Let us be honest, because without that the rest reads like an advert. A spreadsheet is enough when:

• you have a handful of machines and one person who actually reads the scan results,
• nobody audits you and you do not have to report for a period in the past,
• the history of what was fixed interests nobody but you,
• the number of open vulnerabilities is small enough to hold in your head.

In that setup a spreadsheet beats any platform, because it has zero deployment cost and zero learning curve. If that is your case, stop reading and get back to work. You are not missing anything.

First crack: freshness depends on the data feed

A vulnerability scan is a picture from a specific moment. CVE databases update daily, packages get patched, new vulnerabilities appear in things that were clean yesterday. The spreadsheet knows none of it. It is only as current as the last time someone manually transcribed results into it.

In practice, the spreadsheet starts becoming stale after the next environment change or publication of new vulnerability data unless it has an automated feed. The file itself does not reveal whether the data is an hour old or a month old. Microsoft 365 does provide co-authoring, version history and change tracking. The issue is therefore not the spreadsheet format itself, but a manual workflow without one source of truth and automated import.

Second crack: no history

A typical manual register shows state but has no structured event log for each vulnerability. File version history may help reconstruct a change, but it does not replace an easy query for who closed a specific finding, when and why. Without a separate record, the answer requires manual comparison of versions.

That is a question that may arise in an audit. The auditor may want to see that a vulnerability detected three months ago was handled on time, with dated evidence. A spreadsheet used only for current state cannot provide that answer without additional records.

Third crack: version drift

A spreadsheet copies itself. One version on the network drive, another in an email to the boss, a third locally on someone who "just wanted to check". A month later nobody knows which one is real. Someone makes a change on a copy that never returns to the main file, and the record of that fix is lost.

This is not an unavoidable Excel flaw: Microsoft 365 co-authoring limits the problem. Version drift appears when the organisation still circulates copies and has not established one source of truth.

Fourth crack: nothing is enforced

In a spreadsheet everything is optional. The "owner" column is often empty because nobody was forced to fill it. The "deadline" column exists, but nothing makes an overdue deadline stand out. A risk acceptance entry is a cell of text, with no signature, no expiry date, no record of who was entitled to make that decision.

A register where the fields critical to the process are optional becomes, in practice, a wish list. It looks like a process but enforces nothing.

Fifth crack: manual transcription

The scanner output is JSON. The register is a spreadsheet. Between them sits a human, transcribing. With twenty machines and a few hundred findings a day, that is hours of work in which errors creep in: a typo in a CVE number, a skipped row, the wrong package version. The more tedious the task, the more mistakes, and it is hard to find anything more tedious than transcribing scans by hand.

What preparing audit evidence looks like

All of the cracks above converge at one moment: when you have to produce evidence for a period. In the spreadsheet model that means weeks of gathering screenshots, digging old copies out of email, reconstructing from memory when things were fixed. The result is as credible as the sources were, which is to say moderately.

What a minimal real register needs

The point is not to replace the spreadsheet with something complicated. It is five things a spreadsheet cannot give you by nature:

• automatic feed straight from the scanner, no manual transcription,
• a change history where nothing disappears, only new states are appended,
• enforced owners and deadlines, where an overdue deadline flags itself,
• a risk acceptance path with a signature and an expiry date,
• evidence export for any period in one move, not a week of gathering.

I built Secvalis around these five things, because they are what separates a register that survives an audit from a spreadsheet that only looks like one. If you want to see what a register fed automatically from the scanner looks like, with history and deadlines, enter the demo. No registration, fictional data.

A spreadsheet is not bad. It is a good beginning that stops being enough exactly when someone external starts asking about the past. Better to know that moment is coming than to discover it a week before the audit.

Sources

• Microsoft: collaborate on Excel workbooks with co-authoring
• Official KSC Act FAQ