GraphGRC v2: SOC 2 Compliance in GitHub
You need SOC 2 for your first enterprise deal. The sales team says you need it yesterday. You look at Vanta or Drata - $12,000 per year minimum, probably more. They’ll give you pre-written policies and a nice dashboard. They’ll also lock all your compliance documentation in their proprietary platform, where it lives as long as you keep paying.
The alternative is Google Docs or Confluence. You copy policies from the internet, paste them into a folder somewhere, and hope your auditor accepts them. There’s no structure, no validation, no way to ensure your documentation stays current. When someone asks “what’s our incident response process?” you send them a link to a doc that was last updated 18 months ago.
Your compliance documentation should live in version control, not a SaaS platform you're renting.
GRC as code
GraphGRC is compliance documentation in GitHub. Fork the repo and you get pre-written controls, policies, processes, and standards. Everything’s in Markdown with semantic linking between documents. GitHub Actions validate your docs and generate a static compliance site. Free and open source.
This isn’t a full GRC platform - there’s no vendor management module, no training attestation tracker, no fancy dashboard. It’s the foundational documentation you need to pass SOC 2, structured in a way that actually makes sense and validates itself automatically.
How it works
The documentation model has four layers that map to each other:
Controls map SOC 2 requirements to your actual documentation. Each control references the policies, processes, and standards that satisfy it. These are the things your auditor cares about.
Standards describe technical requirements. AWS security baseline. GitHub security configuration. Laptop security standards. These are the concrete security configurations you need to maintain.
Processes are step-by-step procedures. Incident response runbook. Access review process. Onboarding and offboarding workflows. These tell people what to do.
Policies set objectives for different roles. What the security team expects from engineers, from support, from finance. Not generic boilerplate about password complexity - specific guidance about handling customer data, using AI tools, managing secrets.
Everything links together via heading-level anchors. A control references specific sections of policies and processes. A process references relevant standards. Change a policy and the validation checks ensure the control mappings stay accurate. Update a process and automated reviews flag when it needs attention.
The validation runs in GitHub Actions. It checks that every control maps to documentation that exists. It verifies review dates are current and owners are assigned. It ensures your processes reference standards that are actually maintained. When you open a pull request to update documentation, the checks tell you if you broke anything.
Who this is for
This works if you’re preparing for SOC 2 and don’t want to pay for Vanta. It works if your security team values owning your compliance documentation and wants it in version control. It works if your team is comfortable with Git and Markdown workflows.
It doesn’t work if you need extensive hand-holding or want a full-featured GRC platform with vendor questionnaires and training modules. It requires some technical comfort - you need to be able to fork a repo, edit Markdown files, and run GitHub Actions.
The documentation is still being validated. I’ve used this model at multiple companies, but GraphGRC v2 as an open source project is new. Feedback is welcome. If you find gaps or things that don’t make sense, open an issue.
Try it
Check it out on GitHub: github.com/engseclabs/graphgrc
Fork it, customize it for your company, let me know what’s missing. Open to contributions and feedback. If you have questions or want to talk through whether this makes sense for your situation, reach out on LinkedIn or Mastodon.
Your compliance documentation should be yours. This is a start.