QuickZTNA
Get started free
Skip to content
Compliance 18 min read · 4,060 words

SOC 2 Controls for Remote Access: 11 You'll Get Audited On

SOC 2 is based on AICPA's Trust Services Criteria. The 11 specific Common Criteria auditors test for VPN, ZTNA, and remote-work deployments.

By QuickZTNA Engineering · Compliance team
SOC 2 Type II FIPS 203 GDPR
Table of contents

TL;DR

SOC 2 is the attestation report most commonly required by enterprise buyers. It is built on AICPA’s Trust Services Criteria (TSC). Remote-access architecture touches eleven specific criteria across the Common Criteria (CC) family — principally CC6 (Logical and Physical Access Controls) and CC7 (System Operations), with supporting references from CC5, CC8, and CC9. This post walks through each of the eleven criteria, what auditors typically ask for, and what evidence a ZTNA or VPN deployment should be able to produce. For your first SOC 2 audit, treat the remote-access chapter of your compliance workbook as a mostly solved problem if you have picked a modern ZTNA product — the controls and evidence drop out of normal operations. If you are on legacy VPN, expect work.

Who this is for

Compliance leads, CISOs, and engineering managers preparing for a first SOC 2 Type II audit or tightening controls for an existing report. Vendor security-review teams who get buyer questionnaires and need to map answers back to SOC 2. Technical readers comfortable with the AICPA TSC vocabulary; if you are new to it, the AICPA Trust Services Criteria page is the canonical reference.

Table of contents

  1. SOC 2 vocabulary in two paragraphs
  2. The Common Criteria that matter for remote access
  3. Control 1 — CC6.1 Logical access security
  4. Control 2 — CC6.2 Access authorisation at onboarding
  5. Control 3 — CC6.3 Access removal at offboarding
  6. Control 4 — CC6.6 Perimeter security controls
  7. Control 5 — CC6.7 Transmission security
  8. Control 6 — CC6.8 Unauthorised software detection
  9. Control 7 — CC7.1 Vulnerability identification
  10. Control 8 — CC7.2 Anomaly monitoring
  11. Control 9 — CC7.3 Incident evaluation
  12. Control 10 — CC7.4 Incident response
  13. Control 11 — CC8.1 Change management
  14. Evidence auditors typically request

1. SOC 2 vocabulary in two paragraphs

Trust Services Criteria. AICPA-maintained framework with five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The Security category is the Common Criteria and is required in every SOC 2 report. The other four are optional — organisations choose which to include based on what they want to attest to and what their customers require.

SOC 2 report. Independent CPA firm’s attestation report describing the service organisation’s system and the suitability of controls. Type I: point-in-time. Type II: over a period (six to twelve months). The report is typically released under NDA to customers and prospects. The auditor issues an opinion (unqualified, qualified, or adverse).

2. The Common Criteria that matter for remote access

Eleven criteria across CC6, CC7, CC5, and CC8 are the relevant ones for remote-access deployments. For the full list, see the AICPA Trust Services Criteria document. Points of focus for each criterion are AICPA-provided implementation guidance, not strict rules; auditors consider them when evaluating whether a control is suitably designed and operating.

Each section below names the criterion, summarises what it requires, describes the typical audit question, and lists evidence that a modern ZTNA deployment generates.

3. Control 1 — CC6.1 Logical access security

What it requires. The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

Audit question. “How do you verify the identity of users accessing protected systems, and how do you protect the authentication mechanism itself?”

Evidence a ZTNA produces.

  • SSO integration with the corporate identity provider — users authenticate to the IdP, not directly to the ZTNA.
  • MFA evidence — logs of MFA challenges and responses per user.
  • Password policy enforcement via IdP.
  • Device posture requirements — disk encryption, OS patch level, EDR presence.
  • Per-session authentication logs with timestamps, user identity, device identity, source IP.

Pitfall. Shared accounts — SOC 2 auditors object to shared accounts. Every user needs a unique identity. If the ZTNA allows named-accounts-only but the corporate infrastructure still has shared service accounts with direct ZTNA access, the auditor will flag it.

4. Control 2 — CC6.2 Access authorisation at onboarding

What it requires. Prior to issuing system credentials and granting system access, the entity registers and authorises new internal and external users whose access is administered by the entity.

Audit question. “Show me the process by which a new employee’s access is authorised. What ticket, what approval, what actual steps?”

Evidence a ZTNA produces.

  • SCIM provisioning — when an IdP creates a user, the ZTNA auto-provisions with default roles.
  • Manual role-grant events logged with approver identity.
  • Time-stamped records of each grant decision.
  • Tickets in ticketing system (Jira, Linear, GitHub Issues) linked to the grant.

Pitfall. The audit expects evidence for every grant, not a sampled subset. Ensure SCIM logs and manual-grant logs are retained.

5. Control 3 — CC6.3 Access removal at offboarding

What it requires. The entity authorises, modifies, or removes access based on roles, responsibilities, or system design, and removes access when access is no longer authorised.

Audit question. “Pick five terminated employees from the past year. Show me that their access was removed within the policy window.”

Evidence a ZTNA produces.

  • SCIM-driven deprovisioning when IdP disables a user.
  • Logs of access revocation with timestamp and cause.
  • Session kill events on the offboarded user’s active tunnels.
  • Audit of dormant accounts (90-day or similar threshold).

Pitfall. Manual offboarding gaps. If a user is removed from the IdP but not from a specific system, the gap shows up as a finding. Automated SCIM reduces the surface.

6. Control 4 — CC6.6 Perimeter security controls

What it requires. The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

Audit question. “What controls prevent unauthorised access from the internet to your internal systems?”

Evidence a ZTNA produces.

  • No internal services exposed to the public internet — all reachable only via authenticated tunnel.
  • Network segmentation — tunnels land users only in the resources their policy permits.
  • Device posture enforced at tunnel establishment.
  • Rate-limiting and anomaly detection on authentication attempts.

Pitfall. “We have a firewall” is not enough. The auditor wants to see the specific policies and the logs that demonstrate enforcement.

7. Control 5 — CC6.7 Transmission security

What it requires. The entity restricts the transmission, movement, and removal of information to authorised internal and external users and processes, and protects it during transmission, movement, or removal.

Audit question. “How is data protected in transit between users and your systems?”

Evidence a ZTNA produces.

  • TLS 1.3 or WireGuard encryption on every tunnel.
  • Per-session kex mode logged (for products that support it).
  • Cipher suite configuration aligned to current guidance (NIST SP 800-52 Rev. 2 for TLS, current WireGuard recommendations).
  • Hybrid post-quantum key exchange where feasible (see our ML-KEM-768 post) — not required for SOC 2 but a credible control improvement.

Pitfall. Using a deprecated protocol (TLS 1.0, TLS 1.1, PPTP). Auditors expect TLS 1.2 minimum; TLS 1.3 preferred.

8. Control 6 — CC6.8 Unauthorised software detection

What it requires. The entity implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software.

Audit question. “How do you prevent unauthorised software from accessing protected systems?”

Evidence a ZTNA produces.

  • Device posture enforcement — only devices with EDR/antivirus active can establish tunnels.
  • Application-level ACLs limiting what can reach which resources.
  • Endpoint-detection integration with ZTNA posture signals.
  • Session termination when posture signal indicates malware.

Pitfall. Posture signals that are never acted on. If posture is checked at tunnel establishment but never re-evaluated during the session, a compromise after establishment goes undetected. Continuous posture evaluation closes this gap.

9. Control 7 — CC7.1 Vulnerability identification

What it requires. To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

Audit question. “How do you identify vulnerabilities in your remote-access infrastructure?”

Evidence a ZTNA produces (for the product itself).

  • Vendor security advisories subscribed to.
  • Client-side vulnerability scanning integrated with endpoint management.
  • Server-side patching logs for self-host deployments.
  • Monitoring for known IOCs (indicators of compromise).

Pitfall. Not patching the ZTNA infrastructure itself. For self-hosted deployments, the ZTNA service is a component that must be patched like any other. For managed deployments, the vendor handles this — document the vendor’s patch cadence as part of the control.

10. Control 8 — CC7.2 Anomaly monitoring

What it requires. The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives.

Audit question. “Show me anomaly detection for remote access. Specifically, how do you know when something unusual is happening?”

Evidence a ZTNA produces.

  • Per-session audit logs forwarded to SIEM.
  • Anomaly detection rules (impossible travel, off-hours access, geo anomalies).
  • Dashboards showing active sessions, session rates, authentication failure rates.
  • Alerts routed to the security operations team.

Pitfall. Logs sent to SIEM but no alerting rules configured. The auditor will ask what fires an alert; “nothing” is a finding.

11. Control 9 — CC7.3 Incident evaluation

What it requires. The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes action to prevent or address such failures.

Audit question. “Pick three security events from the past year. Show me the evaluation that determined whether they were incidents.”

Evidence a ZTNA produces.

  • Ticketing system records of security events reviewed.
  • Documented criteria for classifying events as incidents.
  • Escalation paths with timestamps.
  • Post-review artefacts (five-whys, blameless post-mortem).

Pitfall. No documented criteria. If the evaluation is “we looked at it and it seemed fine”, the auditor cannot test consistency. Write down the criteria.

12. Control 10 — CC7.4 Incident response

What it requires. The entity responds to identified security incidents by executing a defined incident response programme to understand, contain, remediate, and communicate security incidents, as appropriate.

Audit question. “Show me your incident response playbook. Specifically, show me that a recent incident was handled per the playbook.”

Evidence a ZTNA produces.

  • Runbooks for common scenarios (compromised credential, lost device, suspicious tunnel).
  • Kill-switch capability — ability to terminate all sessions for a user or device.
  • Audit-log retention meeting the investigation window.
  • Post-incident review records.

Pitfall. Runbook exists but has not been exercised. Tabletop exercises at least annually; document the exercises.

13. Control 11 — CC8.1 Change management

What it requires. The entity authorises, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

Audit question. “Pick three changes to the remote-access infrastructure from the past year. Show me authorisation, testing, and post-deployment verification for each.”

Evidence a ZTNA produces.

  • Version-controlled policy-as-code (ACL in source control).
  • Change-review PRs or approval tickets.
  • Deployment logs linking change ticket to environment.
  • Post-deployment verification (smoke tests, test-user verification).

Pitfall. ACL changes made directly in the admin UI without the trail. For SOC 2 hygiene, manage ACLs as code where the product supports it; if not, capture every change in a ticketing system.

14. Evidence auditors typically request

A compiled list for a SOC 2 Type II audit scoped on remote access.

  1. Written information security policy referencing remote-access controls.
  2. Access control policy and matrix.
  3. Onboarding and offboarding procedures with sampled evidence.
  4. List of all remote-access users at quarter-end.
  5. List of privileged users and privileged-access reviews.
  6. MFA enrolment evidence per user.
  7. Configuration documentation for the VPN/ZTNA.
  8. Audit logs for a sample period, typically one week.
  9. SIEM alerting rules, configuration, and a sample of alerts with disposition.
  10. Vulnerability scan results for the infrastructure supporting remote access.
  11. Patch records for the past twelve months.
  12. Incident log with incident-response artefacts.
  13. Change-management records for remote-access changes.
  14. BAAs, DPAs, vendor attestation reports for the VPN/ZTNA vendor.
  15. Risk-analysis documentation including the remote-access threat model.
  16. Disaster recovery and business-continuity plans covering remote access.
  17. Training records including remote-access-specific training.

Not every auditor requests every item. Most requests fall into categories 1–14.

Further reading

Try QuickZTNA

QuickZTNA Business and Workforce tiers include audit log export, SSO with FIDO2 MFA, device posture, per-tunnel kex mode logging, and policy-as-code — the eleven Common Criteria above each have a direct product feature. Contact sales for the SOC 2 control-mapping worksheet.

Frequently asked questions

What is SOC 2?
SOC 2 stands for System and Organization Controls 2. It is a voluntary attestation framework developed by the American Institute of Certified Public Accountants (AICPA). A SOC 2 report is issued by an independent CPA firm and assesses a service organisation's controls against the Trust Services Criteria. SOC 2 is commonly required by enterprise customers before signing vendor contracts.
What is the difference between SOC 2 Type I and Type II?
Type I is a point-in-time assessment of control design — whether the controls are appropriately designed as of a specific date. Type II is an assessment over a period, typically six to twelve months, of both control design and operating effectiveness. Most enterprise buyers require Type II before signing material contracts. A Type I is commonly a stepping-stone to the first Type II.
Which Trust Services Criteria apply to remote access?
Primarily the Common Criteria (security) across CC5 through CC9. The CC6 family (Logical and Physical Access Controls) is most directly relevant; CC7 (System Operations) covers detection and incident response; CC5 (Control Activities), CC8 (Change Management), and CC9 (Risk Mitigation) cover the organisational context. If the SOC 2 scope includes Availability or Confidentiality criteria, additional specific controls apply.
Is SOC 2 legally required?
No. SOC 2 is a private-sector attestation framework, not a law or regulation. It is a commercial requirement imposed by enterprise buyers. Many large organisations require SOC 2 Type II from vendors that handle customer data or provide production-critical services. For healthcare you additionally need HIPAA compliance; for financial services, DORA or sector-specific requirements.
How long does getting SOC 2 take?
From a standing start, most organisations reach SOC 2 Type I in three to six months and SOC 2 Type II in twelve to eighteen months (including the Type II observation period of six to twelve months). Teams with existing mature controls can sometimes achieve Type II within nine months. Remote-access controls are usually among the more straightforward technical areas because modern ZTNA products include most of the required controls natively.
Will I fail SOC 2 if my VPN is consumer-grade?
Not automatically, but you will have to produce evidence that the consumer-grade VPN meets the Common Criteria across authentication, access control, audit logging, and incident detection. Most consumer VPN products do not produce this evidence easily. An enterprise VPN or ZTNA with built-in audit logging, device posture, and SIEM integration is a much easier path through the audit.
QuickZTNA Engineering Compliance team
#soc-2 #compliance #trust-services-criteria #ztna #remote-access
Share X / Twitter LinkedIn