How to Tell If Your Security Program Is Actually Working

The direct answer: a security program that is actually running can produce eighteen dated records on demand: an approved policy set with approval dates, a current risk register with owners, accepted risks signed with expiry dates, a system and application inventory, a device coverage report, last quarter's access review sign-off, a vulnerability report with closure rate, a penetration test and remediation record, an incident response plan with a recent revision date, the last tabletop exercise with findings, a restore test result against the stated RTO, a business impact analysis with RTO and RPO, a tiered vendor list with assessment dates, a data classification and retention record, awareness completion and phishing results, change approvals for the last quarter, the cyber insurance policy with representations that still hold, and the last board report as presented. Every item is a record with a date. No opinion involved.
This is the proof set from our recent town hall, A CISO in the Room, and it is the second half of an argument that started with the fourteen domains a well-run program covers. The domains describe the work. The artifacts prove the work happened. If you only have time for one exercise this quarter, run this one: open the list below and ask, for each row, can we produce this today?
Records, not opinions
Every security program sounds fine when it is described. Maturity self-assessments, steering committee updates, and vendor questionnaires are all narrated by someone with an interest in the answer. Artifacts do not narrate. A restore test result from March either exists or it does not. An access review sign-off either carries last quarter's date or it carries last year's. This is exactly how the outside world already evaluates you: an auditor samples records, a carrier holds you to the representations on the application, an enterprise customer asks for the pen test, and an incident asks for everything at once, with no notice at all.
So the test is deliberately blunt. A valid artifact is a record, it has a date, and you can put your hands on it in about five minutes, as it was created. Rebuilt for the request does not count. Updated for the occasion does not count. If the honest answer is that the record could be assembled by Friday, the honest score is a zero for that row.
The eighteen artifacts
Here is the full set, with what each record proves and the tell that it has gone stale. The tells are not hypotheticals; each one is something we have found inside a real environment.
| # | Artifact | It proves | Stale when |
|---|---|---|---|
| 01 | Approved policy set, with approval dates | Governance actually convenes | Approvals older than four quarters |
| 02 | Current risk register with owners | Risk is managed, not collected | Rows without owners, scores that never move |
| 03 | Accepted risks, signed, with expiry dates | Someone accountable said yes | Acceptances without expiry, or expired and still standing |
| 04 | System and application inventory | You know what you are protecting | Predates the last migration |
| 05 | Device coverage report | Endpoints are managed, not assumed | A coverage number nobody can state |
| 06 | Last quarter's access review sign-off | Access is reviewed, not accumulated | Signed, but nothing was ever removed |
| 07 | Vulnerability report with closure rate | Findings get closed, not just found | Scan output with no closure number |
| 08 | Penetration test and remediation record | Weaknesses are found and then fixed | A test report with no remediation trail behind it |
| 09 | Incident response plan, last revised | You can act under pressure | Stale phone numbers, departed names |
| 10 | Last tabletop exercise, with findings | The plan has been rehearsed | A tabletop that produced zero findings |
| 11 | Restore test result against stated RTO | Recovery is proven, not hoped for | Backups held, restore never run |
| 12 | Business impact analysis, RTO and RPO | You know what matters and how fast | Objectives set once, years ago, or never |
| 13 | Vendor list, tiered, with assessment dates | Third parties are watched | A flat list, no tiers, no dates |
| 14 | Data classification and retention record | You know what data you hold | Classification on paper only |
| 15 | Awareness completion and phishing results | Behavior is measured, not assigned | Completion tracked, click rate unknown |
| 16 | Change approvals for the last quarter | Change is controlled | Changes shipped, approvals reconstructed later |
| 17 | Cyber policy with current representations | Insurance would actually respond | Representations that no longer hold |
| 18 | Last board report, as presented | Leadership sees the real state | No report, or one rebuilt from memory |
Notice what is not on the list: tool counts, framework names, certification logos, headcount. None of those prove a program is running. All eighteen rows are outputs of work, and each maps back to one of the fourteen domains and the cadence it runs on. A domain with a heartbeat produces its artifact as a side effect. A domain without one produces the artifact the week someone asks.
Most programs score eleven
When we walk a new environment through this list, the typical result is about eleven of eighteen. And the missing seven are almost always the same seven: the restore test result, the tabletop findings, the business impact analysis, accepted risks with real expiry dates, change approvals, the data classification record, and insurance representations that still hold at renewal.
The pattern is not a mystery. Every artifact that stays fresh has an external party waiting on it: the auditor gets the policy set, the customer gets the pen test, the carrier gets the application. Every artifact that goes missing has nobody outside the building asking. This is the same asymmetry that shapes the fourteen domains: the work that decays first is the work with no external forcing function. Cadence exists to manufacture that forcing function, and the artifact is how you know the cadence held.
Which of the eighteen could you produce today?
Z Cyber's first working session does exactly this: walk your proof set, row by row, and tell you honestly where it stands.
The one-person problem
There is a moment in the town hall where the list lands and someone always has the same reaction: can one person really produce all this? The honest answer is no, not sustainably, and the wrong conclusion is to hire more people to make binders. In most mid-market companies these records live in one person's head and inbox, which means the program's proof evaporates when that person is on vacation, or leaves, or is the one managing the incident that the records are needed for.
The durable answer is structural: the artifacts should live where the work happens, dated, in your own tenant, so that producing them is a lookup rather than a project. That is the operating model our own service is built on. The Executive Security Advisor runs the cadence that generates each record, and Glance is the system the records live in, so the answer to can you produce this today is yes by construction. You decide and you own the risk; the advisor prepares and recommends; the platform remembers. Nobody's inbox is the system of record.
How to run the test this week
Take the table into your next security meeting and score it honestly, using the five-minute rule: the artifact counts only if you can produce it in five minutes, as it was created, with a date on it. Three outcomes are useful. The score itself gives you a baseline that no self-assessment will. The missing rows give you a work plan that is already prioritized, because the absent artifacts mark the domains with no heartbeat. And the stale tells in the last column give you the honest conversation: an access review that removed nobody and a tabletop that found nothing are not evidence of health, they are evidence that the exercise was ceremonial.
Nobody scores eighteen for eighteen, and the point is not a perfect score. The point is that this is the standard an incident, a customer, an auditor, or a carrier will apply to your program without asking permission first. Better to apply it to yourself on a quiet Tuesday than have it applied to you on a loud one.
Watch the full walkthrough
The eighteen artifacts are one part of the town hall session, which also covers the fourteen domains behind them and a live tour of how the model runs in Glance. The recording and the deck are available on the event page. And if you want your own proof set walked row by row, talk to a Z Cyber advisor; it is the first thing we do.
Frequently Asked Questions
What evidence shows a cybersecurity program is actually working?
Eighteen dated records, produced on demand: an approved policy set with approval dates, a current risk register with owners, accepted risks signed with expiry dates, a system and application inventory, a device coverage report, last quarter's access review sign-off, a vulnerability report with closure rate, a penetration test with its remediation record, an incident response plan with a recent revision date, the last tabletop exercise with findings, a restore test result against the stated RTO, a business impact analysis with RTO and RPO, a tiered vendor list with assessment dates, a data classification and retention record, awareness completion with phishing results, change approvals for the last quarter, the cyber insurance policy with current representations, and the last board report as presented. Every item is a record with a date. No opinion involved.
What security artifacts do auditors, customers, and insurers ask for?
Largely the same set, sampled from different angles. Auditors ask for policy approvals, access review sign-offs, change approvals, and evidence that is current rather than assembled for fieldwork. Enterprise customers ask for the penetration test, the incident response plan, the vendor list, and proof of recovery. Insurance carriers ask whether the representations on the application still hold, which quietly depends on most of the rest. A program that can produce all eighteen on demand stops preparing for these requests, because the preparation is the program.
How many of these artifacts can most companies produce?
About eleven of the eighteen, in our experience. The missing seven are almost always the same ones: the restore test result, the tabletop findings, the business impact analysis, accepted risks with expiry dates, change approvals, the data classification record, and representations that still hold at renewal. What the missing set has in common is that no external party is waiting on any of it. Audit-facing artifacts stay fresh because fieldwork is scheduled; the rest decay quietly until an incident asks for them.
What makes an artifact valid proof?
Three properties. It is a record, not a narrative: a sign-off, a test result, a register, a report. It carries a date, so it shows when the work actually happened rather than that it happened once. And it is producible in about five minutes, as it was created, not reconstructed for the request. A board deck rebuilt from memory, an inventory updated for the occasion, or an approval logged after the fact all fail the test, because each one is an opinion wearing the costume of a record.
How is this different from passing an audit?
An audit samples a subset of this evidence, once a year, with notice. The eighteen artifacts test is the same standard applied without notice, which is how incidents, customers, and carriers apply it. Programs rarely fail at the audit; they fail on a random Tuesday, when the escalation list has a stale number in it or the backup that was always held has never actually been restored. If the artifacts exist, dated and current, the audit becomes a formality. The reverse is not true.
Subscribe for Updates
Get cybersecurity insights delivered to your inbox.


