How-to & Guides · How-to

How to Implement policy-as-code

Express cloud guardrails as versioned, testable policies with preventive, detective, deployment-time, and exception controls across multiple providers.

policy-as-codegovernancecomplianceinfrastructure-as-codemulti-cloudhowguidesimplement

Document class: How-to Guides implementation guide Normative terms: MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are requirements levels. Applicability: Versioned policy definitions, testing, preventive, detective, and deployment enforcement, parameters, exceptions, and multi-cloud mapping. Exception process: Deviations require a documented risk assessment, compensating controls, named risk owner, and expiry date.

Control fieldValue
Document IDHTG-27
OwnerCloud Center of Excellence
Review cycleAt least annually and after material policy, provider, or compliance changes
EvidencePolicy source, test matrix, assignment state, compliance results, remediation logs, exception record, and review date

Decision in brief: Express one control objective as versioned tests and provider-specific enforcement, with exceptions explicit, owned, and expiring.

Document type: Governance implementation guide Primary example: Azure Policy with Terraform and CI validation Operating principle: Normalize the control objective, then implement the strongest safe enforcement available in each cloud.

Objective

Convert architecture, security, cost, residency, and operational requirements into policies that are reviewed, tested, deployed, measured, and safely changed. policy-as-code includes provider-native controls, IaC scanning, admission policy, compliance queries, exception workflow, and remediation evidence.

Enforcement model

flowchart LR CONTROL[Control objective] --> TEST[Policy unit tests] TEST --> PR[Pull-request evaluation] PR --> DEPLOY[Provider policy deployment] DEPLOY --> PREVENT[Preventive enforcement] DEPLOY --> DETECT[Detective evaluation] DETECT --> REMEDIATE[Safe remediation] PREVENT & REMEDIATE --> EVIDENCE[Compliance evidence]

Build the policy catalog

For every policy, define a stable control ID, requirement, rationale, scope, severity, mode, parameters, provider mappings, exclusions, owner, remediation, evidence, version, and deprecation plan. Group policies into approved initiatives or bundles aligned to landing-zone archetypes.

Implementation procedure

  1. Prioritize controls that prevent public exposure, excessive privilege, unencrypted data, missing logs, unsupported regions, and unowned resources.
  2. Write positive, negative, boundary, exemption, and backward-compatibility tests.
  3. Evaluate Terraform or other IaC in pull requests before provider deployment.
  4. Roll out provider policy in audit mode and establish the current compliance baseline.
  5. Correct false positives and narrow policy parameters; never use a broad exclusion to solve one workload issue.
  6. Enforce on new resources, then remediate existing resources through an approved plan.
  7. Monitor evaluation failures, denied deployments, exemptions, drift, and policy changes.
  8. Promote policy releases through protected environments with rollback artifacts.

Provider mapping

CapabilityAzureAWSGCPOCI
Organization guardrailsAzure Policy / management groupsSCPs, Config, Control Tower controlsOrganization Policy and custom constraintsSecurity Zones and Cloud Guard
IaC evaluationOPA/Conftest or scannersOPA/Conftest or scannersOPA/Conftest or scannersOPA/Conftest or scanners
Kubernetes admissionGatekeeper, Kyverno, or managed policyGatekeeper/KyvernoPolicy Controller/GatekeeperGatekeeper/Kyverno
EvidenceResource Graph and compliance stateConfig aggregators and Security HubAsset Inventory and SCCSearch, Cloud Guard, and Audit

Exception lifecycle

Require requester, business reason, affected resources, compensating control, risk owner, approval, issue reference, start date, expiry, and review cadence. Encode exemptions at the narrowest scope. Alert before expiry and fail closed unless renewal is approved. Permanent exemptions indicate that the policy or architecture must be redesigned.

Safe remediation

Auto-remediate only when the action is idempotent, low risk, bounded, and tested. Adding a required tag may be safe; changing routes, encryption keys, identity assignments, or public access can cause outage or data loss. Use a reviewed change workflow for high-impact correction.

Validation

  • Policy tests cover compliant, noncompliant, boundary, and exempt resources.
  • Pull requests fail with an actionable control ID and remediation message.
  • Provider enforcement cannot be bypassed by normal workload identities.
  • Compliance state aggregates every account boundary and reports stale evaluation.
  • Exceptions are scoped, approved, monitored, and expire automatically.
  • Policy rollback and remediation reversal are tested before production rollout.