REF-008 // Insights

Insights

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

  • 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.