Introduction
Mapping Zero Trust controls to SOC 2 evidence means taking the Zero Trust practices your team already runs, such as strong identity checks, device posture rules, segmentation, continuous verification, and least privilege, and showing which SOC 2 criteria each one supports and which dated records prove it operated.
Start with the most important point: SOC 2 does not require Zero Trust. The AICPA Trust Services Criteria describe outcomes, not a required architecture. Zero Trust is a common security approach, and when it runs well, it can produce strong evidence for criteria such as CC6.1, CC6.6, CC6.8, and CC7.2. You still have to show that evidence. A diagram labeled "Zero Trust" is not proof that any control operated.
Many teams adopt Zero Trust for practical reasons: remote work, SaaS-heavy stacks, and cloud workloads with no clear network perimeter. Then the audit arrives and the question changes from "is our architecture modern?" to "which record shows this control worked on a sampled date?" Without a crosswalk, teams either over-claim ("we are Zero Trust, so access is covered") or fail to use the evidence they already have.
In plain language: this guide is a crosswalk. For each common Zero Trust practice, it shows related SOC 2 criteria themes and the artifacts that tend to hold up in sampling. Related pages include What Is Least Privilege?, What Is Multi-Factor Authentication?, What Is Logical Access?, SOC 2 Trust Services Criteria Explained, and Mapping Controls Across SOC 2 and ISO 27001.
What Zero Trust Means
NIST SP 800-207, Zero Trust Architecture, describes zero trust as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. No user account or device is trusted only because of its network location or who owns it. Authentication and authorization happen before a session to a resource is established.
NIST lists seven tenets. In short:
- All data sources and computing services are treated as resources.
- All communication is secured regardless of network location.
- Access to each resource is granted per session, with least privilege.
- Access is decided by dynamic policy that uses identity, the state of the requesting device, and other attributes.
- The organization monitors and measures the integrity and security posture of all owned and associated assets.
- Authentication and authorization are dynamic and strictly enforced before access is allowed.
- The organization collects information about assets, network traffic, and access requests and uses it to improve its security posture.
NIST also notes that these tenets are an ideal goal and that not every tenet may be fully implemented in its purest form for a given strategy. That matters for audits. Most companies run some Zero Trust practices, not all of them, and the evidence should describe what you actually do.
The architecture separates the decision from the enforcement. A policy engine decides whether to grant access, and a policy administrator carries out that decision by setting up or closing the connection path. A policy enforcement point enables, monitors, and ends the connection. In many SaaS-first companies, the identity provider's sign-in and conditional access policies play the decision role, and an access proxy, gateway, or application setting enforces it.
What SOC 2 Requires vs Common Practice
Keep the criteria and the architecture apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include several criteria that Zero Trust practices commonly support:
- CC6.1: logical access security software, infrastructure, and architectures over protected information assets.
- CC6.2: registering and authorizing users before issuing credentials, and removing access when it is no longer authorized.
- CC6.3: authorizing, modifying, or removing access based on roles and responsibilities, considering least privilege and segregation of duties.
- CC6.6: logical access security measures to protect against threats from sources outside the system boundaries.
- CC6.7: restricting the transmission, movement, and removal of information to authorized users and processes, and protecting it in transit.
- CC6.8: preventing, or detecting and acting on, unauthorized or malicious software.
- CC7.1: detection and monitoring procedures to identify configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities.
- CC7.2: monitoring system components for anomalies that indicate malicious acts, natural disasters, and errors.
The 2022 revision of the points of focus mentions zero trust architectures as one technique alongside network segmentation for isolating unrelated parts of the environment under CC6.1. Points of focus are illustrative guidance, not a checklist. Naming Zero Trust there does not make it a requirement.
What is common practice, not a fixed SOC 2 rule:
- A written Zero Trust strategy or roadmap
- Replacing a VPN with identity-aware access
- Device posture checks at sign-in
- Microsegmentation of workloads
- Risk-based reauthentication during a session
- Any specific vendor, product, or maturity level
SOC 2 lets you choose your controls and then tests whether they were designed and operated as described. If Zero Trust is how you meet a criterion, write the control that way and keep the records that prove it.
Why a Crosswalk Helps
A short mapping document pays off in several ways:
- It prevents over-claiming. Each practice maps to specific criteria themes, not to "all of CC6."
- It reuses evidence. One identity provider policy export can support several criteria at once.
- It shows gaps. Policies often cover workforce sign-ins but miss service accounts, contractors, or legacy systems.
- It speeds sampling. Auditors can see where each artifact lives and how often it is produced.
- It gives control owners a clear job. Each row has an owner and a system of record.
The Crosswalk at a Glance
The criteria listed below are common mappings, not official AICPA mappings. Your auditor and your control design decide the final mapping.
| Zero Trust practice | Related SOC 2 criteria (common mapping) | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Strong identity and MFA | CC6.1, CC6.2, CC6.6 | Dated identity provider policy export showing MFA enforcement, approved factors, and approved exemptions | Undated screenshot of one MFA setting |
| Device posture and managed devices | CC6.1, CC6.7, CC6.8 | Device management enrollment compared with headcount, posture rules, sign-in logs showing blocked noncompliant devices | Statement that "all laptops are managed" |
| Segmentation and microsegmentation | CC6.1, CC6.6 | Dated network or account diagram, security group and firewall rule exports, rule change tickets | Diagram from two years ago |
| Continuous verification | CC6.1, CC6.6, CC7.2 | Session lifetime and reauthentication settings, risk policy configuration, risk events with response tickets | Vendor brochure describing the feature |
| Least privilege and just-in-time access | CC6.1, CC6.3 | Role catalog, privileged access requests with approval and expiry, access review results | Standing admin rights for most engineers |
| Encrypted communication everywhere | CC6.1, CC6.7 | TLS configuration, service-to-service encryption settings, certificate inventory | Assumption that internal traffic is safe |
| Asset visibility and posture monitoring | CC6.1, CC7.1, CC7.2 | Asset inventory export, scan coverage, log source list, alert review records | Unreviewed dashboards |
| Access policy changes | CC6.1, CC8.1 | Policy changes made through pull requests or tickets with approvals | Console edits with no record |
The sections below cover the main practices in more detail.
Identity and Multi-Factor Authentication
Identity is the center of most Zero Trust programs. Every access decision starts with who, or what, is asking.
What auditors may look for:
- How users are registered and approved before getting credentials
- Whether multi-factor authentication is enforced, and for which apps and roles
- How exemptions are approved and reviewed
- How access is removed when people leave
Evidence that holds up:
- A dated export of sign-in and MFA policies from the identity provider
- A list of accounts exempt from MFA, each with an approval and review date
- Onboarding and offboarding tickets that match identity provider events
- Single sign-on coverage for in-scope applications, with known gaps documented
Device Posture
Zero Trust asks whether the device is healthy, not only whether the user is valid. Common posture checks include disk encryption, a supported operating system, screen lock, and an endpoint protection agent that is running.
What auditors may look for:
- A defined standard for what a compliant device is
- How the standard is enforced at access time
- What happens to unmanaged or personal devices
Evidence that holds up:
- Device management enrollment counts compared with active staff
- The posture policy and the conditional access rule that applies it
- Sign-in logs showing blocked or limited access for noncompliant devices
- Endpoint protection coverage reports tied to CC6.8 malware themes
Segmentation
Segmentation limits how far an attacker can move. Zero Trust pushes it closer to each resource, sometimes down to individual workloads.
What auditors may look for:
- Separation between production and non-production
- Rules that restrict traffic between environments and services
- How rule changes are approved
Evidence that holds up:
- A current diagram with an approval or review date
- Exports of cloud security groups, network policies, or firewall rules
- Change tickets or pull requests for rule changes
- Separate cloud accounts or projects for production, with restricted access
Continuous Verification
Continuous verification means trust is checked again during a session, not only at sign-in. Triggers can include time limits, a request for a new resource, or unusual activity.
What auditors may look for:
- Session lifetime and reauthentication settings
- How risky sign-ins or anomalies are detected
- How the team responds when they fire
Evidence that holds up:
- Session and token lifetime configuration from the identity provider
- Risk-based policy settings, such as step-up authentication rules
- Logged risk events with triage notes or tickets
- Alert review records that connect to monitoring and incident management
Least Privilege and Just-in-Time Access
Zero Trust grants the minimum access for the task, often for a limited time. This aligns closely with least privilege and role-based access control.
What auditors may look for:
- How roles are defined and approved
- How privileged access is requested, approved, and removed
- Whether periodic reviews catch access that drifted
Evidence that holds up:
- A role catalog with owners
- Privileged access requests with approver, reason, and expiry
- User access review results with removals carried out
- Reports showing standing admin accounts kept to a small, named group
Policy Changes Are Evidence Too
Zero Trust policies change often. A new app gets added to conditional access, a rule gets loosened for a launch, or a network policy gets tightened after an incident. Each change can weaken or strengthen several controls at once.
Treat access policy changes like other production changes:
- Manage policies as code where your tools allow it, with reviewed pull requests
- Otherwise, require a ticket with approval before console changes
- Keep the identity provider and cloud audit logs that record each change
- Link emergency changes to a later review
See Change Management Evidence for SOC 2 for the broader change trail.
Do Not Forget Non-Human Identities
Service accounts, API keys, CI/CD tokens, and workload identities often sit outside workforce Zero Trust policies. They can also hold broad access.
For evidence, keep:
- An inventory of service accounts and keys with named owners
- Scopes and permissions for each
- Rotation records or short-lived credential settings
- Removal records when a service or integration is retired
Example Scenario
A labeled hypothetical: a company replaces its VPN with identity-aware access for internal tools. Access now requires single sign-on, MFA, and a managed device that meets posture rules.
During a Type 2 audit, the auditor samples three dates and asks how access to the admin console was controlled on each. Strong evidence includes:
- The policy version that was active on each date, from the identity provider's change history
- Sign-in logs showing a blocked attempt from an unmanaged device
- An approved, time-bound exception for one contractor using a browser-only session
- The pull request that added the admin console to the access policy, with reviewer approval
Weak evidence would be a current screenshot of the policy with no history, which shows today's design but not how it operated during the period.
Common Mistakes and Why Teams Struggle
- Claiming Zero Trust covers all of CC6 without mapping each control
- Policies that apply to workforce users but skip service accounts and contractors
- Device posture rules in report-only mode, with no enforcement
- MFA exemptions with no approval or review date
- Segmentation diagrams that no longer match the cloud environment
- Access policy edits in a console with no ticket or review
- Risk alerts that fire but have no triage record
- Keeping only current-state screenshots, with no history across the period
These patterns create audit friction and real security gaps.
Operating Model: Build and Run the Crosswalk
1. List the practices you actually run
Write down your real Zero Trust practices, not the roadmap. Note where each one applies and where it does not.
2. Map each practice to criteria and controls
Link each practice to your written SOC 2 controls and the criteria they support. Use common mappings as a starting point, then confirm with your auditor.
3. Name an owner and system of record
Each row needs an owner and a place where evidence lives, such as the identity provider, device management tool, cloud account, or ticket system.
4. Set an evidence cadence
Decide how often you export policies, review exemptions, and check coverage. Write the cadence into the control.
5. Govern exceptions
Record every exemption from MFA, posture, or segmentation rules as a governed exception with an owner and expiry.
6. Route policy changes through change management
Require review for access, posture, and network policy changes, and keep the audit logs.
7. Check coverage gaps
Look for service accounts, contractors, legacy systems, and new apps outside the policies. Fix them or document why they are out of scope.
8. Run an internal sample before fieldwork
Pick a few dates in the period and confirm you can show the active policy, a related log, and any exceptions for each. Fix gaps, then re-export.
Type 1 vs Type 2 Considerations
For Type 1, auditors look at whether controls are suitably designed and in place at a point in time. Current policy exports, diagrams, and the crosswalk itself can support that.
For Type 2, auditors test operation over the period. Policy history, sign-in logs, exception records, and change tickets across the window matter more than any single snapshot. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for control artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as Okta, Azure AD, Google Workspace, AWS, CrowdStrike, GitHub, and Jira.
The focus is organizing dated proof so identity policy changes, access events, endpoint status, and change tickets can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the security architecture your organization defines. It does not design or enforce Zero Trust policies, does not make access decisions, 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
Zero Trust is a common way to meet SOC 2 access and monitoring criteria, not a requirement of SOC 2. The value for audits comes from mapping each practice to specific criteria, naming owners, and keeping dated records: policy history, sign-in and posture logs, segmentation rule exports, privileged access approvals, exceptions, and change tickets. Map what you actually run, cover non-human identities, and keep history across the period.
If you are building the broader readiness path, start from What Is Access Control?, What Are the Trust Services Criteria?, What Is Control Mapping?, and how to prepare for a SOC 2 audit.
FAQ
Does SOC 2 require Zero Trust?
No. The Trust Services Criteria describe outcomes, such as restricting logical access and protecting against outside threats, without requiring a specific architecture. The 2022 points of focus mention zero trust architectures as one segmentation technique, but points of focus are illustrative, not mandatory. Many organizations meet the criteria with other designs.
Does a Zero Trust architecture cover all of CC6?
Not by itself. Zero Trust practices often support CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, and CC6.8, but you still need written controls and evidence that each operated. Physical access (CC6.4) and asset disposal (CC6.5) usually need separate controls.
Do we need a VPN for SOC 2?
SOC 2 does not require a VPN or forbid one. What matters is that remote and outside access is restricted and protected as your controls describe. Identity-aware access can replace a VPN if your evidence shows it works.
Which criteria do Zero Trust practices usually map to?
Common mappings include CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, and CC6.8 for access and device controls, CC7.1 and CC7.2 for monitoring, and CC8.1 for policy changes. Confirm the mapping with your auditor.
Can one export support several criteria?
Yes. A dated identity provider policy export can support CC6.1, CC6.2, and CC6.6 at once. Map it once, store it once, and reference it from each control.
What evidence is weakest for Zero Trust controls?
Current-state screenshots with no date, diagrams that no longer match the environment, and vendor feature descriptions. Auditors testing a Type 2 period need history.
Does AuditFlo implement Zero Trust?
No. AuditFlo helps organize evidence and readiness artifacts from systems you already use. It does not enforce access policies, replace your identity or security tools, or replace your auditor.