Attestive Data Processing Agreement (DPA)
This DPA forms part of the agreement between [Your AS name] (“Processor,” “Attestive”) and the customer (“Controller”) governing Attestive’s processing of personal data on the Controller’s behalf, in accordance with the EU/EEA General Data Protection Regulation (GDPR).
1. Roles
The Controller determines the purposes and means of processing personal data submitted to the Service. Attestive acts as Processor, processing personal data only on the Controller’s documented instructions (including via API calls and configuration made through the Service).
2. Subject matter and duration
Processing covers personal data that may be contained within logged decision records, input evidence, or associated metadata submitted by the Controller to the Service. Processing continues for the duration of the Controller’s subscription and any post-termination retention period described in Section 8.
3. Nature and purpose of processing
Attestive processes such data solely to provide the Service: recording, hash-chaining, storing, and enabling export/verification of decision records, and administering the Controller’s account.
4. Categories of data subjects and data
Data subjects may include the Controller’s employees, customers, or end users whose actions or data are reflected in logged decisions. Categories of data depend entirely on what the Controller chooses to submit as inputEvidence or output fields — Attestive has no visibility into or control over what the Controller logs, and the Controller is solely responsible for ensuring it has a lawful basis for any personal data it submits.
5. Subprocessors
Attestive uses the following subprocessors:
- Supabase (database and authentication infrastructure), hosted on AWS, region: eu-central-1 (Frankfurt, Germany)
- [Add: any email service, hosting/CDN provider, payment processor once billing is wired up]
- [Confirm: Google Workspace’s data handling if any customer support correspondence touches Customer Data]
Attestive will notify the Controller of any new subprocessor with the ability to object within [14] days.
6. Security measures
Attestive implements the following measures, described in full at attestive.io/trust:
- Hash-chained, tamper-evident record storage
- Database-level enforcement (not merely application-level) preventing any application-facing role from updating or deleting logged records
- Row-level security scoping all data access to the Controller’s own organization
- Encryption in transit (TLS) and at rest
- Hashed (not plaintext) storage of API credentials
7. Data subject rights
Attestive will assist the Controller, insofar as possible given the nature of processing, in responding to data subject requests (access, rectification, erasure, etc.) concerning personal data the Controller has submitted. Given the Service’s append-only design, erasure requests concerning logged decision content require the Controller to contact hello@attestive.io to discuss the appropriate mechanism — see Section 9.
8. Data retention and deletion
Upon termination of the Controller’s account, Attestive will make Customer Data available for export for 30 days, after which it will be deleted from active systems within [60] days, except where retained copies exist in backups, which will be purged per Attestive’s actual backup rotation schedule [CONFIRM: check Supabase’s real backup retention period and insert the true figure here — do not guess].
9. The append-only design and erasure requests — read carefully
This section requires real legal input before this document is used. Do not treat the text below as resolved.
Attestive’s core product guarantee is that logged decision records cannot be altered or deleted through normal operation, by design. This has a direct GDPR implication the Controller should understand before submitting personal data: individual record erasure (GDPR Art. 17) is not a self-service, per-record operation in this Service. If a data subject exercises an erasure right over data embedded within a logged decision, the Controller should avoid submitting directly-identifying personal data into inputEvidence/output fields where possible (pseudonymize or reference an external ID instead), and contact hello@attestive.io to discuss handling of any specific erasure request.
Open question needing a lawyer’s opinion: what is the correct, GDPR-compliant procedure when erasure is genuinely required against an append-only, tamper-evident log whose entire value proposition is that records aren’t deleted? Candidate approaches to put in front of counsel include: (a) documented, audited, exceptional database-owner-level deletion with the resulting chain gap itself logged and explained, (b) contractual encouragement/requirement that Controllers never submit directly-identifying data in the first place, with pseudonymized references only, or (c) a formal legal basis argument for retention (e.g., legitimate interest in maintaining audit integrity) that may apply in some circumstances but should not be assumed without review.
10. International transfers
Data is hosted within the EU (Frankfurt). [CONFIRM: are any subprocessors outside the EU/EEA? If Google Workspace, npm, or any US-based service ever touches Customer Data, this section needs Standard Contractual Clauses language added.]
11. Breach notification
Attestive will notify the Controller without undue delay, and in any case within 72 hours of becoming aware, of any personal data breach affecting the Controller’s data.
12. Audits
The Controller may request reasonable evidence of Attestive’s compliance with this DPA, including via the public documentation at attestive.io/trust and the independently verifiable attestive-verify package.
Questions about this document? hello@attestive.io · See also trust & verification.