Data Processing Agreement
Effective
This Data Processing Agreement ("DPA") forms part of the agreement between Indacas Ltd ("Indacas", the "Processor") and the Researcher or their institution (the "Customer", the "Controller") under the Terms of Service or a separate written agreement (together, the "Agreement"). It applies whenever Indacas processes personal data on the Customer's behalf and is intended to satisfy Article 28(3) UK GDPR (and, where EU GDPR applies to the Customer, Article 28(3) EU GDPR).
Capitalised terms not defined here have the meanings in the Terms of Service and Privacy Policy. "Data Protection Laws" means UK GDPR, the Data Protection Act 2018, and where applicable EU GDPR.
1. Roles and scope
1.1 For Research Data — study definitions, survey questions and responses, participant records (including researcher-defined fields), in-product consent records, and study audit logs — the Customer is the controller and Indacas is the processor.
1.2 For Account Data and platform telemetry, Indacas is an independent controller under its Privacy Policy. That processing is outside this DPA.
1.3 If the Customer is itself a processor for another controller (e.g. a university acting for a sponsor), Indacas acts as its subprocessor and the Customer warrants its controller has authorised this DPA.
2. Details of processing
The subject matter, duration, nature and purpose of the processing, the categories of data subject and personal data, and the retention period are set out in Annex I. The technical and organisational measures are set out in Annex II. The authorised subprocessors are set out in Annex III.
3. Customer (Controller) obligations
The Customer warrants and undertakes that it:
- (a) has a lawful basis under Article 6, and where relevant an Article 9 condition, for all Research Data it instructs Indacas to process;
- (b) has obtained any required ethics/IRB/REC approvals and provided Participants with a compliant privacy notice;
- (c) will issue only lawful, documented instructions (use of Platform features constitutes documented instructions; anything beyond requires written agreement);
- (d) will conduct DPIAs where required and is responsible for responding to data subjects as controller;
- (e) will not instruct Indacas to process data of children without the safeguards Data Protection Laws require.
4. Indacas (Processor) obligations
Indacas will:
- (a) process Research Data only on the Customer's documented instructions, including for international transfers, unless required to do otherwise by law that applies to Indacas — in which case Indacas will inform the Customer before processing unless that law prohibits it;
- (b) inform the Customer immediately if, in its opinion, an instruction infringes Data Protection Laws;
- (c) ensure persons authorised to process Research Data are bound by confidentiality obligations;
- (d) implement the technical and organisational measures in Annex II and keep them under review;
- (e) assist the Customer, taking into account the nature of processing, with responses to data subject rights requests (using Platform export, correction, and deletion features, and manual assistance where needed), and with the Customer's obligations under Articles 32–36 (security, breach notification, DPIAs, prior consultation);
- (f) not use Research Data for its own purposes. In particular, Indacas will not use survey questions, responses, participant records or free-text content to develop or improve its own products, to produce analytics on that content, or to train, fine-tune or evaluate machine-learning models. This does not restrict Indacas's use of service metadata — data about how the Platform itself is used, such as which question types and features are used, completion and drop-off rates, response times, error rates and volumetrics — provided it contains no Research Data content and is not attributed to an identifiable Participant. Indacas is an independent controller for service metadata under Section 1.2. Any use of Research Data content beyond this DPA requires a separate written agreement, and the Customer remains responsible as controller for the lawful basis and participant transparency that such use would depend on;
- (g) maintain records of processing as Article 30(2) requires;
- (h) not respond to a data subject who contacts Indacas directly about Research Data, other than to acknowledge receipt and direct them to the Customer, and will forward the request to the Customer without undue delay;
- (i) where Indacas receives a legally binding request from a public authority for Research Data: notify the Customer without undue delay unless prohibited by law, and where prohibited, use reasonable efforts to obtain a waiver of that prohibition; challenge requests that appear unlawful or overbroad, including by seeking interim measures; and disclose only the minimum data the request compels. Indacas will keep a record of such requests and make it available to the Customer on request to the extent the law permits.
5. Subprocessors
5.1 The Customer gives general written authorisation for Indacas to engage the subprocessors listed in the Subprocessor List.
5.2 Indacas will give the Customer at least 30 days' notice of any intended addition or replacement, by updating the Subprocessor List and notifying the Customer's account administrators by email. The Customer may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Customer may terminate the affected services and receive a pro-rata refund of prepaid fees.
5.2A Where a subprocessor must be replaced urgently to maintain security or service continuity, Indacas may make the change with less notice, and will notify the Customer as soon as reasonably practicable and no later than 5 days after the change. The Customer's objection and termination rights in Section 5.2 then run from that notice.
5.3 Indacas will impose data protection obligations on each subprocessor equivalent to this DPA by written contract, and remains fully liable to the Customer for subprocessors' performance.
5.4 Internal infrastructure operated by Indacas itself (e.g. self-hosted Ory Kratos identity and Grafana/Loki logging) is not a subprocessor.
6. Security
Indacas implements the measures in Annex II, taking into account the state of the art, costs, and the nature, scope, context, and purposes of processing, and the risks — including that Research Data may contain special-category data.
7. Personal data breaches
Indacas will notify the Customer without undue delay, and in any event within 72 hours of becoming aware of a personal data breach affecting Research Data, providing (as it becomes available): the nature of the breach, categories and approximate numbers of data subjects and records, likely consequences, measures taken or proposed, and a contact point. Indacas will reasonably cooperate with the Customer's own notification obligations. Notification is not an admission of fault. Unsuccessful attempts that do not compromise personal data are not breaches.
8. Audits
8.1 Indacas will make available information reasonably necessary to demonstrate compliance with Article 28, including its security schedule, the measures and their status in Annex II, and the current independent assurance reports of its infrastructure provider. Certifications Indacas obtains in its own right will be made available under this Section as they are issued; the current position is set out in Annex II.
8.2 The Customer (or an independent auditor that is not an Indacas competitor) may audit Indacas's compliance with this DPA: no more than once per 12 months (unless required by a supervisory authority or following a breach), on at least 30 days' written notice, during business hours, limited to systems and records relevant to Research Data, under confidentiality, and at the Customer's cost. Indacas may satisfy an audit request with a recent third-party assessment covering the same scope.
9. International transfers
9.1 Research Data is stored in the United Kingdom, in DigitalOcean's London region (LON1). Traffic to the Platform passes through Cloudflare before reaching LON1. Cloudflare Regional Services restricts TLS termination and inspection of that traffic to Cloudflare data centres in the United Kingdom; the data categories involved and the applicable safeguard are set out in the Subprocessor List.
9.2 Indacas will not transfer Research Data outside the UK (or the EEA, where EU GDPR applies) without ensuring a lawful transfer mechanism: a UK adequacy regulation (or EU adequacy decision), the ICO's IDTA, or the EU SCCs with the UK Addendum, together with any required transfer risk assessment and supplementary measures. Current transfer details per subprocessor are in the Subprocessor List.
10. Deletion and return
10.1 During the term, the Customer can export Research Data using Platform export features at any time.
10.2 On termination or expiry of the Agreement, Indacas will make Research Data available for export for 90 days (the "export window"). At the end of the export window Indacas will return all Research Data if the Customer has requested return, and otherwise delete it together with existing copies, unless UK or EU law requires storage of specific data.
10.3 Deletion from live systems will be completed within 30 days of the end of the export window — so no later than 120 days after termination or expiry. Indacas will confirm deletion in writing on request.
10.4 Research Data will persist in encrypted database backups until it ages out of the managed database backup window, which is 7 days (daily full backups with write-ahead logs supporting point-in-time recovery to any point in the previous seven days). Backups are not restored except for disaster recovery, and any restore is followed by re-application of completed deletions. The same applies to erasure requests made during the term: erasing a record removes it from live systems immediately but it remains in backups until they age out.
11. General
- This DPA takes effect when the Agreement does and continues for as long as Indacas processes Research Data. It survives termination of the Agreement until deletion or return under Section 10 is complete.
- This DPA prevails over conflicting terms of the Agreement regarding personal data. Where a transfer mechanism incorporated under Section 9 (the IDTA, or the EU SCCs with the UK Addendum) conflicts with this DPA, that mechanism prevails.
- Liability under this DPA is subject to the limitations in the Agreement, except where Data Protection Laws do not permit limitation.
- This DPA is governed by the law of England and Wales.
- Indacas may update this DPA to reflect changes in law with 30 days' notice; changes that materially reduce protections require the Customer's agreement.
Annex I — Details of processing
A. Parties
The Controller is the Customer identified in the Agreement. The Processor is Indacas Ltd, a company registered in England and Wales (company number 17340475), registered office 71-75 Shelton Street, Covent Garden, London, United Kingdom, WC2H 9JQ.
B. Description of processing
| Item | Description |
|---|---|
| Subject matter | Hosting and processing of Research Data on the Indacas Platform |
| Duration | The term of the Agreement, plus the export/deletion period in Section 10 |
| Nature and purpose | Provision of the Platform: collecting, storing, organising, displaying, analysing, exporting, and deleting Research Data as instructed through the Platform's features |
| Data subjects | Study Participants (including anonymous respondents), and Customer's study team members appearing in audit logs |
| Categories of personal data | As defined by the Customer in its study design: may include identity and contact data, demographic data, free-text responses, researcher-defined record fields, consent records (statement text + acceptance timestamps), audit log entries (user, action, timestamp, IP address) |
| Special categories (Art 9) | May include health data and other special-category data where the Customer's study collects it; the Customer must flag such fields as "sensitive" in-product and is responsible for the Art 9 condition |
| Frequency | Continuous, for the duration of the Agreement |
| Retention period | Research Data is retained until the Customer deletes it, and thereafter for the export and deletion period in Section 10. Indacas does not delete Research Data on its own initiative; retention is the Customer's decision as controller |
| Processing by subprocessors | As set out in Annex III, for the duration of each subprocessor's engagement |
C. Competent supervisory authority
The Information Commissioner's Office (ICO), United Kingdom, where the Customer is established in the United Kingdom. Where the Customer is established in the EEA, the competent authority is that of the Customer's main establishment.
Annex II — Technical and organisational measures
Each measure carries its status. In place means implemented and operating. Platform means provided by our infrastructure provider. Committed means scheduled, with the target date shown.
| Area | Measure | Status |
|---|---|---|
| Encryption in transit | TLS for all connections to the Platform and between Platform components and managed services | In place |
| Encryption at rest | Database and block storage encrypted at rest with LUKS by DigitalOcean Managed Databases. No application-layer or column-level encryption above this | Platform |
| Access control | Role-based access control throughout the Platform (organisation and study roles), enforced per resource for reads, writes and exports; sensitive-marked fields require a further privilege to export; least-privilege access for Indacas staff, with production access restricted to authorised engineers | In place |
| Authentication | Self-hosted Ory Kratos identity service; passwords stored as bcrypt hashes at cost factor 12; mandatory email verification; account enumeration mitigation; 24-hour absolute session lifetime, and the browser application signs the user out after 15 minutes of inactivity; TOTP two-factor authentication with recovery codes | In place |
| Audit logging | Append-only application-level audit logs recording actor, timestamp, target, IP address and user agent for creation, update, deletion, viewing and bulk export of Research Data, written from domain events and retained for the life of the study; viewable and filterable by the Customer in-product. Central request logging is separate and described under Logging and monitoring | In place |
| Sensitive-field handling | Researcher-defined fields can be flagged "sensitive" in-product, which excludes them from bulk export unless the exporting user holds a further privilege | In place |
| Logging and monitoring | Self-hosted Grafana/Loki logging and monitoring on Indacas-controlled infrastructure, with log storage in DigitalOcean object storage in LON1. Operational logs are retained for 90 days and authentication, authorisation and API logs for 12 months. Credentials, session tokens, one-time codes and email addresses are redacted from log lines before they are stored. No third-party analytics on Research Data | In place |
| Network segmentation | Three isolated networks; the API is not reachable from the public-facing network; administrative interfaces bound to loopback only and reachable solely over authenticated remote access | In place |
| Hosting | DigitalOcean, London region (LON1), United Kingdom. Physical and infrastructure security is inherited from DigitalOcean, whose current SOC report is available under Section 8.1 | Platform |
| Backups and resilience | Daily full backups of the managed database with write-ahead logging, supporting point-in-time recovery to any point within the previous 7 days. Backups are encrypted by the managed service and held in the same UK region | Platform |
| Restore testing | Documented restore from backup, performed and evidenced at least annually | Committed — 31 October 2026 |
| Data separation | Logical separation of Customers' Research Data by study and organisation with enforced authorisation checks | In place |
| Rate limiting and bot protection | Request rate limits partitioned by authenticated user or client IP; CAPTCHA on creation of new anonymous survey responses | In place |
| Personnel | Written confidentiality obligations for all staff; right-to-work and reference checks before access is granted; access to production removed on the day a leaver's engagement ends | In place |
| Personnel screening | Baseline screening for staff with access to production systems, to BS 7858: identity, right to work, and employment history | Committed — 30 November 2026 |
| Security training | Annual data security and awareness training for all staff, with a 95% completion threshold | Committed — 31 October 2026 |
| Secrets management | Configuration secrets supplied by environment and excluded from version control; automated secret scanning with push protection enabled on all repositories | In place |
| Vulnerability management | Critical and high-severity patches to operating systems, runtimes and dependencies applied within 14 days of a fix being available; automated dependency scanning on every repository with alerts triaged on a defined cadence | Committed — 30 November 2026 |
| Penetration testing | Independent penetration test of the Platform, repeated at least annually and after significant architectural change. No test has been performed to date | Committed — 31 January 2027 |
| Incident response | Documented incident response procedure supporting the 72-hour notification commitment in Section 7, with defined roles, severity classification and escalation | In place |
Annex III — Authorised subprocessors
The subprocessors authorised under Section 5, together with their purpose, the categories of data they process, their location of processing and the applicable transfer safeguard, are set out in the Subprocessor List, which forms part of this Annex and is maintained at that address.
A change of subprocessor is made by updating that list and triggers the notice and objection rights in Section 5; it does not require the parties to re-execute this DPA.