SOC 2 Trust Services Criteria: How Modesto Healthcare Teams Turn Audit Questions Into Operating Controls

SOC 2 Trust Services Criteria are most useful when they become a practical operating map—not a binder assembled for an auditor. For a Modesto clinic, that means connecting EHR access, downtime recovery, vendor oversight, incident response, and evidence ownership to the five criteria and to a team that can prove the controls work.

The decision lands during an EHR access review

At 7:42 a.m. in a Modesto outpatient clinic, the practice administrator is approving a new medical assistant’s access before the first appointments begin. The request is sitting in a ticketing system. The employee needs scheduling and limited clinical access, but not billing administration, export rights, or access to every provider’s records.

The administrator has three questions:

1. Who approved this access?
2. Which role was actually assigned in the identity platform?
3. Can the clinic prove that access was removed when a former employee left last month?

That is a SOC 2 Trust Services Criteria decision in operational form. The issue is not whether someone can produce a polished policy. The issue is whether the clinic’s controls consistently protect information, keep systems available, process requests accurately, preserve confidentiality, and handle personal information appropriately.

The AICPA’s Trust Services Criteria cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. They are used to evaluate and report on controls over the systems and information used to provide products or services.¹ In other words, SOC 2 gives leadership and customers a way to examine whether important promises are backed by repeatable controls and evidence.

For Datapath customers, especially healthcare organizations and mid-market businesses with 100 or more employees, the practical question is narrower:

Which Trust Services Criteria apply to the service we deliver, what could fail, and who can demonstrate that the controls operated consistently?

What are the five SOC 2 Trust Services Criteria?

Security is the foundation. It addresses protection against unauthorized access, use, or modification. In the Modesto clinic, that includes identity lifecycle management, multifactor authentication, endpoint protection, privileged-access review, network segmentation, and monitoring.

Availability concerns whether the systems supporting the service are accessible and usable as committed. For a clinic, that could include EHR access, internet connectivity, phones, scheduling, and the documented process for operating during an outage.

Processing Integrity asks whether processing is complete, valid, accurate, timely, and authorized. A useful example is a patient appointment workflow: does a scheduling change require authorization, reach the correct system, and appear accurately for staff and patients?

Confidentiality concerns information designated as sensitive. That may include clinical records, payment information, credentials, contracts, or internal financial data. Encryption, least-privilege access, secure sharing, and retention rules are examples of controls that support this criterion.

Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of. Its relevance depends on the service and information in scope. A company should not automatically claim that every privacy control applies simply because it is pursuing SOC 2.

The criteria are not five disconnected checklists. A single workflow can touch several of them. Consider a terminated employee:

• Security: the account is disabled and active sessions are revoked.
• Availability: the offboarding process does not disrupt the team’s shared systems.
• Processing Integrity: the termination ticket is complete, authorized, and closed accurately.
• Confidentiality: access to sensitive data is removed promptly.
• Privacy: retained personal information is handled according to the organization’s documented rules.

Where do SOC 2 programs become expensive or unreliable?

The common failure is confusing a control’s existence with a control’s operation. A policy may say that access is reviewed quarterly, but an auditor or customer will want to understand who performed the review, what population was examined, what exceptions were found, and how those exceptions were resolved.

That distinction changes the work. Before creating more documentation, we recommend identifying the critical workflows and their evidence owners.

Operating workflow	Control question	Useful evidence	Likely owner
New-hire access	Was access approved and limited to the employee’s role?	Approved ticket, identity record, role matrix	HR and IT
Termination	Was access removed promptly and completely?	HR notice, disablement log, application checklist	HR and security
EHR downtime	Can staff continue safely and recover records afterward?	Downtime procedure, test results, recovery record	Clinic operations and IT
Security alert	Who decides whether an alert is an incident?	Alert record, escalation notes, incident timeline	Security team
Vendor onboarding	Has the provider’s security responsibility been evaluated?	Review questionnaire, contract terms, approval	Procurement and IT
Backup recovery	Can the organization restore the required service and data?	Restore result, timing record, exception log	Infrastructure team

The point of this table is not to prescribe a universal SOC 2 scope. It is to show how a criterion becomes testable. If the organization cannot name the system, owner, decision, and evidence for a workflow, the control is probably not ready for meaningful assurance.

How should a company map controls to the criteria?

Start with the service commitment, not with a generic control catalog. Ask what the customer relies on the organization to do. A healthcare software provider may emphasize availability and confidentiality. A financial platform may place additional weight on processing integrity. A managed service provider may need to demonstrate security, availability, change management, incident handling, and vendor oversight across its service environment.

Then build a small control map with five columns:

1. Trust Services Criterion
2. Business promise or risk
3. System and workflow in scope
4. Control owner
5. Evidence produced when the control operates

For example:

Criterion: Security

• Risk: A former employee retains access to Microsoft 365 or a line-of-business application.
• Workflow: HR sends a termination notice; IT disables the identity; security verifies downstream applications.
• Owner: Named IT or security lead.
• Evidence: Timestamped ticket, identity-platform record, application confirmation, exception resolution.

Criterion: Availability

• Risk: A clinic cannot access its EHR during a network or cloud-service outage.
• Workflow: Staff invoke downtime procedures, contact the response team, and reconcile records after restoration.
• Owner: Clinic operations and IT leadership.
• Evidence: Procedure, contact list, exercise record, recovery notes, unresolved action items.

This approach also keeps SOC 2 from becoming isolated from the organization’s broader risk program. The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond, and Recover.² Those functions can help a team arrange its control work without pretending that a framework crosswalk automatically proves that a SOC 2 control operated.

Is SOC 2 mainly a cybersecurity project?

No. Cybersecurity is central to the Security criterion, but SOC 2 reaches into accountability and service operations. A technically strong environment can still produce weak assurance if nobody owns access approvals, changes are not documented, vendors are not reviewed, or exceptions disappear into email.

A practical Datapath readiness review looks at four layers:

1. Governance and scope

Define the service, systems, locations, teams, vendors, and data flows in scope. Identify what is intentionally excluded and why. A narrow, defensible scope is better than a broad scope that no one can operate consistently.

2. Technical safeguards

Review identity and access management, MFA, endpoint detection, vulnerability management, centralized logging, backup architecture, encryption, network controls, and cloud configuration. The objective is not to buy every security product. It is to make sure the selected controls address the actual risks and generate usable evidence.

3. Operating procedures

Document how the team handles onboarding, offboarding, access changes, incidents, backups, recovery, patching, vendor reviews, and significant system changes. Procedures should identify decision-makers and escalation paths—not merely list activities.

4. Evidence and accountability

Decide where evidence lives, how long it is retained, who reviews it, and how exceptions are closed. A named team should be able to answer what happened, when it happened, who approved it, and what changed afterward.

What does incident response have to do with SOC 2?

An incident exposes whether controls work together. A suspicious sign-in may begin as a detection event, become an access investigation, require customer communication, and end with a recovery and lessons-learned review.

NIST’s incident-response guidance maps preparation to Govern, Identify, and Protect; detection and analysis to Detect; and containment, eradication, and recovery to Respond and Recover.³ That model is useful because it treats response as part of ongoing risk management rather than as a document opened only after a breach.

For a Modesto clinic, a workable incident workflow might look like this:

1. The security monitoring team identifies an unusual sign-in.
2. The responder validates the user, device, location, and activity.
3. The account is contained if compromise is plausible.
4. The clinic’s designated decision-maker determines operational impact.
5. The team preserves relevant logs and records actions in a timeline.
6. Systems are restored, credentials are reset, and affected workflows are checked.
7. Leadership reviews root cause, control gaps, and required changes.

CISA describes standardized incident-response procedures as a way to identify, coordinate, remediate, recover, and track successful mitigations.⁴ For SOC 2 purposes, the important lesson is not to copy a federal playbook word for word. It is to establish a repeatable process with roles, evidence, communications, and a clear definition of closure.

How can Datapath help make the criteria operational?

Datapath approaches SOC 2 as an accountability problem as much as a technology problem. Our SOC 2 readiness services can help an organization translate criteria into a scoped control plan, evidence calendar, ownership model, and remediation backlog.

Depending on the environment, that work may include:

• Building an access-control and privileged-account review process.
• Connecting endpoint, identity, firewall, and cloud logs to a monitoring workflow.
• Establishing backup and recovery objectives for business-critical systems.
• Testing incident escalation with named contacts and decision rights.
• Reviewing vendors that handle sensitive information or support critical services.
• Creating evidence standards for tickets, approvals, reviews, tests, and exceptions.
• Coordinating with an internal IT team through co-managed IT when the organization already has technical staff.
• Adding strategic security ownership through vCISO services when leadership needs executive-level guidance.

For a clinic, that may mean integrating identity, EHR, backup, and incident workflows. For a bank or credit union, it may mean tighter approval and vendor-risk evidence around systems that support financial processing. For a school district or local-government team, the emphasis may be on service availability, access accountability, and clearly assigned response responsibilities.

What should leadership ask before pursuing SOC 2?

Ask these questions before selecting tools or promising a report date:

• What exact service and customer promise are we evaluating?
• Which of the five criteria are relevant to that service?
• Which systems and third parties can affect the result?
• Who owns each control when the normal process fails?
• What evidence will show that the control operated—not just that a policy exists?
• How are exceptions approved, tracked, and closed?
• Can the team explain what happens during an outage, suspected compromise, or failed access review?
• Which controls should be improved before an auditor or customer asks for evidence?

If the answers depend on one overextended administrator or on evidence scattered across email, spreadsheets, and vendor portals, the organization has found its first readiness priority.

The Datapath perspective

SOC 2 Trust Services Criteria are valuable because they connect technology decisions to customer confidence and operational accountability. The strongest program is not the one with the largest policy library. It is the one where a real team can show how access is approved, how systems are restored, how incidents are handled, how vendors are evaluated, and how exceptions reach leadership.

From Modesto and the Central Valley to Modesto and California communities such as Modesto, Datapath helps organizations build that operating discipline around the systems they actually depend on. If your team needs to turn SOC 2 from an abstract audit objective into owned, testable workflows, start with a focused SOC 2 readiness conversation and identify the first three controls that must work every time.

^{1 2 3 4}

---

Footnotes

1. 2017 Trust Services Criteria (With Revised Points of Focus – 2022) | Resources | AICPA & CIMA ↩ ↩²

2. The NIST Cybersecurity Framework (CSF) 2.0 ↩ ↩²

3. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile ↩ ↩²

4. Fetched web page ↩ ↩²