DORA for Crowdfunding Platforms: Proportionality in Practice for Europe's Newest Financial Entities
Europe's Newest Regulated Entities Meet Europe's Newest Resilience Regulation
The European Crowdfunding Service Providers Regulation (ECSPR) created a harmonized framework for crowdfunding platforms across the EU, effective from November 2021. Platforms licensed under ECSPR are financial entities — and financial entities are in DORA's scope. Article 2(1)(p) explicitly includes "crowdfunding service providers."
For a 15-person crowdfunding platform operating from a single office with a fully cloud-hosted technology stack, DORA's 64 articles, extensive RTS/ITS, and references to threat-led penetration testing can seem designed for a different world — the world of systemically important banks with thousands of employees and dedicated ICT risk teams.
The response to this apparent mismatch is Article 4: proportionality. DORA explicitly states that financial entities shall implement its requirements "taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations." This is not a loophole — it is a design principle. DORA's drafters intended for the regulation to scale from CCPs processing trillions in transactions to crowdfunding platforms raising funding for small businesses.
But proportionality requires interpretation. And for crowdfunding platforms, that interpretation determines whether DORA compliance is a manageable governance exercise or an impossible burden.
What DORA Proportionality Means for Crowdfunding
Proportionality does not mean exemption. Every DORA obligation applies to crowdfunding platforms — but the depth, complexity, and formality of implementation may be reduced. The test is whether the implementation is "proportionate to" the platform's risk profile.
The key distinction:
| DORA element | Full implementation (large bank) | Proportionate implementation (crowdfunding) |
|---|---|---|
| ICT risk framework | Dedicated CISO, formal risk committee, multi-tier governance | CTO/founder with documented risk responsibilities, annual board review |
| ICT asset register | Enterprise CMDB with thousands of assets, automated discovery | Structured spreadsheet or lightweight tool covering all systems |
| Risk assessment | Continuous, formal methodology, dedicated risk function | Annual assessment with ad hoc updates for material changes |
| Incident reporting | Automated pipeline, 24/7 SOC, structured multi-phase reporting | Defined escalation process, template-based reporting to NCA |
| Resilience testing | Annual programme with TLPT, scenario testing, red team | Annual penetration test, basic DR testing, vulnerability scanning |
| Third-party management | Dedicated VMO, hundreds of contracts, concentration analysis | Documented provider inventory, key contracts reviewed, basic concentration assessment |
| Board reporting | Quarterly structured report, KPI dashboard, trend analysis | Annual board presentation covering ICT risk posture |
Minimum Viable DORA Compliance for Crowdfunding
Pillar I: ICT Risk Management (Art. 5-16)
What you must have:
- Documented ICT risk management responsibilities. Who in the organization is accountable for ICT risk? For most crowdfunding platforms, this is the CTO, co-founder, or a senior engineer. The role must be documented and the management body (board or equivalent) must have approved this allocation.
- ICT asset register. A complete list of all ICT systems: cloud infrastructure (AWS/Azure/GCP resources), SaaS applications, databases, APIs, payment processing integrations, investor portals, project issuer tools. For a cloud-native platform, this may be 20-50 items.
- Annual risk assessment. Identify the ICT risks specific to your platform: data breach, platform outage, payment processing failure, unauthorized access to investor data, third-party service disruption. Score each by likelihood and impact. Document mitigating controls.
- Data classification. Classify your data: investor PII (CONFIDENTIAL), transaction records (CONFIDENTIAL), project information (INTERNAL), marketing content (PUBLIC). Ensure protection controls match classification.
- Backup and recovery. Documented backup policy with tested restoration. For a cloud-native platform, this means database snapshot policies, cross-region replication, and at least annual restoration testing.
| Proportionate Art. 5-16 deliverable | Format | Update frequency |
|---|---|---|
| ICT risk management policy | 5-10 page document, board-approved | Annual review |
| ICT asset register | Structured spreadsheet or lightweight CMDB | On change + annual review |
| Risk assessment | Risk register with likelihood x impact scoring | Annual + ad hoc for material changes |
| Data classification scheme | 1-2 page policy with classification per data category | Annual review |
| Backup policy + test record | Policy document + test execution evidence | Annual test minimum |
Pillar II: Incident Management (Art. 17-23)
What you must have:
- Incident response procedure. A documented procedure for detecting, classifying, responding to, and reporting ICT incidents. For a small platform, this can be a runbook rather than a complex workflow.
- Classification criteria. How do you determine whether an incident is major? Apply Art. 18 criteria proportionately: >10% of your users affected, platform unavailable for >2 hours during business hours, any data breach, any payment processing failure.
- NCA reporting capability. Know your NCA, know their reporting channel, know the reporting format. Have a pre-populated template ready. The 4-hour clock is the same for crowdfunding platforms as for banks — proportionality does not extend the reporting timeline.
Pillar III: Resilience Testing (Art. 24-27)
What you must have:
- Annual penetration test. Conducted by a qualified external tester. Scope: the platform's public-facing applications, APIs, and authentication mechanisms.
- Basic DR test. Annual test of your ability to restore the platform from backup. Measure actual restoration time against your RTO target.
- Vulnerability management. Regular vulnerability scanning (at least quarterly) with documented remediation of critical and high findings.
TLPT (Art. 26-27) is unlikely to be mandated for crowdfunding platforms — the designation criteria focus on systemic importance. But basic penetration testing and DR testing are within the proportionate scope.
Pillar IV: Third-Party Risk (Art. 28-30)
What you must have:
- Provider inventory. A list of all ICT service providers: cloud hosting, payment processing, KYC/AML service, email, authentication, monitoring. For each: what service they provide, whether it supports a critical function, and the contract reference.
- Critical provider assessment. For providers supporting critical functions (cloud hosting, payment processing, investor data storage), review the contract against Art. 30 provisions: audit rights, incident notification, data location, exit strategy.
- Basic concentration assessment. If your entire platform runs on a single cloud provider, document this concentration, assess the risk, and document your contingency arrangement (even if it is "we accept this risk because migration would be disproportionately costly").
Pillar V: Information Sharing (Art. 45)
For crowdfunding platforms, Art. 45 information sharing is largely aspirational. Participation in threat intelligence sharing arrangements is encouraged but unlikely to be a supervisory focus for small entities. The proportionate response is awareness of available sharing mechanisms without mandatory participation.
Common Mistakes
Over-engineering. A crowdfunding platform that hires a GRC consultant to build a 200-page ICT risk management framework with 50 policies has over-invested relative to its risk profile. The framework should be proportionate — comprehensive in coverage but lean in documentation.
Ignoring DORA entirely. "We're too small for this" is not a defense. ECSPR-licensed entities are in DORA's scope. Non-compliance creates regulatory risk, and your NCA will eventually ask.
Treating cloud hosting as "not my problem." Running on AWS does not transfer your DORA obligations to Amazon. You are responsible for your ICT risk management, even for hosted services. The cloud provider is a third party under Art. 28.
Use the DORA readiness assessment to evaluate your platform's compliance posture, consult the proportionality guide for additional context, and review the glossary for regulatory definitions. The EBA and ESMA guidance on proportionality provides the supervisory framework for calibrating your implementation.
Conclusion
DORA applies to crowdfunding platforms, but it applies proportionately. The minimum viable compliance framework is achievable for a 15-person platform: a documented risk framework, a structured asset register, annual testing, basic incident response capability, and a third-party provider inventory with critical provider assessment. The effort is measured in weeks, not years. The cost is measured in thousands, not millions. And the outcome is not just regulatory compliance — it is a platform that is genuinely more resilient, which is what investors and project issuers deserve.
Resume en francais
Les plateformes de crowdfunding agreees sous l'ECSPR sont dans le perimetre de DORA (Art. 2(1)(p)). Cet article fournit un cadre de conformite DORA pratique et proportionne pour ces entites, reconnaissant que la plupart sont de petites plateformes technologiques avec des equipes reduites. Pour chaque pilier, l'article definit les livrables minimum viables : cadre de gestion des risques TIC (politique de 5-10 pages, registre d'actifs en tableur, evaluation annuelle des risques), gestion des incidents (procedure documentee, criteres de classification, capacite de reporting NCA), tests de resilience (pentest annuel, test DR annuel, scan de vulnerabilites trimestriel), risque tiers (inventaire des fournisseurs, evaluation des fournisseurs critiques, evaluation basique de la concentration). La proportionnalite ne signifie pas exemption — chaque obligation DORA s'applique, mais la profondeur, la complexite et la formalite de la mise en oeuvre sont reduites proportionnellement a la taille, au profil de risque et a la complexite de l'entite.