SOC 2 readiness review

What this is

This is a readiness review and evidence-collection exercise. It is not an audit and not a certification, it produces no opinion, and nothing in its output may be described as SOC 2 compliance. What it does is walk the Trust Services Criteria common criteria, record what evidence exists today for each one, and name the gaps early enough to close them before a real auditor asks. Say this in the first paragraph of the report, in your own words, every run.

An unanswerable control is a legitimate result. Where the evidence lives somewhere this run cannot see — an HR system, a signed policy PDF, a board minute — record the control as not assessable from here and say exactly what artifact the org would need to produce. Never infer that a control is satisfied because you found no evidence against it; absence of evidence is the finding.

Procedure

1. Fix the scope and say it out loud. Enumerate what this run can actually see: the systems connected to this org and the support ticket history. That list is the scope statement of the review, and everything outside it is "not assessable from here". The org's own systems are the subject throughout — this application is only the instrument, and nothing about it belongs in a finding.
2. CC6.1 / CC6.2 / CC6.3 — logical access. For each connected system, enumerate the accounts and grants it exposes read-only (see the access-review checkup for the per-provider method, and use its results if it has run recently). Evidence for CC6.2 is a record of authorization at the moment of grant — check whether each system's own audit surface carries the invite/creation events that would prove it. Evidence for CC6.3 is deprovisioning: look for accounts that are still active with no activity for 90 days, and for any principal whose privileges exceed what their role needs. Shared or service accounts that multiple humans use are a CC6.1 and CC6.3 finding both, because they destroy attribution.
3. CC7.2 / CC7.3 / CC7.4 — monitoring and incident response. Look at what monitoring is actually connected (any observability, alerting or on-call provider in the inventory) and at how incidents have really been handled: read the support ticket history for incident-shaped tickets and their investigations, and check whether they show detection, triage, resolution and a post-incident note. A documented process nobody follows is a CC7.4 gap; a process visible in the tickets but written down nowhere is a CC5.3 gap. tickets__search_similar is the fastest way to find the incident-shaped history.
4. CC7.1 / CC8.1 — change management. If a source-control or CI integration (GitHub, GitLab) is connected, sample recent merges to the default branch and check for the evidence an auditor asks for: review approval before merge, branch protection on the default branch, and a link from the change to whatever authorized it. Without such an integration, record CC8.1 as not assessable and name the artifact needed (a branch-protection screenshot, a sample of approved pull requests).
5. CC2.1 / CC5.2 / CC5.3 — information and technology controls. Assess the audit surface of each connected system: does it keep an access or change log, does every entry carry an actor and a timestamp, is there a retention answer? An audit trail is the evidence that supports half the other criteria, so gaps here cascade — say so when they do. Check that the role each connection uses is deliberately scoped (a read-only role limited to what the work needs is real evidence of least privilege; an account-admin role used for reading is the opposite).
6. CC9.2 — vendor risk. The connected-integration inventory is a partial vendor list: every connected provider is a third party holding or exposing org data. List them, and for each note whether the org has an owner, a documented purpose, and a stated data classification. Anything connected with no identified owner is a CC9.2 finding.
7. CC1.x / CC3.x / CC9.1 — governance and risk assessment. These almost never have local evidence. Do not guess. Ask the questions explicitly in the report as an evidence request list ("who signs off on the risk assessment, and when was it last performed"), and record each as not assessable with the artifact named. A short, honest not-assessable list is more useful than a padded one.
8. CC6.6 / CC6.7 / CC6.8 — boundary and data movement. Where an infrastructure or cloud integration is connected, check what it shows about network exposure and encryption in transit. Where nothing is connected, say so. Note any place where support data (ticket bodies, attachments, chat threads) leaves the boundary, since that is the movement CC6.7 is about.
9. Collect evidence excerpts, not assertions. Every control you mark as supported must carry a quoted excerpt in the finding's evidence field: the audit-log line, the query result, the account list row, with its source named. An auditor accepts artifacts, not conclusions, and so does this report.

Control mapping

Every finding must set controlRef to exactly one id from this checkup's control set — the id string alone, e.g. "CC6.3". Choose the control the gap most directly frustrates; if a finding touches several, pick the primary one and mention the others in detail. A finding with no matching control does not belong in this checkup — it belongs in credential-hygiene or access-review, and you should say so rather than forcing a mapping.

Finding keys

The key identifies the underlying gap, not this run, so the same gap keeps one ledger row across months and a closed gap that reopens is flagged as a regression. Use <control-or-area>:<subject>:<gap-slug>, all lowercase except identifiers you are quoting verbatim. Never include a date, a run id, or a count.

• cc6.3:dormant-accounts:not-deprovisioned
• cc6.1:shared-service-account:no-attribution
• cc8.1:default-branch:no-review-evidence
• cc9.2:vendor-inventory:no-owner
• cc3.2:risk-assessment:not-assessable

Severity rubric

Severity here is about audit and security exposure, not effort to fix.

• critical — a control failure that also constitutes a live security exposure: an active account for someone who has left, a credential shared across people with no attribution, an audit trail that can be altered or is absent for privileged actions.
• high — a criterion with no evidence at all that an auditor will certainly test: no deprovisioning record, no change-approval evidence, no incident-response history, monitoring connected to nothing.
• medium — evidence exists but is partial or informal: the practice is visible in tickets or history but written down nowhere, an over-broad scope that works but is not least privilege, a vendor list without owners.
• low — documentation and tidiness gaps with no exposure behind them.
• info — a control with adequate evidence today, recorded so the next run can detect it regressing; and each not assessable from here control, with the artifact the org needs to produce.

Output guidance

Open with the honesty statement — a readiness review and evidence collection exercise, not an audit and not certification — then a one-paragraph executive summary: how many criteria had evidence, how many had gaps, how many were not assessable from this run's scope, and the single most exposed area. Follow with an explicit scope paragraph naming exactly what this run could see. Then one section per criteria family (CC1, CC2, CC3, CC5, CC6, CC7, CC8, CC9), each control listed with its status (evidence found / gap / not assessable) and a quoted evidence excerpt naming its source. Close with two tables: a remediation table (Control | Gap | Recommended action | Owner | Effort), most exposed first, and an evidence-request table listing every not-assessable control against the artifact the org must supply. Never state or imply that the org is compliant, certified, or would pass.

Controls this checkup may cite

Control	Title
CC1.1	Commitment to integrity and ethical values
CC1.3	Structures, reporting lines, authority and responsibility
CC1.4	Competence of personnel
CC1.5	Accountability for internal control responsibilities
CC2.1	Relevant, quality information to support internal control
CC2.2	Internal communication of objectives and responsibilities
CC2.3	Communication with external parties
CC3.1	Objectives specified clearly enough to assess risk
CC3.2	Identification and analysis of risks to objectives
CC3.4	Assessment of changes that could affect internal control
CC5.1	Selection and development of control activities
CC5.2	General controls over technology
CC5.3	Control activities deployed through policy and procedure
CC6.1	Logical access security over protected information assets
CC6.2	Registration and authorization of new users
CC6.3	Access granted, modified and removed on least privilege
CC6.6	Protection against threats from outside the system boundary
CC6.7	Restriction of transmission, movement and removal of information
CC6.8	Prevention and detection of unauthorized or malicious software
CC7.1	Detection of configuration changes and vulnerabilities
CC7.2	Monitoring of system components for anomalies
CC7.3	Evaluation of security events to determine whether they are incidents
CC7.4	Response to identified security incidents
CC8.1	Change management: authorize, design, test, approve, implement
CC9.1	Identification and development of risk mitigation activities
CC9.2	Management of vendor and business-partner risk