Sub-processor List

OCTICASE, INC. ("Octicase", "Provider", "we," "us," or "our") engages third-party service providers ("subprocessors") to process Personal Data and Protected Health Information (PHI) on behalf of our Customers. This list identifies all current subprocessors, and the planned engagements disclosed in advance, as of the effective date and is available from Provider on request and, from the date the Beta opens, at https://trust.octicase.com/subprocessors. Customers remain Data Controllers and, where applicable, Covered Entities under HIPAA.

1. Subprocessors: Current, and Planned Engagements Disclosed in Advance

2. How Customers Are Notified of Changes

If Octicase engages a new subprocessor or materially changes the scope or services of an existing subprocessor, we will:

• Provide at least thirty (30) days' advance notice via email to the Customer's account administrator and via in-app notification.
• Describe the new subprocessor's name, contact information, and general purpose of processing.
• Provide Customers with the opportunity to object as described below.

3. Customer Objection Rights

If a Customer objects to the appointment or change of a subprocessor, the Customer must email privacy@octicase.com with a description of the objection within thirty (30) days of the notice. The subject line should read: "Subprocessor Objection -- [Organization Name]."

Upon timely objection, Octicase will work with the Customer in good faith to resolve the concern. If resolution is not feasible and the Customer remains objecting, the Customer may terminate the affected Services without penalty, and Octicase will refund the pro-rata portion of any prepaid fees covering the period after the effective date of that termination, as Section 4.3 of the Data Processing Addendum and Section 5 of the Business Associate Agreement provide.

4. Critical Notes

• Email is not an approved channel for PHI. Octicase transmits no Protected Health Information by email. On the outbound route that position holds today and no Business Associate Agreement is required for it. On the inbound parsing route it does not hold: until the filtering control described below is built and verified, health information a person sends to a case address can reach the email provider, and a Business Associate Agreement is required for that route. Provider has not executed one and does not enable the inbound parsing route until either the control is in operation or that agreement is executed. This position depends on three controls. One is in force today; two are not, and are described below with their status. First, outbound transactional email must carry account, billing, scheduling and notification content only, never clinical content or matter detail. Second, open and click tracking must remain disabled for every message except marketing email addressed to a business: an open-tracking image tells the email provider that a named person opened a message from a personal-injury platform, and a rewritten link tells it which link that person followed, which is information about a person's situation even where the body of the message carries none. The feature flag that controls this is on by default in the codebase and must be turned off for all non-marketing mail (engineering, 25 August 2026). Third, the inbound email parsing route, which archives a message to a matter when it is copied to a case address, must strip or refuse content before it reaches the email provider, because that route allows a user to push clinical content into the channel even though the platform never chooses to. That control does not exist today. The route persists the message body as received, the domain's mail exchange records deliver to the email provider first, and that provider retains the message while it retries delivery. Until the control is built, inbound email must be treated as a channel through which health information can reach the provider. The table above records it: the entry for the email provider shows Protected Health Information as possible on the inbound route. The filtering control is planned and is not in operation, and this list will be revised, with the date it went into production, when it is built. Approved channels for PHI are: the platform itself (upload, portal and secure messaging), fax through SRFax, and voice through Retell AI; email, text message and any forum or question-and-answer post are not approved channels.
• Supplier of personnel, removed 8 September 2026. An earlier version of this list carried a row for a supplier of personnel, and a note describing it. Both were incorrect: Octicase engages no supplier of personnel, no such agreement under 45 CFR 164.308(b)(2) was required, and no third party holds access to the production environment. That correction reaches the staffing service described in Section 2.9 (Placed Personnel) of the Terms of Service as well: no case manager is placed with any Customer firm, and no personnel access matter content or Protected Health Information on that basis. If Octicase engages the employer of personnel to be placed under that Section, that employer will be listed here as a subprocessor and bound by the written subcontractor agreement 45 CFR 164.308(b)(2) requires, and the notice and objection process of Sections 2 and 3 will run, before any placement begins. Octicase's own personnel are not sub-processors, and where they are located is disclosed in Section 5 of the Data Processing Addendum rather than here. Removing a row does not trigger the thirty-day objection period, which applies to additions.
• Azure disaster-recovery replication is planned and is not in operation: no storage account holds a copy of the production dataset today. A HIPAA Business Associate Agreement with Microsoft is executed. Before that replication is placed in operation, two points are to be confirmed: that Azure Blob Storage is an in-scope service under that Agreement, and that the backup region is in the United States.
• Speech and voice subcontractors of Retell AI. What the voice agent says out loud is rendered by a text-to-speech vendor, and what the caller says is transcribed by a speech-recognition vendor. Retell's published documentation names ElevenLabs, Cartesia and MiniMax for synthesis and Azure, Deepgram and Soniox for recognition, and does not publish a subprocessor list or state which of them are permitted when HIPAA is enabled. Three points follow. Three points follow. First, Provider has asked Retell for that list in writing, together with confirmation that a Business Associate Agreement is in place with each permitted vendor, and does not yet hold it. Second, ElevenLabs offers a BAA only on its Enterprise tier and only with Zero Retention Mode engaged, and states that no PHI should be submitted where that mode is not engaged; a comparable condition may apply to the others. Third, until Provider holds that confirmation in writing, the voice configured on each agent is restricted to a provider Retell has confirmed is covered, and the consumer case-assist tools that read matter information aloud remain disabled. Second, note that ElevenLabs offers a BAA only on its Enterprise tier and only with Zero Retention Mode engaged, and states that no PHI should be submitted where that mode is not engaged; a comparable condition may apply to the others. Third, until the position is confirmed in writing, the voice configured on each agent should be restricted to a provider Retell has confirmed is covered, and the consumer case-assist tools that read matter information aloud should remain disabled.
• E-signature history: Dropbox Sign / HelloSign was replaced by BoldSign, which has in turn been replaced by self-hosted DocuSeal running inside our AWS HIPAA perimeter. BoldSign is retained in the data model only to read legacy records and processes no new data.
• Vertex AI: Google Cloud BAA + Cloud Data Processing Addendum executed March 16, 2026. Prompts and responses are NOT used to train Google's foundation models per the BAA.
• Apollo.io and Google Places: Listed but not yet active in production. Will be live for Phase 1 directory enrichment and vendor outreach (no PHI).
• Payments: Stripe, Inc. is the payment processor in production for subscription, add-on and prepaid-credit processing, replacing Cobalt (NeoPayment / MetroBank gateway), which no longer processes subscription, add-on or prepaid-credit payments and remains above as the configured rail for seller payouts, none of which has been made. The migration occurred while Octicase was pre-launch, with no Customer to whom the notice and objection process of Sections 2 and 3 was owed; that process governs the next change. No PHI, case type, injury type, or matter identifier is placed in payment descriptions or metadata with either processor. Stripe Connect, the payout mechanism for Platform Engagements, is not yet engaged: Octicase does not itself receive or hold amounts paid for Platform Engagements, and acts only as the seller's limited payment-collection agent under Section 4.16 of the Agreement (the Terms of Service) and the seller's own agreement with Octicase (the Expert and Consultant Services Agreement or, for partners, the Partner Agreement once published), through the processor engaged for that purpose. Payout timing is the payment processor's, subject to the delays Section 6.3 of the Expert and Consultant Services Agreement or Section 7.3 of the Partner Agreement allows.
• Directory data sources. Pre-loaded directory profiles are compiled from public registries (the National Provider Identifier registry and licensing-board records). Provider licenses no business directory for that use today; if it does, the source will be named here before any profile compiled from it is published. Those sources are data sources, not subprocessors: they do not process Customer Data or PHI on our behalf. They are described in Section D.1 of the Expert and Vendor Portal Terms, which also requires each pre-loaded listing to show its source category and refresh date; the notice at collection and the rights of the professionals named are in Section 4.12 of the Privacy Policy. The sources in use today are the National Provider Identifier registry and the record of the State Bar of California. Google Places is disclosed above as a planned source for firm domain discovery and is not active in production; this note will name it as in use, with the date, when it is enabled. None of them is a licensed directory, and Provider republishes from each on the terms that source makes public.
• Error tracking is engaged under a Business Associate Agreement executed with Octicase, so Protected Health Information that reaches an error payload is covered for the purposes of HIPAA. That agreement supplies no basis under the Confidentiality of Medical Information Act, which has no equivalent of the business associate. Whether the executed agreement itself contains the confidentiality and no-further-disclosure terms Section 56.13 requires has not been confirmed; this closes the loop on whether that agreement itself meets Section 56.13 only once it is, and until then Provider treats medical information reaching an error payload as lacking a confirmed basis under the Act, in addition to the two engineering gaps below. Two engineering conditions that would keep personal and health information out of error payloads altogether are not met today. First, scrubbing is not enforced at the point of capture: what runs there discards whole events by route rather than removing fields, and breadcrumbs are not filtered at all. Second, the browser software development kit still loads inside authenticated areas of the application, which are designated clean-room surfaces on which no third-party script may run, by several paths, including three authenticated directory routes that the clean-room classifier treats as marketing. Until both are met, error payloads are treated as capable of carrying personal and health information, and this list will be revised when they are.
• Medical information and the Confidentiality of Medical Information Act. Octicase is deemed a provider of health care under Cal. Civ. Code Section 56.06(b) for the medical information an individual maintains through the consumer services, as Section 9.5 of the Terms of Service and Section 15 of the Privacy Policy state. The Act has no equivalent of the business associate of HIPAA and no concept of an agent, so the basis for disclosing that information to a subprocessor is Cal. Civ. Code Section 56.10(c)(3), which permits disclosure to a person or entity that provides billing, claims management, medical data processing or other administrative services for providers of health care, on the express condition that the information is not further disclosed by the recipient in a way that would violate that part. Section 56.13 binds a recipient under that subdivision exactly as it binds a recipient under an authorization. Each such subprocessor's written agreement must therefore require it to hold the information in confidence, to use it only to provide its service to Octicase, and not to disclose it further. Provider does not enable a feature that discloses that information to a subprocessor unless that subprocessor's executed agreement contains that requirement and the service it provides falls within Section 56.10(c)(3). The artificial-intelligence and voice services do not sit comfortably within administrative services, so Provider does not rely on that subdivision for them. Provider distinguishes two things. Processing an individual's own submission, in the same session, solely to generate the output that individual asked for, without retaining it beyond that session unless the individual separately agrees to that under Screen C1 of the Consent Screens, is disclosed to the individual as Screen C1 describes and is not gated by a further authorization; Provider treats that as the individual's own act and not a disclosure this subdivision reaches. Once an individual has agreed under Screens C1 and C2 to have a record kept and used for training, any further processing of that kept record by an artificial-intelligence or voice provider, and any use of a voice provider for a call to or from the individual, relies instead on the express authorization of the individual, taken on Screen C5 of the Consent Screens, and Provider does not enable either service for information governed by the Act, beyond the single session Screen C1 describes, until Screen C5 is in operation. The approved channels for that information are the same as the approved channels for Protected Health Information stated in the first note above, and the same three controls hold the email position.

5. Contact

For questions about this list or to submit an objection: privacy@octicase.com