Control template: SOC 2 Type II Trust Services Criteria

Status: Public Beta · Version: soc2-type-ii/v0.1.0-beta

A bundle of CALM control snippets covering the architecturally enforceable subset of the AICPA 2017 Trust Services Criteria (TSC) that SOC 2 Type II auditors test. You copy these into your *.calm.json files on the nodes that are in your SOC 2 audit scope.

Who SOC 2 applies to

Any service organization that wants to demonstrate to customers (usually enterprise customers via security questionnaires or vendor- risk assessments) that it maintains effective controls over relevant trust criteria. There is no regulatory requirement for SOC 2 — it's buyer-driven. Common drivers: - SaaS companies selling to enterprise / Fortune 500 - Cloud service providers, MSPs, MSSPs - Payment processors, fintech infrastructure - Healthcare-adjacent SaaS that also pursues HITRUST - Anyone responding to "send us your SOC 2" in a procurement RFP

What this template covers

The 2017 TSC has 5 categories. Only Security (CC1–CC9 Common Criteria) is mandatory for every audit; the other four (Availability, Processing Integrity, Confidentiality, Privacy) are optional and only in scope if the firm elects to include them.

The architectural surface lives mostly in CC6 (Logical Access), CC7 (System Operations), and CC8 (Change Management). CC1–CC5 are governance and process — document those in your SOC 2 readiness package, not in your CALM.

TSC Criterion	Architectural surface	Control alias
CC6.1	Logical access security	`soc2-logical-access`
CC6.2	Identification and authentication	`soc2-authentication`
CC6.3	Role-based authorization	`soc2-rbac`
CC6.6	Restricted access to system resources	`soc2-restricted-access`
CC6.7	Transmission security (encryption in transit)	`soc2-transmission-security`
CC6.8	Threat protection (anti-malware, IDS)	Out of architectural scope — pair with Crowdstrike etc.
CC7.1	System monitoring	`soc2-system-monitoring`
CC7.2	Security event logging	`soc2-security-event-logging`
CC7.3	Incident response	`soc2-incident-response`
CC7.4	Recovery of system operations	`soc2-recovery-operations`
CC8.1	Change management	`soc2-change-management`
A1.1 (optional)	Availability monitoring + capacity	`soc2-availability`
C1.1 (optional)	Confidentiality designation	`soc2-confidentiality`

11 controls in the mandatory Security category + 2 controls in the most common optional categories (Availability + Confidentiality). Skip the optional ones if you haven't elected those categories.

The audit-scope pattern

A node is SOC 2-in-scope if it is part of the system boundary defined in your auditor's report. Tag those nodes:

{
  "unique-id": "tenant-data-api",
  "node-type": "service",
  "name": "Tenant Data API",
  "metadata": {
    "soc2-in-scope": true,
    "soc2-categories": ["security", "availability", "confidentiality"],
    "data-classification": "customer-confidential"
  }
}

Then attach the relevant controls below.

Control snippets

Copy each block under the controls key of the node it applies to.

CC6.1 — Logical access security (`soc2-logical-access`)

Per-node.

"soc2-logical-access": {
  "description": "SOC 2 TSC CC6.1 — logical access security software and procedures restrict access to information assets, data, software, and physical resources.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/logical-access",
      "config": {
        "control-id": "soc2-logical-access",
        "access-mechanism": "saml-sso-plus-mfa",
        "identity-provider": "okta",
        "session-timeout-minutes": 30,
        "access-review-frequency": "quarterly"
      }
    }
  ]
}

CC6.2 — Authentication (`soc2-authentication`)

Per-node.

"soc2-authentication": {
  "description": "SOC 2 TSC CC6.2 — prior to issuing credentials, the entity registers and authorizes new internal and external users. MFA required for human access.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/authentication",
      "config": {
        "control-id": "soc2-authentication",
        "factor-count": 2,
        "factor-types": ["password", "totp-or-webauthn"],
        "user-registration-document-url": "https://internal.example.com/soc2/user-registration",
        "service-account-auth": "mtls-or-oauth2-client-credentials"
      }
    }
  ]
}

CC6.3 — RBAC (`soc2-rbac`)

Per-node.

"soc2-rbac": {
  "description": "SOC 2 TSC CC6.3 — entity authorizes, modifies, or removes access to data, software, functions based on roles, responsibilities, or system design.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/rbac",
      "config": {
        "control-id": "soc2-rbac",
        "principle": "least-privilege",
        "allowed-roles": ["tenant-read", "tenant-write", "tenant-admin", "support-read-only"],
        "review-frequency": "quarterly",
        "joiner-mover-leaver-process-url": "https://internal.example.com/soc2/jml"
      }
    }
  ]
}

CC6.6 — Restricted access (`soc2-restricted-access`)

Per-node.

"soc2-restricted-access": {
  "description": "SOC 2 TSC CC6.6 — entity implements logical access controls to prevent or detect unauthorized access to system resources.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/restricted-access",
      "config": {
        "control-id": "soc2-restricted-access",
        "network-segmentation": "vpc-private-subnets",
        "production-access-controls": ["jump-host-required", "session-recording", "approval-workflow"],
        "exception-policy-url": "https://internal.example.com/soc2/exceptions"
      }
    }
  ]
}

CC6.7 — Transmission security (`soc2-transmission-security`)

Relationship-level. Attach to edges that cross trust boundaries.

// On a relationship:
"controls": {
  "soc2-transmission-security": {
    "description": "SOC 2 TSC CC6.7 — entity restricts transmission of information to authorized internal/external users and processes; in-transit encryption required across trust boundaries.",
    "requirements": [
      {
        "requirement-url": "https://archrails.io/catalog/req/soc2/transmission-security",
        "config": {
          "control-id": "soc2-transmission-security",
          "minimum-tls-version": ["1.2", "1.3"],
          "forbidden-protocols": ["http", "ftp", "telnet", "smtp-plain", "ws"],
          "mutual-auth-on-organization-boundary": true
        }
      }
    ]
  }
}

CC7.1 — System monitoring (`soc2-system-monitoring`)

Per-node.

"soc2-system-monitoring": {
  "description": "SOC 2 TSC CC7.1 — entity uses detection and monitoring procedures to identify (1) changes to configurations and (2) susceptibility to new vulnerabilities.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/system-monitoring",
      "config": {
        "control-id": "soc2-system-monitoring",
        "config-drift-monitoring": true,
        "vulnerability-scanning-frequency": "weekly",
        "alerting-target": "ops-soc@example.com",
        "runbook-url": "https://internal.example.com/soc2/runbooks/monitoring"
      }
    }
  ]
}

CC7.2 — Security event logging (`soc2-security-event-logging`)

Per-node.

"soc2-security-event-logging": {
  "description": "SOC 2 TSC CC7.2 — entity monitors system components for anomalies indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/security-event-logging",
      "config": {
        "control-id": "soc2-security-event-logging",
        "events": ["auth-success", "auth-failure", "privilege-elevation", "config-change", "data-export", "policy-violation"],
        "destination": "centralized-siem",
        "immutable": true,
        "retention-days": 365
      }
    }
  ]
}

CC7.3 — Incident response (`soc2-incident-response`)

Graph-level.

"metadata": {
  "controls": {
    "soc2-incident-response": {
      "description": "SOC 2 TSC CC7.3 — entity evaluates security events to determine whether they could or have resulted in a failure to meet its objectives; takes action accordingly.",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/soc2/incident-response",
          "config": {
            "control-id": "soc2-incident-response",
            "plan-document-url": "https://internal.example.com/soc2/ir-plan",
            "tested-annually": true,
            "last-test-date": "2025-03-15",
            "escalation-roster-url": "https://internal.example.com/soc2/oncall",
            "customer-notification-policy-url": "https://internal.example.com/soc2/breach-notification"
          }
        }
      ]
    }
  }
}

CC7.4 — Recovery of system operations (`soc2-recovery-operations`)

Per-node.

"soc2-recovery-operations": {
  "description": "SOC 2 TSC CC7.4 — entity has procedures and capabilities to recover the system in a timely manner after a failure, including identification of recovery objectives and testing.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/recovery-operations",
      "config": {
        "control-id": "soc2-recovery-operations",
        "rpo-minutes": 60,
        "rto-minutes": 240,
        "backup-frequency": "daily",
        "restoration-test-frequency": "annual",
        "last-restoration-test-date": "2025-04-10"
      }
    }
  ]
}

CC8.1 — Change management (`soc2-change-management`)

Graph-level (declares the firm's change-management policy).

"metadata": {
  "controls": {
    "soc2-change-management": {
      "description": "SOC 2 TSC CC8.1 — entity authorizes, designs, develops, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/soc2/change-management",
          "config": {
            "control-id": "soc2-change-management",
            "policy-document-url": "https://internal.example.com/soc2/change-mgmt",
            "protected-branches": ["main", "production"],
            "review-required": true,
            "minimum-reviewers": 1,
            "deployment-approval-required": true,
            "approver-cannot-be-author": true
          }
        }
      ]
    }
  }
}

A1.1 (optional category) — Availability (`soc2-availability`)

Per-node. Include only if Availability is in your audit scope.

"soc2-availability": {
  "description": "SOC 2 TSC A1.1 (Availability category, optional) — entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable the implementation of additional capacity.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/availability",
      "config": {
        "control-id": "soc2-availability",
        "sla-uptime-percent": 99.9,
        "capacity-monitoring": "auto-scaling-and-alarms",
        "capacity-review-frequency": "monthly",
        "redundancy-zones": 3,
        "status-page-url": "https://status.example.com"
      }
    }
  ]
}

C1.1 (optional category) — Confidentiality (`soc2-confidentiality`)

Per-node. Include only if Confidentiality is in your audit scope.

"soc2-confidentiality": {
  "description": "SOC 2 TSC C1.1 (Confidentiality category, optional) — entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/soc2/confidentiality",
      "config": {
        "control-id": "soc2-confidentiality",
        "data-classification-applied": "customer-confidential",
        "encryption-at-rest": "AES-256-GCM",
        "encryption-in-transit": "tls-1.2-or-1.3",
        "access-restricted-to-roles": ["tenant-admin", "support-escalation"],
        "data-retention-policy-url": "https://internal.example.com/soc2/data-retention",
        "data-disposal-procedure-url": "https://internal.example.com/soc2/data-disposal"
      }
    }
  ]
}

What the engine enforces

Same constraint engine that handles PCI / DORA / SOX / HIPAA / your own controls. Per-rule behavior:

Presence-shape rules (logical-access, authentication, RBAC, monitoring, etc.): the engine fires a finding when a node tagged soc2-in-scope: true does NOT declare the corresponding control.
Value-constrained rules (TLS version, retention days, RPO/RTO, SLA uptime): the engine checks the config value.
Relationship-level rules (transmission-security): the engine walks edges and fires when a cross-boundary edge lacks the required protection.

All deterministic — pure function over your CALM JSON. Verdicts are replayable byte-for-byte.

Type I vs Type II

Type I assesses the design of controls at a point in time — "do you have the controls defined?"
Type II assesses the operating effectiveness of controls over a period (usually 6–12 months) — "have your controls operated as designed throughout the period?"

This template helps with both, but more so with Type I (design) because that's what an architecture declaration captures. Type II requires evidence over time (logs, exception records, test results), which is your SOC 2 readiness program's job — not architectural. Your auditor's testing of operating effectiveness is the Type II story.

Auto-include during bootstrap (coming)

A future release will let archrails bootstrap detect SOC 2-relevant repos and offer to auto-include this template. Until that ships, copy-paste.

Versioning

This is soc2-type-ii/v0.1.0-beta. Pre-1.0 = beta. Bumps to v1.0.0 per the GA criteria above. Updates as AICPA publishes new points of focus or revises the TSC.

Out of scope for this template

Governance criteria (CC1–CC5) — control environment, communication, risk assessment, monitoring activities, control activities. These are organizational and process-based; document in your SOC 2 readiness package.
CC6.8 (threat protection) — anti-malware, IDS endpoint controls are out of architectural scope; pair with Crowdstrike / SentinelOne / similar.
Privacy category (P1–P8) — the Privacy category overlaps with GDPR / HIPAA / CCPA; if you've elected Privacy in scope, see the GDPR template or work with your readiness advisor.
Type II evidence over the audit period — operating- effectiveness testing happens in your auditor's workpapers, not in CALM.
The SOC 2 report itself — your CPA firm authors and signs the report; ArchRails does not produce or sign SOC 2 reports.

For those surfaces, pair this template with your SOC 2 readiness program and engage a CPA firm for the audit.

Control template: SOC 2 Type II Trust Services Criteria

Who SOC 2 applies to

What this template covers

The audit-scope pattern

Control snippets

CC6.1 — Logical access security (soc2-logical-access)

CC6.2 — Authentication (soc2-authentication)

CC6.3 — RBAC (soc2-rbac)

CC6.6 — Restricted access (soc2-restricted-access)

CC6.7 — Transmission security (soc2-transmission-security)

CC7.1 — System monitoring (soc2-system-monitoring)

CC7.2 — Security event logging (soc2-security-event-logging)

CC7.3 — Incident response (soc2-incident-response)

CC7.4 — Recovery of system operations (soc2-recovery-operations)

CC8.1 — Change management (soc2-change-management)

A1.1 (optional category) — Availability (soc2-availability)

C1.1 (optional category) — Confidentiality (soc2-confidentiality)

What the engine enforces

Type I vs Type II

Auto-include during bootstrap (coming)

Versioning

Out of scope for this template

CC6.1 — Logical access security (`soc2-logical-access`)

CC6.2 — Authentication (`soc2-authentication`)

CC6.3 — RBAC (`soc2-rbac`)

CC6.6 — Restricted access (`soc2-restricted-access`)

CC6.7 — Transmission security (`soc2-transmission-security`)

CC7.1 — System monitoring (`soc2-system-monitoring`)

CC7.2 — Security event logging (`soc2-security-event-logging`)

CC7.3 — Incident response (`soc2-incident-response`)

CC7.4 — Recovery of system operations (`soc2-recovery-operations`)

CC8.1 — Change management (`soc2-change-management`)

A1.1 (optional category) — Availability (`soc2-availability`)

C1.1 (optional category) — Confidentiality (`soc2-confidentiality`)