Compliance and Governance
Compliance is evidence that the organization follows required controls. DevOps does not remove governance; it changes how governance is implemented. Manual approval spreadsheets are weak evidence compared with versioned policy, immutable logs, signed artifacts, access records, and automated control checks.
Policy as Code
Policy as code expresses rules in executable form: images must come from approved registries, production deploys require protected branches, public storage must be explicitly justified, and secrets cannot appear in source. Automated policy reduces ambiguity and gives immediate feedback.
Separation of Duties
Separation of duties does not require slow handoffs. A protected workflow can require review for risky changes while still letting low-risk deployments proceed automatically. The control should match the risk.
Audit Evidence
Good systems produce evidence as a byproduct: who approved, what changed, which artifact ran, which policy passed, which vulnerability exceptions were accepted, and when access was used.
Governance as Product
Governance fails when it appears only as late manual approval. Teams experience it as delay, and auditors receive weak evidence. Governance works better when controls are built into delivery paths: protected branches, required reviews, environment rules, artifact signing, policy checks, access logs, and exception workflows.
The control should be understandable. If a deployment is blocked, the engineer should know which rule failed and how to remediate it. A mysterious “compliance denied” message encourages bypasses and support tickets.
Risk-Based Controls
Not every change deserves the same process. A documentation fix, a minor UI copy change, a database deletion, and an identity-policy change have different risk. DevOps governance should classify risk and apply proportional controls. This preserves speed for low-risk work while strengthening review where harm is plausible.
Exceptions
Exceptions are part of real governance. A vulnerability may require temporary acceptance because no patch exists. A production incident may require emergency access. The key is to record owner, reason, scope, expiry, compensating control, and review date. Permanent exceptions are usually undocumented policy changes.
Study Task
Choose one compliance requirement and translate it into delivery evidence. Specify which system produces the evidence, where it is stored, who can alter it, and how an auditor would verify it without interviewing three engineers.
Operational Review
Governance should be reviewed for both assurance and usability. A control that nobody can follow will be bypassed. A control that cannot produce evidence will fail audit. The best controls are integrated into normal work and produce records automatically.
Reviewers should ask whether evidence is tamper-resistant enough for its purpose. A chat approval may be useful context, but a protected workflow approval tied to a commit, artifact, environment, and user identity is stronger. Audit evidence should survive staff turnover and memory loss.
The review should also examine emergency paths. A system that has no break-glass route may fail during crisis. A system with unbounded break-glass access may fail governance. The mature answer is time-limited emergency access with logging, review, and follow-up remediation.
An auditor asks which commit, artifact, approver, and vulnerability scan result correspond to a production deployment.