Continuous Compliance
Producing compliance evidence automatically and continuously from the systems themselves, rather than reconstructing it before an audit.
The traditional cycle is an annual scramble: gather screenshots, export access lists, chase approvals, and assemble a picture of controls that were in place at the moment someone looked.
That approach has two flaws. It is expensive in senior time, and it demonstrates the control existed on the day of the audit rather than throughout the period — which is what the standard actually requires.
Continuous compliance derives evidence from the systems: infrastructure as code showing configuration over time, pipeline records showing every change was reviewed and approved, IAM data showing access reviews were performed, immutable logs showing the audit trail was intact, and policy-as-code results showing that non-compliant resources were prevented rather than merely reported.
Two consequences worth naming. Organisations that adopt this generally find they are more auditable after cloud migration than before, because everything is declarative and logged. And the same automation that produces evidence also prevents the drift it would otherwise document.
The design instruction: when introducing a control, ask what artefact it will leave and where. A control that operates correctly and leaves no trace fails the audit, and retrofitting the trace is harder than designing it in.