Data processing agreement
The Article 28 terms on which we process personal data on your firm’s behalf. Your firm is the controller. We are the processor. This is the document your compliance file needs.
Last updated · Applies to DutyDesk, operated by AppstackX Ltd
How this agreement is entered into
This agreement is incorporated into the terms of service and takes effect when your firm creates a DutyDesk account. There is nothing separate to sign.
If your compliance file needs a countersigned copy on paper — and an FCA-regulated firm's often does — email khuram@appstackx.co.uk and we will provide one in the same terms as this page.
1. Parties and roles
This agreement is between the firm subscribing to DutyDesk (the Controller) and AppstackX Ltd (the Processor), a company registered in England & Wales under company number 16287309, registered office 18 Westergate Avenue, Brooklands, Milton Keynes, England, MK10 7LQ, registered with the Information Commissioner's Office under reference ZC135044.
| Data | Controller | Processor |
|---|---|---|
| Records about the firm's own customers — customer records, vulnerability records, assessments, board report content, and the audit log of work on them | The firm | AppstackX Ltd |
| Records about the firm's staff as users of DutyDesk — account details, authentication, product analytics, support correspondence | AppstackX Ltd | Not applicable — governed by our privacy policy |
Data Protection Officer. Article 37 of the UK GDPR requires one where an organisation is a public authority, or where its core activities consist of large-scale regular monitoring of individuals or large-scale processing of special category data. AppstackX Ltd is not a public authority, and neither its scale nor its core activity meets those tests, so no appointment is required. Should AppstackX Ltd appoint one, this agreement will name them.
Our contact point for all matters under this agreement — instructions, breach notifications, data subject requests passed to us, audit requests and security questionnaires — is khuram@appstackx.co.uk.
2. Definitions and interpretation
Data Protection Laws means the UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications Regulations 2003, each as amended. Controller, processor, personal data, special category data, processing, data subject and personal data breach have the meanings given in the UK GDPR. Customer Personal Data means personal data processed by us on the Controller's behalf under this agreement.
This agreement forms part of, and is subject to, the terms of service. Where the two conflict on a data protection matter, this agreement prevails.
3. Our obligations as processor (UK GDPR Article 28(3))
The clauses in this section correspond one for one to the obligations Article 28(3) requires a processor to accept.
(a) Processing only on documented instructions
We process Customer Personal Data only on the Controller's documented instructions, including in relation to transfers to a third country, unless we are required to do otherwise by law — in which case we will tell the Controller before processing, unless the law prohibits us from doing so on important grounds of public interest.
The Controller's documented instructions comprise:
- this agreement and the terms of service;
- the Controller's use of the product's features — creating a record, running an AI draft, exporting a report, inviting a user, and so on are all instructions to process;
- any further written instruction the Controller gives us.
We do not process Customer Personal Data for our own purposes. We do not use it to train machine learning models, our own or anyone else's. We do not sell it, and we do not disclose it to anyone other than the sub-processors in Annex 3.
We will tell the Controller immediately if, in our opinion, an instruction infringes Data Protection Laws. We may pause the processing concerned until the point is resolved.
(b) Confidentiality
We ensure that every person authorised to process Customer Personal Data is bound by an appropriate duty of confidentiality, whether by contract of employment, contractor agreement, or statutory obligation, and that the duty survives the end of their engagement.
Access to production data is limited to the individuals who need it to operate and support the service, and is granted on a least-privilege basis.
That access is held by one named individual: Khuram Masood, the director of AppstackX Ltd. His duty of confidentiality to the Controller arises under this agreement and as an officer of the company. No contractor, agency or third-party administrator holds access to the production database or to the service-role credentials. If anyone else is ever given access — an employee, a contractor, an agency — they will be under a written confidentiality undertaking that survives the end of their engagement, and this clause will be updated before they are given it.
(c) Security of processing (Article 32)
We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing — with particular regard to the special category data described in section 4.
Those measures are set out in Annex 2. We may update them, but not in a way that materially reduces the overall level of security.
(d) Sub-processors
The Controller gives us general written authorisation to engage sub-processors. Those engaged as at the date of this agreement are listed in Annex 3.
Where we engage a sub-processor:
- we impose on it, by written contract, data protection obligations no less protective than those in this agreement;
- we remain fully liable to the Controller for the sub-processor's performance of those obligations;
- we carry out reasonable due diligence on its ability to meet them before engaging it.
Notice and objection. We give the Controller at least 30 days' notice by email to its account administrators before a new or replacement sub-processor begins processing Customer Personal Data. The Controller may object on reasonable data protection grounds within those 30 days. If it does, we will work with it to find a solution; if none is found, the Controller may terminate the affected part of the service, or the subscription, without penalty and with a pro-rata refund of any fees paid for the period after termination. Continuing to use the service after the 30 days without objecting is taken as acceptance.
On our contracts with the sub-processors currently engaged. Supabase, Vercel, Anthropic, MailerSend, Sentry and Stripe each publish a data processing agreement, incorporating the EU standard contractual clauses as modified by the Information Commissioner's UK Addendum, which forms part of the terms we have accepted.
Inngest schedules our background jobs and runs in the United States. The jobs themselves execute inside our own infrastructure in Ireland and read the Controller's records there; what reaches Inngest is which firm has work due, and never whose records it concerns. It holds no customer names, no register entries and no report contents, and no Customer Personal Data is transferred to it.
(e) Assisting with data subject rights
Taking into account the nature of the processing, we assist the Controller by appropriate technical and organisational measures, insofar as this is possible, to fulfil the Controller's obligation to respond to requests to exercise rights under Chapter III of the UK GDPR.
In practice:
- the Controller can service most requests without us. Every record is visible, editable and exportable from within the product, and the register and audit log export to CSV and PDF — so access, rectification, erasure and portability are self-service;
- if a data subject contacts us directly, we will not respond substantively. We will tell them to contact their advice firm and let the Controller know without undue delay;
- where a request cannot be serviced through the product, we will provide reasonable assistance, including retrieving data that is not exposed in the interface.
(f) Assisting with security, breaches, DPIAs and prior consultation (Articles 32 to 36)
Taking into account the nature of the processing and the information available to us, we assist the Controller in meeting its obligations under Articles 32 to 36 — security of processing, notification of a personal data breach to the ICO and to affected data subjects, data protection impact assessments, and prior consultation.
Breach notification is dealt with in section 5. For a DPIA, we will provide the information about our processing that the Controller reasonably needs, including the content of Annexes 1 to 3 and reasonable answers to a security questionnaire.
(g) Deletion or return at the end of the service
At the Controller's choice, we delete or return all Customer Personal Data at the end of the provision of services, and delete existing copies, unless law requires us to keep them.
- Return — export to CSV, PDF and Word is available from within the product at any time while the account is open, including after a subscription has been cancelled. The Controller does not need to ask us for it. It should take the export it needs before closing the account, because closing ends access for everyone at the firm, export included.
- Retention window — the 90 days runs from closure of the account, not from cancellation of a subscription. Cancelling deletes nothing: the account stays open, the records stay put and export keeps working. During the 90 days after closure nobody at the firm can sign in, so a Controller that needs its data back should email us inside the window and we will either reopen the account or send a copy.
- Deletion — at the end of that window we delete the data. The Controller may instruct us to delete sooner, and we will comply.
- How the deletion happens — a scheduled job runs once a day, selects the firms closed more than 90 days earlier, and deletes their compliance records, their audit log, their user rows and the sign-in credentials behind them. It runs on the first daily pass after the 90 days have elapsed.
- Backups — encrypted backups are taken daily and retained for seven days, so a firm's data leaves the backup set within seven days of the purge. Annex 2 sets out the arrangement.
- Confirmation — we will confirm deletion in writing on request.
(h) Information and audit rights
We make available to the Controller all information necessary to demonstrate compliance with the obligations in Article 28, and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates.
The Controller is an FCA-regulated firm, and its supervisor may ask how it oversees its outsourced providers. We welcome that scrutiny.
The terms on which we do it:
- Answers first. On request we complete the Controller's own security or due diligence questionnaire, and provide the content of Annexes 1 to 3 and any reasonable follow-up, at no charge and within 30 days.
- A full audit — of our systems, records and premises so far as they relate to the processing — once in any 12-month period, on 30 days' written notice, during business hours, and without unreasonable disruption to the service. The Controller may use an independent auditor it mandates, provided that auditor is not a competitor of ours and is under a duty of confidentiality.
- Cost. The Controller bears the cost of its own audit, including our reasonable time. We bear it, and the audit does not count against the once-a-year limit, where the audit follows a personal data breach affecting the Controller or finds a material breach of this agreement.
- No annual limit applies where an audit is required by the Controller's regulator or by a supervisory authority. A regulator does not wait for our calendar.
4. Special category data
A vulnerable customer register is Article 9 data by design
The FCA's four vulnerability drivers include health — physical or mental conditions affecting decision-making — and life events such as bereavement, divorce, redundancy and caring responsibilities. Recording that a customer is vulnerable for a health reason is processing of data concerning health, which is special category personal data under Article 9(1) UK GDPR. Entries under the other drivers, and free-text notes, may reveal special category data by inference.
The Controller's responsibility. The Controller must identify a lawful basis under Article 6 and, separately, a condition under Article 9(2) together with any associated condition in Schedule 1 of the Data Protection Act 2018, and must record that assessment — including, where Schedule 1 requires it, an appropriate policy document. That determination is the Controller's alone, and nothing in the product makes it or should be read as making it.
Our responsibility. We process this data only on the Controller's instructions and apply the measures in Annex 2, with these product-level controls specific to special category data:
- Data minimisation is designed in. The product provides no field for a full date of birth, National Insurance number, address, contact details, bank details, portfolio values or advice records. Vulnerability is captured as four fixed drivers and a three-value severity scale, with free text confined to two fields capped at 2,000 characters each.
- Guidance discourages clinical detail. The in-product helper text asks firms to record the observation and the adjustment made rather than a diagnosis.
- Isolation is enforced by the database. Row-level security scopes every query to a single firm, and within a firm the adviser role sees only records assigned to them. This is not application logic that could omit a filter.
- Every access-affecting change is audited — creation, edit, review, resolution and deletion, with actor and timestamp.
- Deletion is soft first, then permanent, so the Controller can evidence to a supervisor that a record existed and when it was removed.
- No special category data is sent to the AI provider in identifiable form. AI prompts carry aggregate figures and the firm's own notes; customer display names and customer references are excluded from every prompt as a locked engineering invariant.
Review reminder emails. The daily review reminder email lists the display names of customers whose reviews are overdue or due soon. Because the email says why it is being sent, those names are disclosed to our email provider (MailerSend) in a context that reveals vulnerability status. MailerSend is in Annex 3 and is reachable from the United States. The job behind that email is scheduled by Inngest, but Inngest is told only which firm has work due: the names are read, and the mail composed, inside our own infrastructure in Ireland. A Controller that would prefer its users not to receive review reminders should tell us, and we will deal with it directly.
5. Personal data breach
We notify the Controller without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, and in any event within 48 hours of becoming aware. Notice goes by email to the firm's account administrators. Forty-eight hours is chosen so that it leaves the Controller a full day of its own 72-hour window under Article 33. It is the deadline for telling the Controller; containing and remedying the breach proceeds alongside it, on its own timetable.
Our notification will describe, to the extent known at the time:
- the nature of the breach, and the categories and approximate number of records and data subjects affected;
- the likely consequences;
- the measures taken or proposed to address it and to mitigate its effects;
- a contact point for further information.
Where we cannot provide all of it at once, we will provide it in phases without further undue delay. We will not make any public statement identifying the Controller in connection with a breach without first consulting the Controller, unless required by law.
Notifying the ICO under Article 33, and affected data subjects under Article 34, is the Controller's decision and the Controller's obligation. Our timescale is designed to leave the Controller enough of its 72 hours to make it.
6. International transfers
Customer Personal Data at rest is held in the EU — Supabase's eu-west-1 region in Ireland. Transfers from the UK to the EEA are covered by the UK's adequacy regulations, so no additional safeguard is required for that flow.
The rest of this section sets out the other flows the Controller will need for its own record of processing activities. Serving the product is an EU flow. Our server-side code runs in Vercel's Dublin region (dub1), pinned in the repository rather than in a dashboard setting. A page showing the Controller's register is read from the database in Ireland and assembled in Ireland before being sent to the browser. Static assets are served from the edge location nearest the browser, which may sit outside the EU; they contain no Customer Personal Data.
These providers are based in, or reachable from, the United States:
- Anthropic, for AI drafting prompts — the standard commercial API in the United States. Prompts carry aggregate figures and the Controller's own notes, never customer names, references or dates of birth. They are handled under Anthropic's standard commercial terms and covered by its published data processing agreement.
- MailerSend, for transactional email — mail is stored in Belgium; MailerSend, Inc. is a US company and uses a US affiliate as its own sub-processor, so the content is accessible from the United States. Covered by the EU standard contractual clauses as modified by the ICO's UK Addendum, already in force through MailerSend's terms.
- Sentry, for error monitoring — reports are stored in Sentry's EU data region in Frankfurt; Functional Software, Inc., which runs Sentry, is a US company, so reports are accessible from the United States. Email addresses, cookies, request bodies and query strings are removed before a report is sent, and reports are not used to carry Customer Personal Data. Covered by Sentry's published data processing agreement.
- Stripe, for payments — a US company with EU infrastructure. It processes the firm's billing details and never Customer Personal Data. Covered by Stripe's published data processing agreement.
- Inngest, for scheduled jobs — hosted in the United States, on AWS us-east-2 and dedicated hardware in Virginia. No Customer Personal Data is transferred to it. The jobs run in Ireland; Inngest is told which firm has work due and nothing about the people that work concerns.
For every provider that receives personal data, we rely on the transfer terms in that provider's own published data processing agreement, which incorporate the EU standard contractual clauses as modified by the ICO's UK Addendum.
7. Liability, term and governing law
This agreement takes effect when the Controller first uses DutyDesk and continues for as long as we process Customer Personal Data. The obligations in clause 3(g) survive termination.
Liability under this agreement is subject to the limitations in section 16 of the terms of service, which apply to the two agreements together rather than once each. Nothing in either agreement limits a liability that cannot lawfully be limited, and nothing in either affects the rights a data subject has directly against a processor under Article 82 of the UK GDPR.
This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.
Annex 1 Details of the processing
| Item | Detail |
|---|---|
| Subject matter | Provision of the DutyDesk Consumer Duty compliance service to the Controller. |
| Duration | For as long as the Controller's account is open — which outlasts the subscription, since cancelling does not close the account — plus the 90-day retention window that runs from closure. See clause 3(g). |
| Nature and purpose | Storage, organisation, retrieval, structuring, export and erasure of the Controller's compliance records; generation of draft narrative text from the Controller's own data; sending of transactional and reminder emails to the Controller's users. |
| Types of personal data | Customer display name (often initials); the firm's own customer reference; year of birth; firm-defined segment; assigned adviser; vulnerability drivers, severity, review dates, notes and adjustments; and references to customers within assessments, board report content and the audit log. |
| Special category data | Data concerning health, and data revealing life events such as bereavement, divorce, redundancy and caring responsibilities, where the Controller records them as vulnerability drivers or in the associated free-text fields. See section 4. |
| Categories of data subject | The Controller's own customers, in particular those the Controller has identified as vulnerable. |
| Data not processed | Full dates of birth, National Insurance numbers, postal addresses, customer email addresses and telephone numbers, bank details, portfolio values, transaction history, suitability reports and advice records. The product provides no field for any of these. |
| Criminal offence data | Not processed. The product provides no field for it, and Controllers should not record it in free text. |
Annex 2 Technical and organisational measures
These measures apply to every firm's data in DutyDesk and can be evidenced in the codebase or in the platform configuration.
| Area | Measure |
|---|---|
| Tenant isolation | Row-level security policies on every tenant-scoped table restrict reads and writes to a single firm. Isolation is enforced by the database rather than by application code, and is covered by an automated test suite asserting that one firm cannot read another's rows. |
| Access control | Four roles — administrator, compliance, adviser, read-only — with least-privilege defaults. Advisers see only records assigned to them. Role changes take effect immediately rather than at token expiry, and a database trigger prevents a user from altering their own role, firm or identity. |
| Authentication | Managed by Supabase Auth. Passwords are stored hashed and are never visible to us. Minimum password length of 12 characters. Where a user has enrolled a multi-factor authentication factor, it is enforced server-side on every authenticated request, not only at the sign-in screen. |
| Encryption in transit | HTTPS throughout, with X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy response headers set at the edge. |
| Encryption at rest | The database is managed Postgres on Supabase and is encrypted at rest by that platform, and its daily backups are encrypted in the same way (see Resilience and backup, below). Access to the data is governed by the controls above. |
| Auditability | Every create, update, sign-off and delete is written to an append-only audit log with actor, entity, timestamp and a field-level diff. The Controller can read and export its own audit log. |
| Data minimisation | The customer schema is deliberately minimal and changing it requires an architecture decision record to be reopened. See Annex 1. |
| Segregation of duties | Fair value assessments and board reports require a drafter and a different approver, enforced by a validated database constraint as well as in the application. A single-user firm can opt into a recorded single-signature exception. |
| Abuse and cost controls | Rate limiting on sign-in, sign-up and AI generation; per-tier and per-user AI limits; spend alerting and an automatic cut-off on unusual AI spend. |
| Resilience and backup | Daily encrypted backups of the production database, retained on a rolling seven-day basis. Backups are held in the EU alongside the database, under the same access controls, and Customer Personal Data can be restored from any of the last seven daily backups. The Controller's own export — CSV, PDF, Word, and a complete archive from Settings, available at any time and not on request — sits alongside this in the Controller's business continuity arrangements. |
| Monitoring | Server-side logging at our hosting provider, and error monitoring through Sentry in its EU data region (Frankfurt): email addresses, cookies, request bodies and query strings are removed before an error report is sent, so a fault is found and fixed without the report carrying Customer Personal Data. Product analytics and session replay are PostHog, on consent only, with all typed input masked and replay disabled outright on the dashboard, the register, customer records, board reports and assessments — see our privacy policy. PostHog receives firm-user analytics, not Customer Personal Data. |
| Secure development | TypeScript in strict mode, validated environment configuration, and a continuous integration pipeline running type checking, linting and an automated test suite — including row-level security isolation tests — on every push. |
| Personnel | Access to the production database and the service-role credentials is restricted to a single named individual, the director of AppstackX Ltd. No contractor or third-party administrator holds access. See clause 3(b). |
Annex 3 Authorised sub-processors
This list reflects the providers actually wired into the application as at the date at the top of this page.
| Sub-processor | Purpose | Customer Personal Data it processes | Region |
|---|---|---|---|
| Supabase | Primary database, authentication | All Customer Personal Data | eu-west-1, Ireland (EU) |
| Vercel | Application hosting and delivery | Data in transit, and whatever a page renders while it is being rendered. No persistent store of Customer Personal Data. | Ireland — Dublin (dub1) for server-rendered pages and API routes; static assets, which contain no Customer Personal Data, from a global edge network |
| Anthropic | AI drafting of fair value and board report narrative | Prompt content only — aggregate figures and the Controller's own notes. No customer names, references or dates of birth. | United States |
| MailerSend | Transactional and reminder email | Recipient name and address, and email body. The vulnerable review reminder body contains customer display names and review dates in a context revealing vulnerability status. | Stored in Belgium (EU); MailerSend, Inc. is a US company using a US affiliate as its own sub-processor, so the content is accessible from the United States |
| Inngest | Scheduled background jobs — review reminders, AI spend controls | Firm identifiers and counts only — no customer names and no record contents | United States — AWS us-east-2 and dedicated hardware in Virginia. No Customer Personal Data is transferred to it. |
| Sentry | Error monitoring | Technical details of an error, record identifiers, and firm and user identifiers. Email addresses, cookies, request bodies and query strings are removed before a report is sent; reports are not used to carry customer names or record contents. | EU — Frankfurt, Germany (Sentry's EU data region); Functional Software, Inc. is a US company, so reports are accessible from the United States |
Stripe processes subscription payments, invoices and the billing portal. It receives the firm's billing name, email, address and subscription record; card details go directly to Stripe and never reach us. It is not a sub-processor of Customer Personal Data — no customer record is sent to it — and it is listed in our privacy policy with the rest of the firm-level processing.
PostHog is used for product analytics and session replay on the firm's own users, on EU Cloud and on consent only, and is also listed in the privacy policy. It is not a sub-processor of Customer Personal Data: it receives firm user identity and page views, replay masks everything a user types, and replay is switched off entirely on the dashboard, the register, customer records, board reports and assessments.