What SOC 2 Type II Actually Audits (And What It Leaves Out)

June 25, 2026 · 9 MIN READ

SOC 2 Type II tells you that a service organization's controls were operating effectively over a defined period — typically 6 to 12 months. It's not a point-in-time snapshot, and it's not a rubber stamp. But it also doesn't cover everything your compliance team thinks it covers. Here's what the audit actually examines, where it stops, and which certifications fill the gaps.

What Does SOC 2 Type II Actually Test?

The audit is structured around five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory. The other four are in scope only if the service organization includes them — so when a vendor says "we're SOC 2 Type II certified," the first question worth asking is which criteria they actually had audited.

For a colocation facility, a meaningful SOC 2 Type II report should cover at least Security and Availability. Security addresses logical and physical access controls, change management, risk assessment, and incident response. Availability addresses whether the systems supporting customer workloads are available for operation and use as committed.

Here's what the auditor is actually looking at in a colo context:

  • Physical access controls — Who can enter the facility, how access is logged, how access is revoked when someone leaves
  • Environmental monitoring — Temperature, humidity, power, and fire suppression systems and whether they're being watched continuously
  • Change management — How infrastructure changes are approved, tested, and rolled back if they fail
  • Incident response — Whether there's a documented process, and whether it was actually followed during the observation period
  • Vendor management — How third-party suppliers (power, fiber, cooling equipment) are evaluated and monitored

That last one matters more than people realize. If your colo is running carrier circuits from providers they've never formally evaluated, that's a gap the auditor should flag.

The "Type II" distinction is what separates this from a checkbox exercise. A Type I audit says "these controls exist as of this date." A Type II audit says "these controls operated effectively from January through December." The auditor reviews evidence — access logs, change tickets, incident records, monitoring alerts — to confirm the controls weren't just documented but actually used.

Where SOC 2 Type II Stops

SOC 2 doesn't tell you anything specific about healthcare data. It doesn't validate your cardholder data environment. It doesn't map to federal information security requirements. It's a framework for operational controls, and it's intentionally broad enough to apply to SaaS companies, cloud providers, and data centers alike.

That breadth is also its limitation.

HIPAA and healthcare workloads. SOC 2 has no concept of Protected Health Information. It doesn't require a Business Associate Agreement. It doesn't address breach notification timelines under HITECH. A healthcare SaaS running in a SOC 2-certified facility is not automatically HIPAA-compliant — not even close. The facility's certification tells you about their operational discipline, not their ability to handle PHI under federal law.

Payment card data. PCI DSS has specific, prescriptive requirements for cardholder data environments: network segmentation, encryption in transit and at rest, quarterly vulnerability scans, penetration testing, and strict access controls tied to individual user IDs. SOC 2 doesn't require any of that specifically. A facility can pass a SOC 2 audit with controls that would fail a PCI DSS assessment in the cardholder data environment.

Federal and government workloads. NIST 800-53 is the control framework underlying FedRAMP and many state government security requirements. It's prescriptive in ways SOC 2 isn't — specific control families, specific implementation requirements, specific documentation standards. SOC 2 doesn't map cleanly to NIST 800-53, and a facility that only has SOC 2 can't credibly claim NIST 800-53 alignment without separate documentation.

How HITRUST CSF Fills the Healthcare Gap

HITRUST CSF (Common Security Framework) was built specifically to address the problem above. It's a certifiable framework that maps to HIPAA, HITECH, PCI DSS, NIST, ISO 27001, and other standards simultaneously. When a data center holds HITRUST CSF certification, it means an assessor has validated controls against all of those frameworks in a single audit.

For healthcare organizations, this matters practically. Enterprise health systems and payers increasingly require HITRUST CSF from their vendors — not just SOC 2. A regional hospital IT team evaluating colocation options for their EHR infrastructure isn't going to accept "we're SOC 2 compliant" as sufficient. They need the HITRUST certification because their own compliance program depends on it.

HITRUST also has a tiered assessment structure. The r2 (risk-based) assessment is the most rigorous and the one that carries real weight. If a vendor claims HITRUST but can't tell you which assessment type they completed, ask. There's a significant difference between a self-assessment and a validated r2 certification.

What a Full Certification Stack Looks Like in Practice

Here's how the major certifications divide responsibility for a compliance-sensitive workload:

Certification What It Covers Who Needs It
SOC 2 Type II Operational controls over time Almost everyone
PCI DSS Cardholder data environment eCommerce, payments, fintech
HITRUST CSF Healthcare regulations (HIPAA/HITECH) Healthcare SaaS, hospitals, payers
NIST 800-53 Federal security control framework Government, regulated industries
SSAE-16 Financial reporting controls (legacy SOC 1) Financial services, audit requirements

A healthcare SaaS company processing patient records and taking payments needs SOC 2 Type II, HITRUST CSF, and PCI DSS at minimum. Each certification is examining a different slice of the environment. They're not redundant — they're complementary.

The mistake I see often is a compliance team checking "data center is SOC 2 certified" off their list and assuming that covers their obligations. It doesn't. SOC 2 covers the facility's operational controls. Your obligations under HIPAA, PCI DSS, or a government contract are separate, and the facility's certifications need to match your specific regulatory exposure.

What to Actually Ask a Colocation Provider

When you're evaluating a colo for compliance-sensitive workloads, the SOC 2 Type II report is the starting point, not the finish line. Ask for the actual report, not just the attestation letter. The report tells you which Trust Service Criteria were in scope, the observation period, and any exceptions the auditor noted.

Then ask about the specific certifications relevant to your workload. If you're running healthcare data, you need HITRUST CSF. If you're handling card payments, you need PCI DSS. If you're serving state or federal government customers, you need to understand how the facility aligns to NIST 800-53.

Also ask how long they've held each certification. A facility that just completed its first SOC 2 Type II audit has one observation period of evidence. A facility that's been through multiple audit cycles has demonstrated sustained operational discipline — and that's a meaningful difference.

IDACORE Boise holds SOC 2 Type II, PCI DSS, NIST 800-53, SSAE-16, and HITRUST CSF certifications. That's the full stack for healthcare, financial, and government workloads — not because we collect certifications, but because the customers we serve in those industries require all of them. If you want to see the actual reports rather than the marketing summary, ask us directly. We'll send them.

Frequently Asked Questions

What does SOC 2 Type II actually audit in a data center?
SOC 2 Type II audits a data center's controls across five Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — over a defined period, typically 6–12 months. It tests whether controls were operating effectively throughout that period, not just on audit day. For colocation, this covers physical access, environmental monitoring, change management, and incident response procedures.

What's the difference between SOC 2 Type I and SOC 2 Type II?
SOC 2 Type I is a point-in-time snapshot — it confirms controls exist on a specific date. SOC 2 Type II covers an observation period, typically 6–12 months, and tests whether those controls actually operated consistently. Type II is significantly harder to obtain and far more meaningful to buyers. If a vendor only has Type I, ask why they haven't completed a Type II audit.

Does SOC 2 Type II cover HIPAA compliance for healthcare data?
No. SOC 2 Type II doesn't certify HIPAA compliance. It audits operational controls, but HIPAA has specific requirements around PHI handling, BAAs, and breach notification that SOC 2 doesn't address directly. Healthcare organizations should look for a data center that combines SOC 2 Type II with HITRUST CSF certification — HITRUST maps directly to HIPAA controls and is increasingly required by healthcare enterprise buyers.

Is SOC 2 Type II required for PCI DSS compliance?
Not required, but complementary. PCI DSS focuses specifically on cardholder data environments — network segmentation, encryption, access controls, and vulnerability management. SOC 2 Type II covers broader operational controls. A colocation facility with both certifications gives you overlapping assurance: PCI DSS validates the payment data environment, SOC 2 validates the operational discipline surrounding it. Most serious financial workloads benefit from both.

What colocation certifications does IDACORE Boise hold?
IDACORE Boise is certified SOC 2 Type II, PCI DSS, NIST 800-53, SSAE-16, and HITRUST CSF. That combination covers healthcare, financial, and government workloads. HITRUST CSF in particular maps to HIPAA, HITECH, and other healthcare regulations, making IDACORE Boise one of the few Idaho colocation facilities positioned for compliance-sensitive healthcare SaaS and regional hospital IT infrastructure.

If your workload has real compliance requirements — healthcare, payments, government — the certification stack your data center holds isn't a checkbox. It's evidence of sustained operational discipline across the specific frameworks your auditors are going to ask about. IDACORE Boise carries the full set: SOC 2 Type II, HITRUST CSF, PCI DSS, NIST 800-53, and SSAE-16. If you're evaluating Idaho colocation for a compliance-sensitive workload and want to review the actual audit reports, reach out and we'll walk through them with you.

Ready to Implement These Strategies?

Our team of experts can help you apply these compliance & certifications techniques to your infrastructure. Contact us for personalized guidance and support.

Get Expert Help