Data Processing Addendum — Scope

DRAFT — NOT LEGAL ADVICE — REQUIRES REVIEW BY A QUALIFIED SOLICITOR BEFORE PUBLICATION

Jurisdictions this draft assumes: the United Kingdom first (UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025) and the EU/EEA second (Regulation (EU) 2016/679).

Jurisdictions this draft does not cover: the United States (including state privacy laws and the Illinois and Texas biometric statutes), Canada and Quebec, Australia, New Zealand, India, the UAE and the wider GCC, Singapore, Brazil, South Africa and Japan. Several of those need their own contractual terms, and Quebec's Law 25 and India's DPDP Act in particular impose obligations this document does not contain.

Version: [TO CONFIRM: version number] · Effective date: [TO CONFIRM: effective date]

1. What this document is

This is the Article 28 data processing agreement between you (the Customer) and [TO CONFIRM: legal entity name] (Scope). It forms part of the Terms of Service and applies whenever Scope processes personal data on your behalf.

Where this addendum and the Terms of Service conflict on data protection, this addendum wins.

2. Which of us is which

You are the controller. We are the processor.

You decide to record your client, for your own commercial purpose — to produce a quote and win work. That decision is what makes you the controller of the meeting data. We hold and process that data because you have asked us to.

This applies to: audio, consent artefacts, transcripts, extracted scope, photographs and measurements, quotes and rendered documents, and the client details you enter.

It does not apply to your own account and billing data, where Scope is the controller in its own right. The Privacy Policy covers that.

2.1 What being the controller means for you

As controller you are responsible for:

• having a lawful basis for recording your client, and for everything you do with the recording;
• obtaining consent from everyone present, and being able to evidence it (see the Recording and Consent Policy);
• telling the people you record what you are doing and why;
• answering their requests to access, correct or delete their data;
• deciding what to redact when Scope flags sensitive content;
• deciding how long data is kept, within the retention options your plan offers.

2.2 What being the processor means for us — and why you cannot sign it away

We act only on your instructions. But a processor also has obligations that run directly to it under UK and EU data protection law, and which no agreement between us can remove or transfer to you:

• to process only on documented instructions, and to tell you if an instruction appears to breach the law;
• to keep the data secure under Article 32;
• to impose the same obligations on every sub-processor we use, and to remain liable for them;
• to help you meet requests from the people you record;
• to notify you of a personal data breach without undue delay;
• to be able to demonstrate all of the above.

This matters because the allocation of responsibility in this agreement and in the Terms of Service is real but partial. It decides what you and we owe each other. It does not decide what a regulator can require of us directly, and it does not bind the person you recorded.

3. Our instructions from you

We will process personal data only:

• to provide the service described in the Terms of Service;
• as set out in Schedule 1;
• as otherwise instructed by you in writing;
• where required by law, in which case we will tell you first unless the law forbids it.

We do not use your meeting data for our own purposes. We do not sell it, we do not use it to build products for anyone else, and we do not use it — or allow any sub-processor to use it — to train AI models. [TO CONFIRM: this last sentence must be verified against every vendor contract before publication; the ASR vendor is unselected and at least one candidate offers a discount in exchange for training rights]

We will tell you if, in our opinion, an instruction from you would breach data protection law.

4. Confidentiality

Everyone we allow to process your data is bound by confidentiality obligations and is trained on their responsibilities. Access is limited to those who need it to do their job.

5. Security

We take the technical and organisational measures set out in Schedule 3. We may change them, but not in a way that materially reduces the level of protection.

6. Sub-processors

You give us general authorisation to use the sub-processors listed in Schedule 2.

• We will keep Schedule 2 up to date and publish it at [TO CONFIRM: public subprocessor page URL].
• We will give you at least 30 days' notice before adding or replacing a sub-processor that processes meeting data. [TO CONFIRM: notice period]
• You may object on reasonable data protection grounds within that period. If we cannot resolve the objection, you may terminate the affected part of the service and we will refund any unused prepaid fees.
• Every sub-processor is under a written contract imposing obligations equivalent to this addendum.
• We remain fully liable to you for our sub-processors' acts and omissions.

You can subscribe to change notifications at [TO CONFIRM: how customers subscribe to subprocessor change notices].

7. International transfers

Most of your data stays in the UK and the EU. Schedule 2 says exactly where each supplier processes it.

One transfer leaves the UK and EEA, and we state it rather than bury it. The AI model that extracts the scope of work from your transcript is provided by Anthropic and runs in the United States. Transcript text is sent there. Audio is not.

For that transfer we rely on:

• the International Data Transfer Agreement (or the UK Addendum to the EU SCCs) for UK-originated data;
• the EU Standard Contractual Clauses for EEA-originated data — [TO CONFIRM: which module. Module 2 (controller-to-processor) is what the research brief assumes, but where Scope is itself the processor and Anthropic is a sub-processor, Module 3 (processor-to-processor) is normally the correct one. This must be settled before signature.]
• a documented Transfer Impact Assessment — [TO CONFIRM: this must be written, not merely referenced];
• [TO CONFIRM: whether Anthropic is certified under the EU–US Data Privacy Framework, and whether we rely on it].

We maintain the SCCs and IDTA as the primary mechanism rather than relying on an adequacy framework alone, because the EU–US Data Privacy Framework is currently under appeal at the Court of Justice and a third invalidation is a live possibility.

If you cannot accept a US transfer, tell us. The AI provider sits behind our own abstraction and can be pointed at an EU-hosted endpoint for the same model. [TO CONFIRM: whether an EU-hosted endpoint is available at launch, on which plans, and at what price. Data region choice is currently listed as a Business-tier feature at £229/month, with an additional region at £49/month.]

8. Helping you with the people you record

We will help you, taking into account the nature of the processing and the information available to us:

• Requests from data subjects. If a person you recorded contacts us, we will tell them the recording belongs to your business, pass the request to you without undue delay, and help you act on it. We will not act on it without your instruction.
• Access, correction, deletion, portability and objection. The product gives you tools to do all of these yourself. Where the tools are not enough, we will help.
• Data protection impact assessments and prior consultation with a supervisory authority, where Articles 35 and 36 require them.

9. Breach notification

If there is a personal data breach affecting your data, we will:

• tell you without undue delay after becoming aware of it, and in any event within [TO CONFIRM: internal notification target — the GDPR obliges you as controller to notify a supervisory authority within 72 hours, so our notice to you must leave you time to do that; 24 hours is a common commitment];
• describe what happened, the categories and approximate number of people and records involved, the likely consequences, and what we are doing about it, so far as we know;
• keep you updated as we learn more;
• help you meet your own notification duties.

We will not delay telling you because our information is incomplete.

10. Deletion and return

• You can export all of your data at any time, in a machine-readable format, while your account is open.
• Audio is deleted automatically on the retention schedule in Schedule 1. Deletion is a real deletion carried out by a scheduled job.
• On termination, your data stays exportable for 90 days, then we delete it.
• We will delete on your instruction at any time, including data relating to a specific person you recorded.

One honest limit. Backups are encrypted and roll off on a fixed schedule. We do not surgically edit a backup. Data you have deleted therefore leaves the live systems immediately and leaves the backups within [TO CONFIRM: maximum backup retention window — currently 14 days at launch, 35 days once there are paying customers]. Until then it remains in an encrypted backup and is not accessible in the ordinary course.

11. Audits and information

We will make available the information you reasonably need to show we are meeting our obligations under Article 28. In practice that means:

• this addendum and the published sub-processor list;
• our security documentation and answers to a reasonable security questionnaire;
• [TO CONFIRM: whether any third-party audit report or certification will exist. At launch there is no SOC 2 report and no ISO 27001 certification, and a penetration test is planned rather than complete. Say so rather than implying otherwise.]

You may audit us, or have an independent auditor audit us, no more than once a year and on 30 days' notice, unless a regulator requires otherwise or we have had a breach affecting your data. Audits happen in business hours, must not disrupt the service, and are at your cost unless they find a material breach.

12. Liability

Each party's liability under this addendum is subject to the limits in clause 12 of the Terms of Service, except where data protection law does not allow it to be limited. Nothing here limits any right a data subject has directly against either of us under Article 82.

13. Duration

This addendum applies for as long as we process personal data on your behalf, and the obligations that by their nature should survive — confidentiality, deletion, audit — survive termination.

Schedule 1 — Details of the processing

Subject matter. Providing the Scope service: recording, storing, transcribing, extracting a scope of work from, pricing and producing documents from business meetings.

Duration. For as long as the Customer's account is open, plus the retention and deletion periods below.

Nature and purpose. Storage, transcription by automated speech recognition, extraction of structured information by an AI language model, verification of extracted claims against the transcript, pricing calculation, document rendering, and making all of the above available to the Customer.

Types of personal data

Categories of data subject

• The Customer's own staff and users
• The Customer's clients, and anyone else present at a recorded meeting — including family members, tenants, neighbours and other trades, who may not have any relationship with the Customer
• People named or discussed in a meeting who were not present

Retention

[TO CONFIRM: the research brief argues for a short default retention of raw audio (30–90 days) on GDPR proportionality grounds, on the basis that the purpose is generating one quote. The commercial plan sells 12-month and 24-month retention as a paid feature. Counsel should confirm that a 12- or 24-month retention of a third party's voice is proportionate to that purpose, and that the Customer — as controller — is the one choosing it.]

Schedule 2 — Sub-processors

Current as at [TO CONFIRM: date]. The authoritative, current version is published at [TO CONFIRM: public subprocessor page URL].

On the Free plan, transcription runs on the user's own device. No speech-to-text vendor receives Free-tier audio.

Schedule 3 — Technical and organisational measures

Encryption

• TLS in transit everywhere; HSTS on the web application.
• Encryption at rest by default in the database and the object store.
• Audio is never in a public bucket. All access is by short-lived signed link.

Access control

• Every record carries a business identifier. Separation between customers is enforced twice: by default in the data access layer, and again by an automated cross-tenant denial test generated for every endpoint, which fails the build if it is missing.
• Every endpoint declares the permission it requires; the service refuses to start if one does not.
• Roles are least-privilege by default, including on invitations.
• Authentication is a standards-based OpenID Connect issuer, not a hand-rolled token scheme. Sign-in uses the Authorization Code flow with PKCE, and the code exchange is refused without a valid verifier.
• Access tokens are short-lived (15 minutes) and signed with an asymmetric key whose private half is held in the managed secret store and never leaves it. Refresh tokens rotate; reuse is detected and invalidates the whole session family, forcing re-authentication.
• Rate limiting on authentication endpoints from the first deployment.
• No routine production database access. Access is deliberate, time-boxed and logged.
• The background-job dashboard sits behind administrator authentication.

Data minimisation and logging

• Transcript contents never enter logs. Logs carry a meeting identifier, a business identifier and a correlation identifier.
• No production data in any other environment, ever. Debugging uses a scrubbed extract or a reproduction.
• No voice embeddings or voiceprints are stored anywhere. Speaker separation, where enabled, is a transient property of a transcript and is discarded.

Secrets

• Held in a managed secret store and injected as environment variables, never in the repository or configuration files, with an automated check that fails the build on a committed secret.
• Every credential is rotatable without a code change.

Resilience

• Automated daily backups with point-in-time restore: 14 days at launch, 35 days once there are paying customers.
• Restore drills are scheduled, run against a scratch server, and timed. An untested backup is a belief, not a backup.
• Recovery targets: [TO CONFIRM] five minutes of data loss (RPO) and two hours to restore (RTO). These are honest targets for a small team and are stated as such rather than inflated.

Software supply chain

• Dependency vulnerability scanning on every build.
• Migrations run as their own deployment step and are never applied from application start-up.

What does not exist yet, stated plainly

• No SOC 2 report and no ISO 27001 certification.
• No completed penetration test — one is planned once there is revenue to justify it, and before any conversation with a customer who requires SOC 2.
• No 24/7 on-call rota. Scope is a small team and alerting is deliberately limited to four conditions.
• Signing out does not revoke an already-issued access token. Sign-out clears the token from the device; the token itself remains valid until it expires, because no revocation endpoint is enabled yet. The exposure window is the access-token lifetime above, not the session.
• Email addresses are not verified at sign-up, because public registration is closed and no account can be self-created. When registration reopens, verification is a precondition, not a follow-up.

Updated 11 September 2026 to match the shipped authentication system (SCOPE-037). The two items added under "what does not exist yet" were true before this update and were simply not written down; nothing here describes a reduction in protection.

Evidence index