Can Flowable approval workflows support SOX IT general controls?
Flowable can route and record approvals that serve as evidence for change and access controls, but it does not design the control, assign segregation of duties or issue an audit opinion. Those decisions belong to management and the external auditor. A finance or IT team that must show management approved program and access changes before they reached production needs to separate what a workflow engine can prove from what the control design must still establish. SEC Release 33-8810 explains that management evaluates the IT general controls needed for other controls that address financial reporting risks, and it names program changes and access to programs and data as example areas. PCAOB AS 2201 makes effective general controls over program changes a condition for relying on benchmarked automated controls, and AS 2110 lists unauthorized changes to systems and privileged IT personnel as IT risks the auditor assesses.
The platform covers only part of that picture. A Flowable BPMN process can hold a change request, route it to an approver group, block self-approval through an expression or listener you write, and store each task completion with its user and timestamp in history. Those records support the inspection and re-performance steps described in AS 2201, paragraph 45. The engine does not know who holds production deploy rights, whether the approver's role is appropriate, or whether the change reached production through a path that bypassed the workflow. Confirm with your auditor which change and access populations they will sample, and confirm which IT general controls sit outside Flowable, such as the deployment pipeline, directory access and privileged account management.
Before building, decide three things with your control owner: which approval steps are key controls, who is authorized to approve each step, and how the workflow record will be linked to the ticket and deployment record that auditors will also inspect. Flowable's authorization checks are left to your application, so the segregation rule must be enforced in your code and identity integration, then tested. Plan the evidence package early so that retention and history settings match the period auditors will review, and so that a design deficiency or an operating deficiency, as AS 2201 defines them, is caught by your own testing before the auditor finds it.
Which SOX requirements map to Flowable capabilities and configuration
This table maps each SOX-relevant requirement to the Flowable capability that supports it, the configuration that makes the evidence usable, and the point to settle with your auditor. Read each row as a question to answer before go-live, not as a claim that Flowable satisfies the requirement on its own.
| Requirement | Flowable capability | Configuration to confirm | Confirm with your auditor |
|---|---|---|---|
| Program changes (SEC Release 33-8810 area) | User tasks with candidate groups route each change request to a named approval group before deployment is released | Separate candidate groups for requesters, technical approvers and change managers; history level set to retain task and variable events | Whether the approval gate is the control they will test and what sample of change tickets they expect |
| Access to programs and data (SEC Release 33-8810 area) | Approval tasks for access grants and removals, with the requester, approver and completion time recorded in history | Authenticated completer required on task completion; identity source set to your directory, not default accounts | Which systems and roles are in scope and whether access reviews are a separate control |
| Unauthorized changes to systems or programs (AS 2110, paragraph B4) | Workflow records show whether a change followed its approval path, and the engine rejects completions outside assigned candidates | Process definitions deployed only through your change pipeline; deployment history retained alongside process versions | How they will test that workflow definitions themselves were changed under control |
| Privileged IT personnel breaking segregation of duties (AS 2110, paragraph B4) | Identity service replacement lets you map roles so a person who requested a change cannot also approve it | Custom IdmIdentityService or LDAP-backed identity source; exclusion rules preventing requester and approver from being the same user | How they will test conflicting roles and whether administrators can bypass the workflow |
| Design and operating deficiencies (AS 2201, paragraph A3) | A missing approval step is a design gap; an approval completed by someone without authority is an operating gap | Candidate group membership reviewed against your authority matrix; history showing who completed each task | How they classify a completion by a person outside the intended group and what remediation evidence they need |
| Operating effectiveness tests (AS 2201, paragraph 45) | History tables let an auditor inspect approvals, re-perform the routing logic and observe the queue of pending tasks | Retained history for the full review period; history export or read-only reporting access for auditors | Which samples they will select, the period covered and whether they will re-perform the workflow in a test environment |
How a change approval process is modeled in Flowable
A change approval in Flowable is a BPMN process in which each decision point is a user task assigned to a candidate group or a named assignee, with exclusive gateways routing the instance based on the reviewer's outcome. A typical model has a requester task that submits the change ticket or access request, a reviewer task for the technical owner, an approver task for the business owner or change board, and a deployer step that releases the change only after approval. Each task records who completed it and when, which is the raw material for the who-approved-what evidence auditors sample. Map each candidate group to a role in your identity source, not to an informal list, so the approval path reflects who was actually authorized at the time. Confirm with your Flowable version's documentation how candidate groups and identity links are stored in history before you rely on them as evidence.
The engine does not enforce segregation of duties on its own. Flowable's authorization checks for task claiming and completion are left to your application, so the rule that the requester, the approver and the deployer must be different people has to be enforced in the application layer and in the identity data it reads. In practice, this means your code rejects completion of a task by the user who started the instance or who completed an earlier step, and your deployment pipeline checks the approver identity recorded in history before promoting a process definition or change. Write these rules as explicit test cases, including the case where one person holds two roles through group membership. Decide in advance who may override a rule, and make that override a separate, logged step.
Flowable's identity service can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP implementation is provided as a reference. Connecting the engine to the same directory your access reviews use means group memberships behind candidate groups come from one authoritative source, so a user removed from an approver group in the directory cannot be assigned new approval tasks by the engine. Confirm with your team how group changes propagate to tasks that are already open, since assignments made earlier stay on the task unless your application reassigns them. Ask whether your directory keeps the history of group changes, because an auditor testing a past approval will need to know who held the approver role on that date, not only today.
What evidence the workflow produces and how to keep it
A Flowable approval workflow leaves several distinct records, and an auditor will want each one to tie back to the change it approved. The cards below cover the history an auditor samples, the variables that carry the change identifier, deployment records, retention, protection from change, and the link from a Flowable instance to the change ticket.
Approval task history
Process instance history records which user completed each approval task and when. For SOX change approvals, check that each approval task requires an authenticated user, that the approver identity is captured on completion, and that the approver is not the requester who raised the change. Pull a sample of completed tasks from the history tables and confirm each one shows a distinct approver with the expected timestamp.
Change identifier and risk variables
Process variables should hold the change ticket number, the requested change type and the risk rating used to route the approval. These values are what an auditor compares against the ticket in the change management system. Confirm which variables are written to history at the level you configure, and decide whether the risk rating is set by the requester, a rule or a reviewer, since that choice determines what evidence the variable provides.
Process definition deployment records
Each approval routing rule runs from a deployed process definition. Keep the deployment record, the definition key and version, and the source BPMN file in version control so you can show which routing logic was active on the date of a given approval. Changes to approval logic are themselves changes subject to ITGC, so the deployment history should show who deployed each version and when it was approved.
Exported history for audit packs
Auditors often want history in a format they can filter and sort, so plan a scheduled export of completed instances, task completions and variables for each audit period. Store exports with a hash or checksum and record the query used to produce them. Exports are copies, so the source history must still be retained and protected for the full period the auditor may select.
Retention and protection from change
Retention periods for history and exports should match the period your auditors need to test, and the deletion job that cleans history must be tested before it runs in production. Restrict the Flowable schema to the application service account, remove delete and update rights on history tables from operators and developers, and log administrative access to the database. Confirm history level, cleanup settings and retention behavior against the Flowable configuration docs for your chosen database before relying on them.
Linking instance IDs to change tickets
Store the Flowable process instance ID in the change ticket when the approval starts, and store the change ticket number as a process variable so the link works in both directions. Auditors will sample a ticket and expect to find the instance, and sample an instance and expect to find the ticket. Test the link with a few illustrative changes before the first audit period, and document who owns the mapping and how it is kept consistent if a ticket is reopened or cancelled.
How auditors sample workflow records and what they test
Auditors test whether approvals in the Flowable workflow actually operated, not just whether the workflow exists. Under PCAOB AS 2201 paragraph 45, testing of operating effectiveness combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For a Flowable change approval control, the auditor typically selects a sample of production changes in the period, then traces each one from the change ticket to the Flowable process instance that carried its approval steps, to the deployment record for the approved change, and finally to the production change itself. Confirm before the audit that every link in that chain can be produced on request: the ticket ID stored as a process variable, the instance ID recorded in the ticket, the completed user tasks with their assignees and completion times from the history tables, and the deployment identifier that matches the approved definition version.
Operating deficiencies are the failures auditors look for in that sample. Under AS 2201 paragraph A3, an operating deficiency exists when a control does not operate as designed or is performed by someone without the needed authority or competence. An approval completed by a person outside the approver group defined for that change is therefore an operating deficiency, even though the workflow recorded it faithfully. The record shows who approved, but it does not show whether that person was entitled to approve. Expect the auditor to compare each approver against the authorization list in your identity provider or in the group assignments in the process model, and to ask how that list was reviewed during the period.
This is also where design and access questions meet. Flowable records the completed task and the user who completed it, but the engine does not decide who may complete it unless your application enforces that rule. Candidate-user and candidate-group assignments, and any checks in your application code or listeners before a task completes, are what prevent the wrong person from approving. Segregation of duties needs the same enforcement: a developer who submitted a change must not be able to complete its own approval task. Test this directly with a negative case, attempting the approval under an unauthorized account in a non-production environment, and keep that test result as evidence alongside the production sample.
What Flowable does not cover for SOX ITGCs
Flowable can record and enforce approval steps, but the SOX control environment is larger than any workflow engine. The cards below cover the decisions and controls that sit outside Flowable and that auditors will test alongside the workflow records.
ICFR scope decision
Under SEC Release 33-8810, management evaluates only the IT general controls needed for the proper and consistent operation of controls that address financial reporting risks. Whether a Flowable change or access approval falls in scope depends on the company's own facts, so the scoping memo should name the applications and approvals that feed financial reporting. Ask your auditor to review that scope before the workflow design is locked.
No published SOX control catalog
No SEC rule or PCAOB standard publishes a catalog of IT general controls, and Flowable does not publish one for SOX either. The control design, its owner, its frequency and its evidence must be written by your team and agreed with the external auditor. Treat any template that claims to be a complete SOX control list as a starting point to validate, not an authority.
Program change controls outside Flowable
A Flowable approval proves that someone authorized a change, but the deployed code, process definitions and configuration still move through your source control and release pipeline. Auditors will ask whether the approved version is the version that reached production. Compare the approval record against deployment logs and check that process definitions cannot be redeployed without passing through the same gate.
Privileged access to databases and servers
Anyone with direct database rights can change history tables, approval variables or task assignments without going through the engine. The supplied facts do not state how the Flowable admin console or history tables are protected by default, so confirm this with the vendor and your own configuration. Restrict database and host administrators, log their sessions, and review who holds those rights.
Periodic access recertification
The approver list in Flowable is only as good as the identity source behind it. Identity management can be replaced by a custom identity service, so the group memberships that drive segregation of duties must come from a governed directory. Recertify who holds approver and admin roles on a set schedule and remove access that no longer matches the role.
Computer operations and the auditor's conclusions
Computer operations controls, such as job scheduling, backups and incident handling, support the reliance on workflow records, and they are separate from the approval design. The auditor forms the final conclusion on operating effectiveness through inquiry, observation, inspection and re-performance under PCAOB AS 2201. Plan for those tests to read your evidence directly rather than relying on a summary from the workflow team.
Configuration sequence for change and access approvals
This sequence turns SOX change and access approvals into a Flowable process that assigns approvers by role, blocks self-approval, records who acted and when, and keeps history that an auditor can sample. Each step ends with an output that the control owner and the auditor can inspect.
Confirm ICFR scope with the auditor
Before any model is drawn, the finance controller, the IT control owner and the external auditor agree which systems and change or access processes affect internal control over financial reporting. The SEC guidance in Release 33-8810 limits management's IT general control evaluation to controls needed for the proper and consistent operation of other financial reporting controls, so operational-only workflows can be left out. The output is a written scope note listing in-scope applications, the control objectives each approval supports, and the auditor's stated sampling expectations. Ask the auditor which evidence they will inspect and how they expect re-performance to work, since PCAOB AS 2201 tests operating effectiveness through inquiry, observation, inspection and re-performance.
Design the approval matrix and segregation rules
The control owner and the change advisory board write a matrix that maps each change type and access request to a requester role, one or more approver roles, and an implementer role. The matrix states which combinations are forbidden, such as a developer approving their own change, a requester approving an access grant to themselves, or one person holding both deployment and approval rights. PCAOB AS 2110 lists IT personnel with privileges beyond their duties as a risk that breaks segregation of duties, so the matrix should name who may hold each privilege. The output is an approved matrix with a version number, signed by the control owner, that the workflow design will implement.
Connect the identity source
Connect Flowable's identity handling to the directory that the organization already trusts for joiners, movers and leavers. The Flowable docs say identity management can be replaced by implementing the IdmIdentityService interface, and an LDAP reference implementation is provided. Map directory groups to the roles in the matrix, and confirm that a user removed from a role in the directory also loses approval rights in the engine. The output is a test run in which a sample user from each role can log in, is listed in the right candidate group, and cannot see tasks outside that group. Document how the identity mapping is maintained, because the auditor will ask how approver lists are kept current.
Model the BPMN approval process with candidate groups
Model each approval as an executable BPMN process with user tasks assigned to candidate groups that match the matrix, not to named individuals where a role is intended. Add an exclusive gateway or expression that compares the requester identifier with the approver identifier and routes any match to a rejection or escalation path. Record the change or access request identifier, the requester, the approver decision and the justification as process variables so they appear in history. The output is a deployed process definition and a unit test suite that proves the self-approval route, the rejection route and the normal approval route all behave as the matrix requires.
Set history level and retention on the chosen database
Choose the history level that captures task completion, the authenticated user and variable changes, then set the retention policy in line with the record retention period the auditor and legal team specify. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, which matters when sequencing approval timestamps. Restrict database write and delete rights on history tables to a service account that the change process does not use. The output is a configuration record listing the history level, the database version, the retention setting, and the account permissions, verified by a query that returns completed approvals with timestamps.
Link instance IDs to the ticketing system
Store the Flowable process instance identifier in the ticket record of the change management or access system, and store the ticket key as a business key on the process instance. This two-way link lets an auditor start from a ticket and reach the workflow history, or start from a workflow record and find the ticket, approvals and implementation evidence. Confirm that ticket edits made after approval are logged so that a change to a closed ticket does not appear as an unrecorded modification. The output is a sample set of linked records in which each ticket resolves to exactly one process instance and each instance resolves back to its ticket.
Test a sample of approvals end to end
Run end-to-end tests across the matrix with the control owner and internal audit present. Cover normal approvals, rejections, escalations, self-approval attempts, approver removal from the directory, and a change deployed without a matching approval record. Compare each workflow record with the ticket and the deployment log, and re-perform one approval from start to finish using the audit history alone. The output is a signed test script with expected and actual results for every case, and a list of exceptions with their remediation owners. Retain the test evidence with the design documents so the auditor can inspect the same records the team relied on.
Document procedures for periodic review of history
Write the procedure that tells the control owner how often and how the approval history is reviewed, who performs the review, what they compare it against, and how exceptions are escalated and closed. The procedure should cover checks for approvals without a linked ticket, tasks completed by users outside their candidate group, self-approval attempts, and history rows that were modified or deleted outside the retention schedule. Assign the review to someone who does not hold approval rights. The output is an approved procedure with a review log template, and a first completed review record that shows the procedure works in practice.
Questions teams ask before using Flowable for SOX approvals
Does a Flowable approval workflow satisfy SOX on its own?
No. A Flowable approval workflow supports SOX evidence but does not satisfy Section 404 by itself. Management must still design and operate the change and access controls, and the workflow is one part of that design. Section 404 requires management's annual assessment of internal control over financial reporting, and the auditor's testing covers the whole control, including who is allowed to approve, how changes reach production and whether the records can be trusted. A workflow that records approvals cleanly still fails if approvers lack authority or the same person can request and approve a change. Treat Flowable as the mechanism that produces consistent, sampleable records for a control your organization has designed.
What must our team do itself, and what can a partner do?
Your team owns the control design and the decisions behind it. That includes which change types need approval, who holds each approval role, what counts as segregation of duties in your environment, and how long evidence is retained. A partner can plan, build and document the Flowable process models, connect them to your identity source and ticketing system, configure history and retention, and prepare sample-ready reports. Your internal team should confirm the design with its auditors before build begins, since an external auditor's view of the control is what matters for the assessment. Agree in writing which tasks belong to each party before work starts, because most engagements are fixed-scope.
What drives the effort on a SOX approval workflow?
Four factors drive most of the effort. The first is identity integration: how approvers and requesters are sourced, and whether group membership reflects current roles. The second is the number of change types, since each type can carry its own approval path, evidence fields and exceptions. The third is audit history design, meaning which events are recorded, what each record contains and how it is protected from change. The fourth is sampling readiness, which covers how an auditor can select a population of workflow records and trace each one to its request, approval and deployment. Each factor grows with the number of systems in scope and the number of exceptions your process allows, so ask for these counts in any quote.
How long does the work take?
The duration depends on the scope agreed in writing, so no general timeline applies. A workflow covering one change type with a single identity source is a narrower piece of work than one covering several change types, multiple ticketing systems and access reviews. Ask for a schedule that lists the milestones, the decisions your team must make, and the points where auditors review the design. Build time is often shorter than the time needed to agree the control design and to test sample evidence with your auditors, so confirm those review windows early.
What do we need to provide to the implementation team?
The work needs four inputs. First, auditor input on the control design and the evidence they expect to sample, ideally in writing. Second, named owners from identity management who can confirm approver roles, group membership and how joiners, movers and leavers are handled. Third, access to the ticketing or change system that originates requests, including a test instance and documentation of its fields and states. Fourth, a decision on who approves changes to the workflow itself, since that change is also a control. Ask the partner to list these inputs in the statement of work so delays are visible before work starts.
Can our internal team run the workflow after handover?
Yes, if the handover includes the operating knowledge and the documentation. Flowable is open source under the Apache 2.0 license, so your team can run the engines in infrastructure you control. Your team will need skills in Java, Spring and the database platform, along with the ability to deploy process definitions and review history. Ask for runbooks covering routine operations, failed jobs, backups and version upgrades. Confirm the Java and Spring baseline of the Flowable version you select with the release notes, because major releases change the platform requirements. Plan who will own the control after handover, including periodic review of approver lists and retention settings.
Which auditor questions should the design answer before build?
Auditors test whether the control operated as designed, so the design should show who can approve, what evidence each approval leaves and how that evidence is kept. Under PCAOB AS 2201, testing combines inquiry, observation, inspection of documentation and re-performance, so the workflow should let an auditor inspect a record and trace it to the change. Under AS 2110, auditors look at unauthorized changes and at personnel with privileges beyond their duties, which is where segregation of duties matters. Confirm with your auditors how they want approvals, rejections and emergency changes represented before you configure history.
How DeployOpen scopes SOX-ready approval workflows
DeployOpen plans, configures and documents the approval workflow and its evidence inside your own infrastructure, then prepares the systems, controls and records that your assessment team will test. That includes the Flowable engine deployment in your cloud accounts or data centers, the BPMN process definitions for change and access requests, the identity source that supplies approver roles, the history configuration that captures who approved what, and the written control narrative your team uses with the auditor. DeployOpen does not issue audit reports, attestations or opinions on ICFR. Management still performs the Section 404 assessment, and the external auditor under PCAOB AS 2201 decides what it tests and what it concludes. Confirm early which of your deliverables your auditor will accept as design and operating evidence, and agree that list before any build starts.
Most engagements are fixed-scope: the written scope, deliverables, acceptance criteria and timelines are agreed before work begins, and any change to them goes through a written change request. For this topic, the scope should name the in-scope process definitions (for example, a production change request and a privileged access request), the approver roles and their segregation rules, the systems that feed or consume approvals, the retention location for history and exports, and the walkthrough and sample-pull procedures you expect to hand over. Ask for a quote that separates one-time build and documentation work from recurring items such as engine patching, history retention jobs and the periodic review of approver rosters. Ongoing support, upgrades and continuous control testing are available as a retainer, which suits the recurring part of this work because approver lists and process versions change every quarter.
How DeployOpen works on this
DeployOpen plans, builds and documents Flowable approval workflows for SOX change and access approvals inside infrastructure you control. Each engagement starts with a written scope that defines the approval paths, the evidence fields and the retention settings auditors will test.
How we scope
- Map each change and access approval type to its Flowable process, roles and required approvers.
- Define segregation of duties rules, including who may request, approve and deploy the same change.
- Agree in writing which history, audit and retention records the approval evidence will rely on.
How we build
- Model approval steps in BPMN and connect role checks to your identity source, such as LDAP or your IdP.
- Write and test delegates that block self-approval and reject completions by users without authority.
- Run test cases that reproduce approve, reject and escalation paths before any production deployment.
How we hand over
- Deliver process definitions, configuration, test evidence and a walkthrough of who-approved-what queries.
- Document the sampling procedure so your internal audit team can pull and re-perform approval records.
- Provide runbooks for deploying process versions and recording the change ticket that authorized each one.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Review approval rules and role mappings when access policies or your SOX control narrative change.
- Plan Flowable version upgrades so approval workflows are retested against the new release before go-live.
