MCP server SOC 2 compliance

Which SOC 2 criteria apply to MCP servers

SOC 2 defines five Trust Services Criteria (TSC). Most organisations only scope the ones relevant to their service — including all five is neither required nor always appropriate.

Most enterprise MCP deployments scope Security + Availability, and add Confidentiality if tools access customer data. Processing Integrity and Privacy are typically scoped only when those are the primary service commitments.

Availability criterion (A series)

The Availability TSC requires that the system is available for operation and use as committed. For MCP servers, auditors examine three areas:

A1.1 — Performance capacity monitoring

You need evidence that you monitored system capacity to ensure availability commitments could be met. For MCP servers this means:

• Response time monitoring: p50, p95, p99 latency over the audit period
• Error rate monitoring: percentage of tools/call requests returning errors vs successful completions
• Capacity limits: documented thresholds (e.g., max concurrent connections, request rate limits) and evidence that they weren't regularly exceeded

# Generate monthly availability evidence from AliveMCP API (Team/Enterprise)
curl -H "Authorization: Bearer $ALIVEMCP_TOKEN" \
  "https://alivemcp.com/api/v1/servers/my-data-mcp/report?period=2026-05" \
  | jq '{
      uptime_pct: .availability_pct,
      p95_ms: .response_time_p95_ms,
      p99_ms: .response_time_p99_ms,
      incidents: [.incidents[] | {start: .started_at, duration_min: .duration_minutes, cause: .cause}]
    }'

A1.2 — Environmental protections

Evidence that environmental threats (infrastructure failures, network outages) were mitigated. For MCP servers this means documented HA configuration: multiple availability zones or regions, health checks, and automatic failover — with evidence that the failover actually worked during the period (test run logs or incident-triggered failover records).

A1.3 — Recovery plan testing

You must test your recovery procedures and document the results. Schedule a quarterly "MCP server recovery test" — simulate a server failure, measure actual time to detection and recovery, and compare against your documented RTO. AliveMCP's incident timeline gives you the detection timestamp; your deployment logs give you the recovery timestamp.

Security criterion (CC series)

The Security (Common Criteria) TSC is the broadest and most universally applicable. For MCP servers the key control areas are access control, audit logging, and change management.

CC6.1 — Logical access controls

Authentication and authorization evidence: who can call MCP tools, how is that enforced, and how is access revoked when someone leaves? This maps directly to the SAML SSO and RBAC controls described in adjacent guides. Auditors want to see:

• A list of principals (users, service accounts) with access to each MCP server
• Evidence that the list was reviewed periodically (quarterly access review)
• Evidence of at least one access revocation processed correctly (offboarding record)

# Quarterly access review query
sqlite3 ./data.db <<EOF
SELECT
    email,
    groups_json,
    last_seen_at,
    -- Flag users not seen in 30+ days
    CASE
        WHEN julianday('now') - julianday(last_seen_at) > 30 THEN 'STALE - review'
        ELSE 'active'
    END as status
FROM mcp_users
ORDER BY last_seen_at;
EOF

CC7.1 — Threat detection and monitoring

Auditors want evidence that you monitored for anomalies and had a process to investigate them. For MCP servers, this means:

• Alerting on unusual request volumes (potential abuse of an API key)
• Alerting on repeated auth failures (potential credential stuffing)
• Structured audit logs that make anomalies queryable

CC8.1 — Change management

Every MCP server configuration change, schema update, or deployment must go through a documented change process. At minimum: a ticket or PR that describes the change, approval from a second person, deployment evidence, and a verification test post-deployment. For MCP schema changes (tool additions, removal, or inputSchema updates), the verification step should include a protocol-level probe confirming the new schema is correctly served before closing the change ticket.

Confidentiality criterion (C series)

The Confidentiality TSC requires that information designated as confidential is protected. For MCP servers, this applies when tool arguments or results contain customer data, financial records, or proprietary content. Key controls:

C1.1 — Identification and classification

You need a documented data classification for each MCP tool: does query_customer_records(customer_id) return confidential data? If yes, that tool and its result logs are in scope for Confidentiality controls. The simplest approach is an annotation in your MCP tool registry:

TOOL_DATA_CLASSIFICATION = {
    "search_public_docs": "public",
    "query_customer_records": "confidential",
    "run_internal_query": "internal",
    "export_financial_report": "restricted",
}

@mcp.tool()
async def query_customer_records(customer_id: str, request: Request) -> dict:
    """Retrieve customer account data. Classification: CONFIDENTIAL."""
    user = get_user_context(request)
    # Confidential tool — enforce stricter logging
    result = await _fetch_customer(customer_id)
    # Log access to confidential data without logging the data itself
    audit_log_confidential(user, "query_customer_records",
                           resource_id=customer_id, result_row_count=1)
    return result

C1.2 — Disposal of confidential data

Tool call logs that contain confidential data (even just the fact that a specific customer ID was queried) need a defined retention and disposal policy. Common approach: 90-day hot retention in queryable audit logs, archive to encrypted cold storage for 1-7 years per regulatory requirement, deletion confirmation logged.

Vendor management: third-party MCP servers

One of the most overlooked SOC 2 gaps for teams using MCP: if your production agent pipeline pulls tools from third-party MCP servers (public registries, SaaS vendors), those servers become subprocessors in your data flow. Auditors will ask whether you assessed their availability and security posture.

Minimum vendor management controls for third-party MCP dependencies:

• Inventory: maintain a list of every external MCP server your pipeline depends on, including the URL, the data they process, and your contractual relationship with the vendor.
• Availability assessment: use AliveMCP's public status feed to check the 90-day uptime history of any third-party MCP server before adding it to a production pipeline. A server with 60% uptime in the last 90 days is not vendor-manageable — either it won't pass your vendor review, or it needs a graceful degradation path.
• Annual review: re-check third-party MCP server health annually and document the review. If a vendor's reliability has degraded, update your pipeline to handle that server's unavailability gracefully or switch vendors.

AliveMCP's public dashboard shows the full 90-day uptime history for every public MCP endpoint we monitor — use it as a first-pass vendor availability assessment before the formal vendor review.

Incident response for MCP servers

SOC 2 requires a documented incident response process and evidence that it was followed for incidents that occurred during the audit period. For MCP server incidents:

# Incident response runbook — MCP server outage

## Detection
1. AliveMCP alert fires → routed to on-call via PagerDuty
2. On-call engineer acknowledges within SLA (15 min target for P1)
3. Initial triage: check AliveMCP error type (4xx = auth, 5xx = server, timeout = network)

## Investigation
4. Pull Caddy/Nginx access logs for the last 15 minutes
5. Check application logs for stack traces or OOM signals
6. Check infrastructure metrics (CPU, memory, disk, network)
7. If auth regression: check IdP admin console for policy changes

## Mitigation
8a. Infrastructure failure: restart container / failover to replica
8b. Schema drift: roll back to last known-good deployment
8c. Auth regression: revert IdP policy change or rotate certificate

## Recovery verification
9. AliveMCP shows green (initialize handshake succeeds)
10. Run smoke test: call each registered tool once with test arguments
11. Document root cause in incident ticket

## Post-incident
12. Write 5-line post-mortem within 24h (timeline, cause, fix, prevention)
13. Update monitoring if detection gap found

The detection timestamp from AliveMCP and the acknowledgement timestamp from PagerDuty give you the MTTD (Mean Time to Detect) and acknowledgement time — both numbers auditors look for in CC7.4 evidence.

Further reading

• MCP server audit logging — structured event logs for compliance
• MCP server SAML SSO — enterprise single sign-on and user attribution
• MCP server RBAC — role-based access control for tool-level permissions
• MCP server SLA — uptime commitments, calculations, and reporting
• MCP server incident response — detection, triage, and post-mortem
• MCP server GDPR — data protection compliance for MCP tool handlers
• AliveMCP — continuous protocol monitoring for MCP servers