EU DORA: What Financial Institutions Should Ask Their Document Platform Provider

Regulatory information last checked: November 6, 2026. The evidence model below is implementation guidance; legal duties depend on the service, role and use case.

The EU Digital Operational Resilience Act (DORA) makes ICT third-party risk a continuing governance obligation for EU financial entities. A contract questionnaire at onboarding is not enough. Institutions need evidence that remains usable through architecture review, resilience testing, incidents, material changes, and exit.

Document platforms can support critical or important functions even when they are not the system that makes the financial decision. They may hold credit files, customer correspondence, executed agreements, claims evidence, compliance records, or board materials. If those records are unavailable, corrupted, or inaccessible to the right people, the business function can stop.

The European Banking Authority's DORA overview explains the EU-wide framework and oversight of critical ICT third-party providers. The practical implication for document platform selection is broader: financial entities need to know what service they depend on, who operates each layer, and how resilience will be demonstrated.

DORA Articles 28–30 place ongoing ICT third-party risk responsibility on in-scope financial entities. Assess whether the service supports a critical or important function; that assessment differs from a provider being designated critical under EU oversight. Account ownership does not remove the institution’s duties.

Map the complete service, not only the vendor

A document platform service can include the software supplier, AWS, identity provider, eSignature provider, malware-scanning engine, AI model service, support provider, and customer-operated infrastructure. Treating the platform as one undifferentiated supplier obscures concentration risk and operational responsibility.

Create a service map that identifies:

• the business functions and document types supported;
• production and disaster-recovery regions;
• the operator of each AWS account and service;
• subprocessors and external integration providers;
• identity, encryption, logging, backup, and monitoring responsibilities;
• data flows, including support access and AI processing;
• recovery and exit dependencies.

This map should connect to the institution's ICT asset inventory and register of information. It should be updated when the deployment, region, module, or integration changes.

Evidence to request across the relationship lifecycle

• Stage

  Due diligence

  Evidence

  Architecture, security controls, support model, subprocessors, data locations, and known limitations.

  Question answered

  Is the service suitable for the function and risk level?

• Stage

  Contracting

  Evidence

  Service scope, locations, access rights, incident duties, audit rights, continuity commitments, and termination assistance.

  Question answered

  Are responsibilities and remedies explicit?

• Stage

  Operation

  Evidence

  Availability, security events, changes, vulnerabilities, backup status, and support records.

  Question answered

  Is the control environment performing as expected?

• Stage

  Testing

  Evidence

  Restore tests, failover exercises, access reviews, incident simulations, and remediation tracking.

  Question answered

  Can the service recover under realistic conditions?

• Stage

  Incident

  Evidence

  Timeline, affected services and records, indicators, containment, communications, and corrective action.

  Question answered

  What happened, what is affected, and what happens next?

• Stage

  Exit

  Evidence

  Data export, deletion evidence, transition support, dependency removal, and continuity plan.

  Question answered

  Can the institution leave without disrupting the function?

Separate product risk from operating risk

A software defect and an account misconfiguration are different risks, even when they produce the same outage. The operating model should say who owns patching, monitoring, backups, identity configuration, encryption keys, network controls, recovery tests, and incident decisions.

In a customer-managed FormKiQ deployment, the financial institution controls the AWS account and can integrate the platform into its existing security, logging, key-management, and resilience controls. The edition and agreement define FormKiQ’s software, installation, upgrade and support responsibilities. Request the actual support and evidence schedule; architecture pages do not promise recovery targets, audit access, certifications or incident-response service levels.

In a vendor-managed deployment, FormKiQ operates a segregated AWS account on the customer's behalf. The architecture remains isolated from other customer deployments, but operational evidence and responsibilities must be delivered through the service relationship.

Neither model is automatically compliant. The better model is the one whose responsibilities fit the institution's capacity and can be evidenced consistently.

Test the document-dependent business function

A platform-level restore test is valuable, but DORA-oriented resilience testing should include the business function. For example:

• Can a claims team retrieve evidence and issue correspondence during a search outage?
• Can credit operations access the current approved document while a workflow service is recovering?
• Can legal prove which agreement version was executed if the eSignature integration is unavailable?
• Can the institution identify all records affected by an authorization incident?
• Can a document export continue if the supplier relationship is terminating?

These scenarios expose the difference between technical availability and business continuity.

Design audit access before the audit

Direct access to a customer-controlled AWS account can provide strong observability, but raw logs alone are not a complete assurance package. Institutions need an agreed way to retrieve architecture records, configuration evidence, vulnerability information, support history, incident reports, and resilience test results.

Article 30(2) sets baseline contractual terms; Article 30(3) adds requirements for services supporting critical or important functions, including audit/access rights, test cooperation and transition arrangements. Routine assurance reports must not be used to contract away required rights. Negotiate procedures that preserve those rights. The contract should also address cooperation with competent authorities and how evidence from underlying cloud services will be provided.

Exit is a resilience control

An exit plan should preserve document availability, metadata, permissions, versions, and integration references while the replacement service is introduced. It should identify the transition period, export method, assistance, deletion process, and rollback conditions.

FormKiQ's customer-controlled storage and API-first model can reduce dependency on a proprietary export process. The institution still needs a tested mapping to the destination platform, especially for authorization, workflow, and records governance.

DORA asks financial institutions to remain in control of ICT risk. For a document layer, control is demonstrated through architecture, assigned responsibility, usable evidence, tested recovery, and an executable exit.

Worked diligence decision: credit-file recovery

Illustrative design exercise, not a reported incident or measured FormKiQ result.

1. Step 1

   Credit analysts need approved agreements during an outage

   Evidence and owner

   Institution names the supported function and criticality; operator supplies a timed restore test

   Buyer decision

   Accept only when the business task meets the institution’s recovery objective.

2. Step 2

   Signing and identity services remain external dependencies

   Evidence and owner

   Service map names providers, locations, access paths and evidence owners

   Buyer decision

   Record unavailable evidence and negotiate cooperation before contracting.

3. Step 3

   Operator needs supplier help during an incident

   Evidence and owner

   Agreement defines escalation, incident assistance, reporting inputs and test participation

   Buyer decision

   Do not infer service levels or audit rights from a public architecture page.

4. Step 4

   The institution must exit

   Evidence and owner

   A tested dossier export includes content, permissions, metadata and stable references

   Buyer decision

   Approve the transition plan with a named institution owner.