Can AI Draft SOC 2 and ISO 27001 Compliance Documentation for EHR Vendors?

TL;DR

• AI drafting tools can generate first-pass SOC 2 and ISO 27001 policy language, control descriptions, and gap analyses faster than a human writing from scratch, but they cannot generate audit-ready evidence.
• Evidence artifacts (access logs, change tickets, penetration test reports, vendor risk assessments) must be pulled from real systems and verified by a human before they go into an audit package.
• Control mapping and risk acceptance decisions still require a compliance officer or security lead to sign off, because AI does not carry accountability for an audit opinion.
• For IT admins evaluating an EHR or overlay vendor, the report type (SOC 2 Type I vs Type II), the audit period, and the exception list matter far more than whether the vendor used AI to draft its documentation.
• Thyra's own compliance posture follows this same discipline: AI-assisted drafting for internal policy work, paired with human-reviewed evidence and a named accountable owner for every control.

Can AI draft SOC 2 or ISO 27001 documentation for a healthcare software vendor?

Yes, AI can draft a meaningful first draft of SOC 2 and ISO 27001 documentation, but it cannot complete the compliance process on its own, and treating a drafted document as audit-ready without human validation is a common and costly mistake.

SOC 2 (a report against the AICPA Trust Services Criteria) and ISO 27001 (a certifiable information security management system standard) both require two distinct kinds of output: written policies and procedures, and evidence that those policies and procedures are actually followed in day-to-day operations. AI language models are genuinely useful for the first category. They can draft an access control policy, an incident response runbook, a vendor risk management procedure, or a data retention schedule in a fraction of the time it would take a compliance analyst to write from a blank page. They can also translate control language across frameworks, for example mapping a SOC 2 CC6.1 logical access control to the corresponding ISO 27001 Annex A control, which saves real time during a dual-framework effort.

What AI cannot do is generate evidence. An auditor does not accept a policy document as proof that a control operated effectively over a review period. They want the access review ticket, the quarterly firewall rule audit log, the signed vendor risk questionnaire, the penetration test remediation tracker. Those artifacts come from actual systems of record: the identity provider, the ticketing system, the vendor management tool. AI can help summarize or format that evidence once it exists, but it cannot fabricate a defensible audit trail, and any team that tries will fail the audit or worse, pass it on documentation that does not reflect operational reality.

What parts of SOC 2 and ISO 27001 prep are actually well-suited to AI drafting?

AI drafting tools are most useful for the structural and narrative work of compliance, not for the evidentiary work.

In practice, the tasks that benefit most from AI assistance include:

• Policy and procedure drafting. Writing the initial version of an information security policy, acceptable use policy, or incident response plan against a known control framework. A human still needs to edit for accuracy against the vendor's actual environment.
• Control narrative writing. Describing how a specific control operates, for example how multi-factor authentication is enforced across production systems, in the language an auditor expects to see in a System Description or Statement of Applicability.
• Gap analysis scaffolding. Comparing a vendor's current documentation set against the full list of Trust Services Criteria or ISO 27001 Annex A controls and flagging which ones lack any written policy at all. This is a mechanical comparison task that AI does quickly and that a human would otherwise spend hours doing manually.
• Cross-framework mapping. Translating existing HIPAA Security Rule documentation into SOC 2 or ISO 27001 language, which is common for EHR vendors and overlay platforms that already maintain a HIPAA risk analysis and want to extend it into a formal audit framework.
• Readability and consistency editing. Cleaning up inconsistent terminology across a large policy set, which matters because auditors flag internal contradictions (for example, a data retention policy that says 90 days in one section and 7 years in another).

Each of these tasks produces a document that a human compliance owner then reviews, edits, and approves. The AI output is a draft, not a deliverable.

Where does AI drafting break down in a healthcare compliance context?

AI drafting breaks down anywhere the document needs to reflect a specific, current, and verifiable fact about the vendor's actual environment rather than a generic best practice.

A few concrete failure modes show up repeatedly:

Generic control language that does not match the actual system. An AI model trained on common SOC 2 templates will often draft a control description that sounds correct but describes a generic cloud architecture rather than the vendor's specific configuration. For an EHR vendor running a multi-tenant system with PHI segregation requirements, a generic access control write-up can miss the specific tenant isolation logic an auditor will ask about directly.

Stale or invented detail. Language models can produce confident-sounding specifics, like a named encryption standard or a retention period, that do not match what the vendor actually implemented. In a healthcare compliance package this is a serious problem, because a mismatch between the written policy and the operational reality is exactly what auditors and, later, breach investigators look for.

Risk acceptance and exception handling. Every real environment has gaps: a legacy vendor without a current SOC 2 report, a control that is partially implemented, a finding from a prior audit that has not been fully remediated. Deciding how to describe those gaps, whether to accept the risk, remediate before the audit, or disclose an exception in the final report, is a judgment call with legal and business consequences. That decision belongs to a named accountable person, not a drafting tool.

Auditor-facing evidence packages. SOC 2 Type II and ISO 27001 surveillance audits require a sampling of evidence across the review period, often 6 to 12 months. That evidence has to be pulled, organized, and validated by someone with system access and operational knowledge. AI can help build the evidence request tracker, but it cannot pull the access logs from the identity provider or confirm that a terminated employee's account was disabled within policy.

What compliance evidence still requires human sign-off when using AI drafting tools?

Any evidence artifact that an auditor will test directly, meaning the raw system logs, control test results, and management assertions, requires human generation and human sign-off before it enters the audit package.

This is the practical line IT admins and compliance leads should hold, regardless of how much AI assistance is used elsewhere in the process:

• Access control evidence. User access reviews, provisioning and deprovisioning logs, and privileged access audit trails must come from the actual identity and access management system and be reviewed by the security or IT lead who owns that system.
• Change management evidence. Deployment logs, code review records, and change approval tickets need to be pulled from the source system (git history, CI/CD pipeline, ticketing platform) and verified against the change management policy, not summarized from memory or drafted generically.
• Vendor and subprocessor risk assessments. For an EHR or overlay vendor that relies on cloud infrastructure, clearinghouses, or third-party AI models, the risk assessment of each subprocessor needs a human reviewer who actually evaluated that vendor's own security posture, BAA terms, and data handling practices.
• Incident and breach records. Any security incident, near miss, or breach notification during the audit period must be documented factually and reviewed by legal or compliance leadership, since these records often have downstream reporting obligations under HIPAA or state breach notification law.
• Penetration test and vulnerability scan results. These come from a third-party security firm or internal security tooling and must be reviewed by a security engineer, including remediation status for any findings.
• The management assertion letter. SOC 2 requires a signed management assertion about the accuracy of the system description and the design of controls. This is a legal attestation and must be signed by an accountable executive, never generated or approved by an AI tool.
• ISO 27001 risk treatment decisions. The risk assessment methodology can be AI-assisted in its drafting, but the actual risk scoring, treatment plan, and acceptance of residual risk require sign-off from the person accountable for the information security management system, typically a CISO or equivalent role.

The common thread: anything that becomes a factual claim in front of an auditor, or that creates legal exposure if wrong, needs a named human owner. AI can prepare the draft and organize the supporting material, but it cannot carry accountability for the claim.

How should IT admins evaluate an EHR vendor's SOC 2 or ISO 27001 status?

An IT admin should evaluate a vendor's compliance status by reading the actual report and exception list, not by relying on a vendor's claim of being "SOC 2 compliant" or "ISO certified."

A few things to check specifically:

Report type and period. SOC 2 Type I only attests that controls are designed appropriately at a single point in time. SOC 2 Type II attests that controls operated effectively over a review period, typically 6 to 12 months. Type II is the stronger signal for an EHR vendor handling PHI on an ongoing basis. Ask for the audit period dates directly, not just a badge or logo.

Scope of the report. Confirm which Trust Services Criteria are covered. Security is the baseline criterion and is almost always included. Availability, confidentiality, processing integrity, and privacy are additional and not automatically covered. An EHR vendor handling PHI should ideally include confidentiality and availability at minimum.

Exceptions and qualified opinions. Read the auditor's opinion section and the exceptions list. A report with a few disclosed and remediated exceptions is often more trustworthy than a report with zero exceptions, since a real audit over a real operating environment tends to surface at least minor findings. A completely clean report with no exceptions across a full year can be worth a follow-up question about audit rigor.

Subprocessor coverage. For overlay platforms and EHR vendors built on top of cloud infrastructure or third-party AI services, confirm whether the vendor's own SOC 2 report covers those subprocessors by reference (a "carve-out" or "inclusive" method) or whether the vendor separately maintains its own subprocessor risk assessments.

Currency. SOC 2 reports are point-in-time snapshots covering a past period. Ask when the next audit cycle completes and whether the vendor maintains continuous compliance monitoring between formal audits, since a 14-month-old report tells you less about current posture than a recent one.

ISO 27001 certification body. For ISO 27001, confirm the certification was issued by an accredited certification body and check the certificate's scope statement, since ISO certifications can be scoped narrowly (for example, covering only a specific product line or data center) rather than the entire organization.

What does a realistic AI-assisted SOC 2 workflow look like for an EHR or overlay vendor?

A realistic workflow uses AI to compress the drafting and gap-analysis phase while keeping evidence collection, testing, and sign-off entirely in human hands, usually run by a compliance lead working with an outside auditor or virtual CISO.

A workable sequence looks roughly like this:

1. Readiness assessment. A human compliance lead, sometimes with AI assistance to accelerate the comparison, maps existing documentation against the target framework and produces a gap list.
2. AI-assisted drafting. For each gap, an AI tool drafts a first-pass policy or procedure. A compliance analyst edits each draft against the vendor's real architecture, data flows, and operational practices.
3. Evidence collection. IT and engineering teams pull real evidence, access logs, change tickets, backup test results, from production systems. This step cannot be shortcut by AI because the evidence has to be real.
4. Internal control testing. Before the formal audit, the compliance team or an outside readiness consultant tests a sample of controls the way an auditor will, confirming that the written policy matches what actually happens operationally.
5. Auditor engagement. An accredited CPA firm (for SOC 2) or accredited certification body (for ISO 27001) conducts the formal audit, reviews evidence, and issues the report or certificate. AI has no role in this stage; the auditor's independence and judgment are the entire point of the exercise.
6. Continuous monitoring. Between audit cycles, many vendors use compliance automation platforms to continuously check control status. These platforms are not the same as AI drafting tools, though some now include AI-assisted evidence summarization, and they still require a human to review flagged control failures.

For an EHR or overlay vendor, the honest framing to give customers and IT admins is that AI shortens the drafting timeline, not the audit timeline. A vendor that claims AI let them skip evidence collection or auditor review should be treated as a red flag, not a selling point.

Frequently Asked Questions

Does using AI to draft compliance documents disqualify a SOC 2 or ISO 27001 audit?

No. Auditors generally do not care how a policy document was drafted, whether by a human analyst, a consultant, or an AI tool. What they care about is whether the content accurately describes the vendor's actual controls and whether the evidence supports it. AI-assisted drafting is not disclosed or restricted as a category in AICPA or ISO audit standards, but the final documents still need human review for accuracy.

Can an AI tool generate a SOC 2 report itself?

No. A SOC 2 report is an independent auditor's opinion issued by a licensed CPA firm after testing controls and reviewing evidence. No software tool, AI-based or otherwise, can issue this opinion. Vendors that claim an AI-generated report should be treated with significant skepticism.

How long does SOC 2 or ISO 27001 preparation typically take for a health tech vendor?

Timelines vary widely by organization size and existing maturity, but a SOC 2 Type II typically requires establishing controls for a minimum 3 to 6 month observation period before the audit can even begin, on top of however long the drafting and remediation phase takes. AI-assisted drafting can shorten the documentation phase, but it does not shorten the required observation period for Type II evidence.

Should IT admins ask an EHR vendor whether they used AI to prepare their compliance documentation?

It is a reasonable question, but the more important questions are about report type, audit period, exception list, and subprocessor coverage. How the vendor prepared its internal drafts matters less than whether the final audited output is current, scoped appropriately, and reviewed by qualified humans.

Does Thyra use AI in its own compliance program?

Thyra uses AI-assisted tools for internal drafting and gap analysis work, the same way described in this article, while keeping evidence collection, control testing, and sign-off with named accountable owners on the security and compliance team. Specific certification status and audit reports should be requested directly, since compliance postures change and any current blog content should not be treated as a substitute for the actual audit documentation.

About the Author

This article was prepared by the Thyra editorial team in consultation with Thyra's clinical and health IT advisors, including input informed by the operational experience of Dr. Jean Jacques Nya Ngatchou, founder of Thyra. Thyra is an EHR built for endocrinology and primary care, combining a Smart Inbox, Longitudinal AI Scribe, CGM viewer, orders, and protocols in a single clinical workflow. The company works with healthcare IT administrators and clinical leaders to evaluate security and compliance tradeoffs specific to endocrinology and primary care settings.

References

• AICPA, "SOC 2 Trust Services Criteria," American Institute of CPAs, available at aicpa-cima.com
• International Organization for Standardization, "ISO/IEC 27001 Information Security Management," available at iso.org
• U.S. Department of Health and Human Services, "HIPAA Security Rule," available at hhs.gov/hipaa
• HHS Office for Civil Rights, guidance on business associate agreements and subprocessor risk, available at hhs.gov/hipaa

This article is intended for informational purposes for healthcare IT administrators and compliance professionals evaluating vendor security posture. It does not constitute legal or audit advice. Organizations should consult a licensed CPA firm for SOC 2 engagements and an accredited certification body for ISO 27001 certification.