Self-hosted workflow automation for SOX ITGCs

Why SOX ITGCs reach self-hosted workflow automation

Consider a controller whose n8n flow pulls journal entries from a billing system, reconciles them to the general ledger and posts summary balances to a reporting database every night. A Temporal workflow that recalculates accrual schedules may do the same job for a different entity. If either flow changes what ends up in the financial statements, the flow is part of the information technology that supports internal control over financial reporting, and the general controls over program changes, computer operations and access to programs and data apply to it. The short answer is that the automation does not need to be labeled a financial system to fall in scope. Its effect on reported numbers is what counts. No SEC rule or PCAOB standard publishes a catalog of IT general controls. SEC guidance in Release 33-8810 says the aspects of ITGCs relevant to an ICFR evaluation vary with each company's facts and circumstances, and that management only needs to evaluate the controls necessary for the proper and consistent operation of other controls that address financial reporting risks. Scope is therefore a documented judgment that the reader's finance and IT leaders must make and be able to defend. The external auditor tests ICFR under PCAOB AS 2201 and assesses IT risks under AS 2110, which asks for an understanding of the ITGCs important to automated controls. Confirm with your auditor which workflows they consider in scope before you design evidence for them. The practical decision is which flows to classify as financial reporting relevant, and then which environments, roles and change records will prove the controls worked for the full audit period. Ask the implementation partner to produce a written inventory of workflows, their data sources and their ledger touchpoints, so that scope is set from evidence rather than from memory.

Which SOX ITGC requirements a workflow platform must meet

This table maps each supplied SOX-related control concern to what the workflow platform must do and how to configure n8n or Temporal to meet it. Read each row as a question to answer in your own environment, since auditors assess the controls as operated, not the tool alone. The main takeaway is that the platform supports the controls, but change approval, access review and job monitoring remain management's evidence to produce.

Requirement	What the platform must do	Configuration and evidence to expect
Unauthorized program changes (AS 2110, B4)	Prevent workflow edits from reaching production without a recorded approval	Promote workflows through Git branches with pull review; keep environment separation; retain approval records and diffs for each release
Segregation of duties and access beyond job duties (AS 2110, B4)	Limit who can build, approve, deploy and run financial workflows	n8n SAML single sign-on on Business or Enterprise plans with role mapping; Temporal Authorizer plus ClaimMapper mapping JWT or certificate claims to namespace roles; quarterly access review export
Unauthenticated API access in Temporal	Block any request that reaches the frontend without identity and authorization	Replace the default noopAuthorizer, which allows every request, with a custom Authorizer; enable mTLS for frontend and internode traffic; keep services off public networks
Reliance on inaccurate processing (AS 2110, B4)	Ensure transformations produce complete and accurate results and fail visibly	Document retries and error branches; use Temporal durable execution history; reconcile control totals against source system reports
Inappropriate manual intervention (AS 2110, B4)	Make manual reruns, data edits and credential changes traceable	Restrict manual execution rights; log who triggered reruns; review execution logs and any direct database changes to PostgreSQL or workflow data
Effective general controls over computer operations (AS 2201, B29)	Schedule, monitor and alert on jobs so output is complete and timely	Job scheduling records, failure alerts routed to a named owner, execution history retention, and log streaming where the chosen plan includes it
Benchmarking automated controls (AS 2201, B29, B32)	Keep program change controls effective so automated workflow logic can be relied on year over year	Versioned workflow exports, change tickets linked to commits, and evidence that vendor-supplied code was not modified outside the change process
ICFR evaluation (SEC Release 33-8810, Rule 13a-15(c))	Provide management with IT general control evidence for controls over financial reporting	Map each in-scope workflow to the financial reporting risk it supports; confirm the evaluation approach with your external auditor and document the framework used

How n8n and Temporal differ for financial workflows

n8n suits integration-heavy business flows such as moving approved journal extracts, reconciliation files or vendor data between finance systems through a visual canvas. Its identity and change controls depend heavily on the edition you run. Several controls auditors expect are not included in the free Community edition, so the plan decision is a control decision as well as a cost decision.

Edition-gated access controls: According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Without them, user lifecycle and workflow promotion evidence must come from elsewhere.
Enterprise files: Files marked .ee are not covered by the Sustainable Use License and require a valid n8n Enterprise License, so any .ee component in your deployment needs its own license confirmation.
Licensing for internal use: The Sustainable Use License permits use for your own internal business purposes, which fits an in-house finance deployment, but distribution to third parties is restricted.
Execution records: n8n counts an execution as one run of a whole workflow, so execution logs are the main record of what a finance flow processed and must be retained and reviewed.

Confirm with n8n, in writing, which edition, SSO and environment features apply to your tenant before you design the control set.

Open-source platforms that fit SOX-scoped workflows

Each platform below can run scheduled or approved steps that touch financial data, but none of them satisfies SOX ITGCs on its own. The fit depends on how the platform handles access, change approval, scheduling and evidence, and on what the organization builds around it.

n8n for integration flows

n8n suits integration flows between finance systems, but its Sustainable Use License limits use to internal business purposes, so confirm the license fit first. Queue mode splits triggers from workers, and every worker must hold the main instance's encryption key to read stored credentials, so key custody becomes an ITGC question. SSO and Git-based environments for change control sit in the Business and Enterprise plans, so confirm which plan your controls need before design.

Temporal for durable execution

Temporal is MIT licensed and records workflow history, which helps when a payment or ledger step must survive failures and be explained later. Its self-hosted default authorizer allows every API request, so you must configure an Authorizer, mTLS and a ClaimMapper before production. For server 1.30 and later, use Helm chart 0.73.1 or newer, and upgrade one minor version at a time.

Apache Airflow for scheduled batch jobs

Airflow is Apache-2.0 licensed and built to author, schedule and monitor batch jobs, which maps directly to ITGC expectations for job scheduling and failure monitoring. Evidence comes from run histories, retries and alerts, so define who reviews failed runs and how that review is recorded. Airflow does not manage change approval for DAG code, so pair it with a controlled Git promotion process.

Node-RED for edge and integration flows

Node-RED is Apache-2.0 licensed and fits lightweight integration flows that move data between systems close to where it is produced. Its editor is open by default, so restrict who can open it, enable authentication and separate editing rights from runtime access. Confirm how flow changes are approved and retained, since the editor does not provide change control on its own.

Flowable for human approval steps

Flowable is an Apache-2.0 workflow and BPM platform that can model human tasks, such as journal entry approvals or access requests, as explicit process steps. Approval records become evidence that a reviewer acted before a financial change was released. Confirm that approvers cannot also be the requesters, because segregation of duties depends on the process design as well as the tool.

Dagster for asset-based pipelines

Dagster is Apache-2.0 licensed and organizes pipelines around data assets, which makes it easier to show what a reconciliation or ledger feed produced and when. Asset lineage supports review of data transformations, but it does not replace access controls on the warehouse or source systems. Verify how run metadata and logs are retained and who can change asset definitions.

What auditors ask for and which component produces it

This table maps the evidence an external auditor or internal reviewer typically requests for workflow automation under SOX ITGCs to the component that produces it. Read each row as a question to answer before go-live, and confirm retention periods with your auditor, since no supplied fact sets them.

Evidence item	Producing component	What to retain and confirm
Change tickets and approvals for workflow edits	Ticketing system linked to the workflow change process	Approval record per change, approver identity and date; confirm retention period with the auditor
Git history and promotion records	Git server holding exported workflow definitions	Commit history, reviewer sign-off and tagged promotion from test to production; confirm which branches count as evidence
Access reviews for n8n users and Temporal namespace roles	n8n user management (SSO on eligible plans) and Temporal ClaimMapper and Authorizer roles	Periodic review of who holds editor, admin or namespace roles; confirm review frequency with the auditor
Job schedules and run logs	Temporal visibility store or n8n execution history, forwarded to the SIEM	Schedule definitions, run start and end times, outcome per execution; confirm how long execution data must be kept
Failure alerts and retry records	Monitoring stack fed by n8n log streaming on eligible plans or Temporal event history	Alert logs, who acknowledged each alert, retry counts and manual reruns; confirm alert handling expectations
Encryption key custody	Key management process for the n8n encryption key and Temporal payload codec keys	Named key custodians, storage location, rotation and access logs; confirm key custody model with your security team
Retention of execution data	Temporal persistence and visibility stores, n8n database with pruning settings	Documented retention schedule matching the period your auditor and policies require; confirm before configuring pruning

How the change and access path should look in practice

The production path for a workflow edit should be one route that every change follows: a developer builds and tests in a non-production n8n or Temporal environment, the change is committed to Git, a reviewer approves the merge request against a ticket, and promotion to production runs under a service identity rather than a named developer account. Release 33-8810 names program development, program changes, computer operations and access to programs and data as the IT general control areas management may need to evaluate, and this path touches all four. Whether each area applies to a given flow depends on the company's facts, so the mapping from flow to control should be documented and agreed with the company's auditors before the first production promotion.

Segregation of duties is where most of the design effort sits. AS 2110 lists IT personnel gaining access beyond their duties and unauthorized changes to programs as IT risks to internal control over financial reporting. In practice, the developer who writes a flow should not be the person who approves it, and nobody who approves a merge should hold standing write access to the production instance, the n8n encryption key or the Temporal namespace configuration. Confirm with your auditors whether the reviewer role, the promotion pipeline and the Git hosting administrators are separate enough for the flows in scope, and document who holds each role.

Production editing should be restricted to a break-glass role whose every use is logged and reviewed against an incident or ticket after the fact. Temporal's default noopAuthorizer allows every API request with no access control, so the Authorizer and ClaimMapper must be configured before any role model is meaningful, and n8n's role assignments and SSO (available on Business and Enterprise plans) should be checked for the same purpose. Ask your partner to show, for a sample change, the commit, the review, the ticket link, the promotion record and the break-glass log entry if one exists. Those five artifacts are what an auditor will ask to inspect.

How to bring flows into ITGC scope in order

This sequence moves a set of n8n or Temporal flows from unmanaged scripts to controlled, evidenced automation that an auditor can test. Each step produces an artifact that the next step depends on, so the order matters more than the tooling.

Inventory every flow that touches financial data
Engineering and the process owners list each n8n workflow and Temporal workflow that reads, transforms, moves or reports financial data, including scheduled runs, webhooks and the credentials each one uses. Record the owner, the source and target systems, the execution schedule and where execution data is stored. The step is done when the inventory covers every flow on every instance, and when someone outside the build team has checked it against the systems that feed the general ledger and reporting.
Classify flows with finance and internal audit
Finance and internal audit review the inventory and decide which flows affect financial reporting risks and which only affect operational efficiency. SEC guidance says management evaluates only the IT general controls needed for other controls that address financial reporting risks, so this classification sets the scope of every later step. The output is a signed scope register that names in-scope flows, the control objective each one supports and the reviewer who approved the decision.
Lock down authentication and the Temporal Authorizer
Engineering enables single sign-on for the automation platform, restricts administrative roles and removes shared accounts. For n8n, SAML and LDAP are available on the Business and Enterprise plans, so confirm the edition before design. For Temporal, a self-hosted server with no configured Authorizer uses the default noopAuthorizer, which allows every API request, so the team must configure the ClaimMapper and Authorizer, enable mTLS and keep services off the public internet. The step is done when a test account without a granted role is refused on every namespace and API path.
Set up separated environments and Git promotion
Development, test and production instances are created, each with its own credentials and encryption keys. Workflow definitions are stored in Git, and changes move forward only through merge requests that carry a reviewer and a test result. Direct edits in the production editor are disabled or monitored, and the team confirms that no developer account holds standing write access to production. The output is a promotion path where every production version traces to a reviewed commit.
Define the change approval workflow
The organization writes a change procedure that states who requests a workflow change, who reviews the logic and data impact, who approves it, who promotes it and how emergency changes are handled and reviewed afterward. Auditors look for unauthorized program changes as an IT risk, so the procedure must cover both normal and emergency paths. The step is done when a sample change can be followed from request to approval to production deployment using the ticket, the merge request and the deployment record.
Enable job monitoring and failure alerts
Operations configures run monitoring for every in-scope schedule, including failed, delayed and missed executions, and routes alerts to a named on-call group. For n8n, the team confirms whether log streaming is available on the chosen plan and where execution data is retained. For Temporal, visibility storage is set up with a supported backend, since the documentation recommends Elasticsearch or OpenSearch for anything beyond a few executions. The step is done when a deliberately failed test run produces an alert, a ticket and a recorded resolution.
Run a dry-run evidence collection before the audit period
Before the audit period starts, the control owners run a rehearsal that gathers the evidence auditors normally request: access listings, role assignments, change tickets with approvals, merge request history, schedule and alert records, and sample reconciliations of flow outputs to source data. Gaps found here are fixed while the controls are still new. The output is an evidence binder mapped to each control objective in the scope register, which the internal audit team reviews before the first real period begins.

What do buyers ask before engaging an implementation partner?

What does SOX ITGC work for n8n or Temporal workflows cost, and what drives it up?

The cost is driven by scope more than by the tool itself. The main components are the assessment of which flows touch financial reporting, hardening and configuration of the platform, change approval and access design, evidence design, and the number of environments that must be documented. Ask for a quote that lists each flow in scope, each environment (development, test, production), the identity and ticketing systems to integrate, and whether evidence collection is automated or manual. Ongoing costs recur for infrastructure, platform upgrades, and any paid n8n or Temporal plan features. DeployOpen works from a written, fixed scope, so the quote should map to those items rather than to a generic price list. DeployOpen does not publish prices.

How long does a SOX ITGC engagement take for workflow automation?

The pace is set mainly by your fiscal year cycle and your external auditor's testing calendar, not only by the build. Controls over program changes, access and job monitoring usually need to operate for a period before an auditor can test their operating effectiveness, so the work should finish ahead of the period under review. Confirm with your auditor which period they will test, when they want walkthroughs, and what evidence samples they will request. The number of flows, the state of your ticketing and identity systems, and whether a change board already exists will set the rest of the schedule. Ask any partner to propose a timeline tied to those dates, in writing.

What do we need to provide before a partner can start?

Plan for named control owners, auditor access, and a clear view of your identity provider and change process. Control owners decide which flows matter for financial reporting and approve the control design. Your external auditor should confirm the control population and evidence they expect before testing begins. The identity provider must be available for SSO and group mapping, and your change board or equivalent must agree how workflow edits are approved. Engineers also need a current inventory of workflows, credentials and environments. Without these inputs, a partner can build the platform but cannot prove that the controls operate as your auditor expects.

Can our internal team run SOX ITGCs for workflow automation on its own?

An internal team can do it if it has the skills and time, and the controls are kept simple. The work combines platform administration (access, encryption keys, environments, backups), change management, and evidence preparation that an auditor can inspect. Many teams find the hardest part is consistent evidence over the whole period, such as approvals, access reviews and job failure records, rather than the initial setup. Ask yourself whether you have engineers who can operate n8n or Temporal in production, a control owner who can sign off, and staff who can run access reviews on schedule. A partner can handle some or all of these as a fixed-scope engagement, followed by optional retainers for upgrades and support.

Do we need n8n Business or Enterprise plans for SSO and Git-based change control?

Yes, if you want SSO and environments with Git on n8n, those features sit on the paid plans. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and Enterprise adds dedicated support with an SLA. n8n SAML single sign-on is available on those plans, with setup guides for Okta Workforce Identity and Azure AD. Also confirm your licence position: n8n is under the Sustainable Use License, which covers internal business use, and files marked .ee need an n8n Enterprise License. Check current pricing on n8n's page before budgeting, because plan terms can change.

Does DeployOpen certify that our workflow automation is SOX compliant?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Management is responsible for the ICFR assessment, and your external auditor tests the controls under PCAOB standards and issues any opinion. DeployOpen's role is to design and implement the platform controls, document them, and assemble the evidence your auditor requests, so that the testing can be performed. Ask any partner to show the control matrix, the evidence list and the points where your auditor's review begins, and confirm that the auditor agrees with the design before work starts.

What is the risk if a workflow editor can change production flows without approval?

Unapproved edits to production flows are an IT risk that auditors look for because they can change how financial data is moved or transformed without anyone noticing. PCAOB AS 2110 lists unauthorized changes to systems or programs, and IT personnel gaining access beyond their duties, as risks to internal control over financial reporting. Your design should separate who can build a flow from who can promote it, record each change with an approval, and restrict production access to named roles. For Temporal, note that without a configured Authorizer, the default noopAuthorizer allows every API request, so access control must be set up deliberately. Ask a partner how they will test this configuration and retain the results.

Which parts of a SOX ITGC engagement recur after go-live?

Several parts recur, and they should be priced and owned from the start. Access reviews, change approval records, job monitoring and failure follow-up run every period. Platform upgrades also recur: Temporal recommends moving one minor version at a time and running schema upgrades before server upgrades when release notes require them, and n8n releases must be tested in non-production environments before promotion. Evidence collection, backup testing and credential rotation keep the controls current. Ask a partner whether support is offered as a retainer, what it covers, and how changes to controls are documented after each upgrade.

What tooling alone does not satisfy

A workflow engine can enforce access, log runs and store credentials, but it does not decide which controls the company needs or whether they are sufficient. The cards below cover the gaps that most often surface when self-hosted n8n or Temporal workflows touch financial data.

Control design and risk assessment stay human

No workflow product writes the control narrative, maps each flow to a financial reporting risk or decides which general controls are necessary for the automated controls it supports. SEC guidance (Release 33-8810) leaves the relevant IT general control areas to each company's facts and circumstances. Before build starts, document which flows feed financial figures, who owns each risk and which controls the team will test. Confirm that scope with your external auditor early.

Shared service accounts defeat access review

A single service account used by several developers, schedulers or workers makes it impossible to show who changed a flow or ran a job. PCAOB AS 2110 lists IT personnel gaining access beyond their duties and broken segregation of duties as IT risks to internal control. Give each workflow its own identity, record owners in a register and review that register on a fixed cycle. Ask whether your n8n or Temporal namespace roles can separate build, approve and run rights.

Temporal's default leaves the API open

If no Authorizer is configured, self-hosted Temporal uses the noopAuthorizer, which allows every API request with no authentication or access control. Until a ClaimMapper and Authorizer are in place, anyone who reaches the frontend can start, signal or terminate financial workflows. Restrict network access to trusted internal networks, enable mTLS and map identities to namespace roles before any production job runs. Test the denial path, not only the login path.

Community editions lack SSO and Git environments

According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Without SSO, user removal depends on manual account cleanup, and without Git environments, promotion from test to production is hard to evidence. Confirm which edition, and which license terms, your planned use requires before you design the change process around features you may not have.

Worker encryption key needs custody rules

In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials. That key therefore opens every credential in the database. Define who generates, stores, rotates and recovers it, keep access to it separate from workflow developers, and record each rotation. Ask your partner how the key is injected into workers and whether a lost key can be recovered.

The auditor decides sufficiency

Tool vendors do not determine whether a control is sufficient. External auditors test ICFR under PCAOB AS 2201 and assess IT risks under AS 2110, and their conclusions depend on the company's own design and evidence. A tool that logs runs is one input to that judgment. Agree evidence requirements, sample periods and the population of workflows in scope with the auditor before the controls go live.

How DeployOpen scopes and delivers SOX-ready workflow automation

DeployOpen plans, implements, hardens, documents and supports self-hosted n8n or Temporal inside the client's own infrastructure, with access, change and job controls designed around the evidence an ICFR assessment will ask for. The work is scoped in writing before it starts, and DeployOpen prepares the controls and evidence for assessment without issuing audit opinions.

How we scope

Written scope lists which financial workflows, data flows and integrations fall inside the ICFR boundary.
Scope maps each workflow to the control areas it touches: scheduling, change approval and production access.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Scope confirms license fit for internal use, including which n8n files or editions the planned features require.

How we build

Deployment is configured for trusted internal networks, with Temporal services kept off the public internet.
Temporal authorization is enabled with mTLS, a ClaimMapper and an Authorizer rather than the default noopAuthorizer.
n8n queue mode is set up with encryption key handling, Git-based environments and role-restricted production access.
Scheduling, monitoring and failure alerting are built so job runs leave a reviewable record.

How we hand over

Documentation covers control design, owners, approval steps and the evidence each control produces.
Walkthroughs show operators how to promote a workflow change, review its approval and reverse it.
Test scripts re-perform key access and change controls so the client can demonstrate operating effectiveness.
Handover names who owns each workflow, credential and upgrade decision after go-live.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrade plans follow the vendor's one-minor-version-at-a-time path, with schema changes applied first where release notes require it.
Periodic access reviews and control re-testing can be scheduled to keep evidence current for each fiscal year.
Clients confirm which support and testing items a retainer covers before the engagement starts.