GRC and Audit - Continuous Compliance, Control Mapping, and Evidence
What this domain covers
Governance, risk, compliance and audit questions test whether you can make compliance a by-product of engineering rather than a seasonal scramble. Expect questions on risk treatment, framework scope, control mapping across standards, separation of duties in pipelines, exception handling and automated evidence.
Core rules
- Governance defines policies, standards and procedures with named owners. A control without an owner is a suggestion.
- Risk management cycle: identify, assess as likelihood times impact, treat by mitigating, transferring, accepting or avoiding, then monitor. The risk register records owner, treatment and review date; risk appetite is set by leadership, not by the security team alone.
- Framework scope matters. ISO/IEC 27001 certifies an ISMS with Annex A controls. SOC 2 reports against trust services criteria for a defined period. PCI DSS 4.0 applies wherever cardholder data is stored, processed or transmitted and now expects explicit software development and change-management controls. GDPR requires privacy by design, data protection impact assessments, and breach notification within 72 hours. NIST CSF 2.0 organizes outcomes around Govern, Identify, Protect, Detect, Respond and Recover.
- Control mapping: one technical control often satisfies several frameworks. Map once, reuse the mapping, and avoid parallel spreadsheets per standard.
- Compliance as code: policies expressed in OPA/Rego, Sentinel or cloud config rules; policy tests run in the pipeline; evidence collected continuously and timestamped.
- Audit realities: change-management evidence lives in pull-request approvals, protected branches and deployment logs. Separation of duties means the person who writes code should not be the only approver of its production deployment. Exceptions need an owner, a compensating control and an expiry date.
- Third-party and supplier risk extends to SaaS providers, registries and build tools.
Worked example
An auditor asks for proof that production changes were approved throughout the year. Reasoning: the real control is not a ticket but the combination of required peer review, a protected branch, and a recorded deployment approval, all attributable to an identity. Evidence is exported from source control and the CI system, mapped once to the change-management control that satisfies ISO 27001, SOC 2 and PCI DSS, and regenerated monthly by script. The exception queue is reviewed for expired entries before the audit window opens.
Traps that cost marks
- Equating compliance with security; passing an audit does not mean resisting attack.
- Collecting evidence manually only in audit season, which hides drift.
- Exceptions with no owner, compensating control or expiry.
- Maintaining a separate control set per framework and duplicating effort.
- Breaking separation of duties by letting one administrator both change code and approve deploys.