Configuration Drift Is a Compliance Problem. Most Teams Discover This at the Worst Possible Time.

What Configuration Drift Actually Means for SOC 2

In infrastructure engineering, "configuration drift" describes the gradual divergence between your documented or intended state and what is actually running in production. A security group gets an inbound rule added during an incident investigation. An S3 bucket policy gets loosened to let a contractor access data. An IAM role picks up an extra policy attachment because someone forgot to scope it properly.

None of these changes necessarily cause an outage. Services keep running. Customers don't notice. The problem surfaces later — and in a SOC 2 context, "later" often means "in front of your auditor during fieldwork."

SOC 2's Common Criteria require that your actual security controls match what you've documented. CC6.6, specifically, covers logical access controls: the requirement that access to data and systems is restricted to authorized individuals and that unauthorized access attempts are detected and addressed. When your AWS security group has an inbound rule that contradicts your network access control policy, you now have an evidence problem — not just a security problem.

The 90-Day Problem: How Drift Accumulates Without Detection

Most teams in early-stage SOC 2 programs run their configuration reviews at the start of audit prep. That means they are reviewing the state of their infrastructure at the moment they start gathering evidence — which could be anywhere from one to three months before the audit period ends.

Consider a common scenario: Your SOC 2 observation period runs from January 1 through December 31. You begin audit prep in late October. When you review your AWS IAM configuration in October, you are looking at what exists in October. But your auditor will ask about changes that occurred throughout the entire year — and they will pull CloudTrail logs to verify.

If a permissive IAM policy was attached in June, used briefly, and then forgotten, your October review won't catch it as a "current" issue. But your CloudTrail record shows it was active for months. That is the drift problem: the gap between your point-in-time review and the actual history your auditor is examining.

CompliRun pulls CloudTrail events, configuration change records from AWS Config, and Okta system log events on a daily basis. Each change is evaluated against the mapped control requirements. A change that opens a gap generates an alert the following morning — not six months later when the auditor asks.

Which Controls Drift Most Often

Based on SOC 2 audit observations, several categories of controls are particularly prone to drift:

Network Access Controls (CC6.6)

Security group rules in AWS and firewall rules in GCP are modified frequently by engineering teams responding to operational needs. A temporary rule added to debug a connectivity issue rarely gets cleaned up. Over time, the gap between your documented network access policy and your actual security group configuration grows. Auditors who pull VPC flow logs or review security group rules against your stated network policy will find these discrepancies.

The fix is daily automated comparison of your actual security group rules against a documented baseline. Any deviation that has not been explicitly approved should generate a gap alert.

IAM Privilege Escalation Paths (CC6.3)

CC6.3 requires that access is appropriately restricted and that privilege escalation is controlled. IAM policies are often expanded incrementally — a developer needs to assume a role, an automation script needs a new permission, a vendor integration requires additional access. Each individual change may be reasonable. The aggregate effect can be an IAM structure with undocumented privilege escalation paths.

AWS IAM Access Analyzer identifies policies that grant external access or allow privilege escalation. CompliRun pulls Access Analyzer findings and maps them directly to CC6.3, flagging any new finding within the daily collection window.

Logging and Monitoring Configurations (CC7.2)

CC7.2 covers the monitoring of security events and the investigation of anomalies. Logging configurations — CloudTrail settings, VPC flow log destinations, CloudWatch alert thresholds — drift in ways that are easy to miss. A CloudTrail trail can be inadvertently disabled. A log group retention period can be shortened. An SNS topic that feeds a security alert can lose its subscription.

These changes don't cause application failures, but they create evidence gaps. If your logging was misconfigured for any portion of the audit period, your auditor may question the completeness of your monitoring coverage.

Encryption Settings (CC6.7)

CC6.7 addresses the protection of data in transit and at rest. Encryption configurations are among the more stable settings in most environments, but they do drift. S3 bucket encryption defaults can be changed. RDS instances can be modified in ways that affect encryption-at-rest status. TLS configurations on load balancers can be updated to add compatibility for older clients — which may not match your stated encryption policy.

Catching Drift with Daily Collection vs. Monthly Reviews

The standard manual approach to configuration review typically involves a monthly or quarterly review of key infrastructure settings. A team member pulls IAM configuration exports, reviews security group rules, and checks logging settings against a checklist. This approach has three significant problems.

First, it is retrospective. By the time you review, drift has already occurred. If the review happens monthly, you may have three to four weeks of gap exposure before detection.

Second, manual reviews are inconsistent. Checklists get missed. The person doing the review may not be familiar with the nuances of a particular control. Evidence quality varies.

Third, manual reviews do not produce continuous evidence. An auditor asking for evidence of your configuration monitoring practices expects to see a consistent pattern — not a collection of one-off screenshots taken before the audit.

Daily automated collection addresses all three problems. CompliRun queries your AWS Config, GCP Asset Inventory, and Okta system logs every 24 hours. Changes are compared against the prior day's state. Deviations from your documented controls are flagged with the specific control reference, the resource identifier, and the nature of the change. Your engineering team sees the alert before it becomes an audit finding.

Building a Drift Evidence Trail That Holds Up

The evidence your auditor needs for configuration monitoring is not just the current state of your infrastructure. It is a history of your infrastructure state, evidence that you detected changes, and documentation of how you responded to changes that created gaps.

This is where the difference between a screenshot-based compliance program and a continuous monitoring program becomes visible in an audit. A screenshot proves the state at one moment. A timestamped daily collection proves that monitoring was active throughout the period — and that when something changed, it was detected.

CompliRun stores each daily configuration snapshot with a UTC timestamp and a cryptographic hash. The evidence room shows auditors not just the current state, but the complete change history for the audit period. For CC6.6, that means a record of every security group change with the date, the resource, and the control impact — not just a screenshot from October.

What to Do When Drift Is Found

When CompliRun flags a configuration drift event, the standard workflow involves three steps: assess the control impact, remediate the drift or document the exception, and close the gap in the evidence record.

Not every drift event is a control failure. A security group rule change may be intentional and compliant with your policy — it just needs to be documented. CompliRun allows you to mark a finding as an approved exception with a justification note, which is attached to the evidence record and visible to the auditor. This is a more defensible position than having no record of the change at all.

For actual non-compliant drift, the remediation task queue in CompliRun includes the specific remediation steps for each control. For CC6.6 security group issues, that means instructions to identify the offending rule, assess whether it was intentional, and either remove it or update the documented policy to reflect the intended state.

As we discussed in our article on how to organize a SOC 2 evidence room, the way you document remediation is as important as the remediation itself. Auditors look for evidence that you have a functioning control environment — which includes detecting gaps and addressing them, not just avoiding gaps in the first place.

ISO 27001 Perspective: A.8.8 and Configuration Management

For organizations pursuing ISO 27001 alongside SOC 2, configuration drift maps to a different but equally important set of controls. ISO 27001:2022 Annex A.8.8 covers the management of technical vulnerabilities, and A.8.9 covers configuration management specifically.

A.8.9 requires that organizations establish, document, implement, monitor, and review procedures for managing configurations of hardware, software, services, and networks. The intent is similar to SOC 2's approach: your actual configuration should match your documented intent, and changes should be controlled and reviewed.

One practical difference is that ISO 27001 emphasizes the configuration management process rather than just the control outcomes. Where SOC 2 asks "does CC6.6 hold true?" ISO 27001 asks "do you have a documented process for managing configurations, and is it followed?" This means your ISO 27001 evidence should include not just configuration snapshots but documentation of your change management process — how changes are reviewed, approved, and logged.

CompliRun maps each configuration change event to both SOC 2 Trust Services Criteria and the relevant ISO 27001 Annex A controls simultaneously. A security group change produces evidence for CC6.6 and A.8.9 in the same collection event, reducing the overhead of maintaining evidence for two frameworks.

The Business Case for Continuous Configuration Monitoring

Setting aside the compliance angle, continuous configuration monitoring has straightforward operational value. Security incidents frequently originate from misconfigured resources — an S3 bucket made public, an overly permissive security group, a service account with excessive privileges. Detecting these within 24 hours instead of months is a meaningful security improvement, not just a compliance checkbox.

The compliance benefit is the business case that often gets teams to act: when you are heading into a SOC 2 audit and need to demonstrate continuous monitoring, the cost of setting up automated configuration collection is much lower than the cost of a delayed or qualified audit opinion. Teams that have gone through the scramble of manual audit prep typically move to continuous monitoring not because they believe in compliance theory, but because they do not want to repeat the experience.

The practical outcome is that compliance becomes a byproduct of a well-monitored infrastructure rather than a separate program that runs parallel to engineering work. Your engineers get faster detection of operational misconfigurations. Your compliance team gets continuous evidence without manual collection. Your auditor gets a clean evidence record that reflects the actual state of your security posture throughout the period — not just on the day someone took a screenshot.