Configuration Management and Hardening Evidence for SOC 2

Introduction

Configuration management and hardening evidence for SOC 2 is the dated record that shows your systems are built from approved secure baselines, that those baselines are checked over time, and that differences are found and handled. A policy line that says "servers are hardened according to industry standards" is intent. Baseline documents, image build records, compliance scan results, drift findings, and exception tickets tied to specific systems are evidence.

Most SOC 2 programs already keep an asset inventory and change management records. Both assume a known good configuration exists. Configuration and hardening evidence answers the questions underneath: what the approved configuration is, how new systems get it, and how you know systems still match it months later.

Here is a labeled hypothetical. A 45-person SaaS company builds its virtual machines from a hardened image and passes its Type 1 review. During Type 2 fieldwork, the auditor asks for the baseline and a sample of production hosts. The baseline document was last updated 18 months ago, a third of the sampled hosts run an older image with SSH password login still enabled, and the cloud posture tool flagged two public storage buckets that nobody triaged. None of this proves a breach. It means the company cannot show its described configuration controls operated across the period.

What Configuration Management and Hardening Evidence Means

Configuration and hardening evidence answers six questions with records rather than descriptions:

1. What is the approved baseline? A documented secure configuration for each system type, such as operating systems, container images, databases, cloud accounts, and identity platforms.
2. Where does the baseline come from? A recognized benchmark, a vendor guide, or an internal standard, adapted to your environment with the reasons recorded.
3. How do new systems get it? Golden images, infrastructure-as-code templates, or configuration management tooling that applies the baseline at build time.
4. How do you detect drift? Scheduled compliance scans, cloud posture checks, or drift detection that compares running systems to the baseline.
5. What happens to findings? Triage, fixes, or approved exceptions for each deviation.
6. How does the baseline change? Updates go through review and approval, with version history.

Auditors test the controls your company describes in its system description. If you describe hardened images and weekly compliance scans, expect to show both working for sampled systems across the audit period.

How This Differs From Change Management and Vulnerability Management Evidence

These evidence sets overlap and often live in the same tools. They answer different questions.

A missing patch is usually a vulnerability finding. A setting that differs from your baseline, such as an open management port or disabled logging, is usually a configuration finding. Many teams route both to the same queue, which is fine as long as each is tracked. See Vulnerability Management Evidence for SOC 2 for the patching side.

Why Configuration Evidence Matters for SOC 2

SOC 2 does not require a specific benchmark or tool. The Trust Services Criteria published by the AICPA ask that the entity use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities (CC7.1), that it control changes to infrastructure and software (CC8.1), and that it implement logical access security over its systems (CC6.1). Hardening and configuration monitoring controls usually support all three. See SOC 2 Trust Services Criteria Explained for how the criteria are organized.

In practice, auditors commonly look for three things:

• A defined baseline for each in-scope system type, with an owner and a review date.
• Evidence that systems were built from it and checked against it.
• Consistent operation across the whole period for a Type 2 report. See SOC 2 Type 1 vs Type 2 for how the period affects testing.

Defining Secure Baselines

Start with the system types that are in your SOC 2 boundary.

Scope

List each system type: server operating systems, container base images, managed databases, cloud accounts and their organization policies, Kubernetes clusters, network devices, the identity provider, and endpoints if they are in scope. Tie each type to your asset inventory so the population is complete.

Source

Many teams start from a published benchmark such as the CIS Benchmarks from the Center for Internet Security, vendor hardening guides, or the cloud provider's security best practice guidance. You do not have to adopt every recommendation. Record which ones you apply, which you skip, and why. A short, accurate baseline is stronger evidence than a long one nobody follows.

Contents

A useful baseline covers things like disabled default accounts and services, authentication settings, encryption settings, logging and time synchronization, network exposure rules, and patch configuration. Link related settings to existing standards, for example encryption and key management and logging and monitoring.

Ownership and review

Name an owner for each baseline and review it at least annually or when the platform changes significantly. Keep version history. Treat a baseline update as a change with its own approval record.

Building Systems From the Baseline

Evidence that the baseline is applied at build time is usually the strongest part of the story.

• Golden images: Keep the image build pipeline, the version history, and a record of which image version each running system uses.
• Infrastructure as code: Keep the templates, the review and approval of template changes, and pipeline logs that show production was deployed from them.
• Configuration management tools: Keep the policies or manifests that enforce settings and the run history that shows they applied.
• Image retirement: Record when old images are deprecated and how long systems may keep running them.

If a team builds a system by hand, that should be an exception with a ticket, not a quiet workaround.

Detecting Drift and Monitoring Compliance

Systems change after they are built. Drift detection shows you notice.

• Compliance scans: Scheduled scans of hosts, images, or cloud accounts against your baseline, with results retained.
• Cloud posture checks: Continuous checks for risky cloud settings, such as public storage, open security groups, or disabled audit logging.
• Infrastructure-as-code drift: Regular comparison of deployed resources to the code that should define them.
• Coverage: Evidence that checks run on all in-scope accounts and system types, not only the main production account.

Keep scan configurations, schedules, and a sample of dated results. If your tool keeps history for less time than your audit period, export it on a schedule. The broader pattern of controls slipping over time is covered in What Is Control Drift?.

Handling Findings and Exceptions

A scan whose findings are ignored is weak evidence. Show what happened next.

• Triage: Each finding is reviewed and marked as a real deviation, a false positive with a reason, or an accepted difference.
• Timelines: Define fix timelines by risk and track them in tickets.
• Exceptions: Settings that must differ from the baseline go through exception management with an owner, a business reason, any compensating control, and an expiry or review date.
• Baseline feedback: If the same exception keeps appearing, consider whether the baseline itself should change, and record that decision.

Auditors usually trace a sample of findings from detection to closure or approved exception.

Type 2 Sampling: What Auditors Commonly Request

Auditors decide their own procedures, but configuration testing commonly includes requests like these:

• The baseline or hardening standard for each in-scope system type, with version history and last review date.
• The source benchmark or guide and the documented deviations from it.
• A sample of production systems with evidence of the image, template, or configuration policy used to build them.
• Compliance or posture scan configurations and dated results across the period.
• A sample of findings traced to fix or approved exception.
• Change records for baseline updates during the period.
• Evidence that scans covered all in-scope accounts and environments.

If a population is empty, for example no baseline exceptions were approved, keep evidence of how you know, such as a ticket query for the period.

Common Mistakes

• Pointing to a benchmark as the baseline without recording which items you actually apply.
• Scanning the main production account while staging, data, or shared services accounts go unchecked.
• Leaving systems on old images indefinitely with no retirement rule.
• Approving exceptions with no expiry date, so they never get reviewed.
• Updating the baseline without a change record or approval.
• Losing scan history because the tool keeps results for a shorter time than the audit period.
• Treating console changes that bypass infrastructure as code as normal.

A Practical Operating Model

A workable model for a growing team looks like this:

1. List in-scope system types from the asset inventory and assign baseline owners.
2. Write a short baseline per type, based on a recognized benchmark or vendor guide, with documented deviations.
3. Build systems from images or templates that apply the baseline.
4. Run scheduled compliance and cloud posture checks across every in-scope account.
5. Route findings to owners with tickets and timelines.
6. Manage baseline differences as time-bound exceptions.
7. Review baselines at least annually and through change management.
8. Retain the records across the full audit period.

Framework Notes

• SOC 2: Configuration and hardening controls typically support CC7.1 for detecting configuration changes that introduce vulnerabilities, CC8.1 for controlled changes, and CC6.1 for logical access security. Your control descriptions define what is tested.
• ISO 27001: ISO/IEC 27001:2022 Annex A includes a configuration management control (8.9) that covers establishing, documenting, implementing, monitoring, and reviewing security configurations. It sits alongside management of technical vulnerabilities (8.8) and change management (8.32). See Mapping Controls Across SOC 2 and ISO 27001.
• NIST: NIST SP 800-128 is a guide to security-focused configuration management, and the configuration management (CM) family in NIST SP 800-53 includes baseline configuration (CM-2), configuration settings (CM-6), and least functionality (CM-7). The NIST National Checklist Program (SP 800-70) points to published security configuration checklists.
• CIS: The CIS Benchmarks are consensus-based secure configuration guides for many operating systems, cloud platforms, and applications, and are a common starting point for baselines.

How AuditFlo.co Helps

AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.

For configuration management, that can mean dated history for baseline change tickets, infrastructure-as-code reviews, finding triage tickets, and exception approvals, so you can show the work across the period without rebuilding it from memory. Your cloud platforms, configuration tools, and scanners remain the systems of record for settings and scan results. AuditFlo.co does not scan or harden systems, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.

To see the workflow for your stack, request a demo.

Final Thoughts

Configuration and hardening evidence proves your systems start secure and stay that way. Define a short baseline per system type, build from images or templates that apply it, scan for drift across every in-scope account, handle findings with tickets, and treat differences as time-bound exceptions. If you can show a sampled system's baseline, build record, and recent scan with dated records, configuration testing becomes routine.

For related evidence, see What Is Change Management?, What Is Vulnerability Management?, Secure Software Development Evidence for SOC 2, and how to prepare for a SOC 2 audit.

FAQ

Does SOC 2 require CIS Benchmarks?

No. SOC 2 does not require a specific benchmark. Many companies use CIS Benchmarks or vendor guides as a starting point, then document which settings they apply. Auditors test the baseline you describe.

What is the difference between a baseline and a hardening standard?

The terms are often used together. A hardening standard usually describes the security settings you require, and a baseline is the approved configuration for a system type that includes those settings. What matters is that the approved configuration is written down and versioned.

How often should we scan for configuration drift?

SOC 2 does not set a frequency. Many teams run cloud posture checks continuously and host or image compliance scans weekly or monthly. Choose a cadence you can sustain, describe it accurately, and keep the results.

Do containers and serverless functions need baselines?

If they are in your SOC 2 boundary, they usually need some defined configuration, such as approved base images, runtime settings, and permissions. The baseline will look different from a server baseline, but the evidence pattern is the same.

Is a configuration finding the same as a vulnerability?

Not always. A vulnerability is usually a known weakness in software that a patch or upgrade fixes. A configuration finding is a setting that differs from your approved baseline. Both can create risk, and many teams track them in the same queue.

Does AuditFlo.co harden or scan our systems?

No. Your cloud platforms, configuration tools, and scanners apply and check settings. AuditFlo.co helps organize dated evidence such as tickets, review history, and workflow records from systems you already use, and does not replace your engineers or your auditors.