For decades, auditors and governments defined and molded Legacy GRC in their image. Today, engineers and analysts are transforming it into something new: GRC Engineering. This cheat sheet outlines what makes GRC Engineering different.
This README is the canonical content source for the live cheat sheet at cheatsheet.grc.engineering — the site fetches and renders this file at runtime, so any change merged here goes live within minutes. To contribute a tool, term, teaching, or timeline event, edit the relevant section below and open a pull request (see Contributing).
"Governance, risk, and compliance (GRC) are three related facets that aim to assure an organization reliably achieves objectives, addresses uncertainty and acts with integrity."
"Engineering is the practice of using natural science, mathematics, and the engineering design process to solve problems within technology, increase efficiency and productivity, and improve systems."
GRC Engineering is the practice of using science, math, user-centered design, and modern software development to assure an organization reliably achieves objectives, addresses uncertainty, and acts with integrity, all while continuously improving its efficiency, productivity, and systems.
A side-by-side comparison of the legacy GRC mindset and the GRC Engineering approach across the five program areas. Inside each cell, multiple bullets are separated with <br>•.
| Program | Legacy GRC | GRC Engineering |
|---|---|---|
| All | • Framework-centric approach • Shallow & narrow problem solving mindset • Cumbersome user experience (UX) across GRC processes, tools, etc. • Work products = static documents, disjointed processes, and theatrical controls • Processes are excessively, if not exclusively, manual • Trivial outputs conflated with meaningful outcomes • GRC treated as a program that serves GRC teams' needs and preferences |
• Objectives-centric, risk-focused, and threat-informed approach • Systems thinking mindset applied broadly: organizational governance, risk analysis, control modeling, etc. • Design thinking mindset harnessed to make the right thing to do the easy thing to do • Work products = dynamic systems, embedded processes, and technical controls • Processes are automated, early on and often • Measurable, meaningful outcomes (or bust!) • GRC treated as a product that serves internal and external customers' needs and preferences |
| Governance | • Mainly consists of static policies, standards, and procedures that everyone "acknowledges" but no one reads or remembers • Static governance documentation rarely reflects reality of controls • Committees exist to check boxes but rarely, if ever, drive strategic decisions that effect change • Awareness training checks boxes but is too infrequent, delayed, unengaging, and ill designed to durably change behaviors |
• Mainly consists of strong guardrails (e.g. policy-as-code) that enforce risk tolerance & paved paths that make it easy to do the right thing • Dynamic governance documentation is enforced via policy-as-code, expressed via policy-to-code, and reconciled via policy-from-code • Committees exist to define/refine decision making frameworks & to facilitate strategic decisions • Real-time behavioral interventions ensure cognitive security & awareness training methods are rooted in science-based pedagogy to drive durable behavior change |
| Risk | • Risk program is built on qualitative risk analyses that are heavily, if not entirely, based on unvalidated assumptions, uncalibrated intuition, and generic heatmap frameworks • "Risks" are control gap findings that are detached a real-world understanding of relevant threats • Numerical risk scores conflated with "risk quantification" • Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world analog • Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations • Risk team operates as "accountability police" towards other teams they have no authority over • Third-party risk management (TPRM) is really just third-party compliance management (TPCM) in disguise, focused entirely on third-party controls/mitigations |
• Risk program is built on quantitative risk analyses that are based on scientific methods, statistical modeling, real-world evidence, and proven frameworks (e.g. FAIR) • "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, and impacts • True risk quantification is in place, with quantitative inputs producing quantitative outputs • Risk tolerance/appetite is derived from real-world and measurable constraints, such as insurance limits, cash reserves, organizational goals, etc. • Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations • Risk team operates as "decision support partners" that enable their organization to make smart risk decisions • TPRM is actually managing risk, focused on holistic scenarios, quantitative risk analyses, and both first-party and third-party controls/mitigations |
| Compliance | • Periodic, isolated control monitoring • Evidence samples |
• Automated, holistic control monitoring & active testing • Evidence populations (full) |
| Trust & Assurance | • Opaque, abstracted annual artifacts • RFIs handled via email |
• Transparent, real-time, historical visibility into controls • Self-service RFIs & questionnaire completion |
A history of governance, risk, and compliance milestones — from the first federal IT security standards to the emergence of GRC Engineering as a discipline.
| Year | Date | Event | Actor | Summary | Relevance | Source |
|---|---|---|---|---|---|---|
| Jun 1974 | June 1, 1974 | FIPS 31 | Government · NIST | Federal Information Processing Standard 31 — the first US government guideline on automatic data processing physical security and risk management. | Established the foundational pattern of government-issued standards driving organizational security practice. | https://csrc.nist.gov/pubs/fips/31/final |
| 1977 | 1977 | Control Objectives | Auditor · IIA | The Institute of Internal Auditors' Systems Auditability and Control study formalized the concept of "control objectives" for IT. | Created the auditor-centric vocabulary that still dominates traditional GRC. | https://www.theiia.org/en/standards/ |
| Aug 1979 | August 1, 1979 | FIPS 65 | Government · NIST | First federal risk analysis methodology — a quantitative annualized loss expectancy (ALE) approach to IT risk. | Predecessor to all modern quantitative cyber risk methods (FAIR, ALE, Monte Carlo simulations). | https://csrc.nist.gov/pubs/fips/65/final |
| Dec 1985 | December 26, 1985 | The Orange Book | Government · DoD | DoD's Trusted Computer System Evaluation Criteria — defined assurance levels (C1, C2, B1, B2, A1) for trusted systems. | First formal criteria-based certification regime; precursor to Common Criteria and FedRAMP. | https://csrc.nist.gov/pubs/other/1985/12/26/dod-rainbow-series/final |
| Sep 1992 | September 1992 | SAS 70 & COSO | Auditor · AICPA + COSO | AICPA's Statement on Auditing Standards 70 enabled service-organization audits; COSO published its Internal Control Integrated Framework. | Introduced third-party assurance reporting — the direct ancestor of SOC 2. | https://www.coso.org/internal-control |
| Feb 1995 | February 1995 | BS 7799 | Government · BSI | British Standards Institution code of practice for information security management. | Direct ancestor of ISO 27001, the global ISMS standard. | https://en.wikipedia.org/wiki/BS_7799 |
| Aug 1996 | August 21, 1996 | HIPAA & COBIT | Government + Auditor · HHS / ISACA | US healthcare privacy and security law (HIPAA); ISACA's Control Objectives for Information and Related Technologies (COBIT) framework. | Established sector-specific compliance regulation and an IT governance framework still widely audited against. | https://www.hhs.gov/hipaa/for-professionals/index.html |
| Jul 2002 | July 30, 2002 | SOX & FISMA | Government · US Congress | Sarbanes-Oxley imposed financial reporting controls on public companies; FISMA mandated security programs across federal agencies. | Birth of the modern compliance industry — created enormous demand for control documentation and audit work. | https://www.govinfo.gov/app/details/PLAW-107publ204 |
| 2003 | 2003 | OCEG & The Red Book | Analyst · OCEG | The Open Compliance and Ethics Group was founded and published its Red Book GRC Capability Model. | Coined the umbrella term "GRC" itself. | https://www.oceg.org/about/ |
| Oct 2005 | October 14, 2005 | ISO 27001 | Government · ISO/IEC | International standard for information security management systems, evolving from BS 7799. | Became the de facto global ISMS certification. | https://www.iso.org/standard/42103.html |
| Jun 2011 | June 15, 2011 | SSAE 16 & SOC | Auditor · AICPA | AICPA replaced SAS 70 with SSAE 16, introducing SOC 1, SOC 2, and SOC 3 reports. | SOC 2 became the dominant trust signal for SaaS vendors. | https://en.wikipedia.org/wiki/SSAE_16 |
| Feb 2014 | February 12, 2014 | NIST CSF | Government · NIST | Cybersecurity Framework v1.0 — voluntary risk-based framework with Identify / Protect / Detect / Respond / Recover functions. | Most widely adopted cybersecurity framework outside of regulated sectors. | https://www.nist.gov/news-events/news/2014/02/nist-releases-cybersecurity-framework-version-10 |
| May 2018 | May 25, 2018 | GDPR | Government · EU | General Data Protection Regulation — comprehensive EU privacy law with global extraterritorial reach. | Reset the bar for privacy controls and triggered a wave of similar legislation worldwide. | https://eur-lex.europa.eu/eli/reg/2016/679/oj |
| 2021 | 2021 | Netflix hires GRC Engineers | Engineer · Netflix | Netflix posted some of the first job descriptions explicitly titled "GRC Engineer," applying engineering practices to compliance. | Marked the emergence of GRC as an engineering discipline rather than a purely auditor-driven function. | https://www.youtube.com/watch?v=Aid2P5IVjuw |
| Dec 2022 | December 14, 2022 | EU goes absolutely ham | Government · EU | NIS2, DORA, the AI Act, the Cyber Resilience Act, and more — a sustained legislative push across cybersecurity, resilience, and AI. | Multiplied compliance scope and accelerated the case for engineering-grade automation. | https://eur-lex.europa.eu/eli/dir/2022/2555/oj |
| Nov 2023 | November 24, 2023 | GRC Engineering Podcast launches | Engineer · Community | Ayoub Fandi launches the first podcast dedicated to GRC Engineering with episode S1E1 — "The Who, the Why and the What." | First sustained public conversation series for the discipline; grew the community beyond conference talks. | https://www.youtube.com/watch?v=vupO7TxBWpM |
| 2024 | 2024 | GRC Engineering Manifesto published | Engineer · Community | A community-authored manifesto codifying the principles of GRC Engineering at grc.engineering. | Crystallized the discipline's values — engineering practices, automation, design thinking — into a shared artifact. | https://grc.engineering/ |
Vocabulary that distinguishes GRC Engineering thinking from legacy GRC.
| Term | Description |
|---|---|
| Systems Thinking | Examining how components interrelate and work together over time within larger systems. Applied across governance, risk analysis, and control modeling. |
| Design Thinking | Human-centered problem-solving methodology. Harnessed to make the right thing to do the easy thing to do. |
| Threat-Informed | Grounding policies, controls, and trainings in real-world threat intelligence rather than abstract framework checklists. |
| GRC as a Product | Treating GRC programs as products serving internal and external customers, with user research, feedback loops, and measurable outcomes. |
| Policy-as-Code (PaC) | Policies written as executable code; the code is the source of truth, enabling version control, testing, and deterministic enforcement. |
| Policy-to-Code | Translating human-readable policy documents into executable code, bridging policy authors and enforcement systems. |
| Policy-from-Code | Deriving policy documentation from code, configurations, or runtime behavior. Closes the gap between docs and control reality. |
| Scientific Pedagogy | Evidence-based learning science—spaced repetition, scenario-based exercises, measurable retention—applied to security training. |
| TPCM | Third-party compliance management. Legacy questionnaire-focused approach that conflates compliance with risk. |
| TPRM | Third-party risk management. Balanced third + first-party focus, evaluating real-world threat scenarios and value-at-risk. |
| Qualitative Risk Analysis | Subjective High/Medium/Low scales based on expert judgment. Manual, inconsistent, and difficult to aggregate. |
| Quantitative Risk Analysis | Numerical models, probability distributions, and measurable data. Automated, reproducible, and comparable across scenarios. |
| Heatmaps | Legacy likelihood × impact matrices on ordinal scales. Obscure actual risk magnitude behind coarse, subjective categories. |
| Histograms | Frequency-distribution charts conveying risk shape, range, and confidence intervals in objective, data-driven terms. |
| Monte Carlo Simulations | Probabilistic simulations producing distributions and histograms instead of single-point estimates and heatmaps. |
| Risk Scenarios | Holistic descriptions combining threat + attack vector + affected asset + impact into a single analyzable unit. |
| FUD | Fear, Uncertainty, and Doubt. Legacy fear-based risk communication used to justify budget without rigorous analysis. |
| ELMR | Evidence, Logic, Math, Reason. The GRC Engineering alternative to FUD—grounded in verifiable data and sound reasoning. |
| Decision Support | Providing data, analysis, and options so stakeholders make informed risk decisions. Replaces the "accountability police" model. |
| Control Monitoring | Observing whether controls operate as intended. GRC Engineering automates this continuously and holistically. |
| Active Testing | Exercising controls to confirm they function—not just checking they exist. Analogous to software automated tests. |
| Evidence Samples | Legacy subset of records selected to demonstrate control operation. Incomplete and vulnerable to selection bias. |
| Evidence Populations | Complete control records collected automatically over a period. Eliminates sampling risk with full coverage. |
Open-source and commercial tools that enable GRC Engineering practices — policy-as-code, continuous compliance, evidence automation, quantitative risk, and compliance-as-code.
| Tool | Description |
|---|---|
| Open Policy Agent (OPA) | General-purpose policy engine for unified policy decisions across the cloud-native stack. |
| Rego | OPA's declarative policy language. Enables Policy-as-Code evaluation in CI/CD pipelines. |
| OPA Gatekeeper | Kubernetes admission controller built on OPA. Enforces Rego policies on cluster resources at admission time. |
| Kyverno | Kubernetes-native policy engine that validates, mutates, and generates resource configurations at admission time. |
| Kubewarden | CNCF Kubernetes policy engine; policies as WebAssembly modules in Rust, Go, Rego, CEL, and others. |
| HashiCorp Sentinel | Embedded policy-as-code framework for Terraform, Vault, Consul, and Nomad — gates infrastructure changes pre-apply. |
| Pulumi Policies | CrossGuard policy-as-code for Pulumi infrastructure-as-code, written in TypeScript, Python, or Go. |
| Chef | Continuous compliance via InSpec's human-readable audit DSL; Policyfiles express policy-as-code for environment configuration. |
| Puppet | Policy-as-code via Puppet manifests; continuous compliance through automated drift detection and remediation. |
| Ansible | Policy-as-code via playbooks and roles; continuous compliance through idempotent automated configuration enforcement. |
| Salt Stack | Event-driven configuration management with policy-as-code in SLS files; continuous compliance via reactor and beacon engines. |
| Checkov | Static IaC scanner (Terraform, CloudFormation, Kubernetes, ARM…); policy-as-code and continuous compliance in CI/CD. |
| Cloud Custodian | YAML-based rules engine for cloud governance, security, and continuous compliance with serverless auto-remediation. |
| ScoutSuite | Multi-cloud security auditing tool. Active testing against CIS, PCI DSS, and HIPAA benchmarks. |
| Prowler | Open-source cloud security platform. Continuous compliance across AWS, Azure, GCP, Kubernetes, M365, and more. |
| Steampipe | Cloud APIs as SQL tables. Full-state infrastructure queries for evidence populations across 100+ services. |
| CloudQuery | Infrastructure-as-data platform syncing cloud and SaaS configurations into queryable databases for evidence pipelines. |
| FAIR | Open standard decomposing risk into measurable factors (threat event frequency, vulnerability, loss magnitude). |
| riskquant | Netflix's open-source library for quantifying risk via FAIR-based Monte Carlo simulations. |
| GigaChad GRC | Open-source modular GRC platform for compliance (SOC 2, ISO 27001, HIPAA), risk registers, vendor assessments, and audits. AI-powered, containerized, self-hostable. |
| Corsair | Signs compliance findings as W3C Verifiable Credentials (Ed25519 / JWT) so any party can verify integrity without trusted intermediaries. |
| Gemara | OpenSSF seven-layer logical model for automated GRC engineering — standardised, machine-readable schemas (CUE) for compliance interoperability. |
| GRClanker | Spec-driven open-source AI GRC CLI — bring your own AI agent (Claude, Codex, Gemini…) to generate Go CLIs for FedRAMP, KEV, EPSS, SCF crosswalks. |
| myctrl.tools | Fast, searchable reference site for security compliance controls across frameworks (FedRAMP Rev5, DoD SRG, and more). |
| SCF API | API for the Secure Controls Framework (1,400+ controls mapped to 200+ laws, regulations, and frameworks). |
| Compliance Trestle | OSCAL-native compliance-as-code platform for CI/CD authoring, validation, and governance of compliance artifacts in git. |
| claude-grc-engineering | Claude Code plugin suite for evidence collection, SCF crosswalks, multi-framework gap reports, and OSCAL workflows. |
| Compliance to Policy (C2P) | Bridges OSCAL compliance-as-code with policy-as-code engines (Kyverno, OCM, Auditree); generates policies and ingests assessment results. |
| How to Harden | Community-developed open-source hardening guides focused on cloud services and integration / supply-chain attack prevention. |
| Open Source Cybersecurity Training | Free SCORM-compatible interactive security & privacy training modules — phishing, CEO fraud, secure coding, and more (live demo). |
| GRC Engineering Lab Builder | Static-site generator for hyper-personalized GRC engineering lab prompts (Claude, ChatGPT, Gemini-compatible) — source. |
Books, courses, labs, podcasts, talks, blogs, and communities for learning and practicing GRC Engineering.
| Type | Resource | Author |
|---|---|---|
| Books | GRC Engineering for AWS | AJ Yawn |
| Books | How to Measure Anything in Cybersecurity Risk | Richard Seiersen, Doug Hubbard |
| Books | Measuring and Managing Information Risk: A FAIR Approach | Jack Jones, Jack Freund |
| Books | From Heatmaps to Histograms | Tony Martin-Vegue |
| Books | The Metrics Manifesto | Richard Seiersen |
| Courses | GRC for the Cloud-Native Revolution | Ayoub Fandi |
| Courses | Cybersecurity Foundations: GRC | AJ Yawn |
| Courses | Leveraging AI for GRC | Terra Cooke |
| Courses | Threat Modeling Learning Path | LinkedIn Learning |
| Labs | GRC Playground | Ashley Pearce · original GitHub repo |
| Labs | GRC Portfolio Labs | AJ Yawn |
| Podcasts | GRC Engineer Podcast | Ayoub Fandi |
| Podcasts | Cyber Stories — GRC Engineering | Day Johnson (feat. Ayoub Fandi) |
| Podcasts | Resilient Cyber — Transforming Compliance | Chris Hughes (feat. AJ Yawn) |
| Podcasts | MYGRCPOV — Rise of GRC Engineering | Monica Reagor (feat. AJ Yawn) |
| Talks & Interviews | BSidesSF 2024 — GRC Engineering in Repository | Varun Gurnaney |
| Talks & Interviews | BSidesSF 2025 — Compliance in DevOps Pipeline | Varun Gurnaney |
| Talks & Interviews | Netflix Security — Risk-based Decision Making | Prashanthi Koutha, Shannon Morrison |
| Talks & Interviews | fwd:cloudsec 2025 — GRC Engineering for AWS | AJ Yawn |
| Talks & Interviews | What is GRC Engineering? | Lloyd Evans |
| Talks & Interviews | Automating Compliance Processes | Lloyd Evans |
| Talks & Interviews | CPA to Cybersecurity Pivot | Steve McMichael (feat. Ayoub Fandi) |
| Talks & Interviews | FAIRCon 2022 — Five Objections to FAIR | Tony Martin-Vegue, Prashanthi Koutha |
| Talks & Interviews | GRC Deep Dive on Cyber Risk Quantification | Steve McMichael (with Richard Seiersen) |
| Blogs & Newsletters | The GRC Engineer Newsletter | Ayoub Fandi |
| Blogs & Newsletters | From Heatmaps to Histograms | Tony Martin-Vegue |
| Blogs & Newsletters | Varun Gurnaney's Medium | Varun Gurnaney |
| Blogs & Newsletters | Netflix TechBlog — Open-Sourcing riskquant | Markus De Shon, Shannon Morrison |
| Community | GRC Engineering Discord | Community Discord server |
| Community | GRC Engineering LinkedIn Group | Community LinkedIn group |
| Community | GRC Engineering Club | Patreon community |
Contributions are welcome. To add or update an entry:
- Fork this repository.
- Edit
README.md— add a row to the relevant table, keeping the existing order (chronological for Timeline, grouped-by-Type for Teachings, alphabetical or thematic otherwise). - Open a pull request with a brief explanation of why the resource belongs in this list.
- Tools: Should be actively maintained, documented, and align with GRC Engineering principles (automation, code-as-source-of-truth, measurable outcomes).
- Teachings: Books, courses, talks, podcasts, blogs, labs, and communities — credible authors and accessible content preferred.
- Terms: Vocabulary that meaningfully distinguishes GRC Engineering from legacy GRC. Keep definitions concise (1–2 sentences).
- Timeline: Verifiable historical milestones with a clear connection to the GRC field.
- Comparison table: Keep bullet items short, parallel in structure between Legacy and GRC Engineering columns, and grouped under one of the five program areas.
The cheatsheet renders this README at runtime, so syntax matters:
- All section tables use standard markdown tables.
- Inside the Comparison table, bullet items within a single cell are separated with
<br>•(literal HTML line break + bullet). - Inline links use
[text](url); bold is**text**; italic is*text*. - Raw HTML (
<u>,<em>,<span class="...">,<br>) is preserved through to the rendered cheatsheet.