Governance, Risk, and Compliance in Agile Service Delivery
Governance, Risk, and Compliance in Agile Service Delivery
This domain tests whether you can design controls that provide assurance without serialising delivery. Governance means decision rights plus the controls that evidence they were exercised - not a committee that approves everything.
Principles
- Risk-based proportionality: control effort follows impact and likelihood. A customer-facing payments change warrants more control than a copy edit.
- Prefer preventive controls where cheap (automated tests, peer review, pipeline gates) and detective controls where not (sampling, monitoring, audit logs).
- Evidence should be a by-product of delivery: version history, pipeline logs, approval records, test results, retained automatically.
- Policy as code: codify the rules the pipeline enforces, so control and evidence cannot drift apart.
- Map every control to a risk and a requirement; unmapped controls add cost without assurance.
Small teams and segregation of duties
A team of six cannot staff separate developers, reviewers and deployers. Compensating controls preserve the intent: branch protection requiring review by someone other than the author, automated test gates, immutable deployment logs, four-eyes approval for high-risk changes, and periodic independent sampling. The objective is preventing undetected unauthorised change, not preventing one person from touching one system.
Worked example
An auditor asks for evidence that financial-reporting changes were authorised. The team shows that every change is a backlog item with a linked story and risk label; branch protection requires an approval from someone other than the author; the pipeline records tests, artifact hash and approver; production deploys run through the same pipeline with an immutable log; and a quarterly sample is reviewed against risk labels. Reasoning: each element maps to a control objective - authorised, tested, traceable - and is produced by the delivery process, so the evidence is current and complete without a separate audit exercise.
Traps
Assuming Agile means no documentation; inventing controls nobody maps to a risk; claiming segregation of duties requires separate teams; engaging audit only after go-live; treating compliance as a phase rather than continuous monitoring.
Key distinction
An auditor tests whether the control operated every time, so a control that depends on memory will fail sampling. Automate it, or expect to evidence exceptions.