Data Processing Addendum

1. Introduction and parties

This Data Processing Addendum ("DPA") forms part of the Master Subscription Agreement (the "MSA") between Vora Financial LLC, a Florida limited liability company, 400 Sunny Isles Blvd, Sunny Isles Beach, FL 33160 ("Vora", "we", "us"), and the insurance agency or IMO named in the Order Form or that accepts this DPA in the Service (the "Customer"). The Terms of Service govern individual Authorized Users' use of the Service; this DPA governs the Customer's Client Data.

This DPA applies whenever Vora processes Client Data on the Customer's behalf in providing the Service. It takes effect on the date the MSA (or the Terms of Service) takes effect, or on the date the Customer first puts Client Data in the Service, whichever is earlier, and lasts as long as Vora processes Client Data for the Customer.

Where Vora itself acts as the agency of record for its own book of business, Vora is the controller of that data. This DPA does not apply to that data.

2. Definitions

Capitalised terms not defined here have the meaning given in the MSA. In this DPA:

• Applicable Data Protection Law means every US federal and state law that applies to the processing of Client Data under this DPA, including the Gramm-Leach-Bliley Act (15 U.S.C. §6801 et seq.) and its implementing rules, including the FTC Standards for Safeguarding Customer Information (16 C.F.R. Part 314, the "Safeguards Rule"); state insurance data security laws based on the NAIC Insurance Data Security Model Law (#668); the California Consumer Privacy Act as amended by the California Privacy Rights Act (Cal. Civ. Code §1798.100 et seq., the "CCPA") and its regulations; other comprehensive state privacy laws; and state data breach notification laws (including Fla. Stat. §501.171).
• Client means a consumer (prospect, lead, policyholder, insured or beneficiary) whose personal information the Customer puts in the Service.
• Client Data means personal information about Clients contained in Customer Data. It includes "nonpublic personal information" and "customer information" as those terms are used in the Gramm-Leach-Bliley Act and the Safeguards Rule.
• Customer Data means all data the Customer or its Authorized Users submit to the Service, including Client Data, call recordings, transcripts, messages, consent records and lead files.
• Controller means the Customer, acting as the party that decides why and how Client Data is processed. For the CCPA it is the "business". For the Gramm-Leach-Bliley Act it is the "financial institution".
• Processor means Vora, acting on the Customer's behalf. For the CCPA it is the "service provider". For the Safeguards Rule it is a "service provider".
• Process or processing means any operation performed on Client Data, such as collection, recording, storage, retrieval, use, disclosure, transmission, erasure or destruction.
• Security Incident means a confirmed breach of security that leads to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, Client Data in Vora's or a Sub-processor's systems. It does not include unsuccessful attempts that do not compromise Client Data, such as blocked log-in attempts, pings, port scans or denial-of-service attacks.
• Sub-processor means a third party Vora engages that processes Client Data for Vora in providing the Service.
• Customer-Directed Integration means a third-party service the Customer chooses to connect to the Service (for example, a Discord webhook, a carrier portal, a lead vendor or a consent certificate provider). A Customer-Directed Integration is the Customer's vendor, not Vora's Sub-processor.

3. Roles and scope

The Customer is the Controller of Client Data. Vora is the Processor. Annex A describes the processing.

The Customer is responsible for: having a lawful basis and all notices and consents needed to put Client Data in the Service and to have Vora process it; the accuracy of Client Data; its own privacy notice to Clients; responding to Clients; and its own compliance as a financial institution and as the seller in any telemarketing campaign (see the Dialer & Telemarketing Addendum).

Vora is responsible for processing Client Data in line with this DPA and Applicable Data Protection Law as it applies to a processor or service provider.

4. Data the Customer must not put in the Service

The Service is designed to hold only the last four digits of a Social Security number and the last four digits of a Medicare number. The Customer must not store in the Service, in any field, note, file, message or upload:

• full Social Security numbers, full Medicare Beneficiary Identifiers or other full government ID numbers;
• payment card numbers, bank account numbers or other financial account credentials; or
• protected health information within the meaning of HIPAA (45 C.F.R. §160.103), unless Vora and the Customer have first signed a business associate agreement.

Health information may reach the Service incidentally, for example in a lead vendor's free-form fields, in an agent's notes, or in what a Client says on a recorded call. The Customer must keep this to the minimum needed, must not use the Service as a store of medical records, and must tell its Authorized Users not to record health details in free-text fields. [COUNSEL: HIPAA — confirm that no Customer acts as a business associate of a health plan when it uses the Service, and whether Vora should offer a BAA for any Medicare or health-plan line of business. Medicare calling is disabled in the Service until this review is done.]

If the Customer breaches this section, Vora may delete the prohibited data after notice to the Customer, and Vora's obligations under this DPA do not extend to data the Customer was not permitted to store.

5. Processing only on documented instructions

Vora processes Client Data only on the Customer's documented instructions. The Customer's instructions are: the MSA, the Order Form, this DPA, the documentation of the Service, and the Customer's use and configuration of the Service (including settings its Authorized Users choose, such as recording retention, AI features and integrations).

Vora may also process Client Data where a law to which Vora is subject requires it. In that case Vora will tell the Customer of the legal requirement before processing, unless the law forbids it.

Vora will tell the Customer promptly if, in Vora's opinion, an instruction breaches Applicable Data Protection Law. Vora may suspend processing under that instruction until the Customer confirms or changes it.

Additional instructions outside the scope of the MSA need a written agreement and may carry a fee.

6. Service-provider terms (CCPA and similar state laws)

To the extent the CCPA or a similar state privacy law applies to Client Data, Vora acts as a service provider (or processor) and:

• will not sell or share Client Data, as "sell" and "share" are defined in the CCPA;
• will not retain, use or disclose Client Data for any purpose other than the business purpose of providing the Service to the Customer under the MSA, including not for Vora's own commercial purposes, except as the CCPA permits a service provider to do (for example, to detect security incidents, to fix errors, or to build or improve the Service where this does not involve building a profile about a Client);
• will not retain, use or disclose Client Data outside the direct business relationship between Vora and the Customer;
• will not combine Client Data with personal information Vora receives from or on behalf of another person, or collects from its own interaction with a consumer, except as the CCPA permits a service provider to do;
• will comply with the CCPA as it applies to service providers and give Client Data the same level of privacy protection the CCPA requires of the Customer;
• will notify the Customer if Vora decides it can no longer meet its obligations under the CCPA; and
• allows the Customer, on notice, to take reasonable and appropriate steps to stop and remediate any unauthorised use of Client Data, and to monitor Vora's compliance through the measures in section 15 (Audits).

The business purpose is: hosting, storing and processing Client Data to provide the Service (customer relationship management, deal and commission tracking, client portal, power dialer, texting, call recording, optional AI features and APIs), and the related support, security and maintenance.

Vora certifies that it understands and will comply with the restrictions in this section.

The Gramm-Leach-Bliley Act exemption in the CCPA may cover much of the Client Data. This section applies whether or not that exemption applies.

7. Gramm-Leach-Bliley Act and the Safeguards Rule

The Customer is a financial institution under the Gramm-Leach-Bliley Act. Client Data includes its nonpublic personal information. Vora will not disclose or use that information except to carry out the purposes for which the Customer disclosed it, as 16 C.F.R. Part 313 (and the equivalent state insurance privacy rules) allow for a service provider.

Vora keeps a written information security program with administrative, technical and physical safeguards appropriate to Vora's size and complexity, the nature of its activities, and the sensitivity of Client Data. The program is designed to meet the expectations that 16 C.F.R. §314.4(f) places on a financial institution when it selects and oversees a service provider, and the equivalent service-provider oversight duties under state insurance data security laws based on NAIC Model #668. Annex B describes the measures.

To help the Customer oversee Vora as a service provider, Vora will, on request: give the Customer its current security overview; answer one reasonable security questionnaire a year; and tell the Customer of any change that materially reduces the protection of Client Data. See section 15.

Vora has designated a Qualified Individual to oversee its information security program and reports in writing on it to its owners at least once a year.

8. Confidentiality of personnel

Vora gives access to Client Data only to personnel who need it to provide, support or secure the Service. Each of them is bound by a written confidentiality obligation (or a statutory duty of confidentiality) that survives the end of their engagement, and is trained on Vora's security and privacy rules when they start and at least once a year.

Vora support staff do not see Clients' sensitive fields by default. Every time a member of Vora support views a Client's protected personal fields, the access is recorded in an append-only access log, which names the fields viewed but never their values. Vora support may change Customer Data only through a short list of pre-approved, reviewed operations, never by free-form edits.

9. Security measures

Vora will implement and maintain the technical and organisational measures in Annex B. Vora may update those measures over time, but will not reduce the overall protection of Client Data.

The Customer is responsible for the security choices the Service leaves to it, including: who it invites and with which role; whether it requires two-factor authentication for all members or only for admins; its sub-agency visibility levels; its recording retention period; which AI features and integrations it enables; and keeping its own devices, accounts and exports secure.

We recommend that every Customer requires two-factor authentication for all members. The Safeguards Rule (16 C.F.R. §314.4(c)(5)) expects multi-factor authentication for any individual accessing an information system that holds customer information.

10. Sub-processors

The Customer gives Vora general authorisation to engage Sub-processors. The current list is at Sub-processors (Annex C).

Vora will: (a) enter into a written agreement with each Sub-processor that imposes data protection obligations no less protective of Client Data than this DPA, to the extent relevant to the service the Sub-processor provides; (b) assess each Sub-processor's security before using it and review it periodically; and (c) remain responsible to the Customer for each Sub-processor's performance of its obligations.

Vora will give at least 30 days' notice before a new Sub-processor starts processing Client Data, by updating the Sub-processors page and emailing the Customer's account owner (and anyone who subscribes to updates by writing to info@vorafinancial.io).

The Customer may object to a new Sub-processor on reasonable grounds relating to data protection by writing to Vora within the notice period. The parties will discuss the objection in good faith. If Vora cannot reasonably avoid using the Sub-processor for the Customer, the Customer may terminate the affected part of the Service on written notice and receive a pro-rata refund of prepaid fees for the unused term. This is the Customer's only remedy for the objection.

Vora may replace a Sub-processor without 30 days' notice in an emergency (for example, a Sub-processor's security failure or insolvency). Vora will then give notice as soon as it can.

Customer-Directed Integrations are not Sub-processors. When the Customer connects one, the Customer instructs Vora to send the relevant Customer Data to it, and the Customer is responsible for its terms.

11. AI processing

The Service's AI features process Client Data only as follows:

• Opt-in. Every AI feature that touches Customer Data is off by default. An agency admin turns it on for the agency, with a fresh second factor, and the change is recorded in the audit log.
• Gateway, zero retention, no training. Calls to large language models and speech-to-text models go through the Vercel AI Gateway with zero data retention and no prompt training requested on every request. Model providers (currently Anthropic and OpenAI) do not keep inputs or outputs and do not train on them. [COUNSEL: confirm that Vora's Vercel plan enforces request-level zero data retention for each provider before go-live.]
• Masking. The Data Assistant gets only masked, aggregated results (client names shortened to "First L.", no IDs or contact details) and redacts Social Security numbers, dates of birth, emails and phone numbers from questions. It keeps no conversation history. Report-layout mapping sends only spreadsheet headers and masked cell shapes. Lead files never reach an AI model.
• Call transcription and summaries (separate opt-in). Call audio goes to a speech-to-text model; the transcript goes to a language model told to leave out contact details, Social Security numbers, policy, payment and health details. The transcript is stored with the recording and deleted with it.
• Audio cleanup (separate opt-in). Recording audio is sent directly to ElevenLabs for noise removal, not through the AI Gateway, so the Gateway's zero-retention controls do not apply. Vora relies on ElevenLabs' own data processing terms for that processing. [COUNSEL: confirm ElevenLabs' zero-retention mode and DPA terms before the feature is enabled for any Customer.] ElevenLabs is also used to generate voice audio files from text Vora or the Customer writes (for example, a disclosure or voicemail prompt); that text should contain no Client Data.
• No autonomous decisions. AI output is advisory. No AI feature makes underwriting, eligibility or pricing decisions about a Client, and no AI feature writes to Customer Data.

AI-cloned voices of real people are not part of the Service.

12. Assistance with Client requests

The Service lets the Customer find, export, correct and archive Client Data, which lets the Customer answer most requests from Clients to exercise their privacy rights (for example, access, correction, deletion and opt-out).

If Vora receives a request directly from a Client about Client Data, Vora will not answer it except to direct the Client to the Customer, and will forward it to the Customer within 5 business days, unless the law requires Vora to respond itself.

Where the Customer cannot answer a request using the Service, Vora will give reasonable help, taking into account the nature of the processing. Help that goes beyond what the Service provides may carry a reasonable fee.

Vora will also give reasonable help with any data protection assessment or consultation with a regulator the Customer must carry out about the Service, to the extent the Customer does not otherwise have the information.

13. Security Incident notification

Vora will send the notice to the Customer's account owner and any security contact the Customer has given Vora, by email and by phone where possible. Vora's security contact is info@vorafinancial.io, 786-654-1233.

The notice will describe, as far as then known, and Vora will update it as more is learned:

• what happened, and when it started and was discovered;
• the categories and approximate number of Clients and records affected, and the data elements involved;
• whether the data was encrypted or otherwise unreadable, and whether any key was also exposed;
• the likely consequences;
• what Vora has done and will do to contain the Security Incident and reduce its effects;
• what Vora recommends the Customer do; and
• a named contact at Vora for further information.

Vora will cooperate with the Customer and give it the information it reasonably needs to meet its own deadlines, including: notices to individuals and attorneys general under state breach laws (for example, 30 days under Fla. Stat. §501.171); notice to an insurance regulator under state insurance data security laws (often 72 hours); notice to the FTC under 16 C.F.R. §314.4(j) where a notification event involves 500 or more consumers; and notices to the Customer's cyber insurer.

Unless the law requires otherwise, the Customer decides whether and how to notify Clients, regulators and others about a Security Incident affecting its Client Data. Vora will not name the Customer in a public statement about a Security Incident without the Customer's consent, unless the law requires it.

Vora will preserve relevant evidence and will, on request, share a written summary of its post-incident review. Notice of a Security Incident is not an admission of fault or liability.

14. Data location

Vora stores and processes Client Data in the United States. Vora will not transfer Client Data outside the United States, or allow remote access to it from outside the United States, without the Customer's prior written consent, except where a Sub-processor listed on the Sub-processors page states otherwise and the Customer has had the notice in section 10.

15. Audits and information

Vora does not yet hold a SOC 2 or ISO 27001 report. Until it does, Vora will meet its audit obligations as follows:

• Security overview. On request, Vora will give the Customer its current security overview, describing the measures in Annex B and Vora's compliance status.
• Questionnaire. Once a year (and after a Security Incident affecting the Customer), Vora will complete one reasonable security questionnaire the Customer sends, within 30 days.
• Evidence. Vora will make reasonable supporting evidence available for review on a call (for example, policy documents, the latest security review summary and the sub-processor list), subject to confidentiality.
• Third-party reports. Once Vora obtains an independent audit report (such as SOC 2), Vora will make it available under NDA in place of the items above where it covers them.

An on-site audit or an audit by a third-party auditor is available only: (a) after a Security Incident affecting the Customer's Client Data; or (b) where a regulator with authority over the Customer requires it. The Customer must give at least 30 days' notice (or the shorter period the regulator sets), the audit must happen during business hours and last no more than two business days, and the auditor must sign a confidentiality agreement. Each party bears its own costs, unless the audit shows a material breach of this DPA by Vora, in which case Vora bears the reasonable cost of the audit.

All audit information is Vora's Confidential Information under the MSA.

16. Return and deletion of Client Data

During the term, the Customer can export its data from the Service at any time, subject to the access controls in the Service.

On termination or expiry of the MSA, Vora will follow its agency offboarding process:

• Export. On request made within 30 days after termination, Vora will prepare a full export of the Customer's data as CSV files in an AES-256 encrypted zip. Vora sends a download link, valid for 24 hours, and the password separately, on a different channel. The export file itself expires and is deleted 7 days after it is created; Vora can make a new one on request during the deletion window.
• Suspension. Vora suspends the Customer's agency in the Service. No Authorized User can sign in to it, API keys stop working, and scheduled messages are cancelled.
• Deletion window. The data then stays, suspended, for a deletion window. The default is 30 days. The Customer may ask for a shorter (at least 7 days) or longer window in writing.
• Hard deletion. After the window ends, and after a second confirmation by Vora, Vora permanently deletes the Customer's Customer Data, including Client records, deals, recordings, transcripts, messages and stored files, and the user accounts that belonged only to the Customer.
• Certificate. On request, Vora will confirm the deletion in writing.

Vora will keep only the following after hard deletion, and only for the periods stated in Annex D:

• Consent and opt-out evidence (calling and texting consent, do-not-call and opt-out records, with recording metadata but never audio or transcripts), so the Customer can defend itself against claims under the Telephone Consumer Protection Act (47 U.S.C. §227) and state telemarketing laws. These records are kept in a restricted archive for at least 5 years from capture and, in the current process, 7 years from the hard deletion.
• Deletion and billing evidence (what was deleted and when, billing and usage records, and the support access log), for 7 years.
• Terms acceptance records and audit log entries that Vora needs to show what was agreed and what happened in the Service.
• Backups. Copies in backups are not restored for use, are protected as described in Annex B, and roll off as the backup cycle ends.

The restricted archive is read only by Vora platform administrators with a fresh second factor, and every read is logged. Vora will produce records from it to the Customer, or to a regulator or court where required, on request. While Vora holds any Client Data after termination, this DPA continues to apply to it.

If the law requires Vora to keep any other Client Data, Vora will tell the Customer, keep it confidential and process it only for the purpose the law requires.

17. Liability

Each party's liability under or in connection with this DPA is subject to the limitations and exclusions of liability in the MSA. Any separate cap the MSA sets for breaches of data protection or security obligations applies to this DPA. Nothing in this DPA limits a party's liability where the law does not allow it to be limited.

18. Order of precedence and changes

If this DPA conflicts with the MSA, the Terms of Service or an Order Form on a matter of data protection or security, this DPA wins. On every other matter, the MSA wins.

Vora may update this DPA to reflect changes in law, in the Service or in its Sub-processors, by posting a new version on this page and notifying the Customer at least 30 days before it takes effect. A change that materially reduces the protection of Client Data needs the Customer's written agreement.

If any provision of this DPA is held unenforceable, the rest of it stays in effect.

This DPA is governed by the law that governs the MSA.

Annex A. Details of processing

Annex B. Security measures

Access control and tenant isolation

• Every table in the database enforces row-level security, so each record belongs to one agency and every query is checked against the user's membership and role. Automated tests run in CI for every role, including reads that must fail, and an end-to-end test probes every page, API, storage bucket and realtime channel across two agencies.
• Privileged database functions are hardened (fixed search path, no public execution). Database objects are never exposed to anonymous users.
• Role-based access inside each agency (owner, admin, manager, agent, commission partner, client), with sub-agency visibility levels set by the parent agency.
• Sensitive fields (last 4 of SSN and Medicare number) are masked and visible only to the writing agent and agency admins. Audit records mask sensitive fields.
• Vora support has no general access to Customer Data: read-only views of a few pages, every view of protected fields logged, and changes only through allow-listed, reviewed proposals.

Authentication

• Authenticator-app (TOTP) two-factor authentication, required for agency admins by default and for all members if the agency chooses. Vora staff with platform roles must use it.
• Step-up: sensitive actions (exports, do-not-call removal, role changes, AI and recording settings) need a fresh second factor within the last 5 minutes.
• Strong password rules with leaked-password checks; rate limits on sign-in, password reset, two-factor, invitations and exports.

Encryption

• TLS for all data in transit, with HSTS (two years, preload-ready).
• Encryption at rest provided by Vora's hosting providers (AES-256 on AWS-backed storage).
• Secrets, including agency webhook secrets, stored in an encrypted vault (Supabase Vault), never in code.
• Data exports are AES-256 encrypted zip files, with the password delivered on a separate channel.

Logging and monitoring

• An append-only, partitioned audit log of security-relevant actions (exports, role changes, consent and do-not-call changes, approvals, settings).
• An append-only log of every support view of protected personal fields.
• Error monitoring with personal data collection turned off and pattern-based scrubbing before events leave the Service.
• Health checks, cron monitors and alerts for the application and workers.

Application security

• An enforced content security policy and hardened response headers; signed and replay-protected webhooks; outbound webhook protection against server-side request forgery.
• Secure development: code review on every change, automated tests, lint rules that block unsafe HTML, dependency management, and separate preview environments behind single sign-on.
• Security reviews: a full-codebase security review and production audit in October 2026, with findings tracked to closure; weekly automated OWASP ZAP baseline scans; k6 load tests.
• Secret rotation every 6 to 12 months, and immediately on any suspected leak.

Resilience

• Daily database backups by the database provider, plus a planned weekly encrypted off-site copy.
• Documented backup, restore and rollback procedures and a quarterly restore drill.

Incident response

• A written incident response plan. Any suspected exposure of personal data is treated as the highest severity: contain within 30 minutes, preserve evidence, assess, and escalate to Vora's owner and Qualified Individual immediately.
• Mandatory post-incident review for every high-severity incident.

People and vendors

• Confidentiality obligations and security training for personnel with access.
• Vendor review before a Sub-processor is engaged, and written terms with each.

Annex C. Sub-processors

The current list of Sub-processors, what each does, the data it receives and where it processes it, is at Sub-processors. That page forms part of this DPA.

Annex D. Data retention

During the term, Vora keeps Customer Data for as long as the Customer keeps it in the Service, except for the automatic periods below. After termination, section 16 applies.

Questions about this DPA: info@vorafinancial.io, 786-654-1233, 400 Sunny Isles Blvd, Sunny Isles Beach, FL 33160.