{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-05T09:57:18.570Z"},"content":[{"type":"documentation","id":"0cb150b9-2c2f-4fd3-8362-712ec3c143c4","slug":"dora-ict-third-party-research-tools","title":"DORA and Research Tools: ICT Third-Party Risk, Registers of Information and Vendor Due Diligence for Financial Firms","url":"https://www.koji.so/docs/dora-ict-third-party-research-tools","summary":"Under DORA (Regulation (EU) 2022/2554, applying since 17 January 2025), a customer research SaaS platform is an ICT third-party service provider. It must appear in the financial entity's register of information under Article 28(3) — with legal entity and LEI, service description, functions supported, criticality classification, data locations, subcontracting chain and concentration indicators — and its contract must carry the Article 30(2) baseline clauses. The heavier Article 30(3) regime (quantitative SLAs, unrestricted audit and on-site inspection rights, TLPT cooperation, documented exit strategies, prior authorisation for material subcontracting) applies only where the service supports a critical or important function. Research tools usually do not, because disruption delays insight rather than impairing a regulated service; the exceptions are where research output is the evidence base for a regulatory obligation such as Consumer Duty outcome testing, or where the platform holds the only copy of customer records. UK firms face the parallel SYSC 8, operational resilience (31 March 2025), critical third parties (1 January 2025) and material third-party reporting (18 March 2027) regimes.","content":"**Short answer: under DORA, a customer research platform is an ICT third-party service provider, so it belongs in your register of information and its contract needs the Article 30(2) baseline clauses. The heavy Article 30(3) regime — audit rights, TLPT cooperation, documented exit plans, prior authorisation for subcontracting — only applies if the tool supports a *critical or important function*, and for almost every research platform it does not. Getting that classification recorded, with reasoning, is the piece of work that actually matters.**\n\nEvery insights team at a bank, insurer, payments firm or investment platform has now had the same conversation. Procurement forwards a spreadsheet. Somewhere in it is a cell asking whether the research tool supports a critical or important function, and nobody in the research team knows what that means or what saying \"yes\" costs. Say yes carelessly and you have committed your vendor to threat-led penetration testing cooperation and your firm to an exit plan for a survey tool. Say no without documenting why, and your next supervisory review finds an unjustified classification.\n\nThis guide is written for the researcher or research-ops lead who has been handed that spreadsheet.\n\n*This is practitioner guidance, not legal or compliance advice. Your firm's compliance function owns the final classification.*\n\n## What DORA is, and why a research tool is in scope\n\nThe Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since **17 January 2025**. It creates a single EU framework for ICT risk across banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and around fifteen other categories of financial entity — plus their ICT suppliers.\n\nThe scope trap is that DORA does not regulate \"outsourcing\" in the old, narrow sense. It regulates **ICT services**, defined broadly as digital and data services provided on an ongoing basis. A SaaS platform that hosts customer conversations, stores transcripts and produces reports is squarely an ICT service. There is no de minimis exemption for small contracts, and no exemption because the tool is \"just for research\".\n\nSo the question is never *whether* your research platform is in scope. It is *at what tier*.\n\n## The register of information\n\nArticle 28(3) requires every financial entity to maintain a **register of information** covering all contractual arrangements for the use of ICT services, at entity, sub-consolidated and consolidated level. Registers are reported to competent authorities on a recurring basis — the first full cycle ran in April 2025 against a 31 March 2025 reference date, with national authorities passing consolidated registers to the European Supervisory Authorities by the end of that month.\n\nFor each arrangement, expect to record:\n\n| Field | What research teams usually get wrong |\n|---|---|\n| Provider legal entity and LEI | The contracting entity is often not the brand name on the invoice |\n| Description of the ICT service | Be specific: \"AI-moderated customer interviews and analysis\", not \"research\" |\n| Functions supported | Map to your own function inventory, not the vendor's feature list |\n| Criticality classification | The field that drives everything else — see below |\n| Data processing and storage locations | Including sub-processor locations, and any relocation conditions |\n| Subcontracting chain | Model providers, hosting, transcription and analytics vendors count |\n| Start date, notice period, termination conditions | Auto-renew clauses need to be surfaced here |\n| Concentration indicators | Whether the same provider or hosting region already carries other services |\n\nThe register is a supervisory artefact, not an internal wiki. Inconsistent entity naming across rows is one of the most commonly flagged defects, so agree the provider's legal name and identifiers once and reuse them.\n\n## The classification that decides your workload\n\nDORA's Article 30 has two tiers.\n\n**Article 30(2) — baseline, applies to every ICT contract.** Clear description of the services and any subcontracted elements; locations of data processing and storage plus conditions for relocation; provisions on availability, integrity and security of data; assistance during ICT incidents; cooperation with competent and resolution authorities; termination rights and notice periods; and provider participation in your security awareness and resilience training.\n\n**Article 30(3) — enhanced, applies only where the service supports a critical or important function.** On top of the baseline: full quantitative and qualitative service levels; obligations to report material developments affecting the service; implementation and testing of business contingency plans; participation in your threat-led penetration testing where the provider's systems are in scope; unrestricted audit and inspection rights for you, your auditors and your competent authority, including on-site access; documented **exit strategies** with data portability and continued service through a transition; and prior authorisation or notification for material subcontracting.\n\nArticle 29 adds **concentration risk** analysis, and Article 28(8) requires exit strategies for critical or important arrangements specifically. Article 28(4) requires pre-contractual due diligence before you sign.\n\nNow apply it. A \"critical or important function\" is one whose disruption would materially impair your financial performance, the soundness or continuity of your services and activities, or your compliance with authorisation conditions.\n\n| Research use case | Likely classification | Reasoning to record |\n|---|---|---|\n| Quarterly customer satisfaction and brand studies | Not critical or important | Disruption delays insight; it does not impair a regulated service |\n| Product discovery interviews for a roadmap | Not critical or important | No customer-facing service depends on availability |\n| Consumer Duty outcome-testing evidence on a fixed regulatory cycle | **Arguable — escalate** | Disruption could impair compliance with regulatory obligations if it is your only evidence source |\n| Complaints-driven vulnerability research feeding a control | **Arguable — escalate** | If a control depends on the output, the function inherits the criticality |\n| Research platform holding the only copy of customer-identifying records | **Treat as important** | Data loss, not availability, is the impairment route |\n\nTwo lessons fall out of that table. First, a research tool is usually *not* critical or important — and writing down why, in one paragraph, is the whole deliverable. Second, the classification is a property of the **function**, not the vendor: the same platform can be non-critical for discovery work and important when it becomes the evidence base for a regulatory obligation. If you use research to evidence [FCA Consumer Duty outcomes](/docs/consumer-duty-customer-research) or [vulnerable customer treatment](/docs/vulnerable-customer-research), say so explicitly in the classification rather than letting procurement guess.\n\n## The UK is a parallel, not a copy\n\nUK firms do not fall under DORA unless they have EU entities, but the direction of travel is the same:\n\n- **SYSC 8** governs outsourcing, with notification and reporting duties for critical, important or material outsourcing under SYSC 8.1.12 and SYSC 13.9.2.\n- The **operational resilience** rules required firms to be able to remain within impact tolerances for important business services by **31 March 2025**.\n- The **critical third parties (CTP) regime** — set out in FCA PS24/16 and Bank of England PS16/24 — took effect on **1 January 2025**, letting HM Treasury designate systemically important suppliers and giving the regulators rule-making and enforcement powers over them.\n- New **material third-party reporting requirements** go live on **18 March 2027**, with Principle 11 obligations applying in the meantime.\n\nFor a research platform, the practical UK answer usually mirrors the EU one: not material outsourcing, but documented as such, with the same due diligence file behind it. Run one assessment, map it to both regimes.\n\n## What to ask a research vendor\n\nThe questions that actually distinguish a defensible vendor from a marketing deck:\n\n1. **Which legal entity contracts, and where is it established?** You need this for the register anyway.\n2. **Where is data processed and stored, and what triggers a relocation?** Ask for the sub-processor list, not a region name.\n3. **Which model providers are in the chain, and are prompts or transcripts used for training?** For an AI research platform this is the single highest-value question, and the answer should be an unambiguous no.\n4. **What are the notice periods and what does exit look like?** Even for a non-critical service, you should be able to leave with your data in an open format.\n5. **What certifications are held, and what does the evidence pack contain?** See [Enterprise Security for AI Customer Research Platforms](/docs/enterprise-security-ai-research-platforms) for the SOC 2, SSO and vendor-review baseline, and [AI Governance for Customer Research](/docs/ai-governance-frameworks-research) for ISO 42001 and the NIST AI RMF questions procurement now adds.\n6. **What does the DPA say about sub-processors, audit rights and transfers?** [Reviewing a Research Vendor DPA](/docs/research-vendor-dpa-review) walks the Article 28 clauses line by line.\n7. **Incident notification: what timeline, through what channel, to whom?** DORA's own incident reporting clock starts with *your* awareness, so a vendor that notifies slowly creates a regulatory problem for you, not for them.\n8. **Concentration:** does this vendor sit on the same hyperscaler and region as your core banking or policy administration platform? If yes, note it in the register even when the service is minor.\n\nA note on designation: the ESAs can designate a provider as a **critical ICT third-party provider (CTPP)**, bringing it under direct EU oversight with periodic penalty payments of up to 1% of average daily worldwide turnover for continued non-compliance. That regime is aimed at hyperscalers and core infrastructure, not at research SaaS. Do not let a vendor use \"we are not a designated CTPP\" as evidence of anything — almost nobody is.\n\n## How Koji fits a regulated firm's file\n\nKoji is designed to be an easy row in your register rather than a difficult one.\n\n- **A narrow, well-bounded service.** Koji runs AI-moderated customer interviews and produces analysis and reports. It does not sit in a payment path, a customer servicing journey, or a regulated decisioning process — which is exactly the reasoning that supports a \"not critical or important\" classification.\n- **Clear data boundaries.** Research data stays research data: transcripts and recordings are held for your studies, and are not used to train third-party models. Bring Your Own Key is available where firms want model calls to run through their own provider account — see [Bring Your Own Key](/docs/bring-your-own-key).\n- **Portable output.** Studies, transcripts and reports export through the API, so an exit plan is a real plan rather than a promise. See [Building with AI: the Koji API](/docs/building-with-ai).\n- **An audit trail per participant.** Consent, timestamps, quality scores and structured answers are captured as data, which is what turns a research programme into evidence a supervisor can follow.\n- **Structured questions for evidence-grade output.** Six types — open_ended, scale, single_choice, multiple_choice, ranking and yes_no — mean a Consumer Duty or vulnerability study produces countable, comparable numbers alongside verbatim depth, instead of a folder of anecdotes. See [Structured Questions Guide](/docs/structured-questions-guide).\n\nThere is a resilience argument for AI-moderated research too, and it is not the obvious one. Traditional research in a regulated firm depends on a chain of humans: a recruiter, a moderator, a transcriptionist, an analyst. Each is a single point of failure with a diary. Koji's AI interviewer runs the same protocol at 2am on a bank holiday, and a study that would take six weeks of scheduled sessions completes in days — which materially reduces the chance that a regulatory deadline depends on one person's availability.\n\n## Frequently asked questions\n\n**Is a customer research platform in scope for DORA?**\nYes. DORA regulates ICT services broadly, not just traditional outsourcing, and a SaaS platform that stores and processes customer conversations is an ICT service. It belongs in your register of information and needs Article 30(2) contract clauses regardless of size or spend.\n\n**Does a research tool support a critical or important function?**\nUsually not. The test is whether disruption would materially impair your financial performance, the continuity of your regulated services, or your compliance with authorisation conditions. Discovery and satisfaction research fails that test. The exception is where research output is the evidence base for a regulatory obligation, such as Consumer Duty outcome testing, or where the platform holds the only copy of customer records.\n\n**What do we have to put in the register of information for a research vendor?**\nThe contracting legal entity and identifiers, a specific description of the ICT service, the functions it supports, the criticality classification, data processing and storage locations, the subcontracting chain including model and hosting providers, contract dates and termination conditions, and concentration indicators.\n\n**Do we need an exit strategy for a research platform?**\nDORA requires documented exit strategies for arrangements supporting critical or important functions. For a non-critical research tool it is not mandatory, but a simple export-and-migrate plan is worth having anyway — and the ability to export studies, transcripts and reports through an API is what makes that plan credible.\n\n**How does DORA interact with GDPR for research data?**\nThey cover different things and both apply. DORA governs operational resilience and ICT third-party risk; GDPR governs personal data. A single vendor assessment can serve both if it captures processing locations, sub-processors, retention and transfer mechanisms — which is why the DPA review and the register entry should be produced together.\n\n**Do UK firms need to do any of this?**\nUK firms are outside DORA unless they have EU entities, but face a parallel set of obligations: SYSC 8 outsourcing rules with notification duties, operational resilience impact tolerances from 31 March 2025, the critical third parties regime effective 1 January 2025, and material third-party reporting from 18 March 2027. One assessment mapped to both regimes is the efficient approach.\n\n## Related Resources\n\n- [Structured Questions Guide](/docs/structured-questions-guide) — the six question types that turn research into countable evidence\n- [Enterprise Security for AI Customer Research Platforms](/docs/enterprise-security-ai-research-platforms) — SOC 2, SSO and the vendor review pack\n- [Reviewing a Research Vendor DPA](/docs/research-vendor-dpa-review) — Article 28 clauses, sub-processors and transfer annexes\n- [AI Governance for Customer Research](/docs/ai-governance-frameworks-research) — ISO 42001, the NIST AI RMF, and what procurement actually asks\n- [FCA Consumer Duty Customer Research](/docs/consumer-duty-customer-research) — evidencing consumer understanding and fair value\n- [AI Customer Research for Banking and Financial Services](/docs/ai-research-for-banking) — the use cases regulated firms run most\n- [Vulnerable Customer Research](/docs/vulnerable-customer-research) — evidencing good outcomes under FCA rules\n\n*Need a research platform your second line will sign off? [Start free with 10 credits](https://www.koji.so) and put a real study through your own review process.*","category":"Research Operations","lastModified":"2026-08-03T03:19:37.914078+00:00","metaTitle":"DORA and Research Tools: ICT Third-Party Risk & Registers of Information (2026)","metaDescription":"Your research platform is an ICT third-party service provider under DORA. What goes in the register of information, which Article 30 clauses apply, and why the criticality classification is the real work.","keywords":["dora ict third party research vendor","register of information","dora article 30 contract clauses","critical or important function","operational resilience research tool","financial services vendor due diligence research","sysc 8 outsourcing"],"aiSummary":"Under DORA (Regulation (EU) 2022/2554, applying since 17 January 2025), a customer research SaaS platform is an ICT third-party service provider. It must appear in the financial entity's register of information under Article 28(3) — with legal entity and LEI, service description, functions supported, criticality classification, data locations, subcontracting chain and concentration indicators — and its contract must carry the Article 30(2) baseline clauses. The heavier Article 30(3) regime (quantitative SLAs, unrestricted audit and on-site inspection rights, TLPT cooperation, documented exit strategies, prior authorisation for material subcontracting) applies only where the service supports a critical or important function. Research tools usually do not, because disruption delays insight rather than impairing a regulated service; the exceptions are where research output is the evidence base for a regulatory obligation such as Consumer Duty outcome testing, or where the platform holds the only copy of customer records. UK firms face the parallel SYSC 8, operational resilience (31 March 2025), critical third parties (1 January 2025) and material third-party reporting (18 March 2027) regimes.","aiPrerequisites":["Your firm's inventory of important business services or critical functions","Access to the research vendor's DPA, sub-processor list and security pack","A working relationship with procurement or second-line risk"],"aiLearningOutcomes":["Decide whether a research platform supports a critical or important function, and document the reasoning","Populate a DORA register of information entry for a research vendor","Distinguish Article 30(2) baseline clauses from Article 30(3) enhanced clauses","Run eight due-diligence questions that actually differentiate research vendors","Map one assessment to both the EU DORA and UK SYSC 8 / operational resilience regimes"],"aiDifficulty":"advanced","aiEstimatedTime":"13 min"}],"pagination":{"total":1,"returned":1,"offset":0}}