Data Processing Addendum

1. Definitions

“GDPR”, “Personal Data”, “Data Subject”, “Processing”, “Controller”, “Processor”, “Sub-processor”, “Personal Data Breach” and “Supervisory Authority” have the meanings given in the GDPR. “SCCs” means the Standard Contractual Clauses approved by EU Commission Decision 2021/914. “UK IDTA” means the International Data Transfer Addendum to the SCCs issued by the United Kingdom Information Commissioner's Office under section 119A of the Data Protection Act 2018.

2. Subject matter and duration

Processor will Process Personal Data on behalf of Controller for the duration of the Service Agreement, solely to provide the OrgMCP platform — a multi-tenant MCP server with retrieval-augmented knowledge over Customer-provided sources.

3. Nature and purpose of processing

• Hosting Customer accounts (workspace, members, groups, audience filters).
• Indexing Customer-supplied documents and computing retrieval embeddings to enable retrieval-augmented generation by AI agents and Customer-installed MCP clients.
• Operating audit logs, billing, abuse-prevention and security telemetry.
• Sending transactional email (invites, billing receipts, security notices).

4. Categories of data subjects

• Controller's employees, contractors, and authorised end users.
• Individuals identified in documents that Controller chooses to ingest.

5. Categories of Personal Data

• Identity and contact data (name, email, profile photo, organization membership, role).
• Authentication metadata (WorkOS user ID, last-login timestamp, IP address, user-agent, session identifiers).
• Usage telemetry (tool invocations, audit-log events).
• Any Personal Data contained in Customer-supplied documents and chat-style queries submitted to the MCP server. Controller is responsible for ensuring it has a lawful basis to ingest such content.

6. Processor obligations

1. Process Personal Data only on documented instructions from Controller (including those in this DPA and the platform's configuration UIs), unless required to do so by EU or Member-State law.
2. Ensure that personnel authorised to Process Personal Data are contractually bound to confidentiality.
3. Implement the technical and organisational measures described in Annex II (Security Measures) below.
4. Use only the Sub-processors listed in Annex III, and notify Controller at least 30 days in advance of any change to that list (Controller may object as set out in Annex III).
5. Provide reasonable assistance to Controller in responding to Data Subject requests, Data-Protection Impact Assessments, and Supervisory-Authority consultations, taking into account the nature of the Processing and the information available to Processor.
6. Notify Controller without undue delay (and in any case within 72 hours) of becoming aware of a Personal Data Breach, with the information then available; supplement that notification as further detail is established.

7. International transfers

Personal Data is hosted in the EU (AWS eu-central-1, Frankfurt) by default. Where Sub-processors process Personal Data outside the EEA, transfers are governed by the SCCs (Module 2 controller → processor, or Module 3 processor → sub-processor as applicable), supplemented by the technical safeguards in Annex II. UK transfers are additionally governed by the UK IDTA (Section 12 below).

8. Audits

Controller may, no more than once per year (more often if reasonably required by a Supervisory Authority or following a Personal Data Breach), request: (a) a copy of Processor's most recent SOC 2 Type II report when available; in the interim, the current SOC 2 readiness summary; (b) responses to a reasonable security questionnaire; and (c) an on-site audit conducted with at least 30 days' written notice, during normal business hours, at Controller's expense, and subject to confidentiality. Both parties will work in good faith to minimise disruption to the Service.

9. Deletion and return

Upon termination of the Service Agreement, Controller may export its data via the GDPR-export API. Processor will delete all Customer Personal Data within 30 days of termination, except where retention is required by law (financial records: 7 years per Estonian Raamatupidamise seadus § 12). Backups created during the retention period are cycled out within a further 35 days.

10. Liability and order of precedence

Each party's aggregate liability arising out of or related to this DPA, the SCCs and the UK IDTA is subject to the limitation of liability set out in the Terms of Service, unless a higher cap is mandated by applicable data-protection law. In case of any conflict between this DPA and the Terms of Service, this DPA controls for matters concerning the Processing of Personal Data; the Terms of Service control otherwise. In case of any conflict between this DPA and the SCCs / UK IDTA, the SCCs and UK IDTA control to the extent of the conflict.

11. Standard Contractual Clauses

Where Processor transfers Personal Data outside the EEA to a country that is not the subject of an adequacy decision, the parties hereby incorporate by reference the SCCs as follows:

• Module 2(controller → processor) applies where Controller is established inside the EEA and Processor processes the Personal Data outside the EEA on Controller's instructions.
• Module 3 (processor → sub-processor) applies between Processor and any non-EEA Sub-processor listed in Annex III.
• Clause 7 (docking) — included. Clause 9 (sub-processors) — Option 2 (general written authorisation) with 30 days' advance notice. Clause 11 (redress) — option not used. Clause 17 (governing law) — laws of Estonia. Clause 18 (forum and jurisdiction) — courts of Estonia. Annex I.A (parties), I.B (description of transfer), I.C (competent supervisory authority — Andmekaitse Inspektsioon), II (security measures), and III (sub-processors) of the SCCs are populated by Sections 4, 5, Annex II and Annex III of this DPA respectively.

12. UK transfers (IDTA)

For transfers of Personal Data subject to the UK GDPR, the UK IDTA is incorporated by reference and Tables 1, 2 and 3 of the UK IDTA are completed using the corresponding Annexes of this DPA. Table 4 (ending the IDTA): both parties may end the IDTA. Any conflict between the SCCs (Section 11) and the UK IDTA is resolved in favour of the UK IDTA for transfers of Personal Data of data subjects in the United Kingdom.

13. Transfer Impact Assessment

Processor maintains a Transfer Impact Assessment (TIA) for each non-EEA Sub-processor listed in Annex III, addressing the Schrems II factors (legal regime of the recipient jurisdiction, history of public-authority access requests, supplementary technical and organisational measures). A copy of the current TIA is provided on written request to privacy@orgmcp.io, no more than once per 12-month period, subject to confidentiality.

14. Changes to this DPA

Processor may amend this DPA from time to time. Material changes will be notified with at least 30 days' advance notice via email to the Workspace owner and an in-app banner. If a change has a material adverse effect on the protection of Controller's Personal Data, Controller may terminate the affected processing (and, at its option, the related portion of the Service) by written notice during the 30-day window without prejudice to fees accrued.

Annex I — Details of Processing

See Sections 2 to 5 above.

Annex II — Security Measures

Mirrors the controls in our internal architecture documentation (docs/ARCH-security-compliance.md). Specifically:

• Encryption. TLS 1.2+ in transit (terminated at the AWS Application Load Balancer with HSTS); AES-256 at rest via AWS KMS for RDS storage and S3 (SSE-KMS).
• Tenant isolation. Strict Postgres Row-Level Security enforced via thewithTenantContext request-scoped session role; the elevated gigamcp_service role is restricted to the internal admin console.
• Retrieval audience filter. OpenSearch queries are mandatory-filtered by tenant_id and audience tags in server-side middleware; cross-tenant retrieval is architecturally impossible.
• Edge protection. AWS WAFv2 in front of the load balancer (AWS managed Common Rule Set, Known Bad Inputs, SQLi, plus a per-IP rate limit of 2,000 requests per five-minute window). WAF logs are written to CloudWatch with 30-day retention and have their Authorization, Cookie and X-Api-Key headers redacted.
• Audit trail. Per-tenant audit log, RLS-isolated, retained per the table below.
• Secret management. AWS Secrets Manager with KMS key separation per tenant prefix; OAuth refresh tokens are never written to application logs.
• Monitoring. Sentry (eu.sentry.io) with PII scrubbing; CloudWatch alarms with on-call alerting; 4xx events are dropped before transmission.
• Backup. Automated encrypted RDS backups with point-in-time recovery, retained for 14 days.
• Change control. All code changes flow via GitHub pull requests with required reviewers; no force-push to main; deploys are gated by CI.
• Penetration testing. Independent third-party penetration testing and SOC 2 attestation are planned but not yet complete; status will be published on trust.orgmcp.io when available.

Audit-log retention by plan tier. Renders identically here and in the Privacy Policy:

Annex III — Approved Sub-processors

The current list of Sub-processors is published at /legal/sub-processors and updated whenever it changes. Customers with notify_subprocessor_changes = true receive 30-day advance notice of any addition or replacement and may object in writing before the change takes effect; if the objection cannot be resolved, Customer may terminate the affected processing.

Contact

Privacy / DPO contact: privacy@orgmcp.io. Legal: legal@orgmcp.io.

Changelog

• v2.0 — 12 May 2026 — Added §10 (liability and order of precedence), §11 (SCC incorporation, Module 2 and 3, with the parameter choices spelled out), §12 (UK IDTA), §13 (Transfer Impact Assessment on request) and §14 (change mechanism). Expanded Annex II to mirror the actual security controls in docs/ARCH-security-compliance.md. Audit-log retention now sources from the same table as the Privacy Policy.
• v1.0 — 1 April 2026 — Initial publication.