Overview
Generate Trust Services Criteria-aligned policy documents for SOC 2 audit readiness. Produces 8 core policies (Information Security, Access Control, Change Management, Incident Response, Risk Assessment, Vendor Management, Business Continuity, Data Classification) plus optional Privacy and Processing Integrity policies — each tailored to organizational context with TSC criteria mapping, named roles, and specific systems.
SOC 2 auditors expect formal, documented policies that establish the governance framework for the control environment. Policies define organizational intent and requirements — the “why” and “what” — while controls and procedures implement those requirements. This skill generates policies that reference actual systems, named roles, and specific regulatory obligations from the organization profile, not generic placeholders.
Getting Started
Add your source materials to the project workspace — organization profile, risk register, and any existing policies — then activate the SOC 2 Policy Generator skill. The agent generates each policy in order (POL-001 through POL-008, plus optional POL-009/010), validates each for completeness, and checks overall TSC coverage.
Example Conversation
Below is an example of how a typical policy generation session unfolds. The agent generates policies tailored to the organization’s context and validates each one for structural completeness and TSC coverage.
You: Generate all required policies for our SOC 2 Type II engagement. We’re in scope for Security and Availability.
Agent: I’ve loaded the organization profile and risk register. I’ll generate 8 core policies in order, starting with the umbrella Information Security Policy. Since Privacy and Processing Integrity are not in scope, I’ll skip POL-009 and POL-010.
Starting with POL-001 Information Security Policy — this is the governing document that all other policies reference. I’ve drafted it with:
- Document metadata: POL-001 v1.0, owner Sarah Chen (CISO), approver Michael Torres (CTO)
- 14 policy statements covering governance, risk management, compliance, and continuous improvement
- TSC mapping to CC1.1–CC1.5, CC2.1–CC2.3
- Named roles: CISO, CTO, Compliance Lead, Engineering Managers
- References to actual systems: Okta, AWS, GitHub, Datadog
Let me validate. [Runs policy_completeness_checker] Result: PASS. All 10 required sections present. No vague language detected. Named roles referenced throughout.
You: Continue with the remaining policies.
Agent: I’ve generated all 8 policies. Running the completeness checker on each:
- POL-001 Information Security: PASS
- POL-002 Access Control: PASS
- POL-003 Change Management: PASS
- POL-004 Incident Response: WARNING — notification SLA says “promptly” instead of a specific timeframe. Updating to “within 72 hours of confirmation” to match service commitments.
- POL-005 Risk Assessment: PASS
- POL-006 Vendor Management: PASS
- POL-007 Business Continuity: PASS
- POL-008 Data Classification: PASS
After fixing POL-004, running the TSC mapper across all policies. [Runs policy_tsc_mapper] Coverage: 100% of in-scope TSC criteria (CC1–CC9, A1) are addressed by at least one policy. Cross-reference with organization profile confirmed — all policies reference actual systems, roles, and regulatory obligations.
All 8 policies saved to the output directory. Dashboard updated: 8 policies generated, 100% TSC policy coverage.
Sample Output Excerpt
Below is a representative excerpt from a generated Access Control Policy, showing the structured format with TSC mapping, named roles, and specific systems.
POL-002 — Access Control Policy
Document ID: POL-002 | Version: 1.0 | Classification: Internal Owner: Sarah Chen (CISO) | Approver: Michael Torres (CTO) Effective Date: 2025-07-01 | Next Review: 2026-07-01
1. Purpose
This policy establishes requirements for logical and physical access to DataVault Technologies’ information systems, ensuring that access is authorized, authenticated, and limited to the minimum necessary for job functions.
2. Scope
This policy applies to all DataVault employees, contractors, and third-party users who access DataVault systems, data, or facilities. It covers the DataVault SaaS platform, AWS infrastructure (us-east-1, eu-west-1), and all supporting systems.
4. Policy Statements
4.1. All production system access shall be authenticated through Okta SSO with multi-factor authentication (MFA) enabled. Local accounts are prohibited.
4.2. Access permissions shall follow the principle of least privilege. Role-based access control (RBAC) shall be implemented via AWS IAM roles and Okta groups.
4.3. Access reviews shall be conducted quarterly by each team manager. Reviews must be completed within 10 business days and documented in the access review log.
4.4. Access for terminated employees shall be revoked within 24 hours of HR notification. Okta SCIM provisioning handles automated deprovisioning.
4.5. Privileged access (admin, root) shall require additional approval from the CISO and be logged for audit review.
5. TSC Criteria Mapping
| Criterion | How This Policy Addresses It |
|---|---|
| CC6.1 | Logical access security software, infrastructure, and architectures (Okta SSO, AWS IAM) |
| CC6.2 | Prior to issuing credentials, registered and authorized (Okta provisioning workflow) |
| CC6.3 | Restricts access, removes access (quarterly reviews, 24-hour termination) |
| CC6.6 | Restricts access to externally managed information assets (API gateway, IP allowlisting) |
| CC6.7 | Restricts transmission, movement, and removal of information (DLP, encryption) |
| CC6.8 | Prevents or detects unauthorized changes (config scanning, change management) |
Built-in Validation
The skill includes two validation tools that check policies for structural completeness and TSC coverage. The agent runs the completeness checker after each policy and the TSC mapper after all policies are generated.
What the validators check
Policy Completeness Checker:
| Check Category | What It Validates | Severity |
|---|---|---|
| Required sections | All 10 sections present: Purpose, Scope, Roles, Statements, TSC Mapping, Exceptions, Enforcement, Review Cycle, Version History, Metadata | ERROR per missing section |
| Document metadata | ID, version, classification, dates, owner, approver | ERROR if incomplete |
| Specificity | Flags vague language: “appropriate”, “reasonable”, “as needed”, “periodically”, “promptly” | WARNING per instance |
| Named roles | Named individuals or titled roles referenced (not “management” or “responsible party”) | WARNING if generic |
| Review frequency | Annual review commitment with revision trigger events specified | WARNING if missing |
Policy TSC Mapper:
| Check Category | What It Validates | Severity |
|---|---|---|
| TSC criteria coverage | Every in-scope TSC criterion is addressed by at least one policy | ERROR per uncovered criterion |
| Cross-reference | Policies map only to valid TSC criterion IDs | WARNING if invalid |
| Category coverage | Coverage percentage per TSC category (CC, A, PI, C, P) | INFO |
| Organization alignment | Cross-reference with in-scope categories from organization profile | WARNING if mismatch |
Example validation output
========================================================================
SOC 2 Policy — Completeness Check: POL-004 Incident Response
========================================================================
--- Sections (10 required) ---
[PASS] purpose
[PASS] scope
[PASS] roles_and_responsibilities
[PASS] policy_statements
[PASS] tsc_criteria_mapping
[PASS] exceptions
[PASS] enforcement
[PASS] review_cycle
[PASS] version_history
[PASS] document_metadata
--- Quality Checks ---
[WARNING] Statement 4.3: "Affected customers will be notified
promptly." — vague timeline. Replace with specific SLA
(e.g., "within 72 hours of confirmation").
Result: 1 WARNING (fix recommended)
========================================================================
========================================================================
SOC 2 Policy Suite — TSC Coverage Analysis
========================================================================
Policies analyzed: 8
In-scope categories: Security (CC), Availability (A)
Coverage by category:
[CC] Security: 33/33 criteria covered (100%) ✓
[A] Availability: 3/3 criteria covered (100%) ✓
Overall coverage: 36/36 in-scope criteria (100%)
Result: PASS
========================================================================
The agent runs both validators automatically and surfaces findings inline, so you always know exactly what needs attention before the policy suite is complete.