KSI-CNA-EIS—Enforcing Intended State
Formerly KSI-CNA-08
>Control Description
>NIST 800-53 Controls
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express infrastructure resilience through certifications backed by monitoring data — data center tier ratings validated by environmental monitoring dashboards, physical access audit trails, and redundancy architecture that shows actual failover capabilities rather than just design intent.
Data Center Certifications
SOC 2 Type II, ISO 27001 certifications for data center facilities — third-party validated infrastructure controls
Infrastructure Redundancy Architecture
Architecture expressing infrastructure redundancy, failover paths, and geographic distribution
Environmental and Infrastructure Protections
Physical and environmental controls protecting infrastructure — data center tier classification and monitoring metrics
>Programmatic Queries
CLI Commands
terraform plan -detailed-exitcodeterraform state list | wc -lterraform plan -no-color | tail -5>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does automated intended-state enforcement cover all machine-based resource types — VMs, containers, Kubernetes pods, serverless functions, managed services, and network configurations?
- •Are there resources where intended state is defined but not automatically enforced, and how are those exceptions justified and tracked?
- •How do you define intended operational state for ephemeral resources that are created and destroyed rapidly (spot instances, auto-scaled pods)?
- •When a new resource type is introduced, what process ensures its intended state is defined and enforcement is configured before production deployment?
Automation & Validation:
- •What happens when IaC drift detection identifies a resource has deviated from intended state — is it automatically remediated, flagged, or quarantined?
- •How do you prevent automated enforcement from causing availability issues — for example, reverting a legitimate emergency change?
- •What is the maximum time between a resource drifting from intended state and automated detection, and what is the SLA for remediation?
- •How do you test that enforcement mechanisms actually correct drift rather than just reporting it — do you run chaos engineering or fault injection tests?
Inventory & Integration:
- •What tools compose your intended-state enforcement stack (AWS Config, Azure Policy, Kubernetes admission controllers, CSPM), and how do they coordinate?
- •How do intended-state definitions integrate with your IaC repository so that the source of truth is version-controlled code?
- •Are enforcement results from different tools aggregated into a single compliance dashboard, or do they require separate review?
- •How does your drift detection integrate with your SIEM or incident management to escalate persistent or malicious drift?
Continuous Evidence & Schedules:
- •How do you demonstrate that intended-state assessment and enforcement runs continuously rather than on a batch schedule?
- •Is drift detection and enforcement data available via API for assessors to verify in real time?
- •What metrics show mean time to detect drift and mean time to remediate drift over the past 90 days?
- •How do you prove that enforcement coverage has not degraded — that newly deployed resources are always included in posture assessment?
Update History
Ask AI
Configure your API key to use AI features.