Zero Trust and SOC 2: Stop Doing Compliance Work Twice

Most security teams building a zero trust architecture and running a SOC 2 program are collecting the same evidence twice, writing two sets of policies for the same controls, and treating them as separate projects with separate owners.

They are not separate. They never were.

Zero trust and SOC 2 are solving the same underlying problem — verify who has access, prove they should have it, and show that you know when something goes wrong. The controls that enforce zero trust principles are the exact controls SOC 2 auditors check. The logs your zero trust stack generates are the evidence your SOC 2 auditor needs.

This guide shows you exactly where they map, gives you a control-mapping table covering seven zero trust controls and the SOC 2 criteria each one satisfies, walks you through a four-step process to merge your programs, and flags the mistakes that create the duplicate work in the first place.

Do this right, and your zero trust architecture stops being a security initiative and starts being a compliance engine.

WHAT IS ZERO TRUST — THE VERSION THAT MATTERS FOR COMPLIANCE

Zero trust is defined by NIST Special Publication 800-207 as a cybersecurity framework that eliminates implicit trust in any network element. Instead of assuming that users and devices inside a corporate network perimeter are safe, zero trust requires continuous verification of identity, device health, and authorization for every access request — regardless of where the request originates.

The seven tenets of NIST SP 800-207 are:

— All data sources and computing services are considered resources — All communication is secured regardless of network location — Access to individual resources is granted on a per-session basis — Access to resources is determined by dynamic policy — The enterprise monitors and measures the integrity of all assets — All resource authentication and authorization is dynamic and strictly enforced — The enterprise collects information about assets and uses it to improve security posture

Notice what is missing: perimeter. Zero trust has no perimeter. It has identities, devices, policies, and continuous verification. Those are precisely the things SOC 2 auditors are looking for when they review your Common Criteria controls.

WHY ZERO TRUST AND SOC 2 ARE ALREADY DOING THE SAME JOB

SOC 2's Trust Services Criteria are organized around five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security — the mandatory category — contains the Common Criteria (CC1 through CC9), which cover access controls, change management, risk assessment, vendor management, and incident response.

Zero trust is an implementation methodology for exactly those same controls. When you enforce MFA before granting access, you are satisfying CC6.1. When you implement microsegmentation to limit lateral movement, you are satisfying CC6.6 and CC6.7. When your SIEM alerts on anomalous behavior, you are generating CC7.1 evidence.

The problem is that most organizations do not document this connection. Their zero trust controls live in one system. Their SOC 2 evidence lives in a GRC platform. An auditor asks for access control evidence, and someone manually exports logs instead of pointing directly to the zero trust telemetry that already exists.

According to Konfirmity's 2026 compliance research, auditors and customers now explicitly expect evidence that service organizations implement modern access controls, network segmentation, MFA, and least-privilege policies. Those are not additions to SOC 2. They are the new baseline interpretation of the existing common criteria — and they are exactly what a zero trust architecture implements by design.

By 2026, clients, insurers, and regulators are placing greater emphasis on vendor risk management with heightened expectations for SOC 2 Type II compliance and zero trust architecture. These are not two separate expectations. They are the same expectation stated twice.

THE 7 ZERO TRUST CONTROLS MAPPED TO SOC 2 CRITERIA

This table maps seven zero trust controls to the SOC 2 Trust Services Criteria they satisfy and the evidence each one produces. Every piece of evidence in the right column is generated automatically by a zero trust implementation — no manual collection required.

Zero Trust Control | SOC 2 Criteria Satisfied | Reusable Evidence Generated

1. Identity Verification and MFA Every access request requires verified identity and a second factor before a session is granted. No implicit trust based on network location. → CC6.1 (Logical access security), CC6.3 (Role-based access management) → IdP authentication logs, MFA enrollment and enforcement reports, access request records with deny/approve outcomes, SSO session logs

2. Device Health and Endpoint Compliance Devices must meet a defined compliance baseline — patched OS, disk encryption, EDR active — before access is granted. Non-compliant devices are blocked or quarantined. → CC6.1 (Logical access security), CC7.1 (Security event detection) → MDM compliance dashboards, EDR health and posture reports, device inventory with compliance status, failed access attempts from non-compliant devices

3. Least Privilege and Just-in-Time Access Users and service accounts receive only the minimum permissions required for their current task. Elevated permissions are time-bound and require justification. → CC6.2 (New user provisioning), CC6.3 (Role-based access), CC6.6 (Restrictions on access) → Role permission matrices, JIT access request and approval logs, quarterly access review records, over-provisioning remediation tickets

4. Microsegmentation and Network Isolation Workloads, applications, and data stores are isolated into segments with explicit allow-list policies. Lateral movement between segments requires re-verification. → CC6.6 (Restrictions on access to information), CC6.7 (Transmission and disclosure restrictions) → Network segmentation diagrams, firewall and SDN policy rule sets, traffic flow logs showing inter-segment access decisions, penetration test results confirming isolation

5. Continuous Monitoring and Behavioral Analytics: All user, device, and application activity is monitored in real time. Anomalous behavior triggers automated alerts and investigation workflows. → CC7.1 (Detection of and response to security events), CC7.2 (Monitoring for anomalies) → SIEM alert logs with disposition records, behavioral anomaly detection reports, threat detection dashboard exports, mean time to detect and respond metrics

6. Data Classification and Encryption: Data is classified by sensitivity and protected according to its classification. Encryption is enforced at rest and in transit. Access policies are tied to data classification labels. → CC6.1 (Logical access security), C1.1 and C1.2 (Confidentiality criteria) → Data classification policy documentation, DLP configuration and alert logs, encryption key management records, data flow diagrams showing classification-enforced access paths

7. Continuous Session Validation and Token Rotation Sessions are not trusted indefinitely. Tokens expire, re-authentication is required at defined intervals, and anomalous session behavior triggers termination. → CC6.8 (Preventing unauthorized access via authenticated sessions), CC6.1 (Logical access security) → Session timeout policy documentation, token rotation and expiry logs, forced re-authentication event records, session termination audit trails

Every row in this table represents evidence your zero trust architecture is already generating. The only step missing for most organizations is pointing your GRC platform at those sources instead of collecting the same evidence manually.

THE 4-STEP MERGE GUIDE

Most organizations maintain parallel programs — security teams own zero trust, compliance teams own SOC 2 — with minimal coordination between them. The merge process below closes that gap in four steps without requiring a full program restructure.

STEP 1: MAP YOUR ZERO TRUST CONTROLS TO SOC 2 CRITERIA

Start by documenting every zero trust control your organization has implemented — identity provider configuration, device management policies, segmentation rules, monitoring stack, session management — and mapping each one to the SOC 2 criteria in the table above.

This does not require new tooling. It requires a spreadsheet and one working session between your security architect and your compliance lead. The output is a control mapping document that your auditor can review at the start of your next engagement. Many organizations discover during this step that they have already implemented the majority of their SOC 2 CC6 and CC7 controls through zero trust — they simply have not documented the connection.

Document the control owner, the system that enforces it, the evidence it generates, and where that evidence is stored. This mapping document becomes your primary evidence manifest for the next audit.

STEP 2: REDIRECT EVIDENCE COLLECTION TO ZERO TRUST TELEMETRY

SOC 2 auditors ask for evidence. Your zero trust stack is producing that evidence continuously. The problem in most organizations is that evidence collection for audits is a manual process — someone exports reports, takes screenshots, and uploads files to a GRC platform — even though the underlying data already exists in automated systems.

After completing Step 1, update your evidence collection process to pull directly from zero trust data sources:

— IAM and identity provider: authentication logs, MFA enforcement reports, access reviews — MDM and endpoint management: device compliance dashboards, posture reports — SIEM and behavioral analytics: alert logs, anomaly detection reports, incident records — Network and segmentation tools: traffic logs, policy rule sets, segmentation diagrams — PAM and session management: session logs, token rotation records, JIT access approvals

Configure your GRC platform to ingest these sources automatically where possible. Where APIs are not available, define a scheduled evidence collection process that pulls from the zero trust stack on a defined cadence — not just before audits.

The goal is a state where your auditor can review live telemetry rather than point-in-time exports. This is what continuous compliance looks like in practice, and it is what SOC 2 auditors in 2026 increasingly expect.

STEP 3: ALIGN POLICY DOCUMENTATION

Zero trust architectures require policy documentation: acceptable use policies, access control policies, device management standards, data classification standards, and incident response procedures. SOC 2 requires the same policies under CC1, CC2, and CC5.

The mistake most organizations make is maintaining two versions — one written for the security team and one written for the auditor. They say the same things in different language and are both outdated within six months.

Merge them. Write one set of policies that satisfy both programs. The structure is straightforward:

— Write each policy to describe what the control does, who owns it, how it is enforced technically, and how compliance is measured. — Reference the specific zero trust components that enforce each policy (e.g., "MFA enforcement is implemented via [IdP name] and applied to all production access through [policy name]"). — Map each policy to the SOC 2 criteria it satisfies in a policy-to-criteria crosswalk table appended to each document.

Single-source policy documentation cuts your annual review burden in half and eliminates the version confusion that creates findings when an auditor discovers that your documented policy and your technical implementation do not match.

STEP 4: ESTABLISH A SHARED REVIEW CADENCE

SOC 2 evidence collection, access reviews, and control testing happen on a cadence. Zero trust policy reviews, threat model updates, and segmentation rule reviews happen on a cadence. These cadences are almost always different because they are owned by different teams — and that is where duplicate work compounds.

Define a shared quarterly review that covers both programs simultaneously:

— Quarterly access reviews: covers CC6.3 (SOC 2) and least-privilege validation (zero trust) in one exercise — Quarterly vulnerability reviews: covers CC7.1 (SOC 2) and device posture validation (zero trust) in one exercise — Quarterly policy reviews: covers CC2 and CC5 (SOC 2) and zero trust policy currency in one exercise — Annual penetration test and segmentation validation: covers CC4.1 (SOC 2) and zero trust microsegmentation effectiveness in one exercise

One calendar. One evidence package per quarter. Two programs satisfied.

THE MISTAKES THAT CREATE DUPLICATE WORK

Understanding what breaks the merge is as important as understanding how to execute it.

Treating zero trust as an IT project and SOC 2 as a compliance project. When zero trust lives under the CISO and SOC 2 lives under the GRC team with no shared ownership model, evidence stays siloed. Fix this by assigning a named owner for each zero trust control who is also responsible for the SOC 2 evidence that control produces.

Building zero trust without documentation. Zero trust architectures produce excellent telemetry but poor audit trails without intentional documentation. An SIEM alert log is evidence. A network segmentation diagram is evidence. A JIT access approval record is evidence. None of them satisfy an auditor unless they are labeled, stored, and retrievable on demand.

Running annual point-in-time evidence collection. If your evidence collection process activates three months before your SOC 2 audit window, you are collecting snapshots instead of demonstrating continuous operation. Auditors in 2026 are increasingly asking to see evidence distributed across the full audit period — not just the month before fieldwork. Continuous evidence collection from zero trust telemetry is the structural fix.

Scoping zero trust narrowly and SOC 2 broadly. If your zero trust implementation covers production systems but your SOC 2 scope includes corporate infrastructure, developer environments, and vendor access, you have a coverage gap that creates manual evidence collection for everything outside the zero trust perimeter. Either expand your zero trust scope or explicitly document compensating controls for out-of-scope systems.

FREQUENTLY ASKED QUESTIONS

Does zero trust satisfy SOC 2 on its own?

No — but it satisfies the majority of the Common Criteria controls within the Security Trust Services Category, which is the mandatory TSC in every SOC 2 engagement. You still need organizational controls (CC1, CC2, CC5 cover governance, communication, and risk assessment) that zero trust does not address technically. Zero trust handles the access and monitoring controls; governance and policy documentation handle the rest.

Which SOC 2 criteria does zero trust most directly satisfy?

CC6.1 (logical access security), CC6.2 (provisioning), CC6.3 (role-based access), CC6.6 and CC6.7 (network restrictions and transmission controls), CC6.8 (session management), CC7.1 (security event detection), and CC7.2 (anomaly monitoring). These eight criteria represent the majority of evidence requests in a typical SOC 2 Type II audit.

Does my auditor need to understand zero trust?

Your auditor needs to understand what your controls do and what evidence they produce — not the specific zero trust terminology. Focus your auditor communication on outcomes and evidence: "Our identity provider enforces MFA for all production access and generates authentication logs" is auditor language. "We have implemented zero trust" is not evidence.

How long does it take to merge zero trust and SOC 2 programs?

The mapping exercise in Step 1 typically takes one to two working sessions. Redirecting evidence collection (Step 2) depends on your tooling — organizations with automated GRC platforms connected to IAM and SIEM can complete this in days. Policy consolidation (Step 3) takes two to four weeks. Shared cadence alignment (Step 4) is a process change that takes one quarter to operationalize. The full merge is achievable in 90 days for most SaaS organizations.

Is zero trust required for SOC 2?

Zero trust is not explicitly required by SOC 2 or the AICPA Trust Services Criteria. However, as Konfirmity's 2026 compliance research confirms, auditors now expect evidence of modern access controls including MFA, network segmentation, and least-privilege policies — all of which are zero trust principles. Not using zero trust does not create a SOC 2 gap, but using it and not documenting the connection means you are doing compliance work that zero trust has already done for you.

STOP RUNNING TWO PROGRAMS FOR ONE GOAL

Every quarter your security team runs access reviews for zero trust and your compliance team runs access reviews for SOC 2 is a quarter you are paying twice for the same outcome. Every policy document that exists in two versions is a version mismatch waiting to become a finding. Every evidence export done manually for an auditor that your SIEM already logged is time your team spent on process instead of security.

The merge is not complicated. Map your controls, redirect your evidence, consolidate your policies, and align your review cadences. Your zero trust architecture becomes your SOC 2 compliance engine — and your next audit becomes the easiest one you have run.

DSALTA's compliance platform connects your zero trust evidence directly to your SOC 2, ISO 27001, and NIST control frameworks — so your security telemetry drives your audit readiness automatically.