The data layer beneath the dashboard

I will say the thing this whole site keeps circling, plainly.

A dashboard is a picture of your data. It does not store anything, it does not compute anything from scratch, it reads from somewhere and draws. So a dashboard can never be more trustworthy than the data underneath it. Never.

This sounds obvious written down. It is somehow invisible when you are shopping for tools, because every dashboard, on every tool, looks authoritative. A clean chart on top of solid data and a clean chart on top of garbage look identical. You cannot tell which is which from the picture. That is the trap.

Two layers, not one

Stop thinking of a security dashboard as one thing. It is two.

The top layer is visualization. Charts, scores, trends, filters. This is what you see, what you compare on the tool comparison page, what vendors demo. It is the easy layer. Honestly, it is close to a solved problem. Any decent tool draws a good chart now.

The bottom layer is the data. Where every number comes from, whether sources agree on what they are counting, whether you can reproduce a figure next quarter, whether you can prove how any number was derived. This is the layer nobody demos, because it is not glamorous and it is hard. And it is the layer that decides everything.

When two teams use the same dashboard tool and one trusts its numbers while the other quietly does not, the difference is always the bottom layer. Always.

What the bottom layer has to do

For a dashboard you can actually stand behind, the data underneath has to do four things the dashboard itself never does.

Collect, consistently. Pull from every relevant tool on a schedule, not by hand when someone remembers.

Normalize. Reconcile the different ways your tools count things, so "critical vulnerability" means one thing across your whole program, not five things depending on the scanner.

Record. Keep the computed numbers over time, so you can show a trend and recreate any past figure, even after the source tool has rolled its data over.

Trace. Keep the provenance, so when someone asks "how did you get this," you have a real answer, not a shrug and a spreadsheet.

A dashboard tool does none of these. It assumes they are already done. In most programs, they are not, which is the security dashboard data problem in one sentence.

The finance analogy that makes it click

Finance solved this a century ago. The dashboards a CFO shows the board are not the system of record. Underneath them sits the general ledger, the disciplined, auditable record of every number. The dashboard is just a view on the ledger. Nobody confuses the two. Nobody would dream of running a company off dashboards with no ledger underneath.

Security has the dashboards and, mostly, not the ledger. We built the view and skipped the record. Then we act surprised when a board member asks a question the view cannot answer.

The fix is not a better dashboard. It is the missing ledger. For security, that ledger has a name now: a security KPI system of record.

What to do with this

If you are choosing a dashboard tool, fine, choose one, they are mostly good. But spend at least as much thought on the layer underneath, because that is what your credibility in the board room actually rests on.

If you have ever been unable to defend a number, reproduce a past figure, or explain why two dashboards disagree, you have met this problem already. It was never the dashboard. It was the missing layer beneath it.

Read next: the security dashboard data problem, or what a security KPI system of record is.