.svg)
In cloud environments, configuration compliance is a toggle. Enable AWS Config, deploy a conformance pack, and the platform continuously evaluates every resource against predefined rules. Drift is detected automatically, remediation can be triggered programmatically, and the evidence is an API call away.
On bare metal, there is no conformance pack. The production servers are physical machines running Windows Server or Linux. The network appliances have firmware versions that need to be tracked manually. The hypervisors can't run agents. And the question an auditor will ask is the same one they ask cloud-first companies: how do you know these systems are configured securely, and how do you prove it?
The Key Insight
SOC 2 CC6.8, CC7.1, and CC8.1 don't prescribe AWS Config or Azure Policy. They describe outcomes that on-premise environments can achieve with open-source tooling, structured processes, and deliberate evidence design.
This post covers how to build and maintain configuration baselines for bare metal infrastructure, drawn from real implementations. It's part of a broader series on SOC 2 readiness for bare metal and on-prem infrastructure.
What SOC 2 Expects for Configuration Management
CC6.8 Baselines
Baseline configurations exist and are applied. Every production system has a documented baseline referencing a recognized standard, and new systems are deployed against it.
CC7.1 Monitoring
Deviations from baselines are detected. Configurations are monitored over time and drift is identified when it occurs.
CC8.1 Change Control
Configuration changes are controlled. Changes go through a documented process with justification, testing, and approval.
In cloud environments, all three are handled by a single managed service. In on-premise environments, each requires its own tooling and process design.
Choosing a Baseline Standard
SOC 2 CC6.8 requires systems to be configured based on approved baselines, but it doesn't prescribe which standard to use. Several recognized benchmarks are available, and the right choice depends on the industry, regulatory requirements, and infrastructure.
| Standard | Best For | Key Detail |
| CIS Benchmarks | Most industries, multi-framework compliance | Level 1 (practical) and Level 2 (deep hardening). Maps to NIST CSF and PCI DSS. |
| DISA STIGs | Defense, government, CMMC | More prescriptive than CIS. Updated every 90 days. Mandatory for DoD systems. |
| NIST 800-123 | Custom baselines, gap filling | Higher-level server hardening guidance. Less prescriptive but useful as a reference. |
| Vendor Guides | Platform-specific optimization | Microsoft, Red Hat, Canonical, Cisco. Supplements, not replaces, a recognized standard. |
For most on-premise SOC 2 engagements, CIS Level 1 benchmarks are the practical default. Companies with defense or government contracts should layer DISA STIGs on top of or instead of CIS where required.
Creating a Custom Baseline
Benchmarks are comprehensive, but not every recommendation applies to every environment. The practical approach is to start with the full benchmark for each system type, then create a custom baseline by reviewing each item and documenting one of four decisions:
- Pass: The setting is applied as recommended
- Fail: The setting needs to be remediated
- N/A: The setting doesn't apply to this system (with documented justification)
- Disabled: The setting conflicts with operational requirements (with documented justification and compensating controls)
This review produces a spreadsheet export with per-item decisions. The export itself becomes a primary evidence artifact, showing the auditor that baselines aren't blindly applied but are deliberately evaluated for the environment.
Automated Configuration Scanning
Configuration + Vulnerability Scanning
Configuration scanning and vulnerability scanning are tightly coupled in practice. Most tools handle both. Wazuh runs CIS benchmarks and CVE detection through the same agent. Tenable does vulnerability assessments and CIS audits in a single scan. Teams don't need separate tooling for each domain.
Pre-built CIS policies for Windows Server, Ubuntu, CentOS. No additional infrastructure if already deployed for SIEM and log collection.
SCAP-based compliance scanning for Linux with strong CIS and DISA STIG support. Integrates well with Red Hat and CentOS ecosystems.
Enforce and audit baselines using CIS hardening roles (e.g. ansible-lockdown). Configuration compliance as code, version-controlled and repeatable.
CIS benchmark auditing as part of its vulnerability management platform. Single tool for both vulnerability and configuration scanning.
CIS benchmark scanning designed for MSPs and smaller teams, with a focus on multi-tenant environments.
The choice depends on existing tooling and team capabilities. What matters for SOC 2 is that the scanning is automated, recurring, and produces historical evidence.
Tiered Scanning Cadence
Not every system needs the same scanning frequency. The tiered asset classification that drives vulnerability scanning cadence applies equally to configuration scanning:
- Tier 1 (high-risk): Production servers, databases, bastion host. Weekly CIS scans. Exceeds the typical quarterly policy minimum and demonstrates strong control operation during Type 2.
- Tier 2 (medium-risk): Endpoints, management systems, monitoring infrastructure. Quarterly scans where agents can be deployed. Manual verification for systems that can't run agents.
- Tier 3 (low-risk): Network appliances, training servers. Annual manual baseline verification against vendor documentation.
Firmware Version Tracking
Network appliances, firewall appliances, switches, and storage devices don't run scanning agents. Their security posture depends heavily on firmware versions, and SOC 2 requires a structured tracking process:
- Inventory all Tier 3 devices with current firmware versions
- Cross-reference each version against vendor security advisories and CVE databases
- Document results in a ticket listing each device, firmware version, and advisory check outcome
- Remediate devices with known critical/high vulnerabilities, or document a risk acceptance
Configuration Change Detection
SOC 2 CC8.1 requires controlled configuration changes. In on-premise environments, change detection requires deliberate instrumentation.
Syslog-based alerting: SIEM tools can monitor syslog feeds from network devices to detect configuration changes in near real-time. When a firewall appliance writes a configuration change to memory or a switch configuration is modified, the syslog event triggers an alert. Combined with the quarterly firewall review process, this demonstrates that changes are both detected and periodically validated.
Agent-based drift detection: For servers running scanning agents, recurring CIS scans serve as drift detection. A weekly scan showing a previously passing check now failing is a configuration drift event. The response should follow the same tiered alerting model used for security monitoring: investigate, document, remediate.
New System Deployment
SOC 2 CC6.8 doesn't just require baselines to exist. It requires that new systems are deployed against those baselines before entering production.
1 Deploy to a staging VLAN where the system is isolated from production
2 Apply the baseline configuration using documented hardening procedures or scripts
3 Run a configuration scan against the CIS benchmark to validate compliance
4 Remediate any failures and re-scan until the system passes
5 Move to production only after the scan shows a passing score. Document in a rollout ticket with final scan results.
Handling Exceptions
Not every benchmark item can be implemented. Application dependencies, legacy compatibility, and architectural constraints create legitimate exceptions. For each, document:
- Which benchmark item is excluded
- Why it can't be implemented (specific technical or business reason)
- What compensating controls are in place, if any
- Who approved the exception
An auditor seeing ten deliberate, justified exceptions in a baseline is far more confident than one seeing a baseline with no exceptions at all, which usually means it was never reviewed against the real environment.
Bringing It Together: The STEPP Lens
Scope
All servers, databases, bastion hosts, endpoints, network appliances, hypervisors, and storage devices. Classified into three tiers driving scanning cadence and evidence requirements.
Technology
CIS benchmark scanning via Wazuh SCA, OpenSCAP, Ansible, Tenable, or ConnectSecure on agent-capable systems. Syslog-based change detection for network devices. Manual verification for systems that can't support agents.
Evidence
Baseline exports with per-item decisions and justifications, automated scan results per system (weekly/quarterly/annual by tier), syslog alert records for configuration changes, firmware version records with vendor advisory cross-references, new system rollout tickets with validation scan results, drift remediation tickets.
Process
Weekly Tier 1 scans, quarterly Tier 2 scans, annual Tier 3 verification. Annual baseline review against new benchmark versions. New system deployment through staging with mandatory scan validation. Drift remediation via ticketed investigation.
People
A designated configuration owner responsible for baselines and remediation. For application-specific configurations (IIS, SQL Server), a shared responsibility model with the development team is common and auditor-acceptable when documented.
What Makes This Different From Cloud
AWS Config evaluates resources continuously against managed rules. The results are available through an API, the history is retained automatically, and conformance packs map directly to compliance frameworks.
On-premise configuration management requires assembling the same outcome from multiple tools and processes. The effort is higher, but the depth of understanding is often greater. Teams that build their own baselines, review each item against their environment, and make deliberate decisions about exceptions tend to have a stronger grasp of their configuration posture than teams that deploy a conformance pack and assume it covers everything.
Compliance automation platforms can help centralize the evidence, but the configuration work itself, building baselines, tuning scans, and tracking firmware, remains an infrastructure team responsibility regardless of the platform.
What Comes Next
Configuration management connects directly to access control (password policies are configuration settings enforced via baselines), vulnerability scanning (most tools handle both CIS benchmarks and CVE detection), and network security (firewall configuration is a specialized subset of configuration management).
The consistent pattern across every domain in this series: the on-premise approach requires more deliberate design, but the evidence it produces is equally compelling to auditors when the process is structured and documented.
Building an Effective Security Program for On-Prem?
We help teams get SOC 2 ready on any infrastructure.
Request Your Free Assessment →Frequently Asked Questions
What configuration baseline standards are accepted for SOC 2?
SOC 2 doesn't prescribe a specific standard. CIS Benchmarks are the most widely adopted across industries and accepted by every auditor. DISA STIGs are required for defense and government environments and are more prescriptive. NIST 800-123 provides higher-level server hardening guidance. Vendor hardening guides (Microsoft, Red Hat, Cisco) supplement these standards. For most on-premise SOC 2 engagements, CIS Level 1 is the practical default.
What tools can replace AWS Config for SOC 2 configuration compliance on-prem?
Several options work well: Wazuh SCA, OpenSCAP, Ansible with CIS hardening roles, Tenable (Nessus), and ConnectSecure all provide automated CIS benchmark scanning for on-premise systems. The choice depends on existing tooling and team skills. Many of these tools also handle vulnerability scanning, so teams can cover both SOC 2 requirements (CC6.8 for baselines, CC7.1 for vulnerabilities) from the same platform.
How often should configuration benchmark scans run for SOC 2?
A risk-based tiered cadence works well: weekly scans for Tier 1 high-risk systems (production servers, databases), quarterly for Tier 2 systems (endpoints, management infrastructure), and annual verification for Tier 3 systems (network appliances, training servers). Weekly exceeds the typical quarterly policy minimum and demonstrates strong control operation during Type 2 observation periods.
How do you track configuration compliance for network appliances that can't run agents?
Firmware version tracking combined with syslog-based change detection. Maintain an inventory of all network devices with current firmware versions, cross-referenced annually against vendor security advisories. Configure syslog forwarding so configuration changes on firewalls and switches generate alerts. Document the annual review in a ticket with per-device results.
What happens when a benchmark item can't be implemented?
Document the exception with the specific benchmark item, the technical or business reason it can't be applied, any compensating controls, and management approval. Deliberate, justified exceptions are a sign of mature security decision-making. A baseline with no exceptions usually means it was never reviewed against the real environment, which is a bigger concern for auditors.
How should new servers be validated against baselines before going to production?
Deploy to a staging VLAN, apply the baseline configuration, run a configuration scan to validate compliance, remediate any failures, and document the deployment in a rollout ticket with the final scan results. The system moves to production only after the scan shows a passing score. This produces a clear evidence chain that CC6.8 requires.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.
How Ready Are You for SOC 2?
Score your security program in under 5 minutes. Free.
Take the Scorecard