Data Processing Agreement

This Data Processing Agreement ("DPA") applies to every firm that uses GarnerDocs. It forms part of the Terms of Service. A firm accepts it when it accepts the Terms, and nothing needs to be signed.

For the processing of personal data in Client Documents, this DPA prevails over the Terms if they conflict. It's governed by the same law as the Terms, and the same courts have jurisdiction. Liability under this DPA is governed by the liability section of the Terms.

GarnerDocs is provided by Waseem S. M. Abusenjr, trading as GarnerDocs, Alte Landstr. 85, 51373 Leverkusen, Germany. Our legal notice has our full details.

If you have a question about this DPA, contact us at [email protected].

• GarnerDocs, we and us: the provider of the GarnerDocs service.
• Firm or Customer: the business that creates a GarnerDocs workspace and accepts the Terms.
• Clients: the people and businesses a firm asks for documents.
• Service: the GarnerDocs app, the private upload links sent to clients, and the emails they send.
• Client Documents: the files and notes clients upload, and the details a firm enters about its clients and requests.
• Data protection law: Regulation (EU) 2016/679 (the GDPR) and the German Federal Data Protection Act (BDSG) and, where they apply to the firm's processing, the UK GDPR and the Data Protection Act 2018.
• Subprocessor: a service provider we engage that processes Client Documents for us.
• Controller, processor, personal data, data subject, processing and personal data breach have the meanings given in data protection law.

For Client Documents, the firm is the controller and GarnerDocs is the processor. The firm decides what to collect, from whom and why. We process Client Documents only to provide the Service to the firm.

For firm account data (the names, work emails, roles and activity of the firm's team, and its billing details), GarnerDocs is the controller, as our Privacy Policy explains. This DPA doesn't cover that data.

The firm is responsible for having a lawful basis for the documents it asks its clients for, and for telling its clients how their information is used.

When an email we send for a firm to one of its clients bounces or is reported as spam, we show that only to that firm. We don't tell other firms.

• Subject matter: collecting documents from the firm's clients through the Service.
• Duration: for as long as the firm uses the Service, and then until the data is deleted as set out in Annex 1.
• Nature: collection, upload, storage, access, review, notification, transfer, export and deletion of Client Documents, telling the firm when an email sent for it to a client can't be delivered and, if the firm turns them on, automatic checks of uploaded files against what the firm asked for.
• Purpose: to let the firm request documents from its clients, receive and review them, send the request and reminder emails it has set up, and download them into its own systems. GarnerDocs is a collection tool. It isn't the firm's permanent document archive or records system.

Data subjects: the firm's clients, and anyone whose details appear in the documents those clients upload.

Types of personal data:

• client names, contact names, email addresses and phone numbers, and the notes the firm keeps about its clients;
• the requests the firm sends: titles, checklists, messages and due dates;
• what clients send: files, with their names, types, sizes and upload times, and notes and answers;
• the firm's review decisions and comments, and records of people at the firm opening or downloading files;
• whether an email to a client bounced or was reported as spam;
• each request's activity history;
• the technical data needed to keep the Service secure and working, such as IP addresses and request logs.

The firm decides which documents it asks for. Uploaded files can include identity documents, bank statements, payslips, tax records and any other document the firm requests. Files, notes and answers may contain special categories of personal data, such as health details on a payslip or a medical report, and personal data relating to criminal convictions and offences, such as a criminal record certificate. They can arrive whether or not the firm asks for them. We don't read or classify what files contain. The firm should only ask for what it needs.

Instructions

We process Client Documents only on the firm's documented instructions. Those instructions are this DPA, the Terms, and the settings and actions the firm uses in the Service, such as the retention period it confirms, the requests and reminders it sends and the files it deletes. If the law requires us to process Client Documents in any other way, we'll tell the firm first, unless the law forbids that. If we think an instruction breaks data protection law, we'll tell the firm.

Confidentiality

Everyone at GarnerDocs who can access Client Documents is bound by a duty of confidentiality, and only accesses them where that's needed to provide or support the Service.

Security

We protect Client Documents with the technical and organisational measures in Annex 2. Our Security page describes them in more detail.

Helping with data subject requests

Firms can handle most requests from their clients themselves in the Service: they can correct a client's details, download a request's files as a ZIP, and delete a request's files before the end of the retention period. Where a firm can't do something itself, such as removing a client's request records without deleting the whole workspace, we'll help it respond.

For anything else, the firm's owner or an admin can email us at [email protected]. We'll give the help or information within 10 business days, or tell the firm why we need longer. If one of the firm's clients contacts us directly about Client Documents, we'll pass the request to the firm without undue delay, and we won't answer it ourselves unless the firm asks us to.

We'll also give the firm the information it reasonably needs about the Service to carry out a data protection impact assessment or to consult a regulator.

Deletion and return

Uploaded files are deleted at the end of the retention period the firm confirms, after the firm's owner and admins have been warned by email. Until then, the firm can download them or delete them earlier. When a firm deletes its workspace, its files and records are deleted too. If we end the agreement, the firm has 30 days to download its files first. Copies in backups expire within 30 days. Annex 1 sets out the details.

The firm authorises us to use the subprocessors for Client Documents on our subprocessors list, which names each one, what it does and where it processes data. Each one is bound by written terms that protect Client Documents to the same standard as this DPA, and we remain responsible to the firm for their work.

Before we add or replace a subprocessor, we'll update the list and email the owner of the firm's workspace at least 30 days before the change takes effect, saying what changes and when. The firm can object on reasonable data protection grounds by contacting us at [email protected] before that date. We'll try to resolve the objection, for example by explaining the safeguards. If we can't, the firm may end the agreement with effect from the date of the change, and we'll refund any fees it has paid for the period after that date.

In an emergency, such as a security incident or a provider stopping its service, we may replace a subprocessor sooner. We'll tell the firm as soon as we can, and the firm can still object and end the agreement as above.

The other service providers on that list, such as Stripe for our billing, don't process Client Documents and aren't subprocessors under this DPA.

If a firm sets up webhooks, we send the event data to the URLs the firm chooses. The firm chooses and controls those recipients; they aren't our subprocessors.

Client Documents are stored and processed in Amazon Web Services' Frankfurt region, in Germany. If the firm turns on automatic document checks, each uploaded file is also processed, only for the check, in one of the AWS regions in the EU that Amazon Bedrock's EU inference profile uses: Frankfurt (Germany), Ireland, Paris (France), Milan (Italy), Spain and Stockholm (Sweden). Some subprocessors are based in the United States or work worldwide, and the subprocessors list shows where each one processes data and the safeguard it relies on: the EU-U.S. Data Privacy Framework for certified US companies, or the EU Standard Contractual Clauses in the subprocessor's data processing terms. We'll only transfer Client Documents to another country with the safeguards data protection law requires.

If we become aware of a personal data breach affecting Client Documents, we'll tell the firm without undue delay. We'll give it the information we have about what happened, the data and clients affected, and what we're doing about it, so it can meet its own obligations to notify a regulator or its clients.

We'll tell the firm within 48 hours of becoming aware of the breach, even if we don't have every detail by then, and send the rest as we learn it.

We'll make available the information a firm reasonably needs to show that we meet our obligations under this DPA, and we'll allow for and contribute to audits by the firm or an auditor it appoints.

We'll first answer a written security questionnaire, once in any 12 months. If the answers don't reasonably show that we meet this DPA, or a supervisory authority requires it, the firm or an independent auditor bound by confidentiality may audit us once in any 12 months. The firm must give us 30 days' notice. The audit takes place during business hours and doesn't give access to other customers' data. Each party bears its own costs, unless the audit shows that we materially breached this DPA.

1. Roles

For Client Documents and related personal data processed through the Service on behalf of the Customer, the Customer acts as Controller and GarnerDocs acts as Processor, except to the extent that applicable law or the nature of a separate processing activity requires otherwise.

2. Processing purpose

GarnerDocs shall process Client Documents only for the documented purposes of document collection, upload, storage, access, review, notification, transfer, export and deletion, together with other processing activities authorised under this Agreement. The Service is a collection tool. It is not intended to serve as the Customer's permanent document repository, statutory records archive or records-management system.

3. Documented retention instructions

3.1 The Customer determines how long uploaded Client Documents are kept after a document request is marked as completed, by choosing one of the periods offered in the Service settings: currently 30, 90, 180 or 365 days. The standard period is 90 days.

3.2 Only the Customer's owner or an administrator can confirm or change the period. The Customer cannot send document requests until a period has been confirmed. Each confirmation or change is recorded in the Customer's activity history with the user who made it and the time.

3.3 The confirmed period constitutes the Customer's documented instruction for the retention of uploaded files following request completion. GarnerDocs shall implement it in accordance with the agreed processing instructions and shall not independently extend or shorten the period for its own purposes.

4. Deletion of completed-request files

4.1 GarnerDocs shall notify the Customer's owner, and administrators who have not opted out, by email 14 days and 3 days before the files of a completed request are deleted, and again once they have been deleted. The first notice fixes the deletion date, which is never less than 14 days after that notice.

4.2 If the Customer shortens its retention period, files are not deleted until at least 14 days after the first notice. If it lengthens the period, the deletion date moves later accordingly.

4.3 Files are deleted only after the final notice has been sent. Upon deletion, GarnerDocs shall delete the uploaded files and any ZIP exports of them from active storage, and close the request's client upload link.

4.4 Failure to receive or read a notice does not suspend a deletion the Customer has instructed.

5. Return and export

5.1 Until a request's files are deleted, any authorised user of the Customer may download them as a ZIP archive containing each current file, earlier versions and files sent back for replacement, and a manifest (CSV) listing each file's document, size, upload time and review outcome. Each ZIP can be downloaded for 24 hours after it is prepared and is then deleted.

5.2 The Customer's owner or an administrator may instruct GarnerDocs to delete a request's files before the end of the retention period using the controls in the Service. Deleted files cannot be recovered.

5.3 The Customer remains responsible for ensuring that documents required for its own legal or professional record-keeping purposes are retained in an appropriate system.

6. End of processing services

6.1 The Customer's owner may delete the Customer's workspace at any time. Before confirming, the owner is pointed to the export described in clause 5.1. On confirmation, all users lose access and client links stop working immediately; GarnerDocs then deletes the uploaded files, ZIP exports and the Customer's records (clients, requests, upload records, activity) from active systems.

6.2 Upon termination or expiry of the relevant processing services, GarnerDocs shall, at the Customer's choice, return or delete the personal data processed on its behalf and delete existing copies, unless applicable law requires continued storage.

6.3 Where GarnerDocs ends the agreement, the Customer's owner may continue to sign in and download the Customer's files, as described in clause 5.1, for 30 days after the agreement ends, unless the Customer deletes its workspace sooner. After that period GarnerDocs shall delete the workspace as described in clause 6.1, and backup copies expire as set out in clause 7. GarnerDocs shall confirm the deletion in writing if the Customer asks.

6.4 A trial or paid subscription ending doesn't end the agreement: the workspace continues with the Starter plan's limits, as the Terms describe, until the Customer deletes it.

7. Backup data

7.1 Deleted files and records may remain in operational backups where immediate deletion is technically impracticable. GarnerDocs shall ensure that such backup data is protected against ordinary access and processing, retained for no longer than 30 days, and then deleted through the established backup-expiry process:

• the documents store keeps prior versions of deleted files for 30 days, then expires them;
• database backups are kept for 14 to 30 days;
• a copy restored from a backup is used only for recovery, with access restricted to authorised staff.

8. Required preservation

Where applicable law requires GarnerDocs to preserve particular personal data, or where a valid documented Controller instruction requires preservation for a lawful purpose, the parties shall determine the scope, duration and permitted use of that data in accordance with applicable law. Any preserved information shall remain subject to appropriate confidentiality and security protections.

9. Retained metadata

9.1 When files are deleted, the request record remains in the Customer's workspace: the request title, the names of the documents requested, the names, sizes and upload times of the files, review decisions, whether each file was automatically checked (not what the check found) and the activity history, including a record of the deletion (who or what deleted the files, why and how many).

9.2 Such records that contain personal data remain subject to the Controller's documented instructions and applicable data-protection requirements. GarnerDocs shall not treat them as exempt from data-protection obligations merely because the corresponding uploaded files have been deleted. They are deleted with the Customer's workspace.

10. Subprocessors

GarnerDocs shall ensure that authorised subprocessors processing Client Documents (including hosting, file storage and email delivery) are bound by applicable contractual obligations concerning security, retention, return and deletion, consistent with this Agreement and applicable data-protection law.

These are the measures described on our Security page.

• Location: the servers, database, file storage and backups are in Amazon Web Services' Frankfurt region (eu-central-1), in Germany.
• Storage: uploaded files, files the firm shares with its clients and ZIP exports are stored as private files and are never given a permanent public address. The storage bucket blocks all public access, and files are encrypted at rest.
• Production access: only GarnerDocs's founder can reach the production servers, database and file storage, through accounts protected by two-factor authentication.
• Downloads: a firm user can open or download a file only after GarnerDocs checks that they belong to the firm, through a signed link that expires after 5 minutes and works for whoever holds it until then. Clients download the files a firm shares with them through their request link, after entering its PIN if it has one.
• Webhook download links: if the firm turns on download links for a webhook endpoint, each link expires 60 minutes after the event is sent and downloads the file for whoever holds it, without signing in. A link stops working sooner if the endpoint is deleted, download links are turned off or the firm's plan no longer includes webhooks. The firm decides whether to use them and controls the systems that receive them.
• Access records: each time a firm user opens or downloads an uploaded file or a shared file, we record who and when. Each ZIP download is recorded with who, when and the number of files. Each client download of a shared file, and each use of a webhook download link, is recorded with the time but not the person, because those links work without signing in. Except for ZIP downloads and a client's first download of a shared file, these records aren't shown in the Service yet.
• Separate workspaces: every client, request, file and note belongs to exactly one firm, and people only see their own firm's records. Clients only see their own request.
• Team roles: a firm's team has three roles: owner, admin and member. Owners and admins manage the team and settings, and the owner manages billing. By default, every member of a firm, whatever their role, can open and download the files of every request in the firm's workspace. Owners and admins can restrict a request to themselves and the members they choose; restricting a request needs the firm to require two-factor authentication for everyone, and webhooks send nothing about restricted requests.
• Client links: each request's link contains a random 48-character token. We keep a hash of it to look the link up, and a copy encrypted with the Service's encryption key, which isn't stored in the database, so the firm can copy the link again. A firm can reset a link at any time, and the old link stops working straight away. Clients don't need an account or password.
• Link closure: a link stops working when its request is cancelled, and once a completed request's files are deleted. A completed request's link also closes 90 days after completion, even if the files are kept longer.
• Rate limiting: the client upload pages are rate limited, and repeated attempts at links that don't exist are refused, so links can't be found by guessing. They're also kept out of search engines.
• In transit and in the browser: the Service is served only over HTTPS, with HSTS. Session cookies are sent only over secure connections and can't be read by scripts on the page. A Content Security Policy limits the scripts a page will run, and pages can't be embedded in other sites.
• Accounts: passwords are stored hashed, never as plain text, and new accounts confirm their email address before using the workspace. Each user can turn on two-factor authentication with an authenticator app, with one-time recovery codes, and a firm's owners and admins can require it for everyone in the firm. Single sign-on isn't available yet.
• Activity history: each request records its main events: when it was sent and opened, what the client uploaded, each reminder, review, link reset, ZIP download and deletion, with who did it and when. Changes to the team and to the retention period are recorded too.
• File checks: each upload is checked against the file types the firm accepts, by reading the file's content rather than its name. Each upload is scanned for malware with Amazon GuardDuty Malware Protection for S3, in the AWS region where it is stored, and the firm's users can't open it until the scan finds nothing. A file in which malware is found is deleted. A file that can't be scanned stays blocked until one of the firm's owners or admins releases it.
• Automatic document checks: off unless one of the firm's owners or admins turns them on, which the activity history records. Each file the firm's team can open (after the malware scan) is then sent to Claude, an AI model made by Anthropic, on Amazon Bedrock in the EU regions named under International transfers, with the request title and the requested document's name and description, and compared with what was asked for. Amazon Bedrock runs the model in AWS accounts that Anthropic can't access, and our Bedrock account is set not to retain inputs or outputs; AWS may still keep and report an image its automated systems flag as apparent child sexual abuse material. Possible problems are shown only to the firm's team, which reviews every file: the check makes no decision about the client. The result is encrypted at rest, isn't included in notifications, webhooks or ZIP exports, and is deleted with the files.
• Retention and deletion: files are deleted at the end of the retention period the firm confirms, after email warnings 14 days and 3 days before, as set out in Annex 1.
• Backups: copies of deleted files may stay in backups for up to 30 days, until the backups expire, as set out in Annex 1 (clause 7.1).