About

Most of my career has been spent on the assurance side of the table: planning IT general controls testing, sampling change tickets, tracing access reviews, and writing up what went wrong months after it went wrong. That work taught me something specific about how controls fail. They rarely fail because someone made a bad decision. They fail because the compliant configuration was never the default, and nobody noticed until the sample landed on it.

Why GRC engineering

Point-in-time testing tells you what was true on the day you looked. That was a reasonable trade when infrastructure changed quarterly. It is a poor trade when it changes hourly. If a control matters, it should be enforced continuously and automatically - and the evidence should be a byproduct of the system operating, not a folder of screenshots assembled under deadline.

That is the shift I am making: from describing controls to implementing them. Writing Terraform where the compliant configuration is the only configuration. Writing Open Policy Agent rules that reject a non-compliant change before it deploys. Building pipelines that produce audit evidence as a build artifact.

What the audit background is worth

Knowing NIST 800-53 or SOX ITGC well enough to test it means knowing what a control is actually trying to prevent - which is exactly what you need to encode it correctly. A policy that technically passes but misses the control intent is worse than no policy, because it manufactures false confidence. Having written the findings, I know what that gap looks like.

I also know how to write for the two audiences that have to agree: the engineer who has to implement the control and the stakeholder who has to accept the risk.

Currently

Working through hands-on GRC engineering projects - infrastructure as code, policy as code, and automated evidence collection - and writing up what I learn. The projects page has the detail, and the code is on GitHub.