How to Use Claude Code for GRC and Compliance Automation

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.

Frequently Asked Questions