You can have your cake and eat it too with the right GRC platform

When I think of traditional GRC tools that require me to stare at Microsoft Excel and input control documentation and screenshots manually, I literally break out into hives. Maybe it's my ADHD, and maybe I'm also being dramatic, but I really do not think that we as GRC professionals have to accept the idea that these processes can't be automated (nor can we with changes like FedRamp 20x).

What if those of use who wanted to opt for the flexibility of Excel could keep that flexibility AND still have the benifits of automation. That's the beauty of programmatic evidence automation.

It's all JSON, so just dump that 🎂 baby

I was first introduced to OSCAL by a friend from CISO Global's Talatek. The Open Security Controls Assessment Language is a really exciting concept to me for a lot of reasons including the hype around FedRamp 20x, machine readable assessments, and GRC automation as a whole, but let's focus on that last part.

You don't need OSCAL to automate your compliance documentation. In fact I can't think of a reason you wouldn't be automating your documentation into a JSON structure and inserting it into Excel even without OSCAL in 2025. It would take me at most a day to do that for most systems whereas manually it could take months.

It's all JSON, and at this point all of our controls are queryable if you know what you're doing, so the idea that we should manually document every spreadsheet one row at a time seems insane to me.

The automation gap in modern GRC

If you’ve ever worked inside a “big name” GRC platform, you’ve probably felt the same tension: these systems promise structure, but they often bury flexibility under configuration debt. Before long, you’re managing workflows about managing workflows.

Meanwhile, those of us who still live in spreadsheets do it because we can move fast — we can pivot, tweak, and model our controls the way we think. But the cost is massive manual upkeep. Every evidence change means another screenshot, another control update, another late night in SharePoint hell.

That’s the gap modern evidence automation fills. Instead of choosing between rigidity and chaos, you build your GRC data flow around your actual systems — the cloud accounts, IaC, source code, and monitoring tools that already know what’s true. Once that’s in place, Excel isn’t your source of truth anymore — it’s just a friendly window into your JSON lake.

From static documentation to dynamic evidence

The real shift happening in 2025 isn’t about yet another GRC platform — it’s about treating compliance like an API.

Your infrastructure, repositories, and cloud accounts already generate continuous signals: IAM policies, encryption settings, container manifests, Terraform states. Those are living documents — machine-readable evidence that updates itself.

If you can extract and normalize that data (say, to OSCAL, CycloneDX, or even a simple JSON schema), you can regenerate reports, SSPs, and ConMon packages on demand. That’s not just automation — that’s living compliance.

And the best part? You can still keep your familiar tools. If your team loves Excel, fine — export your evidence table directly from your API or evidence lake into a spreadsheet view. You get all the flexibility of manual tooling, with none of the manual labor.

Send clerical work to the guillotine

The idea isn’t to replace GRC professionals. It’s to free them from clerical work so they can focus on interpretation, validation, and risk strategy — the human parts that actually matter.

Evidence automation lets you:

• Keep the flexibility of custom tables, formulas, and risk matrices.
• Maintain up-to-date control mappings automatically.
• Export or integrate data into any format (OSCAL, JSON, YAML).
• Spend more time interpreting risk, less time chasing screenshots.

If you’re still managing compliance like it’s 2015, you’re leaving efficiency — and sanity — on the table. The GRC future isn’t rigid or chaotic. It’s programmable.

TL;DR: You can have your cake and eat it too — if your evidence pipeline speaks JSON.