Data processing agreement

This Data Processing Agreement (“DPA”) is entered into between Drakon Systems Ltd, a company registered in England and Wales (company number 16867343), registered office 34 Lumina Way, London EN1 1FS, ICO registration C1833149 (“DrakonSign”, “we”, “us”, the “Processor”) and the customer identified in the signature block or in the applicable subscription (the “Customer”, “you”, the “Controller”).

This DPA forms part of, and is governed by, the terms of service (the “Agreement”). It applies whenever DrakonSign processes personal data on the Customer’s behalf in providing the DrakonSign electronic-signature service (the “Service”). The data processing terms in the Agreement apply automatically to every customer; this standalone DPA is for customers who want a countersigned copy. It may be executed electronically — and yes, you can countersign it using DrakonSign itself: email support@drakonsystems.com and we’ll send it to you as an envelope. We sign our own paperwork with our own product.

1. Background and how this DPA applies

The Customer uses the Service to send documents for electronic signature. In doing so the Customer submits content — documents and the personal data they contain, and the names and email addresses of signers — which DrakonSign processes on the Customer’s behalf.

This DPA sets out the terms required by Article 28(3) of the UK GDPR that apply to that processing. It is intended to be signed as-is: no negotiation is required, and the same terms apply to every customer. If there is a conflict between this DPA and the Agreement in relation to the processing of personal data, this DPA prevails.

2. Definitions

“Data Protection Laws” means the UK GDPR and the Data Protection Act 2018, and, where applicable to the processing concerned, Regulation (EU) 2016/679 (the “EU GDPR”), in each case as amended or replaced from time to time. “UK GDPR” has the meaning given in section 3(10) of the Data Protection Act 2018. “controller”, “processor”, “data subject”, “personal data”, “personal data breach” and “processing” have the meanings given in the Data Protection Laws. “Customer Data” means the personal data described in Annex 1 that DrakonSign processes on the Customer’s behalf under this DPA. “Sub-processor” means any third party appointed by DrakonSign to process Customer Data.

3. Roles and scope

For Customer Data, the Customer is the controller (or, where the Customer is itself a processor for a third-party controller, a processor — in which case the Customer warrants that its instructions to DrakonSign are authorised by that controller) and DrakonSign is the processor.

This DPA does not apply to personal data for which DrakonSign is a controller in its own right, namely: (a) Customer account, contact and billing data; and (b) the tamper-evident audit trail DrakonSign generates during a signing ceremony (signing events including signer IP address, browser user-agent and timestamps), which DrakonSign maintains as an independent controller so that both parties have evidence designed to support authenticity and attribution. It does not guarantee that a signature is genuine or any legal result. That processing is described in the privacy notice.

The subject-matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex 1.

4. Processing on documented instructions

DrakonSign shall process Customer Data only on the Customer’s documented instructions, including with regard to transfers of Customer Data to a third country, unless required to do otherwise by law to which DrakonSign is subject; in that case DrakonSign shall inform the Customer of that legal requirement before processing, unless the law prohibits this on important grounds of public interest.

The Customer’s documented instructions are: (a) the Agreement and this DPA; (b) the Customer’s configuration of the Service (including each feature or setting the Customer enables, such as the optional AI features and any optional retention timers described in section 9); and (c) the Customer’s use of the Service’s dashboard and API — each ordinary draft first sent, each corrected copy created, each deletion performed and each export requested is an instruction. DrakonSign shall immediately inform the Customer if, in its opinion, an instruction infringes the Data Protection Laws.

5. Confidentiality

DrakonSign shall ensure that every person it authorises to process Customer Data has committed themselves to confidentiality or is under an appropriate statutory obligation of confidentiality, and processes Customer Data only as needed to provide the Service.

6. Security

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as the risks to data subjects, DrakonSign shall implement and maintain appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 of the UK GDPR. The current measures are described in Annex 3. DrakonSign may update those measures from time to time, provided the updates do not materially reduce the overall level of protection.

7. Sub-processors

The Customer gives DrakonSign general written authorisation to engage the Sub-processors listed in Annex 2, and further Sub-processors subject to this section. DrakonSign shall give the Customer at least 30 days’ prior notice (by email or in-product notice) of any intended addition or replacement of a Sub-processor. If the Customer objects on reasonable data-protection grounds within that period and the parties cannot resolve the objection, the Customer may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees for the unused period.

DrakonSign shall impose on each Sub-processor, by written contract, data protection obligations that provide at least the same level of protection for Customer Data as this DPA, and shall remain fully liable to the Customer for the performance of each Sub-processor’s obligations.

The optional AI features (which send document text to Anthropic) are off by default and Anthropic processes Customer Data only for organisations that have switched those features on. Enabling them is the Customer’s documented instruction to engage that Sub-processor.

8. Personal data breach

DrakonSign shall notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting Customer Data. The notification shall, so far as the information is available to DrakonSign, describe the nature of the breach, the categories and approximate numbers of data subjects and records concerned, the likely consequences, the measures taken or proposed to address the breach and mitigate its possible adverse effects, and a contact point. Information may be provided in phases as it becomes available.

DrakonSign shall provide reasonable assistance to the Customer in meeting the Customer’s own breach obligations under Articles 33 and 34 of the UK GDPR, and shall not notify a supervisory authority or data subject of a breach on the Customer’s behalf unless the Customer instructs it to or the law requires it.

9. Retention, deletion and return of Customer Data

DrakonSign retains Customer Data by reference to criteria, not fixed timers. This is the approach permitted by Articles 5(1)(e) and 13(2)(a) of the UK GDPR, which allow a retention period to be defined by the criteria used to determine it; and because deletion or return at end of service is the controller’s choice under Article 28(3)(g), the Customer’s instructions in this section are what determine when Customer Data is erased. The criteria are:

• While the account is active, Customer Data (documents, signed artifacts and related envelope data) is retained, because its purpose — long-term evidence of what was signed — persists for as long as the Customer keeps the account.
• The Customer can delete anything itself, at any time, through the dashboard or API. The live database deletion is immediate and irreversible; file removal is then verified. A response that reports cleanup pending means the recovery sweep will retry the remaining files.
• On account closure, access, users, API keys and live database content are removed in the closure transaction. The live file-store purge and Stripe cancellation are attempted and verified in the same request; if either cannot be confirmed, the response says so, the operator is alerted and storage remnants are retried by the recovery sweep. Existing encrypted off-site backup copies age out with ordinary rotation within 30 days. Backups are immutable dated archives and are not edited in place; they are read only to restore the service.
• Closed-account billing residue is explicit. The redacted organisation row retains its opaque Stripe Customer ID after closure. The closure timestamp remains the authorization and webhook barrier, so a late event can locate the closed row but cannot restore access, plan or allowance. The handle supports cancellation verification and later Stripe-side retention, deletion or redaction reconciliation. This release does not automatically delete a Stripe Customer or put the handle on a timer: support reviews and removes it when reconciliation and applicable tax, accounting and payment-record duties permit. Customers may request that review; Stripe may retain records it is independently required to keep.
• Lifecycle-email delivery data is minimized separately. Signing-invitation, OTP, cancellation, reminder, completion, authenticated-decline, dashboard sign-in and post-checkout welcome rows duplicate recipient email, document title and the frozen provider request; invitation and reminder requests also contain their fresh signing links; dashboard sign-in and welcome requests contain a fresh single-use login link; and each acting signer’s completion request contains that signer’s personal receipt-page link. A pending OTP request temporarily contains its plaintext code, while a keyed candidate hash and request IP/browser metadata wait for provider acceptance. Acceptance activates the challenge only inside its original first-attempt expiry window and only if it is the newest accepted sequence, then appends otp_sent atomically. A delayed or older acceptance is recorded but its credential is invalidated. Automatic recovery never resubmits after the original window lacks provider-timeout and clock-skew headroom; it terminalizes and redacts that unusable request so a fresh code can be requested. Terminal redaction or erasure removes those duplicated values. Invitation token hashes, frozen requests and sent audit events commit before provider I/O. Completion queues the owner and every acting signer with one personal bearer link to an inert receipt page, never an artifact URL. Explicit browser confirmation names one artifact and mints a short-lived, artifact-bound header session before that SHA-verified completed signed PDF or certificate can be returned or audited. The dedicated receipt/session credential columns store only hashes; while the frozen request remains unredacted, its rendered provider payload necessarily holds the raw link it must submit. It is redacted under the rules below, and envelope erasure deletes the row and credential hashes. Those values are redacted immediately after provider acceptance or an authoritative payload/content rejection. An unsubmitted manual-review row has a 30-day target and is then terminalized and redacted. If explicit durable state says submission may have crossed the provider boundary, the duplicated data remains fail-closed beyond that target and blocks envelope erasure and account closure until DrakonSign support performs controlled reconciliation after all old application processes/containers are affirmatively terminated. No API caller can assert a provider outcome. Retained non-content delivery metadata is limited to delivery status, payload SHA-256, provider message and idempotency identifiers, attempt and redaction timestamps, counts, reconciliation outcome/time and operator actor/provenance, and opaque notice, envelope, signer and organisation identifiers, plus a purpose-limited completion receipt token hash and the current short-lived artifact-session token hash/expiry until envelope erasure. Provider errors are allowlisted non-PII reason codes and are cleared on terminal redaction. Every live submitting row blocks while its worker could still run; after recovery, provably unsubmitted manual work is erasable while provider-crossed uncertainty remains support-only. Delivery and individual erasure share an organisation fence before taking an exclusive envelope fence; account closure takes one exclusive organisation fence. A destructive request waits for a bounded coordination window and, if it expires, returns 503 without reporting erasure or closure. If a worker or fence is lost after the provider boundary, the notice remains support-only and erasure stays blocked; connection loss is never proof of non-submission. A partial signature invalidates only that signer’s reminder; same-tier recipients retain their own live reminder and token state until they act or the envelope actually completes. Signing or declining may still complete after that signer’s reminder outcome becomes uncertain: the link is revoked and durable state records that a stale reminder may arrive. This does not weaken the erasure/account-closure block while duplicated PII remains.
• Optional AI provider boundaries are also linearized against erasure. Before extracted document text can be sent to Anthropic, DrakonSign commits a transient boundary row under the same organisation/envelope delivery fences. It stores opaque organisation, envelope and operation identifiers plus boundary time only, never text or model output. Erasure/closure either wins before the final locked check (no provider call), waits through a healthy bounded call, or remains fail-closed if a lost worker may still submit. Support removes a stranded row only with a maintenance-only CLI after every old application process or container has been affirmatively terminated. The command requires exact stopped-app proof, records actor/provenance in the document audit trail, emits an operations alert and has no customer HTTP route; connection loss alone never authorizes erasure.
• Correction lineage leaves one PII-free residue. The durable correction tombstone retains only organisation, source and successor UUIDs plus creation time after envelope erasure or account closure. It contains no title, recipient, reason or file content and prevents a deleted replacement from opening a second direct branch.
• Envelope consumption leaves a content-free billing residue. An opaque organisation/document UUID pair, consumption time and trial/paid phase remain after document deletion so deletion cannot refund quota and delayed Stripe reconciliation cannot erase paid usage. No title, recipient or file content is stored in this ledger.
• Signed envelopes leave one residue: the tamper-evident audit record of the signing ceremony is retained so that a previously issued signature can still be verified for integrity after the underlying content is gone. The document files, field values (typed signatures and typed text — DrakonSign captures typed signatures only, not drawn ones) and signer contact details are destroyed or redacted; what remains is the hash-chained event log — event types, timestamps, the network metadata (IP address, browser) recorded on those events that were caused by a browser request, the envelope title as recorded at creation, any reason a signer gave for declining or the sender gave for voiding, and the SHA-256 fingerprints of the destroyed artifacts. Where the signed event commits to the field values, it does so as unsalted SHA-256 digests; for short, predictable values such as a name or a date those digests should be treated as identifying rather than anonymous. Those retained events are kept byte-identical because each is covered by the chain hash; altering any of them would destroy the verifiability the residue exists to provide. This retention is DrakonSign’s processing as an independent controller of the audit trail (section 3), on the legal-claims basis in UK GDPR Article 17(3)(e).

At the end of the provision of the Service, at the Customer’s choice, DrakonSign shall delete Customer Data in accordance with the criteria above, or return it: the Customer can export all signed artifacts and certificates of completion via the dashboard or API at any time before deletion, and existing copies are deleted under the criteria above unless UK or EU law requires continued storage of the personal data. Deletion extends to backups in the ordinary course of backup rotation.

Optional retention timers. If and when the Service offers customer-configurable retention timers (for example, automatic deletion of completed envelopes a set period after completion), they will be off unless the Customer enables them; if enabled, the configured schedule constitutes the Customer’s documented instruction under Article 28(3)(a) and section 4, and DrakonSign deletes on that schedule. They are the Customer’s policy, not DrakonSign’s. Until such timers exist in the Service, deletion is on demand under the criteria above.

10. Assistance to the Customer

Taking into account the nature of the processing, DrakonSign shall assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer’s obligation to respond to requests from data subjects exercising their rights under Chapter III of the UK GDPR. If DrakonSign receives such a request directly and can identify the Customer as the relevant controller, it shall pass the request to the Customer without undue delay and shall not respond to it substantively except on the Customer’s instruction or where required by law.

Taking into account the nature of the processing and the information available to it, DrakonSign shall assist the Customer in ensuring compliance with the Customer’s obligations under Articles 32 to 36 of the UK GDPR (security, breach notification, data protection impact assessments and prior consultation).

11. International transfers

The live Service runs in London, United Kingdom: the application and database on Fly.io’s London (lhr) region, and live document content in a separate Tigris bucket configured as a single-region London (lhr) bucket. Encrypted nightly backups of the database and document store are retained for 30 days with Tigris Data in a separate, globally distributed bucket, which is not pinned to the UK or EU. Customer Data in those backups may therefore be stored outside the UK or EEA. DrakonSign shall not otherwise transfer Customer Data outside the UK (or, where the EU GDPR applies to the processing, outside the EEA) except: (a) to the Sub-processors listed in Annex 2, under the safeguards described there; or (b) on the Customer’s documented instructions. Where a restricted transfer occurs, the parties rely on appropriate safeguards under Article 46 of the UK GDPR — the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses — or an adequacy decision where one applies; for processing subject to the EU GDPR, the EU Standard Contractual Clauses apply correspondingly.

Customer-directed webhook egress. Where the Customer configures an outbound webhook destination in the Service, DrakonSign sends an HTTPS request to the address the Customer has specified each time one of the envelope events the Customer has subscribed to occurs. That is a transfer made on the Customer’s documented instruction under (b) above, to a system the Customer controls; the recipient is not a DrakonSign Sub-processor and does not appear in Annex 2. Configuring the destination is the instruction, and disabling or deleting it withdraws that instruction with immediate effect for both new and already-queued deliveries.

The payload is minimised by design and its content is fixed by the Service, not chosen per request: the organisation identifier, the envelope identifier, the envelope status and timestamps, counts of signers and completed signatures, the opaque identifier of the recipient whose action raised the event where one applies, and links back to the authenticated Service. It contains no signer name or email address, no document title, no field value, no typed signature, no document content and no document or certificate hash. Where the Customer’s destination is outside the UK or EEA, the Customer is responsible for the lawfulness of that onward transfer. Requests are signed (HMAC-SHA256 over a timestamp and the exact request body) so the Customer’s receiver can authenticate them; delivery is at-least-once, so the same delivery identifier may arrive more than once and the receiver is expected to deduplicate on it. Requests go over TLS with certificate verification, only to publicly resolvable HTTPS destinations, and redirects are never followed. Delivery records are retained for 30 days and then deleted.

12. Audit and information

DrakonSign shall make available to the Customer all information necessary to demonstrate compliance with the obligations laid down in Article 28 of the UK GDPR, and shall allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer. Audits shall be conducted no more than once in any 12-month period (except following a personal data breach affecting the Customer, or where required by a supervisory authority), on at least 30 days’ written notice, during business hours, without unreasonable disruption to the Service, and subject to reasonable confidentiality undertakings. DrakonSign shall first satisfy audit requests by written responses and existing documentation where these reasonably suffice.

13. Liability

Each party’s liability arising out of or in connection with this DPA is subject to the limitations and exclusions of liability in the Agreement. Nothing in this DPA limits either party’s liability for anything that cannot be limited by law, or affects a data subject’s rights against either party under the Data Protection Laws.

14. Term, general and governing law

This DPA takes effect on the date it is signed (or, where it applies through the Agreement, when the Customer first uses the Service) and remains in force for as long as DrakonSign processes Customer Data, then until deletion is completed under section 9. If any provision is found unenforceable, the remainder stands. This DPA may be updated by DrakonSign where required by changes in Data Protection Laws; material changes are notified to the Customer in advance.

This DPA is governed by the laws of England and Wales, and the courts of England and Wales have exclusive jurisdiction over any dispute arising out of or in connection with it. The UK GDPR is the primary regime; the EU GDPR applies where the processing falls within its scope.

Annex 1 — Details of processing

Subject-matter of processing. Documents submitted for electronic signature through the Service, and the data needed to run each signing ceremony.

Duration of processing. The term of the Agreement, then until deletion is completed under section 9.

Nature and purpose of processing. Hosting, storing, transmitting and displaying documents; delivering signing links and one-time verification codes to signers; capturing signatures; producing the signed PDF and certificate of completion; and, only where the Customer has enabled the optional AI features, analysing document text to produce plain-English summaries and clause flags.

Types of personal data. Names and email addresses of signers; the content of documents submitted for signature, which may contain any category of personal data the Customer chooses to include (the Customer is responsible for what it uploads, and should not upload special category data unless it has a lawful basis and an Article 9 condition for doing so); typed signature text. DrakonSign does not capture drawn signature images.

Categories of data subjects. The Customer’s signers and counterparties; the Customer’s own personnel; any individuals whose personal data appears in documents submitted for signature.

Annex 2 — Authorised Sub-processors

No other Sub-processor has access to Customer Data.

Outbound webhooks are not a Sub-processor arrangement. If the Customer configures a webhook destination, DrakonSign transmits the minimised event payload described under “International transfers” above to that address on the Customer’s own instruction. The operator of that address is the Customer’s chosen recipient, not a party DrakonSign has appointed, and it is therefore deliberately absent from this Annex.

Annex 3 — Technical and organisational measures

• Data location. Application and database pinned to the Fly.io London (lhr) region; live document content held in a Tigris bucket configured as a single-region London (lhr) bucket. Encrypted nightly backups of the database and document store are held with Tigris Data in a separate, globally distributed bucket; DrakonSign therefore does not represent that Customer Data never leaves the UK or the EU.
• Encryption. TLS for all data in transit; encryption at rest for the database, the live document bucket and the backup bucket. Encryption is at the storage layer; DrakonSign does not operate per-document encryption keys, so erasure is performed by destroying the data rather than by destroying a key.
• Integrity. Every signing ceremony produces a hash-chained, tamper-evident audit trail; signed artifacts and certificates of completion are recorded with SHA-256 fingerprints and can be integrity-verified at any time.
• Access control. Dashboard access by authenticated session (an HttpOnly, Secure session cookie, plus a second short-lived HttpOnly, Secure cookie carrying a two-step sign-in ticket where the account holder has enabled optional authenticator-app sign-in); each session is separately listable and revocable, expires server-side after 7 days without use or 14 days absolute, whichever comes first, and its record is deleted 30 days after it ends; the account holder is emailed on new sign-ins, on sign-in setting changes, and when a sign-in link is used but abandoned without the second step; API access by per-organisation API keys that can be revoked and reissued at any time; documents keyed and isolated per organisation, with path-containment checks on all storage access.
• Write-once storage. Fingerprinted completion artifacts cannot be silently overwritten or replaced once their fingerprint is recorded on the audit chain.
• Least exposure. No third-party scripts, fonts, analytics or tracking on the Service’s pages; signing pages set no cookies; the production container runs as an unprivileged user.
• Confidentiality. Personnel access limited to what operating the Service requires, under confidentiality obligations.

Signing this DPA

The canonical signable text of this DPA (with signature blocks) is maintained alongside the product and is available on request as a document ready for execution. To get a countersigned copy, email support@drakonsystems.com and we’ll send it to you through DrakonSign — you sign it the same way your own counterparties sign yours.