Search for compliance automation tools and you get a list of platforms that do one job: connect to your stack, gather evidence that your controls are operating, and get you ready for a SOC 2 or ISO 27001 audit. That layer is real and useful. But for an engineering team there is a second layer these lists usually skip: the pull request, where a control is actually moved, one change at a time, months before an audit samples it.
This is a neutral map of both layers. Each tool is described by its own plainly-stated purpose, not ranked or knocked. The point is not which one wins; it is that the two layers answer different questions, and most teams end up wanting one of each.
The compliance program platforms
These are the tools most people mean by compliance automation. They connect to your cloud, identity provider, and other systems, automate the collection of evidence that controls are operating, monitor that evidence continuously, and help you prepare for an audit against frameworks like SOC 2, ISO 27001, and the GDPR. They operate at the level of your compliance program: policies, controls, evidence, and audit readiness for the whole organization.
Vanta, Drata, and Scytale are widely used SaaS platforms in this space, each automating evidence collection and continuous monitoring for common frameworks. Probo is an open-source, self-hostable option that covers the same GRC lifecycle (controls, risk, vendors, evidence) and exposes CLI, GraphQL, and MCP APIs so the work can be driven from code or an agent. ControlMap, part of ScalePad, automates evidence collection across a broad framework library spanning common security and privacy standards.
If your goal is to stand up a compliance program and get audit-ready, this is the category to evaluate. Which one fits depends on your frameworks, your stack, and whether you want SaaS or self-hosted, and that choice is yours to make against each vendor's own documentation.
The pull-request layer
Program platforms maintain evidence, controls, and audit readiness across your systems. Engineering teams also have a second place where compliance is decided: the pull request, where a change can widen an access path, trim an audit log, or add a new store of personal data. Those are control-relevant design decisions, and a pull request is the place they can be discussed before they merge.
heygrc is that pull-request layer. It reviews each change against the frameworks your company selected and cites the specific control it touches, at the diff, as a review comment plus a neutral Checks status. It is not a program platform: it does not collect your evidence or manage your audit. It adds a framework-aware reading of a change in GitHub, before it merges.
So the two layers compose rather than compete. The program platform manages evidence and audit readiness; heygrc adds framework-aware review context in GitHub before changes merge. An engineering team pursuing a certification often wants both: one to run the program, and one for the compliance reading at the pull request.