Policy and configuration are the rules and settings that control how a system behaves. Policy defines the allowed or denied actions, while configuration sets the operational parameters that implement those rules in software, devices, cloud services or identity platforms.
What Policy and Configuration Control
Policy and configuration sit at the point where intent becomes enforcement. Policy expresses the rules, while configuration turns those rules into system behaviour across software, devices, cloud services, and identity platforms.
How Policy and Configuration Work Together
Policy is the decision layer: what is permitted, denied, required, or constrained. Configuration is the implementation layer: the settings, defaults, thresholds, and feature flags that make those decisions real in an operating environment.
In practice, the two must stay aligned. A strong policy with weak or inconsistent configuration creates a false sense of control, while a tightly configured system without a clear policy can become brittle, inconsistent, or difficult to govern at scale.
Where Policy and Configuration Show Up
This term appears across security baselines, access control rules, password and session settings, cloud guardrails, endpoint hardening, and application behaviour. It also shows up in platform administration where a central policy is inherited by many systems and local configuration can either reinforce or override it.
Because policy and configuration often span multiple layers, the same control objective may be implemented differently in different environments. For example, a policy may define the required minimum security posture, while local configuration determines whether that posture is actually enforced on each workload, tenant, or device.
Secure Configuration and Hardening Policy Template is useful here because it shows how approved baselines, hardened images, and exception handling fit into a policy-led configuration model.
Why Policy and Configuration Drift Matters
When policy and configuration diverge, organisations can end up with controls that are documented but not active, or active but not governed. That gap is a common source of security drift, especially when settings are changed manually, inherited inconsistently, or overridden during urgent operational work.
Drift matters because attackers and misconfigurations both exploit the same weakness: the gap between intended control and actual state. Over time, small exceptions, legacy settings, and permissive defaults can accumulate into a materially weaker security posture.
Configuration Drift and Baseline Enforcement Guide helps frame the operational problem of keeping configuration aligned with the intended baseline as environments change.
External references such as NIST SP 800-53 Rev 5 Security and Privacy Controls and CISA Secure by Design both reinforce the need for secure defaults, consistent configuration, and control enforcement rather than policy on paper alone.
Operational Governance for Policy and Configuration
Good governance makes policy decisions explicit, makes configuration choices traceable, and defines who can change either one. The key issue is not only technical correctness, but also ownership: who approves the rule, who implements it, and who verifies that the deployed setting still matches the approved intent.
In mature environments, policy and configuration are treated as living control objects. They are reviewed, versioned, monitored for drift, and updated when the underlying business, threat, or platform changes. That matters most where one policy spans many systems and a single mis-set parameter can create broad exposure.
AWS Security Hub Guide is relevant because it shows how centralised configuration, standards, and automation can be used to maintain policy consistency across cloud environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Policy and configuration directly govern secure baseline settings and drift control. |
| Recommendation — Establish and enforce secure configuration baselines across systems and software. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | This term centers on approved settings and the baseline that policy should enforce. |
| CM-6 — Configuration Settings | Policy is operationalised through specific configuration settings and parameter values. | |
| Recommendation — Define and maintain approved baselines for system and platform configuration. Specify, implement, and monitor required configuration settings for systems and services. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Configuration management under ISO 27001 directly covers controlled secure settings. |
| Recommendation — Control configuration changes and verify that deployed settings remain approved. | ||
| CSA Cloud Controls Matrix | IVS — Infrastructure & Virtualization Security | Cloud and platform configuration are core to secure control implementation. |
| Recommendation — Apply governance over infrastructure settings, hardening, and configuration consistency. | ||
Related resources from NHI Mgmt Group
- How should security teams protect endpoint security configuration when policy settings change unexpectedly?
- What breaks when AI coding tools are left with weak configuration and poor policy controls?
- How should security teams extend identity governance when configuration alone cannot express business-specific policy logic?
- Who should own drift remediation when cloud cost and configuration policy both move out of sync?