How Apache Fineract supports a SOC 2 audit
If you are preparing a self-hosted Apache Fineract lending or banking platform for a SOC 2 examination, Fineract helps most with three criteria: CC6.3 on granting, changing and removing access, CC8.1 on managing changes, and PI1.3 on processing integrity. The examination itself is performed by a CPA firm, and the report is the auditor's opinion, not something Fineract or DeployOpen issues. Fineract supplies application-level mechanisms that your evidence can point to; it does not make your organization compliant on its own. SOC 2 is built on the AICPA's 2017 Trust Services Criteria, which cover five categories: security, availability, processing integrity, confidentiality and privacy. The security common criteria, CC1 to CC9, apply to every SOC 2. The other four categories are added only when they are in scope, so decide early whether processing integrity is in scope, because the PI1.3 work described here depends on it.
Fineract does not cover several areas an auditor will test. Written policies, the governance that approves them, personnel screening and training, and the hosting controls in your cloud account, data center or network are all yours to design and evidence. The Fineract platform also does not produce the system description that management prepares under the 2018 description criteria, and it does not give you an operating effectiveness opinion. Ask your CPA firm early which controls they expect to test in each category and which of them sit with the application, the hosting layer or the organization. Mapping that answer to Fineract's own configuration is where the engagement effort goes.
Mapping CC6.3, CC8.1 and PI1.3 to Fineract capabilities and configuration
This table maps each SOC 2 criterion in scope for this topic to the Fineract capability that supports it, the configuration it needs and the gap your team must close outside the application. Read each row as a design question: what the criterion asks, what Fineract provides, and what you must configure and evidence yourself. Authentication hardening is a prerequisite for every row, so treat it as the first item in the plan.
| Criterion and need | Fineract capability | Configuration and evidence to confirm |
|---|---|---|
| Baseline: authentication (supports CC6.1 and CC6.3) | Fineract supports OAuth2 and HTTP basic authentication through its documented settings | Replace the default development login (mifos) before any real use. Enforce HTTPS using the documented SSL environment variables such as FINERACT_SERVER_SSL_ENABLED. Confirm the chosen identity provider configuration with the vendor documentation and keep the settings in version control. |
| CC6.3: grant access based on roles | Tenant-scoped roles and permissions, with requests identified by the Fineract-Platform-TenantId header | Define a role matrix per tenant and per office. Export role and permission assignments on a fixed schedule as access evidence. Confirm how role changes are logged in your release version. |
| CC6.3: least privilege and segregation of duties | Maker-checker approvals for sensitive changes, where the feature is enabled for the operation in question | List which operations require a checker, such as loan disbursement or product changes. Test that the maker cannot approve their own request. Keep the approval history as evidence. Confirm per-operation support before designing around it. |
| CC6.3: removal of access | User deactivation through the platform's user administration, plus removal of identities at the external identity provider | Document the offboarding steps for both layers. Sample leavers against active accounts each review cycle. Confirm whether deactivated users keep historical audit records in your version. |
| CC8.1: change authorization and testing | Liquibase database migrations that run only on write instances, or separately through the liquibase-only Spring profile on Kubernetes | Run schema changes through the same change ticket and approval path as application releases. Keep the migration logs and the pre-production test record for each change. Confirm the migration order against your instance layout. |
| CC8.1: patch management and end-of-life tracking | Quarterly official releases at the end of each quarter, with end-of-life releases archived | Record the running version, the target release and the date each patch was assessed. Plan upgrades against the release policy rather than waiting for an incident. Confirm current support status in the repository before each review. |
| PI1.3: processing specifications and scheduled processing | Close of Business Day Spring Batch job, which can run for hours on large deployments and supports remote partitioning through ActiveMQ or Kafka | Document the expected run window, the job owner and the alert path for failed or late runs. Keep job execution history as evidence that processing ran as specified. |
| PI1.3: detecting and correcting processing errors | Batch job status and the audit trail of business transactions, with external events optional and disabled by default | Enable and test event publication to a broker only if your monitoring needs it. Define how failed batch steps are reprocessed and who signs off the correction. Confirm which records your reconciliation process reads. |
Which evidence to collect for each SOC 2 criterion
Auditors test a SOC 2 by sampling evidence, not by reading policies. The cards below cover the records a Fineract-based platform should be able to produce for access, approvals, releases, batch processing and reconciliation, and where each one lives. For a Type 2 report, each record must show the control operating across the examination period, not only on the day it was collected.
Access review records
Auditors ask for periodic reviews showing who holds each Fineract role, who was added or removed, and who approved the change. Export the user list and role assignments from the Fineract tenants and application databases at each review date, then have the reviewer sign the export with the date and the decision taken. Check that privileged accounts, including any remaining default development login, are absent from the export. Keep the exports from every period, not just the most recent one.
Maker-checker approval records
For CC6.3, the evidence that matters is proof that a second person approved sensitive actions such as loan disbursement, product changes or user role changes. Fineract records the maker and checker for approval-enabled actions in its database, so query those records for a sample of transactions across the period. Confirm that no maker approved their own request. Document any action that bypassed approval and why.
Release and deployment change records
CC8.1 expects each change to carry an authorization, a test result, an approval and an implementation record. Link each Fineract upgrade, custom module release and configuration change to a ticket in your tracker, the pipeline run in your CI or release system, and the approver. Keep the release notes and the baseline configuration that existed before each change. Emergency changes need the same chain, recorded after the fact with their justification.
Patch and upgrade history
Auditors look for a record of which Fineract release, database version and container image ran in each period, and when each patch was applied. Keep the image digests, the deployed version string from each environment and the dates of each change. Fineract releases are created quarterly and end-of-life releases are archived, so note when the running version left active support and what was planned in response.
COB job logs
The Close of Business batch job drives interest postings and accruals, so processing integrity evidence depends on its logs. Retain the job execution history from the batch instance, including start and end times, failed steps and reruns, for every business day in the period. Where COB runs with remote partitioning, keep the worker logs as well. Investigate any failure and record the correction, because PI1.3 expects processing errors to be detected and corrected.
Reconciliation outputs
Reconciliation shows that the Fineract ledger agrees with the transactions it processed and with the external ERP or bank records it feeds. Retain the periodic reconciliation reports, the exceptions list, and the sign-off on each exception. Store the reports with the query or script that produced them, so the auditor can rerun the same check. Gaps in the reporting series are often the first finding an examiner raises.
Choosing the Type 1 or Type 2 report and the trust categories in scope
Pick the report type and the trust categories before you write any control narrative. A SOC 2 Type 1 report covers the system description and whether controls are suitably designed as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. For a Fineract platform, the Type 2 period is where evidence matters most: role assignments in the admin screens, maker-checker approvals on loan and savings transactions, and Close of Business Day (COB) job results must exist for every month in the window, not only at the audit date. Ask your auditor which period they will test and whether a Type 1 is expected first.
Security is always in scope through the common criteria CC1 to CC9. Processing integrity (PI1) is added only when you select it, and it should be selected deliberately. If your product promises that loan balances, interest postings and ledger entries are complete and accurate, PI1.3 expects you to define processing specifications and record processing activity, which points directly at Fineract's COB runs, accounting mode settings and journal entry reconciliation. If you leave processing integrity out, say so in the system description so readers understand the boundary. The 2018 description criteria (DC 200) govern how management writes that description, and the 2022 points of focus guide what the controls should address. Use them to decide which Fineract components belong inside the boundary, such as the tenants database, read replicas, batch instances and the identity provider.
Finally, decide who the report is for. A SOC 3 report summarizes the same categories in less detail and is a general-use document that can be freely distributed, which suits a public trust page. A SOC 2 report is generally restricted to existing customers, prospects under agreement and other specified parties, so your sales process should plan for that distinction. Confirm the distribution terms with your auditor before you promise a report to a prospect.
Configuration sequence before the audit window opens
This sequence fixes the system boundary, access rules, change records and reconciliation evidence before the SOC 2 observation period starts, so the first Type 2 window begins with controls that already operate and leave a trail. Each step names the criterion it serves and the output that closes it.
Define the system boundary and tenants
Write down which Fineract tenants, APIs, databases, batch and read instances, integrations and hosting accounts fall inside the system description, and which belong to vendors or other teams. Map each tenant to the products it processes and to the people who administer it. The step is done when the system description draft matches the deployed topology, including the tenant identifiers used in the Fineract-Platform-TenantId header, and the scope has been agreed with the audit firm. This boundary sets the scope for every later control.
Set roles and maker-checker rules
Define Fineract roles that reflect job duties, remove default or shared administrative access, and document which actions require a second person, such as loan approval, disbursement, product changes and journal entries. Confirm in your own test tenant which maker-checker options your release supports before you commit to a rule set. Assign the privileged roles to named individuals only. The step closes with an access matrix that a reviewer can trace to CC6.3 least privilege and segregation of duties, and with a sample of role changes captured as tickets.
Lock down authentication and HTTPS
Replace the development login supplied in the README with credentials issued to individuals, configure OAuth2 or the chosen authentication method, and enable HTTPS only through the documented SSL environment variables. Confirm that the database and tenant connections are not reachable from outside the intended network and that the default account is disabled or removed. Record the configuration baseline in version control so changes to these settings leave a history. The step is complete when a test login over plain HTTP fails and the baseline file matches the running configuration.
Start the change and patch record
Create a change log that links each Fineract release, configuration change, product change and infrastructure patch to a ticket, a designer or developer, a test result, an approver and a deployment date. Tie the log to the Fineract release cycle, which the project publishes quarterly, and record the decision for each release, including whether it is adopted, deferred or tracked as an end-of-life risk. This addresses the authorization, testing, approval and implementation stages expected under CC8.1. The step closes when one full change has passed through the record from request to production.
Verify COB and accounting reconciliations
Run the Close of Business job in a non-production copy, confirm the job completes and that its failures generate alerts, and reconcile the general ledger journal output against the loan and savings subledgers. Document the reconciliation procedure, who reviews the differences and how errors are corrected and recorded. Confirm that batch job runs, failures and manual reruns are logged. This serves PI1.3 by showing that processing specifications are defined, processing errors are detected and corrected, and processing activity is recorded. The step is done when a reconciliation for a sample period is signed off by someone other than the preparer.
Start the evidence calendar
List every recurring artifact the auditor will ask for, including access reviews, role change tickets, release records, patch assessments, backup restores, COB reconciliations and incident logs. Assign each to an owner and a review cadence set by your own policy, and store the outputs in a single evidence repository with consistent naming. Confirm with the audit firm which sample periods and formats it expects. The step closes when the calendar has been run once for each item, so gaps appear before the observation period rather than during fieldwork.
What SOC 2 preparation with Fineract costs and requires
What drives the cost of SOC 2 preparation for a Fineract platform?
Scope drives most of the cost: which Trust Services Categories are in the boundary, how many Fineract tenants and environments exist, how many systems sit in the boundary around the core (identity, hosting, backups, logging, ticketing), and how many controls already have evidence. Existing policies and whether the team already runs a change process reduce the work, while new access reviews or a missing release history increase it. Evidence tooling adds a recurring subscription if you buy it, which is separate from any services fee. Ask any partner for a quote built from a written scope that lists these items, not a flat package.
Is a fixed fee possible for SOC 2 readiness work?
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and fees follow from that written scope. Your readiness work is separate from the audit itself: the CPA firm that examines the system charges its own fees for a Type 1 or Type 2 examination. Ask the audit firm for its own quote and the period it expects to cover, and ask the readiness provider to state which deliverables are fixed and which depend on your answers.
How long does SOC 2 readiness take for a Fineract platform?
Duration depends on the same inputs as cost: scope, the number of systems in the boundary, how mature your access and change records are, and how quickly owners answer questions. A Type 2 report also needs an observation period in which controls operate, so the calendar time to a report is longer than the build time for documented controls. The 2017 Trust Services Criteria and the AICPA attestation standards set the frame, but they do not set a duration. Ask for a plan with milestones and named dependencies rather than a single date.
What must our organization supply before SOC 2 work starts?
Plan to supply the following before work starts:
- Named control owners for access, change management, operations and processing.
- Policy decisions, such as who may approve privileged access, release approvals and the emergency change path.
- Read access to Fineract environments, identity provider configuration, hosting, CI/CD and ticketing systems.
- Release and patch history for Fineract and the database, including the versions deployed and when each changed.
- Records of user access reviews, offboarding and COB or batch job runs.
The quality of these inputs is the largest single driver of how much work remains after the first assessment.
Can our internal team prepare for SOC 2 on Fineract without outside help?
Yes, an internal team can prepare for SOC 2 if it has people who understand the Trust Services Criteria, Fineract configuration and the hosting layer, and enough time to run the controls and collect evidence consistently. The hard parts are usually the observation period and the evidence trail, not the policy text. Teams with a single engineer holding all privileged access, or with no change records for past releases, often find outside help useful. Decide early who will own the control matrix, because a control with no owner rarely produces usable evidence.
Why does DeployOpen not issue the SOC 2 report?
DeployOpen does not issue audit reports, attestations or certifications. A SOC 2 examination is performed by a CPA firm under the AICPA attestation standards, and the service auditor obtains written representations from management. DeployOpen prepares the system, controls and evidence that the auditor will examine, and it can help document the system description. Keeping preparation and examination with separate parties is what gives the report its independence, so ask the audit firm to confirm its independence requirements before engagement.
Which evidence should we keep for Fineract access and change controls?
Keep evidence that shows each control operated over the period, not only that a policy exists. For access (CC6.3), keep role assignments, approval tickets for grants and removals, periodic access reviews, and records of separation. For change management (CC8.1), keep the change request, design or configuration notes, test results, approver identity and deployment records for each Fineract release and product configuration change. Confirm with your auditor which samples and time periods they will select before you finalize the evidence format.
What Fineract and the hosting layer do not cover
Apache Fineract gives you controls inside the application, but an SOC 2 examination covers the whole system, including people, policies, vendors and infrastructure. The cards below list the areas that sit with your organization or your hosting team, and what to confirm with your environment and your auditor before the examination period starts.
No production deployment guide
The Fineract README states that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Your deployment design, including network segmentation, runtime hardening, instance layout and recovery procedures, becomes your own documented baseline. Confirm who owns that baseline, where it is stored and how it is reviewed under CC8.1 baseline configuration.
Policies and the SOC 2 report
The Apache Fineract project does not issue SOC 2 reports, policies or attestations. Security policies, access standards, change procedures and incident response plans must be written, approved and communicated by your organization. Ask your auditor which policies they expect to see, and confirm that the scope of the system description covers the Fineract tenants, the database, the hosting layer and any support providers.
HR onboarding and offboarding
Fineract can record staff, roles and user accounts, but it does not know when an employee joins, changes role or leaves. Joiner, mover and leaver steps happen in your HR and identity processes, and they feed the CC6.3 access decisions. Check that terminations remove access to Fineract, the database, the hosting console and any shared service accounts, and keep dated evidence of each removal.
Vendor and support management
Hosting providers, managed database services, consultants and support vendors that touch the Fineract stack become part of the system under examination. Your organization needs vendor due diligence, contracts that define security and change responsibilities, and records of vendor access. Confirm with your auditor how subservice organizations are described in the system description and whether their own SOC reports must be reviewed.
Backup testing and key management
Backups of the PostgreSQL databases, document storage and configuration are your responsibility, and a backup that has never been restored is weak evidence for availability and processing integrity. Encryption keys for databases, object storage and TLS certificates also need owners, rotation records and a recovery path. Schedule restore tests, record their results, and confirm that key custody is covered by your access reviews.
Events disabled by default
Fineract can publish business events such as ClientCreated to ActiveMQ, other JMS brokers or Apache Kafka, but the README states this is disabled by default. If your monitoring, fraud or reconciliation design depends on those events, you must enable and configure them, then document the setting and the consumers. Without that record, an examiner may find that a processing control depends on data that was never delivered.
Keeping the CC8.1 patch record current on a 1.x release line
The CC8.1 patch record starts with knowing which Fineract release you run and when the project will move beyond it. Official Apache Fineract releases are created quarterly, at the end of each quarter, under the ASF release policy, and end-of-life releases are archived. Fineract CN, the microservices rewrite, was deprecated in May 2023 and archived in late 2023 without an official release, so the 1.x line is the platform to plan around. The current stable release is 1.15.0. Record the version in your baseline configuration inventory, and check the project's published release information on the Apache Fineract site at each quarter end rather than relying on memory or a vendor's summary.
For each release you adopt, document a single upgrade decision record covering the reason for the move, the release notes reviewed, the database migration steps and any configuration or product changes that the release introduces. Attach the test evidence to the same record: the environment tested, the regression scope, the batch and end-of-day job results, and the reviewer's sign-off. Approval should come from someone other than the engineer who performed the upgrade, and the record should show the approval date and the production deployment date. Where a release is applied as an emergency patch, record the emergency justification and the retrospective testing that followed, since CC8.1 expects emergency changes to pass through the same documented steps.
Schedule checks should be recurring and written down. Each quarter, compare the version in production against the latest stable release and the project's end-of-life information, then log whether the gap is accepted, planned or overdue. An auditor reviewing a Type 2 period will look for a consistent pattern of these entries across the whole window, not a single upgrade at the start. Confirm the support window of your current release with the project before you commit to a timeline, because the README does not give a fixed support duration that this page can state.
How DeployOpen prepares a Fineract platform for SOC 2 evidence
DeployOpen plans, implements, hardens and documents self-hosted Apache Fineract inside your own infrastructure, so the access, change, patch and batch-processing controls behind a SOC 2 examination are designed and evidenced before the auditor arrives. We prepare the systems, controls and evidence; independent SOC 2 auditors issue the report.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which Trust Services Criteria categories the examination covers and which Fineract tenants, environments and modules are in the system boundary.
- We map each control owner, role and evidence source to the criteria in scope, and list what your auditor will need to see.
How we build
- We design the Fineract role model, maker-checker approvals and privileged access paths, then test them against documented user scenarios.
- We set up change records, release and patch tracking, and a baseline configuration for the Fineract build, database and hosting layer.
- We configure COB monitoring, accounting mappings and reconciliation checks, and test failure handling and error correction before go-live.
How we hand over
- You receive written control descriptions, runbooks and an evidence calendar that names the owner and recurrence of each artifact.
- We document the system description inputs, including infrastructure, data flows, subservice providers and tenant configuration, for management's review.
- Handover includes a walkthrough with your control owners so each person can explain and produce their evidence.
How we support
- Ongoing support, upgrades and periodic control testing are available as retainers, so evidence keeps pace with Fineract release changes.
- We can review evidence samples before your observation period and help you respond to auditor requests within the agreed scope.
- Questions about the auditor's final opinion, attestation scope or report distribution should go to your SOC 2 auditor, since DeployOpen does not issue reports.
