GRC & Compliance
Audit-ready programs that hold up under real scrutiny — not a folder of evidence assembled the week before the auditor shows up.
Governance, risk, and compliance get flattened into one acronym so often that people start treating them as one activity, and that's where most programs go wrong. Governance is deciding what "secure enough" means for this business. Risk is figuring out where reality falls short of that and by how much. Compliance is proving it to someone outside the building. Skip straight to the third one — chasing a certificate — and you end up with controls that exist on paper and evaporate the moment the audit ends.
Done well, GRC is just security work with better bookkeeping: the same controls you'd want regardless of a framework, with evidence that accumulates as a byproduct of running them rather than a fire drill assembled once a year.
How a GRC Program Actually Runs
Five stages, and a loop back to the first one — the same cycle regardless of which framework is asking for it.
The Frameworks, and What Each One Actually Buys You
Five names get used almost interchangeably in conversation, and they're not interchangeable at all — each answers a different question for a different audience.
| Framework | Type | Who Needs It | What It Really Tests | Typical Cadence |
|---|---|---|---|---|
| NIST CSF / SP 800-53 | Risk framework | US federal, critical infrastructure, anyone benchmarking maturity | Whether risk is identified, prioritized, and tracked to closure | Continuous, reassessed annually |
| ISO 27001 | Certifiable ISMS standard | Global orgs selling into enterprise or EU customers | Whether an information security management system exists and runs itself | 3-year certification, annual surveillance audits |
| SOC 2 | Attestation report | B2B SaaS selling to other companies | Whether controls actually operated effectively over a period of time | Annual Type II report |
| HIPAA | US federal regulation | Healthcare organizations and their vendors (business associates) | Whether PHI is protected administratively, physically, and technically | Ongoing — no formal certification |
| PCI DSS | Payment card industry mandate | Anyone storing, processing, or transmitting cardholder data | Whether the cardholder data environment is segmented and controlled | Annual assessment (SAQ or QSA, by volume) |
SOC 2 Type I vs. Type II — the Distinction That Actually Matters
This is the one mix-up I correct most often. A Type I report is a point-in-time snapshot — it says the controls are designed correctly, as of today. A Type II report covers a window of time, usually six to twelve months, and says those controls actually operated the way they were designed to the whole time. A buyer doing a serious security review wants Type II; Type I is really just the first checkpoint on the way there, useful mainly for a young company proving it has controls at all before it can prove they held up.
How I'd Build the Program, Not Just Pass the Audit
- Pick one control set and map everything else to it. Running parallel programs for NIST, ISO, SOC 2, and PCI multiplies effort for no reason — map their overlapping controls onto a single internal control library once, then satisfy every framework from that one source of truth.
- Make evidence a byproduct, not a project. If pulling audit evidence requires a dedicated scramble, the control wasn't really operating — logging, ticketing, and access reviews should produce their own audit trail as a side effect of being used.
- Monitor controls continuously, not once a year. A control that's only checked during the audit window is a control you're gambling on for the other eleven months.
- Keep a risk register people actually use. Not a spreadsheet that gets updated for the auditor and ignored otherwise — a living list that shapes what gets prioritized day to day.
- Track findings to closure between audits. A finding that gets fixed right before the next assessment and drifts back afterward isn't fixed — it's cosmetic.
- Treat the auditor as a stakeholder to prepare, not an adversary to survive. A well-run program can walk an auditor through the environment without rehearsed answers, because there's nothing to hide behind.
Where These Programs Actually Fail
The failure modes repeat across every framework, almost word for word:
- Treating the certificate as the finish line. Passing an assessment only confirms the minimum bar was cleared on the day someone happened to look — it says nothing about whether risk actually went down, which was the entire reason to start the program.
- Controls that exist only in the policy document. Written policy and operating reality drift apart quietly, and nobody notices until an auditor — or an incident — asks for evidence.
- Manual evidence collection under deadline pressure. Screenshots gathered in a panic the week before an assessment are a signal the control isn't actually embedded in how the team works.
- Scope that's wrong from the start. A PCI cardholder data environment that isn't really segmented, or an ISO 27001 scope statement that quietly excludes the systems that matter most, undermines everything built on top of it.
- No connective tissue between audits. Findings get remediated to pass, then quietly regress, because nothing tracks them in the twelve months between assessments.
A framework is a vocabulary for talking about risk to someone outside your walls — it was never supposed to be the risk-reduction plan itself.