What is the difference between using built-in policies and bringing your own OPA rules for IaC governance?

Built-in policies provide vendor-maintained controls, while bring your own OPA rules preserve customer-authored logic already approved by the organisation. The difference is not capability alone, but control ownership and migration effort. Many teams need both, using built-in rules for standard coverage and custom Rego for organisation-specific requirements.

Why This Matters for Security Teams

Built-in policy packs and customer-authored OPA rules solve different governance problems, and security teams that blur them usually end up with either excessive vendor dependence or brittle exception handling. For IaC governance, the real question is whether the control logic should be owned by the platform vendor or by the organisation’s policy team. NHIMG’s Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both point to the same operational reality: policy must be enforceable, reviewable, and aligned to risk.

Built-in controls are useful when teams need fast coverage for common misconfigurations, but they often encode a vendor’s assumptions about resource types, severity thresholds, and remediation paths. BYO OPA rules preserve organisational intent, especially where security architecture, legal obligations, or exception workflows differ from the default model. That is why many mature programs use built-ins for baseline prevention and Rego for policy decisions that need explicit business context. In practice, many security teams discover the mismatch only after a platform migration exposes gaps in controls they assumed were already standardized.

How It Works in Practice

Built-in policies are usually packaged with the IaC tool, scanner, or cloud governance platform. They are designed to be easy to enable, simple to update, and broad enough to catch common risks such as public storage, open security groups, or missing encryption. Their advantage is speed: teams can adopt them with little implementation effort and benefit from vendor-maintained rule updates. The tradeoff is that built-ins rarely reflect the full organisation policy set, especially where one control needs different treatment across environments, subsidiaries, or regulated workloads.

Bringing your own OPA rules means authoring policy in Rego, or feeding equivalent policy logic into an OPA-compatible pipeline, so governance decisions follow customer-defined rules at evaluation time. This is often the better fit when policy must reference internal exception lists, asset classifications, data residency, or specific approval states. OPA also gives teams a clearer separation between policy logic and enforcement point, which helps with change control and auditability. The NIST SP 800-53 Rev. 5 Security and Privacy Controls supports that kind of control mapping, while NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows how often identity and governance gaps remain unresolved in real environments.

• Use built-in policies for standard, high-volume checks that should remain aligned to vendor updates.
• Use BYO OPA rules when policy must encode internal exceptions, legal constraints, or environment-specific logic.
• Keep policy-as-code versioned, peer reviewed, and tested like application code.
• Map each rule to an approved control objective so auditors can trace intent to enforcement.

This guidance breaks down when infrastructure estates span multiple tools with inconsistent policy engines, because rule parity and exception handling become difficult to maintain across platforms.

Common Variations and Edge Cases

Tighter policy customization often increases operational overhead, requiring organisations to balance governance precision against maintenance cost. That tradeoff is why there is no universal standard for whether built-ins or BYO OPA should dominate; current guidance suggests choosing the smallest policy surface that still satisfies risk, audit, and exception requirements. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is helpful here because audit teams usually care less about where the rule came from and more about whether the rule is defensible, versioned, and consistently applied.

Hybrid models are common. Teams may keep vendor built-ins enabled for broad coverage, then layer OPA for higher-risk controls such as production guardrails, approved exception lists, or sensitive data paths. This is often the right pattern when security, platform engineering, and compliance all need different levels of control ownership. The main edge case is inherited policy debt during migration: a platform may claim parity with prior controls, but subtle differences in severity scoring, resource matching, or evaluation order can change outcomes. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that governance works best when controls are managed across their full lifecycle, not just at deployment time.

Where governance is heavily regulated or exception-heavy, built-ins alone rarely provide enough evidence for audit, while BYO rules without disciplined testing can become opaque and hard to trust.

Related resources from NHI Mgmt Group

• What is the difference between embedding certification reviews in a service management platform and using a separate identity governance portal?
• What is the difference between attack surface management and NHI governance?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?