Data Processing Agreement
This is Edific's standard Data Processing Agreement under Art. 28 GDPR — the DPA included with every engagement (see Security & deployment). Edific acts as the processor (sous-traitant); the client is the controller (responsable de traitement). This is the agreement that governs how client document data is lawfully handled — not a general terms-of-service gate.
This page is a template pending review by a lawyer before it is treated as a binding legal document. Entity details, governing law, and named sub-processors are confirmed per signed engagement; bracketed fields below mark what is not yet fixed.
Parties
- Controller: [client legal entity], [address], [company registration number].
- Processor: Edific — [legal entity name, to be confirmed], Lisbon, Portugal, operated by Hammadou.
1. Subject & Scope
Processing of documents (invoices, receipts, statements, identity files, contracts, and similar records) and the personal data they contain, solely to provide the automated extraction and validation service, on the Controller's documented instructions only (Art. 29). The Processor does not determine the purposes of processing.
2. Duration
For the term of the service agreement between the parties, followed by deletion or return of data at the end of service (§8).
3. Nature of Data
Business documents and the personal data they contain — names, addresses, tax identifiers, and amounts. No special-category data is processed. Data subjects are the Controller's clients and their counterparties.
4. Processor Obligations (Art. 28(3))
- Process data only on the Controller's documented instructions; flag any instruction that appears unlawful.
- Ensure everyone authorised to process the data is bound by confidentiality.
- Implement the security measures set out in §5.
- Respect the sub-processor rules in §6.
- Assist the Controller with data-subject rights requests and with its own Art. 32-36 obligations (security, breach notification, DPIA), given the nature of the processing.
- Delete or return the data at the end of service, per §8.
- Make available all information necessary to demonstrate compliance, and allow audits.
5. Security (Art. 32)
The core measure is architectural: processing runs on the Controller's own infrastructure — a server or VPS the Controller controls — and data never leaves that environment. This is also what preserves professional confidentiality (secret professionnel) for the documents involved.
- Encryption in transit; access controls; secrets isolated from processed data.
- A full audit trail of processing — every field, every confidence score, every reviewer.
- Nothing is sent externally automatically; a human approval gate applies before anything is exported.
6. Sub-processors
No sub-processor is engaged without the Controller's prior authorisation. Current sub-processors, if any, are limited to infrastructure hosting — e.g. an EU VPS provider [name to be confirmed per engagement]. Where the deployment runs a local model with no external API, there is no model or inference sub-processor at all. Any change is notified in advance, with a right to object.
7. International Transfers
Data stays within the EU (EU-region infrastructure). No transfer outside the EEA without an Art. 46 safeguard in place.
8. End of Service
On termination, at the Controller's choice: the Processor returns all data and deletes its copies, or deletes all data and certifies deletion — within 30 days.
9. Breach Notification
The Processor notifies the Controller without undue delay on becoming aware of a personal-data breach — target within 24 hours — with the information the Controller needs to meet its own Art. 33/34 duties.
10. Liability & Governing Law
Governed by [governing law and jurisdiction, to be confirmed per engagement]. Liability is as set out in the underlying service agreement.
Signatures
Controller: ______________________ Processor: ______________________ Date: ______________________
Contact
Questions about this DPA before signing:
Email: hello@edific.uk
Address: Lisbon, Portugal
Asked before, answered plainly
The questions worth asking before you send us a document. Can’t find your answer here?
Nowhere. Edific runs on your own server or VPS; it is never sent to us or a third party. That is a design decision, not a setting you can turn off.
Edific. A named point of contact owns your engagement end to end — the same person you talk to signs the DPA and stands behind the result. Less brand, more accountability.
On our published test — 3 hard receipts, ~15% for standard OCR — Edific got 18 of 18 fields correct. Small, deliberately hard sample, presented as exactly that. The number that matters is the one from a pilot on your own documents.
Its job is to be wrong loudly. The evaluation gate flags uncertain fields for human review before export, and any slip is traceable in the audit log and fixed at the source.
Scoped per engagement, not per seat — it follows volume, document types, and infrastructure. You get a fixed quote after a pilot. No pilot, no quote.
Yes, structurally. Processing happens on your own infrastructure, and the Art. 28 DPA describes the architecture as it actually works.
Next step
See it on your own documents
Not a deck. Not a demo dataset. Send a batch of your real documents — the difficult ones — and get back verified, structured data with every field scored and logged. Then decide.
Runs on your infrastructure. Covered by a DPA. Edific accountable for the result.