Dion Health — Access Control 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: Information Security Policy §§2, 5; Master Subscription Agreement §10; Business Associate Agreement; Privacy Policy §8; Product Schedules

This Access Control Policy (this "Policy") is a component of the written information security program Dion Health Management Company LLC ("Dion") maintains under Section 10.1 of the Master Subscription Agreement (the "Agreement"). It expands Section 5 of the Information Security Policy. Capitalized terms not defined here have the meaning given in the Agreement, the Business Associate Agreement ("BAA"), or the Information Security Policy.

1. Purpose and Scope

1.1 Purpose

This Policy defines how Dion grants, manages, reviews, and revokes access to the systems, applications, and data used to operate the Dion Suite — including Protected Health Information ("PHI"), employee and payroll data, marketing and lead data, and practice financial data.

1.2 What it covers

This Policy applies to every product in the Dion Suite and to the platform that connects them: the Dion Console and suite platform (the "hub"), Dion Insights, MedicalDentalRCM (MDRCM), Lead Intelligence, Smile Design Lab, Oralogix, Dion Growth Studio, Dion Workforce, Patient Engagement, Dion Desk, Dion Clinical (including Dion Scribe), Dion Pay, Dion Membership, and the Dion PMS Bridge.

It governs three distinct classes of subject, and the distinction matters throughout:

• Human identities — Dion personnel and Customer Authorized Users who sign in interactively.
• Machine identities — the credentials that let one system reach another without a human present: per-product service-role credentials, event-bus ingest secrets, outbox-drain credentials, and Dion PMS Bridge credentials. These are covered in Section 7.
• Customer-hosted agents — the Dion PMS Bridge, which runs on Customer hardware under Customer physical control.

1.3 Relationship to contractual commitments

This Policy is an operating standard, not a source of independent contractual obligations. Where a provision here differs from a commitment in the BAA, the Agreement, the Service Level Agreement, or an Order Form, the contractual commitment governs. This mirrors Information Security Policy §1.4.

2. Principles

Access is governed by four principles, enforced technically wherever possible rather than by convention alone:

• Least privilege — personnel, services, and machine identities receive only the access required to perform their function.
• Need to know — access to Customer data is limited to those with a specific operational need.
• Deny by default — systems reject access unless a subject is explicitly authorized; unauthenticated and unscoped requests are refused.
• Individual accountability — every access is tied to a named identity, human or machine, and is auditable. Shared or generic credentials are prohibited.

A fifth principle applies specifically to this architecture:

• Isolation is enforced where the bypass occurs. Where a control is bypassed by design — as database row-level security is bypassed by a service-role credential — the compensating control is implemented at the layer that performs the bypass, and it fails closed. See Section 6.

3. Roles and Responsibilities

4. Identity and Authentication

4.1 The suite identity plane

Access to the hub is authenticated through WorkOS AuthKit. Session tokens are cryptographically verified (RS256 against the WorkOS JWKS) on every request; expired-but-refreshable sessions are re-verified, and there is no local administrative bypass in deployments where single sign-on is required. The hub session is the identity Dion treats as authoritative for suite-level operations — the application launcher, cross-product views, entitlement enforcement, and the audit surface.

4.2 Product-level identity, stated accurately

The Dion Suite does not have a single uniform authentication stack, and this Policy does not claim one. The products were built independently and authenticate their own users through their own identity providers — several on Supabase Auth, others on AuthKit. Consolidation onto the Dion identity broker is in progress, product by product.

The access-control consequences are material and are stated rather than smoothed over:

• Where a product is integrated with the Dion identity broker, the controls in Sections 4.1, 5, and 7 apply end to end, and deprovisioning propagates as described in Section 8.
• Where a product is not yet integrated, that product's own authentication and authorization controls apply to its users, and provisioning, review, and deprovisioning must be performed in that product as well as in the broker. A deprovisioning action taken only at the broker does not, by itself, revoke access to a non-integrated product.
• The list of which products are broker-integrated is maintained operationally and is available to Customers on request. It is not published here because it changes faster than this Policy's review cycle.

4.3 Multi-factor authentication

MFA is required for all production systems, cloud consoles (database, hosting, source control, identity provider, payment and communications providers), and administrative interfaces, for both the hub and every product.

4.4 Credential standards

Where passwords apply, a minimum length of 14 characters with complexity is enforced. Shared credentials are prohibited; every human session is individual and attributable.

4.5 Session integrity

Impersonation and tenant-context cookies are signed with HMAC-SHA256; any unsigned or mis-signed session is rejected, so a lower-privilege user cannot forge elevated scope by editing a cookie. Refresh tokens are revoked server-side on sign-out.

5. Authorization

5.1 Role-based access control

Access to application data is governed by role-based access control (RBAC). Each identity carries a role — operator/administrator versus Customer — resolved from the entitlement record, which drives what actions and what data the session may reach.

5.2 Entitlements

A Customer's session may reach only the products that Customer has subscribed to. Entitlement is enforced server-side from the session's product grants, not from client-side navigation: hiding a launcher tile is a presentation choice, not an access control, and is not relied upon as one.

5.3 Resource visibility

Each product resource the hub can read is classified as shared — safe to expose under a Customer scope — or operator-only. Operator-only resources are not served to Customer sessions regardless of role resolution. This classification is declared centrally alongside the tenant column, so that adding a resource requires an explicit visibility decision rather than defaulting to exposure.

5.4 Elevated capabilities

Elevated capabilities — cross-tenant reads, impersonation for support, entitlement changes, and administrative configuration — are restricted to the operator role, require a signed context as described in Section 4.5, and are logged with the acting identity and the tenant acted upon (Section 10).

6. Tenant Isolation

Tenant isolation is implemented differently on each side of the hub boundary, and describing it as one mechanism would misstate it.

6.1 In the products

Each product enforces isolation for its own user-facing traffic through its application authorization and database row-level security (RLS).

6.2 In the hub, for Read Integrations

The hub connects to a read-integrated product with a service-role credential, which bypasses that product's RLS. RLS is therefore not the control protecting one Customer's data from another on a hub read. The controls that are:

• Tenant scoping is applied in hub code on every read. Each product declares its tenant column in a central registry; a scoped reader applies that filter to every query.
• A per-tenant read that arrives without a tenant scope fails closed — it returns an error, not unscoped rows.
• Credentials are per product, so the blast radius of a compromised credential is one product, not the suite.
• The hub does not write to, modify, or delete records in a read-integrated product.

A tenant-scoping defect is not visible from an operator view, because an operator session legitimately reads across tenants and the filter is skipped by design. Tenant scoping is therefore treated as a security-critical code path subject to test coverage and review, and a defect in it is handled as a security defect under Information Security Policy §9 whether or not data was actually exposed.

6.3 In the hub, for Event Integrations

The hub holds no credential into an event-integrated product. Isolation depends instead on the event contract: each event carries its tenant reference, is validated at ingest, and is rejected and dead-lettered if it fails validation. Events carry identifiers, references, codes, and amounts only — never clinical narrative content.

7. Machine Identities and Integration Credentials

Machine credentials are the highest-privilege access Dion holds. They are governed here explicitly rather than being treated as configuration.

7.1 Service-role credentials (Read Integrations)

• One credential per product. There is no shared platform credential.
• Issued and rotated with Security Officer approval; rotation is performed on personnel departure affecting the credential, on suspected exposure, and on a periodic basis.
• Stored with application-layer encryption in addition to database encryption (Information Security Policy §6.3), never committed to source control, and never written to logs or error output.
• Used only by server-side code. A service-role credential is never present in client-side code, in a browser, or in any Customer-reachable surface.
• Not used interactively. Personnel do not sign in to a product database with the hub's service-role credential to perform manual work; administrative access is obtained through the named individual accounts described in Section 4.

7.2 Event-bus ingest secrets (Event Integrations)

• One distinct secret per emitting product. Ingest fails closed where the secret is absent, malformed, or does not match, and rejections are logged.
• Rotation is possible without downtime by accepting a superseding secret alongside the current one for a bounded overlap window; the overlap is closed as part of the rotation, not left open.
• A secret grants only the ability to submit events for validation. It confers no read access to the hub or to any other product.

7.3 Outbox-drain credentials

Where a product drains its own event outbox on a schedule, the credential authorizing that drain resides only in that product's server-side execution environment and is not distributed to client code, to the hub, or to any other product.

7.4 Dion PMS Bridge credentials

• The Bridge holds credentials to the Customer's locally installed practice management system, configured as a read-only interface or connection. The Bridge does not write to, modify, or delete records in that system.
• The Bridge authenticates outbound only to the hub's ingest endpoint. No inbound connection into the Customer's network is opened and no remote access path into the practice is created.
• The host machine is under Customer physical and network control. Dion publishes host requirements; the Customer is responsible for meeting them, including operating-system access control, disk encryption, and physical security of the machine.

7.5 Inventory and revocation

Every machine credential is inventoried with its owning product, its purpose, its issue date, and its last rotation. Credentials are revoked immediately on decommissioning of an integration, on termination of the vendor or engagement they support, or on suspected compromise.

8. Provisioning, Review, and Deprovisioning

8.1 Provisioning

Access is granted on a least-privilege basis at onboarding, mapped to the individual's role, and approved by the Security Officer or Engineering Lead. Issuance of any machine credential additionally requires Security Officer approval (Section 7).

8.2 Periodic review

User access and privileges are reviewed quarterly, across the hub and each product. The same quarterly review covers machine credential inventory (Section 7.5) and firewall and access rules; unused ports, services, entitlements, and credentials are removed.

8.3 Deprovisioning

• Access is revoked immediately upon termination or role change.
• Automated deprovisioning at the broker. When a person is removed or deactivated in the identity directory, the identity provider notifies the application over a signature-verified webhook. The affected account is flagged and the application denies that user's session on their next request, without waiting for token expiry. As defense-in-depth, the token-refresh path also fails once the user is deactivated at the identity provider.
• Products not yet integrated with the broker require a separate revocation step, performed in that product as part of the same offboarding action (Section 4.2). Offboarding is not complete until both have been done, and the checklist reflects this.
• Machine credentials the departing person could have read are rotated, not merely left in place.
• Vendor and contractor access is removed on engagement end.

8.4 Customer Authorized Users

Provisioning and de-provisioning of a Customer's own Authorized Users is the Customer's responsibility (Agreement §5.1). Dion provides the mechanisms; the Customer decides who holds access and is responsible for removing users who should no longer have it.

9. Remote and Infrastructure Access

• Remote access to production infrastructure is permitted only over encrypted channels — TLS, or SSH with key-based authentication. SSH password authentication is disabled.
• Direct database access from the public internet is disabled; database connections are restricted to application servers within the same private network.
• Production, staging, and development environments are segmented, and non-production environments do not hold live PHI.

10. Logging and Monitoring

• Authentication events (successful and failed sign-ins, MFA events), access to PHI, and administrative and permission changes are logged with timestamp and acting identity.
• Cross-tenant operator actions, including impersonation, are logged with the acting identity and the tenant acted upon, so that an elevated action is attributable to a person rather than to a role.
• Machine-identity activity is logged — hub reads performed under a service-role credential, and accepted, rejected, and dead-lettered events at the bus ingest endpoint with the reason for rejection.
• Logs are retained for a minimum of 12 months, protected from unauthorized modification, and reviewed for anomalous access patterns.

11. Third-Party and Vendor Access

• Vendors and subprocessors with access to systems or PHI must execute a confidentiality agreement and, where applicable, a BAA before access is granted, and receive only least-privilege access.
• Material subprocessors are inventoried in the Information Security Policy §13 and evaluated for security posture before engagement.
• A model provider that processes PHI is a subprocessor and is subject to the same requirements (Information Security Policy §15).

12. Enforcement, Exceptions, and Review

Violations of this Policy may result in disciplinary action up to and including termination. Exceptions require written approval from the Security Officer, a documented compensating control, and a review date; an exception that would reduce a control below a contractual commitment cannot be granted under this Section and requires amendment of the relevant contract.

This Policy is reviewed annually, and additionally following a material change to the suite's architecture, the addition of a Service, or a security incident. Because this Policy is published at /legal/access-control-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