Skip to main content
HIPAA | SOC 2 | PCI DSS | ISO/IEC 42001

Security Policy

CoOrdio Healthcare Platform (by OpenBots, Inc.)

Version 1.0 | Last Updated: October 21, 2026 | Owner: Information Security Officer

OpenBots, Inc. ("OpenBots," "we," "us," or "our") provides the CoOrdio platform, an AI-first healthcare revenue cycle management platform and related services, to healthcare providers and organizations in the United States. Our customers trust us with protected health information (PHI), financial data, and business-critical workflows. This Security Policy describes the administrative, technical, and physical safeguards we maintain to protect that information and the integrity and availability of our services.

1. Purpose and Scope

1.1 Purpose: This policy sets out the principles and controls OpenBots uses to protect the confidentiality, integrity, and availability of customer data, including PHI, and of the systems that process it.

1.2 Scope: This policy applies to the CoOrdio platform, including its AI agents, automation, revenue cycle management (RCM) billing services, APIs, and supporting infrastructure, and to all OpenBots employees, contractors, and subprocessors who access customer data or production systems.

1.3 Relationship to Other Terms: This policy supplements, and does not replace, our Privacy Policy, our Business Associate Agreement (BAA), and any customer agreement. Where a signed agreement sets a more specific obligation, that agreement controls.

2. Compliance Framework

Our security program is designed around recognized regulatory requirements and industry frameworks:

2.1 HIPAA: We operate as a Business Associate under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), as amended by the HITECH Act. We maintain administrative, physical, and technical safeguards consistent with the HIPAA Security Rule (45 CFR Part 164, Subpart C), follow the HIPAA Privacy Rule and Breach Notification Rule as they apply to Business Associates, and sign a BAA with each covered entity customer before PHI is processed.

2.2 SOC 2: OpenBots is SOC 2 compliant. Our controls, designed around the AICPA Trust Services Criteria for Security, Availability, and Confidentiality, have been examined and attested by an independent third-party auditor, and we undergo ongoing SOC 2 audits to maintain that attestation. Customers and prospective customers may request our most recent SOC 2 report under a non-disclosure agreement.

2.3 ISO/IEC 42001 (AI Management System): We align our AI governance and AI security practices with ISO/IEC 42001, the international standard for Artificial Intelligence Management Systems. The AI-specific controls described in Section 9 reflect this program.

2.4 PCI DSS: OpenBots is compliant with the Payment Card Industry Data Security Standard (PCI DSS). Systems and processes that store, process, or transmit payment cardholder data, such as patient payments collected through our revenue cycle services, are maintained in accordance with PCI DSS requirements and are assessed annually. Section 5.7 describes how we protect cardholder data.

2.5 Other Requirements: We also design our controls with reference to the NIST Cybersecurity Framework, the NIST AI Risk Management Framework, applicable state privacy and data breach laws, and the security requirements of healthcare payers and clearinghouses with which the platform connects.

3. Security Governance

3.1 Security and Privacy Officers: OpenBots has designated a Security Officer responsible for the development, implementation, and enforcement of our security program, and a Privacy Officer responsible for privacy and HIPAA Privacy Rule compliance, as required by HIPAA.

3.2 Policies and Procedures: We maintain written information security policies and procedures that are approved by management, communicated to personnel, and reviewed at least annually or when significant changes to our business, technology, or legal obligations occur.

3.3 Accountability: Leadership reviews the status of the security program, risk assessments, audit findings, and incidents on a regular basis. Violations of security policies may result in disciplinary action up to and including termination of employment or contract.

4. Risk Management

4.1 Risk Assessments: We perform a security risk analysis at least annually and when material changes occur, identifying threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI and other customer data, as required by the HIPAA Security Rule.

4.2 Risk Treatment: Identified risks are documented in a risk register, assigned an owner, and remediated, mitigated, transferred, or formally accepted by management based on their likelihood and impact.

4.3 AI Risk and Impact Assessments: Before an AI capability is deployed to production, and when it changes materially, we assess its risks and potential impacts on customers and patients, including accuracy, bias, privacy, security, and misuse, consistent with ISO/IEC 42001.

5. Data Protection

5.1 Data Classification: We classify data by sensitivity. PHI, payer credentials, financial data, and authentication secrets are treated as the most sensitive classes and receive the strongest controls.

5.2 Encryption in Transit: Customer data transmitted over public networks is encrypted using TLS 1.2 or higher. Insecure protocols are disabled on public endpoints.

5.3 Encryption at Rest: Customer data, including databases, file storage, and backups, is encrypted at rest using AES-256 or an equivalent industry-standard algorithm.

5.4 Key and Secret Management: Encryption keys and application secrets are stored in managed key and secret management services, access to them is restricted and logged, and they are rotated according to defined schedules or upon suspected compromise.

5.5 Minimum Necessary: We limit the use and disclosure of PHI to the minimum necessary to provide the services, and we do not sell customer data or PHI.

5.6 Data Segregation: Customer data is logically segregated so that one customer cannot access another customer's data.

5.7 Payment Card Data: Cardholder data is limited to what is needed to process payments, is encrypted in transit and at rest, and is kept within a segmented environment with restricted access. Full card numbers are masked when displayed, sensitive authentication data (such as card verification codes) is not stored after authorization, and we use PCI DSS validated payment processors and tokenization where possible so that card data is not retained in the CoOrdio platform.

6. Access Control

6.1 Least Privilege: Access to customer data and production systems is granted on a least-privilege, role-based basis and only to personnel who need it to perform their job duties.

6.2 Authentication: Each user has a unique account. Multi-factor authentication is required for access to production systems, administrative consoles, source code, and corporate email. Shared accounts are not permitted for access to customer data.

6.3 Access Reviews: Access rights to systems that store or process customer data are reviewed at least quarterly, and access is removed promptly when personnel change roles or leave the company.

6.4 Customer Access Controls: The CoOrdio platform supports role-based permissions and session timeouts so that customers can control which of their users can view or act on PHI.

7. Infrastructure and Network Security

7.1 Hosting: The CoOrdio platform is hosted in the United States with cloud infrastructure providers that maintain their own SOC 2 and ISO/IEC 27001 attestations and sign BAAs with OpenBots.

7.2 Network Protection: Production environments are protected by firewalls, network segmentation, security groups, and web application protections. Production systems are separated from development and test environments, and real PHI is not used in non-production environments.

7.3 Hardening and Patching: Systems are configured from hardened baselines. Security patches are applied on a risk-based schedule, with critical vulnerabilities prioritized for prompt remediation.

7.4 Endpoint Security: Company-managed devices used to access customer data are protected with full-disk encryption, screen locks, endpoint protection software, and automatic updates.

8. Secure Software Development

8.1 Secure Development Lifecycle: Security is considered throughout design, development, testing, and deployment. Engineers receive secure coding guidance, and code changes are peer reviewed before they are merged.

8.2 Testing: We use automated static analysis and dependency scanning, and we conduct independent penetration testing of the platform at least annually. Findings are tracked to remediation.

8.3 Change Management: Changes to production systems follow a documented change management process that includes review, approval, testing, and the ability to roll back.

9. AI Security and Responsible AI

AI agents are central to the CoOrdio platform. We govern them through an AI management program aligned with ISO/IEC 42001 and the NIST AI Risk Management Framework, which includes the following controls:

9.1 AI Governance: We maintain an AI policy, an inventory of AI systems and models in use, defined roles and responsibilities for AI oversight, and documented objectives for the safe and responsible use of AI.

9.2 Use of Customer Data: Customer data and PHI are used to deliver the services to that customer. We do not use PHI to train general-purpose AI models, and we do not permit third-party AI providers to retain customer data or use it to train their models.

9.3 Third-Party AI Models: Third-party AI model providers are evaluated under our vendor management program, must agree to appropriate contractual protections (including a BAA where PHI is involved), and are accessed through secured, access-controlled connections.

9.4 AI-Specific Threats: We design and test our AI systems against AI-specific threats, including:

  • prompt injection and manipulation of AI agents through untrusted inputs such as documents, faxes, and payer responses;
  • leakage of sensitive data through model inputs, outputs, or logs;
  • unauthorized actions by AI agents, which we limit by restricting each agent to the minimum tools, systems, and permissions it needs;
  • tampering with models, prompts, configurations, or the data that AI systems rely on; and
  • abuse, denial of service, or excessive use of AI capabilities.

9.5 Human Oversight: AI outputs that affect claims, eligibility, benefits, or patient financial responsibility are subject to defined validation rules, confidence thresholds, and human review where appropriate. AI agents support, and do not replace, the professional judgment of our customers.

9.6 Monitoring and Quality: We monitor AI systems in production for accuracy, drift, errors, and unexpected behavior, keep audit logs of AI agent actions, and evaluate models before and after changes.

9.7 Transparency: We tell customers where AI is used in the services, the intended purpose of each AI capability, and its known limitations.

10. Vendor and Subprocessor Management

10.1 Due Diligence: Vendors and subprocessors that access customer data are assessed for security and privacy risk before engagement and periodically afterward.

10.2 Contractual Safeguards: Subprocessors that create, receive, maintain, or transmit PHI on our behalf must sign a subcontractor BAA and agree to protect that information with safeguards at least as protective as those in this policy.

11. Personnel Security

11.1 Background Checks: Where permitted by law, employees and contractors with access to customer data undergo background checks before access is granted.

11.2 Confidentiality: All personnel sign confidentiality agreements and acknowledge our security policies.

11.3 Training: Personnel complete security, HIPAA, and responsible AI training when they join and at least annually thereafter, supplemented by phishing awareness exercises.

12. Logging, Monitoring, and Vulnerability Management

12.1 Audit Logging: We log access to and activity in systems that contain customer data, including access to PHI and administrative actions. Logs are protected from tampering and retained according to our retention schedule.

12.2 Monitoring and Alerting: Security events are monitored and alerts are routed to responsible personnel for investigation.

12.3 Vulnerability Management: Infrastructure, applications, and dependencies are scanned for vulnerabilities on a regular basis, and findings are remediated according to severity.

13. Incident Response and Breach Notification

13.1 Incident Response Plan: We maintain a documented incident response plan that defines how security incidents are identified, contained, investigated, remediated, and reviewed. The plan is tested at least annually.

13.2 Customer Notification: We notify affected customers of security incidents and breaches of unsecured PHI without unreasonable delay and within the timeframes required by HIPAA, applicable law, and our BAA, and we cooperate with customers in meeting their own notification obligations.

13.3 Post-Incident Review: After an incident, we perform a root cause analysis and implement corrective actions to reduce the likelihood of recurrence.

14. Business Continuity and Disaster Recovery

14.1 Backups: Customer data is backed up regularly, backups are encrypted and stored redundantly, and restoration is tested periodically.

14.2 Resilience: The platform is designed for high availability, and we maintain business continuity and disaster recovery plans, including a HIPAA contingency plan, that are reviewed and tested at least annually.

15. Data Retention and Disposal

15.1 Retention: Customer data is retained only as long as needed to provide the services, meet contractual commitments, or satisfy legal requirements.

15.2 Return and Disposal: At the end of a customer relationship, customer data, including PHI, is returned or securely destroyed in accordance with the customer agreement and BAA. Media and devices are sanitized or destroyed using industry-standard methods before disposal or reuse.

16. Physical Security

16.1 Data Centers: Production systems run in data centers operated by our cloud infrastructure providers, which maintain physical access controls, surveillance, and environmental protections.

16.2 Offices and Remote Work: OpenBots does not store PHI on paper or on local office systems. Personnel working remotely must follow our workstation security and clean desk requirements.

17. Shared Responsibility

17.1 Customer Responsibilities: Security is a shared responsibility. Customers are responsible for managing their users and permissions in the platform, protecting their own credentials and devices, sending only the data needed for the services, and promptly reporting suspected unauthorized access to their accounts.

18. Reporting a Security Concern

18.1 Contact: To report a suspected vulnerability, security incident, or concern, or to request security documentation such as our SOC 2 report, contact our security team at security@coordio.com.

18.2 Responsible Disclosure: We welcome reports from security researchers acting in good faith. Please give us reasonable time to investigate and address a reported issue before disclosing it publicly, and do not access, modify, or retain data that does not belong to you.

19. Changes to This Policy

19.1 Updates: We review this policy at least annually and may update it to reflect changes in our practices, technology, or legal requirements. The version and "Last Updated" date at the top of this page show when it was last changed.

Version 1.0 | Last Updated: October 21, 2026