Skip to main content
AdvisoryBy Jason LeeAugust 26, 202610 min read

How to Tell If Your Security Program Is Actually Working

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
01Approved policy set, with approval datesGovernance actually convenesApprovals older than four quarters
02Current risk register with ownersRisk is managed, not collectedRows without owners, scores that never move
03Accepted risks, signed, with expiry datesSomeone accountable said yesAcceptances without expiry, or expired and still standing
04System and application inventoryYou know what you are protectingPredates the last migration
05Device coverage reportEndpoints are managed, not assumedA coverage number nobody can state
06Last quarter's access review sign-offAccess is reviewed, not accumulatedSigned, but nothing was ever removed
07Vulnerability report with closure rateFindings get closed, not just foundScan output with no closure number
08Penetration test and remediation recordWeaknesses are found and then fixedA test report with no remediation trail behind it
09Incident response plan, last revisedYou can act under pressureStale phone numbers, departed names
10Last tabletop exercise, with findingsThe plan has been rehearsedA tabletop that produced zero findings
11Restore test result against stated RTORecovery is proven, not hoped forBackups held, restore never run
12Business impact analysis, RTO and RPOYou know what matters and how fastObjectives set once, years ago, or never
13Vendor list, tiered, with assessment datesThird parties are watchedA flat list, no tiers, no dates
14Data classification and retention recordYou know what data you holdClassification on paper only
15Awareness completion and phishing resultsBehavior is measured, not assignedCompletion tracked, click rate unknown
16Change approvals for the last quarterChange is controlledChanges shipped, approvals reconstructed later
17Cyber policy with current representationsInsurance would actually respondRepresentations that no longer hold
18Last board report, as presentedLeadership sees the real stateNo 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.

Talk to an Advisor →

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.