Apache Fineract for ISO 27001 controls

How Apache Fineract supports ISO 27001 controls 8.5, 8.15, 8.32 and 8.13

Fineract supplies application-level evidence for ISO/IEC 27001:2022 controls A.8.5 (secure authentication), A.8.15 (logging), A.8.32 (change management) and A.8.13 (information backup), but the certification decision and the infrastructure controls belong to the organization and its certification body. Consider a financial institution preparing an ISMS around a self-hosted Fineract core: the Fineract application can show how users sign in and what changed, while the hosting layer must show how access, networks, storage and backups are run. ISO does not certify organizations. Accredited certification bodies do that, and DeployOpen prepares systems, configuration and evidence without issuing certificates. Annex A is normative and lists 93 controls in four themes taken from ISO/IEC 27002:2022, so each control in this mapping needs an owner, a documented procedure and a record.

For A.8.5, Fineract supports HTTP basic, OAuth2 and two-factor authentication and strongly encourages HTTPS only, with SSL set through settings such as FINERACT_SERVER_SSL_ENABLED. The default development login must be replaced before any real use. For A.8.15, Fineract persists state-changing commands as an audit of all state changes. Your log pipeline still has to collect, protect and analyze those records, along with authentication failures and infrastructure events, and your auditor will want to see who reviews them and how. Confirm with your team which events leave the application and where they are stored, because the audit trail inside Fineract does not replace central log protection.

For A.8.32, the Fineract 1.15.0 stable release and the project's quarterly release policy give you a predictable upstream cadence to plan against, and maker-checker approval can be enabled for any state-changing API. Your change procedure should record each Fineract upgrade, configuration change and database migration, and should state that Liquibase migrations run only on write instances or through the liquibase-only Spring profile on Kubernetes. For A.8.13, Fineract does not back up itself. Confirm how the PostgreSQL database, the tenants database and any document storage are backed up, and test restores on a schedule defined in your backup policy. The Apache Fineract platform documentation is the natural starting point for confirming these settings against your version.

Mapping Annex A 8.5, 8.15, 8.32 and 8.13 to Fineract capabilities and configuration

This table pairs each of four ISO/IEC 27001:2022 Annex A technological controls with what Apache Fineract provides, and the configuration your team must set before an assessor would see any evidence. Read each row as a starting point: Fineract supplies some of the mechanics, while the control itself is met only by your policies, operating procedures and records. The main takeaway is that every row depends on configuration and hosting decisions that Fineract does not make for you.

Annex A control and requirement	Fineract capability	Configuration and hosting needed
A.8.5 Secure authentication: secure sign-in technologies and procedures tied to your access control policy	HTTP basic, OAuth2 and two-factor authentication are supported; the documentation strongly encourages HTTPS only	Replace the default development login (mifos) before any real use; choose OAuth2 or basic auth per your policy; enable two-factor authentication; document the access control policy it implements
A.8.15 Logging: logs of activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed	Persists state-changing commands as an audit of all state changes	Ship application and gateway logs to a central store you control; restrict who can read or alter them; set review and alerting procedures; confirm log retention with your own policy
A.8.32 Change management: changes to information processing facilities and systems follow change management procedures	Maker-checker approval can be enabled for any state-changing API; Liquibase schema migrations run only on write instances or via the liquibase-only Spring profile	Enable maker-checker for each state-changing API that your change process covers; keep release, migration and configuration changes in tickets with approvals; run Liquibase on a controlled write instance during change windows
A.8.13 Information backup: backups of information, software and systems are maintained and regularly tested under your backup policy	PostgreSQL is the recommended database, and the 1.x line is the maintained platform; Fineract does not itself take backups	Back up the PostgreSQL database, tenants database, configuration and documents together; keep copies outside the primary system; run and record restore tests; confirm the backup approach with your PostgreSQL and hosting teams
Tenant and instance settings across all four controls	Multi-tenant requests carry the Fineract-Platform-TenantId header; read, write and batch instances are set by environment variables	Confirm which tenants and instances are in scope for each control; apply HTTPS and credential settings to every instance and tenant; document the instance layout as an asset in your ISMS

Secure authentication setup for Fineract tenants

HTTP basic authentication is the mechanism the Fineract README uses in its quick start, and it is the simplest option to run on a development or test instance. It sends a username and password with each request, so its security depends almost entirely on the transport layer and on credential hygiene. The README ships a default development login, and that login must be removed or changed before any real deployment, which is a finding auditors check first.

Default credentials: Confirm that the development login is disabled or replaced in every non-development environment, and record the change as evidence.
Transport protection: Basic credentials are only acceptable over HTTPS, so pair this option with the HTTPS-only settings in the release documentation.
Scope limit: Keep basic authentication out of production user access unless the access control policy explicitly approves it for a named service account.
Credential rotation: Define how shared or service passwords are stored, rotated and revoked, since basic authentication offers no session expiry of its own.
Logging linkage: Make sure each request can be attributed to a named user for A.8.15 purposes, which a shared credential does not provide.

The access control policy should say which environments may use basic authentication and who approves exceptions. Confirm the current behavior against the Fineract documentation for the release you run.

Which logs, change records and backup evidence auditors ask for

Auditors test ISO/IEC 27001:2022 controls by sampling records, not by reading design documents. For a Fineract deployment, the evidence falls into three groups: the platform's own record of state changes and approvals, the logs produced by the application and hosting layers, and the change and backup records that prove the environment was controlled over time. Each card below names one item, how long to keep it and who should review it.

Fineract state-change audit and approvals

Fineract persists state-changing commands as an audit of all state changes, and maker-checker approval can be enabled for any state-changing API. Export or query these records on a schedule and sample them against approval rules, such as whether a loan disbursement was approved by someone other than its creator. Confirm with your own configuration which endpoints have maker-checker turned on, because an unenabled endpoint produces an audit trail with no independent approval. Retention periods are set by your policy and any lending or banking rules that apply to you, so confirm them with your compliance lead. Reviewed by the operations owner of the business process and sampled by internal audit.

Application and infrastructure logs

A.8.15 asks that logs of activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed. For Fineract, that means authentication events from the chosen login method, API errors, Close of Business Day job outcomes and Liquibase migration output, plus reverse proxy, database and host logs. Ship them off the application host to storage that administrators cannot silently alter, and set a documented retention period. Confirm which of these your version emits by default and which need configuration. Security operations reviews alerts, and the Fineract platform owner reviews job and exception logs.

Log integrity and access protection

Logs only count as evidence if you can show they were not changed after the fact. Restrict who can read and delete log stores, separate those roles from people who administer Fineract, and record access to the log platform itself. Where logs carry personal data, such as client identifiers in error messages, decide what is masked before storage. Ask your logging vendor or platform team to document hashing, write-once options or immutable storage, and confirm these exist in your environment before an auditor asks. Reviewed by the security team, with access reviews signed off by the control owner.

Release and configuration change records

A.8.32 requires changes to information processing facilities and systems to follow change management procedures. For Fineract, keep records for each release upgrade, each database migration run, each deployment manifest or image version, and each configuration change, including environment variables and tenant settings. Fineract releases are created quarterly at the end of each quarter, so a dated release calendar and an approval record for each upgrade make it easy to show a sample. Link every change to a ticket, a test result and an approver who is not the person who made it. Reviewed by the change advisory group and sampled against deployed versions.

Backup job records and restore tests

A.8.13 asks that backups of information, software and systems are maintained and regularly tested under your backup policy. For Fineract, the evidence includes backup job logs for the PostgreSQL database, the tenants database, documents and configuration, along with the schedule and the retention each one follows. A backup that has never been restored is weak evidence, so keep dated restore test records that show a full restoration into a separate environment and a check that the Fineract instance starts and returns expected client and loan data. Confirm recovery objectives with the business owner. Reviewed by the database and platform owners, with results reported to the risk committee.

Migration and data conversion records

Records from initial data loads and later bulk imports show whether the data in Fineract matches the source system. Keep the mapping files, the row counts and reconciliation totals for each load, the approver's sign-off, and the Liquibase migration logs from the same run. Auditors often ask for these when the platform was populated from a legacy core, because the balances in Fineract must trace back to a controlled source. Confirm with your data team which reconciliation reports the import process produces. Reviewed by finance and the business owner of the migrated portfolio.

What Fineract does not cover for ISO 27001

Fineract can produce many of the technical records an ISO/IEC 27001 audit samples, but it cannot run your information security management system or secure the rooms, people and processes around it. The project also states that it offers no comprehensive production deployment guide and that production deployment can be complex and costly, so the cards below mark where your own controls must start.

The ISMS itself

Scope, risk assessment, Statement of Applicability, policies and management review belong to your organization, not to the software. Auditors will ask how the scope was set, how risks were treated and which Annex A controls were selected and why. Fineract's audit trail cannot answer those questions. Confirm early which owner signs each policy and when management review happens, because certification bodies examine those records directly.

Physical and people controls

The 14 physical controls and 8 people controls in Annex A cover premises, equipment, screening, training and termination. Fineract has no role in badge access to data centers, staff vetting or exit steps for administrators. Map these controls to your facilities team and HR process, and collect their evidence separately from the platform records.

Log retention and SIEM analysis

Fineract records state changes, but the control asks that logs are also stored, protected and analyzed. Retention periods, write-once storage, time synchronization and alert rules must be set in your logging stack. Confirm where Fineract application and database logs are shipped, who reviews them and how often, because a log that nobody reads will not satisfy the control.

Backup restore testing and off-site copies

Fineract's configuration and database are only part of the backup scope. Control 8.13 asks that backup copies are regularly tested, so restore drills must cover the PostgreSQL database, document storage and secrets, then measure how long recovery takes. Keep at least one copy outside the primary site and record each test result, since the platform does not run these drills for you.

Change approval outside Fineract

Maker-checker inside Fineract approves business changes such as loan products or client records. It does not approve infrastructure changes, container image updates, Kubernetes manifests, database migrations or changes to environment variables. Those need their own change tickets, peer review and rollback notes, kept in your Git and deployment tooling. Verify that every production release traces back to an approved change.

Mifos web front end and other clients

Fineract is headless and provides no user interface, so the Mifos web application or any custom client is a separate system. Each needs its own authentication, session timeout, input validation, patching and logging under the controls. The README points to Mifos X as a front end in its Kubernetes example. Treat it as an in-scope component and assess it on its own.

Configuring Fineract so the evidence exists before the audit

This sequence turns the Annex A control intent for authentication, logging, change management and backup into Fineract and hosting settings, with a recorded check at each step. The order matters because later evidence depends on earlier decisions, and the exact sequence depends on the hosting model you choose.

Confirm scope and the Statement of Applicability
Agree with the organization which systems, tenants, databases, batch and read instances, admin consoles and support access fall inside the ISMS scope, and record the controls you claim for each in the Statement of Applicability. The ISMS owner signs off the scope, and the Fineract platform owner confirms which instances and environments are included. Done means a dated scope statement exists and every Fineract component maps to at least one in-scope control. Confirm with your certification body how it expects the Statement of Applicability to reference the control set in ISO/IEC 27001:2022.
Replace default credentials and set authentication
Remove the default development login that the Fineract README documents, and set strong credentials for every administrative account in every tenant. Choose the authentication method your access policy supports (HTTP basic, OAuth2, or two-factor authentication where Fineract supports it for your configuration), and confirm the exact settings against the platform documentation for your release. The identity team records who holds administrative access and how accounts are created and removed. Done means a test login with the default credentials fails in every environment and the access record names the owner of each account.
Enable HTTPS only at the server boundary
Enable TLS through the documented SSL environment variables, such as FINERACT_SERVER_SSL_ENABLED, and make sure the hosting layer (load balancer, ingress or gateway) redirects or rejects plain HTTP to the API. The platform or infrastructure team owns certificate issuance and renewal, and the security team checks cipher and protocol settings against your baseline. Done means a plain HTTP request to the API is refused and the configuration is stored in version control with the deployment manifests.
Enable maker-checker on required APIs
Identify the state-changing APIs that carry financial or access risk, such as product configuration, client onboarding, loan approval and disbursement, and enable maker-checker for each in the Fineract configuration. Business owners define who may make and who may check each action, and the segregation is reflected in role assignments. Done means a test maker request stays pending until a different authorized user approves it, and the approval trail is captured for the evidence pack.
Route logs and set retention
Send Fineract application logs, access logs from the gateway and database audit output to a central log store that the operations team does not control alone, and protect those logs from modification. Set retention periods based on your policy and any contractual or legal obligations, and confirm them with your legal and compliance owners. Analysis rules, such as alerts on failed logins and privileged changes, are defined and tested with sample events. Done means a test event from each source appears in the central store with its timestamp and user identity.
Gate Liquibase migrations and releases
Configure Liquibase migrations to run only on the write instance, or separately with the liquibase-only Spring profile on Kubernetes, so schema changes are controlled events rather than side effects of ordinary restarts. Require every release and configuration change to pass through a recorded change request with a test sign-off and a rollback plan. Done means a change ticket, the migration run record and the deployment record reference the same release identifier.
Set up PostgreSQL backups with tested restores
Configure PostgreSQL backups and point-in-time recovery for the Fineract database and the tenants database, store copies outside the primary failure domain, and set encryption and access controls on the backup store. Run restore tests into an isolated environment and record the results, including the time taken and any gaps found. Done means a restore test has completed for each database and the restored Fineract instance passes a basic read check. Confirm recovery objectives with the business owners before the test is scored.
Collect the first evidence pack
Assemble the records the auditor will ask for: the scope statement, credential and access reviews, TLS configuration, maker-checker test records, log samples and retention settings, change tickets with migration records, and backup and restore test reports. The ISMS owner reviews the pack against the Statement of Applicability and marks gaps for remediation before the audit. Done means each in-scope control points to at least one dated record, and any gap has an owner and a closure record.

Questions buyers ask about Fineract and ISO 27001 readiness

Is Apache Fineract ISO 27001 certified?

No. Apache Fineract is open source software, and a software platform is not certified to ISO/IEC 27001. The standard applies to an organization's information security management system (ISMS), and ISO does not certify organizations. Accredited certification bodies perform that assessment against the organization's own ISMS, scope and controls. Your Fineract deployment, hosting layer, identity setup, change process and backup routine are evidence inputs to that assessment. Ask any partner to show which parts of the control set they prepare evidence for and which parts remain your organization's responsibility.

What drives the effort and cost of ISO 27001 readiness for Fineract?

The main drivers are the scope of the ISMS, the hosting model, the number of Fineract tenants and environments, and how much of an ISMS already exists. A single production tenant on infrastructure you already run with written policies needs less work than several tenants across cloud accounts with no documented access reviews. Cost has two parts: the partner's fixed-scope work on configuration, documentation and evidence, and your staff time for policy approval, access reviews and interviews. Ask for a quote that lists the in-scope tenants, environments, controls, deliverables and the client inputs each deliverable depends on.

How long does ISO 27001 readiness preparation take for a Fineract deployment?

The duration depends on the scope and on the controls you already operate. A team with a working ISMS and a stable Fineract environment will move faster than one that needs policies, asset records and logging written from scratch. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts and should list the milestones, the dependencies on your staff and the review points. Ask for the timeline as a set of deliverables with dates, and confirm which items depend on your change calendar or on access to your cloud accounts.

What does ISO 27001 readiness need from our own staff?

Readiness work needs decisions and access from your organization that no partner can make for you. Expect requests for named owners for each control area, approval of the information security policy and topic-specific policies on access control, logging and backup, and access to Fineract administrators, the hosting platform, the identity provider and the backup system. Staff will also need to walk through how changes are approved, how backups are restored and how access is removed when people leave. Confirm these inputs, their owners and their dates in the written scope so that delays are visible early.

Can our internal team prepare Fineract for ISO 27001 without a partner?

Yes, an internal team can prepare for ISO 27001 if it has people who understand the standard, Fineract's configuration and your hosting platform, and time to build the evidence. The work is mostly documentation and proof: the ISMS scope, the risk assessment, the statement of applicability, control procedures and records from running systems. Teams that do this alone often underestimate the evidence collection for logging, change management and backup testing. A partner can take on defined deliverables, such as hardening documentation or evidence packs, while your team keeps ownership of the decisions and the ISMS itself.

Which body checks our ISMS, and how does the three-year cycle work?

An accredited certification body performs the audit, and it must operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. This means the initial certification is followed by annual surveillance audits and a recertification audit at the end of the cycle. Keep the evidence for each control current throughout the cycle, because surveillance audits sample records across the whole period. You can check an accredited certificate in the IAF CertSearch database, which ISO still points to for that purpose.

Does the 2013 edition of ISO 27001 still apply to our audit?

No. Under IAF MD 26:2023, all certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period. Any audit you plan now should assess the 2022 edition, which has 93 Annex A controls in four themes instead of 114 controls in 14 clauses. Your gap assessment and statement of applability should map to the 2022 control IDs. The 2024 climate change amendment also adds to clauses 4.1 and 4.2, so your context and interested party analysis should consider whether climate change is relevant to your organization.

How the audit uses Fineract evidence in an ISO 27001 certification cycle

The certification body, not DeployOpen and not the ISO, decides whether your information security management system conforms to ISO/IEC 27001 and whether your Annex A control selection is acceptable. ISO does not certify organizations, and accredited certification bodies work to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. Under ISO/IEC 17021-1, a certification cycle runs three years, with at least one audit in every calendar year, either surveillance or recertification. Confirm with your certification body which edition its contract references and how it plans the audit calendar, because that calendar sets when Fineract evidence must already exist. If your organization still holds a certificate to the 2013 edition, note that under IAF MD 26:2023 all such certificates had to expire or be withdrawn by 31 October 2025.

Auditors do not read every log line or every approval. They sample, usually by selecting a set of users, changes, backups or restore tests across the audit period and asking for the record behind each one. For Fineract, a practical sample set includes the role assignments and maker-checker settings for a few privileged users, the change tickets and release records for Fineract upgrades and product configuration changes, backup job reports and at least one documented restore test, and log extracts covering authentication failures and administrative actions. Ask the certification body early which samples it expects, what period they must cover, and whether it accepts system-generated reports or requires screenshots with timestamps. Evidence that exists only for the months before an audit will usually be questioned, so the collection routine should run continuously from the first day of the cycle.

How DeployOpen works on this

DeployOpen plans, builds and documents self-hosted Apache Fineract deployments inside the client's own infrastructure, so the access, logging, change and backup evidence sits where the auditor will look for it. We scope the Annex A controls against the deployment as it actually runs, then prepare the records an assessor asks for, while the independent certification body makes the certification decision.

How we scope

Engagements are fixed-scope, with the Fineract controls, hosting layers and Annex A controls in the written scope.
We confirm which Fineract instances, tenants, databases and admin accounts fall inside the ISMS boundary.
We agree in writing which evidence items each control needs and who in your organization owns each one.

How we build

We configure authentication, HTTPS and maker-checker settings and test them against documented Fineract behavior.
We design log collection, retention and protection for Fineract audit records and the hosting layer around them.
We set up change procedures for releases, Liquibase migrations and product configuration, and test restore of backups.

How we hand over

We deliver a control-to-evidence map that names the system, owner, record location and collection frequency for each control.
We document runbooks for access reviews, release approvals, log review and backup restore tests.
We train your team to pull evidence themselves so the next assessment does not depend on us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover quarterly Fineract release reviews, patch records and periodic restore tests.
We prepare evidence for your certification body, but we do not issue audit reports, attestations or certifications.