HCP Terraform has introduced a native pre‑written policy experience that embeds HashiCorp‑managed policy sets directly into the policy‑set creation UI. Engineers can now discover, review, and attach ready‑made compliance controls without leaving their Terraform workflow, which shortens the time to enforce guardrails and reduces the need for custom policy development.
How the new workflow works
When creating a policy set, users select the pre‑written policy type. The UI provides filters for cloud provider, service, and compliance framework, allowing teams to locate policies that match AWS Foundational Security Best Practices (FSBP) or the AWS CIS Foundations Benchmark. After reviewing the policy description, one or more policies can be added to the set. Each policy’s enforcement mode can be set to Advisory (default) or switched to Mandatory to block non‑compliant runs. The completed set can then be attached at the organization, project, or workspace level.
Impact on architecture and operations
Pre‑written policies are stored as read‑only assets managed by HashiCorp, preserving their integrity while still being consumable by any Terraform workflow. Both existing Sentinel policies and new policies authored with tfpolicy are supported in the same set, meaning teams do not need to maintain separate pipelines for different policy engines. The default advisory mode lets engineers surface violations without disrupting CI/CD pipelines; switching to mandatory mode introduces a hard stop, which can be staged as part of a gradual compliance rollout. Because the policies are applied at the HCP Terraform layer, there is no additional infrastructure to provision, but teams must ensure that the selected enforcement mode aligns with their change‑management processes.
Considerations for security and compliance teams
The beta currently covers AWS FSBP and AWS CIS Foundations Benchmark, with a limited set of Azure and Google Cloud CIS policies slated for future release. Security teams should audit the coverage of the provided policies against their internal control matrices to identify gaps that still require custom policies. Since the policies are read‑only, any required custom logic must be authored separately and combined with the pre‑written set. Teams also need to decide where to attach the policy set—organization‑wide for broad governance, or at a specific workspace for targeted enforcement—balancing the breadth of coverage against the risk of over‑constraining development pipelines.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Adopt the native pre‑written policy set to accelerate compliance onboarding: start with advisory mode to surface violations, validate impact, then promote critical policies to mandatory enforcement. Continuously map the supplied AWS controls to your internal standards, and supplement any uncovered requirements with custom tfpolicy rules. Finally, treat the attachment point as a policy boundary—use organization‑level sets for universal guardrails and workspace‑level sets for project‑specific constraints.