Governance, Risk & Compliance
Obligations mapped to controls, controls mapped to evidence.
GRC has a reputation problem, and it earned it: too many programs produce a binder that proves nothing about whether the organization is actually defended. But the underlying job — enumerate the obligations, map them to controls, map controls to evidence, and keep the evidence current — is genuinely load-bearing, and it’s tractable with engineering.
The bet in this pillar is that GRC done as code is a different discipline from GRC done as spreadsheets, and the difference is where all the value is.
Why it matters
Section titled “Why it matters”Compliance is where security work gets funded. It’s also where it gets wasted: the same control gets evidenced three times for SOC 2, ISO 27001, and FedRAMP because nobody built the crosswalk. Common-control mapping and automated evidence pipelines are the two moves that turn a cost center into leverage.
How this connects
Section titled “How this connects”- → Detection Engineering: continuous control monitoring and detection engineering are the same pipeline with different consumers. Log coverage analysis is shared audit evidence.
- → IAM: access review, least privilege, and joiner/mover/leaver are control requirements in every framework. Identity is where the evidence lives.
- → AppSec: secure SDLC, change management, and vulnerability management are controls. Scanning output is evidence when collected deliberately.
- → Penetration Testing & Red Teaming: required by PCI DSS and FedRAMP outright, and a pentest finding is usually a control gap in disguise.
- → AI & Automation: evidence collection is the single best automation target in security — and the EU AI Act makes AI systems themselves a compliance surface.
- → Threat Intel: quantitative risk (FAIR, loss exceedance) is the honest version of the risk register.
- → Cloud & Infrastructure Security: where most technical control requirements actually land — encryption, segmentation, backup and key management. “Encrypted at rest” is an audit answer; that pillar is what it buys.
- → Incident Response & Digital Forensics: breach notification clocks are regulatory, and evidence handling has to survive counsel.
- → Data Security & Privacy Engineering: obligation vs. engineering. §4 says what must be true; §10 is how it becomes true in a system that is already running.
What’s here
Section titled “What’s here”| Subsection | Focus |
|---|---|
| Common Frameworks | NIST CSF 2.0 and SP 800-53, ISO/IEC 27001 & 27002, SOC 2, FedRAMP, CIS Controls, PCI DSS v4.x, HITRUST, CMMC |
| Regulations by Industry | HIPAA/HITECH, GLBA/SOX/DORA/NYDFS 500, NERC CIP and TSA directives, FISMA and ITAR/EAR, FTC Act and state breach laws |
| Regulations by Region | EU (GDPR, NIS2, DORA, CRA, AI Act), the US state privacy patchwork, UK, APAC, cross-border transfer mechanisms |
| Compliance Mapping | Control crosswalks and common controls, OSCAL and SCF, evidence collection, avoiding duplicate work across audits |
| GRC Engineering | Compliance as code (OSCAL, OPA/Rego, Conftest), automated evidence pipelines, continuous control monitoring, drift detection |
| Risk Management | Risk register mechanics, qualitative vs. quantitative, third-party risk, exception and acceptance workflows |