Five Things That Slow Down On-Prem SOC 2 Audit Preparation, and How to Start Now

SOC 2 audit preparation on on-prem infrastructure slows down in five places: infrastructure scanning and logging, application and container scanning, change approval across release cadences, onboarding and offboarding records, and identity across systems. A team can start all five this week, before it hires a consultant or an auditor, and the first one takes the longest.

A product lead at a company running production on its own hardware asked us this recently: an on-prem Kubernetes data plane, a cloud control plane, code on GitHub, Google Workspace, an HRIS, and a target of SOC 2 Type 2 in about four months. Below is the answer we sent, with identifying details removed.

Five On-Prem SOC 2 Readiness Blockers and the First Step for Each

Each on-prem SOC 2 readiness blocker maps to evidence an auditor will ask for, and each has a first step that fits in a week.

Why Is Infrastructure Scanning and Logging the Slowest Part of On-Prem SOC 2?

Infrastructure scanning and logging take the longest in on-prem SOC 2 because many on-prem environments start with no vulnerability scanner and no central place for host logs, and both need time to build a history. Auditors ask for scan results across the period and a record of how each finding was fixed. Under CC7.1, the Trust Services Criteria expect vulnerability scans on a periodic basis and after significant changes are made to the environment.

The fastest route is one agent on every on-prem host and the Kubernetes cluster that covers scanning, hardening checks and logs together:

• Datadog, for teams comfortable sending host data to a SaaS service: logs, host and container vulnerability scanning, CIS benchmark checks and alerting.
• Wazuh, for teams that prefer to self-host: free and open source, operated by the team or by a provider on its behalf.
• Tenable Nessus, a dedicated vulnerability scanner that also runs configuration checks. Nessus collects no logs, so pair it with one of the options above.
• A managed SOC for monitoring and response, so the team hears only about issues that need action.

Install the agent early: a Type 2 observation period needs scans and log review across the whole window. The guide to SOC 2 vulnerability scanning for on-prem servers covers firewalls and appliances that take no agent, and the SOC 2 logging and SIEM guide for bare metal covers what to log and how long to keep it.

How Do You Scan Application Code and Containers for SOC 2 in GitHub?

Application and container scanning for SOC 2 fits in GitHub, where each workflow run leaves a dated report that serves as audit evidence. Custom code, third-party libraries and container images each need their own scan before they reach production.

Write down which severities block a merge and how fast the rest get fixed; the auditor tests against that rule. The SOC 2 secure development guide for self-hosted GitLab covers the same controls in a merge request workflow.

Can Two Engineering Teams Release at Different Speeds and Still Pass SOC 2?

Two engineering teams with different release cadences pass SOC 2 when each team's review, testing and approval steps are written down and every release leaves a record. CC8.1 asks the organization to authorize, test and approve changes, so the auditor asks each team how it does that and samples its releases. An undocumented process reads to an auditor as no process.

Two approaches for teams at different speeds, and both hold up:

• The slower-cadence team requires an approving pull request review before merge, enforced by branch protection.
• The faster team lets low-risk merges through when automated functional and security tests pass. A reviewer looks back over merged changes each quarter, and each month for security-sensitive code such as authentication.

Each release record holds the pull request, test results, approver and deploy time. The guide to SOC 2 change management with tickets covers emergency changes and segregation of duties, and the CC8.1 change management guide covers the criterion itself.

What Do SOC 2 Auditors Check in Onboarding and Offboarding?

SOC 2 auditors pick a sample of joiners and leavers from the HRIS and ask for each person's record. Fast-hiring teams tend to fall behind on these records first; one checklist started from the HRIS, with a saved record per person, keeps them current.

Joining checklist:

• Background check completed before day one
• Policies signed
• Security awareness training completed
• Laptop enrolled in MDM, with EDR and disk encryption on before first use. EDR options include CrowdStrike, SentinelOne and Microsoft Defender for Business.

Leaving checklist:

• Access removed from every system within a set time, for example 24 hours
• Laptop returned or wiped
• Record saved with dates

The SOC 2 onboarding and access review playbook covers access reviews and offboarding deadlines, the guide to SOC 2 HR security without automated provisioning covers manual workflows, and the SOC 2 endpoint security guide covers laptop baselines.

How Should MFA and Admin Rights Work Across Systems for SOC 2?

MFA on every system and sign-in through one identity provider give a SOC 2 auditor one place to check access under CC6.1 to CC6.3. When each system manages its own users, MFA and admin rights end up set differently per system.

Google Workspace works as the identity provider for teams that already use it; Okta or JumpCloud fit when directory needs outgrow it. Connect the cloud console, GitHub, the Kubernetes cluster and internal admin tools through single sign-on where they support it, and keep a short, named list of admin accounts for each system. The guide to SOC 2 access control for on-prem environments covers bastion hosts, VPN and quarterly access reviews.

Does a Colocation Facility's SOC 2 Report Cover Physical Security?

A colocation facility's own SOC 2 report usually covers physical security for the hardware it hosts. The facility is treated as a subservice organization, typically under the carve-out method, and its report is reviewed each year. That removes a large part of the physical-control work compared with a server room the company operates itself.

The company still manages its cage access list and the customer controls the facility's report lists. The guide to SOC 2 vendor management with a data center as a subservice organization covers what to request from the facility and how to read its report.

How Long Does On-Prem SOC 2 Take to Reach a Type 2 Report?

An on-prem SOC 2 program with fast team responses reaches a Type 2 report about six months after kickoff.

Inside a four-month window, the realistic target is a Type 1 report plus an observation period already under way. Starting the five blockers early shortens the build, because scanners and logs already have history. The breakdown of SOC 2 in 90 days covers what a compressed build requires, and the guide to SOC 2 implementation cost and timeline covers budget.

On-Prem SOC 2 Audit Preparation Starts With the Controls That Need History

On-prem SOC 2 audit preparation goes fastest when the controls that need a track record start first. Scanning, logging and the joiner and leaver checklist build evidence with time; written change processes and one identity provider take days to set up. The SOC 2 scoping guide for hybrid infrastructure covers how to draw one boundary across a cloud control plane and an on-prem data plane, and the guide to SOC 2 evidence collection without APIs covers systems a GRC platform cannot read.

The SOC 2 for bare metal and on-prem infrastructure page lists the controls that change when production is on your own hardware, and the SOC 2 readiness guide for bare metal SaaS covers the full readiness phases. Teams comparing outside help can read how SOC 2 consultants for on-prem and hybrid infrastructure work.

More on-prem SOC 2 guides: the full on-prem security program checklist, what Vanta and Drata automate on-prem and SOC 2 Availability on a single data center.

Frequently Asked Questions

What should we do first for SOC 2 on-prem?

Start with vulnerability scanning and central logging on the on-prem hosts and the Kubernetes cluster, because both need months of history for a Type 2 audit. Install one agent such as Datadog or Wazuh and link each finding to a ticket, then turn on code and container scanning in GitHub.

Do we need a SIEM for SOC 2?

SOC 2 requires monitoring, and the Trust Services Criteria name no specific product. CC7.2 expects the company to monitor its systems for anomalies and act on them. A central log store with alert rules and a record of who reviewed each alert meets that expectation. Wazuh and Datadog both provide this, and a managed SOC can handle review and response.

Is Wazuh enough for SOC 2?

Wazuh covers vulnerability detection, configuration checks against CIS benchmarks, log collection and alerting for on-prem hosts and containers, which handles the infrastructure scanning and monitoring side of SOC 2. The evidence comes from operating it: reviewed alerts, fixed findings and tickets. Application code and container image scanning in GitHub still need their own tools.

Do we need physical security controls if we are in a colocation facility?

A colocation facility usually covers physical security through its own SOC 2 report. The facility is treated as a subservice organization, typically carved out of your report, and you review its report each year. You still manage your cage access list and the complementary user entity controls the facility's report assigns to customers.

How fast can an on-prem company get SOC 2 Type 1?

An on-prem company can reach a SOC 2 Type 1 audit after about six weeks of preparation and build, when the team answers questions and closes gaps quickly. The Type 1 report covers one point in time. A Type 2 report follows a 3-month observation period and arrives about 4 weeks after the period ends.

Can two engineering teams use different change processes for SOC 2?

Yes. SOC 2 accepts different change processes per team when each is written down and every release leaves a record. One team can require pull request review before merge, while a faster team merges low-risk changes on passing automated tests and reviews merged changes each quarter, or monthly for security-sensitive code.

Which EDR tools work for SOC 2?

CrowdStrike, SentinelOne and Microsoft Defender for Business all meet the SOC 2 expectation for malware protection on laptops. Auditors check that EDR, MDM enrollment and disk encryption are on before each new hire uses the laptop, and that each leaver's laptop is returned or wiped. The onboarding record for each person holds that evidence.

Can Google Workspace be the identity provider for SOC 2?

Yes. Google Workspace works as the SOC 2 identity provider for teams that already use it, with MFA enforced and other systems connected through single sign-on. Okta or JumpCloud fit when directory needs grow. Auditors check that MFA is on for every in-scope system and that admin accounts are limited and named.