SOC 2 readiness pack

On Growth and above, Attestly generates a fifth document — a SOC 2 readiness assessment — alongside your AI Trust Center, Privacy Policy, DPA, and OSS attribution. It is a code-grounded translation of your existing Attestly artefacts into the structure an auditor expects to read before a SOC 2 engagement begins.

This is not a SOC 2 attestation. A SOC 2 report can only be issued by a licensed CPA firm after a Type I or Type II engagement. The readiness pack is what you walk into that engagement with.

What's inside

• Service description — the boundary of the system in scope, derived from your repository name and tenant facts.
• Trust Services Criteria coverage — Security (Common Criteria) ships by default, with optional add-ons for Availability, Confidentiality, Processing Integrity, and Privacy.
• Control matrix — every Common Criteria from CC1.1 through CC9.2 (about 33 controls), each with a status, a narrative grounded in your actual stack, the Attestly artefacts that already serve as evidence, and the operator-supplied evidence still required.
• Gap analysis — top gaps surfaced by priority, each with a recommended next step.
• Readiness snapshot — implemented / partial / planned / not implemented / not applicable totals and a percent score.
• Auditor evidence pack — an index of every artefact with its source (Attestly, operator, or external).

How the generator stays grounded

The Zod-locked schema forces the LLM to populate every required field. The controlNarrative is constrained to reference real findings (auth providers, hosting subprocessors, observability tooling) detected by the scanner, plus platform facts that Attestly itself produces — your tenant's published trust center, audit log, drift state. The model cannot invent processes that are not in the input.

Working alongside Vanta / Drata / Secureframe

The readiness pack is designed to run alongside, not instead of, a GRC platform. The right division of labour:

Task	Attestly	GRC tool
Document controls and write narratives	Yes	Yes — both stay in sync.
Track HR, training, hardware, and physical-security evidence	No	Yes.
Maintain the live subprocessor inventory	Yes — from code.	Should be imported from Attestly.
Run the actual SOC 2 audit	No (and neither does the GRC tool).	No — your auditor does.

Regenerating the readiness pack

The pack regenerates on every scan, like the rest of your documents. Drift alerts apply: a change that introduces a new subprocessor or auth provider will surface a drift review on the readiness pack the same way it does on your DPA.

Custom controls

The default scope is the AICPA 2017 Trust Services Criteria. If you have an internal controls library you want to express alongside, drop them into a .attestly/controls.yaml file in your repo — the generator will fold them in as supplemental controls without affecting the TSC matrix.