Dax Okafor had eleven days until his Type II fieldwork closed, and one open sample was going to blow the whole audit.
Dax was VP of Infrastructure at Cascade Ledger, a mid-market payments orchestration platform that routed roughly $900 million a year in transaction volume for 340 mid-size merchants. Cascade's single biggest prospect — a national retail chain worth $3.1 million in first-year contract value — had made a clean SOC 2 Type II report a signed condition of the deal. No report, no contract. The retailer's own vendor risk team had said as much in writing.
The auditor, a meticulous second-year senior at a regional CPA firm, had pulled a sample of twenty production firewall rule changes from the twelve-month observation window. Nineteen had a Jira ticket, a peer-reviewed pull request, and a Terraform plan output attached. The twentieth — a rule opened eight months earlier to let a new payment gateway reach an internal API — had none of that. An engineer, under pressure during an on-call incident, had SSH'd into the firewall appliance and hand-typed the change to stop a cascading failure at 2:14 a.m. It worked. Nobody wrote it down. Nobody rolled it into the infrastructure-as-code repository afterward. Six months later, nobody remembered it existed until the auditor found it sitting open in production with no ticket, no approver, and no record of who made it or why.
That single unlogged rule change didn't just risk a control exception. It threatened to unravel the entire CC7.1 and CC8 testing population, because if one change bypassed the tracked pipeline, the auditor now had to ask how many others did too. Dax spent the next eleven days doing what should have been a five-minute config diff: reconstructing a paper trail for a change nobody had planned to write down.
This is the article I wish Dax had read a year earlier. Configuration management is one of the quietest, most under-resourced corners of a SOC 2 program — and one of the most consistently cited sources of exceptions I see in Type II reports. It sits at the intersection of two Common Criteria: CC7.1, which covers how you detect and correct configuration deviations that could compromise system security, and CC8, which governs how you authorize, test, approve, and track changes to infrastructure and software. Get it right, and it becomes some of the easiest, most automatable evidence in your whole audit. Get it wrong, and every hand-typed change becomes a landmine waiting for a sample to land on it.
Who this is for, and what you'll walk away with
This is written for infrastructure leaders, DevOps and platform engineers, security engineers, and compliance managers who are building or maturing a SOC 2 program and need configuration management to actually hold up under audit — not just look good in a policy document. You should already have a basic grasp of your Trust Services Criteria scope; if you need that foundation first, start with our complete guide to the AICPA Trust Services Criteria.
By the end, you'll have a working model for secure baselines and hardening standards (including how CIS Benchmarks actually get used in practice, not just cited), a defensible asset and configuration inventory, an infrastructure-as-code and GitOps approach that doubles as your change evidence, a real drift-detection program, and a clear map of exactly what an auditor will ask to see — with sample tables and templates you can adapt this week.
Where configuration management sits inside SOC 2
Configuration management doesn't have its own dedicated Trust Services Criterion the way access control or risk assessment do. Instead, it's stitched across two Common Criteria series that auditors test together because they're operationally inseparable.
CC7.1 sits inside the System Operations criteria series and is where auditors look for evidence that the organization uses baseline configurations for its infrastructure and monitors systems for deviations from that baseline that could introduce vulnerabilities. This is the "did you define what 'secure' looks like, and do you know when something drifts away from it" criterion. CC8, the Change Management series, is where auditors test whether changes to infrastructure, data, and software are authorized, designed, developed, configured, documented, tested, approved, and implemented in a controlled way before they reach production.
The table below shows how these two criteria typically get tested together in a configuration management context — this is the mental model to build your program around before you buy a single tool.
Table 1: CC7.1 and CC8 — what each is actually testing in a configuration management context
Criterion | What it's testing | Typical configuration management evidence |
|---|---|---|
CC7.1 | Baseline configurations exist and deviations are detected | Hardening standards, CIS Benchmark scan results, drift detection reports |
CC7.1 | Vulnerabilities from misconfiguration are identified | CSPM findings, configuration scan tickets, remediation SLAs |
CC8.1 | Changes are authorized before development/configuration | Change request tickets, approval workflow logs |
CC8.1 | Changes are designed and documented | Architecture notes, pull request descriptions, IaC diffs |
CC8.1 | Changes are tested before deployment | CI pipeline test results, staging validation logs |
CC8.1 | Changes are approved prior to implementation | Peer review / approver sign-off (e.g., pull request approval) |
CC8.1 | Changes are tracked and traceable | Version control history, ticket-to-commit linkage, deployment logs |
CC8.1 | Emergency changes follow a defined (if abbreviated) process | Emergency change log, retroactive approval records |
Notice that configuration management is really the infrastructure and system-state half of change management, applied continuously — not a one-time project. A hardened baseline that nobody monitors for drift is a document, not a control. An IaC pipeline that nobody actually uses for real production changes is theater, not evidence.
Configuration management vs. change management: where the line actually is
I get asked constantly whether configuration management and change management are the same control area with two names. They're not, and the distinction matters both for how you build your program and for how you'll be tested.
Change management (CC8, broadly) is the process discipline: how any change — a code deployment, a new feature, a database schema update, a third-party integration, a config change — gets requested, reviewed, approved, tested, and released. It's process-first and applies to software and infrastructure alike.
Configuration management (mostly CC7.1, feeding into CC8) is narrower and state-first: it's about the desired state of your systems — server hardening settings, firewall rules, IAM policies, container base images, database parameters — and whether the actual state matches that desired state at any given moment, with a record of how and why it diverged when it did. Configuration management asks "what should this system look like, and does it still look like that?" Change management asks "was this change to the system properly authorized and controlled?"
In practice they overlap constantly, because most configuration changes are also changes subject to CC8's approval and tracking requirements. But you can have excellent change management and still fail configuration management — for example, a team that runs a disciplined pull-request-and-approval process for application code deployments but has no baseline at all for how its servers, Kubernetes clusters, or firewalls should be configured, and no way to detect when someone (or some automation) quietly changes a setting outside that process.
Table 2: Configuration management vs. change management, side by side
Dimension | Configuration Management | Change Management |
|---|---|---|
Primary SOC 2 criterion | CC7.1 (with CC8 overlap) | CC8 |
Core question | Does the system match its defined secure baseline? | Was this change authorized, tested, and approved? |
Unit of work | System/infrastructure state | A discrete change event |
Detects | Drift — unauthorized or unintended deviation | Unauthorized or untested releases |
Primary evidence | Baseline docs, scan reports, drift alerts | Tickets, approvals, test results, deployment logs |
Typical tooling | CIS-CAT, CSPM, Ansible/Chef/Puppet, Terraform state | Jira/ServiceNow, CI/CD pipelines, GitHub/GitLab |
Related PentesterWorld article | This article |
If you're building both programs simultaneously — which is the right way to do it — treat configuration management as the state layer underneath change management's process layer. Every configuration baseline needs a change process to update it; every change process needs a configuration baseline to compare against. Our companion piece on SOC 2 system configuration and hardening goes deeper on how to write the hardening standards themselves; this article focuses on tracking those configurations, detecting drift, and producing evidence over the full observation period.
Why this control area produces so many audit exceptions
I've sat through more Type II fieldwork than I can count, and configuration management is consistently in the top three sources of exceptions, alongside access reviews and vendor management. There's a specific reason: it's the control area most likely to have a gap between "what we documented" and "what we actually do under pressure."
Access control failures usually come from process gaps — someone forgot to run an offboarding checklist. Configuration management failures come from a different place: engineers making legitimate, often correct, often urgent changes outside the system that's supposed to record them. Dax's 2:14 a.m. firewall rule is the textbook case. Nobody was being negligent. Someone was fixing a live incident, and the tooling that should have captured the change — either automatically or through a fast-tracked emergency process — didn't exist or wasn't used.
"The exceptions I write up almost never come from a team with no process. They come from a team with a great process that has one undocumented escape hatch — usually root SSH access to something that's supposed to be managed entirely through code. Auditors don't need to find that hatch every time. We just need to find it once in the sample." — Renata Sousa-Klein, Principal SOC 2 Auditor, Bristow & Yale CPAs
A second, quieter reason configuration management produces exceptions: organizations conflate "we have a hardening standard" with "we enforce and monitor a hardening standard." A PDF hardening checklist from three years ago that nobody has re-validated against current CIS Benchmark versions is worse than having no checklist, because it creates a false sense that the control exists. Auditors will ask for the last time the baseline was reviewed, who approved it, and what evidence shows current systems are actually measured against it — not just that the document exists in a policy binder.
Table 3: The most common configuration management exceptions I see in Type II fieldwork
Exception pattern | Root cause | Fastest fix |
|---|---|---|
Sampled change has no ticket/approval | Out-of-band manual change during incident | Formal emergency change process with retroactive logging |
Baseline document exists but is outdated | No review cadence tied to CIS Benchmark releases | Annual baseline review tied to a calendar control owner |
Drift detected but no remediation evidence | Drift alerts generated, nobody owns closing them | Assign drift alerts an SLA and a ticket queue, like vulnerabilities |
Inventory doesn't match production reality | Asset inventory manually maintained, goes stale | Auto-discovery feeding the inventory from cloud/IaC APIs |
IaC repo exists, but console changes still happen | No guardrails preventing manual console edits | Restrict production write access; enforce IaC-only deploys |
Config change approved by the person who made it | No segregation of duties in the approval workflow | Require a second, independent approver in the pipeline |
Step one: build and document secure baselines
Everything downstream — drift detection, change tracking, evidence — depends on having an actual, specific, versioned answer to the question "what does a correctly configured system look like here?" That answer is your secure configuration baseline (sometimes called a hardening standard), and it needs to exist for every asset class in scope: servers and VMs, containers, databases, network devices, cloud account settings, SaaS admin consoles, and endpoints.
A baseline that says "harden all servers per best practices" is not a baseline. A usable baseline specifies concrete, testable settings: disable password authentication over SSH, require key-based auth, disable unused services, enforce a minimum TLS version, set specific audit logging parameters, restrict root/administrator login, apply specific file permission settings on sensitive directories. The test for whether your baseline is audit-ready is simple: could an engineer who has never seen your environment run a scan against it and get a pass/fail result for every line item? If not, it's a philosophy, not a standard.
The overwhelming majority of organizations I work with don't write hardening baselines from scratch — they adopt an industry standard and tailor it. That's the right move, and it's also what auditors expect to see referenced, because it demonstrates the baseline reflects independent, widely-vetted security guidance rather than one engineer's opinion.
CIS Benchmarks in practice
The Center for Internet Security (CIS) Benchmarks are the most widely adopted hardening reference in SOC 2 audits I encounter, covering operating systems (Windows, Linux distributions), cloud platforms (AWS, Azure, GCP), containers and Kubernetes, databases, and common applications. Each benchmark defines specific configuration recommendations, typically organized into profile levels that trade off security rigor against operational impact.
Table 4: CIS Benchmark profile levels, explained
Profile | What it means | Typical use case |
|---|---|---|
Level 1 | Practical, minimizes impact on system usability/performance | Baseline for most production systems |
Level 2 | Defense-in-depth, may impact functionality or performance | High-sensitivity environments (payment processing, regulated data) |
STIG variant (where applicable) | Aligned to DoD Security Technical Implementation Guides | Government/defense-adjacent environments |
Most SOC 2 organizations I advise land on CIS Level 1 as their baseline for general production infrastructure, with Level 2 applied selectively to systems handling payment data, health data, or other elevated-sensitivity workloads. That tiering decision itself should be documented — auditors will ask why you chose the profile you did, and "we picked whichever one our scanning tool defaulted to" is not a satisfying answer.
Table 5: Where CIS Benchmarks typically get applied across a SOC 2 environment
Asset class | Example CIS Benchmark | Common scanning tool |
|---|---|---|
Linux servers | CIS Distribution Independent Linux / Ubuntu / RHEL | CIS-CAT Pro, OpenSCAP, Lynis |
Windows servers | CIS Microsoft Windows Server Benchmark | CIS-CAT Pro, Microsoft Defender for Cloud |
AWS account/services | CIS Amazon Web Services Foundations Benchmark | AWS Config, Prowler, CSPM tools |
Azure | CIS Microsoft Azure Foundations Benchmark | Microsoft Defender for Cloud, CSPM tools |
GCP | CIS Google Cloud Platform Foundation Benchmark | Security Command Center, CSPM tools |
Kubernetes | CIS Kubernetes Benchmark | kube-bench, CSPM tools |
Docker | CIS Docker Benchmark | Docker Bench for Security |
Databases | CIS benchmarks for MySQL, PostgreSQL, MongoDB | Native audit tools, CSPM |
I typically recommend logging the specific CIS Benchmark version and profile level applied to each asset class inside the baseline document itself — CIS updates benchmarks regularly, and auditors increasingly ask when you last reconciled your baseline against the current published version.
Beyond CIS: cloud, container, and SaaS baselines
CIS Benchmarks cover the technical substrate well, but a complete configuration management program also needs baselines for things CIS doesn't fully address: SaaS administrative console settings (your identity provider's session timeout policy, your code repository's branch protection rules, your cloud storage bucket's default access policy), and internal application-specific configuration (feature flags with security implications, API rate limits, encryption settings for application-managed data). These deserve the same rigor — a written standard, a testable pass/fail state, and a named control owner — even though no external benchmark exists for them.
"The CIS Benchmark gets you maybe 70% of the way for infrastructure. The other 30% — your SSO session policy, your storage bucket defaults, your CI/CD runner permissions — nobody hands you a benchmark for that. You have to write it yourself, and that's usually the part that's missing when I do a gap assessment." — Marcus Chen, Director of Security Engineering, Loomstack
Golden images and hardened templates
The most efficient way to make a baseline stick is to bake it into a golden image — a pre-hardened VM image, container base image, or infrastructure module that new systems are provisioned from, rather than hardened after the fact. This flips the economics of configuration management: instead of scanning every new server after deployment and remediating findings, you start every deployment from a known-good state and only need to detect deviation from it afterward.
Table 6: Golden image approach vs. post-deployment hardening
Dimension | Golden image / hardened template | Post-deployment hardening |
|---|---|---|
When hardening happens | Before first boot | After deployment, reactively |
Consistency across fleet | High — every instance starts identical | Variable — depends who ran the script and when |
Audit evidence | Image build pipeline + version tag | Individual scan-and-remediate tickets per host |
Effort at scale | Front-loaded, then low marginal cost | Recurring cost per new system |
Drift risk | Lower — deviation is easier to spot against a known start state | Higher — no consistent starting point to compare against |
Cascade Ledger, after its firewall incident, moved to exactly this model: a hardened image pipeline rebuilt weekly against the latest CIS Level 1 Ubuntu benchmark, with every production instance required to trace back to a tagged image version. That single change turned "prove this server is hardened" from a manual scan-and-screenshot exercise into a one-line query against the image tag.
Step two: build a real asset and configuration inventory
You cannot detect drift, track changes, or produce evidence for a system you don't know exists. An asset and configuration inventory — often called a configuration management database, or CMDB — is the foundation everything else in this article sits on top of, and it's also one of the first things an auditor asks for: a complete list of in-scope systems, with enough detail to understand what each one is, what it runs, who owns it, and what its expected configuration state should be.
The mistake I see most often isn't a missing inventory — it's a stale one. A spreadsheet maintained by hand, updated when someone remembers, drifting further from reality every sprint. Auditors test this directly: they'll ask for your asset inventory, then independently pull a live list from your cloud provider or infrastructure tooling, and compare. A meaningful gap between the two is an automatic finding, because it demonstrates the inventory isn't a reliable source of truth for anything downstream.
Table 7: Minimum fields for a SOC 2-defensible configuration inventory
Field | Why it matters to an auditor |
|---|---|
Asset identifier (hostname, resource ID) | Unique reference for sampling and tracing |
Asset type/class | Determines which baseline/hardening standard applies |
Environment (production, staging, dev) | Scoping — most controls focus on production |
Owner (team or named individual) | Accountability for remediation |
Data sensitivity/classification | Determines whether elevated hardening (e.g., CIS Level 2) applies |
Baseline/hardening standard applied | Links the asset to its expected configuration state |
Last configuration scan date | Evidence of ongoing CC7.1 monitoring |
Source of truth (IaC module, image tag) | Traces the asset back to its authorized definition |
In-scope for SOC 2? (Y/N) | Confirms boundary alignment with your system boundary |
The most durable fix for inventory staleness is to stop maintaining it by hand at all. Auto-discovery — pulling live inventory from your cloud provider's resource APIs, your infrastructure-as-code state files, and your container orchestration platform — keeps the inventory synchronized with reality by construction rather than by diligence. Several CSPM and asset management tools do this natively; even a scheduled script that queries your cloud APIs and reconciles against your inventory weekly is a substantial improvement over manual updates.
"Every readiness engagement starts the same way: I ask for the asset inventory, and I get a spreadsheet last touched two quarters ago. Once we replace it with something the cloud APIs populate automatically, half the other findings in the engagement quietly disappear, because you can't fix drift on a system you didn't know you had." — Aisha Bello-Fitzgerald, Compliance Lead, Nordbridge Health Analytics
Step three: manage configuration through code
The single most effective structural change I recommend to clients struggling with configuration management is moving configuration out of consoles and runbooks and into version-controlled code — infrastructure as code (IaC). When your servers, networks, IAM policies, and cloud resources are defined in Terraform, CloudFormation, Pulumi, or a configuration management tool like Ansible, Chef, or Puppet, the configuration itself becomes the evidence. A pull request is a change ticket. A merge is an approval record. A commit history is an audit trail that nobody has to reconstruct by hand.
This matters enormously for CC8 testing because it collapses two separate evidentiary burdens — "prove the change was approved" and "prove the resulting configuration matches what was approved" — into a single artifact. The auditor can trace a production security group directly back to the Terraform module that defines it, back to the pull request that changed it, back to the approver who signed off. That's a fundamentally stronger evidence chain than a change ticket that describes an action taken manually somewhere else.
Table 8: IaC and configuration management tool landscape
Tool category | Examples | Primary use | What it contributes as SOC 2 evidence |
|---|---|---|---|
Declarative infrastructure provisioning | Terraform, Pulumi, AWS CloudFormation | Defining cloud resources as code | Diffable plan/apply output tied to a commit and PR |
Configuration management (host-level) | Ansible, Chef, Puppet, SaltStack | Enforcing OS-level settings on running hosts | Run logs showing convergence to defined state |
Container/image build | Packer, Docker, Buildah | Building golden images and container base images | Build pipeline logs, image digest/version tags |
Kubernetes manifests/policy | Helm, Kustomize, OPA/Gatekeeper, Kyverno | Defining and enforcing cluster configuration | Policy-as-code enforcement logs, admission denials |
Version control | Git (GitHub, GitLab, Bitbucket) | Source of truth and change history | Commit history, PR approvals, branch protection logs |
Secrets/config management | HashiCorp Vault, AWS Secrets Manager, SOPS | Managing sensitive configuration values | Access logs, rotation history |
Adopting IaC isn't free, and I'm careful not to oversell it to clients who are mid-migration: legacy systems, acquired infrastructure, and vendor-managed appliances often can't be fully expressed as code, and that's fine — it just means those assets need a compensating configuration-tracking mechanism (scheduled scans, manual change logs with the same rigor) rather than being quietly excluded from scope.
GitOps as the audit trail
GitOps takes the IaC model one step further: instead of engineers running terraform apply from their laptops, a pipeline automatically reconciles the live environment against whatever is merged into a designated branch, and — critically — production is configured to reject changes that didn't come through that pipeline. This is the single strongest control I know of for closing the "manual console change" gap that caused Cascade Ledger's incident, because it doesn't just document changes better; it structurally prevents undocumented ones from persisting.
"Once we moved to GitOps and locked down console write access to break-glass only, our change sample pass rate went from something like 85% to 100% in two audit cycles. Not because our engineers got more disciplined — because the path of least resistance became the compliant path." — Tomasz Wieczorek, Site Reliability Engineering Manager, Ferrovia Logistics
Table 9: Manual configuration changes vs. GitOps-managed changes
Dimension | Manual / console-driven changes | GitOps-managed changes |
|---|---|---|
Where the change originates | Cloud console, SSH session, admin panel | Pull request against an IaC repository |
Approval mechanism | Verbal, Slack message, or none | Required PR review/approval before merge |
Record of who/what/when | Cloud provider audit log only (if enabled) | Git commit history + cloud audit log, cross-referenced |
Drift risk | High — live state can diverge from any documentation | Low — pipeline continuously reconciles state to the repo |
Rollback | Manual, often undocumented |
|
Auditor sampling experience | Reconstructive, time-consuming | Direct trace from resource to commit to approver |
GitOps doesn't eliminate the need for an emergency change process — incidents will always require fast, sometimes out-of-band action — but it does mean the default path for 95%+ of changes produces its own evidence automatically, which shrinks the emergency-change population an auditor needs to test manually.
Step four: detect configuration drift
Configuration drift is what happens when a system's live state diverges from its documented, approved baseline — whether through a manual change, an automated process behaving unexpectedly, a failed deployment that partially applied, or simple entropy as dependencies update themselves over time. Drift is not inherently a policy violation; sometimes it's a legitimate emergency fix that hasn't been reconciled back into code yet, as with Dax's firewall rule. What makes drift a control failure isn't that it happens — it's that it happens silently, without detection or a remediation record.
Even organizations with strong IaC adoption experience drift. Someone with console access fixes something at 2 a.m. and forgets to open a follow-up PR. An auto-scaling event provisions a resource from a slightly stale image. A third-party integration modifies a setting through its own API access. A well-designed configuration management program assumes drift will happen and builds the detection and remediation loop as a first-class, permanent process — not a one-time cleanup project before the audit.
Table 10: How configuration drift typically happens
Drift source | Example | Detection method |
|---|---|---|
Manual emergency change | Console-based firewall rule during an incident | Cloud audit log diff against IaC state |
Partial/failed deployment | Pipeline run fails halfway, leaves inconsistent state | CI/CD pipeline failure alerts + post-deploy state check |
Auto-scaling from stale image | New instances provisioned from an outdated golden image | Image version check against current approved tag |
Third-party/API-driven change | SaaS integration modifies a setting via its own permissions | Periodic configuration export and diff |
Local/host-level drift | Package manager auto-updates a dependency outside the pipeline | Host-level configuration management agent (Ansible/Chef check mode) |
Human error in the pipeline itself | Engineer merges an unreviewed change to a shared module | Branch protection + mandatory review enforcement |
Table 11: Drift detection tooling by layer
Layer | Tooling examples | Detection cadence |
|---|---|---|
Cloud account/resource configuration | AWS Config, Azure Policy, GCP Security Command Center, CSPM platforms (Wiz, Prisma Cloud, Orca) | Continuous / near-real-time |
IaC state reconciliation |
| Daily or on a defined schedule |
Host-level configuration | Ansible in check mode, Chef InSpec, Puppet noop runs | Daily |
Kubernetes cluster state | OPA/Gatekeeper, Kyverno policy reports, kube-bench | Continuous (admission control) + scheduled scans |
Benchmark/hardening compliance | CIS-CAT Pro, OpenSCAP, Qualys, Tenable | Weekly to monthly |
The cadence matters as much as the tool. A drift check that runs once a quarter, right before the audit, tells the auditor exactly what it looks like: a compliance exercise, not an operational control. Continuous or daily drift detection, feeding into a ticket queue with an SLA, is what demonstrates CC7.1 is a living monitoring process rather than a pre-audit fire drill.
"I ask every client the same question in the readiness call: when drift is detected, does a human ever see it, or does the report just sit in a dashboard nobody checks? Detection without a ticket and an owner is the same as no detection, from an audit-evidence standpoint." — Priya Natarajan, CISO, Havenmark Financial
Step five: track and approve configuration changes
Detection is half the loop. The other half is a defensible record of every configuration change — planned or emergency — that shows what changed, who authorized it, when it happened, and how it was verified. This is where configuration management hands off directly to CC8 change tracking, and where most of your Type II sample testing will actually happen.
A configuration change log, at minimum, should capture: the asset affected, the specific setting changed (before and after values where feasible), the requester, the approver (who must not be the same person, to preserve segregation of duties), the ticket or pull request reference, the date implemented, and — critically — the date it was reconciled back into the source-of-truth (the IaC repository or configuration management tool), if it wasn't made through that pipeline in the first place.
Table 12: Anatomy of a defensible configuration change record
Field | Purpose |
|---|---|
Change ID / ticket reference | Links to the request and business justification |
Asset(s) affected | Ties the change to a specific inventory entry |
Change type (standard, emergency, routine) | Determines which approval path applies |
Requested by | Accountability for the change request |
Approved by (independent of requester) | Evidence of segregation of duties |
Description of change (before/after state) | What auditors will compare against the live system |
Test/validation evidence | Confirms the change didn't introduce a new risk |
Implementation date/time | Places the change within the observation period |
Reconciled to IaC/source of truth? (Y/N, date) | Closes the loop for changes made out-of-band |
Emergency and out-of-band changes
Every organization I've worked with, without exception, needs a legitimate emergency change path — incidents don't wait for a two-day review cycle. The mistake isn't having an emergency path; it's not having one at all, which pushes engineers toward silent, undocumented workarounds like the one that nearly cost Cascade Ledger its retail contract. A well-designed emergency change process has a lighter-weight approval (often a single on-call lead rather than a full review board), but it still requires retroactive documentation and reconciliation within a defined window — I typically recommend 24 to 72 hours — after which the change is either formally approved after the fact, rolled back, or captured permanently in the IaC baseline.
Table 13: Standard vs. emergency change process
Element | Standard change | Emergency change |
|---|---|---|
Approval timing | Before implementation | Before or immediately after (defined window) |
Approver | Peer review + designated approver | On-call lead or incident commander |
Testing | Pre-production validation required | Post-implementation validation, if pre-testing isn't feasible |
Documentation | Filed with the change | Filed retroactively within 24–72 hours |
Reconciliation to IaC | Change originates in IaC | Must be reconciled back into IaC/baseline afterward |
Audit sample expectation | Ticket, approval, test evidence, deployment log | Same, plus incident reference and reconciliation record |
Auditors are not surprised to see emergency changes in a sample — production incidents happen everywhere. What draws scrutiny is an emergency change with no retroactive documentation, or one that was never reconciled back into the baseline, because six months later it looks exactly like Cascade Ledger's orphaned firewall rule: a change nobody can explain.
Cloud configuration management and CSPM
For organizations running primarily in AWS, Azure, or GCP — which describes most of the SaaS companies I work with — cloud configuration management deserves its own callout, because the attack surface here moves fast and the blast radius of a single misconfigured setting (a public storage bucket, an overly permissive IAM role, an unencrypted database snapshot) can be enormous.
Cloud Security Posture Management (CSPM) tools continuously evaluate your cloud accounts against a defined benchmark (typically CIS Benchmarks plus vendor-specific best practices) and flag deviations in near real time. This is, functionally, drift detection purpose-built for cloud environments, and it's rapidly become the default expectation auditors have for any organization with meaningful cloud infrastructure in scope.
Table 14: What a CSPM policy set typically checks
Policy category | Example check | Why it matters |
|---|---|---|
Identity and access | No IAM users/roles with unused admin privileges | Enforces least privilege at the account level |
Storage | No publicly readable/writable storage buckets | Prevents accidental data exposure |
Encryption | Encryption at rest enabled on all data stores | Confirms confidentiality commitments are technically enforced |
Network | No security groups open to 0.0.0.0/0 on sensitive ports | Reduces exposed attack surface |
Logging | CloudTrail/activity logging enabled account-wide | Ensures the audit trail itself can't be silently disabled |
Secrets | No hardcoded credentials in resource configuration | Prevents credential leakage through misconfiguration |
CSPM findings should feed the same remediation workflow as vulnerability findings — a ticket, an owner, an SLA, and evidence of closure — rather than living only in a dashboard. Our article on SOC 2 vulnerability management covers that remediation-tracking discipline in more depth; the mechanics translate directly to configuration findings.
Container and Kubernetes configuration hardening
Container platforms introduce a configuration layer most legacy hardening standards were never written for, and auditors in DevOps-heavy environments increasingly ask about it directly. Kubernetes in particular has a large, easy-to-misconfigure surface: role-based access control (RBAC) bindings, network policies, pod security standards, and admission control all need explicit baselines.
Table 15: Kubernetes/container hardening baseline elements
Area | Baseline expectation | Common misconfiguration |
|---|---|---|
Pod security | Non-root containers, no privileged mode, read-only root filesystem where possible | Privileged containers left enabled from early development |
RBAC | Namespace-scoped roles, no cluster-admin for routine workloads | Service accounts granted cluster-admin for convenience |
Network policy | Default-deny between namespaces, explicit allow rules | No network policies defined — flat, fully-open cluster network |
Image provenance | Images built from approved base images, scanned before deploy | Images pulled from unverified public registries |
Secrets handling | Secrets injected via a secrets manager, not baked into manifests | Secrets committed in plaintext to Kubernetes YAML |
Admission control | Policy-as-code (OPA/Gatekeeper, Kyverno) blocking non-compliant deploys | No enforcement — bad configs reach production silently |
Admission control is worth calling out specifically because it changes drift detection from reactive to preventive: instead of finding a privileged container running in production during a weekly scan, a policy engine refuses to schedule it in the first place. That's the container-world equivalent of the golden-image approach for VMs — bake the baseline into the deployment gate rather than checking for it after the fact.
Network device and endpoint configuration management
Not every SOC 2 environment is fully cloud-native. Organizations with on-premises data centers, physical network appliances, or a substantial endpoint fleet need configuration management for those asset classes too, and the tooling looks different from the cloud-native stack above.
Table 16: Network device and endpoint configuration management approaches
Asset class | Baseline source | Configuration tracking approach |
|---|---|---|
Firewalls/routers/switches | CIS Network Device Benchmarks, vendor hardening guides | Config backup + diff tooling (e.g., Oxidized, RANCID), change tickets for manual CLI changes |
Load balancers | Vendor hardening guides, internal TLS/cipher standard | Config export and version control, scheduled diff against baseline |
Laptops/workstations | CIS Benchmarks for the OS, internal endpoint standard | Mobile device management (MDM) enforced policies, compliance dashboards |
VPN/remote access gateways | Vendor hardening guides | Centralized policy management, periodic configuration export |
IoT/specialized hardware | Vendor guidance, compensating controls where hardening is limited | Network segmentation, monitoring in lieu of full hardening |
Where full automation isn't feasible — an aging firewall appliance without a robust API, for instance — the fallback is a disciplined manual process: scheduled configuration exports, a maintained diff history, and change tickets for every manual edit. It's more labor-intensive than a GitOps pipeline, but it's still auditable, which is the bar that actually matters.
The evidence auditors actually request
By the time fieldwork starts, an auditor testing CC7.1 and CC8 for configuration management is going to ask for a specific, fairly predictable set of artifacts. Building your program around producing these as a natural byproduct of daily operations — rather than assembling them under deadline pressure — is the difference between a smooth audit and Dax's eleven-day scramble.
Table 17: Configuration management evidence request checklist
Evidence requested | Where it should come from |
|---|---|
Documented secure baseline/hardening standard per asset class | Baseline documentation repository, version-controlled |
Current asset and configuration inventory | Auto-discovered inventory or CMDB export |
CIS Benchmark (or equivalent) scan results for a sample of systems | CSPM, CIS-CAT, OpenSCAP, or equivalent scan reports |
Drift detection reports and remediation tickets | CSPM/IaC drift alerts linked to ticketing system |
Sample of configuration change tickets across the audit period | Ticketing system (Jira, ServiceNow) with linked PRs |
Evidence changes were approved by someone other than the requester | PR approval logs, ticket approval fields |
Evidence of testing prior to production deployment | CI pipeline logs, staging validation records |
Emergency change log with retroactive approvals | Emergency change register, incident references |
Baseline review/update history | Version history on the baseline document, review sign-offs |
Reconciliation of manual changes back into IaC | Commit history showing post-hoc IaC updates |
I encourage clients to build a lightweight internal "evidence locker" — a shared drive or GRC tool folder mirroring this exact list, refreshed monthly rather than assembled in the two weeks before fieldwork. Our SOC 2 evidence collection article covers the broader discipline of evidence management across all criteria; configuration management evidence tends to be the most automatable category if you've built the CSPM and IaC pipeline described above.
Common audit findings — and how to close them before your auditor sees them
Beyond the exception patterns already covered, a few specific findings show up often enough in my engagements that they're worth calling out directly, along with the remediation path I typically recommend.
Table 18: Frequent configuration management findings and remediation paths
Finding | Why it happens | Remediation |
|---|---|---|
No documented baseline for a specific asset class (e.g., SaaS admin consoles) | Baseline effort focused only on infrastructure, not SaaS | Extend baseline documentation to every in-scope asset class, including SaaS |
Scan results exist but findings were never remediated | No SLA or ownership assigned to scan output | Route findings into the same remediation queue and SLA as vulnerabilities |
Inventory omits assets provisioned outside the standard pipeline | Shadow IT or a team using a different cloud account | Periodic account/subscription discovery sweep; enforce centralized provisioning |
Change approver is the same person as the requester | Small team, no defined segregation of duties | Add a second approver requirement in the ticketing/PR workflow, even if it's a rotating peer |
No evidence baseline was reviewed in the audit period | No calendar owner or reminder for the review cycle | Assign a named control owner with an annual (or benchmark-release-triggered) review date |
CIS Benchmark version referenced is several years out of date | Baseline never revisited after initial adoption | Tie baseline reviews to CIS's benchmark release cadence, not an arbitrary date |
Building the program: a realistic 120-day roadmap
Clients often ask how long it takes to stand up configuration management from a cold start. The honest answer depends heavily on how much infrastructure is already under IaC, but this is the sequencing I use most often for a mid-size SaaS organization with a mix of cloud-native and legacy assets.
Table 19: 120-day configuration management build roadmap
Phase | Timeframe | Key activities |
|---|---|---|
Discovery | Days 1–15 | Inventory all in-scope assets; identify what's already under IaC vs. manually managed |
Baseline definition | Days 16–35 | Adopt CIS Benchmarks per asset class; document tailoring decisions and exceptions |
Tooling selection | Days 20–40 | Select CSPM, scanning, and drift-detection tooling; pilot on one environment |
IaC/GitOps rollout | Days 30–75 | Migrate priority infrastructure into IaC; lock down manual console write access |
Drift detection go-live | Days 60–90 | Enable continuous scanning; route findings into a ticketing queue with SLAs |
Change process formalization | Days 60–90 | Define standard and emergency change workflows; enforce segregation of duties |
Evidence locker build-out | Days 90–110 | Establish recurring evidence capture aligned to the audit evidence checklist |
Internal validation / mock testing | Days 110–120 | Run an internal sample test simulating auditor sampling before real fieldwork |
Organizations already running substantial IaC can compress this significantly — sometimes to 45–60 days — because phases three and four are largely already in place. Organizations with heavy legacy or on-premises footprints should expect the low end of this range to stretch, particularly for network device and endpoint tooling that lacks clean APIs.
Roles and responsibilities
Configuration management fails as often from unclear ownership as from missing tooling. A RACI structure — even a lightweight one — prevents the most common failure mode: everyone assuming someone else is watching the drift dashboard.
Table 20: Configuration management RACI
Activity | Platform/Infra Engineering | Security Engineering | Engineering Managers | Compliance/GRC | Executive Sponsor |
|---|---|---|---|---|---|
Define secure baselines | Responsible | Consulted | Informed | Consulted | Informed |
Maintain asset inventory | Responsible | Accountable | Informed | Consulted | Informed |
Operate IaC/GitOps pipeline | Responsible | Consulted | Accountable | Informed | Informed |
Monitor for configuration drift | Responsible | Accountable | Informed | Consulted | Informed |
Approve standard changes | Consulted | Consulted | Accountable | Informed | Informed |
Approve emergency changes | Responsible | Consulted | Accountable | Informed | Informed |
Review baseline annually | Consulted | Responsible | Informed | Accountable | Informed |
Assemble audit evidence | Consulted | Consulted | Informed | Accountable | Informed |
What this actually costs, by company size
Budget conversations for configuration management tend to focus on tooling license costs and undercount the engineering time required to migrate legacy infrastructure into a trackable state. Both matter, and the ratio between them shifts a lot with company size.
Table 21: Illustrative configuration management program costs by company size
Company size | Primary cost driver | Illustrative annual tooling spend | Illustrative engineering investment |
|---|---|---|---|
Startup (under 50 employees, cloud-native) | CSPM/scanning tool licensing | $6,000–$18,000 | 1 engineer, part-time, ~1 quarter to establish |
Mid-market (50–500 employees, mixed cloud/legacy) | IaC migration + CSPM at scale | $25,000–$80,000 | 2–4 engineers, part-time, 2–3 quarters |
Enterprise (500+ employees, hybrid/multi-cloud) | Enterprise CSPM, config management platform, dedicated headcount | $100,000–$400,000+ | Dedicated platform/security engineering team, ongoing |
These figures are illustrative, tied to the scenarios in this article, and will vary with your cloud footprint, number of accounts, and how much legacy infrastructure resists automation. What's consistent across every size band I've advised: the cost of building this proactively is a fraction of the cost of reconstructing evidence retroactively during fieldwork, the way Dax's team had to.
Case study: Cascade Ledger closes the gap
Back to Dax. His eleven-day scramble did save the audit — the auditor accepted a retroactive incident reference, an interview with the on-call engineer, and a documented remediation plan as sufficient to characterize the finding as a single, isolated exception rather than a systemic control failure. The report shipped with a qualified management letter comment rather than a qualified opinion, and the $3.1 million retail contract closed six weeks later than originally planned.
But the real work started after the audit closed. Over the following two quarters, Cascade Ledger built exactly the program described in this article: a hardened image pipeline rebuilt weekly, production console write access restricted to break-glass emergency use only, a GitOps pipeline enforcing that Terraform was the sole path for infrastructure changes, and a CSPM tool feeding drift alerts into the same Jira queue used for vulnerability remediation. When Cascade's next Type II observation period opened, the auditor pulled a fresh sample of twenty-five configuration changes. All twenty-five had a complete evidence chain — ticket, PR, approval, deployment log — with zero exceptions. Dax's team also cut the time spent assembling audit evidence from roughly three weeks of dedicated effort to under four days, because the evidence had been accumulating automatically the entire year rather than being reconstructed at the end of it.
Case study: Loomstack's benchmark rollout
Loomstack, a DevOps tooling SaaS company with roughly 180 employees, came to a readiness assessment with a common profile: strong application-layer security practices, but no formalized infrastructure hardening standard beyond "whatever the base cloud image ships with." Their auditor's prior-year report had included a CC7.1 exception noting the absence of a documented baseline and no evidence of periodic configuration scanning.
Marcus Chen's team adopted CIS Level 1 benchmarks across their Linux fleet and AWS account, tailored roughly 15% of the benchmark's checks with documented exceptions (mostly around specific package requirements for their build agents), and stood up scheduled CIS-CAT scanning across their production fleet. Within one quarter, their configuration scan pass rate moved from an unmeasured baseline to 96% first-pass compliance, with the remaining 4% tracked through a standing remediation queue. Their next SOC 2 Type II report closed with zero configuration-related exceptions, and — as a secondary benefit Marcus didn't initially expect — their sales engineering team started using the benchmark scan summary as a talking point in security questionnaires with prospective enterprise customers.
Case study: Nordbridge Health Analytics tames cloud drift
Nordbridge Health Analytics, a healthcare data analytics platform operating across three AWS accounts, had a different problem: strong IaC discipline for new infrastructure, but a substantial amount of older infrastructure provisioned manually before their IaC adoption, with no reliable way to tell which resources were and weren't under code management. Aisha Bello-Fitzgerald, their compliance lead, described their pre-engagement state as "flying half-instrument" — confident about new deployments, blind about the rest.
The team deployed a CSPM platform across all three accounts, which surfaced 340 resources with no corresponding IaC definition — roughly 22% of their total footprint. Rather than migrating everything at once, they triaged by data sensitivity, prioritizing the 40-odd resources touching protected health information for immediate IaC migration and applying compensating manual change-tracking to the remainder. Within five months, configuration drift incidents (measured as CSPM findings open longer than 30 days) dropped by roughly 78%, and Nordbridge's following Type II audit period showed a clean CC7.1 testing result for the first time in the company's three-year SOC 2 history.
flowchart LR
A[Define secure baseline<br/>CIS Benchmark + tailoring] --> B[Provision via IaC/<br/>golden image]
B --> C[System live in production]
C --> D{Continuous drift<br/>detection / CSPM scan}
D -- No drift --> C
D -- Drift detected --> E[Ticket created,<br/>owner assigned, SLA starts]
E --> F{Remediate or<br/>reconcile into IaC?}
F -- Reconcile --> G[Baseline/IaC updated<br/>to reflect new approved state]
F -- Revert --> C
G --> C
H[Emergency change<br/>during incident] -.->|retroactive doc<br/>within 24-72h| EConfiguration change lifecycle: the loop between baseline definition, deployment, continuous drift detection, and reconciliation. Emergency changes feed back into the same loop through retroactive documentation rather than bypassing it.
Configuration management as a business advantage, not just an audit line item
It's tempting to treat configuration management as pure audit overhead — the tedious inventory-and-scanning work nobody wants to own. I'd push back on that framing, based on what I've watched happen at companies that build this well versus companies that treat it as a checkbox.
A real-time, accurate configuration inventory and drift-detection capability isn't just SOC 2 evidence — it's the same operational visibility that shortens incident response, because you can immediately see what changed before an outage started. A golden-image and IaC pipeline isn't just change-tracking evidence — it's the same infrastructure discipline that lets engineering teams ship faster with fewer production surprises, because every deployment starts from a known-good, tested state instead of an ad hoc one. And a clean CC7.1/CC8 testing result isn't just a line item in your report — it's a credible signal to prospects and their vendor risk teams that your engineering organization has real operational maturity, not just a compliance program bolted on top of chaotic infrastructure.
The organizations I've seen extract the most value from this work are the ones that stopped asking "what's the minimum we need to pass the audit" and started asking "what configuration visibility do we actually want, for our own operational sanity, regardless of the audit." The audit evidence falls out of that as a byproduct. Cascade Ledger didn't just fix an audit exception — they cut their mean time to diagnose infrastructure-related incidents by watching the same drift dashboard they built for their auditor. That's the version of this control area worth building.
If you're ready to formalize this, our SOC 2 Control Matrix / RACI Template gives you a starting structure for assigning exactly the ownership described above, and our SOC 2 Gap Analysis Tool can help you baseline where your current configuration management practices stand against CC7.1 and CC8 before you commit engineering time to a build-out. PentesterWorld's assessment and advisory team also works directly with infrastructure and security teams to design and validate configuration management programs ahead of Type II fieldwork — reach out if you'd rather have a second set of eyes before your auditor becomes that second set of eyes for you.