Data Processing Addendum
Effective date: September 22, 2026
This Data Processing Addendum (the "DPA") forms part of the Terms of Service or other written agreement (the "Agreement") between Seros, LLC ("Processor", "we") and the customer identified in the Agreement ("Controller", "you"). It applies where we process personal data on your behalf in providing the Service.
If the Agreement and this DPA conflict on the processing of personal data, this DPA wins.
1. Definitions
Terms such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in the GDPR. "Data Protection Laws" means all laws applicable to the processing under this DPA, including the EU General Data Protection Regulation (Regulation (EU) 2016/679) ("GDPR"), the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA/CPRA"), and other US state privacy laws as they apply.
"Customer Personal Data" means personal data contained in Customer Data. "SCCs" means the Standard Contractual Clauses annexed to European Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the UK Information Commissioner's International Data Transfer Addendum to the SCCs, version B1.0. "Subprocessor" means a processor we engage to process Customer Personal Data.
2. Roles of the parties
2.1 For Customer Personal Data, you are the controller (or a processor acting for another controller) and we are the processor (or subprocessor). If you are acting as a processor for a third-party controller, you confirm you have authority to give the instructions in this DPA on that controller's behalf.
2.2 For our own account, billing, security and telemetry data about you and your users, we are a controller and our Privacy Policy applies.
2.3 Under the CCPA/CPRA we are a "service provider". We will not sell or share Customer Personal Data, will not retain, use or disclose it for any purpose other than the business purposes specified in the Agreement, will not use it outside the direct business relationship between us, and will not combine it with personal information from other sources except as permitted for a service provider. We certify that we understand and will comply with these restrictions.
3. Processing instructions
3.1 We will process Customer Personal Data only on your documented instructions. The Agreement, this DPA, your configuration of the Service, and the connections you authorise are your complete instructions.
3.2 We will tell you if, in our opinion, an instruction infringes Data Protection Laws. We may suspend processing of an instruction we reasonably believe is unlawful until it is resolved.
3.3 If a law requires us to process beyond your instructions, we will inform you before processing unless that law prohibits it on important grounds of public interest.
3.4 You are responsible for the lawfulness of the personal data you submit, for having a legal basis, for giving required notices to data subjects, and for the accuracy of the data.
4. Confidentiality
We will ensure that personnel authorised to process Customer Personal Data are bound by written confidentiality obligations or an appropriate statutory duty, are trained on data protection, and have access limited to what their role requires.
5. Security
5.1 We will implement and maintain the technical and organisational measures described in Annex II, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk to individuals.
5.2 We may update the measures over time. We will not materially reduce the overall level of protection during an engagement.
5.3 We do not hold SOC 2, ISO 27001 or any other security certification and this DPA should not be read as claiming one.
6. Subprocessors
6.1 You give general written authorisation for us to engage Subprocessors. The current list is at Subprocessors, which also explains how to subscribe to change notifications.
6.2 We will impose data protection obligations on each Subprocessor that are no less protective than those in this DPA, and we remain fully liable to you for a Subprocessor's performance.
6.3 Change notice. We will give at least 30 days' notice before a new Subprocessor starts processing Customer Personal Data, by email to subscribers of the list. You may object on reasonable data protection grounds within 15 days. If you object, we will work in good faith to offer a change in configuration or an alternative. If we cannot within a reasonable time, you may terminate the affected Statement of Work and receive a refund of prepaid fees for work not performed, as your sole remedy.
6.4 Where a change is needed urgently to protect security or continuity, we may appoint a Subprocessor first and notify promptly afterwards, with the same objection right applying from the date of notice.
7. Assistance with data subject requests
7.1 Where we have built or host a system for you, it gives you controls to access, correct, export and delete Customer Personal Data yourself. You should use them first.
7.2 If a data subject contacts us directly about Customer Personal Data, we will not respond substantively; we will forward the request to you promptly, unless legally prohibited.
7.3 Taking into account the nature of the processing, we will help you respond to requests under Data Protection Laws by appropriate technical and organisational measures, insofar as this is possible. Assistance beyond a system's own features may be charged at $150 per hour where the request is repetitive or unreasonably burdensome.
8. Assistance with DPIAs, consultations and security
Taking into account the nature of the processing and the information available to us, we will provide reasonable assistance with your data protection impact assessments and any prior consultation with a supervisory authority under GDPR Articles 35 and 36, and with your obligations under Articles 32 to 34. Reasonable assistance normally means completing a security questionnaire, providing our documentation, and answering specific questions.
9. Personal data breach
9.1 We will notify you without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Personal Data.
9.2 The notice will describe, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point for more information. We will supplement the notice as the investigation develops.
9.3 We will take reasonable steps to contain and mitigate the breach and will cooperate with your investigation and your notifications to supervisory authorities and data subjects.
9.4 Notifying you is not an admission of fault or liability.
10. Deletion and return
10.1 During an engagement you may export Customer Personal Data through the controls of any system we host for you, or by asking us.
10.2 On termination, and at your choice, we will delete or return Customer Personal Data. Absent an instruction, we will make it available for export for 30 days after termination, then delete or irreversibly anonymise it within 30 days.
10.3 Copies in encrypted backups are deleted on the backup cycle, up to 35 days, and remain protected by this DPA until they are.
10.4 We may retain Customer Personal Data where a law requires it, and only for as long and for the purpose that law requires.
10.5 We will certify deletion in writing on request.
11. Audits
11.1 On request, and no more than once in any twelve-month period unless a supervisory authority requires more or a personal data breach has occurred, we will make available information necessary to demonstrate compliance with this DPA. In the first instance this means our written security documentation and a completed security questionnaire.
11.2 If that is not sufficient for your obligations under GDPR Article 28(3)(h), you may carry out an audit or mandate an independent auditor who is not our competitor and who signs a confidentiality agreement. Audits require at least 30 days' notice, must occur during business hours, must not unreasonably disrupt our operations, and must respect the confidentiality and security of other customers' data. You bear your own costs and reimburse our reasonable costs at $150 per hour beyond the first audit in a period.
11.3 We are not obliged to give access to systems, premises or data where doing so would breach a duty to another customer or to a third party.
12. International transfers
12.1 We process Customer Personal Data in the United States and may use Subprocessors in the locations listed in Subprocessors.
12.2 EEA transfers. Where you transfer Customer Personal Data subject to the GDPR to us in a country without an adequacy decision, the SCCs are incorporated into this DPA by reference and apply as follows: - Module Two (controller to processor) where you are a controller. - Module Three (processor to processor) where you are a processor for another controller. - Clause 7 (docking clause): applies. - Clause 9: Option 2, general written authorisation, with the notice period in Section 6.3. - Clause 11: the optional independent dispute resolution body language does not apply. - Clause 17: governed by the law of Ireland. - Clause 18(b): disputes resolved before the courts of the same member state. - Annex I and Annex II of the SCCs are the Annex I and Annex II of this DPA. - Annex III (list of subprocessors) is Subprocessors.
12.3 UK transfers. The UK Addendum is incorporated and applies to transfers subject to the UK GDPR. Table 1 is completed by Annex I; Tables 2 and 3 by Section 12.2 and the Annexes; in Table 4, the party that may end the Addendum is the importer.
12.4 Swiss transfers. The SCCs apply with these changes: references to the GDPR are read as references to the Swiss FADP; the competent authority is the Federal Data Protection and Information Commissioner; and "member state" is read so as not to deprive data subjects in Switzerland of the right to sue in their place of habitual residence.
12.5 We do not currently claim certification under the EU-US Data Privacy Framework or its UK Extension. Do not rely on the DPF for these transfers unless and until this DPA says otherwise.
12.6 We will notify you if we become subject to a legally binding request from a public authority for Customer Personal Data, unless prohibited, and will challenge requests that appear unlawful.
13. Liability
Each party's liability under this DPA is subject to the limitations and exclusions in the Agreement, except where Data Protection Laws prevent that. See the open point liability under the Data Processing Addendum sits inside the general liability cap in Section 12 in the Terms — enterprise customers often ask for a higher or uncapped liability for data protection breaches, and that is a commercial decision.
14. Term
This DPA takes effect when the Agreement does and continues until we no longer hold Customer Personal Data. Sections 4, 5, 9, 10, 12 and 13 survive as relevant.
Annex I
How to use this document. This is the Company's standard Data Processing Addendum, published so that a prospective client can review it before an engagement. The fields marked completed on signature are filled in when a specific customer executes it alongside a Statement of Work. Published in this form it is a template and an offer to contract on these terms, not an executed agreement with any party.
A. List of parties
| Field | Data exporter | Data importer |
|---|---|---|
| Name | The customer's full legal name, completed on signature | Seros, LLC |
| Address | The customer's registered address, completed on signature | Georgia, United States |
| Contact name, position, email | The customer's data protection contact name, position and email, completed on signature | Not appointed, team@seros.dev |
| Activities relevant to the transfer | Use of the Service to draft, route, assign and track tasks | Provision of the Service |
| Signature and date | On execution of the Agreement | On execution of the Agreement |
| Role | Controller, or processor for another controller | Processor |
B. Description of transfer
| Item | Detail |
|---|---|
| Categories of data subjects | The exporter's employees, contractors and other users; the exporter's customers, clients and prospects; the exporter's suppliers; and any other individual whose personal data appears in the materials or systems the exporter provides or instructs us to access for an engagement |
| Categories of personal data | Identification and contact data (name, work email, user identifiers); employment and organisational data (team and role); the content of systems and documents the exporter provides for the engagement; workflow data (assignments, due dates, status, notes); technical and security data (IP address where supplied, session, log and audit records); and any other personal data the exporter chooses to provide. The precise categories for an engagement are recorded in its Statement of Work. |
| Sensitive data | None expected. The Acceptable Use Policy prohibits submitting special category data, PHI and payment card data without a separate written agreement. If the exporter will submit special category data, describe it here and record the additional safeguards: not applicable — no special category data is accepted under this DPA without a separate signed agreement |
| Frequency of transfer | As required for the engagement; continuous where we host or operate a system for the exporter |
| Nature of the processing | Collection, recording, organisation, structuring, storage, retrieval, consultation, use, transmission to a configured AI provider where the engagement uses one, alignment, combination, restriction, erasure and destruction |
| Purpose of the processing | Performing the Services stated in the Statement of Work — scoping, building, testing, deploying and maintaining software for the exporter — and securing and supporting any system we host or operate for them |
| Retention period | For the duration of the engagement, plus the export window of 30 days and deletion within 30 days, subject to backup cycles of up to 35 days and to the archival copy permitted by Section 15.5 of the Terms |
| Transfers to subprocessors | See Subprocessors for each subprocessor, its purpose, location and retention |
C. Competent supervisory authority
The supervisory authority of the member state in which the exporter is established, or, for exporters not established in the EEA, the authority of the member state where the exporter's Article 27 representative is established, or where the data subjects are located: to be identified in the Schedule to a signed DPA, based on the exporter's establishment.
Annex II — Technical and organisational measures
Current status: no control below is implemented. The in-house application is paused and not deployed, so there is no production system for these measures to apply to. A measure is never described as in place unless it is built and verifiable. Each "Current state" cell below reads Not implemented and names the intended control, which is a plan, not a claim that anything is live. This Annex is updated as controls are built.
| Area | Measure | Current state |
|---|---|---|
| Pseudonymisation and encryption | Encryption in transit (TLS 1.2 or higher) for all external connections | Not implemented. Planned: TLS 1.2+ (1.3 preferred) terminated at the platform edge, HSTS with a long max-age, HTTP redirected to HTTPS, modern cipher suites only, and a scheduled external check that records the negotiated version. |
| Encryption at rest for databases, object storage and backups | Not implemented. Planned: provider-managed volume, bucket and backup/snapshot encryption on every store, plus application-level encryption of secret fields (e.g. integration OAuth tokens) so a database compromise does not yield usable credentials. | |
| Key management and rotation | Not implemented. Planned: a managed key service holding the master key, per-workspace data keys wrapped by it, scheduled rotation with a documented procedure, no key material in source control or logs, and CI secret scanning as a backstop. | |
| Confidentiality | Role-based access control and least privilege for staff | Not implemented. Planned: four customer-facing roles (owner, admin, confirmer, viewer) enforced on every workspace-scoped operation; no standing production access for operators — break-glass, time-boxed, justified and audit-logged; no bulk export of customer content by any operator path. |
| Multi-factor authentication on production and administrative systems | Not implemented (available today, not yet done). Planned: hardware-key or TOTP MFA on every account that can reach production (hosting, database, key service, source control, payment provider, model provider, DNS, email), no shared accounts, and a quarterly-reviewed account/MFA inventory. | |
| Background checks and confidentiality agreements for personnel | Not implemented. The company is currently one person, so there is no HR function. Planned before the first contractor: a signed confidentiality and IP agreement, a background check where lawful and proportionate, and start/end access checklists. | |
| Security awareness training | Not implemented. Planned: annual security-awareness training for anyone with production access, recorded with a date; for a solo founder, a short self-administered review against a written checklist (phishing, credential handling, device encryption, screen lock, incident reporting). | |
| Integrity | Logical tenant separation in a multi-tenant architecture | Not implemented. Planned: workspace id in every tenant-owned key, a scoped accessor that cannot build an unscoped query, database row-level security as a second line, cross-tenant reads confined to audited code paths, and a build-failing test that detects any unscoped tenant query. |
| Change management, code review and separation of duties | Not implemented (available today). Planned: protected main with no direct pushes, every change through a reviewed pull request, green CI before merge, deployment from main only, and a release log. |
|
| Input validation and secure development practices | Not implemented. Planned: schema validation on every external input (including webhooks and model responses), parameterised queries only, output encoding in the UI, a minimal-dependency policy, and a secure-coding checklist in the pull request template. | |
| Availability and resilience | Backups, tested restore procedure, recovery objectives | Not implemented. Planned: automated daily backups plus point-in-time recovery, retained per the 35 value and stored in a different region from the primary, with a monthly timed restore into a scratch environment; RPO and RTO published only after a restore has actually been timed. |
| Redundancy and failover in the hosting environment | Not implemented. Planned: a managed database with automated failover, more than one stateless application instance behind a load balancer, versioned object storage, and queues that survive a worker restart. Multi-region active-active is deliberately not promised. | |
| Business continuity and disaster recovery plan | Not implemented. Planned: a written plan covering total hosting-region loss, source-control loss, payment-provider loss and founder unavailability (including where recovery credentials are held), reviewed twice a year. | |
| Testing and evaluation | Vulnerability scanning and dependency monitoring | Not implemented. Planned: automated dependency alerts with a severity-based remediation window, a committed lockfile, scheduled base-image rebuilds, secret scanning on every push and over full history, and static analysis in CI. |
| Penetration testing cadence | Not implemented. No third-party penetration test has been performed. Planned trigger: the earlier of the first customer who requires one and the first enterprise deal; scope would be the web app, the OAuth flows and tenant isolation, with findings tracked to closure. | |
| Logging, alerting and monitoring | Not implemented. Planned: structured logs with an allowlist of fields so customer content cannot be logged by accident, a request id on every entry, retention per 12 months, an audit log, alerting on authentication failures / integration error rates / 5xx rates / inference-spend thresholds, and a test that fails if a content-classed field reaches a log formatter. |
|
| User access control | Customer-side SSO, provisioning and role management | Not implemented. Current v0 is email-based authentication with roles and admin-managed invitations. SSO and SCIM are explicitly a later (v2) roadmap item; this Annex and the security page must not imply SSO exists today. |
| Session management and credential storage (hashing algorithm) | Not implemented. Planned: a memory-hard password hashing function with per-user salts and current parameters (where passwords exist), server-side sessions with rotation on privilege change and idle/absolute expiry, secure and HTTP-only cookies, CSRF protection on every state-changing request, and integration tokens never rendered to a browser. | |
| Data minimisation | Only the data needed for a feature is sent to model providers | Not implemented. Planned: pre-filters that drop bot, join, leave, emoji-only and link-only messages before any model call; bounded context windows rather than whole threads; author identities pseudonymised unless the task requires the real name; attachments and file contents never sent in v0; and a single audited egress point that records the purpose of each model call. |
| Retention and deletion automation | Not implemented. Planned: a scheduled sweeper per table and per-workspace policy (a retention setting between 7 and 90 days) that writes a retention.swept audit event, nulls content in place, and alerts if a sweep does not run. |
|
| Incident response | Documented process, roles, and customer notification path | Not implemented. Planned: a written plan with severity levels, a single named decision-maker, a customer-notification path meeting the 72 commitment, a communications template, an evidence-preservation step and a required post-incident note, rehearsed on paper before launch. |
| Subprocessor governance | Due diligence, contracts, periodic review | Not implemented. Planned: a subprocessor register recording purpose, data categories, region, DPA status and review date; a signed DPA with every subprocessor that touches customer content; an annual review; and a rule that no vendor touches customer content before it is on the register. The register is Subprocessors; the vendor DPAs are not yet signed. |
| Physical security | Inherited from the hosting provider's data centres | Inherited, not independently implemented. Data-centre physical security is the responsibility of the hosting provider (Vercel, and Neon for the database) and would be described as inherited, referencing the provider's own attestations; no hosting environment is provisioned for production yet. Locally: full-disk encryption, screen lock, and no production credentials on an unencrypted device. |
| Deletion | Secure deletion and media sanitisation | Not implemented. Planned: deletion of a source's content within 24 hours of disconnect; whole-workspace deletion within the 30 window in dependency order, with a completion record the customer can be shown; backups aged out rather than surgically edited; and media sanitisation inherited from the hosting provider. |
Measures a subprocessor is responsible for, rather than us, should be marked as inherited and the provider named.
Annex III — Subprocessors
See Subprocessors. That list, as updated in accordance with Section 6, is Annex III for the purposes of the SCCs.
Signature
| Customer | Seros, LLC | |
|---|---|---|
| Signature | ||
| Name | The customer's authorised signatory, completed on signature | Jackson Durham |
| Title | Managing Member | |
| Date |
This DPA takes effect when signed by both parties.