SOC 2: What Datarim Maps, and What It Does Not Claim
The framework maps technical safeguards to the Trust Services Criteria, but a mapping is not an audit, an attestation, or a SOC 2 report.
Datarim has a security baseline with checks for secrets, dependencies, workflow permissions, repository hygiene, network exposure, and drift. The framework maps those safeguards to external standards so teams can see where a technical gate supports a broader control objective.
For SOC 2, the relevant reference is the AICPA Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. The mapping is useful during control design. It does not turn a collection of shell gates into an auditor's opinion.
What the framework covers
Datarim can provide repeatable technical evidence: a required security scan ran, a release was verified, a risky network bind failed a gate, or a public repository contains its policy files. These controls are versioned with the code and their regressions can be tested.
What remains outside the framework
A real SOC 2 examination also depends on the service organization, its system description, control ownership, operating evidence, access reviews, vendor management, incident response, business continuity, and an independent service auditor. Datarim cannot supply those facts for a project merely because the project installed the framework.
The status is “technical mapping in progress.” Datarim has not published a SOC 2 report and does not claim certification. The next credible milestones are evidence ownership and retention, an internal readiness review, and independent auditor engagement.
Read the security-baseline reference for the current mapping. The AICPA Trust Services Criteria remain the external source.
Published retroactively from the framework archive. The public standards-mapping fanout originally shipped on May 15, 2026; no audit date is implied.