REF-008 // Insights

Insights

Writing on GRC automation, cloud-native security, and building programs that actually work.

  • How to argue with your auditor (and win)

    An auditor walks into an environment they have never seen, carrying a checklist written to apply to every environment they might ever see. They cannot be an expert in your specific stack, your specific history, your specific tradeoffs, and nobody could be, across the range of environments one auditor’s career actually spans. What they know is the framework. What they can assess is whatever you put in front of them.

    That is not a knock on auditors. It is the actual shape of the job: pass judgment on a system you cannot fully inspect, using expertise that cannot cover every technology it might contain, informed only by what the audited entity chooses to disclose. The framework was written to generalize across organizations that don’t resemble each other. The person applying it has the same problem, one audit at a time.

    It cuts both ways. Generic, templated evidence passes because it is legible, whether or not it reflects reality, the same failure this series has already argued against. And a genuine deviation from the letter of a control gets more traction than most practitioners expect, for the same underlying reason: you are not fighting the auditor’s judgment. You are supplying the judgment their position cannot generate on its own.

    You cannot apply the letter of the law, because the letter of the law does not apply everywhere. It does not apply everywhere because no framework, and no examiner, can anticipate every environment in advance. The job is closing that gap yourself, in writing, before anyone has to ask.

  • The intent of the control

    Password rotation still shows up in security frameworks: change your password every 90 days. Most organizations still enforce it, because the control is named and named controls get implemented literally.

    Here is what actually happens when you enforce it. A password that was Summer2024! becomes Summer2024!! at the next forced change, then Summer2024!!! at the one after that. The user isn’t being lazy. They’re solving the problem they were handed: produce something the system will accept, that they can still remember, on a deadline they didn’t choose. The incrementing pattern is a rational response to an irrational requirement.

    The control ran. It’s in the audit log. It did not make credential compromise less likely. A predictable, incrementing password is easier to guess than a strong one a person would have chosen and kept, if the policy had let them.

  • AI governance is just governance

    A new market has formed around AI governance. Standards bodies are convening. Tooling categories are being invented. Consulting practices are positioning themselves as specialists in what agents require that other software did not. The implicit claim across all of it: deploying AI agents introduces governance requirements that didn’t exist before.

    It doesn’t.

    The organization that deployed an agent and discovered it had no audit trail, overly broad permissions, and no defined blast radius did not discover new problems. It discovered old ones, running at a new speed. Those problems existed before the agent arrived. The agent is why they surfaced.

  • Endpoint security is mostly a waste of money

    The EDR/XDR market is worth north of $15B and growing. It is the default answer to “what security tools do you have?” at board level, and the largest line item in most security budgets. The implicit assumption underneath that spend: the endpoint is where you defend.

    That assumption is worth examining.

  • Policy as code, in practice

    Article #4 argued that structural friction beats prohibition. Policy documents don’t run at deploy time. The environment itself has to enforce the right path. That argument is a case for a way of thinking. This piece is the answer to the next question: what does it actually look like to build an environment with an opinion?

    Three failure modes from that article. Three mechanisms that address them. Not a product survey. An explanation of how the philosophy gets built.

  • Everything as code: the complete picture

    Most security programs are accurate descriptions of a program nobody built. The policies are right. The controls are mapped. The SOC 2 is clean. The environment does something else.

  • The automation imperative

    A control that requires a human to initiate, remember, and execute correctly is not the same thing as a control that runs. The gap between those two things is where most security programs quietly live, and where most incidents that aren’t attacks begin.

  • Make the wrong thing hard

    Most security policies fail not because people ignore them, but because the environment never enforced them. If anyone can deploy anything, configure anything, pull in anything, you cannot know what you own, you cannot assess what threatens it, and you cannot measure whether your controls are working. Governance requires a stable environment. A stable environment requires constraints that the environment itself enforces.

  • Your risk register is lying to you

    Most risk registers are audit artifacts — built to satisfy an examiner, formatted to pass a review, and forgotten the moment the auditor leaves. The deeper problem is that even when the intent is genuine, the methodology most organizations use structurally cannot produce useful output. High, medium, and low are not risk management. They are the appearance of it.

  • Threat modeling isn't a security thing, it's an engineering thing

    Governance tells you what you own and who’s responsible. Threat modeling tells you what threatens it. Done right, it drives resource allocation, shapes controls, and hands a usable input to risk assessment. Done as an audit exercise, it produces documentation nobody uses.

  • Governance first, or nothing works

    A security program is a control structure. Before it is a set of tools, a team, or a framework checklist — it is a structure that determines who owns what, who decides what, and what gets measured. Get it right and the rest of the program has somewhere to stand. Get it wrong and you are stacking capabilities on nothing.

  • Your policies should be on Git

    Treating policy documents like code isn’t just a clever idea — it solves real problems that SharePoint, Confluence, and annual review cycles never will.

  • Why OSCAL changes everything about compliance automation

    Most compliance programs fail not because of bad intent but because the tooling is fundamentally mismatched to the problem. OSCAL is the first serious attempt to fix that at the format level.