# Data Processing Agreement — Outline

**STATUS: OUTLINE ONLY. NOT LEGALLY REVIEWED. NOT EXECUTABLE.**

This is an engineering description of what EcoKure does with data and what a DPA
would therefore have to say. **It is not a contract, not legal advice, and must
not be sent to a customer as though it were a DPA.** A lawyer has not read it.

Its purpose is narrow and real: when a regulated buyer asks "do you have a DPA",
the answer should be a specific position with a known status, not silence.

Related: `/subprocessors` (the actual list), `docs/EVIDENCE_RETENTION_POLICY.md`
(the erasure position, which also needs counsel).

---

## 1. The distinction that governs everything

Two systems, and a single DPA covering both would be wrong:

| | ecokure.com | Assurance Runtime |
|---|---|---|
| Role | EcoKure is **controller** for site data | Customer is **controller**; EcoKure is at most **processor** |
| Where it runs | EcoKure's hosting | The **customer's own account** |
| Subprocessors | Seven (see `/subprocessors`) | **None** |
| Data EcoKure can access | Site analytics, enquiries, orders | **None by default** |

The runtime deploys inside the customer's boundary. Evidence, signing keys and
decision records do not reach EcoKure. In a standard deployment there is no
transfer to EcoKure at all, and the DPA's operative clauses would cover
*support access* — the exceptional case — rather than ongoing processing.

**Counsel question 1:** where EcoKure never receives the data, is a processor
DPA the right instrument, or is this better handled as support-access terms
inside the licence?

## 2. What the runtime actually holds

Relevant because it changes the risk profile substantially:

- **An input digest, not the input.** The evidence store holds a hash of the
  request, never the request body. Customer content does not enter it.
- **Reviewer identity**, held tenant-side. The public chain carries only a
  hiding commitment, not a person.
- **No tenant dimension on the transparency surface**, by design.

**Counsel question 2:** does an irreversible digest of personal data remain
personal data for these purposes, and does that change if the customer holds the
input elsewhere and could re-derive the match?

## 3. Clauses a DPA would need

Listed so nothing is quietly dropped. Wording is counsel's.

1. **Subject matter, duration, nature and purpose** — deterministic verification
   of customer-defined controls, for the licence term.
2. **Categories of data and data subjects** — customer-determined. EcoKure
   cannot enumerate them because it does not see the inputs.
3. **Instructions** — process only on documented instruction; obligation to
   notify if an instruction appears unlawful.
4. **Confidentiality** — personnel bound.
5. **Security measures** — reference the security pack rather than restating it,
   so one document does not drift from the other.
6. **Subprocessors** — the published list, with notice of change and a right to
   object. **The runtime has none**, which is worth stating explicitly.
7. **Data subject rights** — assistance obligations. See §4.
8. **Breach notification** — timeframe to be set by counsel.
9. **DPIA assistance.**
10. **Deletion or return on termination.** See §4 — this is the hard one.
11. **Audit and inspection rights.** See §5.
12. **International transfers** — the site's subprocessors sit in the US and
    EU; the runtime transfers nothing.

## 4. The clause that cannot be written normally

A standard DPA promises deletion on termination. **The evidence chain is
append-only and shared across tenants.** Deleting an entry breaks the
tamper-evidence for every other tenant on that chain.

What EcoKure can do is destroy everything that makes an entry meaningful: the
nonce that opens the commitment, the tenant attribution, the decision record and
the reviewer identity. What remains is an unattributed hash that was never
readable without the nonce and cannot be made readable again.

**This is cryptographic erasure and de-attribution. It is not deletion, and the
DPA must not call it deletion.**

**Counsel question 3 — the central one:** does irreversible destruction of the
key material required to interpret a record satisfy a deletion or erasure
obligation under APP 11.2 and GDPR Article 17? If it does not, the correct
answer is that data under such an obligation should not enter the evidence chain
at all, and the DPA should say so.

## 5. The audit clause EcoKure can actually honour

Most vendors resist audit rights. EcoKure's position is unusual and should be
used:

- Evidence packs verify with a **standalone verifier containing no EcoKure
  code**, offline. A customer can audit the evidence without our cooperation,
  our servers, or our continued existence.
- The runtime runs in **their** account, so infrastructure audit is theirs by
  default.

**Counsel question 4:** can the audit clause be drafted to lean on independent
verifiability rather than promising on-site inspection we would struggle to
support at scale?

## 6. What must not be signed until resolved

- The erasure clause (§4) — unresolved and material.
- Breach notification timeframes — no incident response has been rehearsed
  against a real incident.
- Any security warranty implying certification: **there is no SOC 2, no ISO
  27001, and no independent penetration test.** A DPA that implies otherwise
  would misrepresent the position.
- Liability and indemnity — entirely counsel's.

## 7. Honest interim answer

> A DPA outline exists and has not been legally reviewed. We can share it,
> clearly marked, so your legal team sees our position before drafting. Two
> points need resolving before signature: the deletion clause, because an
> append-only evidence chain cannot delete in the ordinary sense and we will not
> describe cryptographic erasure as deletion; and the security warranty, because
> we hold no certifications and will not imply that we do.

That answer loses some deals. It loses fewer than being found out later.