Mapping Trust Service Criteria to Engineering Controls

The Trust Services Criteria tell an organization what its security posture must achieve. They say nothing about how to build it. That gap between a criterion like "logical access is restricted to authorized users" and the actual authentication service, provisioning script, and access review ticket that satisfy it is where every SOC 2 engagement either succeeds or falls apart during fieldwork.

The AICPA developed the TSC, and it underpins SOC 2 reporting. It is not a regulation, and it is not a technical standard in the way the named control catalogs published by major standards bodies are. It is a set of statements about outcomes an organization's controls must achieve, evaluated for design and operating effectiveness. The 2017 version remains the operative standard going into 2026. The October 2022 revision updated the Points of Focus, the illustrative guidance underneath each criterion, but it left the 61 criteria themselves untouched. Those 61 criteria sit inside five trust service categories, and they line up with the COSO Internal Control, Integrated Framework, which is why the first five Common Criteria groups map almost directly onto COSO's five components: Control Environment, Communication and Information, Risk Assessment, Monitoring Activities, and Control Activities.

Because the TSC is non-prescriptive, there is no master list of required controls anywhere in the document. An auditor will not hand an engineering team a checklist that says "deploy Okta" or "configure a SIEM." The framework states the criterion, and the organization has to invent, document, and run the control that satisfies it. That translation work falls on engineering and GRC teams working together, and most companies underestimate how much of it there is until the first audit cycle exposes the gaps.

Security, labeled the Common Criteria and numbered CC1 through CC9, is mandatory in every SOC 2 engagement. No exceptions, no negotiating this one. It covers access control, system operations, change management, risk assessment, incident response, and governance. Nothing else on the list is required, and companies should resist the instinct to scope in more than they need just because a competitor did.

Availability asks whether the system is available as committed, and it pulls in capacity planning, performance monitoring, disaster recovery, and backup processes. Add it when the organization has SLAs to defend, not before. Processing Integrity makes sure processing is complete, valid, accurate, timely, and authorized, covering input validation, reconciliation, output completeness, and CI/CD change validation. It matters most when data accuracy sits at the center of what the service actually does, which is exactly why it is the category AI vendors most often try to skip.

Confidentiality protects information the organization has designated as confidential: data classification, encryption, access restrictions, retention and disposal schedules, and contractual obligations. It fits naturally when NDAs or sensitive intellectual property are part of the customer relationship. Privacy, governed by the AICPA's Generally Accepted Privacy Principles, echoes GDPR and CCPA in spirit, covering consent, data subject rights, cross-border transfer controls, and third-party sharing, though a SOC 2 Privacy attestation covers the organization's own privacy controls, not compliance with GDPR or CCPA as statutes. It becomes necessary once an organization handles personally identifiable information directly, rather than as a downstream processor.

The scoping decision determines evidence obligations across the entire observation period rather than at a single point in time, since every added category adds requirements throughout that window. Somewhere between 55 and 65 percent of first-time audits scope only Security, sometimes adding Availability, and broader scopes tend to get added in later audit cycles. For SaaS and tech companies, the baseline that satisfies enterprise buyers is Security, Availability, and Confidentiality together. Vendor risk questionnaires ask for those three most often, and a company that scopes wider than that on day one is usually wasting audit budget it doesn't need to spend yet.

The nine Common Criteria groups and the engineering controls that satisfy each one

CC1, Control Environment, is about leadership commitment: an organizational structure with defined security responsibilities, management accountability, and documented performance objectives that actually include security. Auditors look for a security charter, an org chart, and evidence that security appears in how the company measures itself on an ongoing basis, beyond a slide someone made for the board once.

CC2, Communication and Information, wants security policies written down and distributed to staff and contractors, security awareness training completed, and incident reporting channels that work. The engineering control here is a policy management system with tracked acknowledgements and training completion records. A PDF sitting in a shared drive that nobody has opened since onboarding does not count, no matter how well written it is.

CC3, Risk Assessment, requires formal risk identification and scoring, an assessment of likelihood and impact, and documented decisions about how each risk gets treated. The control that satisfies this is a risk register reviewed on a recurring schedule with dated entries, maintained continuously rather than built once before the audit and never touched again.

CC4, Monitoring Activities, calls for ongoing evaluation of whether controls actually work: internal audits, management reviews, remediation tracking. Automated control-monitoring tooling that flags failures and routes them to the right person beats a quarterly manual check that someone might forget, every time.

CC5, Control Activities, covers authorization, approval, and segregation of duties: the policies and procedures that carry out what management has decided. Auditors want role-based access policies and approval workflows enforced in the tooling itself, rather than by convention or by trusting people to do the right thing.

Among the whole Common Criteria section, CC6, Logical and Physical Access Controls, forms the largest and most evidence-intensive group, and it earns its own breakdown. Logical access security controls enforced across every in-scope system are what CC6.1 wants, with strong authentication measures such as multi-factor authentication serving as a common way to satisfy it. CC6.2 wants access provisioning tied to a documented onboarding process with real approvals, and deprovisioning that fires automatically when someone leaves, which is the exact point where evidence trails fail most often even when the underlying process exists on paper. Access reviews with documented sign-off from the reviewer are required on a cadence that's actually defined rather than done whenever someone remembers. Physical access controls round out the group: keycards or equivalent systems for server rooms or colocation facilities, visitor logs, periodic physical access reviews, network segmentation that keeps production separate from development with firewall rules documented and reviewed, and documented data disposal procedures for media sanitization and device decommissioning.

CC7, System Operations, needs security monitoring across every system in scope. CC7 wants SIEM alerts, incident tickets, and on-call runbooks as evidence, anomaly detection configured with real thresholds, and incident response procedures that have actually been tested through live exercises.

CC8, Change Management: CC8.1 requires a change approval workflow enforced through tooling, GitHub pull request approvals or Jira change tickets rather than a verbal "looks good, ship it" in a thread on a team messaging app. No direct-to-production deployments without review, and change records kept across the full observation period.

CC9, Risk Mitigation: CC9 requires vendor risk assessments before onboarding any subprocessor, a vendor register maintained and reviewed on a defined schedule, and collection of each subprocessor's own SOC 2 and ISO 27001 reports.

Across all nine groups, each criterion needs its own evidence trail spanning the entire observation period, typically six to twelve months for a Type II report, and the relationship between a control, the evidence it produces, and the criterion it satisfies is rarely clean. One control can satisfy several criteria at once. One criterion often needs evidence pulled from several different systems.

Engineering controls for Availability, Confidentiality, and Processing Integrity when those categories are in scope

Availability controls start with uptime monitoring and alerting tied to actual SLA thresholds, with infrastructure health dashboards kept as evidence rather than glanced at once and forgotten. A disaster recovery plan needs to be documented, tested, and built around defined recovery time and recovery point objectives, with the test results kept on file. Backup processes should run on their own, with restoration tested on a defined schedule and backup logs kept as proof. Capacity planning needs a documented process for forecasting load and scaling ahead of it, with capacity reviews kept as records. Incident response for availability events needs runbooks written specifically for outage scenarios, with post-incident reviews written up after the fact, not reconstructed from memory weeks later.

Confidentiality controls begin with a data classification scheme: documented tiers such as confidential, internal, and public, each with its own handling rules. Encryption at rest and in transit for confidential data is table stakes, paired with documented key management procedures. Access restrictions beyond the general security baseline mean confidential data is only reachable by roles with a documented business need, not by default. Retention and disposal need a defined schedule, secure deletion procedures, and disposal logs kept as evidence. Contractual obligations round out the group: NDA and confidentiality agreement templates reviewed by legal, counterparty agreements tracked in a system rather than in someone's inbox.

Processing Integrity controls include input validation that rejects or quarantines malformed or unauthorized inputs before they ever get processed. Reconciliation checks confirm outputs match what was expected, with reconciliation logs kept on file. Error detection needs automated alerting on processing failures with a documented escalation path, so a failure doesn't sit unnoticed for days. Authorization workflows require processing jobs to carry documented approval or system-level authorization, with audit logs showing who or what authorized each run. Change validation inside CI/CD pipelines means automated tests check processing logic before anything reaches deployment.

Processing Integrity is the category most directly implicated by AI-driven processing, and it is also the one vendors most often leave out of scope when their product runs on a model. If a vendor's service depends on model accuracy and data transformation but Processing Integrity is missing from its SOC 2, that is not an oversight worth letting slide. Ask the vendor directly why the category was excluded, and treat a weak answer as the red flag it is.

Where AI systems create new evidence obligations inside the existing TSC structure

There is no separate "SOC 2 for AI." The same 2017 TSC applies whether the service runs on a rules engine or a large language model. What changes is scope: the audit now has to follow the machine learning lifecycle, and auditors are asking for evidence categories a traditional SaaS company never had to produce.

Reporting from Linford & Co. describes what AI-aware auditors are asking for heading into 2026. Model lineage documentation, for every deployed model, a record of the exact dataset, code version, and approval behind it. Prompt and inference logs with PII redacted before logging ever happens. Drift monitoring output that shows model behavior gets tracked over time, with deviations escalated rather than shrugged off. A vendor risk assessment for every third-party LLM called in production, not just the primary infrastructure provider.

Shadow AI is a real and growing exposure, and it deserves more alarm than most GRC teams currently give it. Engineers piping company data into unapproved AI tools create unvetted subprocessors that bypass change management and vendor review entirely, and Industry reporting notes auditors are actively hunting for it. The engineering control that addresses this is tooling that detects or blocks unauthorized AI API calls from company systems, treating an unsanctioned browser tab open to an outside AI service the same way a security team would treat an unsanctioned database connection. Anything less than that is a policy that exists on paper and nowhere else.

There's also what might be called the agent accountability gap. When an autonomous agent takes a privileged action, SOC 2 expects that action to trace back to an accountable person. A generic service account doesn't satisfy that expectation, full stop. The control is logging agent actions with a mapped human owner or an approval chain behind them, so "the agent did it" never gets to be the end of the audit trail.

These obligations land inside the existing structure rather than creating a new one: CC3 now has to treat AI systems as part of risk assessment, CC6 has to extend access controls to model inference endpoints, CC8's change management has to cover model deployments the same way it covers code deployments, CC9's vendor risk work has to cover LLM subprocessors, and Processing Integrity has to account for accuracy and drift. Konfirmity's research found that nearly 90 percent of SOC 2 reports now include subservice providers, and that third-party breaches cost roughly 40 percent more to remediate than incidents that start in-house. Mapping the vendor risk chain for LLM subprocessors is not paperwork for its own sake. It is the difference between a contained incident and an expensive one.

What the LLM subprocessor relationship means for CC9 and vendor risk evidence

An LLM provider sits outside the organization's own SOC 2 system boundary. It's a subprocessor, not a controlled internal component, and the audit can't reach into the provider's infrastructure to test it directly. Treat any vendor pitch that implies otherwise with suspicion.

What the organization's SOC 2 actually attests to is its own controls over how it uses that LLM: the vendor risk assessment process it ran before onboarding, the data-retention configuration it chose, the training opt-out settings it turned on, and its own review of the provider's SOC 2 and ISO 27001 reports. Enterprise procurement heading into 2026 expects both halves of that picture, the company's own SOC 2 and proof that its LLM subprocessors are independently audited too. One without the other leaves a gap a vendor risk team will catch immediately.

The engineering controls that satisfy CC9.1 for LLM subprocessors start with a model vendor register: provider name, model version, data categories processed, and the contractual data handling terms attached to each. Each provider's SOC 2 Type II and ISO 27001 reports need to get collected and reviewed on a set cadence throughout the relationship. Training opt-out configuration needs to be documented and verified as contractually enforced, with ongoing oversight beyond a toggle set once in a settings panel. A risk assessment needs to run before any new LLM provider gets onboarded, with the assessment and approval kept on file. Re-assessment needs to happen whenever a provider changes its data handling terms or ships a new model version that ends up in production.

In May 2026, CISA and G7 partners published minimum elements for an AI software bill of materials, extending the idea of software component transparency to models, datasets, and the relationships used to build AI systems. Organizations building toward that standard will need their vendor register to track model versions specifically, with that level of granularity beyond providers in the abstract.

How evidence architecture determines whether a mapped control passes audit

Different questions get answered by Type I and Type II reports. Type I attests that controls are designed well at a single point in time. Type II attests that those controls actually operated effectively across a defined period, usually six to twelve months, and Type II is the baseline enterprise buyers expect before they'll even open a commercial conversation. A company that shows up with only a Type I is going to get asked why.

Teams consistently underestimate the evidence load, and this is where most first-time audits actually go sideways. Each of the 61 criteria needs its own trail of proof stretching across the full observation window, and the relationship between a control, the evidence it throws off, and the criterion it satisfies is rarely one-to-one. A single control can satisfy several criteria at once. A single criterion might need evidence pulled from three or four different systems before it's actually covered.

CC6 carries the heaviest evidence burden in the entire Common Criteria section: provisioning approvals, deprovisioning records, MFA enforcement logs, network segmentation documentation, physical access logs, data disposal records. Each of those needs its own separate trail, and none of them substitute for each other, so teams that try to shortcut CC6 by reusing one document for three purposes tend to get caught in fieldwork.

The gaps that appear in fieldwork tend to repeat across companies, and they're almost always the same handful. Access reviews that exist as a stated process but have no documented reviewer sign-off attached (CC6.3). Change approvals enforced by convention, by a message sent through an internal chat tool or a verbal nod, rather than by tooling, which leaves nothing durable behind (CC8.1). Vendor assessments completed once at onboarding and never run again on any defined cadence (CC9.1). Incident tickets that exist in isolation, disconnected from the monitoring alert that actually triggered them (CC7.2).

The fix is architectural: map each control to a specific evidence artifact, name the system that produces it, set a retention period, and automate the collection wherever possible so the trail builds itself continuously. SOC 2+ examinations also let controls get mapped simultaneously against other frameworks, NIST CSF, HIPAA, HITRUST, ISO 42001 among them, so organizations juggling multiple compliance obligations can design a control once and generate evidence that satisfies several frameworks at the same time.

Where AI-specific governance gaps require controls outside the TSC's current scope

The TSC's current form leaves AI fairness, bias, and explainability unaddressed. That is not a mapping failure, and it is not a mistake in how some company implemented its controls. It is a limit built into the scope of the framework itself, and no amount of clever control design closes it. Anyone who claims their SOC 2 report covers algorithmic fairness is misreading what the attestation actually says.

Processing Integrity and Privacy can absorb part of the AI risk picture: accuracy of model outputs falls under one, PII handling in training data falls under the other. But full AI governance asks for something those two categories were never built to produce. ISO 42001 exists to fill exactly that space: an AI management system standard built around risk management for AI-specific harms, bias assessment, and the kind of transparency and explainability review that sits outside what a SOC 2 report, no matter how carefully scoped, was ever designed to attest to.