Check out the pics from our ISACA GRC Conference events
Compliance Automation

How to Use Claude Code for GRC and Compliance Automation

Updated

Most compliance teams still rebuild the same pipeline by hand every audit cycle: pull evidence, map it to a framework, find the gaps, write it up. This guide shows how to use Claude Code so that pipeline runs as a few commands instead of a few weeks of spreadsheet work.

Key Takeaways

  • Claude Code for GRC works because compliance is evidence collection, control mapping, and reporting, all tasks an agent with the right tools can run end to end.
  • The open-source claude-grc-engineering toolkit ships as Claude Code plugins: a pipeline hub, persona plugins, 20-plus framework references, and thin cloud connectors.
  • You can run a first gap assessment with only a GitHub account, no cloud credentials required.
  • Every connector emits findings in one shared contract, so AWS, GitHub, GCP, and Okta data all crosswalk the same way.
  • This is a place to learn the engineering layer of GRC in public. It is not a replacement for your GRC platform, and it is designed so any team can plug their stack in.

We will use the open-source claude-grc-engineering toolkit, built by the GRC Engineering Club, and you will run a real gap assessment by the end.

Claude Code is Anthropic's command-line coding agent. It reads your environment, runs tools, and writes files. GRC, Governance Risk and Compliance, is mostly evidence, control mapping, and reporting work. Those two things fit together well, and the toolkit is what connects them.

What can Claude Code actually do for GRC?

Claude Code can run the parts of a compliance program that are mechanical but time-consuming. With the toolkit installed, it can:

  • Collect configuration evidence from AWS, GitHub, GCP, and Okta.
  • Crosswalk a finding to every framework it touches at once.
  • Generate a prioritized, effort-estimated gap report.
  • Scan Terraform, CloudFormation, or Kubernetes for control violations.
  • Draft remediation as Terraform modules, Python evidence scripts, or policy as code.

What it does not do is replace your judgment, your auditor, or your platform. It removes the repetitive plumbing so you spend your time on the decisions that actually need a human. If you are new to the discipline, start with GRC Engineering 101 for the foundation, then come back here for the tooling.

How the claude-grc-engineering toolkit is built

The toolkit is a set of Claude Code plugins, each with a clear job. Understanding the categories makes the commands obvious.

The engineering hub

The grc-engineer plugin is where the pipeline lives. It holds the commands you run most: gap-assessment, scan-iac, test-control, generate-implementation, map-controls-unified, and monitor-continuous. If you only learn one plugin, learn this one.

Persona plugins

The toolkit ships role-shaped plugins so the commands match how you actually work:

  • grc-auditor for evidence review, workpaper generation, and control validation.
  • grc-internal for risk registers, policy lifecycle, and certification portfolio tracking.
  • grc-reporter for exec summaries, board briefs, and automation return-on-investment reporting.
  • grc-tprm for third-party risk and vendor questionnaire analysis.

Auditors moving into this work have a dedicated path through the CGE-AUD Auditor Specialty, which teaches the same literacy these plugins assume.

Framework plugins

There are 20-plus framework reference plugins, from SOC 2 to NIST 800-53 Rev 5 to ISO/IEC 27001:2022 to FedRAMP to PCI DSS v4.0.1 to CMMC 2.0. They reference control identifiers and ship paraphrased implementation guidance. They do not reproduce copyrighted standard text, so your licensed copy of the standard stays the source of truth.

Connectors

Connectors are thin wrappers around tools you already have: the aws CLI, gcloud, the gh CLI, and the Okta REST API. Each one is a few hundred lines and can be swapped without touching the rest of the toolkit. That design is deliberate, and it is what lets the community keep adding to it.

How to run your first compliance check

Here is the fastest path to a real result. You run these inside Claude Code.

Install the marketplace and the engineering hub:

/plugin marketplace add GRCEngClub/claude-grc-engineering
/plugin install grc-engineer@grc-engineering-suite

For a first run with no cloud credentials, use a GitHub account as the data source:

/plugin install github-inspector@grc-engineering-suite
/plugin install soc2@grc-engineering-suite
/github-inspector:setup
/github-inspector:collect --scope=@me
/grc-engineer:gap-assessment SOC2 --sources=github-inspector

That last command returns a prioritized, remediation-linked SOC 2 gap report against your GitHub configuration. No spreadsheet, no manual control mapping. When you are ready for cloud evidence, add a connector and run again:

/aws-inspector:collect --profile=default --region=us-east-1
/grc-engineer:gap-assessment SOC2,FedRAMP-Moderate --sources=github-inspector,aws-inspector

The cached findings are reused, so adding a second framework only re-runs the crosswalk, not the collection.

Is it safe to use AI for compliance work?

This is the first question every GRC leader should ask, and the toolkit is built around the answer.

Three design choices matter here. First, connectors shell out to tools you already trust and already audit, so there is no opaque black box pulling your data. Second, framework plugins paraphrase rather than reproduce standard text, so you are never relying on the model's memory of a control as the source of truth. Third, the output is a structured finding you can read, diff, and review, not a paragraph of prose you have to take on faith.

You still own the review. Treat AI-generated remediation the way you treat a junior engineer's pull request: useful, fast, and subject to your sign-off before it ships. For the deeper distinction between this way of working and traditional compliance, read GRC vs Traditional GRC.

Where this fits in a real program

Claude Code for GRC is strongest at the edges of the audit cycle that usually eat the most time. Continuous evidence collection so the audit is a byproduct of normal operations. Multi-framework crosswalks so one control satisfies many requirements. Infrastructure as code scanning so violations get caught before merge, not in a Q4 fire drill.

It is weakest, by design, at the things that need accountability: risk acceptance, scoping decisions, and the auditor relationship. Keep those human. Automate the plumbing around them.

If your whole team needs this skill, the GRC Engineering Club team membership is built for that: hands-on labs, the toolkit, and a community of practitioners building in public.

How should GRC teams govern AI coding agents?

Related podcast episode. The toolkit above puts an AI agent to work on compliance tasks. This conversation covers how to govern agents like it and keep auditors on board.

Jon Zeolla has spent nearly 20 years in InfoSec and quality engineering, teaches for SANS and IANS, and founded a startup building quality harnesses for coding agents. He joined AJ Yawn and Omar Sangurima on The AntiCheckbox Podcast. Episode: The Forward Deployed Engineer, Agentic Voting, & Treating GRC Like a Product | Guest: Jon Zeolla.

Key points from the episode

  • Agents doing the work see more context than a generic requirement written by a central team. Jon built a way for coding agents to vote on policies and leave feedback without changing them, so the vote data informs the humans who decide how the program changes.
  • Roll out a new guardrail in audit-only mode first. He ends a new pipeline check with || true so it reports without failing the build, a lesson from a check that broke an important pipeline at a company running about 3,000 of them.
  • Skip ROI-first quick wins. Take the simplest task 100% of the way through, including the retro, because finishing it teaches you something that changes your approach.
  • Treat auditors as users. When an auditor rejects your automation, run a retro: ship fewer new features at once, preview it with them beforehand, or trial it in internal audit first.
  • Auditors will keep wanting the base data underneath AI-based reviews, and he expects a long wait before they accept a human fully out of the loop.

Frequently Asked Questions

Can Claude do compliance work?

Claude Code can run the mechanical parts of a compliance program, collecting evidence, mapping controls across frameworks, and drafting remediation, when paired with the open-source claude-grc-engineering toolkit. It does not replace human judgment on risk acceptance, scoping, or the auditor relationship.

Do I need cloud credentials to start?

No. You can run your first gap assessment using only a GitHub account through the github-inspector connector, then add cloud connectors like aws-inspector later.

Which frameworks are supported?

The toolkit ships 20-plus dedicated framework plugins including SOC 2, NIST 800-53 Rev 5, ISO/IEC 27001:2022, FedRAMP, PCI DSS v4.0.1, CMMC 2.0, and HITRUST CSF, and crosswalk support for many more of the 249 frameworks in the Secure Controls Framework.

Is this a replacement for my GRC platform?

No. It is an open place to learn and ship the engineering layer of GRC in Claude Code. The shared finding contract is designed so any platform, internal team, or assessor can plug their stack in and contribute.

Keep Learning

claude-grc-engineering

The open-source toolkit and its plugins

GRC Engineering 101

The foundation, start here if you are new

GRC vs Traditional GRC

How this way of working differs

Academy

Certifications and learning paths

Next Steps

You learned what Claude Code can do for GRC, how the claude-grc-engineering toolkit is structured, and how to run a gap assessment with nothing but a GitHub account. The payoff is a compliance pipeline that runs in commands instead of weeks.

Install the toolkit and run your first gap assessmentJoin the Club