Data Processing Agreement
Attestly — DPA
Version 3 · effective 5/18/2026 · SHA-256 38bfbb6426da31b6…
Data Processing Agreement — attestly
Effective 2024-08-15
Source repository: Artificial425/attestly
This Data Processing Agreement ("DPA") forms part of the Master Services Agreement (the "MSA") between the Customer (the "Controller") and Domenic Julian's workspace, Address on file with the relevant corporate registrar (the "Processor"). Capitalised terms not defined here have the meanings given in the MSA or the GDPR.
1. Description of processing (GDPR Art. 28(3))
Subject matter. The provision of the attestly product and related services to the Customer.
Duration. For the term of the main services agreement between the parties, and until all personal data is returned or deleted in accordance with this DPA.
Nature and purpose. The Processor will process personal data as necessary to provide the attestly service, which involves user authentication, payment processing, application hosting, and leveraging generative AI models for its core functionality, as directed by the Controller.
Categories of personal data. Contact details, Identifiers, Credentials, Communications, Financial, Device, Behavioral / usage, Other
Categories of data subjects. The Customer's authorized users and end-users.
2. Subprocessors
| Subprocessor | Purpose | Location | AI | Data |
|---|---|---|---|---|
| Anthropic (Anthropic, PBC) | Large language model inference | United States | Yes | Communications |
| Google Generative AI (Gemini) (Google LLC) | Gemini model inference (text, vision, multimodal) | United States (Google Cloud, customer-selectable) | Yes | Communications, Other |
| OpenAI (OpenAI, L.L.C.) | Large language model inference and embeddings | United States | Yes | Communications, Identifiers |
| LM Studio (self-hosted) (Self-hosted) | Local LLM inference | Customer-controlled | Yes | Communications |
| OpenRouter (OpenRouter, Inc.) | LLM routing gateway (underlying provider varies) | Depends on selected provider | Yes | Communications |
| Portkey (Portkey, Inc.) | LLM observability + routing gateway | United States | Yes | Communications, Device |
| Clerk (Clerk, Inc.) | User authentication | United States | No | Contact details, Identifiers, Credentials |
| Neon (Neon, Inc.) | Serverless Postgres | Configurable region (AWS/Azure) | No | Other |
| Resend (Resend, Inc.) | Transactional email | United States | No | Contact details, Communications |
| Fly.io (Fly.io Inc.) | Edge application hosting | Global edge | No | Device |
| Railway (Railway Corp.) | Application hosting | United States | No | Device |
| Stripe (Stripe, Inc.) | Payment processing | United States | No | Financial, Contact details |
The Controller grants a general written authorisation for the engagement of subprocessors. The Processor will give the Controller at least 30 days' prior notice before adding or replacing a subprocessor, during which the Controller may object on reasonable grounds. If the parties cannot agree, the Controller may terminate the affected services.
3. Processor obligations
3.1 Documented instructions (Art. 28(3)(a)). The Processor shall process personal data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the Processor is subject; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
3.2 Confidentiality (Art. 28(3)(b)). The Processor shall ensure that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
3.3 Security (Art. 28(3)(c) / Art. 32). The Processor shall implement the technical and organisational measures specified in this DPA to ensure a level of security appropriate to the risk.
3.4 Subprocessor terms (Art. 28(3)(d)). The Processor has the Controller's general written authorisation for engaging subprocessors. The Processor shall inform the Controller of any intended changes concerning the addition or replacement of other subprocessors, thereby giving the Controller the opportunity to object. Where the Processor engages a subprocessor, it shall do so by way of a written contract which imposes on the subprocessor the same data protection obligations as set out in this DPA.
3.5 Data-subject assistance (Art. 28(3)(e)). Taking into account the nature of the processing, the Processor shall assist the Controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller's obligation to respond to requests for exercising the data subject's rights.
3.6 Security and DPIA assistance (Art. 28(3)(f)). The Processor shall assist the Controller in ensuring compliance with its obligations relating to security of processing, notification of a personal data breach to the supervisory authority and communication of a personal data breach to the data subject, and conducting data protection impact assessments and prior consultation with the supervisory authority.
3.7 Return or deletion at end of services (Art. 28(3)(g)). At the choice of the Controller, the Processor shall delete or return all the personal data to the Controller after the end of the provision of services relating to processing, and delete existing copies unless Union or Member State law requires storage of the personal data.
3.8 Audit rights (Art. 28(3)(h)). The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 of the GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.
4. Technical and organisational measures (Art. 32)
4.1 Technical measures
Encryption in transit. All data transmitted between the Controller's users and the attestly service is encrypted using Transport Layer Security (TLS) 1.2 or higher. Industry-standard certificate management practices are followed.
Encryption at rest. Data at rest, including database storage managed by Neon and application backups, is encrypted using industry-standard algorithms such as AES-256.
Pseudonymisation and tokenisation. User passwords and sensitive credentials are not stored in plaintext; they are hashed using a strong, salted, one-way algorithm. Application-level data is not pseudonymised by default.
Access control. User authentication and session management are handled by Clerk, which supports multi-factor authentication. Access to production systems is restricted to authorized personnel based on the principle of least privilege, with access reviewed periodically.
Network security. The application is hosted on Fly.io and Railway, which provide network-level security controls, including firewalls and DDoS mitigation. Access to internal networks is restricted, and secrets are managed in a secure environment.
Integrity controls. Changes to the application source code are subject to a peer-review process. All actions within the production environment are logged to provide an audit trail.
Availability and resilience. The application is deployed on resilient infrastructure provided by Fly.io and Railway. Databases managed by Neon include automated backups to support point-in-time recovery.
Incident management. An incident response plan is in place to detect, contain, and remediate security incidents. The plan includes procedures for internal and external communication, severity level assessment, and post-incident reviews.
4.2 Organisational measures
- All personnel are subject to binding confidentiality agreements.
- Regular security and data protection awareness training is provided to all employees.
- Background checks are conducted for personnel with access to sensitive data, where permitted by law.
- A formal vendor security assessment process is in place for onboarding new subprocessors.
- A secure software development lifecycle (SDLC) is followed for all application changes.
- Written policies and procedures for information security and data handling are maintained and regularly reviewed.
5. Subprocessor change process
The Processor will notify the Controller of any intended changes concerning the addition or replacement of subprocessors at least 30 days in advance. Notification will be provided via email to the Controller's designated contact. The Controller may object to the change in writing within 15 days of the notification. If the parties cannot reach a mutually agreeable resolution regarding the objection, either party may terminate the main services agreement.
6. 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 Controller data, with the information required under Art. 33(3) GDPR to the extent then known.
In the event of a personal data breach, the Processor will notify the Controller without undue delay, and in any event within 48 hours of becoming aware of it. The notification will be sent to the Controller's registered contact email and will include, at a minimum: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to be taken to address the breach.
7. International transfers
Personal data may be transferred to and processed in jurisdictions outside the European Economic Area (EEA), the United Kingdom, and Switzerland, including the United States, where many of the Processor's subprocessors are located. Such transfers are safeguarded by appropriate transfer mechanisms, such as the EU Standard Contractual Clauses and the UK International Data Transfer Addendum, to ensure an adequate level of data protection.
A summary of the Processor's Transfer Impact Assessment is available to the Controller upon written request.
8. Return or deletion on termination
Timeline. Upon termination of the main services agreement, the Controller will have a 30-day window to export its data. Following this window, the Processor will securely delete all personal data within the subsequent 60 days.
Method. Personal data is deleted from production systems through database record removal. Backups containing the data will expire and be purged according to their standard lifecycle, typically within 30 days.
Deletion certificate. A certificate of deletion is available on written request.
9. Liability
The liability of each party under this Data Processing Agreement shall be subject to the limitations and exclusions of liability set out in the main services agreement between the parties.
10. Governing law
The laws of the jurisdiction in which the Controller is established.