Data Processing Addendum

Version 2.1 · effective 2026-07-27 · in force

This Data Processing Addendum (the "DPA") forms part of the Terms of Service & Acceptable Use (the "Terms") between RunMyB, Inc., a Delaware corporation ("RunMyB", "we"), and the customer holding the account under the Terms (the "Customer", "you"). It applies wherever RunMyB processes personal data on the Customer's behalf within the scope of Regulation (EU) 2016/679 (the "GDPR") or equivalent data-protection law. Terms defined in the GDPR (controller, processor, personal data, personal data breach, and so on) have the same meaning here.

1. Scope and roles

RunMyB acts in three distinct capacities:

1. RunMyB as independent controller. For the platform's own account, identity, billing, credit-ledger, and security/operational data — the direct relationship between RunMyB and the people who use the platform — RunMyB is an independent controller. This DPA does not govern that processing; it is described in the Privacy Policy.
2. RunMyB as the Customer's processor — end-user data. For personal data that the Customer's applications, ventures, and workspaces process about the Customer's own end-users, the Customer (or the Customer's own client) is the controller and RunMyB is the Customer's processor. RunMyB processes that data only to provide the service, on the Customer's documented instructions.
3. RunMyB as the Customer's processor — team-member workspace data. Where the Customer admits employees, contractors, or other collaborators to its account, the Customer is the controller of the team-workspace data about those people and RunMyB is the Customer's processor: the Customer's administrators decide admission, roles, disablement, and — through the platform's affordances — what is retained, and RunMyB processes on those instructions.

Boundary with RunMyB's own controllership. Even within a Customer's team, RunMyB remains an independent controller — not the Customer's processor — for each member's own legal-acceptance and consent records, login identity, and the platform's security and operational logs: compliance evidence RunMyB must keep in its own right, recorded append-only.

Capacities 2 and 3 together define the "Customer Personal Data" this DPA governs.

2. Details of processing

• Subject matter. The personal data processed through the Customer's use of the platform: the Customer's applications and their data stores, venture and workspace content, and the team workspace.
• Duration. For the life of the Customer's account. After termination or a deletion request, processing continues only through the offboarding grace window stated when the request is filed, followed by deletion under Section 3(g), subject to the retention outer bounds stated there.
• Nature and purpose. Hosting, building, verifying, operating, and backing up the Customer's applications and workspace — including publicly serving the Customer's applications where the Customer publishes them, whatever their shape: static pages, full-stack applications with their own databases, and applications with their own end-user accounts; providing the team workspace (admission and access control, per-member environment, attributed collaboration); and providing the platform features the Customer invokes. RunMyB does not use Customer Personal Data for advertising and does not train machine-learning models on it (Section 7).
• Categories of data subjects. The Customer's end-users; the Customer's team members (employees, contractors, collaborators); and, before acceptance, the third parties whose e-mail addresses the Customer's administrators invite.
• Categories of personal data. (a) For end-user data: whatever personal data the Customer's applications are designed to process — determined and controlled by the Customer, including end-user account data where the Customer's application operates its own accounts; where the application has a database, that data lives in the product's own isolated database (the per-product isolation measure in Section 6, provided through the Neon sub-processor listed in Section 4). (b) For team-member data: membership records (role, status, display name, inviter, timestamps); invitation records (invited e-mail address, role offered, expiry — invitation tokens are stored hash-only, and expired or revoked invitation records are purged after a short fixed period); per-member environment and preferences; authorship attribution in the Customer's shared conversation records; venture assignments; and member-to-member messages within the workspace.
• Special categories of data. None are required or requested by the platform. Special-category data is present only if the Customer chooses to put it there, and the Customer is responsible for ensuring a lawful basis for it.

3. Processor obligations (Article 28(3) GDPR)

RunMyB will:

• (a) Documented instructions. Process Customer Personal Data only on the Customer's documented instructions, including with regard to international transfers. The Terms, this DPA, and the Customer's configuration and use of the platform's features and settings constitute the complete documented instructions. RunMyB will inform the Customer if, in its opinion, an instruction infringes the GDPR or other applicable data-protection law, and may suspend the instruction until it is confirmed or withdrawn.
• (b) Confidentiality. Ensure that the persons authorised to process Customer Personal Data — limited to RunMyB's operating team — are bound by confidentiality obligations.
• (c) Security. Implement and maintain the technical and organisational measures described in Section 6, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing (Article 32 GDPR).
• (d) Sub-processing. Engage sub-processors only under Section 4.
• (e) Data-subject-request assistance. Assist the Customer, insofar as possible, in fulfilling its obligation to respond to data-subject requests. The platform's built-in machinery is the primary form of this assistance: the self-service data-export flow produces a complete, structured bundle of an account's data; the in-platform data-request flow records access, portability, and erasure requests and tracks the statutory response clock; and each team member can export the data held about them through the same self-service flow. Requests that concern a member's personal data inside the Customer's shared records are directed to the Customer as controller, and RunMyB assists the Customer through the export and erasure machinery. If a data subject contacts RunMyB directly about processing under this DPA, RunMyB will redirect the request to the Customer and will not respond on the merits except on the Customer's instruction or where required by law. This redirection applies only to processing under this DPA: for the categories where RunMyB is an independent controller (Section 1, capacity 1 and the boundary paragraph — for example login identity, acceptance records, security logs, and the aggregate statistics described in the Privacy Policy), RunMyB answers data subjects directly.
• (f) Breach notification and Articles 32–36 assistance. Notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data — and in any case early enough for the Customer to meet its own 72-hour obligation under Article 33 GDPR; RunMyB's working target is notification within 48 hours, stated as an aim — providing the information reasonably available at that time (nature of the breach, categories and approximate volumes affected, likely consequences, measures taken or proposed) and supplementing it as investigation proceeds. RunMyB maintains a structured incident register that tracks each incident against the 72-hour clock of Article 33 GDPR, so the Customer's own notification window is preserved. RunMyB will further assist the Customer, taking into account the nature of the processing and the information available to it, with data-protection impact assessments and prior consultations under Articles 35–36. Notification of a breach is not an acknowledgement of fault or liability.
• (g) Deletion and return. At the end of the services, at the Customer's choice, delete or return Customer Personal Data. The account offboarding flow queues the deletion with a grace window stated when the request is filed (during which the deletion may be called off and the account reinstated on the Customer's request, through the account surface where it remains accessible or through the platform's contact points); the platform's map-driven, tiered erasure engine then deletes content, while the narrow set of records RunMyB must retain to comply with applicable law (billing, ledger, and acceptance evidence) is retained in pseudonymised, access-restricted form for the legally required period (Article 17(3) GDPR) and deleted thereafter. Return is available through the self-service data export before the deletion request is filed, and on request during the grace window.
• (h) Audit and information. Make available the information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits. Audits proceed reports-first: RunMyB provides written descriptions of its controls (Section 6) and responds to reasonable written security questionnaires, no more than once annually. Where that information is demonstrably insufficient for the Customer's compliance needs or a supervisory authority requires it, the Customer may conduct (itself or through an independent auditor that is not RunMyB's competitor) an audit of the relevant processing: at most once per year, on reasonable advance notice, during business hours, under confidentiality, at the Customer's cost, and scoped so as not to endanger other customers' data or the platform's security. RunMyB does not hold third-party certifications such as SOC 2 or ISO 27001, and none are implied; audit rights under the Standard Contractual Clauses, where they apply, remain unaffected.

4. Sub-processors

Authorization and the published list. The Customer grants RunMyB general written authorization to engage the sub-processors below. Each is engaged under the provider's standard data-protection terms, which impose data-protection obligations consistent with this DPA; RunMyB remains liable to the Customer for its sub-processors' performance. The table in this document is the published sub-processor list:

Changes to the list. RunMyB will give at least 30 days' advance notice of the addition or replacement of a sub-processor by updating the published list in this document and recording the change in this document's changelog, which is the notice mechanism. In addition, once the platform operates its transactional mailer, sub-processor changes will also be notified by e-mail to the Customer's administrators — a strengthening of the notice mechanism, stated now and effective when that mailer operates. The Customer may object on reasonable data-protection grounds within 14 days of the notice; the parties will then discuss in good faith. If the objection cannot be resolved, the Customer's remedy is to stop using the affected feature or terminate the affected service or account before the change takes effect; continued use after the change takes effect constitutes acceptance of the new sub-processor.

Services the Customer connects are not sub-processors. Services that the Customer connects to its account under the Customer's own credentials or authorization — git providers, Google Drive, Gmail, and Google Calendar via the Customer's OAuth grant, Trello, Notion, and AI providers used under the Customer's own keys — are recipients chosen and instructed by the Customer, not RunMyB sub-processors. RunMyB transmits data to them only at the Customer's direction, within the scope the Customer authorized; the Customer's own relationship and terms with each such service govern that processing. The team feature introduces no additional sub-processor: team-member data rides the same infrastructure listed above.

5. International transfers

Processing takes place in the United States: the platform's cloud infrastructure (AWS), the hosted-product databases (Neon), the AI providers (Anthropic, OpenRouter), and the payment processing (Stripe) all process there. The one EU exception is e-mail correspondence: Zoho hosts the platform's mailboxes in an EU data centre (with the Clauses below covering any extra-EEA access). For personal data subject to the GDPR, the UK GDPR, or the Swiss FADP, transfers to RunMyB and onward to its sub-processors are protected as follows:

• Standard Contractual Clauses. The 2021 EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated into this DPA by reference: Module Two (controller-to-processor) where the Customer is a controller, and Module Three (processor-to-processor) where the Customer acts as a processor for its own client — together with the UK Addendum and the Swiss amendments where those regimes apply. Sections 2 and 6 of this DPA serve as the processing and security annexes.
• Data Privacy Framework. Transfers to sub-processors certified under the EU–US Data Privacy Framework — AWS, Stripe, Cloudflare, and Google — additionally rest on that certification, with the Standard Contractual Clauses in each provider's terms as the contractual fallback.
• SCCs only. Transfers to Anthropic, OpenRouter, Neon, and Zoho rest on the Standard Contractual Clauses incorporated in those providers' data-protection terms.

6. Technical and organisational measures

RunMyB implements the following measures for Customer Personal Data:

• Tenant isolation. Per-tenant row-level-security isolation enforced at the database layer on the control plane's tenant-scoped tables, with the platform's own registers (tables owned and written by the platform rather than scoped to a tenant) protected by role-scoped database grants instead. A separate, isolated database per data-bearing Customer product.
• Encryption. TLS for data in transit; managed-cloud encryption at rest; and an encrypted-at-rest credential vault with application-layer encryption for Customer secrets and connection tokens, with write-only intake and by-name references so that secret values do not appear in logs, prompts, or URLs.
• Access control. Edge authentication on the hosted console (managed identity provider with fail-closed session verification); access to Customer Personal Data limited to RunMyB's operating team on a need-to-know basis.
• Least-privilege egress. Deny-by-default outbound network controls for build and agent sandboxes; outbound calls to connected services pass through enforced, host-restricted chokepoints.
• Integrity and accountability. Append-only acceptance, audit, safety-decision, and ledger records; structured incident tracking against the 72-hour clock of Article 33 GDPR.
• Data-subject-rights capability. Self-service data export and the in-platform data-request flow; map-driven, tiered erasure across every registered data store, with the legal-retention carve-out applied in pseudonymised form.
• Backups. Automated backups of the platform's durable stores: the managed control-plane database is encrypted at rest and its automated backups inherit that encryption; the platform file store rides daily automated backups with a bounded retention window, and the infrastructure gate refuses a change that would disable them.
• Infrastructure change control. Cloud infrastructure changes are applied through a gated, policy-checked deployment process — a codified policy check runs against every planned change before it is applied — and releases are versioned and recorded. Cloud IAM follows least-privilege: platform roles carry narrow, named grants rather than administrative access.

RunMyB reviews and updates these measures as the platform evolves; changes will not materially reduce the overall level of protection.

7. No use of Customer Data for AI/ML training

Stated in its own clause so it is findable: RunMyB does not use Customer Personal Data — or Customer content more broadly — to create, train, or improve any machine-learning or artificial-intelligence model, whether RunMyB's own or a third party's, and does not permit its sub-processors to do so on RunMyB's behalf. This restates, in one place, what Section 2 of this DPA and Section 10 of the Terms of Service & Acceptable Use already provide; it would not change without the Customer's express opt-in.

8. Liability

Each party's liability arising out of or related to this DPA, including under the Standard Contractual Clauses, is subject to the exclusions and limitations of liability set out in the Terms of Service & Acceptable Use, except where the Standard Contractual Clauses or applicable data-protection law provide otherwise. Nothing in this DPA or the Terms limits either party's liability toward data subjects or supervisory authorities where such liability cannot lawfully be limited.

9. Precedence and duration

This DPA forms part of the Terms. In the event of a conflict concerning the processing of personal data, this DPA prevails over the Terms, and the Standard Contractual Clauses prevail over this DPA for the transfers they govern. This DPA takes effect with the Terms and remains in force for as long as RunMyB processes Customer Personal Data, surviving termination of the Terms until that processing ends under Section 3(g).