Governance, Risk, and Compliance
This domain tests how security is directed and evidenced: who decides, what the rules are, how risk is recorded and treated, and how you prove compliance without pretending compliance equals security.
Hierarchy of documents
- Policy: management intent, mandatory, stable, e.g. access is granted on least privilege.
- Standard: mandatory specifics, e.g. AES-256, 12-character minimum, TLS 1.2 floor.
- Procedure: step-by-step operational instructions.
- Guideline: recommended and discretionary.
Risk management
- Appetite (broad willingness to take risk) vs tolerance (a specific threshold, such as accepting up to five days of patch lag on internal systems).
- Treatment options: avoid, mitigate, transfer, accept. Financial loss can be transferred; accountability to regulators cannot.
- Register fields: ID, description, owner, likelihood, impact, treatment, residual risk, review date.
Frameworks and regulation
ISO/IEC 27001 (ISMS plus Annex A controls), NIST CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover), the seven-step NIST RMF, CIS Controls, SOC 2 Trust Services Criteria, PCI DSS for cardholder data, GDPR and HIPAA for personal and health data. The three lines model: operations owns risk, risk and compliance oversee it, internal audit assures independently.
Worked example
A SaaS vendor will store cardholder data in a public cloud. Reasoning: assess breach risk with likelihood and impact; PCI DSS obligations still bind the merchant; the provider contract, SOC 2 Type II report, and insurance transfer some financial loss; the business owner accepts residual risk in writing; the data controller remains accountable to regulators. Evidence collected: shared responsibility matrix, data processing agreement, audit report.
Traps
Risk accepted with no accountable owner; assuming a vendor contract erases regulatory liability; confusing policy with procedure; treating a certificate as proof that controls operate effectively.