Policy vs Enforcement

A financial technology vendor had a comprehensive password policy , board-approved, regularly reviewed, aligned to NIST SP 800-63B recommendations. The policy specified a twelve-character minimum length, complexity requirements, prohibition on common passwords, and a ninety-day maximum age for privileged accounts. During a technical security assessment, the assessors tested the actual identity platform configuration against the policy. They found the following: the corporate Azure AD was configured with an eight-character minimum , the configuration had not been updated when the policy was revised two years prior. Complexity was enforced in Azure AD but not in the three legacy application authentication systems that still maintained their own user stores. The ninety-day rotation applied to human accounts in Azure AD but service accounts in the same tenant had no rotation requirement configured. Legacy application service accounts used passwords stored in a shared credential document that had not been updated in fourteen months. Each of these gaps had a common cause: the policy had been updated to reflect security best practices, but the technical configurations that enforced the policy had not been correspondingly updated. The policy described what should be enforced. The configurations described what was enforced. They diverged at every point measured.

What is the Policy vs Enforcement Gap, Really?

Policy versus enforcement is the gap between documented security requirements , the standards, procedures, and guidelines that define how security controls should operate , and the technical and operational mechanisms that actually implement those requirements in running systems. Policies are normative documents: they specify what should be true. Configurations, system settings, and operational procedures are implementing mechanisms: they determine what is true. When policies are updated without corresponding updates to implementing mechanisms, the policy describes an improved security standard that the environment does not enforce.

The policy update lag is the most common source of policy-enforcement gaps. Policies are updated through governance processes , review cycles, framework updates, regulatory guidance changes, or security programme maturation. These processes produce updated policy documents that accurately reflect improved security requirements. The technical configurations that implement those requirements , identity platform password settings, firewall rule sets, encryption configurations, access control matrices , are updated through change management processes that require engineering effort, testing, and deployment. The governance process that produces updated policy documents is typically faster and less resource-intensive than the engineering process that updates technical configurations. The policy advances to the new standard. The configuration lags behind.

The coverage gap problem compounds the update lag. Even policies that are consistently enforced in primary systems frequently have coverage gaps in secondary systems , legacy applications with independent authentication, acquired systems not yet integrated with the corporate standard, development environments operated with different configurations than production, and service account populations governed by different processes than human account populations. A password policy that applies to the corporate identity provider applies to the accounts managed through that provider. It does not apply to accounts in systems outside that provider's scope unless those systems are explicitly governed by corresponding configurations.

• Policy updated without configuration update , revised policy standard not reflected in system configurations
• Legacy system configuration gaps , policy applies to primary systems, legacy applications maintain separate configurations
• Service account policy divergence , human account policy not applied to service account populations
• No policy-to-configuration mapping , policies not explicitly linked to the configurations that implement them
• Configuration audit not performed , actual system configurations not compared against policy requirements

Why this matters

Policy versus enforcement matters for TPRM because vendor security assessments that confirm policy existence are confirming the standard the vendor has documented, not the standard their systems enforce. A vendor with a strong password policy and weak password configurations presents a different security posture than the policy confirmation suggests. The actual security is determined by what the configuration enforces, not by what the policy requires.

The regulatory dimension is explicit and increasingly enforced. Regulators who examine vendors operating in regulated industries will test the configuration against the policy , asking not just 'what does your policy require' but 'what does your system actually enforce, and can you demonstrate that the configuration matches the policy requirement.' A gap between the two , twelve characters in policy, eight in configuration , is a finding that the policy's strength does not mitigate. The control is the configuration, not the document.

Where most teams get this wrong

The most consistent failure is accepting policy documentation as evidence of the security standard in force. Policies describe requirements. Configurations implement requirements. They are different artifacts that require different evidence requests. A password policy document confirms what should be enforced. A configuration export or compliance report confirms what is enforced.

• Accepting policy documentation as implementation evidence
• Configuration audit not included in assessment
• Legacy system coverage not assessed , primary system configuration confirmed, legacy systems not evaluated
• Service account configurations not assessed separately
• Policy-configuration mapping not reviewed , no verification that policies link to specific implementing configurations

What good looks like

Mature policy governance programmes maintain explicit mappings between policy requirements and the implementing configurations, conduct regular configuration audits to verify alignment, and have change management processes that connect policy updates to configuration updates.

• Policy-to-configuration mapping , explicit documentation of which configurations implement which policy requirements
• Configuration audit cadence , regular comparison of actual configurations against policy requirements
• Policy update triggers configuration review , policy changes generate configuration review and update tasks
• Legacy system configuration inventory , configurations in all systems subject to policy documented and periodically audited
• Service account configuration assessment , service account password and credential configurations assessed separately from human accounts

Tooling

Configuration Compliance , AWS Config, Azure Policy, CIS Benchmark Scanners

Configuration compliance tools continuously compare deployed system configurations against defined policy requirements , flagging configurations that do not meet policy standards. CIS benchmark scanners evaluate system configurations against Center for Internet Security hardening standards. For TPRM practitioners, asking whether the vendor uses configuration compliance tools to continuously verify that system configurations match policy requirements provides a specific policy-enforcement alignment question.

Automated Compliance , Drata, Vanta

Automated compliance platforms collect configuration evidence alongside policy documentation , providing the pairing of policy requirements and configuration verification that manual assessment cannot maintain continuously. For TPRM practitioners, asking vendors to provide compliance platform output confirming configuration compliance alongside policy documentation provides both the policy standard and its implementation evidence.

Governance challenges

The governance challenge with policy versus enforcement is the change management discipline required to keep configurations aligned with policies as both evolve. Policy revisions are initiated through governance processes. Configuration changes require engineering effort. The two processes operate on different timelines with different owners, and without explicit connection between them, policy advances while configurations lag.

• Request configuration evidence alongside policy documentation , the actual system settings, not the requirements document
• Ask about legacy system coverage , which systems are in scope for the policy and which have independent configurations
• Ask about service account configuration separately , human and machine account configurations may differ
• Ask when the policy was last updated and when configurations were last audited , the gap between the two is the staleness indicator
• Request compliance tool output rather than policy documents for technical controls

If you are a small team

For your highest-risk vendor, ask for the actual password configuration from their primary identity platform , not the policy document, the configuration export or screenshot showing the minimum password length, complexity requirements, and rotation settings currently enforced. Then ask the same question about their service account configuration. Compare both to their policy document. The gaps between the two are the enforcement gaps that the policy assessment did not surface.

• Request actual password configuration , minimum length, complexity, rotation as enforced
• Ask separately about service account password and credential configurations
• Compare configurations against policy requirements
• Ask about legacy system password configurations

What to require

Ask directly:

"Can you provide the actual password configuration currently enforced on your primary identity platform , specifically, the minimum character length, complexity requirements, and rotation settings as configured in the system, not as specified in your policy?"

"Does your password policy apply to service accounts in the same way as human accounts , and what is the current password configuration for service accounts, including rotation frequency?"

Expect as evidence

• Identity platform configuration showing actual enforced password requirements
• Service account password configuration separately documented
• Legacy system password configuration inventory
• Policy-to-configuration mapping documentation

A vendor who provides a strong password policy should be asked for the configuration that enforces it. The policy is the requirement. The configuration is the reality. A gap between twelve-character policy and eight-character configuration is not resolved by the strength of the policy.

How to evidence it

• Configuration evidence records for key technical controls
• Policy-to-configuration gap assessment records
• Configuration audit records
• Service account configuration assessment

Key Takeaway

The policy governs the standard. The configuration governs the behaviour. They can diverge, and they frequently do when governance processes update policies faster than engineering processes update configurations. The twelve-character policy with an eight-character configuration is not a policy failure , the policy is correct. It is a configuration lag that the policy process did not generate a mechanism to close. Evidence of a strong policy is evidence of a strong requirement. Evidence of the configuration that implements it is evidence of the actual standard enforced. Request both. Accept policy documentation as the specification. Request configuration evidence as the implementation.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations