Privacy Policy and Data Processing Addendum

Expert Grant Ecosystem LLC

Version 1.0 — LOCKED

LOCKED Date: May 25, 2026

Effective Date: June 1, 2026 (amended 2026-05-25 from June 15, 2026 to align with accelerated website-launch timeline supporting pre-June-1 first CPA executions — see "Amendments to V1.0 LOCKED" below)

Canonical URL: expertgrants.com/legal/privacy-policy-and-data-processing-addendum Short-URL redirects: expertgrants.com/privacy, expertgrants.com/dpa, expertgrants.com/privacy-policy (each 301 to canonical)

Amendments to V1.0 LOCKED:

• 2026-05-25 same-day Effective-Date amendment — Effective Date amended from June 15, 2026 to June 1, 2026 to align with Provider's accelerated website-launch timeline supporting pre-June-1 first CPA executions. R1 band, pre-execution amendable per project_lock_candidacy_amendable_pre_execution.md; no Counterparty has executed any operative agreement referencing this Policy as of the amendment date. Scope: single header field update; no body-text changes required (body references to "the effective date" are self-referential and resolve to the header value automatically). Cleanup amendment scope; no operative-effect change beyond the date shift. Joseph approved 2026-05-25.

• 2026-05-25 same-day PSA-naming consistency amendment — Part I §1.3 (Who this Policy covers) Subscribers bullet citation corrected from "EGE Platform Subscription Agreement" to "EGE Platform Services Agreement" (the contract's actual name per PSA Main §1.1 and consistent with Annex A.1.2 of this Policy and the operative-doc universe). Internal-consistency cleanup surfaced through MVP Website Page Content Draft v1 cross-doc sweep 2026-05-25. R1 band (factual citation error in LOCKED doc), pre-execution amendable per project_lock_candidacy_amendable_pre_execution.md; no Counterparty has executed any operative agreement referencing this Policy as of the amendment date. Scope: single-phrase substitution in §1.3; no other body-text changes. Cleanup amendment scope; no operative-effect change. Joseph approved 2026-05-25.

• 2026-05-25 same-day EDIP-expansion correction amendment — Part I §1.3 (Who this Policy covers) EDIP Participants bullet citation corrected from "Ethical Disclosure and Information Provision program" to "Economic Development Introduction Program" (the canonical expansion per EDIP Participation Agreement §1.5.1 + §2.1.18 LOCKED). Internal-consistency cleanup surfaced through MVP Website Page Content Draft v1 page-by-page review 2026-05-25 (same Draft cross-doc sweep cycle as the prior PSA-naming amendment). R1 band (factual citation error in LOCKED doc), pre-execution amendable per project_lock_candidacy_amendable_pre_execution.md; no Counterparty has executed any operative agreement referencing this Policy as of the amendment date. Scope: single-phrase substitution in §1.3; no other body-text changes. Cleanup amendment scope; no operative-effect change. Joseph approved 2026-05-25.

Table of Contents

Part I — Privacy Policy

§1. Introduction and Scope

§1.1 Who we are

This Privacy Policy is published by Expert Grant Ecosystem LLC, a Wyoming limited liability company with principal place of business at 101 7th Street, Mountain View, WY 82939 (EIN 41-4355272) (referred to in this Policy as "Provider," "we," "us," or "our"). Provider operates the Expert Grant Ecosystem platform (the "Platform") at expertgrants.com and the Referral Portal (the "Portal") at a subpath or subdomain of expertgrants.com.

§1.2 Owners Unscripted carve-out

Provider also operates the Owners Unscripted™ media brand, which encompasses the Owners Unscripted™ podcast, Owners Unscripted™ Live in-person events, and Owners Unscripted™ Online virtual events. The Owners Unscripted media brand operates at ownersunscripted.com and is a brand of Expert Grant Ecosystem LLC; it is not a separate legal entity. This Policy does not govern personal-data processing in connection with the Owners Unscripted media brand. A separate privacy notice for media-brand audience interactions (podcast listeners, event registrants, mailing list subscribers, social-media audiences) will be published at ownersunscripted.com/legal/privacy and will govern that processing context. If your interaction with us is solely as a member of the Owners Unscripted audience and not as a Platform participant, please consult the Owners Unscripted privacy notice instead.

§1.3 Who this Policy covers

This Policy describes how we collect, use, share, retain, and protect personal information of the following persons in connection with the Platform:

• Clients — businesses and individuals who engage the Platform's grant-funded and grant-eligible advisory, training, and application services, governed by the EGE Client Platform Agreement (the "CPA").
• Subscribers (also referred to as "Strategists" in client-facing contexts) — independent professionals who subscribe to the Platform to deliver grant-funded engagements to Clients, governed by the EGE Platform Services Agreement (the "PSA").
• Referral Agents (RAs) — independent professionals who refer prospective Clients and other counterparties to the Platform, governed by the EGE Referral Alliance Agreement (the "RAA").
• EDIP Participants — institutional-channel volunteers who participate in the Economic Development Introduction Program, governed by the EGE EDIP Participation Agreement (the "EDIP Agreement").
• Instructors — independent professionals who deliver training content under the Platform's training-grant infrastructure, governed by the EGE Instructor Services Agreement (the "ISA").
• Visitors and prospective counterparties — persons who interact with the Platform's public websites, marketing materials, or pre-engagement intake before entering into any of the foregoing agreements.

Operative contract terminology and definitions in each of the CPA, PSA, RAA, EDIP Agreement, and ISA prevail over this Policy in the event of conflict; see §11 of Part II (Order of Precedence) for the precedence framework.

§1.4 How this Policy is made available to you

This Policy is published at the canonical URL listed in the header above. Counterparties also receive routing references through their respective operative agreements:

§1.5 Relationship of Part I (Privacy Policy) and Part II (Data Processing Addendum)

This document is a unified Privacy Policy and Data Processing Addendum. Part I (this section through §13) is the Privacy Policy — the public-facing description of our personal-data practices. Part II is the Data Processing Addendum (DPA) — the contract-grade processing terms applicable to counterparties whose operative agreements incorporate this document by reference (CPA, PSA, RAA, EDIP Agreement, ISA). Part II is binding on Provider and on counterparties in proportion to each operative agreement's incorporation language. Annexes apply across both Parts where relevant.

§1.6 Effective date and version

This Policy is identified by the version number and effective date shown in the header. Material changes are governed by §11.

§2. Information We Collect

We collect personal information in the following categories, with per-tier specifics noted where material. Annex A.1 catalogs per-tier specifics in structured form; this section provides the public-facing summary.

§2.1 Account information

Information provided in connection with creating, maintaining, and authenticating Platform or Portal access:

• Identity: full legal name, business name (where applicable), preferred name.
• Contact: email address, mailing address, phone number.
• Authentication: account credentials (passwords stored hashed; password-reset tokens transient).
• Counterparty-tier classification: Client, Subscriber, Referral Agent, EDIP Participant, Instructor.
• Where required by operative agreement: government-issued identification or tax-identification numbers (Social Security Number, Employer Identification Number, equivalent foreign identifiers) for tax-reporting and payment compliance.

§2.2 Transaction information

Information generated by counterparty engagement and Platform commerce activity:

• Engagement records: SEA, SPRA, Delivery Contract, Onboarding records, and related operative records produced under the CPA, PSA, RAA, EDIP Agreement, or ISA.
• Payment information: payment-method identifiers held by our payment processor (we do not store complete card or bank-account numbers); payment-instrument metadata (last four digits, brand); transaction amounts, dates, and references.
• Payout information for Subscribers, Referral Agents, and Instructors: Stripe Connect account identifiers, payout amounts, payout dates, 1099 reporting fields.
• Billing and invoicing records.

§2.3 Content information

Information provided in the course of Platform use:

• Materials uploaded to or generated within the Platform (grant-application drafts, supporting documentation, training materials, delivery artifacts, Companion AI conversation transcripts, work product produced under operative agreements).
• Communications exchanged through the Platform (support tickets, in-Platform messaging, attribution-event communications).
• Survey responses, feedback submissions, and consent records.

§2.4 Technical and log information

Information generated automatically by use of the Platform, Portal, and public websites:

• Device and browser information: IP address, browser type and version, operating system, device identifiers, screen resolution.
• Usage analytics: pages viewed, features used, time stamps, session duration, referring URLs.
• Error logs and diagnostic data.
• Geolocation information at country / region granularity (derived from IP address or browser settings; precise geolocation is not collected without explicit consent).

§2.5 Communication information

Information exchanged outside the Platform:

• Email correspondence with Provider personnel, including system-generated notifications, marketing communications (where consent applies), and contract-execution notifications.
• E-signature transaction records (signature events, IP address at signature, timestamp), processed by Provider's e-signature sub-processor.

§2.6 Per-tier specific data

Additional information collected from specific tiers in connection with their operative engagement:

• Clients: business profile, grant-eligibility information, funding-source records, engagement scope and outcomes, post-engagement impact data (where applicable).
• Subscribers (Strategists): professional credentials, areas of practice, regional service area, Strategist Brand Guide compliance records, engagement-delivery records.
• Referral Agents: referral-source information, attribution records, payout records.
• EDIP Participants: institutional affiliation, EDIP track and tier, Affidavit of Intent records, institutional-disclosure records, consent records.
• Instructors: professional credentials, training-content authorship records, delivery records, learner-feedback records (where instructor-directed), Companion Document delivery records.

§2.7 Information we do not collect

We do not knowingly collect: special categories of personal data (GDPR Art. 9) without explicit consent and a specific lawful basis; biometric data; precise geolocation data; personal data from children under 13 (see §10).

§3. Purposes of Processing and Lawful Bases

We process personal information for the purposes described below. Each purpose is mapped to a lawful basis under the EU and UK General Data Protection Regulations (GDPR / UK GDPR Art. 6) and to a "business or commercial purpose" under the California Consumer Privacy Act / California Privacy Rights Act (CCPA / CPRA). Per-tier purposes mirror those described in CPA §7.2.4, RAA §16.2, ISA §18.2, and EDIP §17.2.

§3.1 Service delivery and Platform operation

To provide, maintain, secure, and improve the Platform, Portal, Companion AI tools, and related services; to fulfill our obligations under operative agreements; to enable counterparty-to-counterparty engagement (Subscriber-to-Client, Referral-Agent-to-Client, Instructor-to-learner).

• GDPR lawful basis: Performance of contract (Art. 6(1)(b)); legitimate interests (Art. 6(1)(f)) where pre-contractual.
• CCPA business purpose: Performing services on behalf of the business; auditing related to current interactions; ensuring security and integrity.

§3.2 Account administration and authentication

To create, manage, secure, and terminate counterparty accounts; to authenticate access; to enforce Platform policies.

• GDPR lawful basis: Performance of contract (Art. 6(1)(b)); legitimate interests in account security (Art. 6(1)(f)).
• CCPA business purpose: Account management; security and integrity.

§3.3 Payment, payout, and tax-reporting compliance

To process Client payments; to process Subscriber, Referral Agent, and Instructor payouts; to comply with tax-reporting obligations (1099 reporting; international payroll-equivalent reporting where applicable); to retain transaction records per regulatory requirements.

• GDPR lawful basis: Performance of contract (Art. 6(1)(b)); compliance with legal obligation (Art. 6(1)(c)).
• CCPA business purpose: Performing services on behalf of the business; complying with legal obligations.

§3.4 Communications and notifications

To send transactional notifications (account activity, contract-execution events, payment events, system alerts); to provide customer support; to send marketing communications where consent applies and to honor opt-out elections.

• GDPR lawful basis: Performance of contract for transactional communications (Art. 6(1)(b)); consent for marketing communications (Art. 6(1)(a)); legitimate interests for service-quality outreach to existing counterparties (Art. 6(1)(f)).
• CCPA business purpose: Performing services; advertising and marketing (subject to opt-out where applicable).

§3.5 Analytics, improvement, and quality assurance

To analyze Platform usage to improve features, fix defects, and inform development; to monitor counterparty satisfaction; to audit engagement outcomes for franchise-defense purposes; to anonymize or aggregate data for benchmarking and reporting (as further described in CPA §7.4).

• GDPR lawful basis: Legitimate interests in service improvement and franchise-defense documentation (Art. 6(1)(f)).
• CCPA business purpose: Internal research; quality and safety verification.

§3.6 Legal compliance, dispute resolution, and regulatory cooperation

To comply with applicable laws; to respond to lawful requests from courts, regulators, and law-enforcement authorities (as further described in CPA §7.8 and parallel provisions); to defend our legal interests; to enforce operative agreements; to fulfill grant-program audit obligations and EDIP institutional-disclosure obligations.

• GDPR lawful basis: Compliance with legal obligation (Art. 6(1)(c)); establishment, exercise, or defense of legal claims (Art. 9(2)(f) where special-category data applies); legitimate interests in legal-rights protection (Art. 6(1)(f)).
• CCPA business purpose: Complying with legal obligations; protecting against fraudulent or illegal activity.

§3.7 Vendor and sub-processor management

To engage and manage third-party infrastructure providers, service providers, and sub-processors as necessary to operate the Platform. Sub-processors are enumerated in Annex C.1 (counterparty-data sub-processors) and Annex C.2 (Provider-internal sub-processors).

• GDPR lawful basis: Performance of contract (Art. 6(1)(b)); legitimate interests in efficient operations (Art. 6(1)(f)).
• CCPA business purpose: Performing services on behalf of the business.

§4. Disclosure and Sharing

We share personal information only as described in this §4 and in the operative agreement applicable to your tier. The categorical disclosures below mirror those in CPA §7.2.4, RAA §16.2(f), ISA §18.2, and EDIP §17.2.

§4.1 Provider personnel

To our employees, contractors, and authorized agents who require access to personal information to perform their roles in Platform administration, counterparty support, content delivery, or compliance. All Provider personnel are bound by confidentiality obligations.

§4.2 Third-party infrastructure providers and sub-processors

To third-party infrastructure providers (including cloud hosting, edge compute, AI model hosting, payment processing, e-signature, and similar Platform-operation infrastructure) as necessary for those vendors and providers to provide services to Provider in support of the Platform. The canonical enumeration of these sub-processors, together with their roles, processing purposes, and data categories, is maintained in Annex C.1 (counterparty-data sub-processors) and Annex C.2 (Provider-internal sub-processors).

§4.3 Grant administrators

For Clients engaged in grant-funded programs, to grant-administrator entities (federal, state, local, foundation, or institutional) where required by the terms of the funded engagement and authorized by Client through the applicable Service Engagement Agreement (SEA), as further described in CPA Article 7 and the SEA.

§4.4 Counterparty-to-counterparty disclosures

In the course of Platform engagement, certain personal information necessarily flows between counterparties — for example, a Subscriber's identity is disclosed to the Client they serve; a Referral Agent's identity is disclosed to the Client they refer. These disclosures are governed by the relevant operative agreement(s) and by the consent mechanisms each agreement establishes.

§4.5 Compulsory legal-process disclosures

In response to lawful subpoenas, court orders, search warrants, regulatory inquiries, or other binding legal process, as further described in CPA §7.8 and the parallel provisions in each operative agreement. We will, where lawful and reasonable, notify the affected counterparty before disclosure.

§4.6 Business transitions

In connection with any merger, acquisition, financing, reorganization, or sale of all or part of Provider's business, personal information may be disclosed to actual or prospective successors, acquirers, financing parties, or their advisers, subject to confidentiality protections substantially equivalent to those in this Policy.

§4.7 Anonymized or aggregated data

We may produce and use anonymized or aggregated data — data that cannot reasonably be used to identify an individual — for benchmarking, reporting, research, and product-improvement purposes, as further described in CPA §7.4. Anonymized and aggregated data is not personal information under this Policy.

§4.8 With your consent or at your direction

For any other purpose disclosed to you and to which you consent, or at your direction.

§4.9 We do not sell your personal information

We do not sell personal information, and we do not "sell" or "share" personal information for cross-context behavioral advertising within the meaning of the CCPA/CPRA. See §13.3 for California-specific disclosures.

§5. International Data Transfers

§5.1 Where we process

Provider is established in the United States (Wyoming). Personal information is processed primarily in the United States. Certain sub-processors may process personal information in additional jurisdictions, including the European Union, the United Kingdom, Canada, and other regions where global cloud-infrastructure providers operate edge or regional facilities. The processing-location posture of each sub-processor is identified in Annex C.1 and Annex C.2.

§5.2 Transfer mechanisms

For personal information transferred from the European Economic Area, the United Kingdom, or Switzerland to the United States or to other jurisdictions not deemed adequate by the originating supervisory authority, we rely on:

• Standard Contractual Clauses (SCCs) — the European Commission Standard Contractual Clauses (Decision (EU) 2021/914), Module Two (Controller-to-Processor), incorporated by reference in Annex D of Part II.
• UK International Data Transfer Addendum — the UK Information Commissioner's Office Addendum to the EU SCCs, incorporated by reference in Annex D.
• Swiss FADP adaptation — the SCCs as adapted for Switzerland under the Swiss Federal Data Protection and Information Commissioner's guidance, incorporated by reference in Annex D.
• Derogations under GDPR Art. 49 where applicable (explicit consent, contract performance, public-interest, or legal-claims defense), used narrowly and only where appropriate.

§5.3 Transfer impact assessment

We have performed and maintain a transfer impact assessment evaluating the legal regime of each destination jurisdiction and the supplementary measures applied. We update the assessment when material legal or operational developments warrant. The current assessment is available to counterparties on request under appropriate confidentiality terms.

§5.4 Your rights regarding transfers

You may request a copy of the relevant transfer mechanism documentation and the transfer impact assessment summary by contacting us as described in §12.

§6. Your Privacy Rights

Depending on your jurisdiction of residence and the applicable data-protection regime, you may have the following rights with respect to your personal information. Regime-specific procedures are detailed in §13.

§6.1 The rights

• Access — the right to obtain confirmation of whether we process your personal information and to receive a copy of that information.
• Portability — the right to receive your personal information in a structured, commonly used, machine-readable format, where processing is based on consent or contract performance.
• Correction (rectification) — the right to have inaccurate personal information corrected and incomplete information completed.
• Deletion (erasure) — the right to have your personal information deleted under defined conditions.
• Restriction — the right to restrict our processing of your personal information under defined conditions.
• Objection — the right to object to processing based on legitimate interests or direct marketing.
• Withdraw consent — where processing is based on consent, the right to withdraw consent at any time, without affecting the lawfulness of processing before withdrawal.
• Automated decision-making — the right not to be subject to a decision based solely on automated processing that produces legal effects concerning you, except in defined cases; we do not currently make such decisions on the Platform.
• Complaint — the right to lodge a complaint with your supervisory authority. EU and UK residents may contact their national data-protection authority; California residents may contact the California Privacy Protection Agency or the Office of the Attorney General.

§6.2 How to exercise your rights

Contact us as described in §12. We will respond within the timeframes required by the applicable regime (generally within one calendar month under GDPR / UK GDPR; within 45 days under CCPA/CPRA, extendable by 45 additional days where reasonably necessary). For counterparty-relationship rights (post-termination data portability, retention-period inquiries), the operative agreement applicable to your tier may also describe parallel procedures.

§6.3 Identity verification

To protect against unauthorized requests, we may require verification of your identity before responding to a rights request. The verification method will be proportionate to the sensitivity of the information and the risk of unauthorized disclosure.

§6.4 No fees, with limited exceptions

We do not charge fees for responding to rights requests in the ordinary course. Where requests are manifestly unfounded, repetitive, or excessive, we may charge a reasonable fee based on administrative cost or decline the request, as permitted by the applicable regime.

§6.5 Authorized agents

You may designate an authorized agent to make a request on your behalf, where permitted by the applicable regime. We may require proof of the agent's authorization and verification of your identity.

§7. Data Retention

§7.1 Retention principle

We retain personal information for as long as necessary to fulfill the purposes for which it was collected, including for the duration of the operative-agreement relationship and for a defined period thereafter sufficient to meet legal, audit, tax-reporting, franchise-defense, and other compliance obligations.

§7.2 Per-tier retention

Per-tier retention periods are governed by the operative agreement applicable to each counterparty tier. Annex A.2 catalogs the per-tier retention rules in consolidated tabular form. The governing operative provisions are:

In the event of conflict between this Policy or Annex A.2 and the operative-contract retention provision, the operative-contract provision controls. This Policy and Annex A.2 describe existing retention rules; they do not introduce new retention rules.

§7.3 Visitor and prospective-counterparty retention

Personal information collected from visitors and prospective counterparties (pre-engagement intake records, marketing-list information, public-website analytics) is retained as follows: marketing-list information until consent is withdrawn or the relationship lapses; pre-engagement intake records for 24 months from collection unless an operative agreement is executed (in which case retention shifts to the per-tier rule above); website analytics for the period described in §9.

§7.4 Anonymization and aggregation

After applicable retention periods elapse, we may anonymize or aggregate personal information rather than delete it; anonymized and aggregated data is not subject to retention limits.

§7.5 Deletion on request

Where you have the right to request deletion under §6 and applicable law, we will delete or anonymize the relevant personal information except where retention is required by law (for example, transaction records required to be retained for tax purposes) or necessary for the establishment, exercise, or defense of legal claims. We will inform you of any such exceptions when responding to your request.

§8. Security Measures

§8.1 Our security posture

We implement and maintain appropriate technical and organizational measures (TOMs) to protect personal information against unauthorized access, alteration, disclosure, loss, or destruction, proportionate to the risk and the nature of the data processed. The TOMs operate at the conceptual layer described below, with current-state operational detail summarized in Annex B.

• Encryption. Personal information is encrypted in transit (TLS) and at rest (provider-managed encryption at our cloud-hosting and sub-processor layer).
• Access controls. Role-based access controls and the principle of least privilege govern internal access; multi-factor authentication applies to administrative accounts and to sub-processor consoles where supported.
• Audit logging. Access to, and modification of, personal information is logged within our cloud-hosting and sub-processor infrastructure.
• Backup and restore. Critical data is backed up on a regular schedule with periodic restore verification.
• Incident response. We maintain a documented incident-response procedure; see §8.3.
• Personnel training. Provider personnel receive training on data-handling responsibilities.
• Vendor diligence. Sub-processors are selected and reviewed for appropriate data-protection posture; see Annex C and Part II §4.

§8.2 Supplemental detail available on request

A supplemental TOM document with current-state operational detail (specific algorithms, key-rotation cadences, log-retention windows, sub-processor configuration specifics) is available to counterparties on request under appropriate confidentiality terms. This pattern follows GDPR Art. 32 industry norms for proportionate, audit-defensible disclosure.

§8.3 Personal data breach notification

If a personal data breach occurs that is likely to result in a risk to the rights and freedoms of natural persons, we will notify affected counterparties and, where required, the competent supervisory authority within the timeframes required by the applicable regime (within 72 hours under GDPR / UK GDPR where feasible). Specific counterparty breach-notification obligations are also described in the operative agreement applicable to each tier (for example, CPA §7.5) and in Part II §8.

§8.4 No system is perfectly secure

Despite our measures, no method of electronic storage or transmission is perfectly secure. We cannot guarantee absolute security but commit to ongoing reasonable measures and to the breach-response procedures described above.

§9. Cookies and Tracking Technologies

§9.1 What we use

We use cookies, similar tracking technologies, and analytics SDKs on our public websites, the Platform, and the Portal in four functional categories:

• Strictly necessary — required for authentication, session management, security, and basic functionality. Cannot be disabled while you use the Platform.
• Functional — remember your preferences and personalize your experience (for example, language and display preferences).
• Analytics — measure aggregate usage, performance, and error rates to inform service improvement.
• Advertising — currently not used. We do not deploy cross-context behavioral advertising trackers.

§9.2 Your choices

You may control most cookies through your browser settings (block, delete, accept on per-site basis). Where required by applicable law (EU/UK PECR; CCPA/CPRA opt-out for sale/sharing), we present a consent or opt-out interface on first interaction. We honor Global Privacy Control (GPC) signals where applicable.

§9.3 Third-party cookies

Certain sub-processors (cloud-hosting, analytics, payment processors) may set cookies on our properties; these are described in Annex C and governed by each sub-processor's own privacy notice in addition to this Policy.

§10. Children's Privacy

The Platform is directed to adult counterparties (businesses and adult individuals engaging in commercial, training, referral, or institutional-channel activity). The Platform is not directed to children. Operative agreements require counterparties to be of legal age to enter into the relevant agreement. We do not knowingly collect personal information from children under 13 (or the equivalent age threshold under applicable law, including under GDPR Art. 8, which sets the threshold at 16 by default and permits Member States to set a lower threshold not below 13). If we learn that we have collected personal information from a child without appropriate parental consent, we will delete that information promptly. If you believe a child has provided us with personal information, please contact us as described in §12.

§11. Changes to this Policy

§11.1 Versioning

We may update this Policy from time to time to reflect changes in our practices, our sub-processor roster, applicable law, or operational developments. Each revision is identified by a version number and an effective date in the header.

§11.2 Notification

For material changes that affect your rights or our processing of your personal information:

• Counterparties with active operative agreements receive notice through the channels established in the applicable agreement (CPA §7.2.5, RAA §16.4, EDIP §17.4, ISA §18.6, and the parallel PSA provision when established). Amendment of this Policy does not modify the operative agreement itself; the operative agreement's amendment provisions govern any change to its terms.
• Visitors and prospective counterparties are notified by the updated effective date on this Policy at the canonical URL. Continued use of our public websites after the effective date constitutes acknowledgment of the updated Policy with respect to non-counterparty interactions.

§11.3 Historical versions

Superseded versions of this Policy are archived and available on request, to support data-subject understanding of the processing terms in effect at any prior point in time.

§11.4 No retroactive reduction of rights

Material changes that reduce your rights as a data subject will not be applied retroactively to processing that occurred before the effective date of the change, except as required by law.

§12. How to Contact Us

§12.1 Provider contact

Expert Grant Ecosystem LLC 101 7th Street Mountain View, WY 82939 United States EIN: 41-4355272

Registered Agent: Joseph Alan Gosar, 101 7th Street, PO Box 6, Mountain View, WY 82939 (Wyoming statutory registered-agent address; mailing address for legal process only).

Email (privacy matters): privacy@expertgrants.com Email (general counterparty): the contact email designated in your operative agreement.

§12.2 Owners Unscripted media-brand privacy matters

If your inquiry concerns the Owners Unscripted™ media brand (podcast, Live events, Online events) rather than the Platform, please consult the separate privacy notice that will be published at ownersunscripted.com/legal/privacy. The Owners Unscripted notice will identify its own contact channel. Until that notice is published, please direct media-brand privacy inquiries to the email above and indicate the inquiry concerns Owners Unscripted.

§12.3 EU and UK representative

Where required by GDPR Art. 27 or UK GDPR Art. 27, we will designate a representative in the European Union and the United Kingdom and identify them in this §12. As of the effective date in the header, processing volumes and risk profile do not currently meet the Art. 27 designation threshold; we will update this Policy when designation occurs.

§12.4 Supervisory authority contact

You may contact the supervisory authority in your jurisdiction:

• EU residents: the data-protection authority of your country of residence. A list is maintained by the European Data Protection Board at edpb.europa.eu.
• UK residents: the Information Commissioner's Office (ICO) at ico.org.uk.
• California residents: the California Privacy Protection Agency at cppa.ca.gov or the Office of the Attorney General at oag.ca.gov.
• Quebec residents: the Commission d'accès à l'information du Québec at cai.gouv.qc.ca.
• Swiss residents: the Federal Data Protection and Information Commissioner at edoeb.admin.ch.

§13. Jurisdiction-Specific Disclosures

This §13 supplements the regime-neutral framework in §§1-12 with the disclosures, procedural specifics, and supervisory-authority routing required by particular data-protection regimes. Each subsection applies to data subjects whose residence, processing context, or applicable-law connection triggers that regime. Where multiple regimes apply concurrently (for example, a UK-resident Client whose processing also implicates GDPR mechanisms), the more protective standard governs the procedural element at issue.

§13.1 European Union (General Data Protection Regulation)

Applicability. This §13.1 applies to data subjects in the European Economic Area (EEA) and to processing of personal data that falls within the territorial scope of Regulation (EU) 2016/679 (the General Data Protection Regulation, "GDPR") under GDPR Art. 3.

Controller and processor designations. For personal data processed in connection with Provider's own platform-operation, account-administration, communications, and compliance activities (the purposes described in §§3.1-3.6), Provider is the data controller. For personal data processed on behalf of a counterparty in connection with counterparty-instructed Platform operations (for example, content stored within a Client's workspace; Companion AI conversation transcripts processed on Client's direction), Provider acts as data processor and the counterparty is the data controller. The controller/processor allocation is treated in detail in Part II §3 (Roles of the Parties) and Annex A.1 (Per-Tier Subject Matter and Processing Allocation).

Lawful bases. The lawful bases under GDPR Art. 6(1) on which Provider relies for each processing purpose are identified in §3 of this Policy. Special categories of personal data (GDPR Art. 9) are not knowingly processed without explicit consent (Art. 9(2)(a)) or, where applicable, the establishment, exercise, or defense of legal claims (Art. 9(2)(f)).

Data subject rights. EEA-resident data subjects have the rights described in §6.1 (access, portability, rectification, erasure, restriction of processing, objection, withdrawal of consent, rights regarding automated decision-making, complaint to a supervisory authority), exercised through the procedures described in §6.2-§6.5. Provider responds to verified rights requests without undue delay and in any event within one calendar month of receipt under GDPR Art. 12(3), extendable by up to two additional months for complex or numerous requests with notice to the data subject within the first month.

International data transfers. Transfers from the EEA to the United States or to other jurisdictions not subject to an adequacy decision under GDPR Art. 45 are protected by the mechanisms described in §5.2 (Standard Contractual Clauses under GDPR Art. 46(2)(c); Art. 49 derogations where applicable). The transfer impact assessment described in §5.3 is available on request under appropriate confidentiality terms.

Right to lodge a complaint. EEA-resident data subjects have the right under GDPR Art. 77 to lodge a complaint with a supervisory authority, in particular in the Member State of their habitual residence, place of work, or place of the alleged infringement. Supervisory-authority contact information is consolidated at §12.4.

EU representative. Provider's GDPR Art. 27 representative designation status is described at §12.3. Provider will designate an EU representative and identify them in this Policy when the Art. 27(2) exemption ceases to apply.

Data Protection Officer. Provider has assessed the criteria for mandatory designation of a Data Protection Officer under GDPR Art. 37(1) and has determined that mandatory designation does not currently apply. Privacy inquiries are directed to the contact at §12.1.

Automated decision-making. Provider does not currently make decisions concerning data subjects based solely on automated processing that produce legal effects or similarly significant effects within the meaning of GDPR Art. 22. Companion AI tools support human counterparty work product but do not autonomously make consequential decisions about data subjects.

§13.2 United Kingdom (UK GDPR and Data Protection Act 2018)

Applicability. This §13.2 applies to data subjects in the United Kingdom and to processing of personal data that falls within the territorial scope of the United Kingdom General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018 ("DPA 2018").

Parallel framework. The substantive framework of §13.1 (controller/processor designations, lawful bases, data subject rights, response timeframes, automated-decision-making posture) applies in parallel under the UK GDPR, with statutory citations read to the corresponding UK GDPR articles and DPA 2018 provisions.

International data transfers. Transfers from the United Kingdom to the United States or to other jurisdictions not subject to UK adequacy regulations are protected by the United Kingdom International Data Transfer Addendum (the "UK Addendum") to the EU Standard Contractual Clauses, or by the United Kingdom International Data Transfer Agreement ("UK IDTA"), as described in §5.2 and incorporated by reference in Annex D of Part II. Article 49 UK GDPR derogations are used narrowly where applicable.

Right to lodge a complaint. UK-resident data subjects have the right to lodge a complaint with the Information Commissioner's Office (ICO) at ico.org.uk or by post at Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom.

UK representative. Provider's UK GDPR Art. 27 representative designation status is described at §12.3. Provider will designate a UK representative and identify them in this Policy when the Art. 27(2) exemption ceases to apply.

§13.3 California (Consumer Privacy Act and Privacy Rights Act)

Applicability. This §13.3 applies to California residents whose personal information is processed by Provider and to whom the California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020 (collectively "CCPA/CPRA"), applies. References in this §13.3 to "personal information," "consumer," "sale," "share," and "sensitive personal information" carry their CCPA/CPRA definitions.

Categories of personal information collected. During the twelve months preceding the effective date of this Policy, Provider has collected the following CCPA-defined categories of personal information (cross-reference to §2 of this Policy for fuller description):

• Identifiers — name, postal address, email address, account name, unique identifiers, IP address, government-issued identifiers where required (see §2.1).
• Customer records information (Cal. Civ. Code §1798.80(e)) — name, signature, address, telephone number, financial-account information processed by our payment sub-processor (see §2.2).
• Commercial information — transaction records, payment and payout records, billing and invoicing records (see §2.2).
• Internet or other electronic network activity — browsing and usage information about the Platform, Portal, and public websites (see §2.4).
• Geolocation data — country/region-level geolocation derived from IP address (see §2.4); we do not collect precise geolocation.
• Audio, electronic, visual, or similar information — recordings of voluntary participation in events, podcasts, or interviews where notice and consent are provided.
• Professional or employment-related information — counterparty-tier classification, professional credentials, areas of practice (see §2.6).
• Inferences — limited inferences drawn from the above to support service personalization and counterparty-relationship management.
• Sensitive personal information — government-issued identifiers and financial-account information processed solely for the purposes permitted by Cal. Civ. Code §1798.121(a) (performing the services reasonably expected by the consumer, providing services on behalf of the business, and other limited purposes); account credentials (handled per §2.1; passwords stored hashed).

Sources of personal information. Provider collects personal information from: counterparties directly; counterparties' authorized representatives; counterparty-to-counterparty disclosures within the Platform (see §4.4); sub-processors operating on Provider's behalf; publicly available sources; and grant-administrator entities where applicable.

Business or commercial purposes for collection. The purposes described in §3 of this Policy correspond to the CCPA "business purposes" enumerated at Cal. Civ. Code §1798.140(e), including auditing, security and integrity, debugging, short-term transient use, performing services, providing analytic services, internal research, and quality and safety verification.

Categories of third parties to whom personal information is disclosed for a business purpose. The categories of recipients identified in §4 of this Policy: Provider personnel (§4.1); third-party infrastructure providers and sub-processors enumerated in Annex C (§4.2); grant administrators (§4.3); counterparties (§4.4); legal-process recipients (§4.5); business-transition counterparties (§4.6); and recipients to whom the consumer directs disclosure (§4.8).

Sale or sharing of personal information. Provider does not sell personal information and does not share personal information for cross-context behavioral advertising within the meaning of CCPA/CPRA. Provider has not sold or shared personal information of California consumers in the twelve months preceding the effective date of this Policy and does not knowingly sell or share the personal information of consumers under sixteen years of age.

Use and disclosure of sensitive personal information. Provider's use of sensitive personal information is limited to the purposes set out in Cal. Civ. Code §1798.121(a) and the regulations issued thereunder; Provider does not use or disclose sensitive personal information for purposes that trigger the consumer's right to limit such use under §1798.121(a).

California consumer rights. Subject to verification of identity under §6.3 and the exceptions permitted by CCPA/CPRA, California consumers have the right to:

• Know what personal information Provider has collected, used, disclosed, and (if applicable) sold or shared about them, including categories and specific pieces of information.
• Delete personal information Provider has collected from them, subject to the exceptions at Cal. Civ. Code §1798.105(d).
• Correct inaccurate personal information Provider maintains about them.
• Opt out of the sale or sharing of personal information (not applicable, because Provider neither sells nor shares).
• Limit the use and disclosure of sensitive personal information to the purposes permitted by Cal. Civ. Code §1798.121(a) (not applicable, because Provider already limits sensitive-personal-information use to those purposes).
• Non-discrimination — Provider will not discriminate against a consumer for exercising any of these rights, including by denying goods or services, charging different prices, providing a different level of quality, or suggesting that the consumer will receive different treatment for exercising their rights.
• Notice of financial incentive — Provider does not currently offer financial incentives or price/service differences in exchange for personal information; no financial-incentive disclosure under Cal. Civ. Code §1798.125(b) is required as of the effective date of this Policy.

Response timeframe. Provider responds to verified California consumer rights requests within forty-five (45) days of receipt under Cal. Civ. Code §1798.130(a)(2), extendable by an additional forty-five (45) days when reasonably necessary, with notice to the consumer of the extension and the reason within the initial period.

How to exercise California rights. California consumers may submit rights requests through the contact channels at §12.1. Provider will respond using the procedures at §6.2-§6.5.

Authorized agents. California consumers may designate an authorized agent to submit rights requests on their behalf as permitted by Cal. Civ. Code §1798.135(c) and the implementing regulations. Provider may require the agent to provide written authorization signed by the consumer and may require the consumer to verify their own identity directly with Provider.

Right to appeal. Where Provider declines to take action on a California consumer rights request, the consumer may appeal that decision by replying to Provider's response or by contacting Provider through the channels at §12.1. Provider will respond to the appeal within the timeframes required by applicable law.

Right to lodge a complaint. California consumers may lodge a complaint with the California Privacy Protection Agency at cppa.ca.gov or the California Office of the Attorney General at oag.ca.gov.

Metric disclosure. Provider has assessed the metric-disclosure threshold at Cal. Code Regs. tit. 11, §7102(a) (businesses that buy, receive for a business's commercial purposes, sell, or share for commercial purposes the personal information of 10,000,000 or more consumers in a calendar year) and has determined that Provider does not currently meet the threshold; accordingly, the metric disclosures required of threshold-meeting businesses are not included in this Policy.

§13.4 Quebec (Law 25)

Applicability. This §13.4 applies to personal information of individuals located in Quebec and to processing subject to the Quebec Act respecting the protection of personal information in the private sector, as amended by Law 25 (Act to modernize legislative provisions as regards the protection of personal information).

Person responsible for the protection of personal information. Provider designates the contact at §12.1 as the person responsible for the protection of personal information for purposes of Quebec Law 25. Inquiries, rights requests, and complaints may be directed to that contact.

Confidentiality incident register. Provider maintains a register of confidentiality incidents as required by Quebec Law 25, including incidents that present a risk of serious injury and incidents below that threshold.

Privacy impact assessments. Provider conducts privacy impact assessments for processing activities that warrant them under Quebec Law 25, including for cross-border transfers and for the acquisition, development, and overhaul of information-system or service-delivery projects involving personal information.

Cross-border transfers. Transfers of personal information outside Quebec are evaluated under the framework required by Quebec Law 25, which considers the sensitivity of the information, the purpose for use, the protection measures contractually agreed, and the legal framework applicable in the destination jurisdiction. The transfer impact assessment described in §5.3 supports this evaluation and is available on request under appropriate confidentiality terms. Transfers are governed by contractual protections substantially equivalent to those required for transfers from Quebec.

Data subject rights. Quebec-resident individuals have the rights described in §6.1, including access, rectification, withdrawal of consent, deletion or de-indexation under defined conditions, and the rights specific to Quebec Law 25 such as the right to be informed of the use of automated decision-making and to request human review of decisions based exclusively on automated processing.

Automated decision-making. Provider does not currently make decisions concerning Quebec residents based exclusively on automated processing of their personal information. If Provider implements such processing in the future, the disclosures and human-review rights required by Quebec Law 25 will be provided.

Response timeframe. Provider responds to verified Quebec rights requests within thirty (30) days of receipt as required by Quebec Law 25.

Right to portability. Quebec-resident individuals have the right under Quebec Law 25 to receive computerized personal information collected from them in a structured, commonly used technological format, and to communicate it to any person or body authorized by law to collect such information.

Right to lodge a complaint. Quebec residents may lodge a complaint with the Commission d'accès à l'information du Québec at cai.gouv.qc.ca.

Language. Provider provides this Policy in English. Quebec residents may request a French-language version of this Policy by contacting Provider at §12.1; Provider will respond to language-version requests in accordance with applicable Quebec language-rights requirements.

§13.5 Switzerland (Federal Act on Data Protection)

Applicability. This §13.5 applies to personal data of individuals in Switzerland and to processing subject to the Swiss Federal Act on Data Protection of 25 September 2020 (the revised FADP, in force 1 September 2023) and the Ordinance on Data Protection.

Controller and processor designations. The controller/processor allocation described at §13.1 applies, with statutory references read to the corresponding FADP provisions.

Data subject rights. Swiss-resident data subjects have the rights described in §6.1, including the right of access (FADP Art. 25), the right to rectification (FADP Art. 32(1)), the right to object to processing and to request deletion or destruction under defined conditions, and the right to data portability for personal data processed by automated means on the basis of consent or in connection with a contract (FADP Art. 28).

Profiling. Provider does not currently engage in high-risk profiling within the meaning of the revised FADP that would trigger the heightened transparency, consent, and impact-assessment obligations applicable to such processing. If Provider implements high-risk profiling in the future, the disclosures and procedural protections required by the FADP will be provided.

Automated individual decisions. Provider does not currently make decisions concerning Swiss-resident data subjects based exclusively on automated processing that produce legal effects or similarly significantly affect the data subject within the meaning of FADP Art. 21. If Provider implements such processing in the future, the disclosures and human-review rights required by the FADP will be provided.

International data transfers. Transfers from Switzerland to the United States or to other jurisdictions without an adequacy recognition by the Swiss Federal Council are protected by the Standard Contractual Clauses as adapted for Switzerland under the guidance of the Swiss Federal Data Protection and Information Commissioner (FDPIC), as described in §5.2 and incorporated by reference in Annex D of Part II. Article 17 FADP derogations are used narrowly where applicable.

Response timeframe. Provider responds to verified Swiss data subject access requests within thirty (30) days of receipt as required by FADP Art. 25(7).

Right to lodge a complaint. Swiss residents may lodge a complaint with the Federal Data Protection and Information Commissioner (FDPIC) at edoeb.admin.ch or by post at Federal Data Protection and Information Commissioner, Feldeggweg 1, 3003 Bern, Switzerland.

§13.6 Analogous Data-Protection Regimes

Applicability and equivalence principle. Where a data subject is a resident of a jurisdiction that has enacted a comprehensive data-protection regime not specifically addressed in §§13.1-13.5, and that regime confers rights or imposes obligations on Provider, Provider honors the equivalent rights and observes the equivalent obligations in good-faith application of the regime. The regime-neutral framework in §§1-12 and the parallel mechanisms in §13.1 (controller/processor designation, lawful-basis-equivalent legal-ground identification, transfer mechanism, response timeframe, supervisory-authority complaint right) provide the operational template; regime-specific procedural deviations are honored to the extent the applicable regime requires.

United States — comprehensive state privacy laws. Provider's processing of personal information about residents of states with comprehensive consumer-privacy regimes is governed by the principles in §§1-12 and this §13.6, with the regime-specific framework in §13.3 applicable to California residents. Provider monitors and applies, as applicable, the regimes of:

• Virginia (Consumer Data Protection Act),
• Colorado (Privacy Act),
• Connecticut (Data Privacy Act),
• Utah (Consumer Privacy Act),
• Texas (Data Privacy and Security Act),
• Oregon (Consumer Privacy Act),
• Montana (Consumer Data Privacy Act),
• Delaware (Personal Data Privacy Act),
• Iowa (Consumer Data Protection Act),
• Indiana (Consumer Data Protection Act),
• New Jersey (Data Protection Act),
• Tennessee (Information Protection Act),
• New Hampshire (Privacy Act),
• Minnesota (Consumer Data Privacy Act),
• Maryland (Online Data Privacy Act),
• Kentucky (Consumer Data Protection Act),
• Rhode Island (Data Transparency and Privacy Protection Act),

and other state comprehensive privacy regimes as they become effective or are enacted. Where a regime confers rights of access, deletion, correction, opt-out of sale/share or targeted advertising, opt-out of profiling that produces legal or similarly significant effects, portability, or appeal of declined requests, Provider honors those rights through the procedures at §6.2-§6.5 and §13.3 as applicable.

Canada (federal). Provider's processing of personal information about individuals in Canada (outside Quebec, which is addressed at §13.4) is conducted in accordance with the Personal Information Protection and Electronic Documents Act ("PIPEDA"), including the ten fair-information principles incorporated in Schedule 1 of PIPEDA. Canadian residents outside Quebec may lodge a complaint with the Office of the Privacy Commissioner of Canada at priv.gc.ca. Where provincial private-sector privacy legislation deemed substantially similar to PIPEDA applies (Alberta PIPA, British Columbia PIPA), the applicable provincial regime governs in lieu of PIPEDA, and the provincial supervisory authority is the appropriate complaint forum.

Brazil. Provider's processing of personal data about individuals in Brazil is conducted in accordance with the Lei Geral de Proteção de Dados Pessoais (Law No. 13,709/2018, "LGPD"). Brazilian-resident data subjects have the rights enumerated at LGPD Art. 18, exercised through the procedures at §6.2-§6.5. Brazilian residents may lodge a complaint with the Autoridade Nacional de Proteção de Dados (ANPD) at gov.br/anpd.

Australia. Provider's processing of personal information about individuals in Australia is conducted in accordance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles ("APPs") set out in Schedule 1 of that Act. Australian-resident individuals may lodge a complaint with the Office of the Australian Information Commissioner at oaic.gov.au.

Other jurisdictions. For data subjects in jurisdictions not enumerated above that have enacted comprehensive data-protection regimes, Provider applies the equivalence principle described at the opening of this §13.6 and honors the rights and obligations the applicable regime confers. Data subjects who wish to confirm the applicable framework in their jurisdiction or to exercise jurisdiction-specific rights may contact Provider at §12.1.

Regime evolution. The list of regimes in this §13.6 is current as of the effective date of this Policy. Provider monitors developments in comprehensive data-protection regimes globally and updates this Policy under §11 as the regulatory landscape evolves. The equivalence principle in this §13.6 operates whether or not a particular regime is enumerated here.

Part II — Data Processing Addendum

This Part II is the Data Processing Addendum (the "DPA") governing Provider's processing of personal data on behalf of, or in connection with personal data of, the counterparties identified in §1.3. This DPA is incorporated by reference into each operative agreement that references the unified Privacy Policy and Data Processing Addendum (the Client Platform Agreement, the Provider Subscriber Agreement, the Referral Alliance Agreement, the EDIP Participation Agreement, and the Instructor Services Agreement), and applies in proportion to each operative agreement's incorporation language. Where this DPA conflicts with an operative agreement on a matter within the regime-specific data-protection framework, this DPA controls; where it conflicts with an operative agreement on a matter within the operational counterparty-Provider terms, the operative agreement controls. The full order-of-precedence framework is at §11.

§1. Definitions

The terms below have the meanings given to them in this §1 when used in Part II of this Policy. Capitalized terms not defined here have the meanings given to them in the operative agreement applicable to the counterparty or, where the term is regulatory in origin, the meaning given in the applicable data-protection law.

• "Applicable Data Protection Law" means each of the data-protection regimes identified in Part I §13 (GDPR, UK GDPR + UK DPA 2018, CCPA/CPRA, Quebec Law 25, Swiss FADP) and any analogous data-protection regime that applies by virtue of a data subject's residence, the location of processing, or the connecting factor of a counterparty's operative agreement.
• "Controller" has the meaning given by GDPR Art. 4(7), UK GDPR Art. 4(7), and the parallel concept under each other Applicable Data Protection Law (in California: the "business" under Cal. Civ. Code §1798.140(d); in Quebec: the "person carrying on an enterprise" under Law 25; in Switzerland: the "controller" under FADP Art. 5(j)). Where a regime uses different terminology, references to "Controller" in this DPA carry the regime-equivalent meaning.
• "Counterparty" means a Client, Subscriber (Strategist), Referral Agent, EDIP Participant, or Instructor as defined in the operative agreement applicable to that counterparty.
• "Counterparty Personal Data" means Personal Data that Provider processes on behalf of a Counterparty in Provider's role as a Processor (e.g., personal data Counterparty uploads to, or generates within, the Platform, including content data, Companion AI conversation transcripts processed on Counterparty's direction, and personal data of Counterparty's authorized end-users such as Client employees enrolled in training). It does not include Provider Personal Data.
• "Data Subject" has the meaning given by GDPR Art. 4(1) and the parallel concept under each other Applicable Data Protection Law (in California: the "consumer" under Cal. Civ. Code §1798.140(i); in Quebec, Switzerland, and analogous regimes: the "individual" to whom the personal data relates). Where a regime uses different terminology, references to "Data Subject" in this DPA carry the regime-equivalent meaning.
• "Personal Data" has the meaning given by GDPR Art. 4(1) and the parallel concept under each other Applicable Data Protection Law (in California: "personal information" under Cal. Civ. Code §1798.140(v)). References to "Personal Data" include "Sensitive Personal Information" under CCPA/CPRA, "special categories of personal data" under GDPR Art. 9, and equivalents under each other Applicable Data Protection Law, where applicable to the processing.
• "Personal Data Breach" has the meaning given by GDPR Art. 4(12): a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed. The term carries its regime-equivalent meaning under each other Applicable Data Protection Law (under CCPA: "breach of the security of the system" under Cal. Civ. Code §1798.82(g); under Quebec Law 25: "confidentiality incident"; under Swiss FADP: "data security breach" under Art. 24).
• "Processing" has the meaning given by GDPR Art. 4(2) and the parallel concept under each other Applicable Data Protection Law (any operation performed on Personal Data, whether automated or not, including collection, storage, use, disclosure, deletion, or destruction).
• "Processor" has the meaning given by GDPR Art. 4(8), UK GDPR Art. 4(8), and the parallel concept under each other Applicable Data Protection Law (in California: the "service provider" or "contractor" under Cal. Civ. Code §1798.140(ag) / (j); in Quebec: the "person to whom personal information is communicated for the carrying out of a mandate or the performance of a contract" under Law 25 Art. 18.3; in Switzerland: the "processor" under FADP Art. 5(k)). Where a regime uses different terminology, references to "Processor" in this DPA carry the regime-equivalent meaning.
• "Provider" means Expert Grant Ecosystem LLC, the entity identified in Part I §12.1.
• "Provider Personal Data" means Personal Data that Provider processes in its role as a Controller — including personal data of Counterparties' authorized signatories (for account administration), personal data of visitors and prospective counterparties (for pre-engagement and marketing purposes), and personal data Provider processes for its own compliance, analytics, and operational purposes as described in Part I §3.
• "Restricted Transfer" means a transfer of Personal Data from a jurisdiction whose Applicable Data Protection Law restricts cross-border transfers (notably the EEA, the United Kingdom, Switzerland, Quebec, and any other jurisdiction with comparable restrictions) to a jurisdiction not deemed adequate by the originating supervisory authority, where such transfer requires a transfer mechanism under the originating law.
• "Standard Contractual Clauses" or "SCCs" means the European Commission Standard Contractual Clauses adopted under Commission Implementing Decision (EU) 2021/914 of 4 June 2021, in the module(s) applicable to the relationship of the Parties (typically Module Two, Controller-to-Processor), together with the UK International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner's Office and the SCCs as adapted for Switzerland under guidance from the Swiss Federal Data Protection and Information Commissioner. The SCCs are incorporated by reference at Annex D.
• "Sub-Processor" means any third party engaged by Provider to process Counterparty Personal Data in connection with Provider's performance of an operative agreement, other than Provider's own employees. Sub-Processors are enumerated in Annex C.1.
• "Supervisory Authority" means the data-protection regulator competent for a given Applicable Data Protection Law, as identified in Part I §12.4 and §13.

§2. Subject Matter, Duration, Nature, Purpose, Types of Personal Data, Categories of Data Subjects

The details required by GDPR Art. 28(3) and the parallel requirements under each other Applicable Data Protection Law are set out below at the general level and, on a per-tier basis, in Annex A.1.

§2.1 Subject matter of processing

The subject matter of Provider's processing on behalf of each Counterparty is the operation, administration, and delivery of the services contemplated by the operative agreement applicable to that Counterparty — the operation of the Platform (Client Platform Agreement); the delivery of Subscriber services (Provider Subscriber Agreement); the administration of referral relationships (Referral Alliance Agreement); the administration of EDIP participation (EDIP Participation Agreement); and the delivery of training services (Instructor Services Agreement).

§2.2 Duration of processing

Processing on behalf of a Counterparty continues for the duration of the operative agreement applicable to that Counterparty plus the post-termination retention period required by the operative agreement and by Applicable Data Protection Law. Post-termination retention is governed at §10 (Termination, Return, and Deletion) and at the operative-agreement retention provisions enumerated in Part I §7.2.

§2.3 Nature of processing

The nature of the processing comprises the operations described in §1 (definition of "Processing") as those operations are necessary for Platform operation, account administration, communications delivery, payment and payout processing, content storage and delivery, Companion AI conversation processing, analytics, compliance recordkeeping, and the further operational purposes described in Part I §3.

§2.4 Purpose of processing

The purposes of processing are those described in Part I §3, applied to Counterparty Personal Data only to the extent required to perform Provider's obligations under the operative agreement and to comply with Applicable Data Protection Law.

§2.5 Types of Personal Data

The categories of Personal Data processed are those described in Part I §2, applied to each Counterparty as further detailed per tier in Annex A.1. Special categories of Personal Data under GDPR Art. 9 and Sensitive Personal Information under CCPA/CPRA are not knowingly processed except where Part I §3.6 lawful bases or §13.3 SPI handling specifically apply.

§2.6 Categories of Data Subjects

The categories of Data Subjects whose Personal Data is processed by Provider are: (a) the Counterparty's authorized signatories and account-holders; (b) the Counterparty's authorized end-users (e.g., a Client's employees enrolled in training, a Subscriber's downstream client contacts where stored on the Platform, an EDIP institutional participant's institutional contact); (c) the Counterparty itself where it is a natural person; and (d) other Data Subjects whose Personal Data the Counterparty causes to be processed through Counterparty's use of the Platform. Per-tier specifics are in Annex A.1.

§2.7 Controller and Processor allocation

The controller/processor allocation differs by processing context. For Provider's own platform-operation, account-administration, communications, payment, analytics, compliance, and vendor-management activities (the purposes described in Part I §§3.1-3.7), Provider acts as Controller and processes Provider Personal Data. For Counterparty-instructed Platform operations — including the storage, processing, and routing of content the Counterparty uploads, generates, or directs to be processed (including Companion AI conversation transcripts initiated by the Counterparty); the storage of personal data of Counterparty's authorized end-users (such as a Client's employees enrolled in training); and similar Counterparty-directed processing — Provider acts as Processor on behalf of the Counterparty, and the Counterparty is the Controller. Where Provider and a Counterparty jointly determine the purposes and essential means of a particular processing operation, the Parties are joint Controllers within the meaning of GDPR Art. 26 for that operation and shall agree to a joint-controller arrangement reflecting their respective responsibilities. The per-tier controller/processor allocation is detailed in Annex A.1.

§3. Processor Obligations

Where Provider acts as Processor with respect to Counterparty Personal Data, Provider shall comply with the obligations set out in this §3, which together satisfy GDPR Art. 28(3) and the parallel processor-obligation requirements under each other Applicable Data Protection Law.

§3.1 Processing on documented instructions

Provider shall process Counterparty Personal Data only on the documented instructions of the Counterparty, including with regard to Restricted Transfers, unless required to process by EU, EU Member State, UK, US federal or state, Swiss, Quebec, or other applicable law to which Provider is subject. In such a case, Provider shall inform the Counterparty of that legal requirement before processing unless the law prohibits that information on important grounds of public interest. The operative agreement applicable to each tier, together with this DPA and the Counterparty's documented use of the Platform, constitute the Counterparty's documented instructions; the Counterparty may issue additional written instructions through the channel specified in the operative agreement, and Provider shall accommodate reasonable additional instructions or notify the Counterparty if doing so would require commercial terms outside the operative agreement.

§3.2 Confidentiality of personnel

Provider shall ensure that persons authorized to process Counterparty Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Provider's confidentiality obligations to personnel are documented in Provider's personnel policies and in personnel-engagement contracts.

§3.3 Security of processing

Provider shall implement and maintain appropriate technical and organizational measures to ensure a level of security appropriate to the risk presented by the processing, as required by GDPR Art. 32 and the parallel requirements under each other Applicable Data Protection Law. The measures are described at §7 of this DPA and summarized at Annex B.

§3.4 Sub-Processors

Provider's engagement of Sub-Processors is governed by §4 of this DPA.

§3.5 Assistance with Data Subject rights

Provider shall assist the Counterparty by appropriate technical and organizational measures, insofar as this is possible, in fulfilling the Counterparty's obligation to respond to requests from Data Subjects exercising rights under Applicable Data Protection Law. The assistance procedures are at §6 of this DPA.

§3.6 Assistance with Controller compliance obligations

Provider shall assist the Counterparty in ensuring compliance with the Counterparty's obligations under GDPR Art. 32-36 (and the parallel obligations under each other Applicable Data Protection Law) regarding security of processing, notification of Personal Data Breaches, communication of Personal Data Breaches to Data Subjects, data protection impact assessments, and prior consultation with Supervisory Authorities — taking into account the nature of the processing and the information available to Provider.

§3.7 Return or deletion at end of services

Provider shall, at the choice of the Counterparty, delete or return all Counterparty Personal Data after the end of the provision of services relating to processing, and delete existing copies unless EU, EU Member State, UK, US federal or state, Swiss, Quebec, or other applicable law requires storage. The return-or-deletion procedure is at §10 of this DPA.

§3.8 Information and audit

Provider shall make available to the Counterparty all information necessary to demonstrate compliance with the obligations laid down in this §3 and allow for and contribute to audits, including inspections, conducted by the Counterparty or another auditor mandated by the Counterparty. The audit procedure, including reasonable scope, frequency, cost-allocation, and confidentiality provisions, is at §9 of this DPA.

§3.9 Notification of unlawful instructions

Provider shall immediately inform the Counterparty if, in Provider's opinion, an instruction issued by the Counterparty infringes Applicable Data Protection Law. Provider's notification under this §3.9 does not constitute legal advice to the Counterparty and does not relieve the Counterparty of its Controller obligations.

§4. Sub-Processors

§4.1 General authorization

The Counterparty grants Provider a general authorization to engage Sub-Processors for the processing of Counterparty Personal Data, subject to the conditions set out in this §4. The Sub-Processors currently engaged by Provider are enumerated in Annex C.1.

§4.2 Sub-Processor obligations

Provider shall enter into a written contract with each Sub-Processor that imposes data-protection obligations substantially equivalent to those imposed on Provider under this DPA, including the obligations under GDPR Art. 28(3) and the parallel obligations under each other Applicable Data Protection Law. Where the Sub-Processor fails to fulfill its data-protection obligations, Provider shall remain fully liable to the Counterparty for the performance of that Sub-Processor's obligations.

§4.3 Sub-Processor change notification

Provider shall notify the Counterparty of any intended addition or replacement of a Sub-Processor at least thirty (30) calendar days in advance of the change taking effect, except where a shorter notice period is necessary to address an urgent security, availability, or compliance need (in which case Provider shall notify the Counterparty as far in advance as reasonably practicable and explain the urgency). Notification is provided through the channel specified in the operative agreement applicable to the Counterparty and, in any event, by an update to Annex C.1 at the canonical URL identified in the Part I header.

§4.4 Objection right

The Counterparty may object to an intended Sub-Processor addition or replacement on reasonable data-protection grounds, by written notice to Provider within fifteen (15) calendar days after Provider's notification under §4.3. Where the Counterparty objects, Provider shall use good-faith efforts to make available a commercially reasonable alternative to enable the Counterparty's continued use of the affected service without engaging the objected-to Sub-Processor. If no such alternative is reasonably available within thirty (30) calendar days after the objection, the Counterparty may, as its sole remedy, terminate the operative agreement with respect to the affected service in accordance with the termination procedure of that operative agreement, and Provider shall refund the prepaid-but-undelivered portion of fees attributable to the terminated service. The Counterparty's objection right is without prejudice to any further rights or remedies available to the Counterparty under Applicable Data Protection Law.

§4.5 Provider-internal sub-processors (informational)

Sub-processors that Provider uses for its own internal operations and that do not process Counterparty Personal Data (for example, Provider's payroll processor, Provider's accounting platform, Provider's general-corporate Workspace) are not Sub-Processors within the meaning of this §4. They are enumerated separately at Annex C.2 for transparency. Changes to Annex C.2 do not trigger the §4.3 notification requirement or the §4.4 objection right.

§5. International Transfers

§5.1 Transfer locations

Where Provider transfers Counterparty Personal Data across borders in connection with the processing, the destination jurisdictions are those identified in Part I §5.1 and per-Sub-Processor at Annex C.1.

§5.2 Transfer mechanisms

For Restricted Transfers, the Parties rely on the transfer mechanisms set out in Part I §5.2, which are incorporated into this DPA by this reference, including the Standard Contractual Clauses incorporated at Annex D.

§5.3 SCC implementation specifics

To the extent the Standard Contractual Clauses apply between Provider and the Counterparty:

• The Module appropriate to the Parties' roles applies (Module Two, Controller-to-Processor, where the Counterparty is the Controller and Provider is the Processor; Module Three, Processor-to-Processor, where the Counterparty is itself a Processor for an upstream Controller and Provider acts as Counterparty's Sub-Processor; Module One, Controller-to-Controller, where applicable).
• Clause 7 (Docking Clause) is included.
• Clause 9 (Sub-Processors), Option 2 (General Written Authorization) applies, with the change-notification period as specified at §4.3.
• Clause 11 (Redress), the optional independent-resolution mechanism, is not adopted.
• Clause 17 (Governing Law) is the law of the EU Member State or country of the data exporter where the SCCs require Member-State law; otherwise the law of Ireland.
• Clause 18 (Choice of Forum) is the courts of the EU Member State or country of the data exporter as the SCCs require; otherwise the courts of Ireland.
• The Annexes to the SCCs are populated by the corresponding content of this DPA: SCC Annex I.A (List of Parties) by Part I §12.1 (Provider) and the operative agreement signature block (Counterparty); SCC Annex I.B (Description of Transfer) by §2 of this DPA and Annex A.1; SCC Annex I.C (Competent Supervisory Authority) by the Supervisory Authority identified in Part I §13.1 (for EU) or §13.2 (for UK); SCC Annex II (Technical and Organizational Measures) by Annex B of this DPA; SCC Annex III (List of Sub-Processors) by Annex C.1 of this DPA.

§5.4 UK transfers

Restricted Transfers from the United Kingdom are governed by the UK International Data Transfer Addendum to the EU SCCs, incorporated at Annex D, with Part 1 (Tables) populated by the corresponding content of this DPA and Part 2 (Mandatory Clauses) applying without modification.

§5.5 Swiss transfers

Restricted Transfers from Switzerland are governed by the SCCs as adapted for Switzerland under guidance from the Swiss Federal Data Protection and Information Commissioner, incorporated at Annex D. Where the SCCs refer to "GDPR," the reference is understood, where appropriate, to be a reference to the Swiss FADP; references to "EU Member State" and to the "competent Supervisory Authority" are understood, where appropriate, to be a reference to Switzerland and to the FDPIC; and the Swiss FDPIC is the competent Supervisory Authority for Swiss-origin transfers.

§5.6 Transfer impact assessment

The transfer impact assessment referenced in Part I §5.3 evaluates the legal regime of each destination jurisdiction and identifies the supplementary measures applied. The Counterparty may obtain a current summary on request under appropriate confidentiality terms. The Parties shall cooperate in good faith to evaluate any material change in the destination-jurisdiction legal regime that would require updated supplementary measures.

§5.7 Other Restricted Transfers

For Restricted Transfers originating from a jurisdiction not addressed at §§5.3-5.5 (for example, Quebec, Brazil, or another jurisdiction with cross-border transfer restrictions), Provider shall rely on the transfer mechanism required by that jurisdiction's law (for Quebec, a transfer impact assessment satisfying Law 25 Art. 17; for Brazil, the LGPD-compliant mechanism then in effect), and shall implement the supplementary measures appropriate to the destination jurisdiction.

§6. Data Subject Rights Assistance

§6.1 Receipt and routing

Where Provider receives a Data Subject rights request directly that pertains to Counterparty Personal Data, Provider shall, without undue delay, route the request to the Counterparty and not act on the request unilaterally, except where (a) the Counterparty has provided documented instructions authorizing Provider to act, or (b) Applicable Data Protection Law requires Provider to act directly. Where the Counterparty receives a Data Subject rights request that requires Provider's technical assistance for fulfillment (e.g., a portability request requiring Provider to export the relevant data), the Counterparty shall transmit the request to Provider through the channel specified in the operative agreement.

§6.2 Assistance

Provider shall, taking into account the nature of the processing and the information available to Provider, assist the Counterparty in responding to verified Data Subject rights requests within the regime-specific timeframes identified in Part I §13. Assistance includes, as applicable: (a) confirmation of whether Counterparty Personal Data is being processed; (b) provision of a copy of the relevant Counterparty Personal Data in a structured, commonly used, machine-readable format; (c) rectification or completion of inaccurate or incomplete Counterparty Personal Data; (d) erasure of Counterparty Personal Data subject to applicable retention exceptions; (e) restriction of processing under defined conditions; (f) communication of rectification, erasure, or restriction to recipients to whom the Counterparty Personal Data was disclosed, where required; and (g) any other assistance reasonably necessary to enable the Counterparty's compliance with Applicable Data Protection Law.

§6.3 Cost-allocation

Assistance under this §6 is provided at no additional cost to the Counterparty for routine requests handled through standard Platform tooling. Where a request requires bespoke engineering or operations work that materially exceeds the standard tooling, Provider may invoice the Counterparty at Provider's standard time-and-materials rate, with prior notice to the Counterparty and the Counterparty's consent. Provider shall not invoice for assistance Provider is required to provide under Applicable Data Protection Law without additional charge.

§6.4 Identity verification

Identity-verification responsibility lies with the Controller of the relevant processing (typically the Counterparty for Counterparty Personal Data and Provider for Provider Personal Data). Provider shall, where the Counterparty is the Controller, rely on the Counterparty's verification determination; where Provider acts as the verifying party (for example, where Applicable Data Protection Law requires Provider to verify directly), Provider shall apply verification proportionate to the sensitivity of the requested data and the risk of unauthorized disclosure, consistent with the standard at Part I §6.3.

§7. Security Measures

§7.1 Security obligation

Provider shall implement and maintain appropriate technical and organizational measures to ensure a level of security appropriate to the risk presented by the processing of Counterparty Personal Data, as required by GDPR Art. 32, the parallel requirements under each other Applicable Data Protection Law, and Provider's operational commitments at Part I §8. The measures take into account the state of the art, the costs of implementation, the nature, scope, context, and purposes of the processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons.

§7.2 Annex B

The current technical and organizational measures are summarized at Annex B. Annex B is summary-level; supplemental detail (specific algorithms, key-rotation cadences, log-retention windows, sub-processor-configuration specifics) is available to the Counterparty on request under appropriate confidentiality terms.

§7.3 Updates

Provider may update the technical and organizational measures from time to time, provided that no update materially diminishes the overall level of security. Material updates that affect the Counterparty's risk posture are communicated through the channels established in the operative agreement and reflected in Annex B at the canonical URL.

§7.4 Counterparty configuration responsibility

Counterparty is responsible for the configuration of Counterparty-side controls within the Platform — including the management of Counterparty's authorized user accounts, the password and MFA hygiene of those users, the configuration of Counterparty-side access permissions, and the security of Counterparty's own systems that interact with the Platform. Provider's security obligation under this §7 does not extend to Counterparty-side controls.

§8. Personal Data Breach Notification

§8.1 Provider notification to Counterparty

Where Provider becomes aware of a Personal Data Breach affecting Counterparty Personal Data, Provider shall notify the Counterparty without undue delay and, in any event, within seventy-two (72) hours after Provider's awareness, except where notification is delayed in accordance with §8.3 below or where the breach is not reasonably likely to result in a risk to the rights and freedoms of natural persons (in which case Provider shall document the assessment supporting non-notification and make that documentation available to the Counterparty on request).

§8.2 Content of notification

The notification shall, to the extent then known and progressively as further information becomes available, include: (a) the nature of the Personal Data Breach, including, where possible, the categories and approximate number of Data Subjects concerned and the categories and approximate number of personal-data records concerned; (b) the name and contact details of the Provider point of contact for further information; (c) the likely consequences of the Personal Data Breach; and (d) the measures taken or proposed to address the Personal Data Breach, including, where appropriate, measures to mitigate possible adverse effects. Where the information cannot be provided at the same time, it may be provided in phases without undue further delay.

§8.3 Delay for security or law-enforcement reasons

Provider may delay notification under §8.1 only where delay is necessary to (a) preserve the integrity of a security investigation or response, or (b) comply with a lawful direction from a law-enforcement authority. Where notification is delayed, Provider shall notify the Counterparty as soon as the delay is no longer necessary and shall document the rationale for the delay.

§8.4 Cooperation in regulatory notification

Provider shall, where the Counterparty is required under Applicable Data Protection Law to notify a Supervisory Authority or Data Subjects of the Personal Data Breach (for example, under GDPR Art. 33 / 34, UK GDPR Art. 33 / 34, Cal. Civ. Code §1798.82, Quebec Law 25, Swiss FADP Art. 24, or analogous laws), assist the Counterparty in fulfilling that obligation, including by providing the information specified at §8.2 and by responding to reasonable Counterparty requests for additional information.

§8.5 Coordination with operative-contract breach provisions

This §8 supplements, and does not replace, the breach-notification provisions of the operative agreement applicable to the Counterparty (including Client Platform Agreement §7.5, which governs Provider-to-Client notification, and the parallel provisions in other operative agreements). Certain operative agreements also include counter-direction breach-notification provisions (for example, Instructor Services Agreement §18.4, which governs Instructor-to-Provider notification of Breach Events affecting client information accessed under Delivery Contracts); those counter-direction provisions operate concurrently with this §8 and are not displaced by it. Where this §8 and an operative agreement establish different timeframes or content requirements for the same direction of notification, the more protective standard for the affected Data Subjects applies.

§8.6 No admission

A notification under this §8 does not constitute an admission of fault, liability, or breach of the operative agreement by Provider, except to the extent expressly provided by Applicable Data Protection Law.

§9. Audit Rights

§9.1 Audit right

Subject to the conditions in this §9, the Counterparty has the right to audit Provider's compliance with this DPA, as required by GDPR Art. 28(3)(h) and the parallel audit-right requirements under each other Applicable Data Protection Law.

§9.2 Default audit mechanism

Provider shall make available to the Counterparty, on request and no more than once per twelve (12) month period (except where Applicable Data Protection Law or a material Personal Data Breach requires more frequent assessment), the following audit materials: (a) the most recent independent third-party audit report covering the Platform's security and data-protection posture (e.g., SOC 2 Type II report or equivalent attestation), where available; (b) Provider's responses to a reasonable security and data-protection questionnaire submitted by the Counterparty; and (c) Annex B and any supplemental TOM detail made available on request under §7.2. The Counterparty's auditors shall execute confidentiality undertakings substantially equivalent to those in the operative agreement before receiving the audit materials.

§9.3 On-site audit

Where the materials made available under §9.2 are insufficient to satisfy the Counterparty's audit obligation under Applicable Data Protection Law, the Counterparty may request an on-site audit. The Parties shall agree in good faith on the scope, timing, duration, auditor identity, and cost allocation of the on-site audit, with the following defaults: (a) audit scope limited to controls relevant to the Counterparty's Personal Data and the obligations under this DPA; (b) audit conducted during Provider's regular business hours with no less than thirty (30) calendar days' prior written notice except where Applicable Data Protection Law requires shorter notice; (c) auditor mutually acceptable to the Parties and bound by a confidentiality undertaking; (d) audit duration limited to what is reasonably necessary; (e) Counterparty bears the cost of the audit, except where the audit finds a material non-compliance attributable to Provider, in which case Provider bears the reasonable cost of the audit. The Counterparty's audit right under this §9.3 may not be exercised in a manner that interferes with Provider's ability to provide services to other counterparties or with the confidentiality obligations Provider owes to other counterparties.

§9.4 Supervisory Authority audits

Where a Supervisory Authority exercises an audit, investigation, or inspection right against the Counterparty or against Provider that pertains to Counterparty Personal Data, Provider shall cooperate with that audit, investigation, or inspection to the extent required by Applicable Data Protection Law, and shall notify the Counterparty without undue delay (except where the Supervisory Authority prohibits notification).

§9.5 Confidentiality of audit materials

All audit materials made available under this §9 are Provider's Confidential Information and may be used by the Counterparty solely for the purpose of verifying Provider's compliance with this DPA and the Counterparty's compliance with Applicable Data Protection Law. The Counterparty shall not disclose audit materials to third parties except (a) to the Counterparty's auditors and advisers under confidentiality obligations, (b) to Supervisory Authorities where required by Applicable Data Protection Law, or (c) with Provider's prior written consent.

§10. Termination, Return, and Deletion

§10.1 End of processing trigger

The obligations under this §10 are triggered by the end of Provider's provision of services in connection with the processing — that is, by the termination or expiration of the operative agreement applicable to the Counterparty, or by the cessation of a particular processing activity within the operative-agreement term where the cessation is bilateral or unilaterally directed by the Counterparty.

§10.2 Counterparty election

At the end of the processing, the Counterparty may elect, by written notice to Provider, between (a) return of the Counterparty Personal Data to the Counterparty in a structured, commonly used, machine-readable format, or (b) deletion of the Counterparty Personal Data, in each case subject to the retention exceptions at §10.4. The Counterparty's election shall be made no later than ninety (90) calendar days after the trigger event under §10.1; absent an election within that window, Provider shall delete the Counterparty Personal Data subject to §10.4.

§10.3 Mechanics

Return is effected by export to a Counterparty-designated location using the export tooling available on the Platform or by alternative means the Parties agree in good faith. Deletion is effected by removal of the Counterparty Personal Data from active Platform systems within the timeframe specified at §10.5. Provider shall provide written confirmation of completion of the Counterparty's election within thirty (30) calendar days after completion.

§10.4 Retention exceptions

Notwithstanding §10.2, Provider may retain Counterparty Personal Data after the end of processing where retention is required by EU, EU Member State, UK, US federal or state, Swiss, Quebec, or other applicable law (including tax, audit, grant-compliance, and anti-money-laundering recordkeeping requirements), where required for the establishment, exercise, or defense of legal claims, or where retention is otherwise governed by the per-tier retention provisions of the operative agreement (CPA §7.6, RAA §16.5, ISA §18.5, EDIP §17.5, or the parallel PSA provision when established). Retained Counterparty Personal Data shall be subject to ongoing confidentiality and security obligations under this DPA, used only for the purpose justifying retention, and deleted upon expiration of the applicable retention period or of the legal basis for retention.

§10.5 Backup deletion

Deletion under §10.3 applies to active Platform systems. Deletion from encrypted backup systems shall occur in accordance with Provider's standard backup expiration schedule, provided that backup data is not actively used and is subject to the same confidentiality and security obligations as live data. Backup expiration timing is documented in Annex B.

§10.6 Sub-Processor return or deletion

Provider shall instruct each Sub-Processor processing Counterparty Personal Data to return or delete that data in accordance with the Counterparty's election under §10.2, on terms substantially equivalent to those in this §10, subject to the §10.4 retention exceptions.

§11. Order of Precedence

This §11 establishes the order of precedence governing conflicts between this DPA, the Privacy Policy (Part I), the operative agreement applicable to a Counterparty, the Standard Contractual Clauses, and Applicable Data Protection Law. The framework is the hybrid pattern established by Client Platform Agreement §7.2.5 (and the parallel provisions in the Provider Subscriber Agreement, Referral Alliance Agreement, EDIP Participation Agreement, and Instructor Services Agreement), applied across the document ecosystem.

§11.1 General hybrid rule

On a matter within the regime-specific data-protection framework — including controller/processor allocation, lawful-basis determination, sub-processor terms, international-transfer mechanism, Data Subject rights procedures, breach-notification regulatory triggers, and the other matters governed by GDPR Art. 28 and the parallel requirements of each other Applicable Data Protection Law — this DPA controls over the operative agreement, except where the operative agreement provides a standard more protective of the Data Subject (in which case the more protective standard applies).

On a matter within the operational counterparty-Provider commercial terms — including engagement scope, payment, intellectual-property allocation, term and termination, dispute resolution, and the other matters not within the regime-specific framework — the operative agreement controls over this DPA.

The above hybrid is faithful to CPA §7.2.5 and is the operative pattern across the EGE document ecosystem.

§11.2 Standard Contractual Clauses

In any conflict between this DPA and the Standard Contractual Clauses (incorporated at Annex D), the Standard Contractual Clauses control to the extent of the conflict on a matter within the SCCs' subject-matter scope.

§11.3 Applicable Data Protection Law

Applicable Data Protection Law controls over this DPA, the Privacy Policy, the operative agreement, and the Standard Contractual Clauses, in each case to the extent of any conflict. Nothing in this DPA shall be construed to reduce a Data Subject's rights below the standard required by Applicable Data Protection Law.

§11.4 Privacy Policy (Part I) informational role for counterparty terms

Part I of this Policy (the Privacy Policy) describes Provider's personal-data practices and is binding on Provider as a public-facing disclosure to Data Subjects. On counterparty-Provider operational matters, the operative agreement and this DPA control over Part I. Where Part I and this DPA describe the same matter, the descriptions are intended to be consistent; if they nonetheless conflict on a regime-specific-framework matter, this DPA controls; if they conflict on an operational counterparty-Provider matter, the operative agreement controls.

§11.5 Annexes

The Annexes (Annex A.1, A.2, B, C.1, C.2, D, and E if adopted) are integral parts of this Policy. In the event of a conflict between an Annex and the body of Part I or Part II, the body controls, except where the Annex is the operative locus for the matter at issue (for example, Annex C.1 is the operative locus for the Sub-Processor enumeration; Annex D is the operative locus for the Standard Contractual Clauses).

§11.6 Tier-specific operative-agreement cross-references

For convenience, the operative-agreement provisions that establish the cross-reference to this Policy and the parallel hybrid order-of-precedence framework for each tier are:

§12. Specific Data-Subject-Rights Annexes

§12.1 Regime-specific procedural detail

The regime-specific procedural detail for Data Subject rights handling — including the operational procedures Provider applies for verification, intake routing, response drafting, regulator coordination, and recordkeeping for each Applicable Data Protection Law — is maintained in supplemental procedural documentation. The high-level public-facing rights enumeration is at Part I §6 and the regime-specific timing and routing rules are at Part I §13.

§12.2 Availability on request

Counterparties may request a copy of the current procedural documentation on request under appropriate confidentiality terms. The "available on request" pattern parallels the Annex B supplemental-TOM-detail pattern and is consistent with industry norms for proportionate, audit-defensible disclosure of internal data-subject-rights handling procedures.

§12.3 Updates and feedback

Provider may update the procedural documentation from time to time to reflect regulatory developments, supervisory-authority guidance, and operational learnings. Material updates that affect the Counterparty's risk posture are communicated through the channels established in the operative agreement. Counterparties may submit feedback on the procedural documentation through the channel specified in the operative agreement, and Provider shall consider that feedback in good faith.

Annexes

Annexes A.1, A.2, B, C.1, C.2, D, and E are all drafted below. Annex A was drafted in Phase 2D; Annexes B, C.1, and C.2 were drafted in Phase 2E (following completion of the F1 BoldSign DPA / SCC / data-residency verification web-research that gated the Annex C.1 BoldSign row); Annexes D (Standard Contractual Clauses incorporation by reference) and E (Glossary) were drafted in Phase 2F.

Annex A.1 — Per-Tier Subject Matter, Nature, Purpose, Data Categories

This Annex A.1 sets out the per-Counterparty-tier instantiation of the matters described in Part II §2 (Subject Matter, Duration, Nature, Purpose, Types of Personal Data, Categories of Data Subjects), as required by GDPR Article 28(3) and the parallel requirements of each other Applicable Data Protection Law. The descriptions below are drawn from the operative agreement governing each tier and operate concurrently with — and do not modify — those operative-agreement provisions; the operative-agreement section identified for each tier is the source-of-authority for that tier's processing description. In the event of conflict between this Annex A.1 and the operative-agreement description, the operative agreement controls per Part II §11.4 (Privacy Policy informational role) and §11.5 (Annexes — body-controls-default with operative-locus exception). The duration cross-references in each tier row point to Annex A.2 for the per-tier retention rules.

A.1.1 Client (Client Platform Agreement)

• Source of authority: CPA §§7.2.1–7.2.4 (Data Collected, Use of Data, Storage, Sharing); CPA §7.7 (Employee Data Authorization).
• Subject matter: Administration of Client's use of the Platform under the Client Platform Agreement, including delivery of Strategist services, grant application preparation, training-program delivery to Client's personnel, and grant-funded engagement administration through executed Strategist Engagement Agreements and Strategist Project-Rate Agreements.
• Nature of processing: Collection, storage, organization, structuring, use, disclosure to authorized Provider personnel and to assigned professionals (Strategists, Instructors, Delivering Subscribers), disclosure to third-party infrastructure providers as canonically enumerated at Annex C.1, transmission to grant administrators where Client authorizes through an executed Strategist Engagement Agreement, and erasure or anonymization on Client request or upon expiration of applicable retention periods. Processing includes AI-assisted analysis through Companion AI tools (Client Platform Assistant and analogous tools) initiated by Client and bounded by Client's voluntary input scope.
• Purposes: (a) service delivery and Platform operation; (b) billing and payment processing; (c) grant application preparation and compliance reporting; (d) communication delivery; (e) Platform improvement and product development using anonymized or aggregated data only; (f) compliance with applicable law. Where Client engages in grant-funded engagements, additional grant-program-compliance purposes apply through executed Strategist Engagement Agreements.
• Duration: Term of the Client Platform Agreement plus the retention periods set forth at Annex A.2 (per CPA §7.6) and any applicable grant-program audit retention requirements.
• Types of Personal Data: Contact information (name, email, phone, address); business information (entity type, industry, employee count); financial data (payment method, billing history, grant application financials); engagement data (project scope, deliverables, attendance records, certificates); AI tool inputs and outputs (Digital Strategy Workbook interactions, document generation data); communication data (emails, texts, and calls processed through Platform infrastructure); and employee data for Client's personnel participating in Platform-facilitated training sessions (CPA §7.7) — names, email addresses, attendance hours, and course completion data.
• Categories of Data Subjects: Client (where Client is a natural person or natural-person principal of a Client entity); Client's authorized representatives and personnel interacting with the Platform on Client's behalf; Client's employees participating in Platform-facilitated training sessions under CPA §7.7; Client's grant-administrator points-of-contact to the extent Client transmits such information to Provider through the Platform for engagement-administration purposes.

A.1.2 Subscriber (Platform Services Agreement)

• Source of authority: Platform Services Agreement, Article on Data Privacy — TBD pending PSA workstream gate. Until the PSA's AI sub-processor disclosure sweep closes and the canonical Subscriber data-privacy citation is established, this row carries an interim operational-coverage placeholder consistent with the parallel placeholders at Part II §10.4 (Retention Exceptions), §11.6 (Tier-specific operative-agreement cross-references), and Annex A.2 row A.2.2.
• Subject matter (interim): Administration of Subscriber's use of the Platform under the Platform Services Agreement to deliver Strategist services to Subscriber's clients on a managed-services basis, including Subscriber's onboarding-stage and operational interactions with the Platform and the Subscriber-tier portions of Companion AI tool access.
• Nature of processing (interim): Collection, storage, organization, structuring, use, disclosure to authorized Provider personnel and to Sub-Processors as canonically enumerated at Annex C.1, transmission as authorized by Subscriber, and erasure or de-identification on Subscriber request or upon expiration of applicable retention periods.
• Purposes (interim): Service delivery and Platform operation; settlement and payment processing; communication delivery; Platform improvement and product development using anonymized or aggregated data only; compliance with applicable law; and additional purposes specified in the PSA upon lock. Where Subscriber serves Clients, the data-controllership architecture between Subscriber and the Client-tier Counterparty is governed by the PSA upon lock and is reserved here.
• Duration: Term of the Platform Services Agreement plus the retention periods set forth at Annex A.2.
• Types of Personal Data (interim): Account credentials and contact information; tax documentation; banking information for settlement; Subscriber activity data on the Platform; AI tool inputs and outputs initiated by Subscriber through Subscriber-tier Companion AI tools; communication data through Platform infrastructure.
• Categories of Data Subjects (interim): Subscriber (as a natural person or natural-person principal of a Subscriber entity); Subscriber's authorized representatives interacting with the Platform on Subscriber's behalf.
• Reservation: The interim descriptions above are operationally accurate as to the Subscriber-Provider relationship under Provider's current Platform operation; they will be replaced by the canonical PSA-anchored descriptions upon completion of the PSA workstream consistent with the Phase 1 audit §3 observation that no back-amendment cascade is triggered from the present four-tier audit.

A.1.3 Referral Agent (Referral Alliance Agreement)

• Source of authority: RAA §16.2 (Provider's Handling of RA Data); RAA §16.4 (Data-Privacy Framework — Companion Document).
• Subject matter: Administration of Referral Agent's participation in the Global Referral Alliance under the Referral Alliance Agreement, including referral submission through the Referral Portal, attribution tracking through the Lead Lock Registry, commission processing through Stripe Connect and the Friday Settlement Batch infrastructure, and the Alliance Introduction Bonus program.
• Nature of processing: Collection, storage, organization, structuring, use, disclosure to authorized Provider personnel and to third-party infrastructure providers (including the Stripe Connect payment infrastructure) as canonically enumerated at Annex C.1, transmission as authorized by Referral Agent under RAA §22.3.4 (Operational Consent Mechanism), and erasure or de-identification following termination consistent with RAA §16.5 and §16.4.
• Purposes: (a) administering the Referral Alliance Agreement; (b) processing payments through Stripe Connect and the Friday Settlement Batch infrastructure; (c) complying with tax, financial, and regulatory reporting obligations; (d) communicating with Referral Agent about Platform updates, system changes, and operational matters relevant to Referral Alliance participation; (e) performing internal analytics and quality improvement on Platform operations and the Referral Alliance program; (f) sharing with Provider Tooling vendors as defined in RAA §2.1.36 and with third-party infrastructure providers (cloud hosting, edge compute, AI model hosting, payment processing, and similar Platform-operation infrastructure) to the extent necessary for those vendors and providers to provide services to Provider in support of the Platform and the Referral Alliance, as canonically enumerated at Annex C.1; (g) producing aggregated or de-identified analyses where the resulting data does not identify Referral Agent; (h) any additional purpose for which Referral Agent provides separate, specific consent under RAA §22.3.4.
• Duration: Term of the Referral Alliance Agreement plus the retention periods set forth at Annex A.2 (per RAA §16.5).
• Types of Personal Data: Name; contact information (email, phone, address); tax documentation (IRS Form W-9 for U.S. persons or W-8BEN for non-U.S. persons); banking information (Stripe Connect Express account details); commission records and attribution data; Lead Lock Registry records; Platform activity data; and operational-consent records under RAA §22.3.4.
• Categories of Data Subjects: Referral Agent (natural person — RAA does not permit entity-level participation per RAA §1.1.2). No client data subjects are introduced through RAA-side processing — Referral Agent has no access to client CRM records per RAA §16.3, except through the Introducing Party Dashboard limited disclosures under RAA §7.8 and Re-Up communications under RAA §8.7, each with contained scope.

A.1.4 EDIP Participant (EDIP Participation Agreement)

• Source of authority: EDIP §17.2 (Provider's Handling of EDIP Participant Data); EDIP §17.4 (Data-Privacy Framework — Companion Document); EDIP §17.6 (Institutional-Host Data).
• Subject matter: Administration of EDIP Participant's participation in the Expert Disclosed-Introduction Program under the EDIP Participation Agreement, including disclosed-introduction submissions through the institutional channel, attribution tracking, Air Gap mechanism operation under EDIP §6.3, Affidavit-of-Intent records under EDIP §6.4 and Schedule A, Institutional Disclosure Letter records under EDIP §12.0 and Schedule B, EDIP Community participation, and Institutional Partnership Letter administration under EDIP §2.1.31.
• Nature of processing: Collection, storage, organization, structuring, use, disclosure to authorized Provider personnel and to Provider Tooling vendors as defined in EDIP §2.1.46 and canonically enumerated at Annex C.1, transmission of Institutional Partnership Letter materials to EDIP Participant's Institutional Host Organization to the extent contemplated by EDIP §12.8, and erasure or de-identification following termination consistent with EDIP §17.5 and §17.4. EDIP Participation operates on a zero-personal-compensation basis (EDIP §18.0); accordingly, processing does not include payment-infrastructure provisioning to EDIP Participant.
• Purposes: (a) administering the EDIP Participation Agreement; (b) operating the Air Gap mechanism under EDIP §6.3 (without provisioning payment infrastructure to EDIP Participant); (c) complying with applicable legal, regulatory, and franchise-defense documentation obligations; (d) communicating with EDIP Participant about Platform updates, system changes, and operational matters relevant to EDIP Participation; (e) performing internal analytics and quality improvement on Platform operations and EDIP; (f) sharing with Provider Tooling vendors as defined in EDIP §2.1.46; (g) producing aggregated or de-identified analyses, including the EDIP Community Impact Report under EDIP §2.1.21, where the resulting data does not identify EDIP Participant individually; (h) administering the Institutional Partnership Letter under EDIP §2.1.31 and §14.3, including communication with EDIP Participant's Institutional Host Organization to the extent contemplated by EDIP §12.8; (i) any additional purpose for which EDIP Participant provides separate, specific consent under EDIP §26.0.
• Duration: Term of the EDIP Participation Agreement plus the retention periods set forth at Annex A.2 (per EDIP §17.5).
• Types of Personal Data: Name; contact information (email, phone, address); institutional-role title; Institutional Host Organization identifying information; Track designation (Track 1 or Track 2 under EDIP §7.3); Affidavit-of-Intent records (Schedule A); Institutional Disclosure Letter records (Schedule B); applicable Regulatory Regime designation under EDIP §7.4; EDIP Community participation data; Platform activity data; and operational-consent records under EDIP §26.0. Personal information of EDIP Participant's institutional-host personnel (e.g., EDIP Participant's supervisor's name and contact information) appearing in Schedule B or Institutional Partnership Letter materials is processed under EDIP §17.6 for the limited purpose of administering the institutional partnership.
• Categories of Data Subjects: EDIP Participant (natural person holding a qualifying institutional role under EDIP §7.1); institutional-host personnel whose personal information is incidentally processed under EDIP §17.6 (e.g., the supervisor named in the Institutional Disclosure Letter). No client data subjects are introduced through EDIP-side processing — EDIP Participant has no access to client CRM records per EDIP §17.3, except through the aggregated EDIP Community Impact Report and Re-Up communications under EDIP §8.7, each with contained scope.

A.1.5 Instructor (Instructor Services Agreement)

• Source of authority: ISA §18.2 (Provider's Handling of Instructor Data); ISA §18.6 (Data-Privacy Framework — Companion Document); ISA §18.3 (Client Data Access).
• Subject matter: Administration of Instructor's participation in the Ecosystem under the Instructor Services Agreement, including Expert Database listing, Rate Card administration, Delivery Contract acceptance and performance, Service Delivery Records, settlement processing through Stripe Connect, and Peer Marketplace Feedback.
• Nature of processing: Collection, storage, organization, structuring, use, disclosure to authorized Provider personnel and to third-party infrastructure providers as canonically enumerated at Annex C.1, transmission to Subscribers and Strategists to the extent necessary for Delivery Contract performance, transmission of client-identifying information to Instructor through active Delivery Contracts under ISA §18.3 (with Instructor's reciprocal limitation on use under that section), and erasure or de-identification following termination consistent with ISA §18.5 and §18.6.
• Purposes: (a) administering the Instructor Services Agreement; (b) processing payments through Stripe Connect; (c) maintaining the Expert Database; (d) complying with tax reporting obligations; and (e) sharing with third-party infrastructure providers (cloud hosting, edge compute, AI model hosting, payment processing, and similar Platform-operation infrastructure) to the extent necessary for those providers to provide services to Provider in support of the Platform, as canonically enumerated at Annex C.1.
• Duration: Term of the Instructor Services Agreement plus the retention periods set forth at Annex A.2 (per ISA §18.5).
• Types of Personal Data: Name; contact information; tax documentation (IRS Form W-9 for U.S. persons or W-8BEN/W-8BEN-E for non-U.S. persons); banking information (Stripe Connect Express account details); Expert Database listing information; Rate Card data; Delivery Contract records; Service Delivery Records; settlement data; Peer Marketplace Feedback data; System Activity Metrics; and operational-consent records under ISA §24.3.4. Client-identifying information transmitted to Instructor through active Delivery Contracts under ISA §18.3 is processed under the limited-use restriction set forth in that section.
• Categories of Data Subjects: Instructor (natural person — and, to the extent contemplated by ISA §25.1.2's LLC Assignment Exception, Instructor's wholly-owned and controlled LLC where assignment has occurred consistent with that section); client data subjects whose information is transmitted to Instructor through active Delivery Contracts under ISA §18.3, limited to information necessary for Delivery Contract performance.

Annex A.2 — Per-Tier Retention Table

This Annex A.2 consolidates the per-Counterparty-tier retention rules established in each tier's operative agreement. The retention rules below are descriptions of rules that exist in the operative agreements; this Annex A.2 does not introduce new retention rules. In the event of conflict between this Annex A.2 and the operative-agreement retention provision, the operative-agreement provision controls per Part I §7.2 (Per-tier retention) and Part II §11.4 (Privacy Policy informational role) read together with §11.5 (Annexes — body-controls-default with operative-locus exception).

A.2.1 Common backbone and design intent

All four tiers with locked operative agreements (Client, Referral Agent, EDIP Participant, Instructor) use "life of Agreement (where applicable) plus 7 years" as the baseline, anchored to IRS records-retention timeframes for tax-reporting purposes (Referral Agent, Instructor, Client transaction records), franchise-defense and Regulatory-Regime documentation requirements (EDIP Participant), and grant-program audit requirements (Client grant-funded engagement records). The Client tier is the only enumerated tier with explicit record-type-specific retention periods (transaction / grant-funded / general) reflecting the transactional character of the Client-Provider relationship; the participant tiers (Referral Agent, EDIP Participant, Instructor) use "life of Agreement plus the max of (specific cross-references, 7-year baseline)" reflecting the relational character of those tiers.

A.2.2 Subscriber row reservation

The Subscriber row carries an interim-rule placeholder pending completion of the PSA workstream. The interim rule is operationally accurate as to current Provider Platform operation and is consistent with the pattern across the other four enumerated tiers. The canonical PSA-anchored retention period will replace the interim rule upon PSA lock, at which point the row may be amended through the Part I §11 (Changes to this Policy) procedure to substitute the canonical citation and any tier-specific record-type retention rules introduced by the PSA. The Phase 1 audit §3 observation that no back-amendment cascade is triggered from the present four-tier audit continues to govern.

A.2.3 Visitor and prospective-counterparty retention

Visitor and prospective-counterparty retention is governed by Part I §7.3 (typically up to 24 months for general inquiries and prospective-counterparty contact data, unless a specific tier engagement begins or longer retention is required for legal-compliance purposes) and is not enumerated by tier in this Annex A.2 because no tier-specific operative agreement governs pre-engagement contacts.

A.2.4 Backup-deletion timing

Backup-system data is subject to the standard expiration schedule documented at Annex B per Part II §10.5. Targeted deletion from backup systems where technically impracticable is governed by the operative-agreement provisions (CPA §7.3.4 and parallel architecture across RAA, EDIP, and ISA where applicable).

A.2.5 No new retention rule

This Annex A.2 is descriptive in nature. It consolidates retention rules that exist in the operative agreements and Part I §7 of this Policy; it does not establish any retention rule not already present in those instruments. Any conflict between this Annex and an operative-agreement retention provision resolves in favor of the operative agreement under Part II §11.4 read with §11.5.

Annex B — Technical and Organizational Measures (TOMs)

This Annex describes the technical and organizational measures Provider implements to ensure a level of security appropriate to the risk presented by the processing of Counterparty Personal Data, as required by GDPR Art. 32, the parallel requirements under each other Applicable Data Protection Law, and Provider's operational commitments at Part I §8 and Part II §7.

This Annex is summary-level. It states each measure at the conceptual altitude that is appropriate for a counterparty-facing data-processing disclosure. Operational and audit-level supplemental detail — including specific cryptographic algorithms, key-management cadences, log-retention windows, sub-processor configuration parameters, vulnerability-management metrics, incident-response runbook contents, and personnel-clearance documentation — is available to the Counterparty on request under appropriate confidentiality terms, in the manner contemplated at Part II §7.2. The summary-with-supplemental pattern is the GDPR Art. 32 industry-norm framework for proportionate, audit-defensible disclosure and is designed so that ordinary operational updates to Provider's infrastructure configuration do not trigger an amendment cycle to this Policy.

B.1 Encryption of data in transit

Counterparty Personal Data transmitted between Counterparty endpoints (browsers, mobile applications, API clients) and Provider Platform endpoints is protected by current-generation Transport Layer Security (TLS) configured to industry-current cipher suites and key-exchange algorithms, with older protocol versions and weak cipher suites disabled. Counterparty Personal Data transmitted between Provider Platform components and between Provider and Sub-Processors over public networks is protected by equivalent transport-layer encryption.

B.2 Encryption of data at rest

Counterparty Personal Data stored within Provider Platform systems, including primary databases, object storage, file storage, search indexes, log stores, and backup systems, is encrypted at rest using current-generation symmetric encryption with keys managed under Provider's key-management procedures. Cryptographic keys are stored separately from the encrypted data, are rotated on a documented cadence, and are subject to access controls described at B.3.

B.3 Access control and least privilege

Access to Counterparty Personal Data and to the systems that process Counterparty Personal Data is restricted to Provider personnel and Sub-Processor personnel whose role requires that access for the purposes described at Part I §3 and Part II §2. Access is granted, modified, and revoked through a documented identity-and-access-management process; default-deny is the baseline posture; least-privilege is the design principle; access reviews occur on a documented cadence; and elevated-privilege access is gated by additional approval, scoped to the narrowest set of resources sufficient for the task, and time-bounded where appropriate.

B.4 Authentication and credential security

Provider personnel and Counterparty users authenticate to the Platform through credentials subject to password-strength requirements aligned with current NIST SP 800-63B guidance, multi-factor authentication where reasonably available, and protections against credential-stuffing, brute-force, and session-hijacking attack patterns. Service accounts used for system-to-system authentication use long, randomly generated secrets stored in a managed secret-store with rotation and revocation procedures. Counterparty configuration of Counterparty-side user credentials remains the Counterparty's responsibility per Part II §7.4.

B.5 Audit logging and monitoring

Access to Counterparty Personal Data, administrative actions affecting Provider Platform systems, authentication events, and security-relevant system events are logged with sufficient detail to support incident investigation, regulatory inquiry, and audit. Logs are stored in a manner protected against unauthorized modification, retained for a documented period appropriate to the log type, and subject to monitoring for anomalous patterns. Log access is itself logged and access-controlled.

B.6 Vulnerability management and secure development

Provider maintains a vulnerability-management program covering operating systems, runtime environments, application dependencies, and infrastructure components in scope for processing Counterparty Personal Data. Identified vulnerabilities are evaluated for risk, prioritized, and remediated on a documented cadence proportionate to severity. Provider follows a secure-development-lifecycle approach in the engineering of Platform features, including code review, dependency review, automated and manual security testing appropriate to the change, and pre-release validation of changes affecting the processing of Counterparty Personal Data.

B.7 Network segmentation and perimeter protection

Provider Platform infrastructure is logically segmented to limit the blast radius of an incident affecting any single component, and to restrict network paths to those required by the Platform's functional design. Perimeter protection includes managed denial-of-service mitigation, application-layer attack pattern detection, and rate-limiting appropriate to the API surface. Inbound and outbound traffic flows are restricted by default-deny rules at the network layer.

B.8 Backup, restore, and resilience

Provider maintains backups of Counterparty Personal Data sufficient to support business-continuity and disaster-recovery objectives. Backups are encrypted under §B.2, access-controlled under §B.3, and stored on a schedule designed to support point-in-time restore within the recovery-point objective applicable to the system. Backup integrity is tested on a documented cadence. The restore procedure is exercised periodically to validate operational readiness.

B.9 Backup-expiration timing

Backups of Counterparty Personal Data are retained for a period of up to ninety (90) days from the date the backup was taken (the "Backup Expiration Window"), after which the backup is purged according to the backup system's expiration procedure. Where Counterparty elects deletion of Counterparty Personal Data under Part II §10.2, the deletion takes effect against active Platform systems within the timeframe at Part II §10.3, and against backups by expiration within the Backup Expiration Window. Backup-resident Counterparty Personal Data is not actively used during that window and is subject to the same confidentiality and security obligations as live data, per Part II §10.5.

The ninety-day window is Provider's current operational standard. Counterparties requiring a shorter or differently structured backup-expiration treatment may raise that requirement through the channel specified in the operative agreement, and Provider shall consider it in good faith subject to operational feasibility.

B.10 Incident detection and response

Provider maintains an incident-response capability covering detection, triage, containment, eradication, recovery, and post-incident learning for events that may affect the security of Counterparty Personal Data. Incident-response procedures address coordination with Sub-Processors whose systems may be implicated, preservation of evidence for forensic and regulatory purposes, and the breach-notification pathways at Part II §8 where notification is triggered.

B.11 Personnel security

Provider personnel with access to Counterparty Personal Data are subject to documented confidentiality obligations of an indefinite duration, are vetted to a level appropriate to the access granted, and are subject to access-revocation procedures upon role change or separation. Sub-Processor personnel are bound by equivalent obligations through Provider's contracts with each Sub-Processor under Part II §4.2.

B.12 Security awareness and training

Provider personnel with access to Counterparty Personal Data receive role-appropriate security and data-protection training at onboarding and on a recurring cadence thereafter, with content covering phishing and social-engineering awareness, secure handling of personal data, incident-recognition and reporting, and the obligations applicable to the personnel's role under Applicable Data Protection Law.

B.13 Vendor and Sub-Processor diligence

Provider conducts pre-engagement diligence on each Sub-Processor in scope for processing Counterparty Personal Data, evaluating the Sub-Processor's data-protection posture, security certifications and attestations (such as SOC 2, ISO 27001, or equivalent), data-processing-agreement availability, sub-processor disclosure practices, and data-residency posture. Ongoing oversight includes monitoring of Sub-Processor security advisories and notifications, periodic re-evaluation of high-risk Sub-Processors, and remediation engagement where a Sub-Processor's posture changes in a manner that affects Provider's obligations under this DPA.

B.14 Physical security

Counterparty Personal Data is stored within data-center facilities operated by Provider's infrastructure Sub-Processors (as enumerated at Annex C.1). Those facilities maintain physical security controls — including controlled physical access, environmental controls, and continuous monitoring — under the Sub-Processor's published infrastructure-security commitments and supporting certifications. Provider does not operate self-managed data centers.

B.15 Data segregation and tenancy

Counterparty Personal Data is logically segregated by tenant within Provider's multi-tenant Platform architecture. Access controls and application-layer enforcement prevent one Counterparty's users from accessing another Counterparty's Personal Data through the Platform. Where Counterparty requests a specifically segregated processing environment, Provider may provide that as a chargeable engagement-specific commercial arrangement outside the scope of this Annex.

B.16 Updates to this Annex

This Annex may be updated to reflect Provider's evolving security posture, the addition of new measure categories, the retirement of superseded measure descriptions, and other operational developments, in accordance with Part I §11 and Part II §7.3. No update shall materially diminish the overall level of security applicable to the processing of Counterparty Personal Data. Material updates that affect the Counterparty's risk posture are communicated through the channels established in the operative agreement and reflected in this Annex at the canonical URL.

Annex C.1 — Counterparty-Data Sub-Processor List

This Annex enumerates the Sub-Processors that Provider engages to process Counterparty Personal Data, in accordance with Part II §4. For each Sub-Processor, this Annex identifies the service category, the processing purpose, the categories of Counterparty Personal Data processed, the location or region of processing, the Sub-Processor's data-protection-agreement posture, and any deployment-status note relevant to the Counterparty's evaluation of the entry.

This Annex is operative for the Part II §4 procedural triggers, including the §4.3 thirty-day change-notification requirement and the §4.4 objection right. Counterparties should treat this Annex as the canonical enumeration; the Sub-Processor references that appear in the operative agreements (Client Platform Agreement §7.2.4, Referral Alliance Agreement §16.2(f), EDIP Participation Agreement §17.2, Instructor Services Agreement §18.2, and the Provider Subscriber Agreement when finalized) all designate this Annex as the location at which the canonical roster is maintained.

Provider-internal sub-processors that do not process Counterparty Personal Data — including Provider's payroll processor, Provider's accounting platform, and Provider's general-corporate workspace tooling used for Provider-internal operations — are enumerated separately at Annex C.2 for transparency and are not Sub-Processors within the meaning of Part II §4.

C.1.1 Sub-Processor enumeration

C.1.2 Cross-border-transfer mechanism per Sub-Processor

Where the location of processing for any Sub-Processor enumerated above involves a Restricted Transfer of Counterparty Personal Data from a Counterparty's jurisdiction to the Sub-Processor's processing location, the transfer mechanism is the one identified at Part II §5, including the Standard Contractual Clauses incorporated at Annex D (as adapted for the UK and Switzerland under Part II §§5.4-5.5) and the supplementary measures identified in the transfer impact assessment under Part II §5.6.

C.1.3 Updates to this Annex

This Annex is updated to reflect Sub-Processor additions, replacements, deployment-status changes, and other material changes, in accordance with Part II §4.3. Updates take effect upon the expiration of the §4.3 notification window or, where shorter notice is permitted under §4.3 for urgent need, at the time stated in the notification. The current version of this Annex is the version published at the canonical URL identified in the Part I header.

Annex C.2 — Provider-Internal Sub-Processor List

This Annex enumerates the sub-processors that Provider engages for Provider's own internal operations, including payroll, accounting, internal collaboration, internal AI-assisted work, and analogous Provider-side business functions. The sub-processors listed here process Provider's own data (including Provider personnel employment data) as a function of providing the relevant Provider-internal service; they do not process Counterparty Personal Data within the meaning of Part II §4 and are not Sub-Processors for the purposes of the §4.3 change-notification mechanism or the §4.4 objection right.

This Annex is informational. It is provided for transparency about Provider's processing context as a whole, recognizing that some Counterparties — particularly Counterparties subject to vendor-diligence regimes that require visibility into a vendor's own internal data-processing posture — find the enumeration useful for vendor-assessment purposes. Changes to this Annex do not trigger Part II §4.3 notification or §4.4 objection.

The boundary between Annex C.1 and Annex C.2 is the categorical question of whether the sub-processor handles Counterparty Personal Data. Where a sub-processor begins or expands into a role that involves Counterparty Personal Data — for example, if Provider were in the future to deploy a Provider-internal collaboration tool to a Counterparty-facing workflow — the sub-processor moves to Annex C.1 and becomes subject to Part II §4. Conversely, a sub-processor that ceases to process Counterparty Personal Data moves to this Annex.

C.2.1 Provider-internal sub-processor enumeration

C.2.2 Sub-processors not listed

Other Provider-internal vendors and tools (for example, accounting software, password management, calendaring assistance, or analogous services) are not enumerated here unless and until they process data in a manner that warrants categorization as a sub-processor under the Annex C.1 / Annex C.2 boundary described above. Provider's vendor-diligence program (Annex B §B.13) maintains the operational inventory of Provider's vendor relationships; the entries above are the subset that is meaningful for the data-processing-transparency purpose of this Annex.

C.2.3 Updates to this Annex

This Annex is updated as Provider's internal operating posture evolves. Updates to this Annex do not trigger Part II §4.3 notification or §4.4 objection. The current version is the version published at the canonical URL identified in the Part I header.

Annex D — Standard Contractual Clauses (incorporated by reference)

This Annex D incorporates the Standard Contractual Clauses (the "SCCs") into the Data Processing Addendum (Part II) for purposes of Restricted Transfers governed by Part II §5. The incorporation is by reference; the SCC text is not reproduced in this Annex but is incorporated in full as if set out at length, with the Annexes to the SCCs populated by the corresponding content of this Policy as specified at D.3 below. The framework establishing the population mapping is at Part II §5.3 (SCC implementation specifics); this Annex D consolidates the cross-reference for ease of regulatory inspection and counterparty review.

D.1 SCC frameworks adopted

Provider adopts the following SCC frameworks for the relationship between Provider and the Counterparty, as applicable to the origin jurisdiction of the Restricted Transfer:

• EU SCCs. The Standard Contractual Clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679, adopted by European Commission Implementing Decision (EU) 2021/914 of 4 June 2021 (the "EU SCCs"). The full text of the EU SCCs and their Annexes is incorporated by reference and is available at the source identified at D.9.
• UK Addendum. The International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the United Kingdom Information Commissioner's Office under section 119A of the Data Protection Act 2018 (the "UK Addendum"), in the version that came into force on 21 March 2022 and as updated by the ICO from time to time. The UK Addendum is incorporated by reference and is available at the source identified at D.9.
• Swiss adaptation. The EU SCCs as adapted for transfers from Switzerland under guidance issued by the Swiss Federal Data Protection and Information Commissioner ("FDPIC"), per the FDPIC's statement of 27 August 2021 and subsequent guidance (the "Swiss adaptation"). The Swiss adaptation is applied through the textual modifications identified at D.6.

D.2 Modules applied

The Module of the EU SCCs applicable to a particular processing relationship between Provider and a Counterparty depends on the controller/processor allocation for the processing at issue, as established at Part II §2.7 and per tier at Annex A.1:

• Module Two — Controller-to-Processor — applies by default, where the Counterparty is the Controller and Provider is the Processor with respect to Counterparty Personal Data. This is the default Module for processing on behalf of Clients, Subscribers, EDIP Participants, and (within Instructor-delivered processing of training-participant data) Instructors, in the Counterparty-instructed processing context identified at Part II §2.7.
• Module Three — Processor-to-Processor — applies where the Counterparty is itself acting as a Processor for an upstream Controller (for example, a Subscriber processing Personal Data on behalf of an end-client of the Subscriber that has engaged Subscriber through the Platform), and Provider is engaged as the Counterparty's Sub-Processor in that chain.
• Module One — Controller-to-Controller — applies in the limited circumstances where Provider and a Counterparty jointly determine the purposes and essential means of a particular processing operation such that both Parties are Controllers within the meaning of GDPR Art. 26 for that operation, or where Provider acts as Controller in respect of a transfer to a counterparty acting as Controller in its own right.
• Module Four — Processor-to-Controller — applies in the unusual case where Provider is the Processor and is transferring Personal Data back to the Counterparty acting as Controller in connection with the return-of-data procedure at Part II §10, where such transfer would constitute a Restricted Transfer.

The applicable Module is determined per processing operation. Where multiple Modules apply across different processing operations within a single Counterparty relationship, each Module governs its respective operations.

D.3 Population of SCC Annexes

The Annexes to the EU SCCs (Module-specific) and the corresponding Tables of the UK Addendum are populated by the corresponding content of this Policy as follows. This mapping is the operative interpretation of the SCC Annex contents for purposes of this DPA:

Where the SCCs or the UK Addendum require completion fields not addressed in the cross-referenced sources, the Parties shall complete those fields by good-faith agreement consistent with the regime-specific data-protection framework and Provider's operational posture as described in this Policy.

D.4 Optional clauses and selections

The selections for the optional clauses of the EU SCCs, established in detail at Part II §5.3, are consolidated here for reference:

• Clause 7 (Docking Clause) is included. Additional entities may join the SCCs upon mutual agreement.
• Clause 9 (Sub-Processors), Option 2 (General Written Authorization), applies. The change-notification period is as specified at Part II §4.3.
• Clause 11 (Redress) optional independent-resolution mechanism is not adopted.
• Clause 17 (Governing Law) is the law of the EU Member State or country of the data exporter where the SCCs require Member-State law; otherwise the law of Ireland.
• Clause 18 (Choice of Forum and Jurisdiction) is the courts of the EU Member State or country of the data exporter as the SCCs require; otherwise the courts of Ireland.

D.5 UK transfers

For Restricted Transfers originating in the United Kingdom, the UK Addendum to the EU SCCs applies. Part 1 (Tables) of the UK Addendum is populated by the same sources mapped at D.3, with Table 1 (Parties) drawn from Part I §12.1 and the operative-agreement signature block, Table 2 (Selected SCCs, Modules, and Selected Clauses) reflecting the Module selection at D.2 and the optional-clause selections at D.4, Table 3 (Appendix Information) drawn from Part II §2 and Annex A.1 / B / C.1, and Table 4 (Ending This Addendum When the Approved Addendum Changes) left at the default (the Parties accept ICO-issued revisions per the UK Addendum's standard mechanism). Part 2 (Mandatory Clauses) of the UK Addendum applies without modification.

In lieu of the EU SCCs plus UK Addendum approach, the Parties may agree by written instrument to use the UK International Data Transfer Agreement ("UK IDTA") as the standalone transfer mechanism for UK-origin Restricted Transfers. Absent such written election, the EU SCCs plus UK Addendum approach is the default.

D.6 Swiss transfers

For Restricted Transfers originating in Switzerland, the EU SCCs apply as adapted under FDPIC guidance, with the following textual modifications consistent with Part II §5.5:

• Regulatory references. References in the EU SCCs to "Regulation (EU) 2016/679" or the "GDPR" are read, where appropriate, as references to the Swiss Federal Act on Data Protection of 25 September 2020 (the "FADP") and the Ordinance on Data Protection.
• Member State references. References to "EU Member State" or to "Member State law" are read, where appropriate, as references to Switzerland and to Swiss law.
• Competent Supervisory Authority. The competent Supervisory Authority for Swiss-origin Restricted Transfers is the FDPIC, as identified at Part I §13.5 and §12.4.
• Data Subject coverage. Where the FADP affords protection to legal persons in respect of certain data-protection rights, the SCCs are applied to the relevant Data Subjects coextensively, consistent with FDPIC guidance.

D.7 Order of precedence

The order of precedence governing conflicts between the SCCs (as incorporated by this Annex D), this DPA, the operative agreement, the Privacy Policy (Part I), and Applicable Data Protection Law is established at Part II §11. In particular, per Part II §11.2, the SCCs control over this DPA to the extent of any conflict on a matter within the SCCs' subject-matter scope. Per Part II §11.3, Applicable Data Protection Law (including any updated regulatory instrument that supersedes or amends an SCC framework) controls over the SCCs to the extent of any conflict.

D.8 Effective date and updates

The SCCs incorporated by this Annex D take effect for a given Counterparty on the later of (a) the effective date of this Policy as identified in the Part I header, (b) the date of execution of the operative agreement applicable to the Counterparty, or (c) the date on which a Restricted Transfer subject to the SCCs first occurs in the Counterparty relationship.

Where the European Commission, the United Kingdom Information Commissioner's Office, the Swiss FDPIC, or another competent authority replaces, amends, or supersedes any of the SCC frameworks incorporated by this Annex D, Provider shall update this Annex per the amendment procedure at Part I §11 to reflect the replacement framework, with a transition period appropriate to the underlying regulatory change and consistent with the implementation timeline established by the competent authority. Pending such update, this Annex is interpreted to incorporate the then-current version of each SCC framework consistent with the applicable regulatory transition rules.

D.9 Source documents

The full text of each SCC framework incorporated by this Annex D is published by the issuing authority and is available at the following sources. The URLs are identified for reader convenience; the authoritative source is the issuing authority's then-current publication, which controls in case of any discrepancy between the URL content at a given moment and the issuing authority's official version:

• EU SCCs (Commission Implementing Decision (EU) 2021/914): eur-lex.europa.eu/eli/dec_impl/2021/914/oj, with current operational guidance maintained by the European Commission at commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en.
• UK Addendum to the EU SCCs: ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/.
• UK IDTA: Same ICO source as the UK Addendum above.
• Swiss FDPIC guidance: edoeb.admin.ch, FDPIC statement of 27 August 2021 and subsequent guidance.

A Counterparty may request a printable consolidated copy of the SCC text as adopted by this Annex by contacting Provider at Part I §12.1.

D.10 Counterparty signature and execution

Execution of the operative agreement applicable to the Counterparty constitutes the Counterparty's execution of the SCCs as incorporated by this Annex D, consistent with the incorporation-by-reference approach established at Part II §5.2 and §5.3. No separate signature on the SCC text is required for the SCCs to be effective between Provider and the Counterparty. Where a Counterparty's local regulator requires a separately executed counterpart of the SCCs for record purposes, Provider shall furnish a printable, separately executable counterpart on request under the channel at Part I §12.1.

Annex E — Glossary

This Annex E is a navigation aid. It enumerates, in alphabetical order, the principal defined terms used in this Policy and identifies the section in which each term is defined. The defining section is the source of authority for the term's meaning; this Annex does not restate the operative definitions, to avoid drift between the defining section and a separate restatement. Where a term carries one meaning in Part I and a different (or more specific) meaning in Part II, the Part II definition controls within the Data Processing Addendum context and the Part I definition controls within the Privacy Policy context, per the precedence framework at Part II §11.

This glossary is non-exhaustive. Defined terms that are used only within a single section of Part I or Part II are defined inline at that section and are not enumerated here. Regime-specific defined terms that operate only within a single subsection of Part I §13 are listed at E.2 below for navigation but are defined inline at the regime-specific subsection.

E.1 Glossary entries

E.2 Regime-specific defined terms (cross-reference)

The following regime-specific defined terms operate within a single subsection of Part I §13 and are defined inline at that subsection by reference to the applicable statute or regulation; they are listed here for navigation:

• California (CCPA/CPRA). "Business," "consumer," "personal information," "sale," "share," "sensitive personal information," "service provider," "contractor" — Part I §13.3, by reference to Cal. Civ. Code §1798.140.
• Quebec (Law 25). "Person responsible for the protection of personal information," "confidentiality incident," "person carrying on an enterprise" — Part I §13.4, by reference to the Quebec Act respecting the protection of personal information in the private sector as amended by Law 25.
• Switzerland (FADP). "Controller," "processor," "high-risk profiling," "automated individual decision" under the FADP — Part I §13.5, by reference to FADP Art. 5(j), Art. 5(k), Art. 5(f), and Art. 21.
• United Kingdom (UK GDPR + DPA 2018). "Personal data," "controller," "processor" under the UK GDPR — Part I §13.2, by reference to UK GDPR Art. 4 and the Data Protection Act 2018.
• Other regimes (Part I §13.6). Regime-specific defined terms operating under PIPEDA, the Brazilian LGPD, the Australian Privacy Act / APPs, or another comprehensive data-protection regime enumerated at Part I §13.6 are read by reference to the applicable statute.

E.3 Updates to this Glossary

This Annex E is updated when defined terms are added, removed, or relocated in Part I or Part II, or when a new regime-specific subsection in Part I §13 introduces defined terms appropriate for cross-reference here. Updates to this Annex are governed by the amendment procedure at Part I §11; mere relocation of an existing entry or correction of a section-pointer is a non-material clarification not requiring §11 notification.

End of Privacy Policy and Data Processing Addendum LOCKED V1.0. See Status block at file head for full Phase 0–4 build narrative. LOCKED V1.0 2026-05-25; effective date June 15, 2026 aligned with Provider's minimum-viable website launch supporting the Policy at the canonical URL.