Apache Fineract for DORA ICT risk requirements

Apache Fineract for DORA ICT risk requirements: what the platform helps with

An EU financial entity running or planning to run Apache Fineract must meet the ICT risk management duties in Chapter II of DORA and the ICT third-party duties in Chapter V. Fineract's documented controls help with some of the technical evidence behind those duties, mainly the access model, the database and deployment choices that shape backup and recovery, and the event and batch behavior that supports monitoring. Fineract does not supply the information security policy, the risk assessment, the patching cadence, the backup frequency decisions, the recovery objectives, the vendor register or the exit plans. Those sit with the entity and with any support partner, and this page treats them that way. DORA sets no certification scheme, and no body certifies a Fineract deployment against it. DeployOpen plans, implements and documents a self-hosted Fineract environment and prepares the systems, configuration records and evidence an entity needs for its own assessment. It does not issue attestations, and competent authorities judge compliance on the entity's own documentation.

The first practical step is to map each DORA duty to one of three owners: Fineract configuration, the hosting and operations layer, or the organization's governance. Fineract's role-based permissions, maker-checker approvals and tenant separation belong in the first group, and they feed the access controls DORA expects. The Fineract-Platform-TenantId header and the tenants database define how tenants are separated, so the reader should confirm with the project documentation how tenant administration is restricted in their version. Its README also states that the default development login must be changed before any real deployment, which is a configuration check no platform setting will perform on its own. Items such as backup frequency, recovery objectives and vulnerability scan schedules must be set by the entity and implemented in the hosting layer. Confirm each of these in your own environment before relying on a platform feature.

Which DORA articles Fineract controls map to, and how to configure them

This table maps each DORA article or delegated regulation cadence to the Fineract capability that supports it and the configuration the entity must set. Read each row as the minimum you can show an assessor; the hosting layer and your own procedures close the remaining gaps. Fineract provides the building blocks, but the policies, reviews and evidence remain the entity's responsibility.

DORA requirement	Fineract capability to configure	Evidence to keep
Article 9(4)(a) to (c): information security policy, network segmentation and access limits	Set the default `mifos` login and password to new credentials before go-live. Restrict network paths so only the web front end and approved services reach the Fineract API, and keep the database and tenants database off public networks.	Written information security policy, network diagrams, and a record of the default credential change
Article 9(4)(b) and (c): access limited to approved activities	Use OAuth2 or HTTP basic authentication with per-user roles in Fineract. Review which roles can change products, accounting and tenant data, and keep privileged accounts separate from daily operator accounts.	Role matrix, provisioning tickets and the results of access reviews
Article 9(4)(d): strong authentication based on relevant standards	HTTP basic authentication alone carries a password on every request. Put Fineract behind an identity provider or gateway that enforces multi-factor authentication for staff, and confirm with your vendor which OAuth2 flows your version supports.	Identity provider configuration, MFA enrolment reports and the authentication standard you adopted
Article 9(4)(e): encryption of data in transit and key protection	Enable HTTPS only using the SSL settings exposed as environment variables such as `FINERACT_SERVER_SSL_ENABLED`. Store database credentials and keystores in a secrets manager, not in image files, and confirm the encryption approach for data at rest with your database and storage platform.	TLS configuration, certificate inventory, key custody records and classification of client data
Article 9(4)(f): documented change management and patch policies	Apply Liquibase migrations only through the write instance or the separate `liquibase-only` profile, so schema changes run in a controlled step. Plan upgrades against Fineract's quarterly releases and end-of-life archiving, and test each release before it reaches production.	Change tickets, test results, migration logs and the upgrade calendar tied to the end-of-life policy
Article 12(1): backup scope, frequency and restoration procedures	Back up the database that holds each tenant, including the tenants database, at a frequency set by data criticality. Because Fineract recommends PostgreSQL, base the backup design on PostgreSQL tooling and document the restore sequence across tenants.	Backup policy, schedule records, restore test reports and the list of tenant databases covered
Article 12(6) and (7): recovery objectives and reconciliation during recovery	Set recovery time and recovery point objectives per function. After a restore, run reconciliation of ledger and portfolio balances against source records before reopening business day processing, and confirm how the Close of Business Day job will be resumed.	Approved RTO and RPO per function, reconciliation checklists and recovery drill results
Article 28(3) and (8): register of ICT contracts and tested exit strategy	Record each Fineract support vendor, hosting provider and integration partner in the register. For exit, document how tenant data, configuration and the open-source code can move to another operator, and test a transition using the export and backup paths available in your environment.	Register entries, exit plan, transition test records and contract clauses on data return
Delegated Regulation 2024/1774: access rights review cadence	Review user, role and privileged accounts for Fineract at least every six months where the system supports critical or important functions, and at least yearly for other systems. Export role assignments from Fineract for each review.	Signed access review records with dates, reviewer names and removed accounts
Delegated Regulation 2024/1774: weekly vulnerability scanning and six-monthly firewall verification	Scan the Fineract hosts, containers and API endpoints weekly where the system supports critical or important functions. Verify firewall rules protecting the write, batch and read instances every six months, and confirm that read instances reach only the replicas they are meant to use.	Scan reports, firewall verification records and remediation tickets

How to limit access and enforce strong authentication in Fineract

Article 9(4)(c) of DORA requires policies that limit logical access to what legitimate, approved activities need, and Article 9(4)(d) requires strong authentication based on relevant standards. In Fineract, the first control to close is the default development login, the user mifos with a published password, which the project's README says must be changed for any real deployment. Treat that replacement as a go-live gate: the account should be disabled or re-credentialed, the change recorded, and the check repeated in each environment cloned from the same build. Confirm the credential handling process with your team, including where the new secrets are stored and who can read them.

Fineract supports OAuth2 and HTTP basic authentication, and the documentation strongly encourages HTTPS only, with SSL settings such as FINERACT_SERVER_SSL_ENABLED set through environment variables. Basic authentication alone does not meet a strong authentication reading, so the entity should decide which standard it relies on, document it in the information security policy, and show how OAuth2 tokens, TLS and any multi-factor step fit that standard. Confirm with the Fineract version you deploy how each mechanism behaves, and test that plain HTTP requests are refused at every entry point, not just the primary API hostname.

Fineract is headless, so the Mifos X web application or any other front end you add becomes a separate login surface that needs its own authentication, session timeout and MFA design. The same applies to any identity provider you place in front of Fineract. Record which system is the source of truth for staff accounts, how joiners and leavers are removed, and how multi-tenant access is scoped through the Fineract-Platform-TenantId header. Those decisions feed the access rights reviews that Delegated Regulation (EU) 2024/1774 sets at intervals of six months or a year, depending on criticality.

What evidence DORA reviewers can expect from a Fineract deployment

An examiner reviewing a Fineract deployment will ask for records rather than descriptions of intent. The cards below cover the records DORA's Article 9 and Article 12 duties and the delegated regulation's review cycles point to, and say who produces each one: Fineract itself, the hosting layer, or the entity's own processes.

Access rights review records

Reviewers will expect periodic access reviews covering Fineract users, roles and permissions, with the reviewer's sign-off and the changes made. Fineract records user and role data inside the platform, so export the user and permission lists from the application on each review date and keep them alongside the approval. Access to the database and to the Kubernetes or VM layer is reviewed separately by the hosting team. Confirm the review interval for Fineract, since the delegated regulation sets a six-month maximum for systems supporting critical or important functions. Include the privileged accounts in the review.

Change records for releases and configuration

Article 9 requires that every change is recorded, tested, assessed, approved, implemented and verified. For Fineract this covers two streams: platform upgrades and product or business rule configuration changes made through the API or application. The entity's ticketing system should hold the approval and test evidence, while Fineract's audit trail shows who made each configuration change and when. Reconcile the two streams each quarter so that no configuration change lacks a ticket.

Patch and update policy records

The entity needs a documented patch and update policy that names the Fineract release line it supports and how it responds to new releases. Fineract publishes official releases quarterly and archives end-of-life releases, so the policy should record the release currently in use, the date each release was checked against the project's release list, and the decision taken. Hosting layer patches such as operating system, database and container images need their own dated entries. Keep a log of vulnerability scan results, since the delegated regulation requires weekly automated scanning for these assets.

Backup and restore test records

Article 12 requires documented backup policies, restoration procedures and recovery objectives set per function. Evidence is the backup schedule, the backup scope covering the PostgreSQL database and the tenants database, and dated restore test results showing that a restore reached a usable Fineract state. Fineract does not produce backup evidence itself. The database platform, object storage and the entity's runbook produce it. Record the recovery time and recovery point objectives agreed for the function, and the results measured against them during each test.

Reconciliation logs during recovery

Article 12 expects checks and reconciliations during recovery to keep data integrity at the highest level. After a restore, the entity should run reconciliation of client, loan and savings balances against the independent source, such as the general ledger and payment records, and log the differences found and their resolution. Where Close of Business Day processing was interrupted, record which business dates were reprocessed and confirm the batch job completed. Keep the reconciliation output with the restore test record so that examiners see both together.

Access and configuration evidence from the hosting layer

Some DORA evidence sits outside Fineract. Firewall rule verification every six months and automated vulnerability scanning weekly are typically produced by the hosting team and its tools, while the entity keeps the reports. Retain TLS configuration records, since Fineract's HTTPS settings are environment variables, and the deployment manifests that show which instance types and profiles were running on each date. Confirm with the hosting team which tool produces each report and where it is stored.

Running change and patch management under the Fineract release policy

This sequence turns Fineract's quarterly release cadence and end-of-life archiving into a documented, tested and approved change record that supports Article 9(4)(f) of DORA. Each step ends with evidence an examiner can inspect.

Track official releases and end-of-life status
The platform owner watches the Fineract website, the apache/fineract repository and the release notes for each quarter. The README states that official releases are created quarterly, at the end of each quarter, under the ASF release policy, and that end-of-life releases are archived. Record the current stable release, the version you run in production, and the date you last checked. Keep this register in your ICT asset inventory so the support status of every environment is visible to risk and audit teams.
Decide whether the running release is still supported
Compare your production version against the release list and archive status published by the project. The README supports two conclusions only: a release that is still an official release is maintained under the project's policy, and a release that has been archived has reached end of life. Where the answer is unclear, ask the project or your support vendor in writing and file the answer with the decision. A release you cannot place in one of these two states should be treated as an open risk until resolved.
Assess and plan each candidate upgrade
Review the release notes and documentation for the target version against your configured products, custom code, integrations and database platform. Fineract's documentation says Liquibase migrations run only on write instances, which affects the rollout order in a multi-instance setup. Record the risk rating, the affected functions and whether they support critical or important functions. The output is a change request that names the rollback approach and the owners who must approve it.
Test the upgrade in a non-production environment
Deploy the target release to a staging environment built from a recent copy of production configuration, with data masked where personal data is involved. Run the regression cases for loan and savings products, end-of-day processing, accounting mappings, authentication and the interfaces to downstream systems. Include a timed run of the Close of Business Day job, since the README notes it can run for several hours on large deployments. Save test scripts, results and defects in the change record.
Obtain documented approval before implementation
Route the change request and test evidence to the change authority defined in your ICT change policy, which should be separate from the engineer who built the change. Approval should confirm the scope, the test result, the implementation window and the rollback criteria. Article 9(4)(f) requires changes to be recorded, tested, assessed, approved, implemented and verified, so the approval must be dated and attributable before any production step starts.
Implement the change with a rollback point
Take and verify a database backup and confirm restoration works before you touch production. Apply the change in the order your runbook defines, running Liquibase migrations on the write instance and then rolling out the batch and read instances. Log each step with timestamps and the operator name. Stop and invoke rollback if a defined criterion is met, and record that decision as well.
Verify the result and retain the record
After implementation, confirm the running version, run smoke tests on critical loan and savings transactions, check that the scheduled batch jobs completed, and reconcile key balances against the pre-change figures. Close the change record with the verification results, any residual issues and the updated asset inventory entry. Retain the complete record, including the release decision from the earlier step, for the period your retention policy requires, so that a supervisor can trace any production version back to its approved change.

Setting backup scope and recovery objectives for Fineract data

DORA Article 12(1) requires a documented backup policy that sets the scope of data backed up and the minimum backup frequency, scaled to the criticality or confidentiality of that data. For a Fineract deployment, the scope has to cover more than the database. The PostgreSQL database holds the loan, savings, client and general ledger state, but the backup set should also include the configuration that defines your products and business rules, the tenants database that maps each Fineract-Platform-TenantId to its tenant connection, the document store behind client KYC files, and the secrets and TLS material needed to bring the service back up. Record which of these you back up, how often, where the copies are held and who approves changes to that list. PostgreSQL is the recommended database for Fineract, so your backup tooling, point-in-time recovery settings and restore procedure should be designed around it, and any MariaDB or MySQL deployment will need its own method checked against the project's current guidance.

Article 12(6) requires recovery time objectives and recovery point objectives set per function, with criticality taken into account. Do not set these figures in IT alone. Agree them with the business owner of each function, such as loan disbursement, repayments or the general ledger, and document the reasoning. The timing is harder to guess than it looks. The Close of Business batch job can run for several hours on deployments with millions of accounts, so a restore followed by a full end-of-day rerun can consume much of a recovery window. Measure the restore time for a production-sized copy, then time a complete Close of Business run on that restored environment. Repeat the test after each major data growth step and after each Fineract or PostgreSQL upgrade.

Article 12(7) requires checks and reconciliations during recovery to keep data integrity at the highest level. Write these checks into the restore runbook before an incident happens. Typical checks compare account balances and ledger totals against the figures recorded before the failure, confirm that the last completed Close of Business date is correct, and verify that tenant connections and document references resolve. Make the recovery test a dated record with the restore duration, the measured Close of Business duration, the reconciliation results and the named approver. Auditors and supervisors will ask for that evidence, and it is the only reliable way to show that the RTO and RPO you agreed are achievable rather than assumed.

Treating Fineract support vendors as ICT third parties

Does DORA require a register of information for Fineract support vendors?

Yes. Article 28(3) of DORA requires a register of information covering all contractual arrangements for ICT services, and a vendor that deploys, maintains or supports your Fineract environment belongs on it. Record each vendor's role, the services it provides, the ICT assets and functions it touches, and the contract that governs the work. The register should show each arrangement separately, so a deployment partner, a hosting provider and a managed database provider each appear as their own entries. Keep it current as engagements start, change and end.

Is the Apache Software Foundation a contracted ICT third party for Fineract?

No. Apache Fineract is open source software licensed under the Apache License 2.0, and the Apache Software Foundation does not sell you services, host your environment or take responsibility for your operations. Your contracted ICT third parties are the organizations you pay, such as an implementation partner, a cloud or data center provider, or a managed PostgreSQL operator. The Fineract README notes that organizations may pay a vendor for deployment and maintenance, so that vendor is the party your register and contracts must cover. Document the project as a software dependency, not as a provider.

What must a DORA-compliant contract with a Fineract vendor say?

Article 30(2) of DORA requires every ICT services contract to state where services are provided and data is processed, and to require advance notice before those locations change. The contract must also cover data return on insolvency or termination of the provider. Beyond those terms, ask the vendor to commit to documented incident notification, access for your audit and supervisory needs, cooperation during recovery, and clear responsibility for patching the Fineract release and its database. Have your legal and compliance teams review the final wording against the full Article 30 requirements.

How do we plan an exit from a Fineract support vendor?

Article 28(8) of DORA requires documented, tested exit strategies and transition plans for ICT services that support critical or important functions, and a Fineract deployment usually falls into that group because it runs lending or deposit processing. The plan should name the data you would take back, the configuration and deployment code you own, the credentials and secrets you would rotate, and the team that would take over operations. Test the plan by rehearsing a restore into an environment run by another party, then record the results and the gaps you closed.

What should a Fineract exit plan include for the data and code?

The plan should list each artifact you need to keep operating without the vendor:

Who in our organization owns the vendor relationship?

Assign a named owner in risk or IT operations who is accountable for the vendor's register entry, contract terms, access reviews and exit plan. The owner should not be the same person who approves the vendor's own changes, so that oversight stays independent of delivery. Review the arrangement on a fixed schedule and whenever the vendor's scope changes. Your own ICT risk management documentation should show who signs off each vendor and what evidence they reviewed.

Can we run Fineract ourselves without a support vendor?

Yes, if your team can carry the work. The Fineract README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. If you keep the work in-house, your team becomes the ICT service provider to yourself, and the register, exit and testing duties still apply to any cloud, hosting or tooling vendors you use. Ask a partner for a written scope before deciding, and compare that against the skills and staffing you can commit.

What does a vendor engagement cost, and what drives it?

No fee or duration for vendor work is supplied here, so ask each vendor for a written quote built from a defined scope. Costs typically split into one-time work such as deployment, configuration, integration and migration, and recurring work such as patching, backups, monitoring and access reviews. Cost rises with the number of environments, the integrations in scope, the data volume to migrate and the frequency of support. Ask for the recurring and one-time components separately, along with the vendor's responsibilities for register, exit and testing support.

What Fineract and its hosting do not cover under DORA

Fineract and a well-run hosting layer cover much of the ICT risk management chapter, but several DORA duties sit with the financial entity itself. The cards below list the gaps that remain open and the checks to make before assuming any capability is in place.

Incident classification and reporting

Chapter III of DORA requires the entity to detect, classify, manage and report ICT-related incidents to its competent authority. Fineract writes application logs and business events, but it does not classify incidents against DORA criteria or submit reports. Your security operations process must correlate Fineract logs with infrastructure telemetry, define severity thresholds, and assign who decides on reporting within the required timelines. Confirm which log sources and event types your deployment actually emits before you design the pipeline.

Threat-led penetration testing

Chapter IV requires a digital operational resilience testing programme, and threat-led penetration testing applies to certain entities as designated by their authority. The project does not test your deployment, and a vendor's routine scan does not meet the threat-led standard. Plan the scope to include Fineract APIs, the tenant configuration, the database tier and the hosting layer, and agree with your authority how the test will be run and evidenced. Ask any testing provider to describe its method in writing before scoping.

Information security policy and governance

Article 9(4)(a) requires a documented information security policy, and DORA places ICT risk management responsibility on the management body. Neither Fineract nor its hosting vendor can write, approve or own that policy. Your board must approve the ICT risk framework, name accountable owners for each Fineract function, and review risk reports on a set cycle. Check that the Fineract roles, tenants and environments described in your policy match what is actually deployed.

Network isolation design

Article 9(4)(b) asks for a risk-based network and infrastructure management structure, which may include automated isolation of affected assets during an attack. The platform documentation does not design this for you. Decide how the write, batch and read instances, the database, the message broker and the administrative paths are segmented, and who can reach each one. Confirm that isolation can be triggered automatically and test that the Fineract services keep their required connections when it is.

No comprehensive production guide

The Fineract README states that the project does not provide a comprehensive production deployment guide and that production deployment can be complex, costly and time-consuming. Your architecture, hardening baseline and runbooks therefore come from your own design work or from a partner you contract. Treat every default in the documentation as a starting point to review, including the development login, which must be changed before any real use. Ask a deployment provider to show which parts of its runbook it wrote and which come from upstream.

Capabilities you must confirm

Any control you assume Fineract or its hosting provides should be confirmed in writing before you rely on it in a DORA file. This includes event publishing, which is disabled by default, the scheduling of backups, and the configuration of TLS through environment variables. Record the version you tested, the configuration that enabled each capability, and the evidence that it works in your environment. Where the product cannot show the capability, document the compensating control you chose instead.

Configuration sequence for a DORA-aligned Fineract deployment

This sequence turns DORA's ICT risk duties into an ordered build for a self-hosted Fineract platform, so each control is set up once, in the right order, and leaves a record an examiner can follow. Each step names the article it supports and the evidence it produces.

Scope the critical or important functions
Start by listing the business functions Fineract supports, such as loan servicing, deposits, end-of-day processing and customer records, and classify each as critical or important or not. Assign owners from the business and technology sides. The classification drives the depth of every later step, including vulnerability scan frequency and access review intervals under Delegated Regulation (EU) 2024/1774. The output is a signed function register that names each Fineract tenant, database, and integration in scope, and it feeds the information security policy required by Article 9(4)(a) to (c).
Replace default credentials and enforce strong authentication
Before any environment receives client data, change the default development login that the Fineract README documents, remove shared accounts, and configure OAuth2 or an approved identity provider for interactive users. Store service credentials in a secrets manager rather than configuration files. Confirm the authentication design against the strong authentication expectations in Article 9(4)(d). Evidence is a configuration review showing no default accounts exist in any tenant, plus a list of accepted authentication methods approved by the security owner.
Enable HTTPS and document cryptographic key handling
Turn on TLS using the SSL settings the Fineract documentation describes through environment variables such as FINERACT_SERVER_SSL_ENABLED, and terminate or re-encrypt traffic at the gateway in line with your network design. Record which certificates and keys protect the API, database connections and event brokers, who holds them, and how they rotate. This meets the key protection and encryption expectations in Article 9(4)(d). Evidence is a test showing plaintext requests are refused and a key inventory linked to the data classification in step one.
Set access limits and scheduled access reviews
Map Fineract roles and permissions to the approved activities in step one, and apply least privilege to maker and checker roles, database accounts and administrative tenant access. Schedule access rights reviews at the interval Delegated Regulation (EU) 2024/1774 sets for each class of system (Article 21), and run the first review before go-live. Evidence is a role matrix, a signed first review with removed or justified accounts, and a calendar of future reviews.
Design read, write and batch instances
Define one write instance, one batch instance and any read instances, each set through its instance type environment variables, and place read instances on database read replicas. Document which component serves interactive users, which runs end-of-day processing, and how firewall rules separate these paths. Firewall rule verification every six months applies to systems supporting critical or important functions (Article 13 of the delegated regulation), so record the rule set now. Evidence is an architecture diagram and a network rule export tied to each instance.
Separate Liquibase runs from application startup
Run database migrations only on the write instance, and on Kubernetes execute them as a separate job with the liquibase-only Spring profile. Require that each schema change is approved and rehearsed in a non-production environment before it reaches production. This supports the change recording expectations in Article 9(4)(e). Evidence is the migration job definition, the approval ticket that authorized the schema change, and logs showing the migration completed before application pods started.
Set backup scope and recovery objectives
Define the backup policy under Article 12(1): what data is backed up across the main database, tenants database, documents and configuration, the minimum frequency for each based on criticality or confidentiality, and the restoration procedure. Agree recovery time and recovery point objectives per function, as Article 12(6) requires. Include the reconciliation checks Article 12(7) expects after a restore, such as comparing ledger totals and account counts. Evidence is the approved backup policy, objectives per function, and a documented restore test with its reconciliation results.
Establish change, patch and vendor register records
Create a change record template covering test, assessment, approval, implementation and verification, and link every Fineract release, configuration change and patch to it. Track upgrades against the project's quarterly release cadence and end-of-life archiving so that unsupported versions are caught early (Article 9(4)(f)). Finally, enter every support vendor and hosting provider in the register of information under Article 28(3), with contract terms covering service location, data processing and data return under Article 30(2), and an exit plan under Article 28(8). Evidence is the change log, a patch policy, and the register entries.

What DORA work for Fineract costs and requires from the entity

What drives the cost of DORA work on a Fineract deployment?

The main cost drivers are the number of ICT services that support critical or important functions, the number of tenants, the hosting model, how much of the control set already exists, and how many vendor contracts must be re-papered. Each additional critical or important function adds mapping, testing and evidence work, because Article 9 and Article 12 requirements apply per function. A multi-tenant deployment multiplies access reviews and backup checks, while an existing, documented change process reduces the work. DeployOpen does not publish prices. A quote follows from a written scope that lists these inputs, so ask for each driver to be priced separately.

How long does a DORA gap assessment for Fineract take?

The duration depends on scope, and no fixed timeline is given here. A gap assessment grows with the number of critical or important functions in scope, the number of Fineract tenants and integrations, and the number of hosting and support providers to review. A scope limited to one core deployment with clear documentation is shorter than a review covering several environments, a disaster recovery site and multiple support contracts. Ask for the phases, deliverables and dependencies to be written into the agreed scope, and confirm with the entity's own compliance team which evidence is already available before work starts.

What must the financial entity provide before a DORA review starts?

The entity must supply the records that show how Fineract is built and controlled. Typical inputs are:

Architecture records for the Fineract instances, databases, message brokers and hosting layer
Access lists for administrators, service accounts and business users, with the latest access review
Backup logs, restore test results and the recovery objectives set for each function
Change and release records, including the patch and update policy in use
Contracts and service descriptions for every ICT third party, including data location and exit terms

Missing records usually extend the work, so collect them before the scope is signed.

Can an internal team do DORA work for Fineract without a partner?

Yes, an internal team can perform the work if it has the skills and time. The work spans security engineering, Fineract administration, database and backup operations, legal review of vendor contracts, and governance. The DORA requirements in Article 9, Article 12 and Article 28 need a documented policy, tested procedures and evidence, and the Delegated Regulation (EU) 2024/1774 adds testing and review cadences for systems supporting critical or important functions. Teams that lack one of these areas often bring in outside help for specific gaps, such as backup restore testing or contract mapping. Decide which parts stay internal and which are bought, and write that split into the scope.

Why does DORA not issue a certificate for Fineract compliance?

DORA sets no certification scheme. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). A gap assessment or implementation partner can prepare systems, controls and evidence, but it cannot issue a certificate or attest on the entity's behalf. The supervisory authority for the entity decides how compliance is judged. Ask any provider to state in writing what it delivers and what remains the entity's responsibility.

Which vendor contracts must be reviewed for Fineract under DORA?

Review every contract for ICT services that supports a critical or important function, including the Fineract support vendor, hosting providers, managed database services, backup providers and any identity or monitoring service. Article 28(3) requires a register of information covering all contractual arrangements, and Article 30(2) requires each ICT services contract to state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Article 28(8) requires documented, tested exit strategies for services supporting critical or important functions. Contracts that lack these terms usually need amendment, which takes time and depends on the provider's willingness to negotiate.

Does the entity need to keep DORA work running after the first review?

Yes. Several requirements recur, so the cost includes ongoing operation as well as the first assessment. Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning of relevant ICT assets at least weekly, firewall rule verification at least every 6 months for systems supporting critical or important functions, and access rights reviews at least every 6 months for those systems and at least yearly for others. Backup restore checks, patch records and exit plan tests also repeat. Ask for a quote that separates one-time setup from recurring work, and confirm who will run each recurring control after handover.

Does DeployOpen issue a DORA compliance report for Fineract?

No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Those come from the competent authority, independent auditors or other bodies the entity engages. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask for the written scope to name each evidence item the entity will hold at the end.

How DeployOpen scopes and delivers DORA configuration and evidence for Fineract

DeployOpen plans, implements and documents self-hosted Apache Fineract inside your own cloud accounts, data centers or air-gapped networks. For DORA, the work is shaped around the Article 9 controls, backup and recovery objectives, and the exit and vendor evidence that your own ICT risk function will need to show a competent authority.

How we scope

The written scope lists which Fineract functions are treated as critical or important, since that decision sets the testing and review frequencies that apply.
Scope covers access model, authentication settings, change and patch procedures, backup and recovery design, and support vendor terms, each with named owners.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows directly from that scope.

How we build

Access roles, maker-checker settings, HTTPS and OAuth2 configuration, and removal of the default development login are configured and tested in your environment.
Backup policy, restore procedures and reconciliation checks are built around the recovery objectives your business owners set for each function.
Security testing, including vulnerability scanning and firewall rule verification, is planned into the build and its results are recorded for your review.

How we hand over

Handover includes runbooks for change, patch and end-of-life upgrade decisions tied to the Fineract quarterly release cadence and archived releases.
Evidence packs map each delivered control to the DORA article it supports, with the records your auditors or supervisors are likely to request.
Exit and transition documentation covers data return, provider notice and a tested route to move Fineract workloads, reviewed with your legal and risk teams.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing against the controls agreed at handover.
Retainer work can cover periodic access reviews, firewall rule checks and vulnerability scan follow-up on the cadence your policies require.
Your compliance team remains accountable for the DORA determination. DeployOpen prepares systems, controls and evidence but does not issue attestations or certifications.