SOC 2 Type I in hand, Type II window still open

No - and the gap is structural, not a matter of wording.

A SOC 2 Type I asserts two things: management's description of the system, and the suitability of the design of controls at a point in time. It says nothing about whether those controls operated throughout a period. The prospect's policy asks for Level 2 evidence, and Level 2 is an assurance claim resting on an independent assessment of operating effectiveness - exactly what Type II adds.

Two further gaps sit underneath:

• Framework coverage. The SOC 2 trust services criteria are not the CCM. The report covers Security and Availability; it has never been mapped to the 17 CCM domains. Controls in IPY, STA, GRC and HRS in particular have no natural TSC home and are simply absent.
• Service scope. The report must describe the reconciliation API as offered to customers, including the subservice organisations and the carve-outs. A report covering only corporate IT would fail the same test as an over-narrow ISO scope.

Sending a Type I to the registry in support of a Level 2 claim would misstate the assurance level. Sending it to the prospect with a covering note saying 'equivalent to Level 2 until October' does the same thing privately and is worse for the relationship if the procurement team knows the framework.

The engagement needs three changes, agreed with the CPA firm before fieldwork begins - a scope change after the window opens is expensive or impossible.

1. Add CCM criteria to the examination. The auditor must assess the applicable CCM controls alongside the TSC. The practical input is a CCM-to-TSC mapping plus a gap list: controls with no TSC equivalent must be added to the test plan, not assumed covered.
2. Confirm the system boundary. The description must cover the reconciliation API, the production environment and the subservice organisations, with complementary user entity controls and carve-outs stated. Any carve-out for a control the customer thinks Halcyon operates has to be disclosed in the registry entry too.
3. Fix the period. The 1 July to 30 September window is workable, but it must be long enough for the controls to be tested meaningfully and the report must be issued after the period ends. Check whether an earlier window (from 1 May) is possible if the controls were operating then and evidence is retained - that only brings the report date forward by weeks, not months.

The mapping and the report are what get published; the mapping is not optional documentation, it is how a reader sees which CCM controls were in scope.

Start from arithmetic: the observation window closes 30 September and the report cannot be issued before that, so 15 August cannot be met with Level 2 evidence. Any plan that pretends otherwise creates a contractual misrepresentation.

Options, in order of preference:

1. Move the evidence requirement, not the date. Offer the prospect the accurate Level 1 CAIQ now, the Type I report as design evidence, the signed engagement letter with the CCM scope added, the CCM gap-assessment summary, and a named date for the Type II. Procurement policies often accept 'committed evidence with a contractual condition subsequent' - ask, do not assume.
2. Split the contract. Sign for the service with a condition that the Level 2 registry entry is delivered within 30 days of report issuance, with a defined consequence if it is not.
3. Interim assurance. A bridge letter from the CPA firm covering the period since the Type I, plus a pen-test summary and the remediation tracker, buys credibility but is not Level 2 and must be labelled as such.

What must not happen: a registry submission or a customer-facing statement that presents Type I evidence as satisfying a Level 2 requirement. The October report will be a good outcome; a dispute about a false assurance claim in August will not be.