The 14 Domains of a Well-Run Security Program

The direct answer: a well-run security program covers fourteen domains: governance and policy, risk management, compliance and audit, asset and system inventory, identity and access, vulnerability and patch, detection and monitoring, incident response, resilience and recovery, third-party risk, data protection and privacy, awareness and workforce, insurance and defensibility, and AI governance. But the list is the easy part. What separates a program that is actually managed from one that just looks busy is that every domain carries three things: a cadence it runs on, an artifact that proves it ran, and a named failure mode someone is honestly watching for. Not a framework. Not a certification. A running program.

This is the operating model I walked through in our recent town hall, A CISO in the Room, and it comes from years of inheriting programs in every state of repair. The pattern that repeats is not a missing tool or a missing framework. It is domains that exist on paper with no heartbeat underneath.

Programs rarely fail at the audit. They fail on a random Tuesday.

There are two ways a security program fails, and only one of them shows up in an audit report. The first is the program that fails the exam: findings, gaps, a rough quarter. Visible, embarrassing, and survivable. The second is the program with clean binders that has never actually restored an application from backup, and has never called the third phone number on its escalation list to discover it belongs to someone who left two years ago. Audits sample what is written down. Tuesdays test what actually runs.

The mechanism behind the second failure is simple: the work that decays first is the work with nobody external waiting on it. Evidence gets assembled because fieldwork is scheduled. The restore test slips forever, because no auditor is standing next to the backup console. Which is exactly why every domain needs a cadence, and why a calendar full of meetings is not the same thing as a program.

The fourteen domains

Here is the full set, with the cadence each one runs on, the dated artifact that proves it, and the way each one quietly fails. The failure modes are not hypotheticals; every one of them is something we have found inside a real environment.

Domain	Cadence	Proof artifact	Fails as
Governance & policy	Quarterly	Approved policy set, with approval dates	Policies approved once, never re-approved
Risk management	Monthly	Current risk register with owners; accepted risks signed, with expiry dates	A register nobody has re-scored in a year
Compliance & audit	Continuous	Evidence current as of today, not assembled for fieldwork	Evidence assembled in the two weeks before the audit
Asset & system inventory	Weekly	System and application inventory; device coverage report	A spreadsheet that predates two migrations
Identity & access	Quarterly	Last quarter's access review sign-off	Access reviews signed without being read
Vulnerability & patch	Weekly	Vulnerability report with closure rate	Scanning without a closure rate
Detection & monitoring	Continuous	Coverage map of what is and is not watched	Coverage gaps nobody has mapped
Incident response	Event-driven	IR plan, last revised date; last tabletop with findings	A plan with stale phone numbers
Resilience & recovery	Quarterly	Restore test result against stated RTO; BIA with RTO and RPO	Backups held, recovery never proven
Third-party risk	Monthly	Vendor list, tiered, with assessment dates	An annual questionnaire and nothing between
Data protection & privacy	Quarterly	Data classification and retention record	Classification on paper only
Awareness & workforce	Annual, measured	Awareness completion and phishing results	Completion tracked, behavior unmeasured
Insurance & defensibility	Annual	Cyber policy with current representations	Representations that no longer hold
AI governance	Quarterly	AI system registry with owners; change approvals	Use unlogged, ownership unassigned

Two things to notice. First, AI governance is on the list as a first-class domain, not an appendix; if your program treats AI use as somebody else's problem, its failure mode, use unlogged and ownership unassigned, is already happening. Second, every proof artifact is a record with a date. No opinion involved. That is the standard worth holding a program to, because it is the standard an incident, a customer, or a carrier will hold it to.

The heartbeat: five clocks, not one

A program runs on five cadences at once. Weekly: the vulnerability queue and its closure rate, new assets and unmanaged devices, open incidents and near misses. Monthly: the risk register re-score, vendor monitoring review, control exceptions and expiries, the metrics pack. Quarterly: access reviews and sign-offs, a recovery test or tabletop, the policy re-approval cycle, the board readout. Annual: the maturity assessment refresh, the penetration test, insurance renewal and its representations, a full program plan reset.

And then the fifth clock, the column most programs forget entirely: event-driven. An incident, yours or a peer's. A vendor breach or downgrade. A new regulatory obligation. An acquisition or major change. A program that only runs on the calendar treats these as interruptions; a managed program treats them as triggers with a defined response. A calendar is not a program. The event-driven column is where that difference shows.

How to use this table this week

Run the test on your own program, domain by domain, and be honest on three questions. When did this domain last actually run, not when was it scheduled? What is the most recent dated artifact it produced, and could you put your hands on it in five minutes? And does the failure mode in the last column describe you? Nobody scores fourteen for fourteen. The point is not a perfect score; it is knowing which domains have a heartbeat and which have a binder.

In our experience the domains that fail this test first are the ones with no external forcing function: resilience testing, register re-scoring, policy re-approval, and, increasingly, AI governance. The compliance-facing domains stay fresher, because someone outside the building is waiting on them. That asymmetry is the whole argument for cadence: it manufactures the forcing function the quiet domains never get. It is also, frankly, the reason our model pairs a named advisor who runs the cadence with a platform where the program state lives: the advisor is the external party waiting on the work, and the platform is where every artifact sits, dated, when someone asks.

Frameworks still matter; this is not a replacement for NIST CSF 2.0 or ISO 27001, and a real program anchors to the law that governs it and organizes against a control framework. But frameworks describe what good looks like. The fourteen domains, with their cadences and artifacts and failure modes, describe whether it is actually running. As we put it in the conversation on building a program in 2026: the board does not want bits, bytes, and wires. It wants confidence that someone has already walked the path. The table above is what having walked it looks like.

Watch the full walkthrough

This framework is one part of the town hall session, which also covers the eighteen artifacts a program should be able to produce on demand and a live tour of how the model runs in Glance. The recording and the deck are available on the event page. If you want to see your own program held to this standard, talk to a Z Cyber advisor.