Data processing agreement

Version: draft. Effective date: [effective date]. This agreement forms part of the terms of service.

1. Parties and the chain

This agreement is between you, the customer named on the Restorable account ("the Customer"), and Brindleford Technologies Ltd, company number [company number], registered office [registered office address] ("Restorable").

The Customer is typically a managed service provider that backs up Microsoft 365 tenants belonging to its own clients. The Customer's role depends on its own arrangements with those clients:

• Where the Customer is the controller of the personal data in a tenant it connects, Restorable is its processor.
• Where the Customer is itself a processor for its client, and its client is the controller, Restorable is a sub-processor. In that case the Customer confirms that its own contract with its client permits it to appoint Restorable, and that it has whatever authorisation that contract requires.

Either way, the Customer determines what is backed up, for how long, to which storage and by which policy. Restorable processes on the Customer's documented instructions and for no other purpose. Restorable is a controller in its own right only for the account and billing data described in the privacy notice, which this agreement does not cover.

2. Definitions

"Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the EU GDPR where it applies, and any successor or equivalent legislation. "Controller", "processor", "sub-processor", "data subject", "personal data", "processing", "personal data breach" and "supervisory authority" have the meanings given in the UK GDPR. "Customer Personal Data" means personal data that Restorable processes on the Customer's behalf under this agreement, as described in Annex 1.

3. Subject matter, duration, nature and purpose

The subject matter is the provision of the Restorable service. The duration is the term of the terms of service, plus any post-termination period in clause 11. The nature and purpose of the processing, the types of personal data and the categories of data subject are set out in Annex 1.

4. Restorable's obligations

1. Instructions. Restorable processes Customer Personal Data only on the Customer's documented instructions, which comprise this agreement, the terms of service and the configuration and actions the Customer takes in the console or through the API. Restorable will tell the Customer if it believes an instruction infringes Data Protection Law, and may pause that processing while the point is resolved.
2. No other purpose. Restorable will not use Customer Personal Data for its own purposes, will not sell it, and will not use it to train machine learning models.
3. Legal compulsion. If law requires Restorable to process Customer Personal Data other than on instruction, it will tell the Customer beforehand unless that law prohibits it.
4. Confidentiality. Access is limited to personnel who need it to provide or support the service. They are bound by confidentiality obligations that survive their engagement, and are trained on their responsibilities.
5. Security. Restorable implements and maintains the technical and organisational measures in Annex 2, appropriate to the risk, and will not materially reduce them during the term.
6. Assistance with data subject rights. Restorable will not respond to a data subject directly. It will pass on any request it receives without undue delay and will assist the Customer in answering it, using the console's search, export and deletion tools and, where those are not sufficient, reasonable manual assistance.
7. Assistance with assessments. Restorable will provide the Customer with the information it reasonably needs for a data protection impact assessment or a consultation with a supervisory authority, so far as it relates to Restorable's processing.

5. The Customer's obligations

1. The Customer warrants that it has a lawful basis for the processing it instructs, and that it has given data subjects whatever information Data Protection Law requires about the use of a backup provider.
2. The Customer will connect a Microsoft 365 tenant only with the authority of the organisation that controls it.
3. The Customer chooses the storage provider, the bucket and the region, and is responsible for the lawfulness of that choice, including any international transfer it involves and any object-lock or retention setting that prevents deletion.
4. The Customer sets and safeguards the recovery passphrase, and accepts that Restorable cannot recover it.
5. The Customer is responsible for the accuracy of the retention settings on its policies and for instructing the deletion it needs.

6. Sub-processors

The Customer gives Restorable general written authorisation to appoint the sub-processors listed on the sub-processors page, which forms Annex 3. Restorable will:

• impose data protection obligations on each sub-processor that are no less protective than those in this agreement, by written contract;
• remain liable to the Customer for a sub-processor's acts and omissions in relation to Customer Personal Data;
• give the Customer at least [sub-processor notice period, for example 30 days] notice by email to the account's owners before adding or replacing a sub-processor, and maintain the sub-processors page as the authoritative list;
• allow the Customer to object on reasonable data protection grounds within that notice period. If the objection cannot be resolved, the Customer may terminate the affected part of the service without penalty for the unexpired term.

The Customer's own storage provider is not a sub-processor of Restorable. It is engaged by the Customer under the Customer's own contract, and the Customer is responsible for its appointment.

7. Personal data breach

Restorable will notify the Customer without undue delay, and in any event within [breach notification window, for example 48 hours] of becoming aware of a personal data breach affecting Customer Personal Data. The notification will describe the nature of the breach, the categories and approximate number of data subjects and records affected so far as known, the likely consequences, the measures taken or proposed, and a contact point. Restorable will provide reasonable further information as the investigation proceeds so that the Customer can meet its own notification duties. Restorable will not notify a supervisory authority or a data subject on the Customer's behalf unless the Customer asks it to in writing.

8. Audits and information

Restorable will make available the information reasonably necessary to demonstrate compliance with this agreement, and will answer a written security questionnaire not more than once in any twelve-month period. The Customer may audit Restorable's compliance, on at least 30 days' written notice, not more than once in any twelve-month period unless a breach or a supervisory authority requires otherwise, during business hours, subject to confidentiality, without access to other customers' data or to shared infrastructure that cannot be segregated, and at the Customer's cost. Restorable holds no third-party security certification today: [certifications, for example ISO 27001 or SOC 2, if and when obtained].

9. International transfers

Restorable hosts the service in the European Union (France). Where Restorable transfers Customer Personal Data to a country without UK or EU adequacy, it will do so under the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or under the EU Standard Contractual Clauses with the Customer as data exporter and Restorable or its sub-processor as data importer, together with any additional measures the transfer risk assessment requires. The specific mechanism relied on for each sub-processor is [confirm per sub-processor]. Where those clauses conflict with this agreement, the clauses prevail.

10. Liability

The limitations and exclusions of liability in the terms of service apply to this agreement, except to the extent Data Protection Law does not permit them. [A solicitor must review the interaction between the liability cap and Article 82 of the UK GDPR, and whether a separate cap or an uncapped carve-out is appropriate for data protection claims.]

11. Deletion and return on termination

On termination, or earlier on written instruction:

• Backup content stays where it is, in the Customer's own bucket. Restorable has no copy to return and no ability to delete it. Deleting it, or not, is the Customer's decision and the Customer's action.
• Restorable will make the recovery bundle and the client manifests available for download for [post-termination access window] so that the Customer can read its own bucket without the service.
• Restorable will then delete the index, the audit log and the wrapped keys it holds within [deletion window, for example 30 days], other than data it must keep by law, which it will keep only for as long as that law requires and only for that purpose. Backups of Restorable's own database age out on their normal cycle.
• Restorable will confirm the deletion in writing if the Customer asks.

12. Precedence and general

Where this agreement conflicts with the terms of service, this agreement prevails on data protection matters. Where it conflicts with the Standard Contractual Clauses, the clauses prevail. This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction, without prejudice to any data subject's rights or to the jurisdiction provisions of any Standard Contractual Clauses that apply.

Annex 1: description of the processing

Nature and purpose

Reading Microsoft 365 data from connected tenants through Microsoft Graph; encrypting it and writing it to the Customer's own storage; storing metadata about it in an index so that it can be listed and searched; restoring it to Microsoft 365 or exporting it, on instruction; verifying that stored objects are intact; producing reports and notifications; and keeping an audit log.

Duration

The term of the terms of service, plus the post-termination periods in clause 11.

Categories of data subject

• Employees, contractors and other users of the Customer's clients whose mailboxes or OneDrive accounts are protected.
• Anyone who has sent mail to, or received mail from, a protected mailbox, or who appears in a protected file or a SharePoint library.
• The Customer's own personnel who use the console and the API. Their personal data is also covered by the privacy notice, where Restorable is controller.

Types of personal data

Restorable does not select the data. The Customer selects which mailboxes, drives and libraries are protected, and the source system determines the content. Special category data will be present if the source contains it.

Sensitive data restrictions

The Customer must not use the service to process personal data for which the additional safeguards in Annex 2 are inadequate, and must tell Restorable in writing before protecting a tenant that will contain special category data at scale, so that any additional measure can be agreed: [confirm whether any additional measures are offered].

Annex 2: technical and organisational measures

• Encryption at rest. Every backup object is encrypted before it leaves Restorable's infrastructure, with a 256-bit key unique to each of the Customer's clients, versioned so old objects stay readable. Payloads are sealed in one megabyte chunks with AES-256-GCM, with the object key bound in as associated data so an object cannot be substituted or truncated undetected.
• Key management. Client keys are wrapped under a control-plane key held by Restorable, which is what allows unattended backups, and also under a key derived with Argon2id from a passphrase set by the Customer and never stored. Restorable can therefore decrypt Microsoft 365 backup content; this is inherent in agentless backup and is stated plainly rather than obscured. A separate verifier allows a typed passphrase to be checked without touching a key. Passphrase changes and key rotations are transactional and audited.
• Encryption in transit. TLS for all external traffic, with HTTP Strict Transport Security, and TLS to Microsoft Graph and to the storage endpoint.
• Object naming. Object keys carry no readable customer information: tenant, workload, principal identifier, a hash of the source item identifier, and a version number.
• No content indexing. Message bodies and file contents are never indexed or stored in Restorable's database.
• Access control. Four roles with least privilege, no privilege escalation, protection of the last owner, second-factor authentication available on every account, single-use time-limited password reset links, session revocation on password change and on user removal, and API keys that can be restricted to named clients.
• Tenant isolation. Every table holding customer-owned data carries the account identifier, every query filters on it, this is enforced in a single data access layer rather than in individual handlers, and a build-time check fails if a query bypasses it.
• Credential handling. Storage access key secrets are encrypted under the control-plane key and never redisplayed. Configuration and secrets are read in one place and not scattered through the code.
• Auditability. An append-only audit log of consent changes, protection changes, restores, exports, searches with a term, recovery bundle downloads and key operations, each with the acting user.
• Integrity checking. A verification job after every backup run confirms that each object written is present at the expected size and repairs any that is not. An offline verify mode opens every object without writing anything.
• Resilience and recoverability. Backup jobs record their position and resume after an interruption. Restorable's own database is backed up. Customer backup content is in the Customer's bucket, so the loss of Restorable's infrastructure is not the loss of the Customer's data, and the documented offline recovery path exists to prove it.
• Restore safety. The default restore target is a dated folder that cannot overwrite live data, and a restore in place never overwrites a changed file.
• Monitoring and logging. Structured logging with the account and job identifier on every line, metrics not exposed publicly, and alerting on failure.
• Segregation of environments. Development is local and does not use production data.
• Personnel. Access limited to those who need it, under confidentiality obligations. [Confirm background check and onboarding or offboarding process.]
• Deletion. Deletion is explicit, scoped and audited rather than implicit, and refuses to run where a legal hold is set.

[This annex should be reviewed against the Customer's own security schedule. Items marked as placeholders are process commitments not yet formalised, including business continuity testing, penetration testing cadence and formal incident response runbooks.]

Annex 3: authorised sub-processors

The current list, with the purpose and the data each one processes, is maintained at restorable.cloud/subprocessors.html and forms part of this agreement. Changes are notified under clause 6.