Document the program, or run it.

I have spent twenty years opening GRC tools and using a fraction of what was inside them. I have signed renewals for several of them and watched skilled teams produce real value with them. The reason was always the same. They were built for the audit. I was trying to run a program.

GRC tools document the program. That is their job, and they do it well. They were built around the audit cycle: the assessor's question, the evidence artifact, the control library, the framework map. If your unit of work is “respond to the auditor,” the GRC tool is the right home for it.

If your unit of work is “move the program forward this quarter,” it is not.

What a GRC tool is actually for

The center of a GRC tool is the control. Around it, the tool organizes evidence, attestations, exceptions, audit responses, framework mappings, and reporting built to satisfy an external assessor. The model assumes a cycle: the auditor asks, the program answers, the tool holds the proof. That is a real cycle and it produces real value. Compliance does not happen without it.

The model also has a center of gravity. The audit is the gravity. Everything in the tool bends toward the next assessment. A GRC tool is at its best the week before SOC 2 fieldwork starts and at its weakest the day after it ends, when the program is supposed to go back to running.

What running a program actually involves

The center of a security program is not the control. It is the roadmap. The roadmap moves with budget, with hiring, with what shipped this sprint, with what just got breached at the company down the street, with what the board asked about last meeting, with what the regulator just published.

Around the roadmap sits a different set of objects. The strategic initiative that ran over because it was harder than scoping suggested. The finding from last quarter's red team still owned by an engineering manager who has changed teams twice since. The board deck that is a quarter out of date the day it is delivered. The AI vendor your CISO peer at the conference just got breached on. The CIO sitting next to you who needs to know whether to put a hold on the SaaS contract.

None of those are control-shaped. None of them sit comfortably inside an evidence artifact. A GRC tool can hold a record that they happened. It cannot run them.

What this looks like in practice

I have run the programs a GRC tool is supposed to be the home of, and what held them together was not the tool. It was a side spreadsheet. A Jira board the security team kept in private. A slide deck I rebuilt from scratch every six weeks because the data lived in no single system. A senior security leader who carried the whole program in her head because no tool could hold it.

That is the tell. If your team runs the program out of a side artifact, the GRC tool is downstream of the program, not the home of it. The work is real. The system of record is somewhere else.

Three places this pattern shows up, that I have learned to look for.

The audit-response sprint

SOC 2 Type 2 fieldwork starts. Roadmap work freezes for six weeks. The team's calendar is consumed by evidence pulls. The program returns to motion in late November, having missed Q4 board prep. This is a feature of the tool's design, not a defect. It optimizes for what is happening during fieldwork. Everything else waits.

The quarterly board scramble

The board deck is due Monday. What the board wants is roadmap status, finding closure rate, budget variance, top vendor risks, and what changed since last meeting. None of it lives in one place. It is reassembled by hand from four systems and a memory. The deck is competent. Reassembling it every quarter is reporting on the program, not running it.

The roadmap that lives in someone else's tool

The security roadmap is in Notion, or Coda, or a PowerPoint deck, or a Confluence page, or someone's laptop. It is not in the GRC tool, because the GRC tool cannot represent a strategic initiative. It can hold the controls that initiative will eventually populate. It cannot show you the initiative itself.

The fork

You can pick the tool category by the question you are trying to answer.

If the question is “show the auditor the evidence,” a GRC tool is the right home. If the question is “where does the program go from here, who is doing what, what is in flight, what is overdue, what is the next conversation with the committee,” a GRC tool is the wrong home. It can route a finding to closure. It cannot tell you where the program goes next.

Most security leaders are trying to do both. So are the vCISOs and fractional CIOs running programs at several companies at once, and the PE operators running portfolios. They bought a GRC tool because the audit was on fire, and now they are trying to run the program out of it because they already paid for it. The result is a tool that does its first job well and quietly resists the second.

Document or run

Document the program, or run it. The tools you choose reflect which one you are actually trying to do. A program that is only documented can look fine for a long time. The cost shows up later, in a quarter when the auditor was satisfied and the business asked a question the documentation could not answer.

I have wanted a tool like Command for years, as a practicing CISO. It came from running programs, not documenting them. I will say more about what it looks like in its own time. The reason it exists is that running and documenting are different jobs, and most of the industry has been pretending they are the same one.

---

If you want the worksheet I use to test whether a security program is being run or only documented, reach out. We will send it.