Data Processing Addendum

This Data Processing Addendum (the DPA) forms part of the Terms of Service between you (Customer) and Codas Labs, LLC, a North Carolina limited liability company (Codas Labs, we, us), and applies whenever we process personal data on your behalf in providing Tore.

It is pre-signed on our side and takes effect when you accept the Terms of Service. If your review process needs a countersigned copy, or a copy with your entity details filled into Annex I, write to legal@codaslabs.com and we will send one.

Read the draft banner above before you route this for signature. Tore has not launched and this document has not been through legal review.

1. Definitions

Capitalized terms not defined here have the meaning given to them in the Terms of Service or in the applicable Data Protection Laws.

• Customer Personal Data means personal data that we process on your behalf in providing Tore. In practice that is the contents of your Tore workspace: support conversations, contacts, bug captures, knowledge base articles, feedback, and the records attached to them.
• Data Protection Laws means the EU General Data Protection Regulation (GDPR), the UK GDPR and Data Protection Act 2018 (UK Data Protection Laws), the Swiss Federal Act on Data Protection (FADP), the California Consumer Privacy Act as amended by the CPRA (CCPA), and the other US state privacy laws named in clause 14, in each case as applicable to the processing.
• Personal data, processing, controller, processor, data subject, personal data breach and supervisory authority have the meanings given to them in the GDPR.
• Subprocessor means a third party we engage to process Customer Personal Data.
• Standard Contractual Clauses or SCCs means the standard contractual clauses for the transfer of personal data to third countries approved by the European Commission in Implementing Decision (EU) 2021/914.
• UK Addendum means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0.

2. Which data this covers, and which it does not

Two different relationships run through the same product, and it matters which one applies to a given record.

Where you are the controller and we are the processor

Everything inside your Tore workspace. The conversations your customers start, the contact records behind them, the bug captures your users submit, your knowledge base, your feedback boards, and the attachments on any of them. We process that material only on your instructions, and this DPA governs it.

Where we are an independent controller

A narrow set of records that we decide the purposes and means for, because we have to run a business:

• The account records of your own staff who sign in to Tore, including name, email address, and sign-in history.
• Billing and subscription records, including who bought what.
• Security, audit and operational logs that we keep to protect the Service and to meet our own legal obligations.
• Support you request from us, and correspondence with us.
• Visitors to tore.ai and people who ask us for information.

That processing is governed by our Privacy Policy, not by this DPA. It is a controller-to-controller relationship, not a controller-to-processor one, which means the instruction, deletion and audit rights in this document do not reach it. Your staff still have the rights the Privacy Policy describes.

Where you are yourself a processor

If you use Tore to handle support for someone else’s end customers under a contract with that party, you are an intermediate processor and we are your subprocessor. This DPA still applies, and Module Three of the SCCs applies to transfers instead of Module Two. You are responsible for having your own controller’s authorization to engage us.

3. Subject matter, nature, purpose and duration

Subject matter: our provision of Tore under the Terms of Service.

Nature and purpose: hosting and operating a customer support platform. Receiving, storing and displaying support conversations and bug reports; indexing knowledge for search; sending and receiving email on your behalf; submitting content to AI models to triage, draft, summarize and investigate; and, where you connect a code repository, reading that repository in order to prepare a proposed fix for a person on your team to approve.

Duration: for as long as your subscription lasts, plus the short wind-down described in clause 13.

The itemized description that the SCCs require is in Annex I.

4. Your instructions

We process Customer Personal Data only on your documented instructions. Those instructions are: this DPA, the Terms of Service, your configuration of the Service, and anything else you tell us in writing that we accept.

Your configuration is a real instruction, not a formality. Turning on console capture, network capture, DOM capture or screen recording for a widget instructs us to collect that material. Every one of those is off until you turn it on.

If the law requires us to process Customer Personal Data for something other than your instructions, we will tell you before we do it, unless the law forbids us from telling you. If we think an instruction you have given breaks a Data Protection Law, we will tell you, and we may pause that processing while we sort it out.

5. Confidentiality of our people

Everyone we authorize to process Customer Personal Data is bound by a written confidentiality obligation that survives the end of their engagement, and is granted access on a need-to-know basis for as long as they need it.

6. Security

We implement and maintain the technical and organizational measures set out in Annex II. Those measures are itemized rather than described in a paragraph, so that you can check them one at a time. Our security page describes the same controls in plainer language, including what we do not yet have.

We may change a measure, provided the change does not materially reduce the overall level of protection.

7. Helping you answer data subject requests

Taking into account the nature of the processing, we will give you reasonable help, through appropriate technical and organizational measures, so that you can answer requests from data subjects exercising their rights.

If a data subject comes to us directly about Customer Personal Data, we will not answer the substance of the request. We will tell them to contact you, and tell you that they got in touch, unless the law says otherwise.

Erasure of a single contact is a supported operation, not a manual favor. Deleting a contact walks a registry of tables that records, for every table in the database, whether it holds data about that person and whether the correct treatment is deletion or anonymization.

8. Personal data breach notification

We will notify you without undue delay and in any event within 72 hours of becoming aware of a personal data breach affecting Customer Personal Data.

The notice will contain, to the extent known at the time:

• What happened, and when we became aware of it.
• The categories and approximate number of data subjects affected, and the categories and approximate number of records affected.
• The likely consequences.
• The measures we have taken or propose to take, including anything we have done to reduce the harm.
• A named contact at Codas Labs who can answer follow-up questions.

If we cannot give you all of that at once, we will give you what we have within 72 hours and the rest as it becomes available, rather than delay the first notice.

We will cooperate with you in investigating, containing and remediating the incident, and in any notification you have to make to a regulator or to affected people. A notification from us is not an admission of fault or liability.

To report a suspected vulnerability or incident to us, write to security@codaslabs.com.

9. Impact assessments

On your reasonable request, we will give you reasonable help with data protection impact assessments and with prior consultations with a supervisory authority, taking into account the nature of the processing and the information available to us.

10. Subprocessors

You give general written authorization for us to engage the subprocessors listed at tore.ai/legal/subprocessors, which is also reproduced in Annex III. For each one we will:

• Impose data protection obligations by written contract that are at least as protective as those in this DPA.
• Remain fully liable to you for that subprocessor’s performance, as if we had done the work ourselves.
• Give the subprocessor access only to the categories of data it needs for the function described in Annex III.

Notice, objection, and what you can do about it

• Notice: we will publish an intended addition or replacement on the subprocessor page at least 30 days before that subprocessor starts processing Customer Personal Data. Email legal@codaslabs.com to be put on the notification list, and you will get the same notice by email.
• Objection: you may object on reasonable data protection grounds within 30 days of the notice, by writing to us and saying what the ground is.
• What we do: we will work with you in good faith to find a change that resolves the objection, which may include not routing your data through that subprocessor.
• Your remedy if we cannot: if within 30 days of your objection we cannot offer a reasonable alternative, you may terminate the affected part of the Service on written notice, and we will refund any prepaid fees covering the period after termination on a pro rata basis. That refund is your only remedy for the objection.
• Urgent replacements: if a subprocessor has to be replaced faster than 30 days for security or continuity reasons, we will tell you as soon as we can, and your objection and termination rights above still apply after the fact.

11. International transfers

We are established in the United States and we process there. Where a transfer of Customer Personal Data needs a valid transfer mechanism under Data Protection Laws, the following apply and are incorporated into this DPA by reference.

European Economic Area

The SCCs apply, completed by the details in Annex I, Annex II and Annex III.

• Module Two (controller to processor) applies where you act as controller.
• Module Three (processor to processor) applies where you act as a processor on behalf of a third-party controller.
• Clause 7 (the docking clause) applies. A further party may accede to the SCCs as an exporter or an importer by completing the annexes and signing, without renegotiating this DPA.
• Clause 9 option 2, general written authorization, applies. The notice period for a change of subprocessor is 30 days, as set out in clause 10 above.
• Clause 11(a), the optional independent dispute resolution body, is not elected.
• Clause 17 option 1 applies, and the SCCs are governed by the law of Ireland. Clause 18(b): disputes under the SCCs go to the courts of Ireland. This is different from the governing law of the rest of the agreement, which is North Carolina, and it is deliberate: the SCCs require the law of an EU member state that allows third-party beneficiary rights.

United Kingdom

The UK Addendum applies to transfers subject to UK Data Protection Laws. It amends the SCCs as set out in its Part 2 mandatory clauses. Tables 1 to 4 are populated in Annex III. Under Table 4, neither party may end the UK Addendum when the ICO issues a revised approved addendum, except that we may do so if the revision materially changes our obligations.

Switzerland

For transfers subject to the FADP, the SCCs apply with these adaptations:

• References to the GDPR are read as references to the FADP, so far as the processing falls under the FADP.
• The competent supervisory authority is the Swiss Federal Data Protection and Information Commissioner, and Annex I(C) is read accordingly.
• References to a Member State or to EU member state law are read as including Switzerland, and data subjects in Switzerland may enforce their rights in Switzerland.
• Until the revised FADP position says otherwise, the term personal data also covers data about legal entities.

Supplementary measures

Where required, we will apply supplementary technical, organizational and contractual measures designed to give protection essentially equivalent to that guaranteed in the EEA or the UK. The technical ones are listed in Annex II. We have not received a government request for Customer Personal Data. If we receive one we will challenge it where there is a reasonable basis to, and tell you unless we are legally prohibited from doing so, in which case we will use reasonable efforts to get a waiver.

What we have not done

We have not appointed a representative in the European Union or the United Kingdom under Article 27 of the GDPR or the UK GDPR. A reviewer will look for one, so we would rather say it here than leave a blank. If your procurement process requires an appointed representative, tell us at legal@codaslabs.com and we will tell you where that stands.

12. Audit

We will make available to you the information reasonably necessary to demonstrate compliance with this DPA. In the first instance that means our security documentation, our policies, and a completed response to your security questionnaire.

We do not hold a SOC 2 report, an ISO 27001 certificate, or any other independent attestation, and we have not commissioned a third-party penetration test. We are not going to point you at a report that does not exist. If and when we obtain one, our then-current report will satisfy your audit rights under this clause as the primary evidence of compliance, and an on-site audit will be limited to what the report does not cover.

Where Data Protection Laws give you an audit right beyond that:

• Frequency: once per calendar year.
• Notice: at least 30 days’ prior written notice.
• Who: you, or an independent third-party auditor we both agree on who is not a competitor of ours and who is bound by confidentiality obligations at least as protective as those in the Terms of Service.
• Scope and conduct: limited to systems and records relevant to the processing of your Customer Personal Data, during normal business hours, in a way that does not disrupt our operations, and never in a way that would give the auditor access to another customer’s data.
• Cost: you bear your own costs and the auditor’s costs. We bear our own costs for the first audit in any twelve-month period. For any additional audit, and for any audit that takes more than two of our working days, we may charge our reasonable costs of supporting it at our then-current professional services rate.
• Results: audit reports are our confidential information. You may share them with a regulator on request.

More frequent audits may take place only in response to a documented personal data breach affecting your data, or a specific written request from a regulator with jurisdiction over you.

13. Return and deletion

On your written request, or on termination of the Service, we will at your option return or delete Customer Personal Data.

• Export first. You can export your data from the Service at any time during the subscription, and for 30 days after termination.
• Active systems: 30 days. We delete Customer Personal Data from active production systems within 30 days of your request or of the end of the export window, whichever is later.
• Object storage. Attachments, bug capture artifacts and inbound email bodies live in object storage, which is deleted in the same pass. Where a bucket keeps non-current versions of an object, the deletion is only treated as verified if those versions are proven to expire within 30 days.
• Backups: up to 90 days. Encrypted database backups age out on their own rolling schedule and in no event later than 90 days after the deletion request. We do not selectively edit a backup, because a hand-edited backup is not a backup. Backups are not restored except for disaster recovery, and if we ever restore one we re-run the deletion against the restored data.
• Verified, not asserted. Deletion runs a verification pass afterwards that counts the rows left in every table the registry says could hold your data, enumerates the objects and non-current object versions left in each of the five blob stores, and records the date the backup window closes. If anything is left behind, the run is recorded as failed rather than complete. We can give you that record.
• Legal holds. Where a law requires us to keep something, we keep only that, we keep it under the protections in this DPA, and we delete it when the requirement ends. Today the practical cases are billing records and audit records we are obliged to retain.

Audit events have their own clock. They are retained for 90 days by default, you can change that for your organization, and they are removed by a separate purge role rather than by the application.

14. US state privacy laws

This clause applies where you are a business or controller and we process Customer Personal Data on your behalf under the CCPA, the Virginia Consumer Data Protection Act, the Colorado Privacy Act, the Connecticut Data Privacy Act, the Utah Consumer Privacy Act, the Texas Data Privacy and Security Act, the Oregon, Montana, Delaware, Iowa, New Hampshire, New Jersey, Minnesota, Maryland, Tennessee, Indiana, Kentucky and Rhode Island consumer privacy laws, and any other US state consumer privacy law of substantially similar scope as it comes into force.

The commitments below are our service provider, processor or equivalent obligations under each of those laws.

• We are a service provider and a processor. We are not a third party. We receive Customer Personal Data only to perform the Service for you under a written contract, which is this DPA.
• We do not sell Customer Personal Data and we do not share it for cross-context behavioral advertising. We receive no consideration of any kind for it. This is not a disclosure we make in exchange for something; there is nothing on the other side of it.
• We do not retain, use or disclose Customer Personal Data for any purpose other than performing the Service for you, or as otherwise permitted by the applicable law, and never outside the direct business relationship between us.
• We do not combine Customer Personal Data with personal information received from another source, except where the applicable law permits it in order to perform the Service for you.
• We do not use Customer Personal Data for targeted advertising or for cross-context behavioral advertising, and we do not use it to build or improve a profile of any individual for our own purposes.
• We do not train models on your content, and the AI vendors named in Annex III are used under business terms that prohibit them from training on it.
• We will comply with the applicable law, give you the help you need to respond to consumer rights requests, and let you take reasonable and appropriate steps to confirm we are using Customer Personal Data in a way consistent with your obligations.
• We will tell you promptly if we determine we can no longer meet an obligation under an applicable US state privacy law, and you may then take reasonable steps to stop and remediate any unauthorized use.
• Every subprocessor in Annex III is engaged under a written contract holding it to obligations substantially equivalent to this clause, so that each is a service provider or processor under those laws too.
• Deidentified data. If we produce deidentified data, we will not attempt to reidentify it, we will keep technical and process safeguards against reidentification, and we will bind any recipient to the same.

This clause covers our role as your service provider only. Where we act as an independent controller or business, as described in clause 2, our Privacy Policy governs, and we do not sell or share personal information in that role either.

15. Liability

Each party’s liability arising out of or relating to this DPA, whether in contract, tort or otherwise, is subject to the exclusions and limitations of liability in the Terms of Service, and any liability under this DPA counts toward that same cap rather than sitting on top of it.

Said plainly: there is no separate, higher cap for a data breach claim. Today the Terms of Service cap our total liability at the amount you paid us in the twelve months before the claim arose. Some vendors offer a multiple of fees for security claims. We do not, at this stage of the company. If a super-cap is a requirement for you, raise it at legal@codaslabs.com before you sign rather than after.

Nothing in this DPA limits liability that cannot lawfully be limited, and the carveouts in the Terms of Service, including fraud, apply equally here. Nothing in this clause limits a data subject’s rights under the SCCs.

16. Changes to this DPA

We may update this DPA to reflect a change in Data Protection Laws, in regulatory guidance, in our subprocessors, or in how the product processes data. Where a change is material we will give you notice by email or in the product before it takes effect. Where a change is required by law and we cannot give advance notice, we will tell you as soon as we can.

17. Order of precedence

If this DPA conflicts with the Terms of Service, this DPA governs for matters of data protection. If this DPA conflicts with the SCCs or the UK Addendum, those clauses govern. Where the UK Addendum and the SCCs conflict, the UK Addendum governs for transfers subject to UK Data Protection Laws.

Annex I. Description of the processing

A. The parties

B. Description of the transfer

Categories of data subject

• Your customers and prospective customers who contact your support, or who submit a bug report, a feature request or a survey response.
• Your own staff and contractors who use Tore, whose account and activity records sit in your workspace.
• People incidentally named in the content of a message, a bug capture or a knowledge base article, because someone wrote about them.

Categories of personal data

Sensitive data, and the restrictions applied to it

Tore is not designed for special categories of personal data under Article 9 of the GDPR, for criminal offence data under Article 10, or for payment card data, government identifiers, or protected health information. Do not configure it to collect them, and do not upload them. We do not offer a HIPAA Business Associate Agreement and Tore must not be used for protected health information.

Because bug capture is the one surface where sensitive data could arrive by accident, these restrictions are applied to it in the product rather than being left to a policy:

• Every capture kind is off until you turn it on, per widget, and the reporter is shown a consent step before a capture is taken.
• Every input, textarea, select and rich text field is masked in a capture, and that is not a setting you can turn off.
• Password fields, iframes, canvas, video and audio elements are blocked outright rather than masked, so nothing from them is recorded at all.
• Request and response bodies are never captured from the network trail, only the request line and timing. That is fixed, not configurable.
• Fields tagged with your own selectors, or with a private-data attribute, are masked in addition to the built-in list.
• Text artifacts, meaning the console output, the network trail and the DOM snapshot, then go through a server-side redaction pass that removes API keys and tokens, high-entropy strings, email addresses, phone numbers and national identifiers, and flags text that looks like an instruction to a model.
• That redaction runs as a background worker after the artifact is stored, not before. Until it completes, the artifact is not viewable, and if the pass fails the artifact is quarantined rather than released.
• Pixels are a different story, and you should know it before you enable them. A screenshot or a session replay carries the masking and blocking applied in the reporter’s own browser, and is not scrubbed again on our side. A screen recording is stored without any redaction at all and rests entirely on the reporter’s recorded consent. If a group is flagged as sensitive, its screenshots and replays are quarantined and deleted rather than released. Screen recording is off unless you turn it on, and session replay cannot currently be turned on at all.

Frequency of the transfer

Continuous, for the duration of the subscription. Data arrives whenever a person contacts your support, submits a capture, or your staff use the product.

Nature and purpose of the processing

As set out in clause 3, and specifically:

• Receiving, storing, displaying and searching support conversations.
• Receiving and sending email on your behalf, and handling bounces.
• Storing and redacting bug capture artifacts.
• Indexing your knowledge base, which involves generating embeddings.
• Submitting content to AI models to triage a queue, draft a reply, summarize a thread, or investigate a bug.
• Reading a connected repository and preparing a proposed change for a person on your team to approve.
• Billing, support, security monitoring and backup.

Retention period

• Customer Personal Data is kept for the life of the subscription, then deleted per clause 13: 30 days for active systems, up to 90 days for backups.
• Audit events: 90 days by default, configurable by your organization.
• Text bug capture artifacts are replaced by their redacted derivative once the redaction pass completes, and a quarantined artifact is not released at all. Screenshots, replays and recordings are retained as captured, subject to the same organization-level deletion.
• Expired authentication sessions are deleted 30 days after they expire.
• Deletion of a single contact, and deletion of a whole organization, are both driven by a per-table registry so that the retention answer for a table is written down rather than inferred.

Transfers to subprocessors

The subject matter, nature and duration of the processing carried out by each subprocessor is set out in Annex III. Each subprocessor processes for the duration of our agreement with it and for no longer than we retain the underlying data.

C. Competent supervisory authority

Determined under Clause 13 of the SCCs by reference to your own position as the exporter:

• Where you are established in an EEA member state, the supervisory authority of that member state.
• Where you are not established in the EEA but have appointed an Article 27 representative, the supervisory authority of the member state where that representative is established.
• Where you are not established in the EEA and are not required to appoint a representative, the supervisory authority of the member state in which the data subjects whose data is transferred are located.
• For UK transfers, the Information Commissioner’s Office. For Swiss transfers, the Federal Data Protection and Information Commissioner.

Annex II. Technical and organizational measures

These are the measures we take under Article 32 of the GDPR and Clause 8.6 of the SCCs. They are listed one at a time on purpose. Anything not on this list, we are not claiming.

Pseudonymization and encryption

• All traffic to and from the Service is encrypted in transit with TLS.
• Data at rest is encrypted by the underlying providers: the managed Postgres database, the object storage buckets, and the Redis queue.
• API keys are never stored. We store a keyed HMAC-SHA256 digest of the key, the public prefix, and the last four characters. A leak of the database does not yield a usable key, and comparison at authentication time is constant-time.
• Credentials you give us for a connected integration are stored in a secrets vault. The database holds a reference to the secret, not the secret.
• Text bug capture artifacts, meaning console output, network trails and DOM snapshots, are redacted so that secrets, tokens, email addresses, phone numbers and national identifiers are replaced with markers before anyone can view them. Screenshots and replays carry only the masking applied in the browser, and screen recordings are stored unredacted under the reporter’s consent. See Annex I(B).

Tenant isolation

• Separation between customer organizations is enforced by Postgres row-level security, not by application code remembering to add a filter. Every tenant-scoped query runs inside a transaction that sets the tenant identifier as a transaction-local setting, and the database policy compares each row against it.
• Row-level security is set to forced on those tables, so it applies to the table owner too.
• The setting is transaction-local by construction, which is what stops a pooled connection from carrying one tenant’s identity into another tenant’s request.
• The application role does not have the privilege to bypass row-level security.
• Background jobs carry a signed payload and re-assert the organization at the moment they claim the job, so a job cannot be replayed against a different tenant.

Access control

• Access to production systems follows least privilege and is limited to the small number of people who operate the Service.
• Inside a customer organization, access is governed by role and by product scope, so a member can be restricted to a subset of products.
• API keys carry coarse, stable scopes (support, knowledge and feedback, each read or write) and cannot be issued with more permission than the person issuing them holds.
• Keys can be given an expiry, can be revoked immediately, and can be rotated with a bounded overlap window so a rotation does not require an outage.
• Separate database roles exist for the application, for control-plane writes, for the audit purge, for the audit anchor, for the credential mail sweeper and for erasure. Each is provisioned with only the privileges its job needs, and the provisioning script fails if a role ever gains a privilege it should not have.
• Administrative impersonation of a customer organization is recorded as its own audit event, at the start, at the end, and on every write performed while impersonating.

Logging and accountability

• Security-relevant actions are written to an audit trail: sign-in events, organization access, role and scope changes, API key issue and revocation, data export, viewing a bug capture artifact, downloading an attachment, credential changes on a connected integration, and administrative overrides.
• The audit trail is append-only. UPDATE and DELETE are revoked from the application role at the database level, so an application bug, or an attacker holding the application role, cannot rewrite or erase history.
• Removal of expired audit events is done by a separate role that can delete but cannot insert, so the role that writes history cannot remove it and the role that removes it cannot forge it. The provisioning script asserts both of those and refuses to run if either drifts.
• The timestamp on an audit event is set by a database trigger, not by the caller.

Restrictions on what is collected

• Every bug capture kind is off by default and enabled by you, per widget.
• All form inputs are masked in a capture, unconditionally.
• Password fields, iframes, canvas, video and audio are blocked entirely.
• Network request and response bodies are never captured.
• Per-artifact and per-capture size ceilings are enforced at ingest.
• A capture is taken only after the reporter passes a consent step, and the consent version is recorded with the capture.

Source code access

• Repository access is through a GitHub App you install and can revoke at any time, on the repositories you choose. We do not ask for a personal access token.
• The App requests three narrow permission sets and nothing else: read-only contents and metadata to investigate; read-only pull requests and administration to establish provenance; and, only for publishing a fix, write access to contents and pull requests.
• The fix path deliberately has no access to repository administration, to workflows, or to checks, so it cannot change your repository settings or your CI.
• Every repository operation mints its own short-lived, narrowly scoped token internally and never returns it to the calling code, so there is no long-lived token for an executor to hold, log or leak.
• A proposed change is published only if the tree the host computes matches the digest a person on your team approved, byte for byte. Otherwise the commit is refused.
• A proposed change that touches a locked risk class (authentication, billing, migrations, secrets, or tenant isolation) is escalated to a person rather than proposed automatically, and a file path that cannot be classified is escalated too rather than allowed through.
• Nothing merges on its own. Tore opens a pull request. Your existing review and branch protection rules apply exactly as they would to a human contributor.

Software and change management

• Every change runs through automated lint, type checking, unit and integration tests, and a build, before it can be merged.
• Every change gets an independent review, and changes touching authentication, billing, migrations, tenancy, secrets or the fix executor get a second, adversarial review from a different reviewer before merge.
• Dependencies are pinned by a lockfile, and secrets are kept out of source control.
• Database migrations are replayed on a fresh database in the pipeline, so a migration that only works against an existing database does not reach production.

Availability and resilience

• Managed Postgres with automated, encrypted backups.
• Background work runs through a durable queue with retries, so a transient failure does not silently drop a job.
• Health monitoring, error tracking and alerting on production.
• Infrastructure is defined in configuration held in source control, so a rebuild is reproducible.

Verification of deletion

• Deletion is driven by a per-table registry that records, for every table, whether it holds end-customer personal data and whether the correct treatment is deletion, anonymization, or nothing.
• A verification pass runs after deletion. It counts the rows remaining in each table, enumerates the objects and non-current object versions remaining in each of the five blob stores, and records the date the backup window closes.
• The run is marked failed, not complete, if anything remains, or if a bucket cannot prove its non-current versions expire within 30 days.

Organizational measures

• Written confidentiality obligations for everyone with access.
• Access reviewed when a role changes and revoked when it ends.
• Disk encryption and screen lock required on machines with access.
• A written incident response path with a single reporting address, security@codaslabs.com.
• Vendor review before a subprocessor is engaged, and the public list in Annex III kept current.

Measures we do not have

Listed here rather than left out, because the omission is the thing a reviewer would notice.

• No SOC 2 report, of any type.
• No ISO 27001 or other certification.
• No third-party penetration test report.
• No HIPAA Business Associate Agreement.
• No appointed Article 27 representative in the EU or the UK.
• No customer-facing multi-factor authentication or single sign-on yet.
• No formal, externally audited business continuity or disaster recovery exercise.

Annex III. Subprocessors, and the UK Addendum tables

Approved subprocessors

This is the list in force on the date at the top of this page. The canonical, current version lives at tore.ai/legal/subprocessors, and that page governs if the two ever differ.

UK Addendum, Tables 1 to 4

Not subprocessors

Two things a reviewer often expects to find here, and why they are not on the list:

• Your own AI provider key. If you connect your own key, your content goes to your own account with that vendor under your own agreement with them. We are the conduit, not the contracting party, and our terms with that vendor do not apply to it.
• Systems you connect on your own side. A repository you give the GitHub App access to, or a tool you integrate, is a customer-directed flow. GitHub appears on the list because we hold the App credential; a tool you push data into from your own systems does not.

Contact

Questions about this DPA, or a request for a countersigned copy: legal@codaslabs.com. Privacy questions and data subject requests: privacy@codaslabs.com. Security reports: security@codaslabs.com. Abuse: abuse@codaslabs.com.

Codas Labs, LLC, a North Carolina limited liability company. We have not appointed a data protection officer, because we are not required to. The addresses above reach the people who make these decisions.