Compliance Readiness Assessment

You tell the owner, honestly and with evidence, how far they are from passing a given framework and what to do first. Each requirement gets a status backed by something you saw, not something someone said. The plan at the end is ordered so the company reaches audit-ready with the least wasted effort.

When to use

• "What would it take for us to get SOC 2?"
• "Are we ready for our ISO 27001 stage 1 audit?"
• "Are we GDPR compliant?"
• "A big customer wants SOC 2 or ISO; how long would it take?"
• Before investor or acquirer due diligence.

What you need

• The target framework and why (customer demand, sales, regulation). If the owner is unsure which one, see step 1.
• Scope: which product, systems, locations and teams.
• Evidence access: policies and documents (connected Google Drive or Notion), admin consoles in your browser signed in by the owner, the code host, the ticket tracker, HR records for training and onboarding. Read-only is enough.
• Time with the owner and system owners to confirm how things work; use ask_teammate and clarify.

Method

1. Confirm the right framework. Summarise the choice for the owner:
   • SOC 2 (AICPA): an attestation report by a licensed CPA firm against the Trust Services Criteria. Security (the Common Criteria CC1 to CC9) is always in scope; Availability, Confidentiality, Processing Integrity and Privacy are optional. Type I tests design at a point in time; Type II tests operation over a period, commonly 3 to 12 months. Common with US customers.
   • ISO/IEC 27001:2022: certification by an accredited certification body of an information security management system. Clauses 4 to 10 are mandatory; Annex A has 93 controls in four themes (organisational, people, physical, technological), selected through risk assessment and recorded in a Statement of Applicability. Stage 1 and Stage 2 audits, then surveillance audits within a three-year cycle. Common with European and global customers.
   • GDPR / UK GDPR: law, not a certificate. Readiness means the required records, processes and safeguards exist and work. Confirm details with web_search against the official sources and cite them; do not rely on memory for anything an auditor will check.
2. Fix the scope in writing: systems, data, people, locations, and for SOC 2 the categories and the type.
3. Build the requirement list from references/framework-checklists.md, which groups requirements into practical areas. The licensed standards themselves are copyrighted; the owner should buy the ISO standard or download the AICPA criteria for exact wording.
4. Collect evidence per requirement. Acceptable evidence is something an auditor could inspect: a signed policy, a console screenshot with the date, a configuration export, a ticket showing a completed review, a training record. "We do that" from a person is a lead, not evidence. Store evidence in a dated folder per area.
5. Rate each requirement:

   Status	Meaning
   Met	Designed and working, with evidence
   Partial	Exists but incomplete, undocumented, or not consistently done
   Missing	Not in place
   N/A	Out of scope, with the reason recorded
   For SOC 2 Type II and ISO surveillance, "met" also needs proof that it happened repeatedly over time (for example four quarterly access reviews, not one).

6. Prioritise the gaps:
   • P1: foundations everything else depends on (scope, risk assessment, asset inventory, policy set, MFA everywhere, access reviews, logging, backups, incident process)
   • P2: controls that need a track record before an audit window (start early so evidence accumulates)
   • P3: documentation tidy-ups and controls that are quick to fix later Estimate effort as small, medium or large and name an owner for each item.
7. Draft the roadmap: gap closure, then the evidence-gathering period, then the audit. For SOC 2, the Type II observation window can only start once controls are running. For ISO, the internal audit and management review must happen before Stage 2. State that timelines are estimates and depend on the auditor.
8. Tooling advice, honestly. Spreadsheets and a shared drive are enough for a small company. Do not recommend paid compliance platforms or auditors by name as requirements; if the owner asks, compare options neutrally and note costs must be checked.
9. Present a one-page readiness summary and the full gap register.

Gaps you will usually find in a small company

• No written risk assessment, or one that was done once and never revisited.
• No asset or vendor inventory, so scope cannot be shown.
• MFA on email but not on the cloud console, code host, registrar or finance tools.
• Leavers removed from email but still active in SaaS tools outside single sign-on.
• Access reviews that happen informally, leaving no record.
• Backups that exist but have never been restore-tested.
• Logs kept but never reviewed, and no alerting on admin changes.
• Code merged without review because the team is small.
• Policies copied from a template that describe controls nobody runs.
• No security training records, even if people were briefed.

Evidence an auditor will usually not accept

• A policy alone, with no record that the activity happened.
• Screenshots without a date, a system name or a visible account.
• A single example where the control needs to operate over a period.
• Statements in chat ("yes, we always do that").

Example gap register row:

| Access | SOC 2 CC6.2 (TSC 2017) | Leavers removed within 5 working days | Partial | leaver-tickets-Q3.csv | 2 of 6 leavers still active in CRM | P1 | Ops lead | S | 30 Nov |

Output

• Gap register (spreadsheet or CSV): area, requirement reference (with framework version), description, status, evidence link, gap, priority, owner, effort, due date.
• Readiness summary on a show_card: requirements met, partial, missing per area; top ten gaps; estimated path to audit.
• Evidence folder, organised by area and dated.

Checks before you finish

• Every "met" has inspectable evidence linked.
• Framework versions are named (for example ISO/IEC 27001:2022, TSC 2017 with 2022 revised points of focus).
• Statements about the framework are sourced, not from memory.
• Every gap has an owner and a priority.
• The summary says clearly that this is a readiness view, not an audit opinion.

Pitfalls

• Taking people's word for it. Auditors test evidence. So do you.
• Policy without practice. A signed policy that nobody follows is a finding, not a pass.
• Treating Type I as the finish line. Many customers want Type II; plan for the observation window.
• Trying to certify everything at once. A tight scope gets through audit; expand later.
• Promising a certification date. Only the auditor decides the outcome; give ranges and dependencies.
• Sign-off. You do not certify or give a legal opinion. A licensed CPA firm issues SOC 2 reports, an accredited body issues ISO certificates, and GDPR positions need a qualified privacy lawyer or DPO. The owner approves the plan and its spending.

Checklists: references/framework-checklists.md. Credits: references/CREDITS.md.