MCP server SOC 2 Type II security: trust service criteria, CC6, and evidence collection

When does an MCP server enter SOC 2 scope?

SOC 2 scope encompasses all systems that store, process, or transmit customer data in support of the services under examination. An MCP server enters scope when it:

• Provides tool access to systems containing customer data (CRM, support tickets, analytics, databases)
• Is part of the production infrastructure serving customers — even as an internal orchestration layer
• Processes inputs or outputs that include customer-identifiable data
• Is operated by a third-party vendor used to deliver the service (subservice organization scope)

CC6: Logical and Physical Access Controls

CC6 is the most directly applicable trust service criterion for MCP servers. The criteria require that access to system resources is restricted to authorized users and that access is granted based on least-privilege principles.

• CC6.1: Logical access security software, infrastructure, and architectures have been implemented to support (1) identification and authentication of authorized users, (2) restriction of authorized user access to system components or resources, and (3) prevention and detection of unauthorized access. For MCP servers: per-tool authorization checks, short-lived session tokens, audit logging of all tool invocations.
• CC6.2: Prior to issuing system credentials and granting system access, authorized user access is registered and authorized using the organization's change-control process. For MCP servers: documented onboarding of new tool consumers (agents), access review process for agent personas and their tool permissions.
• CC6.3: The organization removes access to protected information assets when no longer needed. For MCP servers: when an agent persona is decommissioned, its credentials and tool permissions must be revoked — not just the agent, but any API keys the MCP server uses on behalf of that agent.
• CC6.6: Logical access security measures restrict access to information assets, including those in the cloud environment. For MCP servers in containerized environments: network policies restricting MCP server egress, service mesh mTLS between agent orchestrator and MCP servers.

CC7: System Operations and Monitoring

CC7 requires detection and response to security events. For MCP servers:

• CC7.1: To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations or the introduction of new vulnerabilities. For MCP servers: automated dependency scanning (npm audit, Dependabot), configuration drift detection, SkillAudit scans on every PR touching the MCP server code.
• CC7.2: 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. For MCP servers: structured audit logs with anomaly detection (unusual tool call rates, calls from unexpected IP ranges, failed authorization attempts).
• CC7.3: The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives, and if so, takes actions to prevent or address such failures. For MCP servers: incident response runbook that includes MCP-specific indicators (prompt injection detection, SSRF attempt logs, credential access anomalies).

CC8: Change Management

CC8 requires that changes to system components are authorized, tested, and reviewed before implementation. For MCP servers this means:

• No direct production deployments — all MCP server changes go through a code review and CI pipeline
• Security testing (including SkillAudit scan) is a required gate before deployment of new tool implementations
• Rollback capability: the ability to revert to the previous MCP server version without data loss if a change introduces a vulnerability
• Change log: documented record of all MCP server version deployments, including what changed and who approved

Evidence collection: what SOC 2 auditors look for in MCP servers

Your auditor will request evidence demonstrating that controls are operating effectively over the audit period (typically 6–12 months). For MCP servers, collect:

• Access control evidence: Sample of audit log entries showing per-tool authorization checks; access review records showing agent permissions are reviewed quarterly
• Monitoring evidence: Alert configurations for unusual MCP tool call patterns; sample incident tickets where an alert was investigated
• Change management evidence: PR merge history for MCP server code changes; security scan results (SkillAudit reports) attached to deployment records
• Vulnerability management evidence: npm audit outputs; Dependabot PR merge logs; SkillAudit grade history showing remediation of findings
• Incident response evidence: Documented MCP-specific incident response procedure; table-top exercise records if conducted

SkillAudit's role in the SOC 2 evidence package

SkillAudit scans provide third-party security assessment evidence for the CC8 (change management) and CC7.1 (vulnerability management) criteria. The Team plan generates a dated, signed audit report for each scan — suitable for inclusion in your SOC 2 evidence package. The report includes finding severity classifications (Blocker/Major/Minor) aligned with CVSS scoring, which auditors can map to your organization's risk tolerance thresholds.

Running SkillAudit on every production MCP server deployment creates an audit trail showing that security testing was performed before each change was promoted — directly satisfying the CC8 testing requirement.

Related: MCP server audit trails for SOC 2 and GDPR · MCP server GDPR compliance · MCP security review checklist