Governance, risk, and compliance (GRC)

Spelled out, the acronym is a claim about how three functions relate. Governance sets direction: policies, ownership, and the decisions leadership makes about what the company will and won’t tolerate. Risk management identifies what threatens those intentions and picks a treatment — mitigate, transfer, accept, or avoid. Compliance demonstrates to auditors and customers that the resulting obligations are actually met. Run separately, the three produce shelfware; run as a loop — governance decides, risk prioritizes, compliance proves — they produce a program that holds up under questioning.

Concretely, GRC is a recurring workload: policy reviews on a schedule, a risk register that gets revisited rather than framed, vendor assessments, access reviews, security training, framework audits, and the customer questionnaires that reference all of the above. Enterprises staff a dedicated team for it. At a startup the same workload exists at smaller scale and lands on whoever is nearest — usually a founder or an engineering lead — which is why this is so often the first security function handed to an outside operator; that model is defined under managed GRC.

The discipline has been migrating from documents to systems. Controls are monitored by a GRC platform, evidence arrives through integrations, and policies live in version control with named owners. Agency treats that shift as the whole point: GRC done well is an engineering practice with paperwork attached, not the reverse. The argument — and how we staff for it — is on GRC Engineering.