SOC 2 · Trust Services Criteria
SOC 2
SOC 2 is the AICPA's attestation framework for service organizations: an independent auditor's report on the controls protecting customer data. Helmwart reads it the way it reads every framework — as an interpretive layer, mapping the criteria that carry a design-time threat surface to the agentic threats they bear on, and honestly marking the rest as organizational process.
What SOC 2 is
SOC 2 (System and Organization Controls 2) is an attestation report, not a certification: an independent CPA firm tests a service organization's controls against the AICPA's Trust Services Criteria and opines on whether they were suitably designed (Type I) or operated effectively over a period (Type II). The 9 Common Criteria (CC1–CC9, the "Security" category) are mandatory in every report; four further categories — Availability, Confidentiality, Processing Integrity, and Privacy — are included only when the engagement's scope calls for them.
In practice the criteria ask an organization to run a control environment, assess and monitor risk, restrict logical and physical access, operate and monitor its systems, manage change, and mitigate vendor risk — then to keep evidence that it actually does these things. It is a governance and assurance lens, not a threat taxonomy: where OWASP and MITRE ATLAS tell you what can go wrong, SOC 2 asks whether you run controls that would catch and manage it.
How Helmwart maps to it
Helmwart is a design-time threat-modeling tool, not an auditor. It cannot make you attested to SOC 2 — that's an audited outcome of a CPA firm's own testing. What Helmwart can do is show, criterion by criterion,which Trust Services Criteria your threat model and placed mitigations actually bear on, and which are gaps — a readiness map you can hand to your auditor, never an opinion.
Two honest limits shape that map.
Most of SOC 2 is organizational, not technical. Of the 51 criteria, 38 are control-environment, risk-assessment, monitoring, and HR/vendor-process criteria — a control environment exists, risks are assessed, incidents are communicated. A design-time tool cannot satisfy those; they are your organization's process, and Helmwart marks them organizational rather than claiming a green. Only the 13 logical-access (CC6), system-operations (CC7), change-management (CC8), and vendor-risk (CC9.2) criteria carry a threat surface a model can assess — those are the ones mapped below to the agentic threats they bear on.
The mapping is interpretive. The Trust Services Criteria are AICPA copyrighted material. Every criterion description here is Helmwart's own summary of the criterion's intent, citing SOC 2 — never the standard's verbatim text. Treat it as an interpretive layer, the same posture Helmwart takes toward every framework it reads.
To turn this reference into a live coverage read against a specific system, model it on thecanvas and open the Compliance view — it scores each criterion as covered, at-risk, or not-present from the findings your design actually raises, and lists the mitigations that close each gap.
Trust Services Criteria
The 51 criteria across 13 sections. Criteria that carry a design-time threat surface are tagged mappable and list the agentic threats they bear on; the rest are tagged organizational — real criteria, but your process, not a Helmwart control.
CC1Control Environment
Integrity, ethics, oversight & accountability structures
CC1.1The entity demonstrates a commitment to integrity and ethical values.organizational Ethics & integrity.
CC1.2The board demonstrates independence from management and oversees internal control.organizational Board independence & oversight.
CC1.3Management establishes structures, reporting lines, and authorities/responsibilities.organizational Organizational structure.
CC1.4The entity attracts, develops, and retains competent individuals.organizational Competence.
CC1.5The entity holds individuals accountable for their internal-control responsibilities.organizational Accountability.
CC2Communication & Information
Internal and external information flows supporting control
CC2.1The entity obtains or generates and uses relevant, quality information to support internal control.organizational Quality information.
CC2.2The entity internally communicates information necessary to support internal control.organizational Internal communication.
CC2.3The entity communicates with external parties on matters affecting internal control.organizational External communication.
CC3Risk Assessment
Identifying and analyzing risk to objectives
CC3.1The entity specifies objectives with enough clarity to identify and assess risk.organizational Objective-setting.
CC3.2The entity identifies and analyzes risk to the achievement of its objectives.organizational Risk identification.
CC3.3The entity considers the potential for fraud in assessing risk.organizational Fraud risk.
CC3.4The entity identifies and assesses changes that could significantly impact internal control.organizational Change-impact assessment.
CC4Monitoring Activities
Ongoing evaluation of control effectiveness
CC4.1The entity performs ongoing and/or separate evaluations of internal control.organizational Control evaluation.
CC4.2The entity evaluates and communicates internal-control deficiencies in a timely manner.organizational Deficiency reporting.
CC5Control Activities
Policies and procedures that mitigate risk
CC5.1The entity selects and develops control activities that mitigate risk to objectives.organizational Control-activity selection.
CC5.2The entity selects and develops general control activities over technology.organizational Technology general controls.
CC5.3The entity deploys control activities through policies and procedures.organizational Policy deployment.
CC6Logical & Physical Access Controls
Access over agent identities, tools, data & facilities
CC6.1The entity implements logical access security software, infrastructure, and architectures to protect information assets.mappable Logical access over agent identities, credentials & privilege boundaries.
CC6.2Before issuing system credentials and granting access, the entity registers and authorizes new internal and external users.mappable Credential issuance & onboarding of agent/service identities.
CC6.3The entity authorizes, modifies, or removes access based on roles and least privilege.mappable Least-privilege scoping across delegation hops.
CC6.4The entity restricts physical access to facilities and protected information assets.organizational Physical access.
CC6.5The entity discontinues protections over physical assets only after data/software recoverability is diminished.organizational Asset disposal.
CC6.6The entity implements logical access security measures against threats from outside its system boundaries.mappable Boundary exposure of tools/servers to unintended callers.
CC6.7The entity restricts the transmission, movement, and removal of information to authorized users and processes.mappable Data exfiltration via retrieval or cross-origin browsing.
CC6.8The entity implements controls to prevent, detect, and act upon unauthorized or malicious software.mappable Malicious code entering via execution, framework, or plugin paths.
CC7System Operations
Detection, monitoring, incident response & recovery
CC7.1The entity uses detection and monitoring to identify vulnerable configurations and newly discovered vulnerabilities.mappable Vulnerability monitoring of the supply chain and dependencies.
CC7.2The entity monitors system components for anomalies indicative of malicious acts, disasters, or errors.mappable Monitoring of autonomous-write and resource-consuming behaviour.
CC7.3The entity evaluates security events to determine whether they constitute security incidents.mappable Traceable, non-repudiable action records to evaluate events.
CC7.4The entity responds to identified security incidents via a defined incident-response program.mappable Human override / deactivation of drifted or manipulated agents.
CC7.5The entity identifies, develops, and implements activities to recover from security incidents.mappable Recovery from error, drift, and inconsistent behaviour.
CC8Change Management
Authorizing, testing & approving system changes
CC8.1The entity authorizes, designs, tests, approves, and implements changes to infrastructure, data, software, and procedures.mappable Verification & validation of tool/execution changes before release.
CC9Risk Mitigation
Business-disruption and vendor/partner risk
CC9.1The entity identifies, selects, and develops risk-mitigation activities for business-disruption risk.organizational Business-continuity risk.
CC9.2The entity assesses and manages risks associated with vendors and business partners.mappable Third-party model/tool/agent supply-chain risk.
AAvailability
Capacity, backup & recovery — in scope only if the report covers Availability
A1.1The entity monitors current processing capacity and use to manage capacity demand.organizational Capacity management — in scope only if Availability applies.
A1.2The entity maintains environmental protections, backup, and recovery infrastructure.organizational Backup & recovery infrastructure.
A1.3The entity tests recovery-plan procedures supporting system recovery.organizational Recovery testing.
CConfidentiality
Protecting confidential information — in scope only if the report covers Confidentiality
C1.1The entity identifies and maintains confidential information to meet its confidentiality objectives.organizational Confidential-information inventory — in scope only if Confidentiality applies.
C1.2The entity disposes of confidential information to meet its confidentiality objectives.organizational Confidential-information disposal.
PIProcessing Integrity
Complete, accurate, timely processing — in scope only if the report covers Processing Integrity
PI1.1The entity obtains, uses, and communicates relevant quality information about processing objectives.organizational Processing-objective information — in scope only if Processing Integrity applies.
PI1.2The entity implements policies over system inputs, including completeness and accuracy controls.organizational Input completeness & accuracy.
PI1.3The entity implements policies over system processing to meet the entity's objectives.organizational Processing controls.
PI1.4The entity implements policies to deliver output completely, accurately, and timely.organizational Output delivery.
PI1.5The entity implements policies to store inputs, in-process items, and outputs completely and accurately.organizational Storage of processed data.
PPrivacy
Notice, choice, collection, use & disposal of personal data — in scope only if the report covers Privacy
P1.1The entity provides notice about its privacy practices.organizational Privacy notice — in scope only if Privacy applies.
P2.1The entity communicates choices and obtains consent for collection, use, retention, disclosure, and disposal of personal information.organizational Choice & consent.
P3.1The entity collects personal information consistent with the entity's objectives.organizational Collection.
P4.1The entity limits the use, retention, and disposal of personal information to what is consistent with its objectives.organizational Use, retention & disposal.
P5.1The entity gives individuals access to their personal information for review and correction.organizational Access.
P6.1The entity discloses personal information to third parties consistent with the entity's objectives.organizational Disclosure to third parties.
P7.1The entity collects and maintains accurate, up-to-date, complete personal information.organizational Quality.
P8.1The entity monitors compliance with its privacy policies and addresses inquiries, complaints, and disputes.organizational Monitoring & enforcement.
Trust Services Categories
Not every SOC 2 report covers everything above. Security is mandatory; the four further categories are elective, scoped in only when the engagement calls for them. Helmwart still shows all of them — mostly organizational — so you can see the whole shape of a report before deciding what your engagement covers.
- SecurityMandatory in every SOC 2 report — the 9 Common Criteria (CC1–CC9) above.
- AvailabilitySystems are available for operation and use as committed (criteria A1.1–A1.3).
- ConfidentialityInformation designated confidential is protected as committed (C1.1–C1.2).
- Processing IntegritySystem processing is complete, valid, accurate, timely, and authorized (PI1.1–PI1.5).
- PrivacyPersonal information is collected, used, retained, disclosed, and disposed of per commitments (P1.1–P8.1).
Sources
- AICPA — SOC 2 / Trust Services Criteria ↗ · AICPA · the authoritative framework
- Run the coverage against your model → · Helmwart Compliance · live per-criterion read from your canvas findings