Data Processing Agreement

Status: v1.0, in force from 2026-08-28. Written by engineering from the running system and published without prior review by outside counsel; that review is pending, and a revised version will be published under Section 14 of the Terms of Service when it completes.

Version: 1.0 · Prepared: 2026-08-18 · Effective: 2026-08-28

This DPA forms part of the Terms of Service between ProChatFlow LLC, a Minnesota limited liability company formed on 25 April 2025 under Minn. Stat. ch. 322C, Minnesota Secretary of State file number 1558059000024, whose registered office is on file with the Minnesota Secretary of State ("Processor") and the Customer ("Controller"). BurnLedger is the Processor's service, not a separate legal person. This DPA applies where BurnLedger processes personal data on the Controller's behalf, in the sense of GDPR Article 28 and equivalent laws.

1. Roles

The Controller determines the purposes and means; BurnLedger processes only on documented instructions. Using the Service — registering a system, defining a query, submitting a data-subject identifier — is such an instruction.

BurnLedger is a controller in respect of its own account and security data; that processing is described in the Privacy Policy and is outside this DPA.

2. Annex I — the processing, in fact

Subject matter. Measuring the presence and subsequent absence of records relating to a data subject, and issuing a signed record of both measurements.

Duration. For the term of the agreement, save that issued certificates and transparency-log entries persist as described in Section 9.

Nature and purpose. Read-only queries against Controller systems, executed inside an AWS Nitro Enclave; cryptographic hashing of identifiers; signature and publication of a verification record.

Categories of data subject. Whichever the Controller submits — typically its own customers, users or employees exercising erasure rights.

Categories of personal data.

• A data-subject identifier submitted by the Controller (for example an email address). Held in enclave memory for the duration of a query and not persisted.

Retention note, kept visible because two earlier drafts of this document got it wrong in opposite directions. Attestations carry an expiry (default 72 hours, maximum 7 days) after which they can no longer be certified. The first draft said the rows were then deleted; they were not, and no purge job existed. The correction said production held "46 expired attestations, each containing a salted subject hash", which overstated the exposure: 37 of those 46 are CERTIFIED and are the evidence behind issued certificates, which we are supposed to retain. The number that was genuinely over-retained is 9.

A purge now exists (default: 30 days past expiry, configurable) and deletes expired attestations that were never certified. Certified attestations are never deleted. Counsel sets the retention period that appears in the privacy policy; the default is a support window, not a legal judgement. - A salted SHA-256 hash of that identifier, persisted inside certificates. Because BurnLedger also holds the salt, this is treated as pseudonymised personal data, not anonymous data. - Record counts and metadata — how many records matched, in which named system, at which times. - Connection configurations for Controller systems, encrypted at rest under a key released only to the measured enclave.

Special categories. BurnLedger does not require, request or knowingly process special-category data. Note the reasonable inference available from context — that a subject appears in a named system — and that the Controller chooses the system names that appear in the record.

Content of records. BurnLedger sees record counts and hashes. Record contents are hashed inside the enclave and discarded; they are not transmitted to or stored by BurnLedger.

3. Instructions and unlawful instructions

BurnLedger processes only on the Controller's documented instructions, including as to transfers, unless required by law — in which case it will inform the Controller first unless the law forbids it. BurnLedger will inform the Controller if it considers an instruction infringes data protection law.

4. Confidentiality

Personnel with access are bound by confidentiality obligations. Access to production is restricted and logged, and datastore credentials are not readable by personnel at all: they are decryptable only inside the enclave.

5. Security (Article 32)

BurnLedger implements the measures in Annex II. Material reductions will not be made during the term.

6. Sub-processors

Current sub-processors:

As of 2026-08-28: email and operator notifications are live (email hosting moved from ImprovMX forwarding to Google Workspace on that date; ImprovMX has been removed from the list, not merely deprecated); outbound email is configured but not yet sending; payment processing runs in test mode only and has processed no customer payment data. The notification service receives no personal data: as of 2026-08-20 its payload states only that an event occurred, having previously carried account names, email addresses, and application text over an unauthenticated topic.

The Controller gives general authorisation for these and for replacements, on 30 days' prior notice of any addition or change, during which the Controller may object on reasonable data-protection grounds. If BurnLedger cannot meet the objection within a further 30 days — by not using the new sub-processor for the Controller's data, or otherwise — the Controller may terminate the Service without penalty and receive a pro-rata refund of any subscription fee paid for the period after termination.

7. Data-subject requests

BurnLedger will not respond to a data subject directly except to refer them to the Controller, and will assist the Controller in responding, taking into account the nature of the processing.

A practical note that belongs in the agreement rather than in support email: BurnLedger cannot search by raw identifier. It stores only salted hashes, so locating records about a data subject requires the Controller to supply the identifier so it can be re-hashed. This is a consequence of minimisation, and it means Controller cooperation is required for any request BurnLedger assists with.

8. Personal data breach

BurnLedger will notify the Controller without undue delay and in any event within 72 hours of becoming aware of a personal data breach affecting Controller data, with the information available, supplemented as it emerges.

Settled 2026-08-27 (Determination 8). 72 hours mirrors the Controller's own Article 33 clock. Automated failure alerting with deduplication is live, so this is a commitment the company can meet; 24 hours was drafted before that existed and a window the processor cannot honour is worse than a longer one it can.

9. Deletion and return — including what cannot be deleted

On termination, and at the Controller's election, BurnLedger will delete or return Controller personal data within 30 days, save that:

• Issued certificates may be retained where the Controller or a third party relies on them as evidence, or deleted on request. Deleting them removes the salted subject hash and the record contents.
• Transparency-log entries cannot be deleted. The log is append-only by design, and that property is what makes a certificate trustworthy. Entries contain a certificate identifier, a hash of the certificate, an entry type and a timestamp — no identifiers and no hashes of identifiers. Following deletion of the certificate and expiry of the off-site backups that held it, BurnLedger retains no means of linking an entry to a data subject: reversing the entry would require the certificate it hashes, which BurnLedger no longer holds.

Settled 2026-08-27 (Determination 1), and deliberately weaker than the previous drafting. The earlier text asserted the entry contained "no data" full stop. That is true of the entry in isolation but not of the world: the entry carries a deterministic hash of the certificate, and a third party who still holds that certificate can match the two. The position is that such a party thereby confirms what it already holds and learns nothing new, so no fresh disclosure occurs — and that BurnLedger itself, having destroyed its own copies, has no such means at all.

Two consequences the Controller should understand, stated because they are the conditions on which the position rests:

• It becomes true 60 days after deletion, not on the day. Off-site backups expire on a 60-day lifecycle rule. Any retained copy of the certificate makes the entry linkable in BurnLedger's own hands and reverses the analysis.
• The erasure obligation runs to the Controller. BurnLedger is a processor here; a data subject's Article 17 request is made to the Controller, and BurnLedger's duty is to assist it.

This is the position we hold and the one we expect a careful privacy team to read first. It is stated here in full, including its conditions, so that it can be examined rather than trusted; if a regulator takes the absolute view that any persistent entry tied to a data subject is personal data, we will say so here and adjust.

10. Audit

BurnLedger will make available the information necessary to demonstrate compliance with this DPA and will allow audits, including inspections, by the Controller or an independent auditor it mandates, once in any 12-month period and additionally after a personal data breach affecting Controller data, on 30 days' written notice, during business hours, at the Controller's cost, without disrupting the Service, and under confidentiality obligations no less protective than Section 4. An audit is conducted first on documents and remote access; on-site inspection follows only where those are insufficient. Where BurnLedger holds a current SOC 2 report or an independent penetration-test summary it may offer it in satisfaction of an audit request; it holds neither today, and this DPA does not imply otherwise.

11. International transfers

Processing takes place in the United States. BurnLedger does not contract with Controllers established in the EEA or the UK (Terms §2).

Where a Controller established elsewhere processes personal data of data subjects in the EEA or the UK, and the GDPR or UK GDPR therefore applies to that processing, the parties enter into the Standard Contractual Clauses, module 2 (controller-to-processor), with the UK Addendum where applicable, incorporated by reference, together with a transfer impact assessment.

Business decision, 2026-08-27: the customer restriction narrows this clause but does not retire it. A US controller with EU data subjects is still a GDPR controller and BurnLedger is still its processor, so the clauses stay drafted and available. The annexes must be completed before this clause is first relied upon rather than before the first customer.

The clauses are incorporated by reference in the form published by the European Commission (Decision (EU) 2021/914) and the UK Information Commissioner's Office. Their annexes are completed from Section 2 and Annex II of this DPA at the time the clause is first relied upon.

12. Liability

Liability under this DPA is subject to Section 9 of the Terms of Service, and in particular to the data-protection cap in Section 9.4.

Annex II — Technical and organisational measures

Written from the running system. Each is verifiable; nothing aspirational is included.

• Datastore credentials are encrypted under a key released only to a measured AWS Nitro Enclave. Neither the host system nor BurnLedger personnel can decrypt them. There is no operation on the enclave's interface that returns a decrypted configuration.
• Signing keys exist only inside the enclave. The KMS key policy releases them only to a specific image measurement (PCR0); a modified image is refused the key.
• Read-only credential enforcement. Registration is refused for credentials BurnLedger can prove are write-capable. Where a datastore exposes no privilege introspection, the record states that read-only status was operator-asserted.
• Verified TLS floor. Every datastore connection must present a certificate that verifies; plaintext and unverified-TLS connections are refused, and the floor is enforced inside the enclave from its own baked-in configuration.
• Record contents are hashed in enclave memory and discarded. Only counts and hashes leave.
• Identifier minimisation. Raw identifiers are never persisted; only a per-controller salted hash is stored.
• Append-only transparency log with an equivocation guard, so a certificate cannot be issued or withdrawn without a public trace.
• Continuous verification. A daily automated run exercises the full path — register, attest, delete, verify, issue, verify offline — against 17 live datastores, and fails loudly.
• Encryption in transit and at rest; access to production restricted and logged; reproducible enclave builds so the running image can be rebuilt from source and compared.

Also in place since 2026-08-21: nightly off-site backup replication with a 60-day lifecycle, an independent off-box transparency witness, and external uptime monitoring with a dead-man heartbeat.

Not yet in place, and therefore not claimed: SOC 2, an independent penetration test, and 24×7 human on-call.