Data Sharing Addendum

Version 1.0 · Updated 19 October 2026 · Effective 16 October 2026

This Data Sharing Addendum (the “DSA”) forms part of the agreement between Forward AI Labs, Inc. (“MiraDay”, “we”, “us”) and the Customer identified in that agreement. It governs Personal Data contained in eligible professional fields contributed by the Customer to F2D (Fast to Data) and in F2D Data delivered by MiraDay to the Customer, with each party acting as an independent controller for its relevant processing. F2D is MiraDay’s recruiting data infrastructure, bringing together professional profiles, company information and job information. This DSA applies only to Personal Data within those activities; it does not, by itself, govern information that is not Personal Data.

The “Agreement” means the MiraDay Terms of Service accepted by the Customer. Acceptance of the Agreement also constitutes acceptance of this DSA, its Annexes and the applicable transfer terms completed below. No separate checkbox is required by this DSA. A person accepting for an organization must have authority to bind it; an invited member does not accept the organization’s DSA on its behalf merely by joining its Workspace. “DSA” in these documents means Data Sharing Addendum.

1. Definitions

Capitalized terms not defined here have the meanings given in the Agreement. Data Protection Law, EU GDPR, UK GDPR, Personal Data Breach, EU SCCs, UK Addendum and Restricted Transfer have the meanings given in the Data Processing Addendum (the “DPA”). Terms such as Personal Data, processing, controller, processor and data subject have their meanings under applicable Data Protection Law.

Term

Meaning

Shared Personal Data

Personal Data in eligible Contributed Fields disclosed to MiraDay or in F2D Data delivered to the Customer under this DSA

Contribution

Disclosure of eligible Contributed Fields from the relevant Customer’s Workspace to MiraDay for its independent F2D purposes under Section 4

Delivery

For purposes of this DSA, MiraDay’s disclosure of Personal Data contained in F2D Data to the Customer for its Recruiting Purposes under Section 5

Disclosing Party / Receiving Party

The party disclosing or receiving Shared Personal Data for the particular contribution or delivery; roles reverse with the direction of sharing

Suppression Record

Minimum identifiers and associated restrictions retained to recognize an affected person or record and prevent prohibited processing or reintroduction; it is not an active recruiting profile

Processing Notice

MiraDay’s notice for individuals whose professional profiles are held in F2D, available as the Personal Information Notice. References to the Processing Notice or Candidate Privacy Notice identify that notice

2. Scope and Independent Controllers

2.1 Two Sharing Directions. Annex 1 describes separately (A) Customer-to-MiraDay contributions and (B) MiraDay-to-Customer deliveries. Each party is responsible as an independent controller for its own decisions, lawful basis, transparency, security, retention and rights handling in relation to its processing. Neither party may claim that the other party’s contractual permission alone establishes lawfulness.

2.2 Applicable Plans and Workspaces. Eligible fields from Personal and Organization Workspaces are subject to the Contribution Channel under the Agreement; there is no separate switch to disable it. The same eligibility, source exclusions and rights safeguards apply to both Workspace types. Workspace separation remains in place and does not transfer all content between Workspaces. Email and Extension connections follow the account, while captured Customer content belongs to the relevant Channel’s Workspace; data and Credits do not move between Workspaces.

2.3 DPA Boundary. The DPA governs MiraDay’s processing on the Customer’s instructions, including the Customer’s original Workspace copy and subsequent instructed hosting of delivered F2D Data saved there. This DSA governs the independent F2D purposes, contribution, delivery and source/use restrictions. Preparatory processing follows the parties’ actual purposes and decision-making; writing into F2D is not the sole legal test. A shared field does not remove DPA protection from other Workspace content. The same information may be subject to different obligations for different copies or activities.

2.4 Other Sources and Actual Roles. MiraDay’s public-source collection, licensed-provider collection and any direct Extension collection for F2D are subject to its own source arrangements, Data Protection Law and notices. This Customer DSA does not authorize those upstream activities or substitute for provider agreements. Each source must be assessed separately. If an activity actually involves joint determination of purposes and essential means, the parties must assess and put in place any required joint-controller arrangement; the label “independent controller” does not override the facts.

3. Data Categories and Source Restrictions

3.1 Contribution Whitelist. Only the individual structured professional field values listed in Annex 1, Part A are eligible. Contribution does not include complete documents or communications. A field category being eligible does not mean the field is actually collected, present or deliverable for every person.

3.2 Excluded Data. Original CVs, attachments, full page captures and screenshots; Customer notes, private labels, assessments, scores, interview feedback, recordings and transcripts; email/message content; prompts, instructions and hiring decisions; compensation, credentials and Customer confidential business information; personal email addresses or telephone numbers; home or precise addresses; photographs, date of birth and age; special category and criminal offence data or fields revealing or inferring them; and data relating to children are excluded from contribution. Public availability does not override these exclusions.

3.3 Source Permission. The Customer must have the rights and lawful basis required for its collection and disclosure. MiraDay must have its own lawful basis and lawful source permissions for receipt, use and delivery. Both must respect contractual, confidentiality and platform restrictions relevant to their activities. The whitelist does not override connected-account data-use restrictions, Restricted Sites, objections, suppression or source-specific limitations. Consent is not automatically required for every field, and agreeing to this DSA is not consent from a candidate.

3.4 Connected-Account Data. Connected-account data, including Google, Microsoft and other connected-account fields and data derived from them, is excluded from contribution. It may be processed only for the authorized connected functions and applicable provider requirements. A value’s presence on the whitelist does not override this exclusion. Genuinely independent acquisition of the same value from an eligible public or licensed source must be recorded separately; relabeling connected-account data does not establish independent acquisition. MiraDay will use appropriate technical measures to distinguish work contact details from personal contact details; a field with an unresolved classification is not eligible for contribution or delivery.

3.5 Changes and Historical Data. Contribution applies to eligible structured fields newly added or updated in ordinary use after these contribution terms apply; it does not authorize bulk contribution of unchanged historical Workspace records. New source categories, expanded fields or changed purposes require the legal assessment, notices and acceptance applicable under the Agreement and Data Protection Law. Excluded and suppressed data remain excluded regardless of Plan-level contribution conditions.

4. Contribution to F2D

4.1 Limited Permission. Subject to lawful source permissions, this DSA and the Agreement, the Customer grants MiraDay a non-exclusive, worldwide, royalty-free license to extract the eligible structured fields, verify and maintain them in F2D, and deliver them to other Customers for Recruiting Purposes. Worldwide permission is subject to Section 11 and does not authorize an unlawful transfer. Eligible contributed copies already in F2D may remain after the Customer’s subscription ends only while their continued processing is lawful under this DSA. This permission does not authorize unrestricted use of Customer Content or model training and does not override candidates’ rights.

4.2 Admission Checks. MiraDay will check source eligibility, the field whitelist, exclusion rules, relevant quality information and its suppression list before admitting a record to F2D. It will use the matching methods reasonably available for suppression checks and withhold matching records. It will not knowingly admit excluded data or overwrite an effective correction or suppression with an older source value. Uncertain eligibility or unresolved conflicting restrictions must be resolved before the affected data is admitted or disclosed.

4.3 Notice and Disclosure Gate. MiraDay will not deliver a contributed record to another Customer until the required candidate notice has been provided, unless MiraDay has assessed and documented a legally applicable exception and implemented the required safeguards under Section 6. A suppression, applicable objection or restriction blocks the corresponding processing even if a notice exception exists. No minimum 30-day waiting period is established by this DSA; withholding is tied to the applicable legal and operational conditions. There is no separate contribution staging area. Source, notice and suppression requirements apply to the relevant processing regardless of storage location.

4.4 Provenance and Accountability. MiraDay will keep records sufficient to identify the source category, relevant Customer/Workspace origin where contribution applies, eligible fields, admission decision, applicable notice/exception, rights restrictions, and deliveries needed for cooperation under Section 8. Internal provenance does not authorize disclosure of the Customer’s confidential Workspace content or identity beyond a lawful and necessary purpose.

4.5 No Training Exception. MiraDay will not use Contributed Fields or data derived from Customer Content to train, fine-tune or improve its own or third-party AI models. The prohibition remains after contribution, aggregation, de-identification or anonymization. AI inference needed for permitted service functions is allowed. Independently obtained public or licensed F2D data is governed by the Agreement’s separate limits; MiraDay must maintain sufficient source separation to enforce the Customer-data restriction.

5. Delivery and Permitted Use

5.1 Recruiting Purposes. MiraDay licenses delivered F2D Data to the Customer on the terms of the Agreement for Recruiting Purposes: identifying, evaluating, contacting and hiring candidates for roles it fills for itself or a specific recruiting client engagement, including talent, company, labour-market and compensation research supporting those recruiting activities. Delivery is not permission for sales prospecting, marketing, advertising, list building, resale, unrelated commercial research or other purposes excluded by the Agreement. The Customer is an independent controller of its received Personal Data copy.

5.2 Restricted Reuse. The Customer must not sell, license, publicly disclose or make F2D Data generally available; build, enrich or verify a database or product offered to others; or make unauthorized onward disclosures. The specific recruiting-client exception is subject to Section 9. Ownership of a report or Output does not confer ownership of underlying F2D Data or remove its restrictions.

5.3 AI and Decisions. The Customer may not use F2D Data or data derived from it to train, fine-tune or improve AI models, including internal models. Necessary inference for permitted Recruiting Purposes remains subject to the Agreement, source restrictions, lawful basis, minimization, security and rights duties. MiraDay provides suggestions for appropriate human review; this does not remove either party’s duties concerning profiling, automated decisions, discrimination or candidate rights, or relax MiraDay’s own no-training obligations.

5.4 Contacting Candidates. A business contact field being available does not establish permission for every communication channel or message. The Customer must comply with applicable recruiting, electronic communications and direct-marketing rules, respect objections and opt-outs, and use the available controls as the Agreement requires. Inclusion of work telephone numbers in the whitelist does not represent that MiraDay provides telephone calling, WhatsApp, InMail or calendar functionality.

6. Lawful Basis and Transparency

6.1 Each Party’s Lawful Processing. Each party is responsible for establishing and documenting the lawful basis and safeguards applicable to its own processing and completing assessments required by Data Protection Law. Public availability, Customer agreement or a commercial license does not alone establish lawfulness. This DSA does not represent that an assessment has already been completed.

6.2 Customer Notices. The Customer is responsible for notices concerning its Workspace processing and its disclosure of eligible professional fields to MiraDay. It must include required information about the Contribution Channel and may use information supplied by MiraDay for that purpose. A template does not replace the Customer’s assessment of its actual processing. On receiving F2D Data, the Customer must meet the notice duties applicable to its own receipt, recruiting use and onward disclosures; it cannot assume MiraDay’s notice covers its distinct purposes.

6.3 MiraDay’s Candidate Notice. MiraDay will provide information about its F2D processing through its Personal Information Notice (the Processing Notice) and the individual notices required by law. MiraDay is responsible for the information required about its F2D processing, including identity/contact, data categories, purposes and lawful basis, legitimate interests where applicable, sources, recipients, transfers, retention, profiling and rights. For indirectly obtained data, it will provide the information within the timing required by applicable law. Where Article 14 applies, this includes a reasonable period no later than one month after obtaining the data, at the latest on first communication with the individual, or at the latest on first disclosure to another recipient, as applicable. Holding a record without delivering it does not remove an earlier applicable notice deadline.

6.4 Individual Notice and Exceptions. MiraDay will provide individual notice primarily by email where a lawful delivery channel is available, supported by its publicly accessible Personal Information Notice (the Processing Notice), and will retain records of notices, delivery and any relied-on exception. It may rely on an exception only where legally applicable and after documenting its grounds, scope and safeguards. In particular, where providing individual information is impossible or would involve disproportionate effort under applicable Article 14 rules, MiraDay will make the required information publicly available through its Processing Notice and take appropriate measures to protect individuals’ rights, freedoms and legitimate interests. Lack of an email address, scale or cost alone is not a blanket exemption. The assessment must consider the actual source, expectations, risk, available channels and necessary safeguards and must be reviewed when circumstances change.

6.5 Public Notice and Rights Access. MiraDay will maintain an accessible Personal Information Notice (the Processing Notice) and a Privacy Center through which candidates can access privacy information and rights channels. Candidates may submit applicable objection, correction, deletion and other rights requests through the Privacy Request page or privacy@miraday.ai. Publishing a Processing Notice supports transparency and an applicable exception; it does not itself authorize all collection or delivery. Records must remain blocked from delivery if there is neither a valid notice route nor a legally applicable exception that has been assessed and documented. Delivery decisions and exception records must be capable of review.

7. Accuracy, Data Quality and Retention

7.1 Quality and Provenance. Each party will take reasonable steps to ensure Personal Data is accurate and sufficiently current for its purpose. MiraDay will use provenance, conflict handling and verification measures appropriate to the data and risk, avoid representing unsupported inferred values as verified facts, and reflect effective corrections and restrictions. The Customer will verify material facts before relying on profiles or Outputs for decisions. The Agreement’s data-quality disclaimer does not displace legal accuracy duties.

7.2 Retention. Each party will retain Shared Personal Data only as long as necessary for its lawful purpose, subject to legal requirements and rights decisions. MiraDay’s F2D review and removal criteria are recorded in Annex 1. A license surviving subscription termination does not authorize indefinite retention. The Customer will periodically review its saved F2D copies, apply its own retention criteria and remove data no longer needed.

7.3 Suppression Records. Each party may retain minimum identifiers needed to honor objections, deletion or restrictions and prevent prohibited reintroduction, on an appropriate lawful basis. Suppression information must be secured, used only for that purpose and retained no longer than necessary to maintain the restriction and required accountability. It must not be used to recreate an active profile, recruit the person or train models.

8. Data Subject Rights and Cooperation

8.1 Routing and Decisions. MiraDay will handle requests for its F2D processing through the Privacy Center, the Privacy Request page or privacy@miraday.ai. The Customer will handle requests for its own controller processing. A party receiving a request that concerns the other party will route it without undue delay and provide necessary information, without transferring unrelated Customer data. Each party performs proportionate identity verification and decides matters within its responsibility. Neither may send the person between parties without providing the assistance required by law.

8.2 Recipient Notifications. When rectifying, erasing or restricting shared Personal Data, a party will communicate the action to each recipient where applicable Data Protection Law requires it, including Article 19 requirements, unless an applicable exception is established and recorded. It will provide recipient information to the individual where required. Notifications will identify the affected record/fields, action, scope, effective date and applicable reason or restriction, without unnecessary personal information. Where source or suppression problems affect multiple records, the notification must identify the relevant scope.

8.3 Workspace and External Copies. For MiraDay-delivered F2D fields held inside a Customer Workspace, MiraDay will implement the corresponding correction, deletion or restriction and notify the Customer as the Agreement provides. For copies outside MiraDay, the Customer must locate and apply the change to affected F2D-origin fields and copies, and notify permitted onward recipients where required. The Customer must act without undue delay and, for ordinary implementation, no later than 30 calendar days after receipt of the notice. Action must occur sooner where applicable law, urgency or the stated restriction requires. This is an outer contractual limit, not permission to delay a required response or continue prohibited processing. The Customer will confirm completion or identify a lawful exception and measures taken through the notified reply channel. In-product automation does not relieve the Customer of responsibility for external copies.

8.4 Mixed Records and Independent Sources. A rights notice concerns the relevant delivered data, not automatically every field in a mixed record. Customer-created notes and independently obtained data must be assessed separately by the responsible controller. An independent source is not a means to evade an objection or erase an effective restriction. If the Customer considers a notified action inapplicable to a separately held field or that continued retention is legally required, it must document the basis, separate or restrict the relevant data as necessary and inform MiraDay of the exception. MiraDay will not remove unrelated Customer content merely because an F2D field is affected.

8.5 Objections and Restrictions. MiraDay will block processing covered by an effective objection or restriction, with the safeguards and legal assessment required by law. In accordance with the Agreement and Privacy commitments, an objection to direct marketing, including recruiting outreach treated as direct marketing, stops that outreach. General legitimate-interest objections are assessed under the applicable statutory test; they are not dismissed solely because contribution is a Plan condition. The parties will communicate a relevant block promptly and prevent affected records from being automatically reintroduced from a different source.

8.6 Propagation and Evidence. MiraDay will maintain sufficient source and delivery records to send and track relevant notices. The Customer must retain enough information to identify F2D-derived copies and permitted recipients, apply notices and demonstrate completion. Where a lawful permitted use produces summaries, reports or other derivatives, the Customer must assess and implement the steps required to give effect to the request, including restricting affected processing where necessary. The parties will maintain records of notifications, acknowledgments, actions, exceptions and unresolved failures. Neither party represents that deleting a source field automatically removes all effects from a model.

8.7 Channels and Failure Escalation. MiraDay will send notices to the Customer’s current registered/privacy contact, with any available in-Service delivery. The Customer will send contribution-related corrections, source restrictions or rights issues to privacy@miraday.ai, identifying the record and necessary scope. If delivery fails, the sender will use another available verified contact, investigate the failure and record follow-up. An unresolved implementation issue must be escalated between the privacy contacts; continued use or delivery of affected data must be restricted where necessary pending resolution. Completion and failure records are retained under a necessary and documented accountability period.

8.8 Survival and Suppliers. Required rights cooperation and recipient notifications apply while a party or its permitted recipients retain affected Shared Personal Data. No fixed post-termination commercial email update service is promised. MiraDay will establish appropriate correction, deletion, suppression and rights cooperation with its upstream suppliers, communicate applicable restrictions, and obtain completion confirmation or a documented lawful exception. This Customer DSA does not bind those suppliers by itself.

9. Onward Disclosure and Service Providers

9.1 Specific Recruiting Clients. A recruitment agency or search firm may disclose F2D Data to a client only in a specific recruiting engagement permitted by the Agreement, on terms no less restrictive concerning permitted use, onward disclosure, confidentiality, security, rights cooperation and applicable transfers. It must inform that client of relevant restrictions and keep recipient details necessary for Section 8. The client’s actual controller or processor role must be assessed; describing it as a client does not determine that role.

9.2 Each Controller’s Processors. Each party may engage processors for its own lawful processing subject to Data Protection Law, including any required controller–processor contract, sufficient guarantees, security and transfers. Processors used by MiraDay for its independent F2D purposes are MiraDay’s processors, not Subprocessors appointed on the Customer’s behalf under the DPA. A provider with both roles must be treated appropriately for each activity. The Customer may not avoid onward disclosure restrictions by labeling a data purchaser or database operator as its processor.

9.3 Source and Geographic Limits. The Receiving Party must respect applicable source, purpose and geographic limitations notified with delivery. A permitted recipient or provider does not receive broader rights than the relevant party has. No disclosure may take place where required safeguards or legal conditions are missing. Each party remains responsible for the obligations imposed on it by law and this DSA.

10. Security, Personal Data Breach Notification and Cooperation

10.1 Measures. Each party will implement appropriate technical and organizational measures for its processing of Shared Personal Data, taking account of the nature, scope, context, purposes and risk. Annex 2 contains MiraDay’s common technical measures for the service components actually used in its independent F2D processing; it does not change the independent-controller roles in Section 2 or describe the Customer’s external systems. The source and F2D safeguards in Sections 3–8, processor requirements in Section 9 and receiving-party and transfer controls in Sections 10.5–10.6 apply in addition. MiraDay will not reduce the overall level of its agreed protection during the subscription period. Available security information may be requested from privacy@miraday.ai.

10.2 Mutual Notification. A party becoming aware of a Personal Data Breach involving Shared Personal Data that affects the other’s data, processing or ability to fulfil legal obligations will notify the other without undue delay. The initial notice must not wait for a completed investigation. Available information, further updates, containment and cooperation will be provided proportionately, including the nature, scope, likely consequences and mitigation measures. The verified contacts in Annex 1 will be used, with prompt fallback for delivery failures.

10.3 Each Party’s Legal Duties. Each controller is responsible for any notifications it must make to supervisory authorities or individuals. The parties will share information necessary for those duties and coordinate where appropriate, without unnecessarily delaying either party’s legal deadlines. No party will notify on the other’s behalf without authorization unless required by law. A processor breach affecting Workspace data follows the DPA; an event affecting both roles must be addressed under both applicable arrangements.

10.4 Compliance Cooperation. The parties will provide information reasonably necessary to assess lawful sharing, rights, security and required transfer safeguards and cooperate with competent authorities where required. Necessary confidentiality arrangements may protect commercial information and other persons’ data but must not defeat statutory access or applicable EU SCC information/audit duties.

10.5 Receiving-party Security and Retention. Each Receiving Party will restrict access to authorized personnel and lawful processors who need the data for the permitted purpose and are bound by appropriate confidentiality obligations. It will protect credentials and devices, use authentication safeguards appropriate to the privilege and risk, and apply appropriate encryption and access protections to transfer and storage. It will maintain proportionate incident, vulnerability and recovery arrangements and secure the records needed for rights and notice cooperation. The Customer must apply appropriate controls to any external ATS, CRM, repository or other receiving system; MiraDay’s platform measures do not certify those systems. Each party will implement necessary retention and deletion controls, protect retained backups and reapply effective deletion, restriction and suppression decisions after restoration before ordinary use. Records and expired copies are handled under Sections 7–8 and applicable law.

10.6 Transfer Controls and Specific Measures. The parties will verify the authorized recipient and processing context, minimize the transferred fields, communicate applicable source and rights restrictions, and protect transfer, notice and completion records. Actual locations, lawful mechanisms and necessary assessments or supplementary measures must be recorded for the relevant direction under Section 11 and Annex 1. Before relying on an SCC transfer, the importing party’s applicable technical and organisational measures must be identified for that receiving arrangement. Where the Customer receives data in an external system, its actual measures must be recorded or incorporated by an identified, dated security description in Annex 1, Part B. That description and any necessary supplementary measures are incorporated as the Customer-importer information for SCC Annex II. MiraDay’s measures in Annex 2 apply only to the components confirmed as relevant to its processing and do not substitute for a Customer’s external-system description. For receipt solely within MiraDay, the record will identify the relevant platform measures together with the Customer’s access and use controls under Section 10.5. The parties will provide necessary compliance information under Section 10.4 and suspend transfers lacking adequate safeguards under Section 11.5.

11. International Transfers

11.1 Assess Each Direction. Each contribution or delivery is assessed separately for its exporter, importer, actual roles, countries of processing and remote access, applicable law and lawful transfer basis. Details are in Annex 1. Public availability, candidate nationality or a business location alone does not establish whether a Restricted Transfer occurs. Both parties must comply with applicable onward-transfer requirements.

11.2 EU SCC Incorporation. For each controller-to-controller Restricted Transfer under this DSA that falls within the scope of Decision (EU) 2021/914 and is not covered by another valid mechanism identified in Annex 1, the parties incorporate the EU SCCs by reference, including their unmodified mandatory text and Module One, with the selections and Appendix information below. The official text is in Decision (EU) 2021/914. The parties agree to be bound by that text as completed for the relevant direction. The contribution and delivery arrangements are separate sets of Module One clauses with reversed parties; either or both may apply, according to the actual transfer.

The 2021/914 EU SCCs are not relied on where the relevant importer processing is outside their permitted scope, including where that processing is already directly subject to the EU GDPR and the instrument does not cover that situation. The applicable mechanism must be established before transfer. A statement that parties are independent controllers does not resolve this scope question.

11.3 UK Addendum Incorporation. Where a UK GDPR Restricted Transfer is protected through EU SCCs and the UK Addendum, the UK Addendum forms part of this DSA for that direction, completed in Tables 1–4 below. Part 2: Mandatory Clauses of the Approved Addendum, being template Addendum B.1.0 issued by the ICO and laid before Parliament under section 119A of the Data Protection Act 2018 on 2 February 2022, as revised under Section 18 of those Mandatory Clauses, are incorporated by reference. The official ICO template identifies the mandatory clauses. The UK-specific amendments, hierarchy, ICO oversight and court rights apply.

11.4 Assessments and Government Access. Before applicable transfers, the parties will complete the required assessments, including EU SCC Clause 14 and the relevant UK transfer risk assessment or data protection test, and implement necessary supplementary measures. Each importer will comply with applicable EU SCC Clause 15 duties concerning government demands, including required notification, assessment of legality, appropriate challenge, minimum disclosure and records. Where lawful, the importer will notify the exporter promptly of a demand relevant to the transfer and cooperate on safeguards; secrecy restrictions are handled as the transfer terms require.

11.5 Suspension and Remediation. A party unable to meet the applicable safeguards will promptly notify the other and stop or suspend affected transfers or processing as required. The parties will seek a lawful remedy or alternative mechanism and exercise required termination, return or deletion rights where protection cannot be restored. Ordinary cure periods, continuing licenses or export rights in the Agreement cannot override the EU SCCs, UK Addendum or Data Protection Law. This DSA does not automatically execute SCCs with a party’s processors or onward recipients.

The applicable party details, including actual addresses, transfer description, competent supervisory authority and measures, must be completed in an identified record incorporated into these clauses and available to the parties before reliance on them. Acceptance of this standard form does not replace that completion.

EU SCC Selections , Separate Module One Arrangements

SCC item

A , Contribution

B , Delivery

Applicability

Only where Section 11.2 applies to this direction

Exporter / role

Customer / controller

MiraDay / controller

Importer / role

MiraDay / controller

Customer / controller

Module

Module One

Clause 7

Docking clause included; additional parties join only as required by that clause and are individually identified

Same selection

Clause 9(a)

Not applicable to Module One

Clause 11(a) option

Optional independent dispute-resolution provision not included; other rights remain

Same selection

Clause 13 / Annex I.C

The competent authority for the Customer exporter must be determined under Clause 13 and identified in the applicable completed transfer record before SCC reliance

The competent authority for Forward AI Labs, Inc. as exporter must be determined under Clause 13 and identified with contact details in the applicable completed transfer record before SCC reliance

Clause 17

Law of Ireland

Clause 18(b)

Courts of Ireland; additional data subject forum rights preserved

Annex I.A

Annex 1, Common Party Information; Customer exporter, MiraDay importer

Annex 1, Common Party Information; MiraDay exporter, Customer importer

Annex I.B

Annex 1, Part A

Annex 1, Part B

Annex II

Annex 2: MiraDay common measures for the applicable components; Sections 3–10 and any transfer-specific supplementary measures identified in Annex 1

Sections 10.5–10.6 and the applicable Customer security description identified in Annex 1, Part B; for MiraDay-hosted receipt, the applicable Annex 2 platform measures and Customer access/use controls

Annex III

Not applicable to Module One

Execution

Binding recorded acceptance of the Agreement incorporating this DSA constitutes execution of the applicable SCCs and Annex I.A where valid under applicable law; date/authority retained in the contract record, or separately recorded binding executions

Same execution basis for this separate arrangement

UK Addendum , Part 1 Tables for Each Applicable Direction

Tables 1–4 below specify the selected options for separate UK Addenda for A and B where Section 11.3 applies; required party and Appendix information must also be completed in the identified applicable transfer record before reliance on either arrangement. They do not assume that both directions are Restricted Transfers.

Table 1 , Parties

Item

A , Contribution

B , Delivery

Start date

Date of binding acceptance of the incorporating Agreement, or later UK-transfer start date recorded in Annex 1, Part A

Date of binding acceptance of the incorporating Agreement, or later UK-transfer start date recorded in Annex 1, Part B

Exporter legal/trading name

Customer legal identity and trading name in Annex 1, Common Party Information

Forward AI Labs, Inc., trading as MiraDay

Importer legal/trading name

Forward AI Labs, Inc., trading as MiraDay

Customer legal identity and trading name in Annex 1, Common Party Information

Exporter address/registration

Customer details in Annex 1

710 Lakeway Drive, Suite 200, Sunnyvale, California 94085, United States. Applicable registration details are identified in the linked completed transfer record

Importer address/registration

710 Lakeway Drive, Suite 200, Sunnyvale, California 94085, United States. Applicable registration details are identified in the linked completed transfer record

Customer details in Annex 1

Exporter key contact

Customer privacy/incident contact in Annex 1

privacy@miraday.ai (privacy and incident contact)

Importer key contact

privacy@miraday.ai (privacy and incident contact)

Customer privacy/incident contact in Annex 1

Execution

Recorded binding Agreement acceptance identifying the parties and authority; separate signatures if used in Annex 1

Same execution basis, with roles reversed

Table 2 , Selected SCCs, Modules and Selected Clauses

For each applicable direction: the Addendum EU SCCs are the EU SCCs in Decision (EU) 2021/914 incorporated under Section 11.2, identified by DSA Version 1.0 and direction A or B. Module One applies; Clause 7 is included; the optional Clause 11(a) independent dispute-resolution provision is not included. Clause 9(a) authorization and notice period are not applicable. The Module Four data-combination question is not applicable. Parties and Appendix information are those for the corresponding direction, not the DPA processor transfer.

Table 3 , Appendix Information

Appendix item

A , Contribution

B , Delivery

Annex I.A , parties

Annex 1, Common Party Information, and Table 1 with Customer exporter / MiraDay importer

Annex 1, Common Party Information, and Table 1 with MiraDay exporter / Customer importer

Annex I.B , transfer description

Annex 1, Part A and Actual Transfer Record

Annex 1, Part B and Actual Transfer Record

Annex II , measures

Annex 2 and relevant supplementary measures identified in Annex 1, subject to Sections 3–10

Sections 10.5–10.6 and the actual Customer measures identified in Annex 1, Part B; relevant Annex 2 platform measures for MiraDay-hosted receipt

Annex III

Not applicable to Module One

Table 4 , Ending this Addendum when the Approved Addendum Changes

For each applicable direction, both the Importer and Exporter are selected as parties that may end the UK Addendum under Section 19 of its Mandatory Clauses, subject to that Section’s conditions. Part 2 is incorporated under Section 11.3. This is not an unrestricted termination right.

12. Termination, Survival, Liability and General Terms

12.1 End of Access and Contribution. Ending the relevant service stops new contribution and delivery for that service. Continued personal use or another Workspace is governed by its own Agreement and Plan. Customer copies are handled under the DPA where MiraDay is the processor; F2D copies already lawfully contributed remain subject to this DSA, purpose/retention limits and rights. Termination cannot validate a prior unlawful contribution or remove a necessary correction or suppression.

12.2 Saved F2D Copies. F2D Data lawfully saved into the Customer’s own applicant-tracking or CRM system during the subscription, in the ordinary course of Recruiting Purposes, may continue to be used after the subscription as Section 13.4 of the Agreement permits, subject to this DSA and the Customer’s ongoing lawful basis, retention review, transparency and rights duties. Bulk export in anticipation of termination does not qualify for this continued use. No post-termination license applies to data whose use must cease under a rights decision, source restriction or law.

12.3 Survival. Obligations concerning permitted use, security, confidentiality, retention, rights cooperation, lawful transfers and relevant liability survive for as long as a party or permitted recipient retains affected Shared Personal Data, or as otherwise required by law or applicable transfer terms. The end of an ordinary contractual notice window does not erase those duties.

12.4 Precedence. For independent controller sharing, this DSA and its Annexes prevail over inconsistent provisions of the Agreement. The DPA governs MiraDay’s processing on the Customer’s behalf and is not displaced by this DSA for that processing. Applicable EU SCCs and the UK Addendum take precedence in the hierarchy they require. Mandatory law remains applicable. A signed negotiated DSA replaces a published version only to the extent it validly covers the same activities without impairing mandatory protections.

12.5 Liability and Rights. Sections 11 and 12 of the Agreement govern commercial liability, including the general cap in Section 12.3 and its applicable exceptions; this DSA creates no separate monetary cap. Those provisions apply except where incompatible with Data Protection Law, EU SCCs or the UK Addendum. No cap, disclaimer, indemnity, forum rule or third-party-rights exclusion restricts protected data subject rights, liabilities or remedies under those instruments. Each party remains responsible for its own legal duties; this DSA creates no representation that a contract alone makes all sharing compliant. Early beta status does not reduce these data protection obligations.

12.6 Notices and Changes. MiraDay’s privacy and rights contact is privacy@miraday.ai; requests may also be submitted through the Privacy Center or the Privacy Request page; support and general Agreement notices use support@miraday.ai. Customer contacts are recorded in Annex 1 and must be kept current. Urgent rights or incident communications follow Sections 8, 10 and 11. Changes follow the Agreement’s applicable procedure, with corresponding source/field and notice updates as required, and cannot retroactively authorize processing requiring prior conditions. The English version controls, subject to mandatory law and applicable transfer terms.

Annex 1 , Details of Data Sharing and Transfers

This standard template is completed for each relevant Customer by linked registration, order, billing or other binding contract records and the applicable dated, versioned transfer profile. Those records identify the actual contracting Customer, country, contacts, representative authority where applicable, accepted Agreement version/date, relevant direction of sharing and profile identifier/version. The identified records and completed profile form part of this Annex and the applicable SCC/UK Addendum completion, must supply all required facts and be retrievable by the relevant parties. Common facts and assessments may be reused only where they cover the actual parties’ roles, locations, data, purposes and risks. A material departure requires an updated applicable profile or agreed customer-specific supplement before the affected transfer. Record changes do not amend mandatory clauses or replace required binding acceptance.

Common Party Information

Item

Customer

MiraDay

Legal identity

Actual individual Customer for its Personal Workspace or organization for its Organization Workspace, identified in linked registration, order or binding contract records; not automatically an invited member or third-party payer

Forward AI Labs, Inc.

Trading name, if applicable

As recorded in Agreement

MiraDay

Main address and registration details

Actual contracting address/country and registration details where applicable, as recorded and kept current in the linked Customer record

710 Lakeway Drive, Suite 200, Sunnyvale, California 94085, United States. Applicable registration details are identified in the linked contracting or completed transfer record

Role

Independent controller for its relevant contribution/delivery processing

Independent controller for F2D processing

Privacy and incident contact

Customer-designated contact and email in its linked record, or a verified registered contracting contact where valid for that purpose

privacy@miraday.ai (privacy and incident contact)

Relevant activities

Lawful candidate collection and contribution; receipt and Recruiting Purposes use

Receipt, verification, maintenance and lawful delivery of professional F2D profiles

Acceptance, date and signature

Recorded binding acceptance by the Customer/authorized representative; actual identity and date retained in Agreement record, or separately recorded binding execution

Binding Agreement acceptance; actual entity and date retained in record, or separately recorded binding execution

Part A , Contribution: Customer to MiraDay

A.1 Field Whitelist

Part B , Delivery: MiraDay to Customer

Item

Description

Exporter / importer

MiraDay controller / Customer controller; identities in Common Party Information

Data subjects

Adult candidates and other professionals whose Personal Data is lawfully held in F2D, including in related company or job information

Deliverable data

Structured professional identity/profile links, employment, education/qualifications, skills/expertise, city/region location, public professional work links, and lawfully sourced business contact details, where present, lawfully disclosable and available in the Customer’s service. Professional summaries and role-specific suggestions may accompany delivery within the same source and purpose limits. The same professional field categories and exclusions apply as in Part A. Lawfully sourced work email and work telephone fields may be included; not all fields are present in every profile. Personal Data contained in related company or job information remains subject to the same personal-data categories, exclusions and source restrictions; non-personal company or job information is outside this DSA

Exclusions

No Customer-origin confidential notes, assessments, original documents, email content or other excluded contribution data; no special category/criminal/children’s data, protected-characteristic inference or other prohibited fields admitted through another source

Nature/purpose

Controlled disclosure and receipt, candidate research, verification, saving and Recruiting Purposes use, including talent, company, labour-market and compensation research supporting the relevant recruiting activities; appropriate human review of AI suggestions; no competing database, resale or general marketing

Frequency

On Customer searches, retrievals and lawful exports within its service; delivery/recipient records maintained for rights cooperation under Section 8

Retention

Customer’s necessary recruiting retention and review criteria, subject to rights/source restrictions; for an external receiving system, its actual criteria must be identified in the linked Customer-specific receiving-system record before any transfer relying on those criteria. Continued use of saved copies is permitted only as Section 12 allows

Locations/access

MiraDay sending/access locations identified in the applicable completed transfer profile; Customer receiving, storage, backup and access countries identified in its linked record. Use of an external ATS/CRM or other receiver is recorded where applicable; solely platform-hosted receipt is identified as such

Onward disclosure

Limited specific recruiting-client exception and lawful processors under Section 9; no unrestricted third-party database or model disclosure

Rights propagation

Identification of F2D-origin fields and deliveries; notices and confirmation under Section 8; ordinary external implementation without undue delay and within 30 calendar days after notice, subject to earlier required action under Section 8.3; notices by verified email and any designated Service channel, with affected identifiers, action, recipient and completion/exception records

Measures

Sections 10.5–10.6 and the actual Customer security description/version identified in its linked receiving-system record, completed before any SCC-reliant transfer requiring those measures. For MiraDay-hosted receipt, identify the applicable Annex 2 platform measures and Customer access/use controls; this does not establish protection of an external system

Mechanism/authority

Actual Transfer Record and Section 11; exporter-specific Clause 13 authority must be identified where applicable; ICO for applicable UK Addendum

Actual Transfer Record

Identify each direction through the applicable completed standard transfer profile and link the actual Customer’s identity, country, receiving arrangement and acceptance record. Complete or agree a customer-specific supplement where the arrangement is outside the assessed standard scope. The two directions may use different mechanisms or may not require SCCs. Required parties, Appendix information, assessments and safeguards must be complete before the affected transfer; template acceptance or an uncompleted profile does not supply missing facts or authorize a transfer.

Direction / activity

Exporter entity / role

Importer entity / role

Sending/receiving/access countries

Mechanism and legal scope

Competent authority where applicable

Assessment/supplementary measures

Record date

A , contribution

Actual Customer identified in Common Party Information and its linked record / controller

Actual MiraDay entity in Common Party Information / controller

Actual countries and access locations in the matched contribution profile and Customer record

Valid mechanism and scope in the completed profile; Section 11 applicability and importer GDPR scope assessed separately

Actual Customer-exporter authority identified under Clause 13 where applicable, or ICO for applicable UK Addendum

Completed contribution assessment and supplementary measures, with any Customer-specific variation

Profile assessment/update date and Customer matching date

B , delivery

Actual MiraDay entity in Common Party Information / controller

Actual Customer identified in Common Party Information and its linked record / controller

Actual countries and access locations in the matched delivery profile and receiving-system record

Valid mechanism and scope in the completed profile; Section 11 applicability and importer GDPR scope assessed separately

Actual MiraDay-exporter authority identified under Clause 13 where applicable, or ICO for applicable UK Addendum

Completed delivery assessment and supplementary measures, including applicable Customer measures and variations

Profile assessment/update date and Customer matching date

Annex 2 , Technical and Organizational Measures

Version 1.0 , common MiraDay measures for the applicable service components. This schedule applies to components actually used by MiraDay for its independent F2D contribution, processing or delivery under this DSA, as identified for the relevant activity in Annex 1. It does not convert MiraDay into the Customer’s processor for those activities or represent that every customer-service component is used for F2D. Capitalized terms have the meanings given in this DSA and the Agreement.

The source, field, notice, suppression, accuracy and rights requirements remain in Sections 3–8. Controller-processor and onward safeguards remain in Section 9. Security, breach notification, Customer receiving-system measures and common transfer controls are governed by Sections 10–11. The actual Customer-importer measures identified in Annex 1, Part B are incorporated for SCC Annex II as Section 10.6 provides; they are not certified by the platform measures below. Return and retention treatment follows the relevant agreement and activity, rather than importing the DPA’s customer-service deletion period into every independent F2D record. These measures supplement those obligations; updates follow Section 10.1 and the Agreement.

1. Access Control and Authentication

MiraDay uses role-based access controls to restrict access to production environments, administrative functions and Personal Data. Employees use individual identities for AWS single sign-on; production databases are accessed through authorised AWS identities and network paths. The read-only replica is configured as publicly accessible, but its security group restricts inbound sources to fixed IPv4 addresses and a designated security group. The MiraDay administration console and primary integration service share a deployment environment and use permission separation. Authing provides employee authentication using an account password and SMS verification code. The employee system is integrated to disable an employee’s Authing identity upon termination. Designated personnel manage production access.

2. Authorisation and Privileged Access

Production data and administrative privileges are limited to personnel who require them for their duties. Manual employee access to Customer task data is limited to authorised internal personnel and approved by a super administrator. AWS production resources use AWS IAM Identity Center permission sets and group-based assignments. Administrators can disable or adjust identities and permissions when personnel leave or change roles.

3. Transmission Security

MiraDay uses TLS to protect network transmissions between clients and services. Production databases and caches hosted on AWS, and object storage, use the cloud provider’s at-rest encryption capabilities. E2B sandboxes use the hosting platform’s default at-rest encryption and TLS transmission protection. Cloudflare R2 buckets are private and configured to prohibit public access, and use the provider’s at-rest encryption capability.

4. Data Separation and Processing Controls

MiraDay separates task data by user or Customer data scope. Sandboxes are reused at user level during task execution; multiple tasks of the same user may share one E2B sandbox. Processing of Customer task data, including necessary evaluation and retesting, remains subject to the Customer’s lawful instructions and the purpose and no-training restrictions in the Agreement and the applicable DPA or DSA. This schedule does not authorize reuse of Customer task content in a general evaluation library or for unrelated product improvement.

5. Input, Change and Audit Logging

MiraDay records some system activity and operational events through application and cloud-platform logs. GitHub main-branch settings require pull requests, review by at least one team member, re-approval after the latest push and successful CI checks. Production releases or deployments are expected to be reviewed by someone other than the code submitter, but there is no fixed process. AWS CloudTrail Event History and CloudWatch logs provide event records for limited periods. Logging scope, retention and review vary by system, and auditable records are not available for every access to Customer data.

6. Availability, Backup and Recovery

The AWS production RDS primary has automated backups retained for seven days; the read-only replica’s own backup-retention setting is zero. The production Redis replication group has a seven-day snapshot retention period. The databases and snapshots use the cloud provider’s encryption capabilities.

7. Data Retention and Deletion

MiraDay provides an application function for deleting an individual user and corresponding application data on authorized instructions. Deletion and retention may depend on the service component and manual action. The applicable return, deletion, restriction, backup and retention obligations, including timelines and confirmation requirements, remain those in the Agreement and the relevant DPA or DSA. An individual application deletion function is not confirmation that every component or copy has been deleted.

8. Secure Development and Vulnerability Management

MiraDay uses code review and CI checks to support change management. GitHub requires pull requests and review for the main branch and runs lint, test, build and security-audit workflows. The semantic-versioning and release bot has configured bypass capability. Dependabot security updates are enabled.

9. Incident Response and Personnel

Designated personnel handle security or privacy issues received through the support email. Employee identities are authenticated through Authing and disabled upon termination through the employee-system integration; access removal and log review in other systems still depend on administrator action.