Legal coverage
Every applicable requirement is mapped to a controlled policy, plan, register or evidence pack.
Article 16 · Simplified ICT risk framework
Build day-one resilience.
Build day-one resilience.
Without policy sprawl.
A practical implementation map for a small and non-interconnected investment firm preparing for authorisation in Iceland.
14controlled
deliverables
deliverables
Governance
Controls
Evidence
Testing
Choose your starting point
What are you trying to do?
Each route opens the relevant part of the guide with the useful view or filters already selected.
The operating principle
Four layers—not one misleading percentage
A policy can be approved while the underlying control is absent. Readiness must be assessed across separate layers.
Document readiness
The relevant D01–D14 deliverables are drafted, reviewed and appropriately approved.
Control implementation
The operational measures described on paper exist in the firm’s actual ICT environment.
Evidence & testing
Current evidence shows the controls operate and resilience tests demonstrate they work.
Critical distinction
Small and non-interconnected is not the same as microenterprise.
Article 12 IFR determines whether the investment firm falls within the Article 16 simplified framework. DORA’s separate microenterprise definition may affect particular requirements, but does not decide Article 16 status.
1
Confirm permissionsInvestment services, client assets, execution and operational model.
2
Test Article 12 IFRDocument every quantitative and qualitative SNI condition.
3
Test microenterprise statusFewer than 10 employees and relevant EUR 2m financial threshold.
4
Record proportionalityConnect each simplification to scale, risk and complexity.
Session-only scoping guide
Build an initial DORA scope
Answer six questions to identify the likely framework, conditional issues, priority deliverables and fact-finding needed. Nothing is saved.
Informational onlyNo client record is created
Requirement explorer
Compliance matrix
Corrected legal mapping, supervisory position and proportionate implementation destination.
Use this view for normal scoping.The 42 source-list items and nine add-ons remain the default. Open legal detail when you need paragraph-level traceability.
Click any row for legal basis, rationale and implementation detail.
| Source | Requirement | Correct legal reference | Pre-licence | Primary deliverable |
|---|
| ID | Legal requirement | Applicability | Readiness gate | Primary location |
|---|
Controlled architecture
Fourteen actual deliverables
Granular controls, consolidated into a proportionate and filterable implementation package.
One policy ≠ one controlThe framework deliberately avoids 50 standalone documents.
How the suite works
Architecture and implementation order
Deliverable catalogue
Open any deliverable
Each detail panel includes prerequisites, required inputs, decisions, validation, templates and what implementation looks like beyond approval.
Working documentation suite
Template library
Editable policies, procedures, registers, workpapers and training materials—organised around the same D01–D14 architecture used throughout the matrix.
29 controlled filesOne integrated suite, including the corrected D06 incident pack.
v1.1 correctionD06 annex remediation complete
Annexes A and B are mandatory operational tools; Annex C is conditional, Annex D is contextual and Annex E is optional. The legal-detail explorer, master matrix, D14 register and downloads now use the corrected references.
Read release notes ↗!
A template is not evidence of implementation. Yellow or bracketed fields require completion. Actual systems, providers, controls, tests, incidents, audit results and evidence must be supplied and independently validated where appropriate.
Start here
Architecture & implementation tools
Use these master files to scope the engagement, collect facts and prove complete requirements coverage.
D01–D14
Deliverable template packs
Each pack explains what the file does, what it contains and what must still be populated, implemented or validated.
Individual downloads stay grouped under their controlling deliverable.
Licence readiness
Sequence evidence, not just drafting
The pre-licence gate should demonstrate a credible operating model—not a stack of aspirational policies.
Interpret “Pre-Licence: No” carefully.
If it means “not normally submitted with the application,” it may be reasonable. If it means the control does not need to exist until after authorisation, that is unsafe for core operating-model controls.
Engagement design
Implementation playbook
A legal-led, technically validated workplan for a greenfield investment firm.
Responsibility map
Who must do what
Management retains responsibility. Legal can own the mapping and narrative; technical controls require validation by the firm’s IT or security specialist.
Map & structure
Applicability, compliance matrix, governance, contracts, licensing narrative and decision records.
Own & approve
Strategy, risk tolerance, roles, resources, major risk acceptance and oversight.
Operate & evidence
Registers, monitoring, reporting, vendor oversight, training and action closure.
Implement & validate
Configuration, identity, logging, patching, backup, restoration, testing and technical evidence.
Likely critical path
Start provider contracts early.
Standard SaaS terms may not be negotiable. The file should distinguish protection obtained, standard assurance relied upon and risk formally accepted.
Service scope & locationsAvailability, integrity & securityIncident support & cooperationAudit, access & inspection rightsSubcontracting & material changeTermination, return & exit support
Authority map
Legal sources
The corrected baseline for the simplified framework and adjacent obligations.
Legal baseline reviewed23 July 2026
Legal mapping principle
For Article 16 firms, Articles 5–15 DORA and Title II (Articles 2–27) of Delegated Regulation 2024/1774 do not supply the simplified ICT risk-management framework. Incident management, testing and ICT third-party obligations continue separately under DORA.