Don't Let Your GRC Tool Choose Your Control Set For You

Here's a pattern that shows up constantly with growth-stage companies starting their first SOC 2 or HIPAA compliance effort: they sign up for a GRC platform first, click through the onboarding wizard, get handed a templated control set matched to their industry and framework, and start working through it as if it were custom-built for them. Eighteen months later, they're paying a five-figure annual subscription, half the controls in the platform don't actually reflect how their environment works, and nobody on the team can say with confidence whether the control set is the right one — only that it's the one the tool gave them.

This isn't a knock on GRC platforms. Drata, Vanta, Thoropass, and similar tools solve a real problem — evidence collection at scale is genuinely painful to do manually, and automating it is valuable. The problem is sequencing: buying the automation before you know what you're automating.

The Templated Control Set Problem

GRC platforms need to onboard companies quickly, so the control sets they provide out of the box are built for the median company in a given industry and framework — reasonable defaults, not an assessment of your specific environment. That's a sensible product decision for the vendor. It's a less sensible starting point for you.

In practice, this shows up a few ways:

Controls that don't match your actual architecture. A templated control set built for a typical SaaS company doesn't account for the fact that you might run a hybrid cloud environment, use a specific set of subprocessors, or have an unusual data flow that changes what actually needs to be controlled and evidenced.

Controls that are missing entirely. If your risk profile includes something the template didn't anticipate — a particular type of PHI handling, a payments flow relevant to SOC 1, a vendor relationship with unusual access — the templated set simply won't include it, and nobody flags the gap until an auditor does, later, at a worse time.

Controls that are overbuilt for you. The reverse problem is just as costly — implementing and maintaining evidence for controls that don't meaningfully reduce your actual risk, because they were included for a company with a different footprint than yours.

None of this is really the platform's fault. It's what happens when a control set gets adopted rather than built.

What a Readiness Assessment Actually Buys You

A readiness assessment done by a qualified assessor, before you touch a GRC platform, produces something different: a control set built from an actual evaluation of your environment, your data flows, your architecture, and your risk profile — not a template matched to your SIC code.

The commercial structure is different too, and this matters more than it might seem at first. A readiness assessment is typically a one-time engagement fee. A GRC platform is a recurring subscription, commonly $10K+ annually once you're past the smallest pricing tier, for as long as you use it. That's not an argument against ever paying for automation — it's a reason to make sure what you're automating is right before you start paying to automate it indefinitely.

Once you have a custom control set built around your actual environment, you're in a meaningfully different position than the templated-first path:

• You know precisely what needs to be evidenced and why, rather than trusting that a template covers you.
• If you decide to bring in a GRC platform for evidence automation afterward, you can import your own control set rather than starting from — and potentially never fully correcting — the vendor's default.
• If you decide a platform isn't worth the recurring cost for your stage or scale, you still have a real, audit-ready control set, and can manage evidence collection manually or semi-manually without having paid for tooling you didn't strictly need yet.

The sequencing point is the whole argument: assessment first, automation decision second — not the other way around.

Where Automation Genuinely Fits

To be clear, this isn't an argument that GRC platforms are unnecessary. For companies at real scale — multiple frameworks, ongoing Type II evidence collection, sizable engineering and IT footprints — continuous automated evidence collection solves a problem that becomes genuinely painful to handle manually. The point isn't "skip the tool." It's "don't let the tool hand you your control set as a side effect of buying it."

Once you have a control set that's actually yours, bringing in a GRC platform to automate evidence collection against that control set is a reasonable and often good decision. You're just making it deliberately, with the right control set already defined, instead of inheriting one by default.

A Note on DIY Continuous Compliance

There's a newer option worth mentioning honestly, with real caveats attached: with the current generation of agentic AI tools and MCP-based integrations, technically sophisticated teams can build their own lightweight continuous evidence collection pipelines — pulling configuration state, access logs, and policy attestations on a schedule without paying for a full commercial GRC platform.

This is a genuinely interesting option for the right team, and it can reduce recurring cost meaningfully. But it comes with real tradeoffs that are easy to underweight when you're excited about the technical approach:

• Evidence integrity and chain of custody matter to auditors. A homegrown pipeline needs the same rigor around access control, immutability, and audit trail that a commercial platform has already built and hardened. A sloppy DIY evidence pipeline can itself become an audit finding.
• Maintenance is now your problem. Commercial platforms absorb the burden of keeping integrations current as APIs change. A self-built pipeline puts that maintenance burden on your team indefinitely.
• This is not a shortcut around the assessment. An agentic evidence pipeline still needs a real control set to collect evidence against — it doesn't replace the readiness assessment, it's a possible answer to the automation question that comes after.

For teams with the engineering capacity to build and maintain this well, it's a legitimate path. For most companies, a commercial platform's maturity around evidence handling is worth the subscription cost — the point of this post isn't to talk anyone out of that. It's to make sure the control set underneath whichever automation choice you make is actually yours.

The Actual Recommendation

Get your control set right first, through an actual assessment of your environment — not a template. Then decide, deliberately, whether commercial automation, a self-built pipeline, or manual evidence collection is the right fit for your stage and team. All three are reasonable answers to the automation question. None of them are a substitute for knowing what you're actually supposed to be controlling in the first place. If you're not sure which stage you're at or whether your current control set is actually built for your environment, that's usually a thirty minute conversation — not a commitment.