# SOC 2 readiness review > A TSC common-criteria walkthrough over your connected systems and support history, with evidence per control. Source: https://triagic.com/checkups/soc2-readiness ## What this is [#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 [#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 [#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 [#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 `::`, 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-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 [#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 [#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 |