Data Processing Addendum
1. Parties and incorporation
This Data Processing Addendum ("DPA") forms part of the Terms of Service at Terms of Service, or of any signed agreement that references it, between:
Processor
GPT LLM ORAGLE Ltd. Liability Co.
A Wyoming close limited liability company (filing ID 2026-001932735)
Registered office: 30 N Gould St, Ste N, Sheridan, WY 82801, United States
Contact for this DPA: dpa@oraglegpt.orgreferred to as "Processor", "we", or "the Company", and
Controller - the customer identified in the order form or account record, referred to as "Controller" or "Customer".
This DPA applies where the Processor processes Personal Data on behalf of the Controller in connection with the Service. It takes precedence over the Terms of Service on data protection matters.
To execute this Addendum, email dpa@oraglegpt.org and we will return a countersigned copy. The Processor signs as the Company through an authorised signatory; the published text does not name an individual.
2. Definitions
- Data Protection Law - as applicable: Regulation (EU) 2016/679 (GDPR); the UK GDPR and Data Protection Act 2018; the Swiss FADP; the California Consumer Privacy Act as amended by the CPRA (CCPA); and other US state comprehensive privacy laws, Brazil's LGPD, and Canada's PIPEDA, in each case as they apply to the processing.
- Controller, Processor, Data Subject, Personal Data, Processing, Personal Data Breach, Supervisory Authority - as defined in GDPR. Under the CCPA the Controller is the Business and the Processor is a Service Provider.
- Customer Personal Data - Personal Data contained in Customer Content and processed by the Processor on the Controller's behalf.
- Platform Data - data obtained from a social platform under the Controller's authorisation.
- Subprocessor - a processor engaged by the Processor.
- SCCs - the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914.
- UK Addendum - the UK Information Commissioner's International Data Transfer Addendum to the SCCs, version B1.0.
3. Roles
- For Customer Personal Data, the Controller is the controller and the Processor is the processor. Where the Controller is itself a processor for its own client, the Processor is a subprocessor and the Controller warrants it has authority to appoint one.
- For account registration data, billing records, authentication and security logs, and product telemetry, the Processor acts as an independent controller under Privacy Policy. This DPA does not apply to that processing.
- Social platforms are independent controllers of the data they hold.
4. Processing instructions
- The Processor will process Customer Personal Data only on the Controller's documented instructions, which comprise this DPA, the Terms of Service, the configuration the Controller sets in its workspace, and the Controller's use of the Service's features and APIs.
- The Processor will tell the Controller if, in its opinion, an instruction infringes Data Protection Law, and may suspend the affected processing.
- If the Processor is required by law to process beyond the instructions, it will inform the Controller first unless the law prohibits it on important grounds of public interest.
- The Processor will not sell or share Customer Personal Data, will not retain, use, or disclose it for any purpose other than performing the Service, will not use it outside the direct business relationship, and will not combine it with data from other sources except as permitted by the CCPA for a service provider. The Processor certifies it understands and will comply with these restrictions.
- The Processor will not use Customer Personal Data or Platform Data to train, fine-tune, or evaluate machine-learning models.
5. Confidentiality and personnel
Personnel authorised to process Customer Personal Data are bound by confidentiality obligations that survive their engagement, receive data protection training appropriate to their role, and are granted access on a least-privilege, need-to-know basis. Administrative access is logged.
6. Security measures
The Processor implements the technical and organisational measures in Annex II. The Processor may update them provided the level of security is not reduced.
7. Subprocessors
- The Controller gives general written authorisation for the Processor to engage Subprocessors.
- The current list is published at Subprocessors.
- The Processor will give at least 30 days' notice before adding or replacing a Subprocessor. Subscribe for notices at
dpa@oraglegpt.org. - The Controller may object on reasonable data protection grounds within the notice period. The parties will work in good faith to resolve it. If it cannot be resolved, the Controller may terminate the affected part of the Service without penalty and receive a pro-rata refund of prepaid unused fees.
- The Processor imposes data protection obligations on each Subprocessor that are no less protective than this DPA, and remains fully liable for their performance.
8. Assistance with data subject rights
- The Service provides self-serve tooling for access, export, correction, and deletion (see Data Deletion Policy). The Controller should use it first.
- If a Data Subject contacts the Processor directly, the Processor will not respond substantively. It will forward the request to the Controller within 5 business days and tell the Data Subject it has done so.
- Where the Controller cannot fulfil a request through the tooling, the Processor will provide reasonable assistance, taking into account the nature of the processing, at no charge for reasonable volumes.
9. Personal Data Breach
- The Processor will notify the Controller without undue delay and in any event within 48 hours of becoming aware of a Personal Data Breach affecting Customer Personal Data.
- The notification will describe, as far as known: the nature of the breach, the categories and approximate number of Data Subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point. Information will be supplied in phases where it is not all available at once.
- The Processor will assist the Controller with its own notification duties to Supervisory Authorities and Data Subjects.
- A notification is not an admission of fault.
- The Processor operates outage and incident alerting and an append-only audit trail to support breach investigation.
10. Data protection impact assessments
The Processor will provide reasonable assistance with data protection impact assessments and prior consultations with Supervisory Authorities, taking into account the nature of the processing and the information available to it. The Processor publishes our published threat model, our Security page, and our data flow documentation to support that work.
11. Deletion and return
- During the term the Controller can export Customer Personal Data at any time through the Service and its APIs.
- On termination the Controller has 30 days to export. After that the Processor deletes Customer Personal Data in accordance with Data Deletion Policy: live systems within 30 days, and the backup and export files the Processor writes within 90 days. Backups taken outside the Service, such as a hosting provider's volume snapshot, follow that system's own rotation and are not on this timetable.
- The Processor may retain Customer Personal Data where required by law, and in that case will continue to protect it and process it only for the retention purpose.
- On written request the Processor will certify deletion.
12. Audits
- The Processor will make available the information necessary to demonstrate compliance with Article 28 GDPR, including the release evidence, security documentation, and test reports published in
docs/. - Independent certifications or reports (SOC 2, ISO 27001, penetration test reports): none currently held. The Company does not hold a SOC 2 Type II, ISO/IEC 27001, or equivalent third-party audit report, and does not claim one. Where such a report is obtained it will be offered under NDA. Where such a report exists, providing it satisfies an audit request.
- Beyond that, the Controller may audit no more than once every 12 months, on at least 30 days' written notice, during business hours, under confidentiality, without disrupting the Service or accessing other customers' data, and at the Controller's cost. A Supervisory Authority may audit as the law provides.
13. International transfers
- The Processor is established in the United States. Customer Personal Data may be transferred to and processed in the United States and in any region where a Subprocessor operates.
- EEA transfers. The SCCs are incorporated by reference and apply as follows:
- Module Two (controller to processor) where the Controller is a controller;
- Module Three (processor to processor) where the Controller is itself a processor;
- Clause 7 (docking) applies; Clause 9 option 2 (general authorisation) with a 30 day notice period; Clause 11 optional redress body does not apply; Clause 17 governing law: Ireland; Clause 18(b) forum: Ireland;
- Annexes I, II, and III of the SCCs are populated by Annexes I, II, and III of this DPA.
- UK transfers. The UK Addendum applies to the SCCs. Table 4: neither party may end the Addendum as set out in Section 19.
- Swiss transfers. The SCCs apply with references to the GDPR read as references to the FADP, "Supervisory Authority" read as the Swiss Federal Data Protection and Information Commissioner, and with Swiss-law protection extended to legal entities.
- Where an adequacy decision or an approved certification mechanism covers a transfer, that mechanism applies instead.
- Government access. The Processor will, unless legally prohibited, notify the Controller of a binding request from a public authority for Customer Personal Data, challenge requests that appear unlawful or overbroad, and disclose only the minimum lawfully required. The Processor maintains encryption at rest and in transit and key separation as supplementary measures.
14. CCPA service provider terms
The Processor is a Service Provider. It will not sell or share Personal Information, will not retain, use, or disclose it for any purpose other than performing the Service specified in the Terms of Service, will not use it outside the direct business relationship, and will not combine it with Personal Information from other sources except as permitted by the CCPA. The Processor will notify the Controller if it determines it can no longer meet these obligations, and the Controller may take reasonable steps to stop and remediate unauthorised use.
15. Liability and precedence
Liability under this DPA is subject to the limitations in the Terms of Service, except where Data Protection Law prohibits that. In case of conflict, the order of precedence is: the SCCs, then this DPA, then the Terms of Service, then any other policy.
16. Term
This DPA takes effect when the Controller accepts the Terms of Service or countersigns, and continues until the Processor has deleted or returned all Customer Personal Data under section 11.
Annex I - Description of processing
A. List of parties
Data exporter: the Controller, as identified in the order form or account record. Role: controller (or processor, where Module Three applies). Contact: the workspace administrator email on the account. Activities: use of a multi-tenant social media management service.
Data importer: GPT LLM ORAGLE Ltd. Liability Co., 30 N Gould St, Ste N, Sheridan, WY 82801, United States. Contact: dpa@oraglegpt.org. Role: processor. Activities: hosting and operating the GPTpost service.
B. Description of transfer
Categories of Data Subjects
- The Controller's employees, contractors, and authorised users.
- The Controller's clients and their authorised representatives, where the Controller manages accounts on their behalf.
- Holders of the connected social accounts.
- Social platform users who interact publicly with the Controller's accounts: commenters, mentioners, reviewers, question askers.
- Social platform users who send direct or private messages to the Controller's accounts.
- Contacts, creators, influencers, advocates, and community members the Controller records in the Service.
- Recipients of outbound messages the Controller sends through the Service.
Categories of Personal Data
- Identity and contact data: name, email address, social handle, provider user ID, avatar URL, profile URL, job title, organisation.
- Authentication data: password verifier, TOTP secret, recovery codes, WebAuthn credentials, session records, SSO and SCIM attributes.
- Authorisation data: OAuth access and refresh tokens, granted scopes, token expiry, provider account identifiers, connection health.
- Content data: drafts, approved and published posts, per-network variants, media and its metadata, campaigns, schedules, RSS and CSV imported items.
- Communications data: comments, mentions, replies, reviews, questions, and direct or private messages, including bodies and attachments.
- CRM data: contacts, conversations, cases, routing and SLA records, moderation decisions, assignments, notes.
- Analytics data: impressions, reach, engagement, video views, click counts, follower counts, location and search insights, competitor and listening records, attribution records.
- AI processing data: prompts, input hashes, outputs, knowledge citations, tools requested, token usage, cost.
- Technical data: IP address, validated forwarding chain, user agent, request and audit logs, correlation identifiers.
- Commercial data: plan, entitlements, usage counters, invoices, paid-social spend.
How communications and analytics data reaches the Processor. In this build the Processor's platform connectors are publish-only. Communications data and analytics data are submitted to the Service by the Controller, through the ingest APIs described in Privacy Policy sections 4.4 and 4.5. The Processor does not read messages, comments, mentions, reviews or insights from a social platform, and does not send replies to one.
Sensitive data. The Service is not designed for special category data and the Controller must not deliberately submit it. Incidental special category data may nevertheless appear in free-text comments and direct messages the Controller submits to the unified inbox, because the Controller does not choose what a member of the public writes. The Processor applies the same technical measures to all Customer Personal Data: encryption at rest and in transit, tenant isolation, RBAC and ABAC, and audit logging. The Controller is responsible for a lawful basis and for any Article 9 condition.
Frequency. Continuous, for the duration of the agreement.
Nature and purpose. Hosting, storage, transmission, scheduling, retrieval, organisation, analysis, and deletion of Customer Personal Data in order to provide social media publishing, engagement queues and case management over records the Controller supplies, analytics over metric observations the Controller records, workflow and approval, AI assistance, integration, and support services.
The Processor does not collect engagement data from social platforms on the Controller's behalf. Every connector in the Service is publish-only and the Service operates no inbound webhook receiver, so a comment, message, mention or review becomes Customer Personal Data here only because the Controller, or a system acting for the Controller, posted it to the Service. The Controller is accordingly the source as well as the controller of that data, and remains responsible for the lawful basis on which it was collected from the individual.
Retention. As set out in Privacy Policy section 9 and Data Deletion Policy.
Subprocessor transfers. Subject matter, nature, and duration as set out in Subprocessors.
C. Competent supervisory authority
The supervisory authority of the EEA member state in which the Controller (or its Article 27 representative) is established. Where the Controller is not established in the EEA but the processing falls within Article 3(2) GDPR, the authority of the member state where the affected Data Subjects are located.
Annex II - Technical and organisational measures
These are the measures implemented in release 3.4.0-fullpower.1. Items marked as an operator responsibility depend on how the operator deploys the Service.
| Area | Measure |
|---|---|
| Encryption at rest | Tenant data is held in an encrypted PostgreSQL database on an encrypted volume, with FORCE ROW LEVEL SECURITY on tenant-owned tables so isolation is enforced by the database itself |
| Credential protection | Social, AI, and integration credentials are held in sealed envelopes bound to the deployment context, are never returned by the API, and are omitted from responses rather than echoed as redacted placeholders |
| Key management | Master key supplied by environment and never persisted in state; offline master-key rotation procedure with verified re-encryption |
| Encryption in transit | HTTPS with automatic certificate management at the reverse proxy; TLS to all provider and AI endpoints |
| Pseudonymisation | AI agent inputs are stored as hashes where the run is blocked; audit records reference identifiers rather than duplicating content |
| Access control | Tenant identity on every record; role-based and attribute-based access control; approval workflows; step-up re-authentication for operator diagnostics and sensitive actions |
| Authentication | Password with salted verifier, TOTP, recovery codes, WebAuthn passkey foundations, OIDC and SAML SSO, SCIM provisioning and deprovisioning |
| Session security | Opaque server-side sessions; HttpOnly, SameSite=Lax, Secure-on-HTTPS cookie; absolute and idle expiry; server-side revocation on logout |
| Network integrity | Trusted-proxy configuration with right-to-left forwarding-chain validation so client IP attribution cannot be spoofed |
| Outbound event integrity | Webhook deliveries signed with HMAC-SHA256 over timestamp and body, replay protection, secret rotation, retry, dead-letter, automatic disable thresholds |
| Input safety | Request decoding limits, SSRF-safe outbound fetching for feeds and menus, prompt-injection heuristics and content filters on AI input |
| Logging and auditability | Append-oriented tenant audit log and immutable publication attempt log; secrets redacted before logging; correlation identifiers |
| Availability and recovery | Encrypted, context-bound backup envelopes with tamper detection; verified restore with a pre-restore snapshot and atomic replacement; documented rollback runbook |
| Resilience testing | Release verification gate covering unit tests, static analysis, browser end-to-end paths, load smoke, shutdown, restore, key rotation, and an automated secret scan |
| Segregation | Tenant-scoped records with isolation enforced at the store layer and covered by regression tests |
| Change management | Versioned releases with build provenance, SBOM, release manifest checksums, and documented deployment and rollback runbooks |
| Incident response | Outage watchdog and alerting; documented incident and rollback procedures; 48 hour breach notification commitment |
| Personnel | Confidentiality obligations, least-privilege access, logged administrative access |
| Hosting provider and region | Application hosting and the primary database run at Contabo GmbH, Germany (European Union). Object storage for uploaded media is operated by the Company itself on that same German infrastructure, using S3-compatible MinIO software; it is not a third-party service, so uploaded media is not transferred outside the European Economic Area and needs no transfer tool. No United States object storage provider is engaged, and none is named in Annex III. Host hardening, firewall, key custody, backup off-siting, monitoring, patching, and physical security of the deployment are the Company's responsibility |
| Known limitation | Tenant data is held in an encrypted PostgreSQL database with FORCE ROW LEVEL SECURITY on tenant tables, a durable database-backed job queue, a transactional outbox and a hash-chained audit log. Backups are encrypted, taken daily, and each is restored into a clean environment and verified against production before retention; write-ahead log archiving is enabled. The database runs as a single primary with no high-availability cluster and no automatic failover, and recovery to an arbitrary point in time has not yet been rehearsed end to end, so no recovery-point or recovery-time objective is offered |
Annex III - Subprocessors
The subprocessor list published at Subprocessors forms Annex III of the SCCs and is incorporated into this Addendum by reference. It names every subprocessor engaged at the date of that page, its legal entity and country, the service it provides, the personal data categories it receives, its processing location, and the transfer mechanism relied on. It also records the categories the Company has deliberately not engaged.
Changes to that list are governed by section 7 of this Addendum, including the 30 days' advance notice and the Customer's right to object.
Signature
For the Processor:
GPT LLM ORAGLE Ltd. Liability Co.
Signature: ______________________________
Name: Authorised signatory
Title: Authorised signatory
Date: __________________________
For the Controller:
Entity: ______________________________
Signature: ______________________________
Name: ______________________________
Title: ______________________________
Date: __________________________The published template does not print the name of any natural person acting for the Company. An executed counterpart may be requested from dpa@oraglegpt.org.