Dion Health — Information Security Policy

Version: 2.0 Effective Date: July 24, 2026 Last Updated: July 24, 2026 Document Owner: Amin Samadian, CEO / Security Officer Review Cycle: Annual (or upon material change or security incident) Related: Access Control Policy; Master Subscription Agreement §10; Business Associate Agreement; Privacy Policy §8; Product Schedules

This Information Security Policy (this "Policy") is the written information security program that Dion Health Management Company LLC ("Dion") maintains under Section 10.1 of the Master Subscription Agreement (the "Agreement") and that Section 8 of the Privacy Policy describes. Capitalized terms not defined here have the meaning given in the Agreement or the Business Associate Agreement ("BAA").

1. Purpose and Scope

1.1 Purpose

This Policy establishes the administrative, technical, and physical safeguards Dion uses to protect information assets across the Dion Suite, including Protected Health Information ("PHI") processed on behalf of Customers, employee and payroll data, and Dion's own confidential information. It is the reference point for the Security Rule commitment in BAA Section 2.3 and the security program commitment in Agreement Section 10.1.

1.2 Services covered

This Policy applies to every product in the Dion Suite, whether generally available, in limited availability, or not yet released:

Availability designations and the authoritative description of each Service are set out in the Product Schedules; where this table and a Schedule differ, the Schedule governs.

1.3 Who this Policy binds

• All Dion employees and contractors with access to systems or data.
• All systems, networks, environments, and infrastructure used to operate any Service.
• All vendors and subprocessors with access to Dion systems or to data processed on a Customer's behalf.
• All data Dion processes for Customers, including PHI received through a Read Integration, an Event Integration, or the Dion PMS Bridge.

1.4 Relationship to contractual commitments

This Policy is an operating standard, not a source of independent contractual obligations. Some provisions state internal targets that Dion sets for itself and that are deliberately stricter than what Dion has contractually promised. Where an internal target in this Policy differs from a commitment in the BAA, the Agreement, the Service Level Agreement, or an Order Form, the contractual commitment governs and is the only measure of Dion's obligation. Internal targets are labelled as such wherever they appear. Section 10.3 applies this rule to incident notification, where the distinction matters most.

2. The Architecture This Policy Secures

The Dion Suite is not one application. It is a set of independently operated products, each with its own database and its own tenancy model, connected to a central hub. The security model differs meaningfully between the hub and the products, and between the two integration modes — a single uniform description would misstate the controls. This section defines the boundaries the rest of the Policy refers to.

2.1 Trust boundaries

Dion recognizes four distinct boundaries:

1. The hub — the Dion Console and suite platform. It holds the suite session, the cross-product activity feed, the event bus and its inbox, entitlement records, and the audit surface. It is the only component that holds credentials to more than one Service. 2. Read-integrated products — each maintains its own database and its own user-facing authorization. The hub connects to each with a separate, per-product service-role credential. 3. Event-integrated products — each maintains its own database and pushes events outbound to the hub. The hub holds no credential into these products. 4. Customer-hosted components — the Dion PMS Bridge, an on-premises agent running on Customer hardware at a practice location.

2.2 Read Integration — service-role access and the code-scoping obligation

In a Read Integration, the hub reads a product's database directly using a service-role credential. The security-relevant consequence is stated plainly here because it drives several controls:

A service-role credential bypasses that product's database row-level security. Row-level security is therefore not the control that keeps one Customer's data separate from another's on a hub read. The controls that are:

• Tenant scoping is enforced in hub code on every read. Each product declares its tenant column in a central registry, and a scoped reader applies that filter to every query. A per-tenant read that reaches the connector without a tenant scope fails closed rather than returning unscoped rows.
• Credentials are per-product, and the access is read-only in effect. The hub does not write to, modify, or delete records in a read-integrated product. Each product's credential is stored and rotated independently; compromise of one does not extend to another.
• Row-level security remains enabled in each product as defense-in-depth for that product's own user-facing traffic, which does not use the service-role path.
• Operator-only resources are marked as such. Resources that are not safe to expose under a Customer scope are flagged in the registry and are not served to Customer sessions.

Because the operator console legitimately reads across tenants, a tenant-scoping defect can be invisible from an operator view. Tenant scoping is therefore treated as a code-level security control subject to test coverage and review, not as a configuration setting.

2.3 Event Integration — the PHI-free contract boundary

In an Event Integration, the product emits structured events outbound into the hub's event bus. The hub holds no inbound credential into the product, and the product's own database is never exposed to the hub. The controls are:

• The PHI rule is structural, not advisory. Events carry identifiers, references, codes, and amounts only — never clinical narrative content, and never a raw diagnostic or risk value. This is encoded in the published event contract, not left to the emitting product's discretion.
• Every event is validated at ingest against that contract, including required fields and a forbidden-key check for PHI-bearing fields. Events that fail validation are rejected and dead-lettered, not partially accepted.
• Ingest is authenticated per product with a distinct shared secret, and fails closed if the secret is absent or does not match. Rejections are logged.
• Delivery is at-least-once from a durable outbox. Where a product drains an outbox on a schedule, the credential used for that drain lives only in the product's own server-side execution environment, never in client code.

The practical effect is that a compromise of the bus inbox would expose event metadata, not clinical records — the class of data most likely to cause harm never crosses this boundary.

2.4 Customer-hosted components (Dion PMS Bridge)

The Dion PMS Bridge is an on-premises agent installed on a Customer server. Its distinguishing characteristics:

• It connects to a locally installed practice management system through that system's sanctioned developer interface or a read-only database connection, and does not write to, modify, or delete records in that system.
• It reads incremental changes since a watermark, maps them to Dion's PHI-safe event family, and transmits outbound only, over HTTPS, to the hub's ingest endpoint. No inbound connection to the Customer's network is opened, and no remote access path into the practice is created.
• The physical and network security of the host machine is the Customer's responsibility, because it is the Customer's hardware on the Customer's premises. Dion publishes host requirements; Dion cannot enforce them. This is the one place in the suite where a material control sits outside Dion's administrative reach, and it is stated here rather than left implied.

2.5 Where controls differ by boundary

3. Roles and Responsibilities

Dion designates the CEO as the Security Officer responsible for HIPAA Security Rule compliance under 45 C.F.R. § 164.308(a)(2) until a dedicated CISO role is filled. Dion states this plainly rather than implying a larger security organization than exists.

4. Data Classification

Classification drives the controls that apply. The suite processes categories governed by different bodies of law, and they are not interchangeable.

Non-commingling is a control, not a convention. Employee data in Dion Workforce is not merged into the patient-facing data of other products, and marketing and lead data is not merged into PHI. Where a Customer chooses to place health-related records into a category not designed to receive them, the Customer carries the additional legal requirements that attach — see Agreement Section 4(l) and the applicable Product Schedule.

5. Access Control

Access control is governed in detail by the Access Control Policy, which covers identity, authentication, authorization, provisioning, review, and deprovisioning across the hub and the products, and the handling of machine identities — service-role credentials, event-bus ingest secrets, and PMS Bridge credentials. The load-bearing principles:

• Least privilege, need to know, deny by default, and individual accountability.
• Multi-factor authentication on all production systems, cloud consoles, and administrative interfaces.
• Shared credentials are prohibited; every human access is individual and attributable.
• Access is reviewed quarterly and revoked immediately on termination or role change.
• Vendors and contractors sign a confidentiality agreement and, where they will access PHI, execute a BAA before access is granted.

6. Encryption

6.1 Data in transit

All data transmitted between Customers, their source systems, the products, and the hub uses TLS 1.2 or higher. Unencrypted HTTP connections are rejected. This includes the hub's reads of read-integrated product databases, event-bus ingest traffic, and the outbound transmissions from the Dion PMS Bridge. Certificates are managed through automated renewal.

6.2 Data at rest

Customer data and PHI stored in Dion-operated databases is encrypted using AES-256, enforced at the infrastructure level by the managed database and hosting providers and not disableable at the application layer. This applies uniformly across the hub and every product, whichever integration mode the product uses.

6.3 Credentials and secrets

Service-role credentials, event-bus ingest secrets, integration credentials, and API keys are stored with application-layer encryption in addition to database-level encryption. They are never written to logs, error messages, or application output. Each product's credential is distinct; there is no shared platform key whose compromise would reach multiple products. A secret used to drain a product's outbox resides only in that product's server-side execution environment.

7. Network and Application Security

• Production systems run in isolated cloud environments with network segmentation separating development, staging, and production.
• All inbound traffic to production APIs passes through a TLS-terminating load balancer or gateway.
• Direct database access from the public internet is disabled; database connections are restricted to application servers within the same private network.
• The event-bus ingest endpoint fails closed: an unauthenticated, mis-signed, or contract-invalid request is rejected, never partially accepted.
• Firewall and access rules are reviewed quarterly; unused ports, services, and entitlements are removed.
• Dependency and security patches are applied within 7 days for high and critical severity, and within 30 days for low and medium severity.

8. Audit Logging

• All access to PHI — reads, queries, and API calls, including hub reads performed under a service-role credential — is logged with timestamp, actor identity, and the data accessed.
• Authentication events (successful and failed sign-ins, MFA events) are logged.
• Administrative actions — configuration changes, permission changes, entitlement changes, and any cross-tenant operator action including impersonation — are logged.
• Event-bus activity is logged, including accepted events, rejected events, and dead-letter entries with the reason for rejection.
• Logs are retained for a minimum of 12 months, protected from unauthorized modification, and reviewed on a regular basis; anomalous access patterns trigger investigation.

9. Vulnerability Management

• Code repositories are scanned for known vulnerabilities using automated dependency and static analysis on every commit and pull request.
• Critical vulnerabilities are remediated within 7 days; high within 30 days.
• Defects in tenant scoping are treated as security defects regardless of whether data was actually exposed, because a scoping gap is invisible from an operator view.

On penetration testing, the position is stated plainly: Dion does not currently perform annual third-party penetration testing. Dion intends to engage a qualified third party for annual testing as the organization scales, and will update this Policy when that testing begins. Until then, no representation of third-party penetration testing should be inferred from this Policy or from any other Dion material.

10. Incident Response

10.1 Definition

A security incident is any actual or suspected unauthorized access to, use of, disclosure of, modification of, or destruction of Dion data or systems, or of Customer data processed by Dion.

Consistent with BAA Section 2.4(c), the parties acknowledge that unsuccessful security incidents — pings and broadcast attacks on a firewall, port scans, unsuccessful sign-in attempts, denial-of-service attempts, and malware blocked before it reaches PHI — occur routinely and are not individually reported.

10.2 Response steps

1. Detect and contain — identify the incident; isolate affected systems to prevent further exposure. 2. Assess — determine scope, the data categories affected, which Services and which Customers are implicated, and whether PHI was involved. 3. Notify — report in accordance with Section 10.3. 4. Remediate — address root cause; apply patches or configuration changes. 5. Document — maintain a written incident record including timeline, affected data, notifications made, and corrective actions. 6. Review — conduct a post-incident review within 30 days to prevent recurrence.

10.3 Notification timelines — internal target versus contractual commitment

Dion sets an internal target that is stricter than what it has contractually promised. The two must not be confused, and the contractual commitment is the only measure of Dion's obligation.

If Dion misses the internal target in row 1, it has not breached anything. Rows 2 through 5 are the commitments. Dion aims for row 1 and is bound by rows 2 through 5. Notification under any row is not an acknowledgment of fault or liability (BAA §2.4).

10.4 What the 60-day clock is, and what it is not

Three distinct 60-day figures appear in HIPAA's breach rules, with different obligors. Confusing them misstates who owes what to whom:

• 45 C.F.R. § 164.410(b) — a business associate's outer limit for reporting a breach to the covered entity: 60 calendar days after discovery. Dion's BAA commits to 30 calendar days, which is stricter than this regulatory maximum.
• 45 C.F.R. § 164.404(b) — a covered entity's deadline to notify affected individuals: without unreasonable delay and no later than 60 calendar days after its own discovery of the breach. This is the practice's obligation, not Dion's.
• 45 C.F.R. §§ 164.406 and 164.408 — a covered entity's obligations to notify prominent media and the Secretary of the U.S. Department of Health and Human Services, on their own timetables.

Dion does not notify individuals, the media, or the Secretary on a Customer's behalf, and nothing in this Policy is a representation that Dion assumes a 60-day obligation of its own. Dion reports to the Customer within the BAA's clocks and provides the information the Customer reasonably needs to meet its own obligations (Agreement §10.2). Customers should separately assess state breach notification laws, which may impose shorter or additional requirements that this Policy does not address.

10.5 Reporting

Customers and any other party should report a suspected security incident to security@dionhealth.com immediately.

11. Business Continuity and Backup

• Customer data is backed up on a daily cadence to redundant storage managed by Dion's database and hosting providers. Point-in-time recovery capability follows the provider tier in use for each Service.
• Backup restorability is verified periodically.
• Recovery Time Objective (RTO): 24 hours. Recovery Point Objective (RPO): 24 hours. These are internal targets. Availability commitments, and the sole remedies for failing to meet them, are set out in the Service Level Agreement.
• In a prolonged outage, Dion will aim to notify affected Customers within 4 hours — again an internal target, not an SLA commitment.
• Backups may contain PHI that cannot be selectively deleted. Where return or destruction of PHI is not feasible for that reason, Dion extends the BAA's protections to that PHI and limits further use and disclosure for as long as it is retained (BAA §5; Privacy Policy §7.4).

12. Personnel Security

• All employees and contractors with access to PHI complete HIPAA security awareness training on hire and annually thereafter.
• Background checks are conducted for roles with access to PHI or production systems.
• Security responsibilities are documented in employment and contractor agreements.
• Personnel are required to report suspected security incidents immediately, and may do so without fear of retaliation.
• Access is revoked immediately on termination or role change, as set out in Access Control Policy §7.

13. Vendor and Subprocessor Management

Dion evaluates third-party vendors and subprocessors for security posture before engagement. A vendor with access to PHI must:

• Execute a BAA before any PHI access, with restrictions at least as restrictive as those that apply to Dion under its own BAA (BAA §2.6);
• Demonstrate SOC 2 Type II certification or equivalent; and
• Agree to Dion's vendor security requirements.

Current material infrastructure subprocessors: Supabase (database and authentication), AWS (cloud infrastructure), Vercel (application hosting), and WorkOS (identity and single sign-on). Several products additionally depend on third parties that a Customer contracts with directly — payment processors and lenders, clearinghouses and payers, telephony and messaging carriers, advertising platforms, laboratories and manufacturers, and practice management system vendors — which are described in Privacy Policy §6.3 and are not Dion subprocessors. A current subprocessor list is available on request.

14. Certifications and Attestations

Dion states its certification posture plainly, because overstating it would be both a misrepresentation and a security risk in its own right:

• Dion has not completed a SOC 2 Type II audit.
• Dion does not hold HITRUST certification.
• Dion does not hold ISO 27001 certification.
• Dion does not currently perform annual third-party penetration testing (Section 9).

Dion's cloud infrastructure providers maintain their own SOC 2 Type II attestations, and Dion requires SOC 2 Type II certification or equivalent of subprocessors that access PHI. That is their certification, not Dion's, and Dion does not represent otherwise. No Dion material — including sales materials, security questionnaire responses, and this Policy — may state or imply a certification Dion does not hold. This Policy will be updated when the position changes.

15. Artificial Intelligence and Model Providers

Several Services apply artificial intelligence to Customer data — ambient clinical documentation in Dion Scribe, qualification and scoring in Lead Intelligence, agent assistance in Dion Desk, and risk banding in Dion Membership, among others. The controls:

• AI processing is subject to the same classification and access controls as the underlying data. Applying a model to PHI does not change that data's classification.
• A model provider that processes PHI is a subprocessor and is subject to Section 13, including the BAA requirement.
• Model outputs are drafts, not records. Dion Scribe produces draft clinical documentation; machine transcription is not a verbatim record and may be inaccurate. A licensed provider reviews the output and remains responsible for the clinical record.
• Recording an encounter requires patient consent that the Customer obtains before the feature is enabled, and consent law for recording varies by state (Privacy Policy §2.4).
• Training on Customer data is permitted only on de-identified data, under the express de-identification authorization in BAA Section 3.1 and the methods, documentation, and re-certification requirements in BAA Sections 3.2 and 3.3. The BAA governs; this Policy neither expands that authority nor creates a separate one. Re-identification is prohibited (Privacy Policy §10).

16. Policy Compliance and Exceptions

Violations of this Policy may result in disciplinary action up to and including termination. Exceptions must be approved in writing by the Security Officer, documented with a compensating control, and given a review date. An exception that would reduce a control below a contractual commitment in the Agreement or the BAA cannot be granted under this Section and requires amendment of the relevant contract.

17. Review and Updates

This Policy is reviewed annually, and additionally following a significant security incident, a material change to the suite's architecture, or the addition of a Service. Updates are communicated to all personnel within 30 days. Because this Policy is referenced by Agreement Section 10.1 and published at /legal/infosec-policy, each revision is versioned and content-hashed; the hash of the exact text in force is the authoritative record of what a Customer relied on.

Approved by: Amin Samadian, CEO / Security Officer Dion Health Management Company LLC July 24, 2026