HIPAA, SOC 2, and Enterprise Security

October 2, 2025 •12 min read • Abdus Muwwakkil – Chief Executive Officer

HIPAA, SOC 2, and Enterprise Security

Security Overview

Why Security Matters for Ambient Documentation

Ambient clinical documentation represents one of the most sensitive data processing scenarios in healthcare IT. Unlike traditional EHR interactions where clinicians manually enter discrete data points, ambient documentation systems continuously capture, transcribe, and analyze entire patient-provider conversations. This creates unique security and compliance challenges that require enterprise-grade protection.

Every patient encounter processed through OrbDoc involves Protected Health Information (PHI) in its most raw and comprehensive form—unstructured conversations containing diagnoses, treatments, symptoms, social histories, and intimate personal details. The stakes for securing this data couldn’t be higher. A breach doesn’t just expose discrete data fields; it potentially exposes complete clinical narratives that reveal the full context of a patient’s health journey.

Healthcare organizations evaluating ambient documentation solutions must scrutinize security architectures with the same rigor applied to EHR selection. The technology touches every aspect of patient care, from emergency departments to primary care to specialty practices. CIOs and compliance officers need assurance that their ambient documentation partner implements security controls that match or exceed those of their core clinical systems.

The Regulatory Landscape

Healthcare data security operates under an increasingly complex regulatory framework. HIPAA and HITECH establish the federal baseline for PHI protection, but organizations must also navigate state privacy laws, industry-specific requirements, and international regulations when applicable.

The HIPAA Security Rule mandates administrative, physical, and technical safeguards for electronic PHI (ePHI). The HITECH Act strengthened enforcement, increased penalties for violations, and extended compliance obligations to business associates. Recent guidance from HHS emphasizes that cloud services and AI-powered tools must meet the same rigorous standards as traditional health IT systems.

State laws add additional layers of complexity. California’s CMIA, Texas’s medical privacy laws, and New York’s SHIELD Act impose requirements that often exceed HIPAA’s federal baseline. Multi-state health systems must ensure their technology partners can accommodate the strictest applicable standard across all jurisdictions.

OrbDoc’s Security-First Approach

OrbDoc was architected from day one with healthcare security requirements as foundational design principles, not afterthoughts. Our security model follows defense-in-depth principles, implementing multiple overlapping layers of protection so that no single control failure can compromise patient data.

We operate under the principle of least privilege—every system component, every user, and every integration point receives only the minimum access required to perform its function. Our zero-trust architecture assumes breach and validates every access request regardless of network location. We encrypt everything: data in motion, data at rest, and data in use wherever technically feasible.

Our development follows secure SDLC practices with security reviews at every stage. We conduct regular third-party penetration testing, maintain a responsible vulnerability disclosure program, and participate in healthcare security information sharing forums. When security researchers identify potential issues, we respond rapidly with patches and transparent communication.

Compliance Certifications Roadmap

OrbDoc maintains an aggressive compliance certification schedule aligned with enterprise healthcare requirements:

Current Status:

HIPAA compliance with comprehensive technical, administrative, and physical safeguards
Business Associate Agreement (BAA) execution with all enterprise customers
Annual third-party security assessments
Regular penetration testing and vulnerability assessments

In Progress:

SOC 2 Type II certification (audit completion Q2 2025)
HITRUST CSF certification (target Q3 2025)

Planned:

ISO 27001 certification (target Q4 2025)
FedRAMP Moderate authorization for government healthcare facilities (2026)

We provide detailed attestations and audit reports to enterprise customers under NDA. Our compliance roadmap is driven by customer requirements—if your organization requires specific certifications, we prioritize them in our development schedule.

HIPAA Compliance

Technical Safeguards Implemented

OrbDoc implements comprehensive technical safeguards that meet or exceed HIPAA Security Rule requirements across all five standard categories:

Access Control (§164.312(a)(1)):

Unique user identification for all system users with individual credentials tied to organizational identity providers
Emergency access procedures that maintain audit trails while ensuring clinical continuity during system outages
Automatic logoff after 15 minutes of inactivity on clinical workstations, configurable by organization policy
Encryption and decryption mechanisms using FIPS 140-2 validated cryptographic modules

Audit Controls (§164.312(b)):

Comprehensive logging of all PHI access, modification, and transmission events
Tamper-evident audit logs stored in immutable storage with cryptographic integrity verification
Real-time monitoring and alerting for suspicious access patterns
Audit log retention for seven years, exceeding the six-year HIPAA requirement
Quarterly audit log reviews by our security team with annual comprehensive analysis

Integrity (§164.312(c)(1)):

Cryptographic checksums for all stored PHI to detect unauthorized alteration
Version control and change tracking for all clinical documentation
Digital signatures for finalized clinical notes providing non-repudiation
Real-time integrity monitoring with automated alerts for detected corruption

Person or Entity Authentication (§164.312(d)):

Multi-factor authentication required for all user access
Integration with enterprise SSO systems (SAML 2.0, OAuth 2.0, OpenID Connect)
Certificate-based authentication for system-to-system integration
Biometric authentication support for mobile clinical workflows

Transmission Security (§164.312(e)(1)):

TLS 1.3 encryption for all data in transit with perfect forward secrecy
VPN and private connectivity options for Epic integration and data exchange
Secure file transfer protocols (SFTP, HTTPS) for batch data exchange
Network segmentation isolating PHI processing from other system components

Administrative Safeguards

Our administrative safeguards establish the governance framework for ongoing HIPAA compliance:

Security Management Process (§164.308(a)(1)):

Formal risk analysis conducted annually with continuous risk monitoring
Written security policies and procedures updated based on threat landscape evolution
Sanction policy for workforce members who violate security policies
Information system activity review through quarterly security metrics reporting to leadership

Assigned Security Responsibility (§164.308(a)(2)):

Designated Security Officer with direct executive reporting line
Security team with defined roles covering technical security, compliance, and incident response
Clear escalation procedures for security incidents affecting customer data

Workforce Security (§164.308(a)(3)):

Background checks for all employees with PHI access
Signed confidentiality agreements from all workforce members
Termination procedures ensuring immediate access revocation
Role-based access provisioning tied to job function

Information Access Management (§164.308(a)(4)):

Formal access authorization process requiring manager approval
Periodic access reviews quarterly to verify appropriate access levels
Access modification procedures triggered by role changes
Access termination within one hour of separation

Security Awareness and Training (§164.308(a)(5)):

Security and privacy training for all workforce members upon hire and annually
Specialized training for developers, operations staff, and support teams
Phishing simulation exercises conducted quarterly
HIPAA compliance training with testing and certification

Security Incident Procedures (§164.308(a)(6)):

24/7 security incident response capability
Defined incident response procedures with customer notification protocols
Incident tracking and post-incident analysis to prevent recurrence
Annual tabletop exercises testing incident response procedures

Contingency Plan (§164.308(a)(7)):

Data backup and disaster recovery procedures with RPO of 1 hour and RTO of 4 hours
Disaster recovery plan tested semi-annually
Emergency mode operation procedures maintaining PHI availability during disruptions
Business continuity plan covering extended outages

Physical Safeguards

While OrbDoc operates as a cloud-native service, we implement rigorous physical safeguards through our infrastructure partners and company operations:

Facility Access Controls (§164.310(a)(1)):

SOC 2 compliant data centers with 24/7 physical security
Biometric access controls and video surveillance
Visitor logs and escort requirements for non-authorized personnel
Facility access limited to authorized data center personnel only

Workstation Use and Security (§164.310(b)(c)):

Company-issued devices with full-disk encryption and mobile device management
Prohibited use of personal devices for PHI access
Screen privacy filters and automatic screen locking
Clean desk policies for any printed PHI

Device and Media Controls (§164.310(d)(1)):

Hardware disposal procedures requiring cryptographic erasure or physical destruction
Media reuse procedures preventing PHI recovery
Accountability procedures tracking hardware assignment
Data backup and storage procedures with encryption

Business Associate Agreements

OrbDoc executes comprehensive Business Associate Agreements (BAAs) with all covered entity customers as required by HIPAA. Our BAA:

Establishes permitted uses and disclosures of PHI consistent with customer privacy policies
Requires OrbDoc to implement appropriate safeguards to prevent impermissible uses or disclosures
Requires OrbDoc to report security incidents and breaches to customers
Ensures OrbDoc obtains satisfactory assurances from subcontractors through downstream BAAs
Makes PHI available to customers and individuals for access and amendment requests
Requires OrbDoc to make internal practices and records available for HHS compliance reviews
Establishes data return or destruction obligations upon contract termination

We maintain executed BAAs with all subcontractors who may access PHI, including our cloud infrastructure provider, speech recognition service, and AI model provider. Our vendor management program includes annual review of subcontractor security controls.

Breach Notification Procedures

In the unlikely event of a breach affecting PHI, OrbDoc follows rigorous notification procedures:

Detection and Assessment (0-24 hours):

Security monitoring tools provide real-time alerting for potential breaches
Security team investigates to determine if breach criteria are met
Risk assessment evaluates probability PHI was acquired, accessed, used, or disclosed

Customer Notification (24-48 hours):

Notification to affected covered entity customers without unreasonable delay
Detailed incident report including date of breach, description of PHI involved, steps individuals should take, and OrbDoc’s remediation actions

Individual Notification (60 days maximum):

OrbDoc assists customers in individual notification when required
Notification includes same elements as customer notification in plain language

Media and HHS Notification:

Breaches affecting 500+ individuals require media notification and immediate HHS reporting
Smaller breaches reported to HHS annually

Post-Breach Activities:

Root cause analysis to prevent similar incidents
Implementation of corrective actions
Updates to security controls and procedures as needed

Patient Rights

OrbDoc supports covered entity customers in fulfilling all HIPAA-required patient rights:

Right of Access (§164.524):

API endpoints enabling customers to retrieve patient’s PHI within 30 days
Support for data export in human-readable and machine-readable formats
No charges for standard electronic access

Right to Amend (§164.526):

Functionality for authorized users to append amendments to clinical documentation
Audit trail of original content and amendments
Amendment flags visible to downstream users

Accounting of Disclosures (§164.528):

Comprehensive disclosure logs for all PHI access and transmission
API providing disclosure history for patient access requests
Six-year retention of disclosure records

SOC 2 Type II

What SOC 2 Type II Means

SOC 2 Type II is the gold standard for demonstrating security, availability, and confidentiality controls for service organizations. Developed by the American Institute of CPAs (AICPA), SOC 2 provides a framework for evaluating controls relevant to security, availability, processing integrity, confidentiality, and privacy—the Trust Service Criteria.

Unlike SOC 2 Type I, which evaluates controls at a point in time, Type II examines whether controls operate effectively over a period (typically 12 months). This extended observation period provides assurance that security isn’t just designed properly but functions consistently under real-world operating conditions.

For healthcare organizations, SOC 2 Type II provides independent validation that a vendor’s security claims are backed by audited evidence. The report details specific controls, testing procedures, and any exceptions or deficiencies identified, giving compliance officers transparency into actual security practices rather than marketing claims.

Trust Service Criteria Covered

OrbDoc’s SOC 2 Type II audit scope encompasses four Trust Service Criteria most relevant to healthcare customers:

Security (CC1-CC9):

Logical and physical access controls protecting PHI
System operations including change management, incident response, and monitoring
Mitigation of security risks through vulnerability management and threat detection

Availability (A1):

System availability commitments to customers (99.9% uptime SLA)
Monitoring and incident response to maintain availability
Disaster recovery and business continuity capabilities

Processing Integrity (PI1):

System processing is complete, valid, accurate, timely, and authorized
Quality assurance procedures for clinical documentation accuracy
Data validation and error handling procedures

Confidentiality (C1):

Protection of confidential information (PHI) throughout its lifecycle
Data classification and handling procedures
Secure disposal and deletion procedures

Our audit scope specifically excludes Privacy criteria as HIPAA provides more stringent and healthcare-specific privacy requirements that we address through our compliance program.

Audit Process and Frequency

Our SOC 2 Type II audit follows a rigorous annual cycle:

Readiness Assessment (Month 1-2):

Internal control testing to identify gaps
Remediation of any control deficiencies
Evidence collection procedures established

Audit Period (12 months):

Continuous evidence collection for all in-scope controls
Monthly control testing by internal audit team
Quarterly management review of control effectiveness

Formal Audit (Month 13-14):

Independent CPA firm conducts control testing
Sample-based testing of control operation throughout audit period
Management interviews and evidence review
Site visits and walkthroughs of security procedures

Report Issuance (Month 15):

Final SOC 2 Type II report issued
Management response to any findings
Remediation plans for identified deficiencies

Continuous Improvement:

Post-audit remediation activities
Incorporation of findings into next audit cycle
Updates to control environment based on lessons learned

We engage a Big Four accounting firm as our SOC 2 auditor to ensure the highest standards of independence and rigor. Our audit period aligns with our fiscal year to facilitate consistent reporting to customers.

How to Request SOC 2 Report

SOC 2 reports contain sensitive information about our control environment and cannot be publicly distributed. Enterprise customers and qualified prospects can request our SOC 2 Type II report through the following process:

Submit Request: Contact your OrbDoc account executive or email [email protected] with your SOC 2 report request
Validation: We validate that your organization has a legitimate business need for the report (existing customer, active procurement process, or formal evaluation)
NDA Execution: Both parties execute a mutual non-disclosure agreement covering the SOC 2 report
Secure Delivery: Report delivered via secure portal with access logging and download tracking
Review Support: Security team available to discuss report findings and answer questions

For prospects evaluating OrbDoc, we can provide a redacted executive summary of our SOC 2 report prior to NDA execution to facilitate initial security assessment. The full report is available once commercial discussions progress to serious evaluation.

We encourage customers to review our SOC 2 report annually and to request updates immediately upon renewal. We proactively notify all customers when our new annual report is available.

Data Protection Architecture

End-to-End Encryption

OrbDoc implements end-to-end encryption for patient-provider conversations from the moment audio is captured until it’s securely deleted:

Audio Capture Encryption:

Audio encrypted on mobile device using AES-256-GCM before leaving device memory
Encryption keys generated using hardware-backed keystores on iOS and Android
Encrypted audio transmitted over TLS 1.3 to OrbDoc processing infrastructure
Audio never stored unencrypted at any point in the processing pipeline

Processing Pipeline Encryption:

Encrypted audio streams processed in isolated processing environments
Decryption occurs only in memory within secure enclaves
Intermediate processing artifacts (transcripts, extracted data) encrypted immediately upon generation
Processing nodes communicate over mutually authenticated TLS connections

Storage Encryption:

All PHI encrypted at rest using AES-256 encryption
Unique data encryption keys per customer with key rotation every 90 days
Encrypted backups with separate encryption keys from production data

Data at Rest Encryption

Our data at rest encryption implements multiple layers of protection:

Database Encryption:

Transparent Data Encryption (TDE) for all database instances storing PHI
Column-level encryption for particularly sensitive fields (SSN, financial information)
Encrypted database backups with separate encryption key hierarchy

Object Storage Encryption:

Server-side encryption for all objects (audio files, documents, images)
Customer-managed encryption keys (CMEK) option for enterprise customers requiring key control
Versioning with encryption applied to all object versions

File System Encryption:

Full-disk encryption for all servers processing or storing PHI
Encrypted temporary file systems with automatic secure deletion
Swap and memory encryption where technically feasible

Key Management:

Hardware Security Modules (HSMs) for master key protection
Multi-party key ceremonies requiring multiple authorized individuals
Key usage logging with alerting for anomalous key access patterns

Data in Transit Encryption

Every network communication involving PHI uses strong encryption:

External Communications:

TLS 1.3 for all client-to-server communication with deprecated protocol blocking
Perfect forward secrecy ensuring past session security even if keys are compromised
Certificate pinning for mobile applications preventing man-in-the-middle attacks
HSTS headers enforcing HTTPS connections

Internal Communications:

Mutual TLS (mTLS) for all service-to-service communication
Private network connectivity for Epic integration avoiding public internet
VPN connections for administrative access
Encrypted replication channels for database synchronization

Epic Integration:

HL7 over secure transport (MLLP over TLS)
FHIR API access over HTTPS with OAuth 2.0 authentication
Direct VPN or private connectivity options for on-premise Epic installations
Message-level encryption for sensitive payloads beyond transport encryption

Key Management

Our cryptographic key management follows NIST SP 800-57 guidelines:

Key Hierarchy:

Master keys stored in FIPS 140-2 Level 3 certified HSMs
Data encryption keys (DEKs) encrypted by key encryption keys (KEKs)
DEKs rotated every 90 days with automatic re-encryption
KEKs rotated annually with HSM-based key ceremonies

Key Access Control:

Keys accessible only to authorized encryption services
No human access to production encryption keys
Separation of duties requiring multiple approvals for key operations
Detailed audit logging of all key access and usage

Key Lifecycle:

Secure key generation using HSM-based random number generators
Automated key distribution to authorized services
Key rotation with backward compatibility for encrypted data access
Secure key destruction following NIST guidelines after retention period

Backup and Recovery:

Encrypted key backups stored in geographically separate HSMs
Key recovery procedures requiring multiple authorized individuals
Regular testing of key recovery procedures
Documented key escrow for customer-managed keys

Data Retention Policies

OrbDoc implements configurable data retention aligned with healthcare record retention requirements:

Default Retention:

Clinical documentation retained for 10 years from date of service (exceeding most state requirements)
Audio recordings retained for 30 days then automatically deleted
Audit logs retained for 7 years
Billing-related data retained for 10 years

Configurable Retention:

Enterprise customers can configure extended retention periods
State-specific retention schedules (e.g., 25 years for minors in some states)
Legal hold capability suspending automated deletion
Retention policies enforced at data level with cryptographic verification

Retention Enforcement:

Automated retention workflows with human oversight
Immutable retention flags preventing premature deletion
Compliance dashboards showing retention status
Alerts for data approaching retention expiration

Data Deletion Procedures

When retention periods expire or customers request deletion, we implement secure deletion:

Standard Deletion:

Cryptographic deletion by destroying encryption keys rendering data unrecoverable
Physical deletion of data from primary storage within 30 days
Deletion from backups during next backup rotation cycle (maximum 90 days)
Deletion certificates available upon request

Immediate Deletion:

Available for sensitive scenarios requiring urgent deletion
Physical deletion from all storage systems within 7 days
Manual verification of deletion completion
Attestation of deletion provided to customer

Media Sanitization:

Decommissioned storage media cryptographically erased (NIST SP 800-88)
Physical destruction of media storing particularly sensitive data
Certificate of destruction from certified e-waste recycler
Chain of custody documentation for disposed media

Access Controls

Role-Based Access Control (RBAC)

OrbDoc implements granular RBAC aligned with clinical workflows:

Standard Roles:

Physician: Full access to own patients, read-only to colleagues’ patients when covering
Advanced Practice Provider: Similar to physician with scope of practice restrictions
Medical Assistant: Documentation preparation, no signature authority
RN/LPN: Documentation review, patient education materials
Administrative Staff: Scheduling, billing-related documentation, no clinical access
Compliance Officer: Audit log access, no patient identifiable information
IT Administrator: System configuration, no PHI access unless required for support

Custom Roles:

Enterprise customers can define custom roles matching organizational structure
Granular permissions at feature and data field level
Role templates for common specialties and use cases
Role inheritance allowing organizational role hierarchies

Dynamic Access:

Break-glass access for emergency situations with automatic audit alerts
Temporary access grants for covering physicians with automatic expiration
Context-aware access based on patient assignment and encounter status

Multi-Factor Authentication (MFA)

MFA is required for all user access with multiple authentication options:

Supported MFA Methods:

Authenticator apps (Google Authenticator, Microsoft Authenticator, Authy)
SMS-based one-time passwords (OTP)
Hardware security keys (YubiKey, Google Titan)
Push notifications to registered mobile devices
Biometric authentication on supported mobile platforms

MFA Policies:

MFA required for initial authentication and re-authentication after timeout
Step-up authentication for sensitive operations (data export, configuration changes)
Remember device option for trusted devices (configurable by organization)
MFA bypass not permitted even for administrators

MFA Recovery:

Backup codes provided during MFA enrollment
Help desk verification procedures for locked out users
Self-service MFA reset with identity verification
Audit trail of all MFA events

Single Sign-On (SSO) Integration

Enterprise customers can integrate OrbDoc with their identity providers:

Supported Protocols:

SAML 2.0 (primary recommendation)
OAuth 2.0 with OpenID Connect
Active Directory Federation Services (ADFS)
Azure AD, Okta, OneLogin, Ping Identity

SSO Features:

Just-in-time (JIT) user provisioning based on SAML attributes
Group-based role assignment from identity provider
Automatic deprovisioning when removed from identity provider
Session management tied to identity provider session lifetime

SSO Configuration:

Metadata-based configuration for easy setup
SAML attribute mapping for custom user fields
Conditional access policy support (IP restrictions, device compliance)
Multiple identity provider support for complex organizations

Session Management

Our session management balances security and clinical workflow usability:

Session Policies:

15-minute idle timeout for web sessions (configurable per organization)
8-hour maximum session lifetime requiring re-authentication
Mobile app sessions persist but require biometric re-authentication
Concurrent session limits preventing credential sharing

Session Security:

Secure session tokens with cryptographic signing
Session token rotation on privilege escalation
Secure cookie attributes (HttpOnly, Secure, SameSite)
Session invalidation on password change or role modification

Session Monitoring:

Active session visibility for users showing all login locations
Ability to remotely terminate suspicious sessions
Alerts for concurrent logins from different geographic locations
Session anomaly detection based on normal usage patterns

Audit Logging

Comprehensive audit logging provides accountability and security monitoring:

Logged Events:

All PHI access (view, create, modify, delete)
Authentication events (login, logout, failed attempts)
Configuration changes (role modifications, integration settings)
Data exports and bulk operations
Administrative actions (user provisioning, access grants)

Log Contents:

User identity and role
Timestamp (UTC with millisecond precision)
Action performed and result (success/failure)
Patient and encounter identifiers
Source IP address and geographic location
User agent and device information

Log Protection:

Append-only logging preventing modification
Cryptographic integrity verification
Separation of logging infrastructure from application systems
Real-time log forwarding to customer SIEM systems

Log Retention and Access:

7-year retention exceeding HIPAA requirements
Search and export capabilities for compliance officers
Pre-built reports for common audit scenarios
API access for integration with enterprise security tools

Network Security

Zero-Trust Architecture

OrbDoc implements zero-trust principles assuming no implicit trust:

Identity Verification:

Every access request authenticated regardless of network location
Continuous authentication using behavioral analytics
Device health verification before granting access
Least-privilege access granted for minimum duration necessary

Micro-Segmentation:

Network segmentation isolating PHI processing systems
Application-level segmentation limiting lateral movement
Database access only from authorized application servers
No direct database access from internet-facing systems

Encryption Everywhere:

All network traffic encrypted in transit
Service-to-service authentication using mutual TLS
No cleartext protocols permitted in production environments

Firewall and Intrusion Detection

Multiple layers of network security protect against threats:

Perimeter Defense:

Web Application Firewall (WAF) protecting public-facing services
DDoS mitigation at network edge
IP allowlisting available for enterprise customers
Geographic blocking of non-healthcare relevant regions

Intrusion Detection and Prevention:

Network intrusion detection systems (NIDS) monitoring traffic patterns
Host-based intrusion detection (HIDS) on all servers
Behavioral analysis detecting anomalous network activity
Automated blocking of detected threats with SOC team review

Security Monitoring:

24/7 Security Operations Center (SOC) monitoring
SIEM aggregation of security events
Real-time alerting for critical security events
Weekly security posture reporting to leadership

DDoS Protection

Distributed denial of service protection ensures availability:

Layer 3/4 Protection:

Volumetric attack mitigation at network edge
Protocol attack detection and blocking
Automatic traffic rerouting during attacks
1 Tbps+ mitigation capacity

Layer 7 Protection:

Application-layer DDoS detection using rate limiting
Bot detection and challenge mechanisms
Anomalous request pattern detection
Origin cloaking preventing direct IP targeting

Availability Commitment:

99.9% uptime SLA including during DDoS attacks
Incident response procedures for sustained attacks
Communication protocols during service disruptions
Post-incident analysis and hardening

Penetration Testing Schedule

Regular penetration testing validates security controls:

Annual External Penetration Testing:

Third-party penetration testing firm engaged annually
Black-box testing simulating external attacker perspective
Scope includes web applications, APIs, and network infrastructure
Remediation of high and critical findings within 30 days

Quarterly Internal Testing:

Internal security team conducts quarterly vulnerability assessments
Automated scanning supplemented with manual testing
Testing of new features before production release
Continuous security testing in development pipelines

Bug Bounty Program:

Responsible disclosure program for security researchers
Defined scope and rules of engagement
Financial rewards for validated vulnerabilities
Coordinated disclosure timeline protecting customers

Testing Deliverables:

Executive summary of findings and risk ratings
Detailed technical findings with reproduction steps
Remediation recommendations and timelines
Retest results confirming fix effectiveness

Case Study: Enterprise Security Evaluation

Organization: Regional health system with 4 hospitals, 50+ clinics, 800 physicians

Challenge: Needed ambient documentation solution meeting enterprise security requirements for deployment across entire organization

Security Requirements:

HIPAA compliance with BAA
SOC 2 Type II or equivalent third-party audit
Integration with enterprise SSO (Okta)
On-premise Epic integration without internet exposure
Compliance with state medical privacy law exceeding HIPAA
Security controls matching internal EHR security standards

OrbDoc Solution:

Executed comprehensive BAA covering all physicians and care sites
Provided SOC 2 Type II report and detailed security documentation
Configured SAML 2.0 integration with Okta including custom attribute mapping
Deployed Epic integration via dedicated VPN avoiding public internet
Implemented extended audio retention supporting state law requirements
Aligned security controls with customer’s EHR security baseline

Security Evaluation Process:

Initial security questionnaire completed (200+ questions)
Security architecture review session with customer CISO
SOC 2 report review and gap analysis
Penetration test results review
On-site security audit of OrbDoc procedures
Quarterly ongoing security reviews

Outcome:

Approved for enterprise-wide deployment following 90-day security evaluation
Deployed to 200 physicians in initial rollout
Zero security incidents in 18 months of operation
Successfully passed customer’s annual vendor security audit
Expanded deployment to full physician population

Key Success Factors:

Transparent security documentation and audit access
Willingness to accommodate customer-specific security requirements
Demonstrated track record with other healthcare organizations
Responsive security team addressing evaluation questions
Alignment with customer’s existing security frameworks

Compliance Checklist for Vendor Evaluation

What to Ask Vendors

When evaluating ambient documentation vendors, ask these critical questions:

Compliance Certifications:

Do you have SOC 2 Type II certification? When does it expire?
Are you HIPAA compliant with documented policies and procedures?
Will you execute a Business Associate Agreement?
Do you have HITRUST certification or plans to achieve it?
What other compliance certifications do you maintain?

Data Protection:

How is PHI encrypted in transit and at rest?
What encryption standards and key lengths do you use?
Who has access to encryption keys?
How do you handle encryption key rotation and management?
Can we use customer-managed encryption keys?

Access Controls:

What authentication methods do you support?
Is multi-factor authentication required or optional?
Do you support SSO integration? Which protocols?
How do you implement role-based access control?
What audit logging capabilities do you provide?

Infrastructure Security:

Where is your infrastructure hosted? Which regions?
Do you support private connectivity (VPN, AWS PrivateLink)?
What DDoS protection do you have in place?
How do you monitor for security incidents?
What is your incident response process?

Data Governance:

What are your data retention policies?
How do you handle data deletion requests?
Do you support legal hold capabilities?
Can we configure custom retention schedules?
How do you handle subcontractors who access PHI?

Operational Security:

How often do you conduct penetration testing?
Do you have a bug bounty or vulnerability disclosure program?
What security training do your employees receive?
How do you manage security vulnerabilities and patches?
What is your change management process?

Business Continuity:

What are your availability SLAs and uptime history?
How do you handle disaster recovery?
What is your RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?
How do you test your disaster recovery procedures?
What happens to our data if your company is acquired or ceases operations?

Security Evaluation Framework

Structure your evaluation using this framework:

Phase 1: Initial Screening (1-2 weeks)

Review vendor security documentation
Validate compliance certifications
Request SOC 2 report and penetration test results
Evaluate alignment with your security policies

Phase 2: Detailed Technical Review (2-4 weeks)

Security architecture review session
Network integration planning and security assessment
Review of audit logging and monitoring capabilities
Evaluate access control implementation
Assessment of data protection mechanisms

Phase 3: Risk Assessment (1-2 weeks)

Gap analysis against your security requirements
Risk rating of identified gaps or exceptions
Vendor remediation plan for critical gaps
Residual risk acceptance decision

Phase 4: Legal and Contractual (2-3 weeks)

BAA negotiation and execution
SLA and security commitment documentation
Incident response and notification procedures
Data ownership and portability provisions

Phase 5: Ongoing Monitoring (Continuous)

Quarterly security reviews
Annual SOC 2 report updates
Security incident notifications
Compliance attestation renewals

Due Diligence Questions

For Your Legal Team:

Does the BAA adequately protect our organization?
Are data ownership rights clearly established?
What are the vendor’s liability limitations for security incidents?
Are there adequate termination and data return provisions?
How does the contract address regulatory changes?

For Your Compliance Team:

Does the vendor meet all applicable regulatory requirements?
Are there any compliance gaps requiring risk acceptance?
What ongoing compliance attestations will we receive?
How will we monitor ongoing vendor compliance?
What audit rights do we have?

For Your IT Security Team:

Does the vendor’s security architecture meet our standards?
Are there adequate technical controls for PHI protection?
Can we integrate with our existing security tools (SIEM, SSO)?
What security metrics and reporting will we receive?
How will security incidents be communicated and managed?

For Your Clinical Leadership:

Will clinical workflows be disrupted during security incidents?
How quickly can physician access be restored if systems fail?
Are there adequate safeguards preventing documentation errors?
Can we maintain patient safety during vendor security maintenance?
What is the vendor’s track record for security and availability?

For Your IT Operations Team:

How complex is the integration with our existing systems?
What ongoing operational security responsibilities will we have?
How are security patches and updates deployed?
What monitoring and alerting will we need to implement?
What are the disaster recovery and business continuity implications?

Conclusion

Security and compliance are not optional features for healthcare technology—they are foundational requirements that protect patients, providers, and healthcare organizations. OrbDoc’s security architecture reflects our commitment to earning and maintaining the trust of the healthcare community.

Our HIPAA compliance, SOC 2 certification roadmap, comprehensive data protection, and rigorous access controls provide the enterprise-grade security that CIOs and compliance officers require. We understand that choosing an ambient documentation vendor means entrusting that partner with your organization’s most sensitive data and critical clinical workflows.

We encourage thorough security evaluation and welcome detailed scrutiny of our security controls. Our team is available to discuss your specific security requirements, provide detailed documentation, and support your evaluation process.

Ready to evaluate OrbDoc’s security? Contact our security team at [email protected] to request our SOC 2 report, schedule a security architecture review, or discuss your organization’s specific compliance requirements.

For technical questions about Epic integration security, see our Epic Integration Technical Guide. For information about enterprise deployment options, visit our Enterprise Solutions page.