GRC for Cloud

What GRC is

GRC is the discipline that translates security intent ("we will protect customer data") into controls (specific things we do - encrypt at rest, MFA on admin accounts, rotate keys), into evidence (proof those controls run), and into attestation (a third party signing off that what we say is true). Done well, it's the connective tissue between the security org, the rest of the business, and the outside world of auditors, regulators, and customers who want assurance before they buy.

Done badly, it's the worst caricature security has: a separate team, a separate vocabulary, screenshots-for-screenshots'-sake, and a calendar driven by audit windows rather than by what's actually changing in the environment. The good news is that the cloud-native version of GRC can avoid most of those failure modes if the team builds with the right primitives from the start.

This page is the practitioner's view - what the work actually is in 2026, which frameworks you'll encounter, how compliance-as-code changes the game, and how to choose between native cloud tools, CSPM/CNAPP, and dedicated GRC platforms.

The three pillars

The "G", "R", and "C" are distinct disciplines that interlock. Most orgs do one well, one passably, and one badly - recognizing which is yours is the first step in maturing the program.

The pillars are reinforcing. A weak governance pillar produces inconsistent risk decisions; a weak risk pillar produces compliance work that costs more than it should because nothing is risk-prioritized; a weak compliance pillar produces well-governed, well-risked programs that customers can't buy from because there's no report to send them.

What cloud changes about GRC

The fundamentals of GRC predate cloud by decades. The execution looks meaningfully different once your workloads run in someone else's data center, behind APIs that auditors don't have ssh access to.

The bottom row matters most. In traditional GRC, the audit finding generally arrives before the breach. In cloud, an attacker scanning for public S3 buckets, exposed IMDS, or overly permissive trust policies can act in minutes - your control either holds at the moment of misconfiguration, or it doesn't hold at all. GRC has to keep up with the cloud's change rate, not the auditor's calendar.

The framework landscape

You will eventually be asked about most of these. The pragmatic strategy is to pick one as your primary internal framework, map all others to it, and run a single control set with framework-specific overlays where required.

SOC 2

The de facto B2B SaaS attestation in North America. AICPA-defined Trust Services Criteria - Security is required; Availability, Confidentiality, Processing Integrity, and Privacy are optional add-ons. Type I is a point-in-time design assessment; Type II covers a period (typically 6 or 12 months) and verifies the controls actually ran. Most enterprise procurement teams require Type II.

ISO 27001

The international information-security management system (ISMS) standard. More prescriptive than SOC 2 on management-system structure, less prescriptive on individual technical controls. Required or preferred outside North America for most enterprise buyers; increasingly co-required with SOC 2. Annex A (in the 2022 revision) lists 93 reference controls.

PCI DSS

The Payment Card Industry Data Security Standard. Required if you store, process, or transmit cardholder data. v4.0 (in force) places much heavier expectations on continuous monitoring and risk-based scoping than v3.2.1 did. Tokenization and scope reduction are the highest-leverage moves; doing it the brute-force way (everything in scope) is several multiples more expensive.

HIPAA / HITECH

U.S. healthcare. The Security Rule defines administrative, physical, and technical safeguards for protected health information (PHI). All three major clouds offer BAA-eligible services; using a service not on your provider's BAA list with PHI is a quiet path to a finding. Breach Notification Rule sets the timeline for disclosure.

FedRAMP

U.S. federal cloud authorization. Three impact levels (Low, Moderate, High) drawn from NIST SP 800-53. Moderate is the most common; High applies to data whose loss would have severe or catastrophic effect. The authorization process is long (12-18+ months typical) and expensive; most vendors use a 3PAO and target an agency sponsor or the Joint Authorization Board.

NIST Cybersecurity Framework (CSF)

Not an attestation, but the most-cited common-language framework for security programs. CSF 2.0 organizes work into six functions: Govern, Identify, Protect, Detect, Respond, Recover. Useful as the meta-framework that maps SOC 2, ISO 27001, and PCI DSS to a shared vocabulary for executive reporting.

CIS Benchmarks

Technical baselines - specific configurations for AWS, Azure, GCP, Kubernetes, Docker, OS images, and more. Not attestations; they're the implementation-level baseline most CSPM tools score against by default. Aligning your environment with CIS produces evidence that crosswalks cleanly to SOC 2, ISO 27001, and PCI DSS controls.

Privacy: GDPR, CCPA/CPRA, and regional

Personal-data protection laws. GDPR (EU), CCPA / CPRA (California), LGPD (Brazil), PIPL (China), and dozens more. Distinct from security frameworks but heavily overlapping - most security controls also serve privacy obligations. Data-residency, data-subject-rights workflows, and lawful-basis tracking are the new asks; cloud providers have residency tooling (regions, sovereign-cloud offerings) to support them.

Sector-specific

• SOX - U.S. public-company financial-reporting controls. ITGC (IT general controls) is the security-relevant slice.
• NIST SP 800-171 / CMMC - U.S. defense supply chain.
• NYDFS Part 500, FFIEC, GLBA Safeguards Rule - U.S. financial services.
• NERC CIP - North American electric utilities.
• NIS2, DORA - EU critical-infrastructure and financial-services resilience.
• IRAP (Australia), ENS (Spain), BSI C5 (Germany), HKMA (Hong Kong) - country-specific cloud requirements.

The 80/20 of mapping

SOC 2, ISO 27001, and most other frameworks overlap by 60-80%. Pick one as the internal source-of-truth control set; map every other framework to it. Add framework-specific controls only where the others don't already cover the requirement (e.g., PCI DSS network segmentation, HIPAA breach-notification timelines, FedRAMP continuous monitoring deliverables). This is the single highest-leverage decision in a multi-framework program.

Control frameworks & baselines

Where attestation frameworks (SOC 2, ISO 27001) define what outcomes you must demonstrate, control frameworks define how at the configuration level. Cloud GRC programs reach for these:

• CIS Benchmarks - per-platform technical baselines. CIS AWS Foundations, CIS Azure Foundations, CIS GCP Foundations, CIS Kubernetes, plus dozens of OS and application benchmarks. The lingua franca of CSPM rule libraries.
• NIST SP 800-53 - comprehensive U.S. federal control catalog. Underpins FedRAMP, used widely as a reference even outside government. Rev 5 is current.
• CSA Cloud Controls Matrix (CCM) - cloud-specific control framework from the Cloud Security Alliance, with crosswalks to most major attestation frameworks. Used heavily for vendor-risk questionnaires (CAIQ).
• AWS Well-Architected Framework - Security Pillar, Azure Cloud Security Baseline, GCP Architecture Framework - Security - provider-authored baselines. Practical starting points; well-aligned with the CIS Benchmarks for the same platform.
• MITRE ATT&CK Cloud - not a control framework, but the threat model your controls are defending against. Mapping detections (see Cloud SOC) and preventative controls to ATT&CK techniques produces the coverage-gap analyses auditors and CISOs both find legible.

Policy-as-code & compliance-as-code

The biggest mechanical change cloud brings to GRC is that policy can be code. The control "S3 buckets must have public access blocked" can be a one-line rule that runs against every bucket every time anything changes, instead of a sentence in a PDF that gets sampled annually.

The languages and runtimes

• Open Policy Agent (OPA) / Rego - vendor-neutral, runs anywhere. The CNCF graduated standard. Used heavily for Kubernetes admission control (Gatekeeper / Kyverno), Terraform pre-apply checks (Conftest), and API authorization.
• AWS Config Rules - managed and custom rules that evaluate resource configurations continuously and on every change.
• Azure Policy - JSON-defined rules that audit or enforce at the subscription / management-group scope. Pairs with Initiative definitions to bundle controls into framework-aligned sets.
• GCP Organization Policy - constraint-based enforcement at organization, folder, or project scope. Pairs with Security Health Analytics for detective rules.
• Sentinel - HashiCorp's policy-as-code for Terraform Cloud / Enterprise.
• Kyverno, Gatekeeper - Kubernetes admission policy (see also the Kubernetes page).
• CSPM policy languages - Wiz, Prisma Cloud, Lacework, Orca, Defender for Cloud, and every other CSPM ships its own rule library with crosswalks to CIS, NIST, SOC 2, ISO 27001, PCI DSS, HIPAA. Most also accept custom rules in the platform's own DSL.

Where to enforce

• Pre-deploy - the highest-leverage spot. CI/CD pipelines run Conftest / Checkov / tfsec / OPA against Terraform plans, blocking the misconfiguration before it ships. Kubernetes admission controllers reject non-conformant resources before they reach the cluster.
• At deploy - cloud-native enforcement at the API. Service control policies, organization policies, deny-by-default IAM permissions stop the change at the cloud's edge even if pipeline checks were bypassed.
• Post-deploy - CSPM, Config Rules, Security Command Center, Defender for Cloud catch the drift. Auto-remediation handles the high-confidence findings; everything else flows to a ticket queue.

The three layers are complementary. Pre-deploy is cheapest and fastest; post-deploy is the safety net for everything that slips. Skipping pre-deploy because "the CSPM catches it" means you ship the misconfiguration and rely on the post-deploy detection to be tuned, alerted, and acted on - at which point the bucket may already have been scanned.

Continuous compliance with CSPM/CNAPP

A CSPM (Cloud Security Posture Management) tool inventories your cloud, evaluates every resource against a rule set, and emits findings continuously. When the rule set is tagged with the framework it satisfies (CIS, NIST, SOC 2, ISO 27001, PCI DSS, HIPAA, etc.), the CSPM becomes the live sensor for your compliance posture - not the system of record, but the source of truth for "is this control passing right now?"

What CSPM/CNAPP gives GRC

• Continuous evidence. Every control's pass / fail state, timestamped, queryable by framework.
• Drift detection. A control that was compliant yesterday and isn't today is now an alert, not a quarterly-audit discovery.
• Risk-prioritized remediation. A modern CNAPP weighs findings by exploitability and exposure (a public S3 bucket with sensitive data + an over-permissioned role + a CVE in a workload that touches it is graver than any one finding alone). GRC inherits this prioritization for free.
• Exception workflows. The platform records the approval, the expiration date, the compensating control, and the owner - the artifacts auditors actually want.
• Auditor-ready exports. Most CSPMs produce framework-mapped reports out of the box. The auditor sees the same evidence the security team sees, on the same cadence.

What CSPM/CNAPP doesn't give you

• The non-technical controls. Background checks, security training completion, vendor risk assessments, business-continuity plans - none of these are visible from a cloud API. A GRC platform (or a well-organized wiki) is still required.
• The framework structure. CSPM finds control failures; it doesn't write the policy that says "this control exists." The framework mapping, the policy document, the exception register - that's GRC-team work.
• The auditor relationship. Tools don't answer auditor questions. Humans do.

The pragmatic split: CSPM/CNAPP for the technical controls (probably 60-70% of any modern framework), GRC platform or wiki for the rest, both feeding into the same audit-evidence repository.

Audit evidence in cloud

The evidence shape changes in cloud, and so does the work of gathering it. The categories an auditor will ask about - and what cloud-native sources answer them:

Automating evidence collection

The 2026 reality: the GRC platforms that have integrated with cloud APIs collect most of the technical evidence automatically. Vanta, Drata, Secureframe, Hyperproof, ServiceNow GRC, OneTrust, and others connect to AWS, Azure, GCP, GitHub, identity providers, MDM, HRIS, ticketing - and refresh evidence on a schedule. The control-engineering work is in defining the mapping; once defined, the evidence is mostly free.

GRC platforms

The system-of-record layer that lives above the cloud-native tooling. The major categories in 2026:

• Compliance-automation-first - Vanta, Drata, Secureframe, Thoropass, Anecdotes. Built around automated evidence collection and SOC 2 / ISO 27001 / similar attestations. Fastest path to a first SOC 2 for a SaaS company.
• Integrated GRC platforms - ServiceNow GRC, MetricStream, Archer, OneTrust, LogicGate, Hyperproof. Heavier enterprise tooling; broader scope (operational risk, vendor risk, third-party risk, audit management). Right when your org is large enough to have a full GRC function.
• Privacy-led - OneTrust, TrustArc, Securiti. Strong on GDPR / CCPA / data-subject-rights workflows.
• Open-source / DIY - Comply, internal git-based control libraries, controls-as-code in OSCAL (NIST's machine-readable control format). Right when you have engineers happy to build the missing automation.

Choosing one

• Integration depth with your cloud(s) and identity provider. The whole value proposition is automated evidence. A platform that pulls 80% of evidence automatically is worth 2-3× one that pulls 30%.
• Framework coverage you actually need. Many tools support 20+ frameworks; you'll use 2-4. Pay for the depth on those, not the breadth across all.
• Auditor familiarity. If your target auditor has run a hundred SOC 2s on Vanta, that's a cheaper audit than the same auditor's first ServiceNow GRC engagement.
• Total time-to-attestation. The fastest path to a first SOC 2 Type II for a 30-person SaaS is a compliance-automation platform + an experienced auditor + 6 months of evidence collection. Anything more complex is over-engineered.

AWS, Azure, and GCP side-by-side

The native GRC-supporting capabilities each cloud ships, reduced to a one-screen reference:

The native tools are necessary but not sufficient. Every cloud will tell you it ships everything a regulated workload needs; in practice the cross-cloud GRC platform fills the gaps between them, and the human program runs above all of it.

Roles & responsibilities

GRC roles look different at different company sizes. The work doesn't disappear at small scale; it just collapses onto fewer people.

• CISO / Head of Security. Owns the program at the executive level. Signs the security policy, owns the risk register at the board level, fronts the auditor relationship for major engagements.
• GRC Lead / Compliance Manager. Owns the framework mappings, the audit calendar, the evidence repository, and the relationship with auditors and 3PAOs. The role that grows in headcount as the company adds frameworks.
• Security Engineer (controls). Builds the technical implementations of the controls - IAM policies, encryption configs, logging pipelines, CSPM rules. Lives in the cloud platform team day-to-day; consults with GRC on framework mapping.
• Risk Analyst. Maintains the risk register, runs assessments (cloud, vendor, application), tracks treatments. Bigger orgs separate operational and enterprise risk; smaller orgs combine.
• Privacy Officer / DPO. Where GDPR or similar applies. Owns data-subject-rights processes, ROPA (Record of Processing Activities), and the privacy-impact-assessment cadence.
• Internal auditor. Independent line of assurance. Runs internal audits against the same frameworks external auditors will, before the external auditor arrives.
• External auditor / 3PAO. Third-party assurance. SOC 2 (CPA firm), ISO 27001 (registrar), FedRAMP (3PAO), PCI DSS (QSA). Not on staff; contracted.
• Engineering & product partners. The non-GRC humans whose work the controls describe. Their cooperation is the bottleneck of any GRC program; a program adversarial to engineering eventually fails its audits because evidence stops flowing.

For how these roles relate to broader cloud-security career paths, see the Cloud Security Careers page.

Maturity stages

A useful staging model for a cloud GRC program:

The skip-stage cost is real here too - an org trying to compliance-as-code without a written policy and a defined control set is automating against nothing. Sequencing matters.

Common pitfalls

• Treating GRC as a paperwork team separate from engineering. Controls live in code; the team that writes code has to be a first-class partner. Adversarial GRC ships bad audits.
• Single-framework tunnel vision. Pursuing SOC 2 without thinking about the ISO 27001 or PCI DSS that's coming six months later means duplicate work and two control sets. Pick the primary up front, plan the overlays.
• Manual evidence collection at scale. Screenshots in a Google Drive folder is a Stage 1 pattern. Past 20 controls it becomes the dominant cost of the program. Automate.
• Compliance theater. Controls written to pass the audit, not to reduce risk. The auditor will sign off; the breach will happen anyway. Risk-rank, then implement; never the reverse.
• Letting exceptions accumulate. Every exception is a risk acceptance with an expiration date. Without a workflow that surfaces expiring exceptions, you accumulate them silently until an auditor finds them. Track and review.
• Outsourcing the auditor relationship to the GRC platform. The platform helps; it doesn't replace the human conversation. Build the relationship with your auditor across multi-year engagements; the same firm year-over-year is dramatically cheaper than rotating.
• Mapping debt. Frameworks evolve (PCI DSS 4.0, ISO 27001 2022, NIST CSF 2.0, SOC 2 with revised TSC). Mapping drift is silent - every framework revision needs a planned remap.
• Picking a CSPM that doesn't map to your target frameworks. Every modern CSPM does - but verify the depth, not just the checkbox. Some tools map 90% of CIS but only the highlights of FedRAMP.
• Confusing residency with sovereignty. A region in the right country doesn't, by itself, address regulator concerns about cloud-provider personnel access, foreign legal subpoena, or sovereign-cloud requirements. Read the specific regulation; pick the matching offering.
• "AI will write our controls." AI is a credible assistant for drafting policy language, mapping frameworks, and summarizing evidence. It is not a substitute for the human judgment that decides what risk the org will accept. Treat as augmentation; the auditor still needs a human signatory.

Further reading

Frameworks & standards

• AICPA - SOC 2
• ISO/IEC 27001:2022
• PCI Security Standards Council
• FedRAMP program
• NIST Cybersecurity Framework 2.0
• NIST SP 800-53 Rev 5
• CIS Benchmarks
• CSA Cloud Controls Matrix
• NIST OSCAL - machine-readable controls

Policy-as-code tooling

• Open Policy Agent
• Conftest
• Kyverno
• Checkov
• tfsec

Provider docs

• AWS Compliance Center
• AWS Audit Manager
• Microsoft Compliance offerings
• Azure Policy documentation
• Google Cloud Compliance
• GCP Assured Workloads

Related CSOH pages

• Shared responsibility - where provider obligations end and yours begin.
• CSPM vs CNAPP - the posture-management layer GRC programs depend on.
• Cloud SOC - the detection / response counterpart to preventive controls.
• CI/CD - where pre-deploy policy enforcement lives.
• Landing zones - the foundation that makes GRC enforceable at scale.
• Cloud security careers - GRC, audit, and compliance role tracks.
• Glossary - every term on this page, defined.

FAQ

How long does a first SOC 2 Type II take?

For a 20-50-person SaaS using a compliance-automation platform: roughly 3-4 months to readiness, then a 6-month observation period for Type II, then 4-8 weeks of audit fieldwork. Total elapsed: 9-12 months from "we should do this" to a signed report. Skip the platform and add 50%; skip the prior auditor relationship and add another 25%.

Should the GRC team report to the CISO or to Legal?

Most cloud-native orgs put GRC inside Security under the CISO. Some larger or heavily regulated orgs (financial services, healthcare) keep the compliance function under Legal or a Chief Compliance Officer. The trade-off: Security-aligned GRC is closer to the engineering work that produces evidence; Legal-aligned GRC is closer to the contractual and regulatory side. Neither is wrong; pick the one that matches where the dependent decisions get made.

Is FedRAMP worth pursuing for a commercial SaaS?

Only if you have an actual federal-government deal that requires it. FedRAMP is 12-18+ months of work and significant ongoing cost; the math only works against revenue you can name. The path is: identify the federal customer, secure an agency sponsor or pursue JAB authorization, pick a 3PAO, and budget 18 months. "Maybe federal eventually" is a recipe for sunk cost.

How does zero trust relate to GRC?

Zero trust is an architectural pattern; GRC is a discipline. Zero-trust controls (verify every request, least privilege, continuous validation) generate evidence GRC values (every access logged, every policy decision auditable). Most modern frameworks now reference zero-trust principles (NIST 800-207, CSF 2.0 Govern function). They reinforce each other; neither replaces the other.

What's changing in cloud GRC over the next 1-2 years?

Three forces: AI assistance for drafting and mapping (most GRC platforms now ship LLM-assisted evidence summarization and control-mapping), regulatory expansion (NIS2, DORA, AI-specific regulations like the EU AI Act), and continuous-control-monitoring displacing point-in-time evidence as the auditor expectation. The orgs investing in compliance-as-code now will have an easier time when the third force fully arrives.

Do auditors trust automated evidence?

Increasingly yes - and the signing auditor's familiarity with the platform you use is the bigger variable. A SOC 2 auditor who has run a hundred audits on Vanta evidence is comfortable with Vanta evidence; the same auditor's first ServiceNow GRC engagement will take longer. Talk to your auditor about evidence sources before you pick the platform.