Effective Date: April 23, 2025

This Data Processing Agreement (“DPA”) is incorporated into and forms part of the Terms of Service (the “Agreement”) between Customer and Kodezi, Inc., a Delaware corporation (“Kodezi”), with respect to the Processing of Personal Data in connection with the use of Kodezi OS™ and associated services.

This DPA reflects the parties’ agreement with respect to the processing of Personal Data by Kodezi on behalf of Customer in connection with the Services under the Agreement, and is effective upon execution or acceptance of the Agreement.

1. Definitions

For purposes of this DPA:

1.1 “Affiliate” means any entity that directly or indirectly controls, is controlled by, or is under common control with a party.

1.2 “Authorized Sub-Processor” means a third party engaged by Kodezi to Process Personal Data in connection with the Services.

1.3 “Customer” means the legal entity that has accepted the Agreement and enabled use of the Services.

1.4 “Data Protection Laws” means all applicable data protection and privacy laws and regulations including, without limitation, the California Consumer Privacy Act (CCPA), the General Data Protection Regulation (GDPR), UK GDPR, and other local laws that apply to the parties’ processing of Personal Data.

1.5 “Data Subject” means the individual to whom the Personal Data relates.

1.6 “Personal Data” means any information relating to an identified or identifiable natural person that is processed by Kodezi as part of delivering the Services.

1.7 “Processing” means any operation or set of operations performed on Personal Data, whether or not by automated means.

1.8 “Processor” means Kodezi, to the extent that it processes Personal Data on behalf of the Customer under this DPA.

1.9 “Controller” means the Customer, or a third party acting on behalf of Customer, which determines the purposes and means of the processing of Personal Data.

1.10 “Kodezi OS” means the autonomous operating system for modern codebases, including self-healing, automated documentation, memory-based intelligence, and integrations with development tools such as GitHub, CI/CD pipelines, IDEs, and observability platforms.

1.11 “Service Data” includes structured metadata, logs, code commit history, and technical information used for healing, refactoring, and documentation by Kodezi OS.

1.12 “Usage Data” means telemetry, performance, interaction, and request-level data collected for analytics, debugging, and service improvement.

1.13 “Ghost mode” means an operational mode where no plaintext code is persisted by Kodezi or its subprocessors. All code data is transient and processed solely in memory, or encrypted with client-held keys.

1.14 “EU SCCs” means the European Commission’s Standard Contractual Clauses for the transfer of personal data to third countries.

1.15 “UK Addendum” means the UK’s International Data Transfer Addendum to the EU SCCs.

2. Scope of Processing and Roles of the Parties

2.1 Roles and Responsibilities

Customer may act as a Controller or Processor with respect to the Personal Data it shares with Kodezi. Kodezi acts as a Processor (or Sub-Processor, where applicable) when processing Personal Data on behalf of Customer, in connection with Kodezi OS and related services.

Kodezi acts as an independent Controller only with respect to:

• Customer Account Data (e.g., business contact information, billing data)

• Usage Data (e.g., logs, service metrics)

• Aggregated analytics not tied to identifiable Personal Data

2.2 Customer Responsibilities

Customer:

• Ensures it has all necessary rights, consents, and legal bases to provide Kodezi with Personal Data for processing.

• Is solely responsible for the accuracy, quality, and legality of the Personal Data.

• Must not provide Kodezi with Personal Data that infringes on applicable laws or the rights of any individual.

2.3 Purpose and Nature of Processing

Kodezi processes Personal Data only to:

• Deliver, maintain, and improve the functionality of Kodezi OS

• Execute autonomous healing, testing, documentation, and evolution of software codebases

• Provide integrations with IDEs, Git platforms, CI/CD tools, observability platforms, and team communication tools

• Perform data-driven recommendations based on codebase memory and test history

Processing includes, but is not limited to:

• Identifying regressions and submitting autonomous pull requests

• Generating documentation and changelogs

• Mapping entropy and architectural risk zones

• Indexing code and git history for long-term memory

2.4 Duration of Processing

Kodezi processes Personal Data for the duration of the Agreement, or until:

• The Customer account is deleted; or

• Data is requested to be deleted or returned, in accordance with Section 8 (Data Retention & Deletion)

Kodezi may retain minimal metadata required by applicable laws or for operational integrity (e.g., fraud detection or billing) unless otherwise directed by law.

2.5 Ghost mode Guarantee

When Ghost mode is enabled:

• Code data is never stored in plaintext at rest

• No subprocessors store or retain code content

• All AI-related code processing occurs in-memory and is encrypted during transit

• Background jobs and file caching use keys generated and held on the client, destroyed post-execution

Kodezi enforces Ghost mode at both the client and infrastructure level, with redundant safeguards (see Part 5: Security and Privacy Controls).

2.6 CCPA & GDPR Compliance

Kodezi certifies it:

• Does not sell Personal Data under the meaning of the CCPA

• Does not retain, use, or disclose Personal Data for any purpose outside of performing the Services

• Processes Personal Data in compliance with the GDPR, including lawful transfer mechanisms, security measures, and individual rights support

3. Subprocessors

3.1 Use of Subprocessors

Customer authorizes Kodezi to engage Subprocessors to provide elements of the Kodezi OS services, including infrastructure, AI inference, analytics, storage, security, and communications.

Kodezi ensures that:

• Each Subprocessor is contractually bound to data protection obligations no less protective than those in this DPA.

• Kodezi remains fully liable for the acts and omissions of its Subprocessors.

A current list of Subprocessors is provided in Exhibit B.

3.2 Subprocessor Notification and Objection

Kodezi will:

• Provide advance notice (minimum 15 days) of any intended additions or replacements of Subprocessors via email or dashboard notifications.

• Allow Customer to reasonably object to a new Subprocessor on data protection grounds by submitting a written notice within 10 business days of receiving the notification.

If Customer objects:

• Kodezi will use commercially reasonable efforts to address Customer’s concerns, including identifying an alternative Subprocessor.

• If no resolution is possible, Customer may terminate the affected Services with written notice. Termination will not relieve Customer of payment obligations for services rendered up to that point.

3.3 Categories of Subprocessors

Subprocessors fall into the following categories:

• Cloud Infrastructure: AWS, GCP, Azure

• AI Model Hosting & Inference: Turbopuffer

• Analytics & Monitoring: Datadog, Amplitude, Segment, PostHog

• Error Tracking: Sentry

• Code Search & Vector Storage: Pinecone, Turbopuffer

• Customer Success & Comms: Intercom, Slack, HubSpot

• Authentication & Identity: WorkOS

• Payments: Stripe

• Deployment: Vercel

• Search APIs: Exa, SerpApi

All Subprocessors are listed with their functions and regions in Exhibit B.

3.4 International Transfers

All Subprocessors located outside of the EEA, UK, or Switzerland are contractually bound via:

• Standard Contractual Clauses (EU SCCs)

• UK Addendum (if applicable)

• Supplementary safeguards (e.g. encryption, pseudonymization, limited access)

Transfers to these subprocessors are governed under Part 6 (International Transfers).

4. Security of Personal Data

Kodezi implements and maintains industry-standard technical and organizational security measures to protect Personal Data against unauthorized access, disclosure, alteration, and destruction.

These measures are designed to ensure confidentiality, integrity, availability, and resilience of Personal Data and the systems that process it.

4.1 Encryption and Data Isolation

• All Personal Data in transit is encrypted using TLS 1.2+.

• All stored data (including logs, memory indexes, and metadata) is encrypted at rest using AES-256 or stronger.

• Code data processed under Ghost mode is never persisted in plaintext and is encrypted with client-generated keys before temporary storage.

• Autonomous processing occurs within logically isolated multi-tenant infrastructure with strict access control policies.

4.2 Access Control & Authentication

• Access to infrastructure is strictly restricted to authorized personnel on a least-privilege basis.

• Multi-factor authentication (MFA) is enforced for infrastructure and administrative systems.

• Role-based access control (RBAC) governs access to services, logs, customer accounts, and system configurations.

4.3 Ghost mode Enforcement

Kodezi enforces Ghost mode as a core security principle:

• Client-side flag defaults to "on" for team accounts or enforced workspaces.

• Server-side infrastructure runs in dual-path replicas: one replica for privacy users, another for non-privacy users, with separate workers and queues.

• Requests lacking a clear x-ghost-mode header are treated as privacy-first by default.

• Ghost mode logs are disabled or replaced with no-op stubs unless explicitly whitelisted for non-sensitive telemetry.

4.4 Codebase Indexing Controls

When enabled:

• Kodezi uses Merkle tree hashing to track deltas and uploads only changed files.

• Obfuscated file paths are generated with a deterministic nonce and client-stored secret key.

• Turbopuffer stores vector embeddings, never plaintext code, for nearest-neighbor search.

• Ghost mode disables all persistent storage; files are processed in memory and deleted post-inference.

4.5 Operational Security & Resilience

• Daily automated backups and restore testing using Google Cloud tooling.

• Annual penetration testing and independent audits.

• Monitoring via Datadog, Sentry, and internal alerting systems.

• Infrastructure as code managed via HashiCorp Terraform and GitOps controls.

• Security patches to upstream dependencies (e.g., VS Code) are cherry-picked immediately upon detection of severity.

4.6 Third-Party Certifications

• Kodezi is SOC 2 Type II certified.

• Third-party audits and pen testing reports are available upon request (trust@kodezi.com).

• Compliance controls monitored and enforced using Vanta and internal security teams.

4.7 Client-Side App Security

• Kodezi VS Code plugins and CLI agents inherit upstream security updates and are audited before every major release.

• Workspace Trust is disabled by default to avoid confusion with Kodezi Ghost mode.

• Signature verification for extensions is currently in development and is planned for enforcement in a future release.

5. Data Subject Rights & Audit Support

5.1 Requests from Data Subjects

Where Kodezi processes Personal Data on behalf of Customer, and receives a request from a Data Subject to exercise rights under applicable Data Protection Laws (e.g., access, erasure, correction, objection, portability):

• Kodezi will promptly notify Customer (unless prohibited by law) and redirect the Data Subject to Customer.

• Kodezi will not respond directly to such requests unless authorized by Customer or required by law.

5.2 Customer Assistance

Kodezi will provide reasonable assistance to Customer to:

• Respond to Data Subject access and deletion requests

• Demonstrate compliance with applicable laws

• Fulfill Customer obligations regarding data minimization, security, and impact assessments

Such assistance may include:

• API or dashboard-level access to relevant data

• Confirmation of data deletion

• Documentation of security practices

Reasonable costs may apply if the request involves non-standard manual work.

5.3 Right to Audit

Customer may audit Kodezi’s compliance with this DPA up to once per year, or more frequently if required by law or in response to a verified security incident.

Audit options include:

1. Review of third-party audit reports (e.g., SOC 2 Type II, penetration test results)

2. Virtual Q&A with security and compliance personnel

3. On-site audit of relevant systems and processes (with 30 days' written notice)

Conditions:

• Must not unreasonably interfere with Kodezi operations

• Must maintain confidentiality of information learned

• Any third-party auditor must be bound by appropriate NDAs

If requested by regulators, Kodezi will cooperate with inspections or audits under applicable Data Protection Laws.

5.4 Records of Processing

Kodezi maintains internal logs and records of:

• Processing activities performed on behalf of Customers

• Access logs to Personal Data systems

• Subprocessor interactions and transfers

• Actions taken in response to Data Subject Requests

Retention of such records is for no longer than 3 years, unless required for regulatory or legal purposes.

6. International Data Transfers

6.1 Data Hosting and Processing Location

Kodezi primarily processes and stores Personal Data in the United States. However, some subprocessors may operate in other regions (e.g., EU, UK, Japan, Canada) to support latency, resilience, or compliance.

For customers subject to the EU GDPR, UK GDPR, or Swiss DPA, any transfer of Personal Data from the EEA, UK, or Switzerland to a third country not deemed to provide adequate protection will be governed by appropriate legal mechanisms.

6.2 Transfer Mechanisms

6.2.1 EU Standard Contractual Clauses (SCCs)

Where Personal Data is transferred out of the EEA to a country that does not ensure an adequate level of protection, Kodezi and Customer agree the following applies:

• The 2021 SCCs adopted by the European Commission (Decision 2021/914) are incorporated into this DPA by reference.

• Depending on roles:

  • Module Two (Controller → Processor) applies where Customer is a controller.

  • Module Three (Processor → Sub-Processor) applies where Customer is a processor and Kodezi is a sub-processor.

• The optional docking clause (Clause 7) does not apply.

• Clause 9 Option 2 applies (general written authorization with notice for subprocessor changes as described in Part 3).

• Governing law: Ireland.

• Competent authority: Irish Data Protection Commission.

Annex I and II of the SCCs are provided in Exhibits B and C of this DPA.

6.2.2 UK International Data Transfer Addendum

Where Personal Data is transferred out of the United Kingdom, the UK International Data Transfer Addendum to the SCCs is incorporated into this DPA, with the following specifications:

• References to “Member State” or “Supervisory Authority” are to be read as references to the UK equivalents.

• Governing law: England and Wales.

• Parties agree to work in good faith to update this DPA as necessary if new UK transfer mechanisms are issued.

6.3 Supplementary Safeguards

Kodezi applies the following technical and organizational measures to ensure equivalent protection for transferred data:

• Encryption at rest and in transit (AES-256, TLS 1.2+)

• Access minimization using RBAC and MFA

• Ghost mode ensures code is never persisted for users who opt in (or are enforced by team policy)

• Logging separation and infrastructure isolation for privacy vs. non-privacy environments

• Vendor due diligence and zero-retention clauses in subprocessor contracts

6.4 Government Access Requests

As of the effective date:

• Kodezi has not received any government requests for access to customer code or Personal Data under surveillance laws.

• If a legally binding request is received, Kodezi will:

  • Promptly notify Customer (unless legally prohibited)

  • Challenge the request where legally appropriate

  • Provide only the minimum amount of data required

If Kodezi becomes aware of legal circumstances that weaken its ability to comply with the SCCs or UK Addendum, it will notify the Customer and offer options including suspension or termination of affected transfers.

7. Data Retention and Deletion

7.1 Duration of Processing

Kodezi retains and processes Personal Data only for as long as necessary to:

• Deliver the agreed-upon Services (including Kodezi OS modules, integrations, and dashboards)

• Comply with legal, regulatory, or accounting obligations

• Support security, debugging, or operational performance (when ghost mode is not enabled)

When Personal Data is no longer required, Kodezi securely deletes or anonymizes it in accordance with industry best practices.

7.2 Customer-Controlled Deletion

Customers may delete:

• Indexed codebases and associated memory using Kodezi’s dashboard or API

• Entire accounts through Settings → Advanced → Delete Account

Upon account deletion:

• All linked repositories, commit metadata, and memory embeddings are purged

• Remaining personal metadata (e.g., email, name, usage logs) is marked for deletion within 30 days

• Any file-based backups are automatically overwritten within the same window (maximum backup lifecycle: 30 days)

Customers may also contact privacy@kodezi.com to request expedited deletion or full data export.

7.3 Ghost mode Retention Policy

For users with Ghost mode enabled (including all team accounts with enforced privacy):

• No plaintext code is ever persisted at rest

• Temporary job data is stored only in-memory, or in encrypted cache with ephemeral keys

• All such data is automatically deleted once the request is fulfilled or the session expires (typically within minutes to hours)

• Privacy logs are disabled or scrubbed

Kodezi uses dual-path infrastructure (dedicated workers, queues, and caches) to enforce this retention model at the system level.

7.4 Residual Metadata

Kodezi may retain limited metadata (e.g., billing history, access logs, security events) for:

• Legal defense or dispute resolution

• Detection and prevention of abuse or fraud

• Internal analytics (only in anonymized or aggregated form)

Such residual data is retained only as long as reasonably necessary and never includes content-level customer code when Ghost mode is active.

7.5 Model Training and Privacy

Unless explicitly stated otherwise:

• Code data from Ghost mode users is never used in any training or fine-tuning of Kodezi’s AI models

• Data from non-privacy users may be temporarily cached or used to improve inference quality (e.g., auto-rewriting logic), but never reused for general-purpose training without Customer opt-in

Deletion of your data ensures it will be excluded from future models.

8. Kodezi as Independent Controller

While Kodezi primarily acts as a Processor for Customer code and service data, there are limited contexts where Kodezi operates as an Independent Controller under applicable Data Protection Laws.

This includes:

8.1 Categories of Independently Controlled Data

• Customer Account Data: Information related to account registration, authentication, billing, and team management (e.g., names, emails, workspace settings, payment method).

• Customer Usage Data: Logs, session metadata, performance metrics, and behavioral events (e.g., API call frequency, feature usage patterns).

• Security & Audit Data: Access logs, IP addresses, access timestamps, and device identifiers for monitoring and abuse prevention.

• Aggregated & Anonymized Data: High-level platform insights used for analytics, product development, and internal reporting.

8.2 Purposes of Controller-Based Processing

Kodezi processes the above data for:

• Managing Customer relationships (e.g., billing, support, onboarding)

• Operating, maintaining, and improving the platform

• Monitoring system performance and uptime

• Investigating or mitigating abuse, fraud, or misuse

• Ensuring product and infrastructure security

• Complying with legal or regulatory obligations

• Conducting internal analytics, testing, or research (always in anonymized or pseudonymized form)

8.3 Lawful Basis

Kodezi processes such data based on:

• Contractual necessity: To deliver core services under the Agreement

• Legitimate interests: To improve services, ensure security, and run business operations

• Legal obligation: When compliance is required by law

• Consent: When explicitly obtained (e.g., email marketing preferences or optional beta tracking)

8.4 Exclusions

Kodezi does not use Customer’s code, commit messages, or repository data for independent purposes unless:

• It is explicitly anonymized and de-identified

• The Customer has opted in

• It is required to fulfill critical security or operational duties (e.g., debugging a customer-reported issue)

Kodezi will never sell, license, or share such data with third parties for unrelated purposes.

9. Conflict Resolution & Supporting Exhibits

9.1 Order of Precedence

In the event of any conflict or inconsistency between:

1. The EU Standard Contractual Clauses or UK Addendum (if applicable)

2. This Data Processing Agreement (DPA)

3. The main Kodezi Terms of Service

4. Any other documents or policies referenced

The order listed above shall govern, with the SCCs taking the highest precedence.

9.2 Governing Law and Jurisdiction

Unless otherwise required under the SCCs or UK Addendum:

• This DPA is governed by the laws of Delaware, United States.

• Disputes will be resolved in accordance with the dispute resolution terms in the Kodezi Terms of Service.

9.3 Amendments

Kodezi may update this DPA to comply with changes in law, expand subprocessors, or improve clarity. Material changes will be communicated to Customer in advance and will take effect upon continued use of the Service or written agreement.

Exhibit A – Details of Processing

Nature and Purpose:
Autonomous debugging, refactoring, testing, documentation, and code evolution via the Kodezi OS infrastructure and memory systems.

Duration:
For the length of the service engagement, or until account or data deletion is requested.

Categories of Data Subjects:

• Customer developers

• End users (if Customer shares such data)

Types of Personal Data:

• Names, emails, workspace identity

• Code commit metadata, PR history

• Behavioral usage data (e.g., API calls, errors)

• Obfuscated file paths and test failures

Special Categories of Data:
Not intentionally collected. If submitted by Customer, Customer is responsible for lawful basis and safeguards.

Exhibit B – Authorized Subprocessors

Exhibit C – Security Measures

Encryption:

• TLS 1.2+ in transit

• AES-256 at rest

• Ephemeral key encryption for Ghost mode file storage

Access Control:

• MFA and RBAC enforced

• Least-privilege access reviews quarterly

Infrastructure Isolation:

• Dual-path replicas for Privacy vs. non-Privacy

• Separated workers, queues, and cache

• Session isolation for model inference

Codebase Indexing:

• Merkle hash delta sync

• Obfuscated file paths (non-reversible without key)

• Ghost mode disables all persistent storage

Auditing & Logging:

• Logging redacted or suppressed under Ghost mode

• Internal and external audits (SOC 2 Type II available upon request)

• Datadog and Sentry for performance visibility

Business Continuity:

• Daily backups and encrypted disaster recovery plans

• Independent redundancy across AWS regions

1.10 “Kodezi OS”

“Kodezi OS” refers to Kodezi’s autonomous operating system for modern codebases — a system designed to maintain, heal, evolve, and document software infrastructure without human intervention. It integrates across a developer’s stack (including GitHub, IDEs, CI/CD tools, observability platforms, and collaboration channels) to continuously manage the lifecycle of codebases.

Kodezi OS includes, but is not limited to:

• Self-Healing Engine: Automatically detects and fixes regressions, bugs, and flaky tests.

• Auto-Evolution Modules: Refactors architecture, upgrades dependencies, and modularizes codebases.

• Living Documentation: Generates comments, READMEs, changelogs, and inline documentation.

• Smart PR Engine: Reviews team pull requests, blocks risky merges, and submits healing branches.

• Kodezi Cortex: A visual dashboard with entropy heatmaps, flakiness trends, and regeneration metrics.

• Kodezi Memory: A long-term memory layer that retains repository-specific knowledge, commit history, and test outcomes to make intelligent decisions across the entire codebase.

Kodezi OS operates as an autonomous infrastructure layer, replacing traditional manual code maintenance workflows with intelligent, self-sustaining processes — without relying on prompts or copilot-style interactions.

1.11 “Service Data”

“Service Data” refers to all data processed by Kodezi in the course of providing the Kodezi OS services to the Customer, excluding Customer Account Data and Usage Data.

Service Data includes, but is not limited to:

• Code commit metadata (e.g., commit hashes, timestamps, author identifiers)

• File structure details and dependency graphs

• PR content, test coverage statistics, CI/CD pipeline results

• Error stack traces, logs tied to code execution or test failures

• Code snippets and diffs submitted via Kodezi CLI, IDE plugin, GitHub App, or API

• Auto-generated changelogs, inline comments, or documentation blocks

• Data ingested or generated during use of the Kodezi Memory engine or Smart PR Engine

Service Data is used exclusively to power Kodezi OS’s autonomous debugging, testing, documentation, and code evolution capabilities. It is only retained and processed in alignment with Ghost mode policies and Customer configuration.

1.12 “Usage Data”

“Usage Data” refers to information collected automatically through Customer or user interaction with Kodezi OS, its integrations, or associated interfaces — excluding code content or other Service Data.

Usage Data includes, but is not limited to:

• API request metadata (e.g., timestamps, endpoints used, frequency)

• Feature interaction events (e.g., which modules were triggered, which dashboards viewed)

• System and performance logs (e.g., latency, failure rates, memory usage)

• Client configuration settings, plugin usage, and workspace metadata

• Clickstream data, session duration, and navigation paths within Kodezi UI or Cortex

Usage Data is used for:

• Monitoring product performance and stability

• Understanding feature adoption and usage trends

• Debugging operational issues

• Improving UX and feature delivery

• Supporting onboarding, guidance, and personalization (e.g., hiding unused modules)

Kodezi may aggregate or anonymize Usage Data to generate benchmarks or platform intelligence, provided it does not identify any individual user or Customer.

1.13 “Ghost Mode”

“Ghost Mode” is Kodezi’s highest level of data protection — a zero-observability execution layer that ensures Customer code and associated data are never stored, never logged, and never seen by any system, engineer, or subprocessor.

When Ghost Mode is enabled:

• Code is processed entirely in volatile memory and immediately discarded after execution.

• No logs, events, telemetry, or traces are recorded that could reconstruct or infer code structure, content, or logic.

• Background tasks operate using client-side, single-use encryption keys, generated per request and unrecoverable after execution.

• Subprocessors are explicitly prohibited from storing, caching, or inspecting code inputs — even temporarily.

• Internal Kodezi systems enforce strict I/O isolation, ensuring code processed in Ghost Mode never reaches persistent storage, disk buffers, or shared memory.

Ghost Mode includes:

• Invisible compute: No plaintext ever leaves the client unencrypted.

• Dual-layer enforcement: Infra routes all Ghost Mode requests through isolated queues, stateless workers, and replica services with no logging capacity.

• Immutable safeguards: Even if logs were enabled, Ghost Mode replicas treat logging functions as no-ops — code is unobservable by design.

• Team override enforcement: Ghost Mode is forcibly enabled and locked for all users under enterprise team policies.

Kodezi defaults to Ghost Mode if the mode is ambiguous or unspecified, ensuring conservative, zero-trust handling of all code data. The system assumes Ghost Mode is active unless explicitly proven otherwise.

Ghost Mode is not just secure. It’s untouchable.
No storage. No training. No record. No access — not even by us.

1.14 “EU SCCs”

“EU SCCs” means the Standard Contractual Clauses adopted by the European Commission in Decision 2021/914 of 4 June 2021, as may be amended, updated, or replaced from time to time.

These clauses provide a lawful mechanism for the transfer of Personal Data from the European Economic Area (EEA) to countries outside the EEA that have not been deemed to provide adequate protection under the GDPR.

For purposes of this DPA:

• The Module Two (Controller-to-Processor) and Module Three (Processor-to-Subprocessor) clauses typically apply.

• The EU SCCs are incorporated by reference into this DPA where relevant.

• Required annexes and details are included in Exhibits A, B, and C.

Kodezi agrees to abide by the obligations of the EU SCCs where applicable to ensure cross-border transfers of Personal Data are legally valid, secure, and protective of Data Subject rights.

1.15 “UK Addendum”

“UK Addendum” refers to the International Data Transfer Addendum to the EU Standard Contractual Clauses, issued by the UK Information Commissioner’s Office (ICO) and effective from March 21, 2022 (or as may be updated or replaced).

This addendum modifies and extends the EU SCCs to support lawful transfers of Personal Data from the United Kingdom to countries that do not provide an adequate level of protection under the UK GDPR or Data Protection Act 2018.

Under this DPA:

• The UK Addendum is automatically incorporated where UK-originating Personal Data is involved.

• Kodezi agrees to complete and comply with the UK Addendum alongside the EU SCCs.

• Relevant tables and required entries are reflected in Exhibits B and C.

The UK Addendum ensures that data transfers from the UK to non-adequate countries maintain equivalent protection as under UK data laws.