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 the canvas 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.
CC1 Control Environment
Integrity, ethics, oversight & accountability structures
-
CC1.1 The entity demonstrates a commitment to integrity and ethical values. organizational Ethics & integrity.
-
CC1.2 The board demonstrates independence from management and oversees internal control. organizational Board independence & oversight.
-
CC1.3 Management establishes structures, reporting lines, and authorities/responsibilities. organizational Organizational structure.
-
CC1.4 The entity attracts, develops, and retains competent individuals. organizational Competence.
-
CC1.5 The entity holds individuals accountable for their internal-control responsibilities. organizational Accountability.
CC2 Communication & Information
Internal and external information flows supporting control
-
CC2.1 The entity obtains or generates and uses relevant, quality information to support internal control. organizational Quality information.
-
CC2.2 The entity internally communicates information necessary to support internal control. organizational Internal communication.
-
CC2.3 The entity communicates with external parties on matters affecting internal control. organizational External communication.
CC3 Risk Assessment
Identifying and analyzing risk to objectives
-
CC3.1 The entity specifies objectives with enough clarity to identify and assess risk. organizational Objective-setting.
-
CC3.2 The entity identifies and analyzes risk to the achievement of its objectives. organizational Risk identification.
-
CC3.3 The entity considers the potential for fraud in assessing risk. organizational Fraud risk.
-
CC3.4 The entity identifies and assesses changes that could significantly impact internal control. organizational Change-impact assessment.
CC4 Monitoring Activities
Ongoing evaluation of control effectiveness
-
CC4.1 The entity performs ongoing and/or separate evaluations of internal control. organizational Control evaluation.
-
CC4.2 The entity evaluates and communicates internal-control deficiencies in a timely manner. organizational Deficiency reporting.
CC5 Control Activities
Policies and procedures that mitigate risk
-
CC5.1 The entity selects and develops control activities that mitigate risk to objectives. organizational Control-activity selection.
-
CC5.2 The entity selects and develops general control activities over technology. organizational Technology general controls.
-
CC5.3 The entity deploys control activities through policies and procedures. organizational Policy deployment.
CC6 Logical & Physical Access Controls
Access over agent identities, tools, data & facilities
-
CC6.1 The entity implements logical access security software, infrastructure, and architectures to protect information assets. mappable Logical access over agent identities, credentials & privilege boundaries.
-
CC6.2 Before 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.3 The entity authorizes, modifies, or removes access based on roles and least privilege. mappable Least-privilege scoping across delegation hops.
-
CC6.4 The entity restricts physical access to facilities and protected information assets. organizational Physical access.
-
CC6.5 The entity discontinues protections over physical assets only after data/software recoverability is diminished. organizational Asset disposal.
-
CC6.6 The entity implements logical access security measures against threats from outside its system boundaries. mappable Boundary exposure of tools/servers to unintended callers.
-
CC6.7 The entity restricts the transmission, movement, and removal of information to authorized users and processes. mappable Data exfiltration via retrieval or cross-origin browsing.
-
CC6.8 The entity implements controls to prevent, detect, and act upon unauthorized or malicious software. mappable Malicious code entering via execution, framework, or plugin paths.
CC7 System Operations
Detection, monitoring, incident response & recovery
-
CC7.1 The entity uses detection and monitoring to identify vulnerable configurations and newly discovered vulnerabilities. mappable Vulnerability monitoring of the supply chain and dependencies.
-
CC7.2 The entity monitors system components for anomalies indicative of malicious acts, disasters, or errors. mappable Monitoring of autonomous-write and resource-consuming behaviour.
-
CC7.3 The entity evaluates security events to determine whether they constitute security incidents. mappable Traceable, non-repudiable action records to evaluate events.
-
CC7.4 The entity responds to identified security incidents via a defined incident-response program. mappable Human override / deactivation of drifted or manipulated agents.
-
CC7.5 The entity identifies, develops, and implements activities to recover from security incidents. mappable Recovery from error, drift, and inconsistent behaviour.
CC8 Change Management
Authorizing, testing & approving system changes
-
CC8.1 The entity authorizes, designs, tests, approves, and implements changes to infrastructure, data, software, and procedures. mappable Verification & validation of tool/execution changes before release.
CC9 Risk Mitigation
Business-disruption and vendor/partner risk
-
CC9.1 The entity identifies, selects, and develops risk-mitigation activities for business-disruption risk. organizational Business-continuity risk.
-
CC9.2 The entity assesses and manages risks associated with vendors and business partners. mappable Third-party model/tool/agent supply-chain risk.
A Availability
Capacity, backup & recovery — in scope only if the report covers Availability
-
A1.1 The entity monitors current processing capacity and use to manage capacity demand. organizational Capacity management — in scope only if Availability applies.
-
A1.2 The entity maintains environmental protections, backup, and recovery infrastructure. organizational Backup & recovery infrastructure.
-
A1.3 The entity tests recovery-plan procedures supporting system recovery. organizational Recovery testing.
C Confidentiality
Protecting confidential information — in scope only if the report covers Confidentiality
-
C1.1 The entity identifies and maintains confidential information to meet its confidentiality objectives. organizational Confidential-information inventory — in scope only if Confidentiality applies.
-
C1.2 The entity disposes of confidential information to meet its confidentiality objectives. organizational Confidential-information disposal.
PI Processing Integrity
Complete, accurate, timely processing — in scope only if the report covers Processing Integrity
-
PI1.1 The entity obtains, uses, and communicates relevant quality information about processing objectives. organizational Processing-objective information — in scope only if Processing Integrity applies.
-
PI1.2 The entity implements policies over system inputs, including completeness and accuracy controls. organizational Input completeness & accuracy.
-
PI1.3 The entity implements policies over system processing to meet the entity's objectives. organizational Processing controls.
-
PI1.4 The entity implements policies to deliver output completely, accurately, and timely. organizational Output delivery.
-
PI1.5 The entity implements policies to store inputs, in-process items, and outputs completely and accurately. organizational Storage of processed data.
P Privacy
Notice, choice, collection, use & disposal of personal data — in scope only if the report covers Privacy
-
P1.1 The entity provides notice about its privacy practices. organizational Privacy notice — in scope only if Privacy applies.
-
P2.1 The entity communicates choices and obtains consent for collection, use, retention, disclosure, and disposal of personal information. organizational Choice & consent.
-
P3.1 The entity collects personal information consistent with the entity's objectives. organizational Collection.
-
P4.1 The entity limits the use, retention, and disposal of personal information to what is consistent with its objectives. organizational Use, retention & disposal.
-
P5.1 The entity gives individuals access to their personal information for review and correction. organizational Access.
-
P6.1 The entity discloses personal information to third parties consistent with the entity's objectives. organizational Disclosure to third parties.
-
P7.1 The entity collects and maintains accurate, up-to-date, complete personal information. organizational Quality.
-
P8.1 The 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.
- Security Mandatory in every SOC 2 report — the 9 Common Criteria (CC1–CC9) above.
- Availability Systems are available for operation and use as committed (criteria A1.1–A1.3).
- Confidentiality Information designated confidential is protected as committed (C1.1–C1.2).
- Processing Integrity System processing is complete, valid, accurate, timely, and authorized (PI1.1–PI1.5).
- Privacy Personal 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