Back to list

Guided Elaboration of SOC 2 Readiness Documentation

Step-by-step guide to producing SOC 2 control narratives and evidence placeholders with the agent, with example chat turns and document output at each stage.

  • beginner
  • 12 min read
  • 2026-02-18
Author Ricardo Cabral · Founder

This guide walks through a typical session using the SOC 2 Control Narrative Author skill: you tell the agent your audit scope and existing policies, and the agent drafts control narratives aligned to AICPA Trust Services Criteria (TSC), adds evidence placeholders, and runs a built-in validation tool so you can close gaps before your Type I or Type II audit.

You’ll see example dialogs as chat messages and document excerpts after each major turn so you know what to expect at every step.

What you’ll need

  • A Rakenne project with the SOC 2 Control Narrative Author skill enabled.
  • A clear idea of your in-scope TSC categories (e.g. Security only, or Security + Availability).
  • Any existing documents you want the agent to use or extend: access control policy, change management procedure, runbooks, BCP/DR docs.

Turn 1: Scoping the engagement

You open the project and describe your goal. The agent confirms scope and asks whether to create a new document or extend an existing one.

You: We need SOC 2 Type II readiness. We’re in scope for Security (all common criteria) and Availability. Can you draft control narratives and evidence placeholders for CC1 through CC9 and A1?

Agent: I’ll draft control narratives for Security (CC1–CC9) and Availability (A1). Do you already have a control narrative document I should extend, or should I create a new one?

You: Create a new document. We have an access control policy, change management procedure, and monitoring runbooks.

Agent: I’ve created soc2-control-narratives.md with sections for each criterion. For CC1 (Control environment) I’ve described your board oversight and management structure and added an evidence placeholder: “Board charter, org chart, management meeting minutes.” For CC6 (Logical and physical access) I’ve referenced your access control policy and added placeholders for access reviews and termination checklist. I’ll continue with CC2–CC5, CC7–CC9, and A1.

Document excerpt after Turn 1 — The new file has a title, scope note, and the first few criteria filled in; the rest are scaffolded for the next pass.

# SOC 2 Control Narratives — [Company]  
**Scope:** Security (CC1–CC9), Availability (A1). Target: Type II readiness.

---

## CC1 — Control environment

**Control objective:** The entity demonstrates a commitment to integrity and ethical values; the board exercises oversight; management establishes structure, authority, and responsibility.

**Control narrative:** [Company] maintains a control environment through board oversight of risk and compliance. The audit committee reviews internal control and receives periodic reports from management. Roles and responsibilities for security and operations are defined in job descriptions and the org chart.

**Evidence:** Board charter; org chart; management meeting minutes (quarterly).

---

## CC6 — Logical and physical access controls

**Control objective:** The entity implements logical and physical access controls to protect against unauthorized access to systems, data, and facilities.

**Control narrative:** Access to production systems and customer data is governed by an Access Control Policy. New hires receive access only after HR onboarding and manager approval; access is provisioned via our identity provider (Okta). Access reviews are conducted quarterly by managers; access is revoked within 24 hours of termination. Physical access to data centers is controlled by badge and MFA; visitors are escorted.

**Evidence:** Access Control Policy v2.1; Okta provisioning workflow; quarterly access review report (Q3 2025); termination checklist; data center access log sample.

---

## CC2 — Communication and information  
*[Drafting in progress…]*

## CC3 — Risk assessment  
*[Drafting in progress…]*

Turn 2: Completing all criteria

The agent has finished drafting CC2–CC5, CC7–CC9, and A1. You review and ask for one refinement.

Agent: I’ve completed all sections. CC2–CC5 cover communication, risk assessment, monitoring activities, and control activities; CC7–CC9 cover incident response, change management, and risk mitigation. A1 covers availability (SLA, monitoring, BCP/DR). Each criterion has a control narrative and an evidence line. Tell me if you want to tie any narrative to a specific policy or runbook by name.

You: For CC7 can you name our incident response runbook and add a placeholder for tabletop exercise notes?

Agent: Updated CC7: narrative now references “Incident Response Runbook v1.2” and the evidence line includes “Tabletop exercise notes (annual).”

Document excerpt after Turn 2 — CC7 and A1 show the pattern: narrative + concrete evidence placeholders.

## CC7 — Incident response

**Control objective:** The entity identifies, selects, and develops incident response activities.

**Control narrative:** Incidents are detected via monitoring and user reports, triaged using the Incident Response Runbook v1.2, and escalated to the security team. Root cause is documented; corrective actions are tracked in our issue tracker. We conduct an annual tabletop exercise and update the runbook based on lessons learned.

**Evidence:** Incident Response Runbook v1.2; incident log sample; tabletop exercise notes (annual).

---

## A1 — Availability

**Control objective:** The entity maintains system availability consistent with commitments to users.

**Control narrative:** We target 99.9% uptime for our core platform. Monitoring is 24/7; incidents are triaged via PagerDuty. RTO/RPO are documented in our BCP; we run annual DR tests and document results.

**Evidence:** SLA document; PagerDuty runbook; BCP section 4.2; DR test report 2025.

Turn 3: Running the validation tool

You ask the agent to run the built-in coverage check. The tool reports which criteria are present and whether each has a narrative and evidence reference; it can also flag missing or weak evidence.

You: Run the validation tool to see if we’re missing anything.

Agent: I ran check_trust_services_criteria_coverage on the document. Result: 10 criteria referenced (CC1–CC9, A1). Two warnings: CC4 and CC7 need a clearer evidence reference (e.g. name the specific runbook or monitoring report). I’ll add those now.

Agent: Updated CC4 to reference “Monitoring and Alerting Runbook” and CC7 already had the runbook name; I added “quarterly incident review summary” to the evidence line. Re-ran the check: PASS — all 10 criteria have a narrative and evidence reference.

Validator output (excerpt) — What the tool reports before and after fixes.

=== Trust Services Criteria Coverage ===
Document: soc2-control-narratives.md

Criteria referenced: CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8, CC9, A1 (10)

--- Per-criterion checks ---
CC1: narrative OK, evidence OK
CC2: narrative OK, evidence OK
CC3: narrative OK, evidence OK
CC4: narrative OK, evidence WARNING — evidence reference vague; name specific artifact (e.g. runbook, report)
CC5: narrative OK, evidence OK
CC6: narrative OK, evidence OK
CC7: narrative OK, evidence WARNING — evidence reference vague
CC8: narrative OK, evidence OK
CC9: narrative OK, evidence OK
A1: narrative OK, evidence OK

Unmapped criteria (optional): PI1, C1, P1–P8 (not in scope)

Overall: 2 warnings. Address warnings and re-run for a clean PASS.

After the agent’s updates, a second run shows:

Overall: PASS — All referenced criteria have control narrative and evidence reference.

Turn 4: Ready for audit prep

With the check passing, the document is in good shape for internal review and audit prep. You can still ask for more sections (e.g. a readiness checklist) or to align wording to a specific auditor or framework.

You: Add a short readiness checklist at the top with one row per criterion and columns for narrative done, evidence collected, and owner.

Agent: Added a “Readiness checklist” table at the top of the document with columns: Criterion, Control narrative, Evidence collected, Owner. Rows for CC1–CC9 and A1. You can fill in the Owner and Evidence collected as you gather artifacts.

Document excerpt after Turn 4 — The top of the document now includes a checklist table.

# SOC 2 Control Narratives — [Company]  
**Scope:** Security (CC1–CC9), Availability (A1). Target: Type II readiness.

## Readiness checklist

| Criterion | Control narrative | Evidence collected | Owner |
|-----------|--------------------|--------------------|-------|
| CC1       | Done               | —                  | —     |
| CC2       | Done               | —                  | —     |
| CC3       | Done               | —                  | —     |
| CC4       | Done               | —                  | —     |
| CC5       | Done               | —                  | —     |
| CC6       | Done               | —                  | —     |
| CC7       | Done               | —                  | —     |
| CC8       | Done               | —                  | —     |
| CC9       | Done               | —                  | —     |
| A1        | Done               | —                  | —     |

---

Summary

StepYou doAgent doesDocument state
1State scope (Security + Availability) and ask for new docCreates soc2-control-narratives.md, drafts CC1, CC6, scaffolds restNew file with first criteria and placeholders
2Request naming of runbooks / evidenceCompletes all criteria, ties CC7 to runbook and tabletop notesFull draft for CC1–CC9 and A1
3Ask to run validationRuns check_trust_services_criteria_coverage, fixes CC4/CC7 evidence, re-runsSame doc with clearer evidence lines; check PASS
4Ask for readiness checklistAdds checklist table at topDoc ready for internal review and evidence collection

The SOC 2 Control Narrative Author skill keeps the conversation in plain language while producing TSC-aligned narratives and evidence placeholders. Use the built-in check_trust_services_criteria_coverage tool after each major edit so gaps are caught before the auditor does.

Next steps

Ready to let your expertise drive the workflow?

Stop wrestling with rigid templates and complex tooling. Write your process in markdown, let the agent handle the rest.

Get Started