SOC 2 Readiness

Attestly generates a fifth document on Growth and above — a SOC 2 readiness assessment, not an attestation. It translates the artefacts you already have (subprocessor list, audit log, drift history, scan findings) into the structure an auditor expects to read before a SOC 2 engagement begins.

This is not a SOC 2 report. A SOC 2 attestation can only be issued by a licensed CPA firm after a formal engagement. Use this readiness pack to identify gaps, plan remediation, and brief your auditor.

Sections produced

• Service organization and description — the boundary of the system in scope, derived from your tenant facts.
• Scope — period (point-in-time for readiness), Trust Services Criteria selected, in-scope and out-of-scope services.
• Service commitments and system requirements — the SLAs and operational requirements you've made to your customers.
• Readiness snapshot — totals across implemented / partial / planned / not-implemented / not-applicable, and a percent score the model self-computes from those totals.
• Process narratives — risk assessment, change management, logical access, system operations, monitoring, incident response.
• Vendor management — pointer to your live subprocessor inventory plus review cadence.
• Control matrix — one block per control. Default scope (Security only) covers Common Criteria CC1.1 through CC9.2 (≈33 controls); each has a status, an intent statement, a narrative grounded in your stack, Attestly evidence, operator-supplied evidence still required, and (when not implemented) a gap with a recommended next step.
• Top gaps — sorted by priority.
• Next steps — 3–6 concrete actions to move from readiness to a Type I attestation.
• Auditor evidence pack — every artefact tagged attestly / operator / external so you know who produces what.

Optional categories

The default scope is Security (Common Criteria) only. The schema supports the other four AICPA categories — toggle them in the dashboard:

Category	Adds
Availability	A1.1, A1.2, A1.3
Confidentiality	C1.1, C1.2
Processing Integrity	PI1.1 – PI1.5
Privacy	P1.0 – P8.1

Schema

The generator output is constrained to a Zod schema with explicit descriptors per field. Every implementation status is enumerated; every control narrative must reference the literal entities surfaced by the scanner. The model cannot invent processes that are not in the input.

Regeneration

The readiness pack regenerates on every scan, like the rest of your documents. A drift alert that changes the subprocessor list or auth provider will surface a drift review on the readiness pack the same way it does on your DPA. See Drift detection.

Custom controls

If you have an internal controls library, drop a .attestly/controls.yaml file in your repo. The generator folds those controls into a separate "Internal controls" section; they don't affect the TSC matrix.