Expert Grant Ecosystem LLC
Version 1.21
Effective Date: June 1, 2026
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)
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.
Provider also operates the Owners Unscripted™ media brand, which encompasses the Owners Unscripted™ podcast, Owners Unscripted™ Meet Up 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 that arises solely from a person's interaction with the Owners Unscripted media brand as a member of its audience (for example, podcast listeners, event registrants, mailing-list subscribers, and social-media audiences). A separate privacy notice for those media-brand audience interactions is published at ownersunscripted.com/legal/privacy (the "Owners Unscripted Privacy Notice") and governs that audience-interaction processing context. Where a person holds a unified login used across the Owners Unscripted and Expert Grant Ecosystem platforms, the login identity spans both properties, but content does not follow it across the boundary: this Policy governs Platform-side processing, the Owners Unscripted Privacy Notice governs media-brand audience-side processing, and neither property's content is combined into the other's context except as an operative agreement expressly provides. This carve-out does not displace this Policy for any person who enters into an operative agreement with Provider in connection with the Owners Unscripted media brand — for example, Owners Unscripted Participants and Guests — whose personal data Provider processes through Platform infrastructure such as intake forms, CRM records, scheduling, or contract execution; for that processing this Policy continues to govern, subject to the order-of-precedence terms of the operative agreement per §1.3 and Part II §11. If your interaction with us is solely as a member of the Owners Unscripted audience and not as a Platform participant or counterparty, please consult the Owners Unscripted Privacy Notice at ownersunscripted.com/legal/privacy; see also §12.2.
This Policy describes how we collect, use, share, retain, and protect personal information of the following persons in connection with the Platform:
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.
This Policy is published at the canonical URL listed in the header above. Counterparties also receive routing references through their respective operative agreements:
| Tier | Operative anchor | Routing mechanism |
|---|---|---|
| Client | CPA §7.2.5 | Provider's published legal disclosures (at expertgrants.com) |
| Subscriber (Strategist) | PSA §4.9.4 (Data-Privacy Framework — Companion Document) | Provider's published legal disclosures (at expertgrants.com) and the Strategist-tier Portal |
| Referral Agent | RAA §16.4 | Referral Portal |
| EDIP Participant | EDIP §17.4 | Referral Portal |
| Instructor | ISA §18.6 | Provider's published legal disclosures (at expertgrants.com) |
| Visitors | This Policy | expertgrants.com (public) |
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.
This Policy is identified by the version number and effective date shown in the header. Material changes are governed by §11.
Provider's Platform operates through a Beta Launch build-out period from its initial cohort engagement (the "Beta phase," which comprises the sequential Beta Launch phases set forth in the Platform Build-Out Transition Protocol and is not a single flat phase) until Provider's transition to general MVP availability (the "MVP transition"), as established under Provider's Beta Tier Phase architecture. As used in this Policy, the defined term "Beta phase" denotes that build-out period as a whole for personal-information-processing purposes only, and carries no representation about rate levels or financial terms, which are governed by the operative agreement and its Exhibits. Personal-information processing during the Beta phase reflects three operational realities that Beta-cohort counterparties should understand at the outset of engagement:
The Beta-cohort acknowledgment in this §1.7 modulates how Beta-cohort counterparties should read the rest of this Policy: the §11 Versioning mechanism (and the Part II §4.3 sub-processor change-notification mechanism) is more frequently exercised during the Beta phase than is expected during MVP operation, and Beta-cohort counterparties should anticipate periodic Annex updates as Provider's operational posture matures. Counterparties who are not part of the Beta cohort (including counterparties whose engagement commences after the MVP transition) read this Policy without the modulations described in this §1.7.
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.
Information provided in connection with creating, maintaining, and authenticating Platform or Portal access:
Information generated by counterparty engagement and Platform commerce activity:
Information provided in the course of Platform use:
Information generated automatically by use of the Platform, Portal, and public websites:
Information exchanged outside the Platform:
Additional information collected from specific tiers in connection with their operative engagement:
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).
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.
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).
To create, manage, secure, and terminate counterparty accounts; to authenticate access; to enforce Platform policies.
To process Client payments; to process Subscriber, Referral Agent, and Instructor payouts; to collect, remit, and report sales, use, and marketplace-facilitator taxes that Provider collects in its capacity as marketplace facilitator per the Platform Tax Schedule, and to intake and validate tax-exemption certificates asserted by Clients or institutional payors; to comply with tax-reporting obligations (1099 reporting; international payroll-equivalent reporting where applicable); to retain transaction records per regulatory requirements.
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.
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).
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.
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).
To verify, through a consumer reporting agency, a Counterparty's eligibility to participate as an independent contractor where an operative agreement conditions participation on a background check (currently the Instructor tier per Instructor Services Agreement §3.7 / §3.7.1, and available to the Subscriber/Strategist tier under the Access-Phase qualification architecture). The verification supports counterparty and grant-administrator confidence in the qualification and trustworthiness of ecosystem participants and is run through the background-screening sub-processor enumerated at Annex C.1. Provider runs the full FCRA choreography regardless of the independent-contractor classification — standalone disclosure, separate written authorization, and the vendor-managed two-step adverse action — and the verification cost is borne by the Counterparty as an at-cost, zero-margin pass-through (Provider remits the cost in full to the sub-processor and retains nothing).
To record and review the access of Provider personnel (administrative operators and coordination personnel) to counterparty engagement records, so that such access is attributable, proportionate to the operator's role, and auditable. This access-oversight record (the "operator access log") supports the identity-wall and role-partition commitments described in the operative agreements (for Clients, CPA §6.3.2.1 and §6.5.5), supports dispute resolution and security, and, where Provider makes elements of the record available to a Client as a transparency measure, supports the Client's visibility into who has accessed their engagement. Provider also maintains a decision-trail record for Provider-operated funder-information tools (the "funder-screening trail"), which records the objective, documented criteria and exclusion reasons applied when a set of funders is narrowed, so that such narrowing remains information-based and not a recommendation, ranking, or selection (CPA §6.5.2.1 and §6.5.6).
To host the Platform's community features — including strategist-run coaching groups, discussion groups, and community learning groups — by storing and delivering the content members share into group-visible community spaces and by transmitting and storing member-to-member direct messages. This purpose operates under the two-part access boundary disclosed in the operative agreements (for Clients, CPA §3.4.4):
Direct-message content is not processed for any secondary purpose: it is not used for analytics, profiling, advertising, or AI model training, and no community or group content is used for automated decision-making producing legal or similarly significant effects. As of this version, the community data store is in design and is not yet processing personal information under this purpose; activation will be reflected consistent with §11 and, for any sub-processor service-scope change, the Part II §4.3 change-notification mechanism prior to first processing.
To prepare participant-contributed session media (video recordings of professional delivery sessions and standalone professional content uploaded through Provider's Contribution Portal) for the destinations its uploader has permitted, by: generating transcripts; screening transcript, audio, and sampled video frames against Provider's published Redaction Standard (an objective checklist covering identifiers, financial account details, credentials, health information, named third parties, engagement-flagged items, sensitive personal attributes, on-screen and in-frame content, and third-party or commercially sensitive material); producing redacted cuts by excision, audio muting, transcript redaction, or fixed-region visual occlusion; performing human review and quality assurance of placement-bound cuts; screening marketing candidates for compliance (including role-conditional review in which a human reviewer records only the speaker's role — never a stored identity assertion); and maintaining the flag, decision, and consent records that evidence performance of the published process. Provider performs all editing; no participant edits content. This purpose operates alongside the notice-and-consent mechanics disclosed in the operative agreements (for Clients, CPA §12.1 — including the seven-day placement notice windows, the mid-session pause right, per-quotation affirmative approval, and ongoing profile- and listing-placement removal on request).
As of this version, the Contribution Portal redaction pipeline is in design and is not yet processing personal information under this purpose; activation will be reflected consistent with §11. The pipeline operates entirely on sub-processors already disclosed in Annex C.1 — Cloudflare infrastructure (including Stream media storage and caption generation, and rendering jobs on Cloudflare Containers instances operated by Provider) and Anthropic screening passes, with Cloudflare Workers AI as the designated fallback transcription path — so no new sub-processor accompanies this purpose; any future substitution would follow the Part II §4.3 change-notification mechanism.
To operate the social content programs described in the operative agreements, under which Provider authors and schedules social media posts ("Curated Posts") and distributes them to social media accounts that a participating Counterparty has connected for that purpose (for Subscribers (Strategists), PSA §1.5.94, §1.5.175, and §5.3.3; for Referral Agents, RAA §3.5, Tier 1 content only). Processing under this purpose comprises: maintaining each participant's separate, isolated distribution profile within the Social Distribution Service (the headless, API-first distribution infrastructure described at PSA §1.5.175 and at Annex C.1.6, which participants do not see, log into, or interact with directly); recording the participant's connected accounts (up to the operative cap of five simultaneous accounts) through scoped, revocable account-connection authorizations granted by the participant in the participant's own social media accounts (Provider never collects, transmits, or stores the participant's social media passwords); maintaining the scheduling, distribution, and participant review and opt-out records associated with the program, surfaced to the participant through Provider's own Platform dashboard; and executing the offboarding lifecycle the operative agreements promise, strictly by event class and never as an undifferentiated whole: cancellation of scheduled posts (or, during suspensions, pause and resumption where the Social Distribution Service supports it); deactivation of the Social Engagement Concierge where active; and suspension, conversion, or automatic restoration of the distribution profile as the applicable event class directs. The offboarding lifecycle includes no deletion of published Curated Posts and no submission of deletion requests: Provider performs no deletion of published Curated Posts from participants' accounts on any exit path. Published Curated Posts follow the operative agreements' keep-by-default regime: on any exit other than a for-cause termination they remain on the participant's own connected accounts under the participant's control; the participant may delete any post at any time; on a termination for cause the operative agreements require the participant to remove published Curated Posts within five (5) business days of Provider's written notice, with removal performed by the participant, never by Provider; Provider undertakes no monitoring obligation as to kept posts; and Provider's technical ability to process a participant's kept posts ends at account disconnection.
As of this version, the Social Distribution Service is not yet provisioned, its vendor has not been selected (see Annex C.1.6), and no personal information is being processed under this purpose. Activation will be reflected consistent with §11 and, as to the sub-processor roster, through the Annex C.1.6 mechanics (including the Part II §4.3 thirty-day change-notification where a third-party vendor is engaged).
To maintain the Certification Registry the operative agreements establish (PSA §2.11.10) as the authoritative record of every credential issued under them, each entry recording the participant's name and Platform identifier, the credential name and tier, the Certification Program or assessment completed, the unique Certificate Identification Number, the issuance date, the per-credential status with its applicable status-change date, and, for Subscribers at Access Phase 3 only, the participant's independent business name; and, where Provider establishes the credential-verification mechanism the operative agreements describe (PSA §2.11.10.1.4; for the client-facing surface, CPA §2.7), to enable a third party to confirm a participant's certification status by reference to the Certificate Identification Number. Any public verification or lookup surface displays status only, recorded per credential (Active; Certified (Seat Inactive); Lapsed (applicable to Tier 2 verifications); Inactive (Exited); or Revoked, with the applicable status-change date), and discloses no narrative of reason, cause, or circumstance for any status.
Registry entries are retained indefinitely under the operative agreement's own registry retention rule (PSA §2.11.10.1.5) for evidentiary and regulatory-defense purposes; Annex A.2.10 describes that rule. As of this version, no public verification or lookup surface has been established; activation of any such surface will be reflected consistent with §11.
To maintain the Transfer Registry the operative agreements establish (PSA §5.7): a segregated, record-only census store in which a Subscriber (Strategist) may register the Subscriber's own pre-existing client relationships, at intake or during the one-time retroactive window the operative agreement opens for a Subscriber already in the field when the registry architecture first binds that Subscriber (PSA §5.7.2). Processing under this purpose comprises: recording each registration as submitted by the registering Subscriber (the censused client's identity; money-class evidence of the pre-existing relationship in the operative agreement's enumerated evidence classes, PSA §5.7.2.3; the Subscriber's per-client election of transfer or keep-out; and the Subscriber's signed attestation of the relationship's bona fides on the Platform's standard attestation instrument); adjudicating each registration on a read-only basis against Provider's existing Platform records (customer-relationship-management presence, recorded data contact events within the evaluation period the operative agreement states, current Lead Lock and attribution state, and first-in-time ordering, per PSA §5.7.3); and maintaining the resulting adjudication outcomes, Transfer Flag states and endings, and keep-out evidence records through the flag lifecycle the operative agreement defines (PSA §5.7.4 and §5.7.5).
Censused clients are a distinct, non-user data-subject category. A censused pre-existing client is not a Platform user, holds no Platform account, and is not a counterparty to any operative agreement; the censused client's identity and relationship evidence arrive from the registering Subscriber, not from the censused client. Because that is so, this purpose operates under an express purpose limitation, stated in the operative agreement (PSA §5.7.1) and restated here as a commitment of this Policy: the Transfer Registry never synchronizes to any customer-relationship-management or outreach-capable system; no outreach, marketing, solicitation, advertising, or profiling use of Transfer Registry data is permitted for any purpose at any time; adjudication access is read-only; and Transfer Registry records are used solely to adjudicate, evidence, and administer the registration, flag, and flag-ending states the operative agreement defines, and to resolve disputes about them. Provider never contacts a censused client under this purpose. If a censused client ever deals with Provider, that engagement arises only through the client's own independent choice (the operative agreement's natural-entry rule, PSA §5.7.3.5) and is then governed by the tier agreement the client executes and the disclosures applicable to that tier.
As of this version, the Transfer Registry has not been provisioned and no personal information is being processed under this purpose; the registry architecture is in its contract-rollout period and the registry data store is in design. Activation will be reflected consistent with §11. The registry is designed to operate on Provider-controlled Platform infrastructure already enumerated at Annex C.1, so no new sub-processor accompanies this purpose; any future change to that posture would follow the Part II §4.3 change-notification mechanism prior to first processing. Retention is described at Annex A.2.11.
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.
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.
To third-party infrastructure providers (including cloud hosting, edge compute, managed database and object storage, AI model hosting, payment processing, e-signature, programmable SMS and voice communications, email and calendar integration, media recording, AI meeting notetaking and transcription, video streaming delivery, social-media content distribution, 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).
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.
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; and a community Host receives — and on exit may export — the member relationship records of the Host's own community space (member names, contact information, and participation records), for which the Host is independently responsible under the Host's own agreement (for members, CPA §3.4.5). These disclosures are governed by the relevant operative agreement(s) and by the consent mechanisms each agreement establishes.
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.
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.
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.
For any other purpose disclosed to you and to which you consent, or at your direction.
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.
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. Tax-exemption-certificate information and marketplace-facilitator tax records are processed in the United States (the payment processor's US region per Annex C.1 #6; the structured tax-records store per Annex C.1 #2), within the processing-location posture described in this Section; no additional cross-border transfer mechanism is introduced for this data.
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:
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.
You may request a copy of the relevant transfer mechanism documentation and the transfer impact assessment summary by contacting us as described in §12.
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.
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.
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.
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.
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.
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.
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:
| Tier | Governing operative section |
|---|---|
| Client | CPA §7.6 (Data Retention) |
| Subscriber (Strategist) | PSA §4.9.3 (Retention of Subscriber Personal Information) |
| Referral Agent | RAA §16.5 (Retention of Referral Agent Personal Information) |
| EDIP Participant | EDIP §17.5 (Retention of EDIP Personal Information) |
| Instructor | ISA §18.5 (Retention of Instructor Personal Information) |
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.
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.
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.
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.
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.
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.
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.
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.
We use cookies, similar tracking technologies, and analytics SDKs on our public websites, the Platform, and the Portal in four functional categories:
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.
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.
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.
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.
For material changes that affect your rights or our processing of your personal information:
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.
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.
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.
If your inquiry concerns the Owners Unscripted™ media brand (podcast, Meet Up events, Online events) solely in your capacity as a member of its audience rather than as a Platform participant or counterparty, please consult the Owners Unscripted Privacy Notice published at ownersunscripted.com/legal/privacy. The Owners Unscripted Privacy Notice identifies its own contact channel; you may also direct media-brand audience privacy inquiries to the email above and indicate that the inquiry concerns Owners Unscripted. If you are an Owners Unscripted Participant or Guest who has entered into an agreement with Provider, the privacy rights and contact channels in this Policy apply to Provider's processing of your personal data through Platform infrastructure, as described in §1.2.
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.
You may contact the supervisory authority in your jurisdiction:
edpb.europa.eu.ico.org.uk.cppa.ca.gov or the Office of the Attorney General at oag.ca.gov.cai.gouv.qc.ca.edoeb.admin.ch.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.
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.
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.
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):
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:
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.
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.
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.
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:
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.
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 Platform Services 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.
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.
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.
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 (Platform Services 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).
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.
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.
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.
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.
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.
The controller/processor allocation differs by processing context. For Provider's own platform-operation, account-administration, communications, payment, analytics, compliance, vendor-management, background-verification, access-oversight, and community-safety activities (the purposes described in Part I §§3.1–3.9 and the safety, moderation, and integrity processing described in Part I §3.10), 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, and community and group content the Counterparty shares or exchanges through the community features described in Part I §3.10 — group-visible content and end-to-end-encrypted direct-message ciphertext, which Provider stores and transmits but cannot read); 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.
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.
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.
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.
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.
Provider's engagement of Sub-Processors is governed by §4 of this DPA.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
To the extent the Standard Contractual Clauses apply between Provider and the Counterparty:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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, PSA §4.9.3). 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.
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.
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.
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 Platform Services Agreement, Referral Alliance Agreement, EDIP Participation Agreement, and Instructor Services Agreement), applied across the document ecosystem.
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.
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.
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.
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.
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).
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:
| Tier | Operative provision establishing cross-reference and hybrid precedence |
|---|---|
| Client | Client Platform Agreement §7.2.5 |
| Subscriber (Strategist) | Platform Services Agreement §4.9.4 |
| Referral Agent | Referral Alliance Agreement §16.4 |
| EDIP Participant | EDIP Participation Agreement §17.4 |
| Instructor | Instructor Services Agreement §18.6 |
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.
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.
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 A.1, A.2, B, C.1, C.2, D, and E are all set out below. Annex A states per-tier subject matter, nature, purpose, and data categories; Annex B states the technical and organizational measures; Annexes C.1 and C.2 list the sub-processors; Annex D incorporates the Standard Contractual Clauses by reference; and Annex E is the glossary.
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.
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).
| Tier | Source provision | Retention period | Exceptions / supplements | Disposition at end of period |
|---|---|---|---|---|
| Client (Client Platform Agreement) | CPA §7.6 (Data Retention); CPA §7.7.4 (Employee Data Retention) | (a) Transaction records: 7 years from transaction date; (b) Grant-funded engagement records: per applicable grant program's audit requirements (typically 3–7 years from engagement close-out); (c) General engagement records: 3 years from CPA termination or close-out of the last active Strategist Engagement Agreement or Strategist Project-Rate Agreement, whichever is later. Employee data under §7.7 (training-participant attendance records) retained for the same periods applicable to the underlying engagement (§7.7.4). | Post-termination retention is for compliance, legal, and audit purposes only; no reprocessing for marketing or commercial purposes (CPA §7.6.2). Additional retention exceptions under CPA §7.3.3: (i) tax reporting and financial recordkeeping required by applicable law; (ii) active legal proceedings, regulatory investigations, or legal holds; (iii) Agreement enforcement; (iv) anonymized or aggregated data that no longer identifies Client. | Deletion or anonymization from active Platform systems upon expiration; backup-system data subject to standard expiration per backup retention schedule (CPA §7.3.4); backup expiration timing documented at Annex B per Part II §10.5. |
| Subscriber (Platform Services Agreement) | PSA §4.9.3 (Retention of Subscriber Personal Information) | Life of Agreement plus the longer of (a) the survival periods specified for record-specific retention obligations under the Platform Services Agreement, or (b) 7 years following termination, covering the longest-applicable IRS records-retention period for tax-reporting purposes, consistent with the operational pattern across the other enumerated tiers. | Exceptions parallel the CPA §7.3.3 framework: tax reporting; active legal proceedings or legal holds; Agreement enforcement; anonymized or aggregated data. | Deletion or de-identification from active Platform systems upon expiration; backup-system data subject to standard expiration per backup retention schedule. |
| Referral Agent (Referral Alliance Agreement) | RAA §16.5 (Retention of Referral Agent Personal Information) | Life of Agreement plus the longer of (a) the survival periods specified for record-specific retention obligations under RAA §3.5.12 (Audit Trail and Operational Logging), §4.12 (Records Retention), §7.6.3 (Records and Verification), and §22.3.4 (Operational Consent Mechanism); or (b) 7 years following termination, covering the longest-applicable IRS records-retention period for tax-reporting purposes. | Personal information not subject to a specific record-type retention obligation enumerated above may be deleted or de-identified following termination consistent with RAA §16.4 and applicable law in the jurisdictions in which Provider operates. | Deletion or de-identification from active Platform systems upon expiration of the longer of the applicable record-specific obligation and the 7-year IRS-tax baseline. |
| EDIP Participant (EDIP Participation Agreement) | EDIP §17.5 (Retention of EDIP Participant Personal Information) | Life of Agreement plus the longer of (a) the survival periods specified for record-specific retention obligations under EDIP §4.12 (Records Retention), §12.0 (Institutional Disclosure Obligation), and §26.0 (consent-record retention); or (b) 7 years following termination, supporting post-termination Affidavit-of-Intent records, institutional-disclosure records, audit trail, and franchise-defense documentation. The 7-year baseline is shorter than the RAA/ISA baseline to the extent EDIP Participation does not generate compensation-tax records but is consistent with broader franchise-defense and Regulatory-Regime documentation needs. | Personal information not subject to a specific record-type retention obligation enumerated above may be deleted or de-identified following termination consistent with EDIP §17.4 and applicable law in the jurisdictions in which Provider operates. Institutional-host personnel personal information processed under EDIP §17.6 follows the same disposition mechanics as EDIP Participant personal information. | Deletion or de-identification from active Platform systems upon expiration of the longer of the applicable record-specific obligation and the 7-year franchise-defense baseline. |
| Instructor (Instructor Services Agreement) | ISA §18.5 (Retention of Instructor Personal Information) | Life of Agreement plus the longer of (a) the survival period specified for the consent-record retention obligation under ISA §24.3.4 (Operational Consent Mechanism); or (b) 7 years following termination, covering the longest-applicable IRS records-retention period for tax-reporting purposes. | Personal information not subject to a specific record-type retention obligation enumerated above may be deleted or de-identified following termination consistent with ISA §18.6 and applicable law in the jurisdictions in which Provider operates. | Deletion or de-identification from active Platform systems upon expiration of the longer of the applicable consent-record retention obligation and the 7-year IRS-tax baseline. |
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.
The Subscriber row is anchored to PSA §4.9.3 (Retention of Subscriber Personal Information), added to the Platform Services Agreement on 2026-05-31 (PSA composite V1.6). The retention rule is consistent with the pattern across the other enumerated tiers: life of Agreement plus the longer of record-specific retention obligations or the 7-year IRS baseline. Consistent with the rest of this Annex A.2, this row describes the rule established in the operative agreement; it does not introduce it.
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.
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).
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.
The operator access log and the funder-screening trail described in Part I §3.9 are operational integrity and accountability records rather than a separate counterparty tier. They are retained for the period of the underlying engagement and the §7.1 / Part II §10.4 legal, audit, and dispute-resolution retention exception, consistent with the access-oversight and accountability purpose for which they are kept; they ride the existing per-tier engagement retention and are not a new tier-level retention rule. This subsection describes the rule; it does not introduce a new one. Disposition follows the same deletion-or-de-identification mechanics as the underlying tier's engagement records.
Community and group content described in Part I §3.10 (group-visible content and end-to-end-encrypted member direct-message ciphertext) is not a separate counterparty tier and carries no new tier-level retention rule. Its lifecycle follows the operative-agreement community provisions (for Clients, CPA §3.4.6): member-authored group-visible content and member-associated direct-message ciphertext are deleted on group exit, account deletion, or verified deletion request within the operative agreement's deletion timeframe (for Clients, CPA §7.3.1); a closed community space's group-visible content is deleted no later than ninety (90) days after closure — closure meaning dissolution or conversion to a read-only mode that ends interactive community features, not a transfer to a successor Host, and purchased digital-product libraries instead remain available for their purchased access terms. Business and relationship records associated with community participation (including group-membership facts) ride the existing per-tier engagement retention. This subsection describes rules established in the operative agreements; it does not introduce a new one. Direct-message ciphertext is, in all cases, content Provider cannot read; its retention confers no Provider access to message content.
Contribution session media and its preparation records described in Part I §3.11 are not a separate counterparty tier and carry no new tier-level retention rule, with one media-specific lifecycle fact: the raw source recording is retained ninety (90) days after the conclusion of the upload's preparation lifecycle (publication of its last placement-bound redacted cut or, where no placement publishes, completion of the upload's processing) and is then expired from media storage per the published Redaction Standard. Redacted cuts follow the lifecycle of the destination that carries them, including the operative agreements' decline, removal, and withdrawal mechanics (for Clients, CPA §12.1.10–§12.1.11). The flag, decision, role-review, consent, and quality-assurance records ride the existing per-tier engagement retention and the §7.1 / Part II §10.4 legal, audit, and dispute-resolution retention exception, as the audit evidence of the Redaction Standard's process-performance warranty. This subsection describes rules established in the operative agreements and the published Redaction Standard; it does not introduce a new one.
The social content program records described in Part I §2.3 and §3.12 are not a separate counterparty tier and carry no new tier-level retention rule. Scheduling, distribution, and review and opt-out records ride the existing per-tier engagement retention; on the Referral Agent side the program's operational logs are RAA §3.5.12 Audit Trail records within the record-specific retention obligations the Referral Agent row above already enumerates. Provider performs no deletion of published Curated Posts and submits no deletion requests on any exit path, so no deletion-request submission logs arise under this purpose. Published Curated Posts a participant keeps after exit reside on the participant's own social media accounts and are outside Provider retention entirely; Provider's technical ability to process them ends at account disconnection. This subsection describes rules established in the operative agreements; it does not introduce a new one.
Certification Registry entries described in Part I §3.13 are retained indefinitely under the operative agreement's own registry retention rule (PSA §2.11.10.1.5), including entries whose per-credential status is Certified (Seat Inactive), Lapsed, Inactive (Exited), or Revoked, for evidentiary and regulatory-defense purposes. The indefinite retention attaches to the registry entry itself (the credential record and its status history); it does not extend the retention of the underlying tier engagement records, which follow the per-tier rules in the table above. This subsection describes a rule established in the operative agreement; it does not introduce a new one.
Transfer Registry census records described in Part I §3.14 (the censused client's identity, money-class relationship evidence, the registering Subscriber's election and signed attestation, and the adjudication, flag-state, flag-ending, and keep-out evidence records) are not a separate counterparty tier and carry no new tier-level retention rule. The records arrive on the Subscriber tier and ride the Subscriber row above (PSA §4.9.3). Their operational life is defined by the flag lifecycle and its endings (PSA §5.7.4 and §5.7.5, including ending states with continuing defined-period effects, such as the twelve (12) month Lead Lock ineligibility following a taking by the client's own transferor and the window-bounded deemed-conversion leg following a taking by a third party) together with the Referral Protection Window administration, review, and dispute machinery of the operative agreement (PSA §5.6.7 and §5.6.12); thereafter the records ride the Subscriber-tier engagement retention and the Part I §7.1 / Part II §10.4 legal, audit, and dispute-resolution retention exception, as the evidence of registrations, adjudications, flag states, and any disputes about them. The record-only, never-outreach purpose limitation of Part I §3.14 applies for the full retention life of the records: retention confers no outreach, marketing, solicitation, or contact use at any time. This subsection describes rules established in the operative agreements; it does not introduce a new one.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 Platform Services Agreement §4.9.2) 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.
| # | Sub-Processor | Service category | Processing purpose | Categories of Counterparty Personal Data processed | Location / region of processing | Data-protection-agreement posture |
|---|---|---|---|---|---|---|
| 1 | Anthropic, PBC | AI model hosting | Provision of AI-generated outputs through Provider's Companion AI tools (currently the deployed Client Platform Agreement Companion AI and the deployed Referral Alliance AI Companion, the latter answering a Referral Agent's plain-language questions about the Referral Alliance Agreement and the Referral Alliance Certification Course through the same Anthropic Commercial Messages API; additional Companion AI tools queued for deployment per Provider's product roadmap). Counterparty Personal Data is processed only insofar as a Counterparty user submits it as input to a Companion AI tool (for the Referral Alliance AI Companion, the Referral Agent's typed queries). In addition (deployment-status pending: the Contribution Portal redaction pipeline described at Part I §3.11 is in design and not yet processing), Provider's automated content-screening passes will submit contribution-media transcript text and sampled video frames to the same Anthropic Commercial API for redaction flagging, compliance screening, and marketing-candidate identification under Provider's published Redaction Standard; screening outputs are flags that route to Provider's human review for placement-bound content or apply the published Redaction Standard's default exclusion for base-destination content, and in either case are not automated decisions producing legal or similarly significant effects. | Text inputs the Counterparty user submits to the Companion AI tool (may include identifying or contextual information at the user's discretion); AI-generated text outputs returned to the Counterparty user; (pending, per Part I §3.11) transcript excerpts and sampled video frames from contribution session media screened under the published Redaction Standard. | United States (Anthropic Commercial API processing) | Direct contractual relationship under Anthropic Commercial Terms of Service, under which Anthropic does not use Commercial API inputs or outputs to train its models. Under Anthropic's default Commercial API retention, inputs and outputs are retained by Anthropic for up to thirty (30) days for abuse monitoring and automated safety classification and are then automatically deleted. Zero Data Retention is a separate enterprise-tier Anthropic configuration available on Anthropic's approval and enabled per organization; it is not currently enabled for Provider's organization, and if later enabled it further shortens Anthropic-side retention without changing the no-training commitment stated above. Anthropic Data Processing Addendum available through Anthropic's standard process. |
| 2 | Cloudflare, Inc. | Cloud hosting / edge compute / iframe hosting / managed SQL database / application back-end / video hosting and streaming delivery | Hosting and delivery of Provider's Companion AI tool iframes; hosting of Provider's ESAR Tools Portal Worker and Provider's QR-redirect platform; provision of generic Workers-based edge compute, content delivery, and DDoS / WAF protection for Provider Platform endpoints; (deployment-status pending per the footnote at the end of this entry, with respect to the Cloudflare Stream surface) hosting and streaming delivery of Provider's Platform video content through Cloudflare Stream — course and training videos, recorded media content, and similar Platform-delivered video, including any such video in which a Counterparty appears; (deployment-status pending, with respect to the Contribution Portal redaction pipeline per Part I §3.11) storage, transcript and caption generation, and streaming of participant-contributed session media through Cloudflare Stream, rendering of redacted cuts and marketing excerpts by Provider-operated processing jobs on Cloudflare Containers instances (with Cloudflare Workers AI as the designated fallback transcription path), and the D1-resident flag, decision, and consent records of that pipeline; and (deployment-status pending per the footnote at the end of this entry, with respect to the structured-data-store and dashboard surfaces) operation of Provider's structured operational system of record on Cloudflare D1 (Provider's managed SQL database for financial, project, hour-and-delivery, attribution, transaction, and settlement records across the multi-tenant Platform) together with a single Cloudflare Worker as the authenticated access-and-integration layer that mediates every read from and write to that database with server-side per-user scoping. The Worker renders the Counterparty-facing dashboards through which authenticated Counterparties access their own scoped data — a Strategist (Subscriber) dashboard, an Instructor dashboard, and a Client view-only dashboard scoped to that Client's own project status and own payments (never the split economics or marketplace internals behind them). External Counterparties authenticate on expertgrants.com and never access the database directly; the same Worker, not the database, initiates the outbound calls to the Stripe payment infrastructure at entry 6. | Counterparty Personal Data in transit through Cloudflare's edge as a function of the request-path architecture (identifying request metadata, request-body content where applicable, response content where applicable); short-duration caching of public content as the Platform configures; and (upon activation of the structured-data-store surface) the structured Counterparty Personal Data persisted in the Cloudflare D1 system of record — identifying information, contact information, account and authentication metadata, project and engagement records, hour-and-delivery entries, attribution records, transaction and settlement records, payout-reference metadata, and the audit-log records associated with those entries. | Globally distributed edge network with US-region origin for Provider Platform components; the Cloudflare D1 system-of-record database is provisioned in a United States region | Direct contractual relationship under Cloudflare Self-Serve Subscription Agreement or Enterprise Master Subscription Agreement as applicable; Cloudflare Data Processing Addendum incorporated; Cloudflare publishes SCC-compliant transfer mechanism and a sub-processor roster. Deployment status as of this Annex's current version (with respect to the Cloudflare D1 structured-data-store, the Counterparty-facing dashboard surfaces, and the Cloudflare Stream video surface only — the edge compute, iframe hosting, ESAR Tools Portal Worker, QR-redirect platform, content delivery, and DDoS / WAF surfaces are operationally live): Provider's Cloudflare D1 system-of-record database and the Strategist (Subscriber) dashboard Worker are operationally live at dashboard.expertgrants.com as of 2026-06-02; both Google OIDC and magic-link email authentication paths have been validated end-to-end; the Strategist dashboard is currently scoped to joseph@gosarconsulting.com (Provider principal) and will be widened to additional Strategist accounts as onboarding proceeds. The Instructor dashboard and Client view-only dashboard are in design and are not yet processing live Counterparty Personal Data; activation of each surface will be reflected through the Part II §4.3 change-notification mechanism prior to first processing of Counterparty Personal Data through those surfaces. The Cloudflare Stream video surface is not yet processing Counterparty Personal Data; its activation will likewise be reflected through the Part II §4.3 change-notification mechanism prior to first processing of any Counterparty-appearing video content. |
| 3 | Make.com (Celonis SE / Integromat s.r.o.) | Workflow automation / iPaaS | Execution of Provider's automation scenarios that move data among Provider Platform components and integrated systems, including reference-document synchronization, notification routing, data-store coordination, and similar integration workflows. | Counterparty Personal Data routed through automation scenarios as the scenario design requires (may include identifying information, transaction metadata, document content, or other categories specific to the scenario). | United States (us2 zone, per Provider's selected Make.com tenant region, directly verified); origin-region of integrated systems applicable per integration | Direct contractual relationship under Make.com Terms of Service; Make.com Data Processing Addendum incorporated; SCCs incorporated for any cross-border transfers. |
| 4 | Notion Labs, Inc. | Workspace tooling / database hosting | Hosting of Provider's internal workspace databases used for Provider-internal Platform operation and project management, principally the Phase Tracker and Provider's internal reference and content-authoring databases. Following Provider's adoption of the Cloudflare D1 system of record at entry 2 for the structured financial / project / multi-tenant Platform data, Notion is no longer the system of record for that structured Counterparty data; its role is limited to Provider-internal coordination and to content and reference material that legitimately resides in Notion. Reference databases used for Provider-internal coordination of Counterparty engagements may contain identifying and contact information for Counterparties in the course of Provider's coordination of their engagement under the operative agreement. | Limited Counterparty Personal Data appearing in Provider's internal workspace databases as a function of operational coordination (for example, identifying information, contact information, engagement-status metadata, and similar coordination-supporting categories); Notion is not the system of record for the structured Counterparty financial, project, attribution, or settlement data, which resides in the Cloudflare D1 system of record at entry 2. | United States (Notion's primary processing region) | Direct contractual relationship under Notion's Master Subscription Agreement; Notion Data Processing Addendum incorporated; Notion publishes a sub-processor roster and SCC-compliant transfer mechanism. Transition status as of this Annex's current version: Provider has determined to transition the remaining Provider-internal coordination and content functions described in this entry to Provider's native Platform infrastructure (entry 2) and Provider's document workspace. Processing under this entry continues during the transition; this entry will be retired through the C.1.3 / Part II §4.3 update mechanism when Notion ceases processing Counterparty Personal Data on Provider's behalf. |
| 5 | Google LLC (Google Workspace, Google Drive, Google Meet, Google Chat, Google Forms, and Google Business Profile) | Cloud hosting / collaboration / file storage / video conferencing / chat / forms / business-profile listing | Hosting of Provider's domain email (joseph.gosar@expertgrants.com and similar Provider-personnel mailboxes), calendars, Drive folders, Meet video-conferencing sessions, Chat channels used for Provider-internal coordination touching Counterparty engagement, Forms used for ad-hoc structured data intake (distinct from the purpose-built research-survey infrastructure at entry 10), and (deployment-status pending per the footnote at the end of this entry) a Google Business Profile of Provider entity used in connection with the EGE-side review-collection infrastructure described in entry 7 and at C.1.4. To the extent Counterparty Personal Data is transmitted to Provider via email, shared with Provider via a Drive folder, exchanged in a Meet session, exchanged in a Chat channel touching Counterparty engagement, submitted through a Form, or (upon activation) submitted as a review through Google Business Profile (for example, an Instructor's CV submitted through email, a Client's grant-application supporting documents submitted through a shared Drive folder, a deployment-folder reference document used by an AI tool with read-only access, a multi-party grant-coordination Meet session, an ad-hoc Form intake), Google Workspace and the relevant Google service process that data in the course of providing the email / Drive / Calendar / Meet / Chat / Forms / Business-Profile service. Meet video sessions are not recorded or transcribed by default; recording and transcription occur only where the host explicitly enables those features for a given session and Provider obtains the consents required for session recording and transcription. | Counterparty Personal Data transmitted via email, shared via Drive, exchanged in Meet sessions (including any session-specific recording or transcript artifacts generated where the host enables those features), exchanged in Chat channels, submitted through Forms, and (upon Business-Profile activation) submitted as Google Business Profile reviews; identifying information, contact information, document content, audio/video content of Meet sessions where applicable, free-text review content where applicable, and other categories as a function of what the Counterparty transmits. | Globally distributed Google infrastructure; Provider's Google Workspace tenant is configured for US-region default with regional residency options for specific data types | Direct contractual relationship under Google Workspace Enterprise terms; Google Cloud Data Processing and Security Terms (incorporated into Workspace terms) apply; Google publishes a sub-processor roster and SCC-compliant transfer mechanism. Deployment status as of this Annex's current version (with respect to the Google Business Profile surface only — Workspace, Drive, Calendar, Meet, Chat, and Forms are operationally live): A Google Business Profile of Provider entity has not yet been established and no review-side Counterparty Personal Data is currently being processed through a Google Business Profile of Provider entity. Activation is planned for Phase 02 of Provider's deployment sequence in coordination with Provider's review-request architecture. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 6 | Stripe, Inc. (Stripe Connect and Stripe Payments) | Payment processing / payout infrastructure | At activation: processing of Counterparty payments to Provider (Subscriber subscription fees, Instructor delivery-fee invoicing where structured through the Platform, similar Platform-side payment flows) and payouts from Provider to Counterparties (Subscriber compensation under PSA Exhibit B, Referral Agent commission under RAA §6.0, Instructor delivery-fee payouts under ISA §9.0) through Stripe Connect Express; identity verification of Subscriber, Referral Agent, and Instructor payout accounts to satisfy Stripe's Know-Your-Customer requirements. EDIP Participants do not receive personal compensation through Provider per EDIP §6.0 + §18.0 (Zero Personal Compensation & Air Gap) and accordingly will not have a payout account in this flow. Additionally, where Provider enables Stripe Tax, Stripe performs computation and collection of sales, use, and marketplace-facilitator taxes on Platform transactions in Provider's marketplace-facilitator capacity, together with the associated tax-reporting export, as a function of the existing Stripe relationship (no separate sub-processor is introduced where tax computation is performed within Stripe). | At activation: identifying information, contact information, taxpayer identification information (SSN or EIN as Stripe Connect collects), bank-account or payment-instrument information, transaction history, and the supporting information Stripe collects for KYC and anti-money-laundering compliance. | United States (Stripe's primary processing region for US-resident accounts); US-stored regardless of Provider account region per Stripe Connect platform-level configuration | Direct contractual relationship under Stripe Services Agreement (Provider-side) and Stripe Connected Account Agreement (Counterparty-side, where Counterparty has a Stripe Connect Express account); Stripe Data Processing Agreement to be incorporated at activation; PCI DSS compliance posture inherits from Stripe; Stripe publishes a sub-processor roster and SCC-compliant transfer mechanism. Deployment status as of this Annex's current version: Provider's Stripe Connect platform account is established and platform-categorization is approved (business profile approved, live payments enabled); activation remains pending Provider's completion and validation of its Stripe Connect integration build. No Counterparty Personal Data is currently being processed by Stripe through Provider's account; activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. Reserved-entry note (Stripe Tax / alternative tax tool): if Provider selects a tax-computation provider other than Stripe (for example, a third-party tax engine such as Avalara or TaxJar, open per the Platform Tax Architecture Brief §12.1), that provider is added as a new Annex C.1 entry under the deployment-status-pending pattern (Conventions §14.1), with the Part II §4.3 thirty-day change-notification prior to first processing; the Stripe Tax refinement to this entry creates no new sub-processor and requires no such notice. |
| 7 | HighLevel, Inc. (GoHighLevel — "GHL") | CRM / workflow automation / messaging / scheduling / forms / reputation management | Counterparty-relationship-management database (contact records, engagement-state tracking, pipeline and deal-stage management); automated workflow orchestration for Counterparty-facing notifications and routing; multi-channel messaging (email and SMS) to Counterparty contacts as deployed workflows configure; calendar and appointment-booking infrastructure; custom-field capture of engagement-specific information; file and attachment storage associated with Counterparty records; notes and communication-history retention; survey and feedback-collection forms used for Counterparty intake or engagement-stage feedback collection (distinct from the purpose-built research-survey infrastructure at entry 10); Reputation Management orchestration and AI Review Response capabilities operating on client-engagement review-request flows in coordination with the destination platforms enumerated at C.1.4. Engagement spans all Counterparty tiers — Clients, Subscribers (Strategists), Referral Agents, EDIP Participants, Instructors — and pre-engagement prospects. | Identifying information (name, business name); contact information (email, phone, mailing address); communication history (email content, SMS content, call records where captured); engagement-state metadata (pipeline stage, custom-field values, automation-trigger state); calendar and appointment-booking data; files or attachments associated with the Counterparty record; notes; prospect-stage data for individuals not yet under any operative agreement; form-response content where Counterparty submits a HighLevel-hosted form; review-request engagement state, review-response content (where the AI Review Response capability is invoked), and review-deduplication tracking metadata. | United States (GHL US-region processing per the GHL standard) | Direct contractual relationship under HighLevel Subscription Agreement at the Agency level, with sub-accounts established under that Agency for data-segregation across Counterparty groups; HighLevel Data Processing Addendum incorporated; HighLevel publishes a sub-processor roster; data-isolation architecture uses GHL's Location-level OAuth model with application-layer assignedTo-based silo enforcement, appropriate to the multi-Counterparty-group operating context. The review-platform orchestration is scope-bounded by C.1.4. Transition status as of this Annex's current version: Provider has determined to transition the functions described in this entry to Provider's native Platform infrastructure (the Cloudflare systems at entry 2 and the communications sub-processors at entries 14–16). Processing under this entry continues during the transition; this entry will be retired through the C.1.3 / Part II §4.3 update mechanism when HighLevel ceases processing Counterparty Personal Data on Provider's behalf. |
| 8 | Syncfusion Pvt. Ltd. (BoldSign) | Electronic signature platform | Execution of Counterparty contracts through electronic signature, including the Referral Alliance Agreement, EDIP Participation Agreement, Instructor Services Agreement, Client Platform Agreement, the Platform Services Agreement, and any other Counterparty agreement Provider executes through the BoldSign Platform. Generation and retention of audit trails for executed agreements. | Signer identifying information (name, email address, IP address, geolocation metadata), signer authentication artifacts where collected, executed-contract document content (which itself includes the personal-data categories of the operative agreement), and audit-trail metadata (signing timestamps, view events, signature events). | United States (per Provider's selected BoldSign account residency, directly verified) | Direct contractual relationship under BoldSign Terms of Use; BoldSign's standard Data Processing Amendment is available on request through BoldSign's published DPA-request process at boldsign.com/dpa/ and BoldSign maintains a GDPR Representative through Bird & Bird (Belgium and United Kingdom). BoldSign does not accept counterparty-paper DPAs; the BoldSign standard DPA is the operative instrument for the BoldSign processing relationship. BoldSign publishes its own Sub-processor roster at boldsign.com/subprocessors/ and notifies of changes through an RSS feed at boldsign.com/blogs/feed/; Provider monitors that feed as part of the §B.13 vendor-diligence program. |
| 9 | CircleCo, Inc. (operating as Circle.so) | Community and membership platform / iframe hosting | Hosting of Provider's community spaces and course-content delivery surfaces, including (a) historically, the Companion AI tool iframe surfaces referenced from operative Counterparty-facing surfaces — the CPA Companion AI iframe surface ceased processing through Circle on 2026-06-10, when the Client Onboarding Course lessons that embedded it transitioned to native delivery on Provider's Platform (the Companion AI tool itself remains available, delivered natively on Provider's Platform) — (b) historically, the Client Onboarding Course content-delivery surface — that surface ceased processing through Circle on 2026-06-10, when the Client Onboarding Course transitioned to native delivery on Provider's Platform — and (c) Beta-cohort feedback Spaces operating during the Beta phase as part of the Beta-cohort feedback infrastructure described at Part I §1.7. | Identifying information of Counterparty members of a Circle Space (name, email address), profile information members provide (avatar, bio at member's option), member-generated content (Space posts, comments, direct messages), engagement metadata (sign-in activity, content-interaction events), and content within iframe-hosted sub-experiences where applicable (for example, Companion AI conversation transcripts that the iframe-hosted Companion AI surface itself processes through the Anthropic Sub-Processor at entry 1; Circle hosts the iframe but does not process the AI conversation substance). | United States (Circle's primary processing region on AWS US-East infrastructure) | Direct contractual relationship under Circle.so Terms of Service; Circle Data Processing Addendum incorporated; SCC-compliant cross-border transfer mechanism; Circle publishes a sub-processor roster, which Provider monitors as part of the §B.13 vendor-diligence program. The Client Onboarding Course content-delivery surface and the CPA Companion AI iframe surface both ceased processing through Circle on 2026-06-10 (native-Platform delivery); the Beta-cohort feedback Spaces have not activated; Circle's remaining processing is limited to storage of historical member-account and Space data pending Provider's wind-down and deletion of the Circle workspace. Transition status as of this Annex's current version: Provider has determined to transition all remaining functions described in this entry to Provider's native Platform infrastructure (entry 2). Processing under this entry continues during the transition; this entry will be retired through the C.1.3 / Part II §4.3 update mechanism when Circle ceases processing Counterparty Personal Data on Provider's behalf. |
| 10 | SurveyMonkey Inc. | Survey distribution / response capture / statistical analysis | Hosting and distribution of Provider's research and feedback surveys (Beta-cohort quarterly structured survey infrastructure, MVP-cohort quarterly platform satisfaction and friction-point surveys, mission-ally feedback surveys, Sponsor-tier satisfaction surveys, Community-Patron experience surveys, Investor-Sponsor experience surveys, prospect-research surveys at scale for ICP refinement, EDIP applicant assessment forms, and Aggregate Industry Benchmarking surveys); collection and statistical analysis of respondent responses including anonymous responses; AI-assisted dataset query through SurveyMonkey's native AI Analysis Suite. | Respondent identifying information where the respondent voluntarily provides it (often anonymous); response content (free-text and structured answers as the survey instrument captures them); engagement metadata (response timestamps, completion state, channel attribution where applicable); cross-tab and significance-test artifacts generated through SurveyMonkey's native analysis tooling. | United States (SurveyMonkey's primary processing region for US-resident accounts) | Direct contractual relationship under SurveyMonkey Terms of Use at the Advantage tier (or higher) supporting the MCP-API integration architecture; SurveyMonkey Data Processing Agreement to be incorporated at activation; SCC-compliant cross-border transfer mechanism; SOC 2 Type II and ISO 27001 compliance posture inherits from SurveyMonkey's enterprise posture; SurveyMonkey publishes a sub-processor roster. Deployment status as of this Annex's current version: SurveyMonkey account is not yet established (or, where Provider's principal had a personal-use SurveyMonkey account in 2024–2025, that account is being reactivated under EGE operational scope at activation) and no Counterparty Personal Data is currently being processed by SurveyMonkey through Provider. Activation is planned for Phase 01 of Provider's deployment sequence. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 11 | Calendly LLC | Meeting scheduling / availability coordination / calendar integration | Multi-party grant-coordination meeting scheduling (Meeting Polls primary mode for 4-party grant meetings involving Subscriber + Client + Provider's Grant Coordinator personnel or AI tooling + grant administrator and optional ad-hoc external invitees), plus standard single-host event types and (where Provider's Calendly tier supports them) round-robin and collective event types as Provider's scheduling needs develop; coordination across Counterparty + Client + Provider-personnel calendars and ad-hoc invitee calendars; integration with Provider's HighLevel CRM (entry 7) where pre-fill and post-meeting persistence applies per the Coordinator AI tool architecture. | Name (where collected; optional for poll voters who participate by email only); email address; calendar availability metadata (where the invitee connects a personal calendar, which is optional); meeting metadata (purpose, attendee list, scheduled time, location/link); custom intake-field responses (where event types capture them); IP address and timezone metadata for invitees. | United States (Calendly's primary processing region) | Direct contractual relationship under Calendly Terms of Service at the Standard tier or higher supporting MCP-API integration (Teams tier or higher if Collective or Round Robin event types are also active); Calendly Data Processing Addendum to be incorporated at activation; SCC-compliant cross-border transfer mechanism; SOC 2 Type II posture inherits from Calendly's enterprise posture; HIPAA BAA available at Teams tier and above (not relied on by Provider absent a protected-health-information processing context). Deployment status as of this Annex's current version: Provider's Calendly account is established and the single-host scheduling surface is operationally live as of 2026-06-13 — a single-host "Strategy Session" booking event type through which prospects and Counterparties schedule one-to-one sessions with Provider personnel (Provider's Calendly organization, with Provider-personnel seats provisioned under single-sign-on). The multi-party Meeting Polls grant-coordination surface and the Coordinator AI tool integration described above remain in development and are not yet processing Counterparty Personal Data; those surfaces will be reflected through the Part II §4.3 change-notification mechanism prior to first processing. Calendly was disclosed as a Sub-Processor in the policy version published at first CPA execution (entry added V1.1, 2026-05-29; first executions 2026-06-10), so the live-surface activation is a deployment-status fact change rather than a Part II §4.3 sub-processor addition; it is noticed to executed Counterparties under Part I §11.2 and CPA §16.3.3 (published-policy update, continued-use acceptance) through the supplemental activation confirmation, consistent with the treatment of the Annex C.1 #13 activation at V1.11. |
| 12 | Meta Platforms, Inc. | Social-media business-page hosting / review-platform destination surface | Hosting of a Facebook Page of Provider entity used as a destination surface in the EGE-side review-collection infrastructure orchestrated through the HighLevel Reputation Management capability at entry 7. Where a Counterparty submits a Facebook Page review of the Provider's Platform-experience including any Strategist's engagement-delivery, Meta processes that review-side personal information as a function of providing the Facebook Page hosting service. The Facebook Page surface is scope-bounded by C.1.4 (Strategist-side independent review collection and non-client review sources are out of scope). | Reviewer identifying information as Meta surfaces it (typically Facebook profile name and any profile metadata Meta exposes through the Page reviews view), free-text review content where applicable, star rating where applicable, and any reviewer comments responding to a Provider response. | Globally distributed Meta infrastructure; US-region origin processing for US-resident reviewers; international processing inherent to Meta's global Facebook infrastructure for non-US reviewers | Direct contractual relationship under the Meta Business Tools terms of service (including the Meta Pages Terms) governing the operation of a Facebook Page of Provider entity; Meta publishes data-processing terms applicable to Page administrators; Meta's cross-border transfer posture for EU-origin processing applies (Meta's published transfer mechanism). Deployment status as of this Annex's current version: A Facebook Page of Provider entity has not yet been established and no review-side Counterparty Personal Data is currently being processed by Meta through Provider. Activation is planned for Phase 02 of Provider's deployment sequence in coordination with Provider's review-request architecture. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 13 | Backblaze, Inc. (Backblaze B2 Cloud Storage) | Immutable compliance / audit archive (object storage with Object Lock) | Retention of an immutable, write-once-read-many (WORM) archive of Provider's legally-significant Platform records for tax, audit, anti-money-laundering, grant-compliance, and franchise-defense recordkeeping. The archive is fed from periodic snapshots of the structured financial / project / settlement records held in the Cloudflare D1 system of record at entry 2 and of the Platform-generated legally-significant documents produced on Provider's native Platform. Records are written under Object Lock in Compliance mode for a defined retention period and cannot be altered or deleted before that period elapses. This archive is the immutability layer for Provider's compliance recordkeeping; it is distinct from the operational backups described at Annex B.8–B.9 and is not used for day-to-day Platform operation. | Identifying information, contact information, transaction and settlement records, payout-reference metadata, attribution records, and the executed-record and engagement-record content captured in the archived snapshots and export feeds, to the extent such Counterparty Personal Data appears in the legally-significant records being preserved. | United States (Backblaze B2 US-region bucket) | Direct contractual relationship under Backblaze's B2 Cloud Storage terms; Backblaze Data Processing Addendum incorporated; Backblaze publishes a sub-processor roster and an SCC-compliant transfer mechanism. Retention of Counterparty Personal Data in this immutable archive operates as a retention exception under Part I §7.1 and Part II §10.4 (legal, tax, audit, anti-money-laundering, grant-compliance, and franchise-defense recordkeeping); because Object Lock in Compliance mode prevents deletion before the retention period elapses, archived records are not subject to the Part II §10.2 deletion election or to erasure until the Object Lock retention period expires, consistent with the §10.4 retention-exception framework. Deployment status as of this Annex's current version: the archive pipeline is operational. The Backblaze B2 bucket operates under Object Lock in Compliance mode; the automated daily snapshot pipeline completed post-implementation validation on June 11, 2026 and entered unattended daily operation on June 12, 2026. Counterparty Personal Data appearing in the archived Platform records described in this entry is being written to the archive in the ordinary course, and archived records are subject to the Object Lock retention period from the date each record is written. This entry and its activation mechanism were disclosed through the V1.10 counterparty notification of June 11, 2026, and Counterparties receive a supplemental activation confirmation through the Part I §11.2 communication channels. Future material changes to this entry's processing description will be reflected through the Part II §4.3 change-notification mechanism. |
| 14 | Resend, Inc. | Transactional email delivery | Delivery of authentication-related transactional email to users of Provider's Platform dashboard — specifically, the time-limited single-use sign-in link ("magic-link") delivered to a user who requests email-based authentication on the Platform dashboard — and, upon activation of the expanded surface described in the deployment-status note for this entry, delivery of general Platform-generated transactional email (engagement notifications, contract-execution notices, settlement and payment-event notifications, and similar Platform-originated transactional messages). Resend processes the recipient's email address and the message content as necessary to transmit each email. Resend does not retain message content beyond the delivery window and does not process Counterparty Personal Data for any purpose other than transmission of the email as instructed by Provider. | Recipient email address; message content — for the magic-link surface, a time-limited single-use authentication URL and associated boilerplate; for the expanded transactional surface upon activation, the notification content of the Platform-generated message (which may include identifying information, engagement-status metadata, and transaction-event references as a function of the notification type). | United States (Resend's primary processing region) | Direct contractual relationship under Resend Terms of Service; Resend Data Processing Agreement available through Resend's standard DPA process; Resend publishes a sub-processor roster. Deployment status as of this Annex's current version: Resend is operationally live as of 2026-06-02. A Resend account has been established under Provider's operational credentials ("EGE Platform dashboard" API key, Sending access, All domains); the expertgrants.com sending domain has been verified via Cloudflare Auto-configure (DNS + DKIM applied automatically); and the magic-link authentication increment of Provider's Platform dashboard has been deployed and validated end-to-end. Resend is currently processing magic-link authentication emails for authenticated Platform dashboard users. Expanded-surface deployment status: Provider has determined to extend Resend's role to general Platform transactional email (engagement notifications, contract-execution notices, settlement and payment-event notifications, and similar Platform-generated transactional messages) as part of Provider's native-platform communications architecture; that expanded surface is not yet processing Counterparty Personal Data and its activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 15 | Telnyx LLC | Programmable communications (SMS / voice CPaaS) | Provision of the Platform's business-line telephony layer: provisioning of dedicated business phone numbers ("Siloed Access Numbers") for Platform participants' Platform-related SMS and voice traffic; delivery of Platform-orchestrated SMS notifications and two-way SMS conversations; inbound-call forwarding from a provisioned number to the participant's own existing phone line (native ring on the participant's own device — Provider's member pattern provisions a new business number with forwarding and does not port participants' personal mobile numbers); A2P 10DLC brand and campaign registration supporting compliant business SMS; and port-in of a participant's existing true business line (VoIP or landline) on a case-by-case basis at the participant's election. | Participant and Counterparty contact phone numbers; SMS message content transmitted through provisioned numbers; voice-call signaling and routing metadata (call detail records); forwarding-destination phone numbers; business-identity information submitted for A2P 10DLC registration. | United States (Telnyx US-region processing) | Direct contractual relationship under Telnyx terms of service; Telnyx Data Processing Addendum incorporated; Telnyx publishes a sub-processor roster and an SCC-compliant transfer mechanism. Deployment status as of this Annex's current version: Telnyx service is not yet provisioned and no Counterparty Personal Data is currently being processed by Telnyx through Provider. A2P 10DLC brand and campaign registration — a multi-week external approval process that precedes any SMS processing — is underway as of 2026-06-12. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 16 | Nylas, Inc. | Email and calendar integration API | Where a Platform participant elects to connect the participant's own email account under the Platform's bring-your-own-email architecture, Nylas provides the authenticated integration layer through which the Platform sends, receives, and synchronizes Platform-related correspondence through the participant's own account, strictly within the OAuth scopes the participant grants at connection; calendar-integration functions where the participant connects a calendar. Processing through Nylas occurs at the participant's direction by virtue of the participant's grant, and Provider configures the requested scopes to the minimum necessary for the Platform communication functions the participant uses. | Participant email-account identifiers and OAuth grant tokens; message content and message metadata of correspondence sent or synchronized through the connected account within granted scopes; calendar event data (titles, attendees, times) where a calendar is connected. | United States (Nylas US-region processing) | Direct contractual relationship under Nylas terms of service; Nylas Data Processing Agreement incorporated; SOC 2 compliance posture inherits from Nylas's enterprise posture; Nylas publishes a sub-processor roster and an SCC-compliant transfer mechanism. Deployment status as of this Annex's current version: Nylas service is not yet provisioned and no Counterparty Personal Data is currently being processed by Nylas through Provider. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 17 | RiversideFM, Inc. (Riverside) | Remote audio/video recording and transcription studio | Recording of Provider's media-brand and Platform content sessions, including Owners Unscripted podcast episodes with contracted Guests and Participants and recorded Platform or course content featuring Counterparties: local high-resolution audio/video capture, cloud upload and storage of session recordings, transcription, and post-production artifacts. Consistent with Part I §1.2, personal-data processing arising solely from Owners Unscripted media-audience interactions is outside this Policy's scope; this entry covers contracted Owners Unscripted Participants and Guests (and any other Counterparty appearing in recorded Platform content) whose recordings Provider processes through Platform infrastructure under an operative agreement. | Audio and video recordings (likeness and voice) of session participants; transcripts; participant names and email addresses used for session invitations; session metadata (timestamps, device/browser metadata incident to the recording session). | United States (primary cloud processing); vendor operations in the United States and Israel per RiversideFM, Inc.'s published Data Processing Addendum (Israel holds an EU adequacy decision; EEA/UK/Swiss transfers ride the SCC modules incorporated in Riverside's DPA) | Direct contractual relationship under Riverside terms of service; Riverside Data Processing Addendum incorporated (published at riverside.fm/data-processing-addendum, SCC Modules Two and Three attached); Riverside publishes a sub-processor roster at riverside.fm/subprocessors and maintains a designated DPO contact. Deployment status as of this Annex's current version: Riverside service is not yet provisioned under Provider's operational credentials and no Counterparty Personal Data is currently being processed by Riverside through Provider. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 18 | Fathom Video Inc. (Fathom) | AI meeting notetaker / call recording, transcription, and AI summary | AI notetaking on calls that Provider's own staff (Provider personnel, including W-2 internal Strategists) host and elect to record, riding on top of the third-party conferencing service on which the call is hosted (Zoom, Google Meet, or Microsoft Teams): capture of the call's audio/video recording, generation of a transcript, and production of an AI-generated summary, action items, and notes. This entry covers only calls that Provider's own staff host and record; notetaking, recording, or transcription tools that independent Subscribers (Strategists), Instructors, or other independent participants elect to run on their own calls under their own vendor relationships are outside this entry and are addressed at C.1.5. Counterparty Personal Data is processed where a Counterparty (or a Counterparty's authorized representative or invitee) participates in a Provider-staff-hosted, recorded call. Notice and consent: every participant is notified that the call is being recorded — through the in-call recording announcement, this Policy, and Provider's booking-flow disclosure — and recording proceeds consistent with applicable all-party and two-party consent law. Model-training posture: Fathom's AI sub-processors (Anthropic, OpenAI, and Google) are contractually prohibited from using the data to train their models, and Provider elects the account-level opt-out of Fathom's use of de-identified customer data to improve Fathom's own models. | Audio and video recordings (voice and likeness) of call participants; AI-generated transcripts; AI-generated summaries, action items, and notes derived from the call; participant names and email addresses used for calendar and conferencing association; call metadata (timestamps, duration, conferencing platform, participant list). | United States (Fathom stores customer data in the United States per Fathom's published security documentation) | Direct contractual relationship under Fathom Video Inc.'s Terms of Service; Fathom Data Processing Agreement incorporated (published at fathom.ai/dpa, with SCC-compliant cross-border transfer mechanism); HIPAA Business Associate Agreement available (fathom.ai/baa; not relied on by Provider absent a protected-health-information processing context); Fathom is SOC 2 Type II certified and GDPR-compliant; Fathom publishes its sub-processor roster at trust.fathom.video. On deletion of Provider's account or of specific recordings, Fathom removes the recording data and metadata and purges backup copies within its published backup window. Deployment status as of this Annex's current version: Fathom is not yet provisioned under Provider's operational credentials and no Counterparty Personal Data is currently being processed by Fathom through Provider. At activation Provider will (a) configure the organization-level opt-out of Fathom's de-identified model-improvement use and (b) enable the in-call recording announcement. Activation will be reflected through the Part II §4.3 change-notification mechanism with thirty (30) days' notice prior to first processing. |
| 19 | Checkr, Inc. | Consumer reporting agency / background screening | Background verification of a Counterparty's eligibility to participate as an independent contractor in the Provider ecosystem, where an operative agreement conditions participation on a background check — currently the Instructor tier under Instructor Services Agreement §3.7 / §3.7.1 (and, by the Access-Phase qualification architecture, available to the Subscriber/Strategist tier where Phase-2 clearance is relied upon). Checkr, as the consumer reporting agency, conducts the screening: identity / Social Security number verification, national, federal, and county criminal-record searches, sex-offender-registry and global-watchlist checks, and — for a candidate without a U.S. Social Security number — an out-of-country (international) criminal-record check; and, where applicable to a Counterparty who operates through a business entity, a business-entity exclusion check (SAM / OFAC). Checkr also conducts the FCRA choreography in its own hosted candidate flow: it presents the standalone FCRA disclosure and authorization (and the state-specific forms) and, on a flagged (Lane B) result that Provider's single adjudicator determines to be disqualifying, sends the vendor-managed two-step adverse-action notices (pre-adverse notice with a copy of the report and the FTC Summary of Rights, the mandated waiting period, then the adverse-action notice). Data-flow note: Provider initiates the screening order by transmitting only the candidate's name, email address, mobile number, and work location to Checkr; the candidate enters identity and Social Security number information directly into Checkr's own hosted flow — Provider does not collect, transmit, or store the candidate's Social Security number (the qualification intake Provider collects is limited to a neutral "U.S. Social Security number — yes/no" routing fact, never the number itself and never citizenship or national-origin). Provider receives from Checkr the screening result (clear / consider) and, on a consider result, the report content necessary for Provider's single-adjudicator Lane B review. Cost posture: the background-verification cost is borne by the Counterparty as an at-cost, zero-margin pass-through under ISA §3.7 — Provider collects the cost and remits it in full to Checkr, retaining nothing. | Data Provider routes to Checkr to initiate the order: candidate name, email address, mobile phone number, and work location (state/city). Data the candidate provides directly to Checkr in Checkr's hosted flow (not collected or stored by Provider): Social Security number or other identity information, date of birth, and address history as Checkr's screening requires. Data Checkr returns to Provider: the screening result (clear / consider), and on a consider result the consumer-report content necessary for adjudication and, where applicable, the adverse-action record. The consumer report may include criminal-history records, sex-offender-registry records, watchlist records, identity-verification results, and (for international checks) out-of-country criminal-history records. | United States (Checkr's primary processing region for U.S. candidates); for a candidate without a U.S. Social Security number, the international criminal-record check involves processing in the relevant out-of-country jurisdiction(s) | Direct contractual relationship under Checkr's Customer Agreement and Background Check Authorization terms; Provider certifies the permissible purpose to Checkr on the dual basis of "employment purposes" (15 U.S.C. §1681b(a)(3)(B)) and the consumer's "written instructions" (15 U.S.C. §1681b(a)(2)) for independent-contractor screening; Checkr Data Processing Addendum incorporated; Checkr is SOC 2 Type II certified and FCRA-compliant; Checkr publishes a sub-processor roster and an SCC-compliant transfer mechanism. As the consumer reporting agency, Checkr maintains the standalone FCRA disclosure/authorization and the state-specific notices in its own candidate flow and operates the Integrated Adverse Action workflow (vendor-sent pre-adverse and adverse notices with the mandated waiting period). Deployment status as of this Annex's current version: Checkr is not yet fully credentialed under Provider's operational account and no Counterparty Personal Data is currently being processed by Checkr through Provider; the interim operating mode is the manual Checkr dashboard while the native API integration is built. No Counterparty has executed a Referral Alliance Agreement or Instructor Services Agreement as of this Annex's current version, so this entry is added pre-execution as to the Counterparty tiers it governs (no §4.3 advance-notice window runs and no counterparty notice is required for this addition — see the V1.14 Status note); first processing follows Counterparty engagement on the Instructor track. Future material changes to this entry will be reflected through the Part II §4.3 change-notification mechanism. |
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.
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.
The review-platform infrastructure orchestrated through the HighLevel Reputation Management capability (entry 7) and operating on the destination platforms identified in this Annex (the Google Business Profile of Provider entity within entry 5 and the Facebook Page of Provider entity at entry 12, with additional destination platforms to be enumerated through the Part II §4.3 notification mechanism per Provider's review-request architecture decisions at activation) is operationally bounded as follows:
The C.1.4 boundary statements operate as interpretive guidance for the entries above and do not expand or contract the substantive sub-processor relationships those entries describe. Where a Counterparty has a question about whether a particular review-collection or testimonial-collection activity falls inside or outside the C.1.4 boundary, the Counterparty may contact Provider through the channel at Part I §12.1.
Provider provides a meeting-recording and AI-notetaking tool (entry 18) for use by Provider's own staff on calls that Provider's staff host and record. Provider does not provide, require, configure, or define a notetaking or call-recording tool for independent Subscribers (Strategists), Instructors, or any other independent participant, and the following boundary applies:
Where Provider's own staff host and record a call on which an independent Subscriber or Instructor also participates, Provider's recording of that call through entry 18 is within Annex C.1 scope and is governed by the entry-18 notice-and-consent mechanics; the boundary above addresses only tools the independent participant separately elects to run on the participant's own initiative.
The operative agreements describe a Social Distribution Service (PSA §1.5.175; RAA §3.5): headless, API-first social media distribution infrastructure through which Provider distributes platform-authored Curated Posts to participant-connected social media accounts, maintaining each participant as a separate, isolated profile with complete profile isolation, participants interacting only through Provider's own Platform dashboard and never logging into the service directly. The operative agreements permit Provider to select, and to change, the specific vendor without contract amendment, provided the service meets the operative capability requirements.
As of this Annex's current version, no Social Distribution Service vendor has been selected and no Counterparty Personal Data is being processed under this service class. Two candidate architectures are under evaluation: (a) a managed third-party multi-tenant distribution vendor, which would vault the participants' scoped account-connection authorizations (so that Provider houses no social media credentials) and would process participant identifying information, connected-account identifiers, scheduled and published post content, and distribution and engagement metadata; or (b) a Provider-self-hosted deployment operating on the Cloudflare infrastructure at entry 2, in which case the scoped account-connection authorizations are held on Provider's own infrastructure and no new sub-processor arises. If architecture (a) is selected, that vendor is added as a new numbered entry in the C.1.1 table under the deployment-status-pending pattern, with the Part II §4.3 thirty-day change-notification prior to first processing of Counterparty Personal Data. If architecture (b) is selected, the relevant processing surfaces are reflected through the entry-2 surface enumeration by the same Part II §4.3 mechanism prior to first processing. In either architecture, participation follows the operative agreements' enrollment and consent mechanics, and connection of a social media account occurs only through the participant's own authorization granted in the participant's own account.
Scope boundary (participant-side social platforms). The social media platforms on which a participant's connected accounts exist process published posts as a function of the participant's own account relationships with those platforms, under the participant's own terms of service with them. Those platforms are not Provider Sub-Processors by virtue of the participant's connection of an account to the social content program, and published Curated Posts a participant keeps after exit under the operative agreements' keep-by-default regime reside on the participant's own accounts, outside Provider's processing (Provider's technical ability to process them ends at account disconnection). This boundary parallels C.1.4 and C.1.5; it does not affect entry 12, which covers the distinct Facebook Page of Provider entity used in the review-collection infrastructure.
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.
| # | Sub-processor | Service category | Provider-internal processing purpose | Categories of Provider-internal data processed |
|---|---|---|---|---|
| 1 | Gusto, Inc. | Payroll / employment data processing | Processing of payroll for Provider's W-2 Personnel, including payroll calculation, tax withholding and remittance, payment disbursement, benefits administration where elected, and the supporting recordkeeping; provision of digital workplace-posters compliance per the Provider's HR infrastructure design. | Provider personnel identifying information, taxpayer identification information, bank-account information for direct deposit, compensation information, withholdings and tax-jurisdiction information, employment-status information. Does not process Counterparty Personal Data. |
| 2 | Anthropic, PBC (via the Cowork session model used for Provider-internal work) | AI model hosting (Provider-internal use) | Provision of AI-assisted authoring and analysis during Provider's internal documentation, contract drafting, system-architecture, and similar work sessions. Distinct from the deployed-Companion-AI Sub-Processor relationship at Annex C.1 entry 1; the Cowork session model operates on a Zero-Data-Retention default for the session-scoped workloads. | Provider-internal working materials submitted to the session (draft documents, internal notes, codebase contents); does not process Counterparty Personal Data outside of any deployed AI tool's processing context (which is enumerated at Annex C.1 entry 1). |
| 3 | Google LLC (Google Workspace — Provider-internal use) | Internal collaboration / email / calendar / file storage | Provision of Provider's internal email (Provider personnel mailboxes), shared calendars, and Drive folders for Provider-internal operations — distinct from the Counterparty-facing email and shared-Drive use enumerated at Annex C.1 entry 5. | Provider-internal correspondence, calendar data, internal documentation. The same Google Workspace tenant supports both the Annex C.1 Counterparty-facing use and this Annex C.2 Provider-internal use; the Annex placement reflects the data-category boundary rather than a tenant boundary. |
| 4 | The Hartford Financial Services Group, Inc. | Workers' compensation insurance | Issuance and administration of Provider's workers' compensation insurance policy, including premium processing, claim intake and adjudication where a claim is filed, and the supporting recordkeeping required for the Utah-jurisdiction workers' compensation regime. | Provider personnel identifying information, employment information, and (in the event of a claim) claim-related information including the nature of the workplace event and supporting medical or witness information as the claim process requires. |
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.
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.
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.
Provider adopts the following SCC frameworks for the relationship between Provider and the Counterparty, as applicable to the origin jurisdiction of the Restricted Transfer:
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:
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.
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:
| SCC Annex / UK Addendum Table | Subject | Source in this Policy |
|---|---|---|
| Annex I.A | List of Parties (data exporter and data importer) | Part I §12.1 (Provider's identity and contact) and the signature block of the operative agreement (Counterparty's identity and contact) |
| Annex I.B | Description of the Transfer (subject matter, duration, nature, purpose, types of Personal Data, categories of Data Subjects, frequency, retention) | Part II §2 (general level) and Annex A.1 (per-tier instantiation), with retention rules at Annex A.2 |
| Annex I.C | Competent Supervisory Authority | Part I §13.1 (EU — supervisory authority of the EEA Member State of habitual residence of the Data Subject); Part I §13.2 (UK — Information Commissioner's Office); Part I §13.5 (Switzerland — FDPIC) |
| Annex II | Technical and Organizational Measures, including measures to ensure security of data | Annex B of this Policy |
| Annex III | List of Sub-Processors | Annex C.1 of this Policy |
| UK Addendum Part 1 (Tables 1–4) | UK-specific population analogous to EU SCCs Annex I and Annex III | The same sources mapped above, read into the UK Addendum's Table structure per D.5 |
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.
The selections for the optional clauses of the EU SCCs, established in detail at Part II §5.3, are consolidated here for reference:
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.
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:
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.
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.
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:
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.ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-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.
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.
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.
| Term | Defining section |
|---|---|
| Applicable Data Protection Law | Part II §1 |
| Backup Expiration Window | Annex B §B.9 (defined); Annex A.2.4 (cross-reference) |
| Client (Counterparty tier) | Part I §1.3 (also defined in the Client Platform Agreement) |
| Companion AI | Used throughout Part I §3 and Part II §2 / §6; defined and operationalized in the CPA (CPA §1.1.9.1 definition; CPA §9.2 operational scope); Sub-Processor relationship enumerated at Annex C.1 entry 1 |
| Controller | Part II §1 |
| Counterparty | Part II §1 |
| Counterparty Personal Data | Part II §1 |
| CPA / Client Platform Agreement | Part I §1.3 |
| Data Subject | Part II §1 |
| DPA / Data Processing Addendum | Part I §1.5 (relationship of Part I and Part II); Part II opening paragraph |
| EDIP Agreement / EDIP Participation Agreement | Part I §1.3 |
| EDIP Participant (Counterparty tier) | Part I §1.3 |
| EU SCCs | Annex D §D.1 |
| FADP (Swiss Federal Act on Data Protection) | Part I §13.5; Annex D §D.6 |
| FDPIC (Swiss Federal Data Protection and Information Commissioner) | Part I §13.5; Annex D §D.1 |
| Instructor (Counterparty tier) | Part I §1.3 |
| ISA / Instructor Services Agreement | Part I §1.3 |
| Operative agreement | Used throughout; refers to the CPA, PSA, RAA, EDIP Agreement, or ISA applicable to a given Counterparty per Part I §1.3 |
| Owners Unscripted | Part I §1.2 |
| Personal Data (and the parallel concept "personal information") | Part II §1 |
| Personal Data Breach | Part II §1 |
| Platform | Part I §1.1 |
| Policy | This document — the unified Privacy Policy (Part I) and Data Processing Addendum (Part II) |
| Portal / Referral Portal | Part I §1.1 |
| Processing | Part II §1 |
| Processor | Part II §1 |
| Provider | Part I §1.1; Part II §1 |
| Provider Personal Data | Part II §1 |
| Provider personnel (descriptive usage) | Part I §4.1 (categorical disclosure recipient); Part II §3.2 (confidentiality obligation); Annex B §B.3, §B.4, §B.11, §B.12 (TOMs personnel-security context); Annex C.2 (Provider-internal sub-processor data category). Descriptive usage throughout the Policy — lowercase form standardized doc-wide in Phase 3 (2026-05-23) F13 consistency-pass closure |
| PSA / Platform Services Agreement | Part I §1.3; Subscriber data-privacy provisions at PSA §4.9 (companion-document routing §4.9.4; retention §4.9.3) |
| RAA / Referral Alliance Agreement | Part I §1.3 |
| Referral Agent (RA) (Counterparty tier) | Part I §1.3 |
| Restricted Transfer | Part II §1 |
| Standard Contractual Clauses / SCCs | Part II §1 (defined-term entry); Annex D (operative incorporation) |
| Strategist | Part I §1.3 (client-facing terminology for Subscriber) |
| Subscriber (Counterparty tier) | Part I §1.3 (also referred to as "Strategist" in client-facing contexts) |
| Sub-Processor | Part II §1; enumerated at Annex C.1 |
| Supervisory Authority | Part II §1; per-regime identification at Part I §12.4 and Part I §13 |
| UK Addendum | Annex D §D.1 |
| UK IDTA (UK International Data Transfer Agreement) | Annex D §D.5 |
| Visitor / Prospective counterparty | Part I §1.3 |
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:
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.
Last updated: July 11, 2026. Effective June 1, 2026.