SOC 2¶
Statement¶
ClaimGuard is not yet SOC 2 attested. We are working toward SOC 2 Type I as our first formal attestation, with a target audit window in H2 2026. The trust portal you are reading is the scaffolding for that attestation: every control documented here will become an evidence link in the auditor's worksheet.
This page is the single place an auditor or a prospect can read to understand where we are on the SOC 2 journey, what controls already have evidence, and what is still being assembled.
Implementation¶
Target framework and trust services criteria¶
- Framework: AICPA SOC 2.
- Type: Type I first (point-in-time control design and implementation), then Type II once Type I is closed.
- Trust Services Criteria: the Security criterion is in-scope from the start. Availability and Confidentiality are likely to be added in Type I; Processing Integrity and Privacy are deferred to Type II or a later cycle.
Where each criterion stands¶
A snapshot mapping criteria to their primary evidence pages in this portal. "Status" reflects the state of the control evidence, not a formal auditor finding.
| Criterion area | Primary evidence pages | Status today |
|---|---|---|
| Logical access | Authentication, Authorization, Privileged access | Mostly partial; password_plain remediation queued |
| Cryptography | Cryptography, Encryption at rest | Partial (TLS gap pending A1.3) |
| Audit logging | Audit logging (cloud), Application audit logging | Cloud side implemented; application side partial |
| Change management | Change management, Secure SDLC | Implemented |
| Vulnerability management | SAST, SCA, Dependency management, Snyk remediation summary | Implemented |
| Backup / availability | Backups, Business continuity | Backups implemented; BC partial |
| Vendor / subprocessors | Vendor management, Subprocessors | Subprocessors implemented; vendor process partial |
| Incident response | Incident response, Vulnerability disclosure | VDP implemented; IR partial |
| Risk management | Risk management | Partial |
What's still missing for Type I¶
The high-leverage gaps that block fieldwork today are tracked across the trust portal. Cross-listed here so an auditor sees them in one view:
password_plainremoval — credibility-killer if shipped as-is. See Authentication.- Public user-facing TLS (plan step A1.3) — see Cryptography.
- Structured
audit_logtable for application-level events. See Application audit logging. - Standalone risk register — see Risk management.
- Written RTO/RPO + DR runbook + restore drill — see Business continuity.
- Tabletop incident-response exercise with a written post-mortem artifact — see Incident response.
- Annual vendor review sign-off — see Vendor management.
- Periodic access review of users + API keys — see Authorization.
What's helping us¶
- A single hardening journal (
docs/security/HARDENING-LOG.md) is the canonical, time-ordered record of cloud-posture and trust-portal changes. It is the closest artifact to the "evidence package" an auditor will eventually request. - The trust portal itself is structured around Statement → Implementation → Status, which mirrors the auditor's framing of "describe the control, describe its operation, attest to its state."
- Every
partialpage lists its known gaps publicly, so there is no surprise inventory to triage during audit fieldwork.
Auditor and consultant relationships¶
No auditor has been engaged yet. A SOC 2 readiness consultant has not yet been engaged either. Both are expected to land before the target audit window opens.
Status¶
planned — target audit window: H2 2026 (Type I).
There is no current attestation. The work to make the attestation possible is ongoing and visible across every linked page on this portal.
Roadmap¶
- Engage a SOC 2 readiness consultant to validate scope and the evidence framework before fieldwork.
- Engage an audit firm for the Type I engagement.
- Close the Type I gap inventory above before the readiness assessment.
- Type II window opens after Type I is closed; nominal target is the following 6–12 month observation period.
- Add Privacy and Processing Integrity criteria in a later cycle if customer demand or regulation requires.