Is SOC 2 Type II Enough for a Secure Cloud EHR? What Practices Need to Know

If I do not beat around the bush and come straight to the point, then no, SOC 2 Type II alone is not enough for cloud EHR security, though it is the strongest proof you can get that a vendor protects your patient data on its own side. The report means an independent CPA firm tested the vendor’s security controls and confirmed that they kept working over several months, which carries far more weight than a sales promise. However, the vendor decides which systems the audit covers, so the report checks only part of your EHR security.

Three important questions still remain with you:

• You need to know whether the EHR software has protections like audit logs and multi-factor login
• Whether a signed business associate agreement makes the vendor answerable for a breach, and 
• Whether your own staff keep their logins safe

Hence, we wrote this blog for practice owners, administrators, and physicians at independent clinics who are choosing or reviewing a cloud EHR without a security team of their own. Every point traces back to a primary source, including AICPA guidance, HHS rules under HIPAA, ONC certification criteria, and CMS’s current MIPS requirements, so you can verify each one yourself.

The sections follow the order these questions come up when you evaluate an EHR. That starts with the audit scope, because what the auditor agreed to test decides how much a SOC 2 Type II report can tell you about your vendor.

What SOC 2 Type II Covers in a Cloud EHR

The auditor was looking at controls, and the rulebook for them comes from the AICPA. Its SOC suite defines SOC 2 as a report on a service organization’s controls in five areas, called the Trust Services Criteria. In EHR terms, they mean.

• Security: It is the one area every SOC 2 must include. It covers who can get into the system and how the vendor detects and handles intrusions.
• Availability: It shows whether controls kept the EHR reachable and recoverable, which matters when your schedule depends on it.
• Processing integrity: It applies when lab results, orders, and claims must post completely and accurately.
• Confidentiality: It covers how restricted information is protected and disposed of.
• Privacy: It follows the AICPA’s own privacy criteria, which are separate from the HIPAA Privacy Rule.

The vendor decides which of the last four go into the examination. A vendor that says “we have SOC 2 Type II” may have been tested on Security alone, and the report’s opening pages tell you which criteria made the cut.

The word “Type” in SOC 2 Type II tells you how long the auditor watched.

So, a Type I report checks whether controls were suitably designed and in place as of one date, while a Type II report tests whether those controls worked across a stated review period, so you get evidence from many ordinary workdays.

However, one detail is easy to miss here. 

An article on SOC credibility in the AICPA’s own journal points out that “compliance” is a term SOC 2 examinations never use.

What you receive is an attestation report with an auditor’s opinion, so “SOC 2 certified” on a vendor’s website tells you little until you see the report itself.

And that same article mentions that the report is restricted to specified parties, which means getting a copy requires a request.

How to Read Your EHR Vendor’s SOC 2 Report

Because the report is restricted-use, the vendor may ask you to sign a nondisclosure agreement first. 

The AICPA also offers a SOC 3, a general-use version anyone can read, yet it carries only the auditor’s opinion and leaves out the detailed testing you need.

And just to let you know, HIPAA will not hand you the full report either.

HHS cloud guidance says the rules don’t require a cloud vendor to share its security documentation or allow audits, though you can require that through your business associate agreement (BAA) or service level agreement. 

So, put the request in the contract before you sign, while you still have leverage.

Now, once the report arrives, read these parts in this order.

• Auditor’s opinion: An unqualified opinion means the auditor found the controls met the criteria. A qualified opinion flags at least one area that fell short, so find out which one.
• System description: Look for the modules your clinic will use, such as the patient portal, e-prescribing, billing, and telehealth. A module missing from this section was outside the examination. Check connected services as well, such as lab interfaces, clearinghouse connections, and AI tools added to the EHR, because a service another company runs stays outside the report unless it is named there.
• Carved-out providers: If your EHR runs on servers rented from a hosting company and the report “carves out” that host, the auditor did not test the host’s controls, so ask for the host’s own SOC 2 report too.
• Exceptions: An exception means a control failed in at least one sample the auditor checked. Read management’s response beside it and ask whether the fix is in place today.
• Review period: Note the date the period ended. For the gap between that date and today, request a bridge letter, a statement from vendor management that controls haven’t materially changed. Management signs it, and no auditor tests it.

Pay attention to the CPA firm behind the opinion as well.

Because the same AICPA journal article reports that SOC tool companies, now numbering in the dozens, market reports delivered in weeks, and one SOC 2 Working Group member described reports that look identical apart from the client’s logo.

Moreover, the AICPA’s own SOC page now carries a notice that it is looking into allegations about one compliance vendor’s SOC practices and refers unlicensed firms to state boards of accountancy.

So, note the firm’s name on the opinion, confirm it holds a CPA firm license with its state board, and treat a report that reads as generic or that leans more on interviews with vendor staff than on evidence as a reason for follow-up questions.

Inside that system description sits one more list, and this one is written specifically for your clinic.

The Cloud EHR Security Controls Your Clinic Still Owns

That list is called complementary user entity controls, or CUECs. These are the controls the vendor assumes its customers will implement when designing its own controls. If your clinic skips them, the auditor’s conclusions may not fully apply to your account. 

Your vendor’s report sets the exact list, and in a cloud EHR it can include items like these.

• Removing EHR access the same day someone leaves your practice
• Giving each staff member a role that limits which charts and functions they can open
• Turning on multi-factor authentication (MFA) wherever the EHR offers it
• Reviewing the EHR’s audit logs for unusual access
• Securing the laptops, tablets, and front desk computers that log in

HHS treats this division of duties seriously. 

Its guidance says that when a contract assigns certain security features to the customer and the customer doesn’t implement them, OCR will weigh that during an investigation, and the vendor isn’t responsible for failures caused solely by the customer.

The same guidance expects your practice to understand the vendor’s cloud setup well enough to run its own risk analysis. 

Your CUEC list gives that analysis a ready starting point, and the free SRA tool, built by ONC with HHS’s Office for Civil Rights, helps you document it. Turn each CUEC into a named task with an owner, and your office manager has a security checklist to work from.

For clinics reporting to MIPS, this work now carries a scoring consequence. 

CMS’s MIPS guide for 2026 adds a second yes-or-no attestation to the Security Risk Analysis measure, covering whether you carried out the risk management the HIPAA Security Rule requires, and a “No” zeroes the entire Promoting Interoperability category. 

The analysis must also cover your certified EHR functionality, and CMS asks you to keep the supporting documentation for six years. Small practices have that category reweighted automatically, yet the HIPAA duty to run a risk analysis still applies to them.

One item on that list, MFA, depends on something SOC 2 doesn’t settle, which is whether the EHR software supports it in the first place.

What SOC 2 Type II Doesn’t Cover, and What Fills the Gap

Whether the software supports MFA is a product question, and ONC certification is where product questions get answered. 

ONC-certified EHR modules are held to privacy and security criteria such as authentication, audit reports, and automatic access time-out. 

Under ONC’s MFA criterion, the developer must attest either yes or no to supporting multi-factor authentication, and a “no” still passes, so an EHR can be ONC-certified without offering MFA at all. 

Look the product up in ONC’s Certified Health IT Product List (CHPL), then ask the vendor for its MFA attestation and the use cases it described, which ONC requires whenever a developer answers yes.

Legal accountability is the next gap. SOC 2 comes from the accounting profession, and no federal law requires it of an EHR vendor. 

HIPAA is federal law, and HHS states that a practice storing patient data with a cloud vendor without a signed business associate agreement is violating it, whatever the vendor’s SOC 2 status. 

The BAA must also require the vendor to return or destroy your data when the relationship ends, where feasible.

Time is the last gap. A clean report describes how controls performed during a period that has already ended, so it can’t tell you whether the vendor will be breached next month. 

That is why the contract terms and your clinic’s own safeguards carry so much weight.

Put together, each document answers a different question.

Document	Issued by	What it answers
SOC 2 Type II	Independent CPA firm	Did vendor controls work over time?
ONC certification	ONC-authorized certification body	What can the software do?
BAA	Vendor and your practice	Who is accountable for your data?
Risk analysis	Your practice	Where is your clinic exposed?

Every row in that table becomes a question you can put to a vendor across the demo table.

EHR Vendor Security Questions to Ask Before You Sign

Those demo questions do the most work when they cover ground the SOC 2 report leaves open. Use the seven below as your cloud EHR security checklist for every vendor on your shortlist, and get the answers in writing.

Where are our patient records stored? 

HHS allows servers outside the U.S. with a BAA in place, yet it tells practices to weigh the added risk of offshore storage in their risk analysis.

Is our data encrypted to HHS’s standard? 

When ePHI encrypted to HHS guidance is breached, the incident falls within a safe harbor and needs no breach report, while weaker encryption still counts as a breach. Ask the vendor to confirm in writing that its encryption meets that guidance.

How fast will you report a security incident to us? 

The BAA must require incident reporting, but HIPAA leaves the detail, timing, and format for you and the vendor to agree on. The Breach Notification Rule separately governs breaches of unsecured patient data, and your BAA can set a faster deadline than that rule but never a slower one. Set a timeframe you can live with.

Which other companies touch our data? 

A subcontractor that stores your records for the vendor, such as a hosting company, is itself a business associate and needs a BAA with the vendor.

How do you back up our data and restore it after ransomware? 

HHS names backup and data recovery as terms a service level agreement can spell out, so ask for recovery times on paper.

What happens to our data if we leave? 

Ask for the export format and timeline. HHS warns that contract terms should never block your access to your own records.

Which MFA methods do you support, and for whom? 

Ask separately about staff logins, admin accounts, and the patient portal.

If OmniMD is on your shortlist, bring these same seven to your demo. A few related questions deserve direct answers of their own.

Keep Cloud EHR Security on Your Calendar After You Sign

Asking those questions once, at signing, protects the day you sign. Each SOC 2 Type II report describes a period that has already closed, so its value fades as the months pass and your practice changes. Three moments call for a fresh look.

• When the vendor issues its next report: Request it, compare its scope and criteria with the previous one, and read any new exceptions.
• When you add a module or integration: A telehealth add-on, a new portal feature, or an AI tool may sit outside the current report until the vendor’s scope catches up.
• When staff join or leave: Each change triggers the clinic-side controls on your CUEC list, starting with access.

Put those three triggers on your office manager’s calendar, and your cloud EHR security keeps pace with your practice. If OmniMD is on your shortlist, book a demo, ask our team for the security documentation behind each answer, and hold us to the same seven questions.