How open source BPM supports SOX controls over financial processes
If your finance or IT team still routes journal entries, vendor onboarding and access requests through email threads and spreadsheets, the approvals may happen but the evidence that they were authorized, segregated and reviewed rarely holds up under audit. BPMN approval processes in Flowable can enforce segregation of duties and documented authorization in the workflow itself: the engine assigns each step to a role or group, blocks the same person from approving a request they submitted, and records who acted, when and on which version of the process. That moves the control from habit into design, which is what the auditing framework looks for. The catch is that the engine then becomes part of the financial reporting environment. Under PCAOB AS 2110, IT personnel with privileges beyond their duties and unauthorized changes to systems or programs are both listed as IT risks to internal control over financial reporting, and a process engine that enforces approvals is exposed to exactly those risks.
Under PCAOB AS 2201, an automated control that depends on the engine can be relied on without annual retesting only when the general controls over program changes are effective, so the engine's own IT general controls (ITGCs) become a condition for the approval controls working at all. The SEC's Release 33-8810 is practical on scope: management evaluates only the ITGCs needed for the proper and consistent operation of controls that address financial reporting risks, and it names program changes and access to programs and data among the areas to consider. For a Flowable deployment, that points to change approval and testing before any BPMN model reaches production, and to restricting who can deploy definitions, assign roles and alter running instances. Confirm with your external auditor which process and application controls they will rely on before you design the evidence, because the ITGC scope depends on your facts and the controls they test.
Plan the scope early, while the process is still being modeled. Identify which approval steps are key controls, document which roles can start, approve, reassign and administer each process, and decide where the identity source comes from, since Flowable's identity management can be replaced with a custom service or an LDAP implementation. Then define the change path for model versions: who approves a new BPMN definition, what test evidence is retained, and how deployment is logged in your change management system. Ask your implementation partner to show how segregation rules are tested in a non-production environment, and how the production audit history is exported for the auditor. Those decisions shape both the design deficiency and operating deficiency analysis under AS 2201 and the effort required to keep the engine in scope.
Mapping SOX ITGC and ICFR requirements to BPM functions
This table maps the IT risks and deficiency definitions that auditors apply under PCAOB standards to the BPM functions that address them and the Flowable configuration that supports each one. Read each row as a control objective, the process behavior it requires, and the setting an assessor will ask to see. Most gaps sit in identity wiring, deployment approval and history retention, so confirm those first with your auditors.
| Requirement | What the BPM function must do | How to configure Flowable and what evidence to keep |
|---|---|---|
| Privileged access beyond duties (AS 2110, B4) | Ensure no one who starts an approval can also approve it, and that engine administrators cannot act as process participants | Connect Flowable identity handling to the corporate directory through a custom IdmIdentityService, map groups to candidate groups, and keep admin roles separate from business roles; export group membership at each review |
| Unauthorized changes to systems or programs (AS 2110, B4) | Allow only approved BPMN models and decision tables into production, with each deployment traceable to a change ticket | Store BPMN and DMN files in version control, deploy through a pipeline with a reviewer gate, and restrict deployment rights to a change group; retain deployment records and the model diff |
| Inaccurate processing or inaccurate data (AS 2110, B4) | Validate process variables that drive approval limits and routing, and prove that the engine executed the model version intended | Use typed process variables and gateway conditions tested against fixed inputs; keep history tables enabled so each instance records the model version, variable values and task completions |
| Design deficiency (AS 2201, A3) | Define a control for every approval step, including the missing-approver and escalation paths, so no step lacks a designed check | Document each approval step as a control with owner, threshold and expected outcome; model escalation as explicit boundary timers rather than manual workarounds |
| Operating deficiency (AS 2201, A3) | Ensure approvals are performed by people with the authority the policy requires, and that the process runs as designed in practice | Compare task completion history against the delegation matrix each period; review instances that completed through administrative or manual intervention |
| Reliance on program change controls (AS 2201, B29) | Demonstrate that the approval logic has not changed during the year, so that automated checks can be relied on without retesting each instance | Keep a dated register of deployed definition versions with approver sign-off; use the version identifiers in history to show which logic decided each case |
| SEC Release 33-8810 ITGC areas: program changes, access and computer operations | Scope the ITGCs to the controls that address financial reporting risks, covering change, access to programs and data, and job operation | Separate development, test and production environments with different credentials; restrict database and admin access; monitor the async executor and job failures through the actuator endpoint |
| COSO Principle 11 (technology general controls) | Select and maintain general control activities over the engine that support the control objectives of each approval process | Document the control set for the engine itself, assign owners, and perform periodic reviews of access, changes and job health, with results retained as evidence |
Which open-source engines fit a SOX-scoped process layer
The engine you pick decides which access, change and licensing controls you must design and evidence before the first approval flow goes live. The three options below differ on license terms for production, default security posture and how much of the control set falls to your team. Compare them against the controls your auditors will test.
Flowable as the Apache-2.0 engine
Flowable provides BPMN, CMMN and DMN engines under Apache-2.0 with Java and REST APIs, so production use does not depend on a commercial license. Because you own the deployment, the controls around the engine (access to the process definitions, deployment pipeline, database access) sit in your scope. Confirm the database you will run against, since the configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and note the MySQL precision caveat for versions below 5.6.4. The Flowable 8.0.0 release on February 27, 2026 is the current major line, so document which version your change process approved.
Camunda 8 and the license limit
Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. For a SOX-scoped approval layer, that means a production license must be in place before any control runs on it, and the license becomes a contract item your procurement and legal teams must track. Ask the vendor to confirm in writing which components fall under the license and whether your deployment model is covered. Treat the license check as a precondition of the change approval process, not a later procurement task.
Temporal and the default authorizer
The Temporal server is MIT licensed, but self-hosted Temporal uses a noopAuthorizer by default, which allows every API request with no authentication or access control. That default fails the access control expected for approval workflows, so you must configure a ClaimMapper and an Authorizer, enable mTLS, and set OIDC single sign-on for the Web UI before go-live. Temporal is also a code-first durable execution engine rather than a BPMN modeling tool, so the approval logic will be in workflow code that needs its own change control. Confirm how your auditors will evidence the namespace role mappings.
Why the engine changes the control set
The engine determines where the access and change controls live. An engine that requires you to build identity integration, as the Flowable identity service does through its replaceable identity interface, moves authorization evidence into your own code and configuration. A managed or licensed platform may supply some of these controls but still requires you to document how it is configured and who administers it. For each candidate, list which controls are inherited from the product, which are configured by you, and which are operated by your team, and make that list part of the selection record.
Operating the engine after go-live
Whichever engine you choose, its upgrades and patches become changes that must be tested and approved before they reach production. Temporal documents that it should be upgraded one minor version at a time and that schema upgrades must run before server upgrades when release notes call for them. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, and 8.0.0 moved to Spring Boot 4 without backward compatibility for Spring Boot 3, so an upgrade can break compatibility across your own applications. Ask each candidate for its upgrade and deprecation policy and plan a test environment that mirrors production.
Evidence auditors request from the approval workflow and the engine
This table lists the evidence an auditor is likely to ask for, the component that produces it, and what to confirm with the auditor before the test starts. Read it as a checklist: each row names the source system and the question to settle early, so evidence is captured by design rather than rebuilt at year end.
| Evidence | Produced by | What to confirm with the auditor |
|---|---|---|
| Approval history per process instance | Flowable history tables, read through the Java or REST API, exported on a schedule | Which history level is retained, how long records are kept, and whether the auditor samples by instance, by period or by approver |
| Role and identity assignments | Identity service (the IdmIdentityService implementation, such as an LDAP-backed service), synced from the directory | Whether the auditor expects a point-in-time extract of candidate groups for each approval task, and how changes to group membership are dated |
| Model version and deployment records | Deployment repository in Flowable, plus the change ticket that released each BPMN or DMN version | Which version was live on each transaction date, and whether running instances stayed on the prior version after deployment |
| Change tickets and test sign-offs for BPMN changes | Change management tooling linked to the Git commit and the deployed model ID | Whether the approver of the model change must differ from the author, and what test evidence must be attached before production |
| Access review records for engine administrators | Directory group exports, database and admin console access logs, and periodic review sign-offs | The review frequency, the reviewer, and whether administrators who can edit models are separated from those who approve business transactions |
| Database and history backups with restore tests | Backup tooling on the Flowable database (PostgreSQL, Oracle, SQL Server or other supported type) and restore test reports | Whether the auditor wants a restore test in the audit period, and how backups of history tables are protected from change |
| Async job and lock monitoring output | Flowable async executor metrics and the actuator endpoint at /actuator/flowable, collected into your monitoring stack | Which failure conditions must be alerted and reviewed, such as stuck jobs or expired locks, and how those alerts are documented as resolved |
Splitting ITGC scope between the workflow and the engine
The process owner decides what the approval workflow must enforce. In a Flowable deployment, that means the BPMN model, the rules that route a request to an approver, the segregation of duties matrix that says which roles may initiate, approve and release a transaction, and the rules for delegation during absence. The model is a control design, so changes to it are changes to a financial control and should go through the same approval as any other control change. The owner does not need to write Java, but must be able to read the model and sign off on it.
- Approval rules: Document each approval step, its threshold, and the role or group allowed to act, mapped to the control objective it serves.
- SoD matrix: Keep a current matrix of incompatible duties and confirm the BPMN model prevents the same user from initiating and approving the same item.
- Delegation: Define who may delegate, for how long, and which delegations need a second approval. Record each delegation as evidence.
- Model versions: Keep the approved version of each BPMN process with its approval date, so a running instance can be tied to the rules in force when it started.
- Test scripts: Maintain walkthrough and exception test cases, such as a self-approval attempt, and retain the results.
Before relying on the workflow, confirm with the process owner that the matrix in the model matches the matrix the auditors were given.
The IT and application team runs the engine and the platform underneath it. Its scope covers how users authenticate, how the engine is deployed and promoted between environments, how the database and async executor are operated, and who has administrative access to the running system. Flowable's identity service can be replaced with an LDAP or directory-backed implementation, so the link between the enterprise directory and workflow roles is a design decision this team must document and test.
- Identity integration: Document how groups from the directory map to workflow candidate groups, and how leavers and role changes are removed from the engine.
- Deployment pipeline: Keep version-controlled builds, automated tests and an approval step before any model or code reaches production.
- Environments: Maintain separate development, test and production environments, with production data and admin credentials restricted to named personnel.
- Administrative access: Limit database and engine admin rights, and record privileged sessions so that no one can alter a running process without a trace.
- Upgrade records: Keep change tickets for engine upgrades, including the release notes reviewed and the test results.
Confirm with the IT team which environment a model reaches first and whether any person can deploy a model directly to production.
Security and internal audit do not operate the workflow. They test whether the controls the other two layers claim to operate actually do. Their questions are whether access reviews happen on schedule, whether logs of approvals and model deployments are complete and protected from change, and whether each production change can be traced to an approved request and a passing test. Under the SEC's guidance, management evaluates only the IT general controls that support other controls over financial reporting, so the scope here should follow the financial processes the workflow touches.
- Access reviews: Review workflow roles, engine admin accounts and directory group membership on a defined cycle, and keep signed review records.
- Logging: Confirm that task completions, claims, reassignments and deployments are logged, and that logs are stored outside the administrators' reach.
- Change evidence: Match each production deployment to a change ticket, an approval and a test record, and sample them periodically.
- Operating tests: Use inquiry, observation, inspection and re-performance to test that approvals behave as the model says.
- Gaps: Track deficiencies in a register with owners and remediation dates.
Ask internal audit which controls auditors will rely on, because that determines which evidence must be kept for the whole period under review.
How change approval and testing before production apply to the engine
The process engine is itself part of the control environment, and the changes that alter how an approval runs are program changes. A BPMN model that routes a payment approval, a DMN table that sets approval limits, and an engine configuration that changes timers, identity mapping or the database connection all affect whether a control operates as designed. SEC Release 33-8810 names program changes and access to programs and data as IT general control areas management might consider, so the team should treat each of these artifacts as in scope. PCAOB AS 2201, paragraph B29, makes effective general controls over program changes the condition for relying on an automated control without retesting it each year, so the strength of the promotion path directly determines how much testing the control needs. Confirm with your external auditor which artifacts they expect to see in the change population before the first release.
A workable promotion path has separate development, test and production environments, each with its own database, identity source and credentials. Developers change models only in development. A different person reviews every model, decision table and configuration diff before it is merged, and the reviewer cannot be the author or someone with production deployment rights. Test runs against representative data are recorded with the model version, input set, expected outcomes and the tester's sign-off, and the same version identifier must be what gets deployed. Keep the approval of the change ticket, the review record and the test evidence linked to one deployment record so an auditor can follow a single change from request to production in one pass.
Production use of Camunda 8 is a licensing question before it is a technical one. The Camunda License 1.0 that covers Camunda 8 source code permits use only in non-production environments without a commercial license, so a team that picks Camunda 8 for a SOX-relevant approval flow must obtain and document the production license before go-live. Flowable is licensed under Apache-2.0, which carries no such restriction, but the team should still record the version it deploys, which for Flowable is the 8.0.0 line published on February 27, 2026 in the flowable-engine repository. Ask the vendor or partner to show the license terms in writing and file them with the change package for the go-live release.
What tooling alone does not satisfy
A BPM engine enforces the steps it is given, but it cannot decide who should hold which role, who may change a running process, or what the controls are meant to be. The cards below cover the gaps that sit around the engine and must be closed with people, policy and agreed scope before the workflow can serve as control evidence.
Identity provider that reflects real roles
Flowable assigns tasks to users and groups that come from an identity source. If the directory still carries old group memberships, shared accounts or leavers, the approval step will look correct in the audit trail while the approver had no authority to act. Flowable's identity service can be replaced or backed by LDAP, so the design question is which directory is authoritative and how group membership is reviewed. Check that role assignments are recertified on a schedule and that leavers lose task access the same day their account is disabled.
Administrators who can alter running instances
Engine administrators can often move tokens, reassign tasks, or change variables on instances already in flight. Any of these actions can bypass an approval without a trace in the business process history. Map which accounts hold administrative rights on the database, the engine REST API and the deployment pipeline, and restrict them to a named group with logged, approved use. Confirm with the auditor whether administrative actions on live instances are in scope for the access and change controls.
No documented segregation of duties matrix
A BPMN model can route a request to two different people, but it cannot tell whether the same person requested, approved and released a payment. A segregation of duties matrix lists the incompatible combinations of roles across the process, including developers who deploy models, process owners who approve changes and operators who run production. Without that matrix written and signed by the process owner, there is no baseline against which the workflow design or the engine's access settings can be tested.
Manual steps outside the workflow
Controls often depend on steps that happen in email, spreadsheets or a phone call before a case enters the engine, or after it leaves. If a reconciliation or a manual override sits outside the model, the engine's evidence covers only part of the control. Inventory every manual step that supports a financial reporting assertion, record who performs it and where its evidence is kept, and decide whether it moves into a human task in the workflow or remains a documented manual control with its own testing.
ITGC scope agreed with the auditor
No SEC rule or PCAOB standard publishes a catalog of IT general controls. SEC Release 33-8810 says the relevant areas vary with each company's facts and circumstances, and management need only evaluate the general controls that support other controls addressing financial reporting risks. The practical step is to agree in writing with the external auditor which applications, environments and control areas are in scope before design work starts, because the scope determines the evidence the engine must produce.
Readiness work, not audit opinions
DeployOpen plans and implements the workflow, prepares the access reviews, change records, test scripts and evidence packs, and documents the controls for review. It does not issue audit reports, attestations or certifications. Management remains responsible for its ICFR assessment, and the external auditor forms the opinion under the applicable PCAOB standards. Confirm the evidence format and sampling approach with your auditor before the first test cycle.
What do SOX BPM controls cost and require from our team?
What drives the cost of running SOX controls in a BPM engine?
The cost is driven mainly by how many processes carry financial reporting controls, how much identity integration is needed, how far the IT general control scope is agreed with auditors, and whether existing workflow tools must be migrated. Each process needs its approval paths modeled, tested and documented, and each control needs evidence that it operated. Flowable's Apache-2.0 engine carries no license fee, so the main costs are people and infrastructure: modeling, task interfaces, integration with the identity provider and ERP, environment setup, testing and the ongoing change process. Ask any partner for a quote that lists these components separately, with one-time work (build, migration, initial testing) shown apart from recurring work (upgrades, control testing, support).
Can our internal team run SOX-relevant BPM controls without a partner?
Some organizations can, if they already operate Java platforms, have engineers who understand BPMN and an internal change process that auditors have accepted. The gaps usually appear in three places: designing approval logic that enforces segregation of duties, building the program change and testing evidence that auditors will inspect, and keeping the engine upgraded on a supported path. Assess these honestly against your team's capacity. A partner can supply the implementation and documentation, but control ownership, approval authority and the final judgment on control design stay with your management and auditors.
What does the work require from finance and IT?
Finance must define the approval matrix: which transactions need which approvers, thresholds, and which roles must never hold conflicting permissions. Finance also owns the control objectives and reviews the evidence. IT must provide the identity provider integration, environments, database and network access, and must own access reviews for the engine's administrators. Both teams should agree early on who approves changes to process models, since that approval is itself a control. Without named owners on both sides, the design phase tends to stall, so confirm these roles in writing before the scope is signed.
Does SOX Section 404 attestation apply to our company?
Section 404 applies to SEC-registered issuers, and whether an auditor must attest to management's assessment depends on filer status. Under 15 U.S.C. 7262, management's annual assessment of internal control over financial reporting applies to all covered issuers, while the auditor attestation applies to accelerated and large accelerated filers that are not emerging growth companies. Your general counsel, controller or external auditor should confirm your filer category, since the answer determines how much external testing your controls must withstand. Private companies may follow SOX-aligned practices voluntarily, but they are not bound by the statute.
What did the SEC's 2020 estimate cover for newly exempt issuers?
The SEC estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, made up of roughly $110,000 in audit fees and $100,000 in other costs (Release 34-88365). The figure reflects the change in filer status, not the cost of building a BPM control environment, so it should not be used to size an implementation budget. Use it only to understand the economics of attestation when deciding how much external assurance your organization needs. Confirm the current rules with your advisers, because filer definitions and thresholds can change.
How long does a SOX-scoped BPM implementation take?
No duration can be stated responsibly without a defined process inventory, identity landscape and control list. The main variables are the number of controlled processes, whether approval logic must be migrated from an existing tool, how many systems the workflow must call, and how much evidence auditors expect at the start. A written scope should give phases, dependencies on your change calendar, and the points where auditors or control owners must review. Ask for a plan that separates design, build, control testing and go-live, and treat any timeline offered before the process inventory is complete as provisional.
What should we ask a partner before signing a fixed-scope agreement?
Ask which processes and controls are in scope, which ITGCs the partner will document and which remain with your team, and how change approval and testing evidence will be produced before production. Request the list of deliverables, the acceptance criteria for each, the responsibilities of your finance and IT owners, and the process for handling change requests after signature. Confirm how the engine will be upgraded and what support is included or offered as a retainer. DeployOpen works on fixed-scope agreements where scope, deliverables and timelines are agreed in writing before work starts, so ask any partner to show that structure in the proposal.
How DeployOpen scopes and delivers SOX-ready BPM
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Flowable process engines. For SOX-relevant approval processes, we tie each process step to a documented control objective, then prepare the engine, its change path and its evidence so that management and external auditors can test them.
How we scope
- Written scope lists the approval processes in SOX scope and the control objective each step supports.
- Scope names the systems that feed approvals, such as identity directories, ERP or ticketing, and who owns each integration.
- Scope states which roles may start, approve and administer processes, and which ones must stay separate.
How we build
- We model approval BPMN with role-based user tasks, documented authorization rules and an audit trail of each decision.
- We test segregation of duties with positive and negative cases, including attempts by administrators to approve their own requests.
- We set up a change path where process definitions are version-controlled, reviewed and tested in non-production before release.
How we hand over
- Handover includes process models, configuration, access matrices and the test scripts and results for each control.
- Runbooks cover deployment, process version rollout, running instance handling and the production change approval steps.
- Evidence templates define what is retained for each change, approval and test run, and where it is stored.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover regression testing of approval flows before each Flowable upgrade or platform patch.
- Confirm with us in writing which evidence and reviews remain the client's responsibility, since auditors issue all opinions.
