How to Write a SOC 2 Readiness Prompt That Lists Your Control Gaps

Most teams meet SOC 2 the same way: a sales call with a compliance vendor, a quote, and a six-week wait for a readiness assessment. The vendor pages that rank for soc 2 readiness prompt are exactly that funnel. They explain what a readiness assessment is, list a price band, and end with a demo button. None of them hand you a prompt you can paste into ChatGPT or Claude to get a control-gap list out of your own controls today.

That's the gap. A readiness assessment is, at its core, a mapping exercise: take what you do now, line it up against the Trust Services Criteria, and mark where you fall short. A language model is genuinely good at that mapping when you give it a real description of your controls and a strict output contract. Not good enough to skip the auditor. Good enough to stop walking into the kickoff blind.

This post shows how to build that prompt, what the output contract should look like, and where it breaks. The job is narrow on purpose: describe your current controls, get back a severity-ranked gap register against the criteria.

What a SOC 2 readiness prompt actually does

A soc 2 readiness prompt is a reusable instruction that takes a description of your current controls and returns a gap analysis against the SOC 2 Trust Services Criteria, with each gap ranked by severity and tied to a remediation step.

It does four things in one pass:

1. Maps your controls to criteria. It reads your "we do X" description and places each control under the right Common Criteria series (CC1 through CC9), plus any optional categories like Availability or Confidentiality you've scoped in.
2. Finds the silence. The hard part isn't scoring the controls you described. It's catching the criteria you didn't mention at all, which is where most readiness gaps actually live.
3. Ranks severity. A missing access-review cadence and a missing favicon policy aren't the same risk. The output separates the material gaps from the cosmetic ones.
4. Gives you a worklist. Each gap comes with a remediation step you can assign to an owner, not a vague "improve your controls."

The reason vendor pages don't ship this is structural. Secureframe's readiness hub explains the three-step process (map controls, find gaps, remediate) and offers a downloadable self-assessment checklist, but no prompt and no worked example (secureframe.com). Vanta's gap-analysis page is the same shape: a procedural framework with steps like "scope the assessment," zero structured output, and the platform as the answer (vanta.com). Drata's checklist page even wires up "summarize this with ChatGPT" buttons, but they summarize the article, not your controls (drata.com). Useful background. Not a tool you can run.

What you can do with this prompt

• Turn a Notion doc describing your current security practices into a gap register before you ever book a vendor call.
• Re-run it quarterly so the gap list tracks drift instead of going stale between audits.
• Scope a Type 1 vs Type 2 conversation with real numbers ("we have 11 high-severity gaps, here they are").
• Hand a prioritized remediation list to engineering instead of forwarding a 200-row checklist.
• Pressure-test a control you think is covered by asking the model which criterion it actually satisfies.
• Brief a new compliance hire on where the program stands in one artifact.

Anatomy of the prompt

The whole thing hinges on the output contract. A readiness prompt that returns prose is worthless; you want a register you can sort and assign. Here's the shape:

Variables
  {{company_profile}}            → what you build, stack, headcount, data you hold
  {{current_practices}}          → your honest description of controls today
  {{trust_services_categories}}  → Security (always) + any of Availability,
                                   Confidentiality, Processing Integrity, Privacy
  {{audit_target_date}}          → when you want to be audit-ready

Prompt
  Role: SOC 2 readiness analyst preparing a startup for a Type 2 examination.
  Task: map {{current_practices}} to the Trust Services Criteria, find gaps,
        rank each by severity, and propose one remediation step per gap.
  Rules: flag criteria not addressed at all as gaps. Don't invent controls
         the description doesn't claim. Mark anything you're unsure about.

Output contract (one row per criterion, table):
  | Criterion | Control described? | Gap | Severity | Remediation | Owner hint |

That last line is the load-bearing part. The model fills "Control described?" with a yes/no/partial, so you can immediately see the silences. Severity is constrained to high/medium/low so it can't waffle. The remediation column makes each row actionable.

A note on which model to use

Claude tends to honor a ## Output format heading and keep every row in the table shape across a long control description, where GPT-4o is more likely to drift into a summary paragraph after the table if you don't restate the format on the final line. If your control description runs long, put the output contract last in the prompt, after the pasted {{current_practices}}, because models weight the most recent tokens. Contract first, long context after, and the format gets ignored.

Step-by-step usage

1. Write an honest current-practices description

Garbage in, garbage out applies hard here. "We're pretty secure" produces a useless gap list. Describe the actual mechanics: "Access reviews happen ad hoc when someone leaves. We don't have a documented cadence. MFA is on for the AWS console but not for the database."

2. Scope your categories

Security (the Common Criteria) is mandatory. Add Availability, Confidentiality, Processing Integrity, or Privacy only if they apply to what you sell. Don't pad the scope; every extra category is extra controls to evidence.

3. Fill the variables and run

Paste your {{company_profile}} and {{current_practices}}, set {{trust_services_categories}}, and run. With the contract last, you'll get the table back clean.

4. Sort by severity and assign

Filter to the high-severity rows first. Those are the ones that'll stall an audit. Assign owners off the "Owner hint" column and put dates against them relative to {{audit_target_date}}.

5. Re-run after remediation

Update {{current_practices}} with what you've fixed and run it again. The gap count should drop. If it doesn't, the fix didn't actually close the criterion, which is exactly the kind of thing you want to catch before an auditor does.

Prompt-craft patterns that make the gap list trustworthy

Force a "not addressed" verdict. The single most valuable instruction is telling the model to treat any criterion your description doesn't mention as an explicit gap, not to quietly skip it. Without that line, the model only scores what you fed it and the silences vanish.

For every criterion in scope, if {{current_practices}} does not
describe a control that addresses it, mark "Control described? = No"
and treat it as a gap. Never omit a criterion from the table.

Constrain severity to a fixed scale. Free-text severity drifts into "moderate-to-high" mush. Lock it.

Severity is exactly one of: High, Medium, Low.
High = would likely cause an audit exception.
Medium = needs remediation but won't block the examination.
Low = hygiene; document it and move on.

Make it admit uncertainty. A readiness prompt that's confidently wrong is worse than one that flags doubt. Tell it to mark rows where your description is too thin to judge, so you know which controls to go re-document rather than trusting a guess.

Variables you'll set

Getting started

1. Pull together your current security documentation, however scattered.
2. Write the {{current_practices}} description honestly, including the ad-hoc stuff.
3. Decide your in-scope {{trust_services_categories}}.
4. Run the prompt with the output contract last.
5. Sort the register by severity and assign owners.
6. Re-run after each remediation sprint to watch the gap count fall.
7. Walk into your vendor or auditor kickoff with the register in hand.

If you'd rather not hand-build and tune the prompt across four passes, the pack version does the whole arc.

Compliance work doesn't stop at SOC 2. Once you're tracking controls, the next questions are how you govern the AI tools your own team uses and how you read other people's SOC 2 reports. For the first, a clear policy beats an ad-hoc Slack rule. For the second, see the companion approach in scoring a vendor's security posture with a prompt. And if your audit scope touches code, a security code review prompt mapped to CWE covers the engineering side of the same trust story. The AI Usage Policy & Governance Playbook handles the policy gap that now shows up in 2026 SOC 2 scopes, since auditors increasingly want an AI use policy on file.