Why a new ERP go-live becomes a SOX control question
When a new ERP or major upgrade approaches go-live, the question for management is whether the system that will produce financial results has been acquired, built and approved under controls that hold up to an auditor. Under Sarbanes-Oxley Section 404, management must maintain effective internal control over financial reporting, and that includes the IT general controls over financially significant systems. Program development is one of the areas SEC guidance names as an example of IT general control activity management might consider, though the specific areas that matter vary with each company's facts and circumstances. For a controller, the practical meaning is simple: if the new system will calculate revenue, post journal entries or close the books, the way it was specified, configured, tested and released is part of the reporting control environment from the first day it runs. The central risk is that logic or data changes at cutover without anyone authorizing or testing them. A mapping table edited late in the project, a tax rule configured in production but not in the test environment, or a converted opening balance that does not tie to the legacy ledger can all misstate balances while the system appears to work. The external auditor's standard, PCAOB AS 2201, lists controls over application and system software acquisition and maintenance among the IT controls relevant to automated controls (paragraph B33), so an auditor will ask how the new automated controls were approved and baselined. COSO's 2013 framework makes a similar point in Principle 11, which expects the organization to select and develop general control activities over technology that support its objectives. Both point to the same test: can you show who approved the design, what was tested and when it was signed off? What makes this hard is schedule pressure. Go-live dates are fixed by contracts, fiscal calendars and vendor support windows, and the work to satisfy the control tends to slip to the end. The evidence is also scattered across the implementation partner's project tool, a PMO spreadsheet, test scripts in shared drives and approvals in email. Before the project is far along, confirm three things with your project lead: who owns the final go-live approval, which system of record holds requirements, test results and sign-offs, and whether the auditor has agreed to the evidence format in advance. Settling these early is far cheaper than reconstructing them during a year-end audit.
Which new systems and upgrades fall inside SOX program development scope
Scope starts with the accounts and reports a new system touches, not with the system's name. SEC guidance limits management's evaluation to the IT general controls needed for reliable financial reporting, so the decisions below determine which projects bring program development controls into play and which teams must sign off.
Systems that feed financial accounts
Start from the financially significant accounts and disclosures, then trace which applications originate, calculate, summarize or store the data behind them. A new general ledger is an obvious case, but a billing engine, expense tool or consolidation utility that posts journals is in scope too. Map each system to the reports and automated controls it supports, and document the reasoning so an auditor can follow the same path.
Major version upgrades
Decide whether an upgrade changes calculation logic, security configuration, workflow approvals or reporting outputs. A minor patch that changes none of these may need only a lighter review, while a major release that alters tax, revenue or close functions usually needs the full program development path. Record the decision and the rationale in the change or project file, because auditors will ask why an upgrade was or was not treated as a new implementation.
SaaS and cloud configuration changes
Subscription platforms often change through configuration rather than code, so the controls must cover settings such as approval thresholds, chart of accounts mappings and role assignments. Confirm with the vendor which configuration changes are logged, who can make them and whether release notes arrive before production. Treat a vendor-pushed update that alters financial calculations as a change that needs your own testing and approval.
Data conversion and migration
Historical balances, open items and master data moved into a new system are part of the implementation scope, because errors there flow straight into reported numbers. Identify which conversion routines, mapping tables and reconciliations need controls, such as record count and balance tie-outs with documented sign-off before cutover. The sibling topic on data conversion covers these controls in detail.
Interfaces feeding financial systems
Every interface that carries financially relevant data into or out of the new system changes the risk profile of the reporting process. Inventory feeds from payroll, procurement, banking and subledgers, and determine whether each is automated, scheduled or manually loaded. Confirm which interfaces are tested end to end, how failed transmissions are detected, and who approves changes to interface mappings.
Third-party implementers and sign-off roles
Consultants, system integrators and vendor professional services may build or configure in-scope systems, but management keeps ownership of approvals. Define in writing which finance, IT, business owner and vendor roles must approve requirements, test results and go-live. Confirm that implementer access is time-limited, that their work products are retained as evidence, and that an internal owner accepts responsibility for the controls after handover.
How an auditor tests project approval, testing and go-live sign-off
A walkthrough follows one project from request to production so the auditor can confirm that the controls exist as described and that the people involved understand them. The auditor usually picks one project, asks the project owner to explain the lifecycle, and then requests the artifacts created at each stage: the business case, the approved requirements, the vendor or build decision, the test plan, the test results, the user acceptance sign-off and the production release approval.
- Start from a single project: Choose a recently completed implementation and trace it through every approval gate, not only the final release.
- Compare documents to the lifecycle: Confirm that each gate has a dated, named approver with the authority recorded in the governance charter.
- Ask who can release to production: Confirm that the person who builds or configures a system is not the person who approves its go-live.
- Check the handoff points: Look for places where a project moved between a project tracker, an email thread or a ticketing system without a retained record.
- Confirm the explanation matches the evidence: If the project owner describes a gate that has no artifact, the auditor records a gap.
Before a walkthrough, confirm that the project tool, ticket history and approval records cover the same project from start to finish, so the trace does not depend on memory.
Design evaluation asks whether the approval and testing controls, if they operated as written, would reasonably prevent or detect a misstatement in financial reporting. The auditor reads the project methodology, approval matrix, testing standard and go-live policy, and asks whether they cover the risks that a new financially significant system creates, such as incomplete requirements, untested interfaces, unauthorized configuration changes and unreviewed data conversion.
- Approval thresholds: The matrix should state which projects need steering committee, finance or internal control approval, and it should match the systems that feed financial statements.
- Testing scope: The standard should require testing of configured automated controls, interfaces and reports, not only functional features.
- Segregation of duties: Developers, testers and approvers should have defined and separated roles in the design.
- Exception handling: The design should describe how emergency or deferred go-live decisions are approved and documented.
- Policy alignment: The methodology should reference the same definition of a financially significant system used in SOX scoping.
A design gap, such as a methodology that never requires finance sign-off, often becomes a finding even when every project happened to be approved, so confirm the design before sampling begins.
Operating effectiveness testing checks whether the controls worked for the projects that actually went live during the audit period. The auditor defines the population of relevant projects, usually from a change or project register, selects a sample, and inspects each selected project's evidence against the control's requirements. The sample size and selection method depend on the auditor's risk assessment and the control's frequency, so the population must be complete before anything is selected.
- Define the population: Ask for a complete listing of go-lives and major upgrades in the period, and reconcile it to the production change log.
- Select across the period: Auditors typically sample across the audit period rather than only early or late projects.
- Check approval timing: An approval dated after the go-live date is a common finding because it shows the control did not precede the event.
- Check user acceptance: Missing or generic acceptance sign-offs, or sign-offs by people without business authority, are frequent exceptions.
- Check test evidence: Test results should reference the version tested and the version deployed, since mismatches are a common gap.
Before the audit, run your own reconciliation of the project register against production records, because an incomplete population is itself a finding.
Cutover inspection examines the checklist and evidence used to move a system into production. For a new ERP, this is where the auditor looks for proof that the system went live in the state management approved, with migrated data reconciled, interfaces confirmed and automated controls configured as designed. Auditors also use the go-live configuration as the baseline for testing new automated controls, so an undocumented or unverified cutover weakens reliance on those controls for the rest of the year.
- Pre-cutover approval: The checklist should show a go/no-go decision with named approvers and a date before the cutover window opens.
- Data reconciliation: Record counts and balances should reconcile between legacy and new systems, with sign-off recorded.
- Configuration baseline: Auditors often ask for an export or screenshot of key automated control settings as they existed at go-live.
- Rollback criteria: The checklist should define the conditions under which the cutover is reversed, and who decides.
- Post-go-live review: Look for a documented review of the first production period, including issues found and how they were closed.
Before inspection, confirm that the cutover checklist, configuration export and reconciliation evidence are stored together and can be produced without reconstruction after the fact.
Sequence for governing a new financial system from request to production
This sequence gives management a documented trail from the first business need to a signed go-live decision, so auditors can see who approved the system, what it was tested against, and who was accountable when it went live. Each step produces an artifact that the next step relies on.
Document business requirements and risk assessment
Finance, IT and process owners write down what the new system must do, which financial reporting risks it addresses, and which key controls will depend on it. Risk assessment identifies the accounts, disclosures and automated controls affected. The output is an approved requirements document with a risk assessment that states why the system is in scope for ICFR. It is done when the process owner and the control owner sign it, and the document names the reports and interfaces the system must produce.
Approve the build or buy decision
Management compares a commercial package, a configured open-source platform or an in-house build against the requirements, and records the reasons for the choice. Procurement, IT and finance leadership review vendor due diligence, including contract terms for audit access and provider evidence. The output is a decision memo with an approval record from the designated executive. Confirm with the vendor which SOC reports or audit rights apply before signing, because these affect how evidence is obtained later.
Charter the project and set steering authority
A project charter defines scope, roles, decision rights and the steering committee that can approve changes to scope, budget or go-live timing. Finance and internal audit should hold seats, and the charter should state who can accept residual risk. The output is a signed charter and a RACI matrix. It is complete when the steering committee minutes show that the committee has met and recorded its decisions, so the approval chain is visible to an auditor.
Define the test strategy and user acceptance
The project team sets the testing approach for the system and its interfaces, names the testers, and defines the criteria for passing each test phase. Business users who will operate the system perform user acceptance testing and log defects in a tracked system. The output is an approved test strategy and signed user acceptance results. Detailed test scripts belong to the sibling topic on testing and go-live approval, so this step only establishes who approves the testing and what counts as a pass.
Obtain data conversion sign-off
Before cutover, the data owner confirms that financial balances and records moved into the new system are complete and accurate. Governance requires a named owner, a documented reconciliation approach and a signed acceptance of the converted data. The output is a signed conversion sign-off that references the reconciliation evidence. Detailed reconciliation controls are covered in the sibling topic on data conversion and migration.
Separate developer and production access
Before go-live, the team confirms that people who built or configured the system do not hold standing production access, and that production changes flow through an approved release path. In a Git-based workflow, protected branches can restrict who may push or merge, block direct pushes and keep force pushes disabled. The output is an access review record and screenshots or exports of the configuration. The check is complete when the reviewer confirms no developer can deploy to production without a second approver.
Record documented go-live approval
The steering committee or designated executive gives a written go-live decision that lists the open defects, accepted risks, compensating procedures and the date of cutover. Finance and IT both sign. The output is a go-live approval record that auditors can match against the test results, conversion sign-off and access review. Management also evaluates whether the implementation is a change in internal control that must be considered for disclosure under the quarterly evaluation rules, and documents that conclusion.
How go-live approval differs from routine program change control
A one-time implementation or major upgrade of a financial system runs through a project lifecycle with its own approvals, while routine changes after that point fall under program change control. The distinction matters to auditors because the go-live approval is the moment management asserts that the new system is ready to produce financial records. Before that sign-off, the project steering group should hold a documented decision that the requirements were met, the test results were accepted by the business process owners, and the data conversion reconciliations were signed off. Routine change tickets, by contrast, assume a stable baseline already exists.
That go-live package becomes the baseline auditors rely on when they later test program changes. Auditors typically ask for the configuration and code versions in production at cutover, the list of automated controls and reports configured in the new system, and the access roles assigned at go-live. Management should confirm that the cutover record in the ticketing or project tool links to the approved test scripts and results, the conversion reconciliations, and the named approvers, so an auditor can trace each later change back to a known starting point. Where a baseline is missing or only partly documented, auditors may need to test the new automated controls from scratch in the first year, which adds effort for both management and the auditor.
Major upgrades and system replacements can also raise disclosure questions. Item 308(c) of Regulation S-K requires disclosure of any change in internal control over financial reporting during the last fiscal quarter that has materially affected, or is reasonably likely to materially affect, it, and a major system implementation can meet that test. Rule 13a-15(d) requires management to evaluate such changes each fiscal quarter. Management should document that quarterly assessment for every major go-live, record the conclusion and the reasoning, and involve legal or disclosure counsel where the conclusion is unclear. Confirm the assessment with your external auditor and securities counsel before the quarter closes, since the documentation is evidence the evaluation was performed.
Evidence that passes for new system implementation controls
Auditors test a new financial system by asking for dated, approved records that trace from the business need through testing to go-live. Each card below names one artifact or record set, what it proves and what to check before the auditor arrives. Keeping these items in a project register indexed to the fiscal year makes the evidence usable at year end instead of a rebuild after the fact.
Approved business requirements
The requirements document shows what the system must do for financial reporting, including calculations, approval limits, interfaces and reports that feed the financial statements. Auditors compare it with the test scripts later, so each requirement should trace to at least one test case. Check that the document carries an owner's approval date and that the version tested is the version approved. Missing or unsigned requirements are the most common gap we see when reviewing program development files.
Project approval minutes
Minutes from the steering or investment committee show who authorized the project, the scope approved and the risks accepted. They establish that management, not only the project team, decided to proceed. Confirm the minutes name the approvers, record the date and reference any scope change approved later. Keep them with the project register so an auditor can follow each approval without asking for additional documents.
Vendor selection memo with risk review
The selection memo records the options compared, the criteria used and the reasons for the chosen product or implementation partner. For a purchased package, the risk review should cover security certifications, data location, support terms and the vendor's own control reports where relevant. Ask the vendor for its current SOC 1 or equivalent report if it hosts financial data. The memo should be signed before the contract, not reconstructed after it.
Signed test plans and results
Test plans define the scenarios, expected results and pass criteria for the system and its interfaces. Results show the actual outcomes, the tester's name, the date and how defects were resolved and retested. Auditors use these records to baseline new automated controls, so a plan that never reached the final configuration is weak evidence. Store the version of the code or configuration tested alongside the results.
User acceptance sign-offs
User acceptance confirms that the business owners of each process reviewed the system in test and accepted its behavior. Sign-offs should come from people who run the process, not only from the project manager, and should name the process area, the scenarios covered and any open issues accepted. Confirm that each sign-off predates the go-live decision and that accepted exceptions have a documented owner and follow-up date.
Conversion reconciliation references
Reconciliations show that financial data moved into the new system is complete and accurate, typically through record counts and balance tie-outs between the legacy and target systems. Each reconciliation should reference the migration run it covers and carry a preparer and reviewer signature. Sibling controls on data conversion and migration describe how these checks are designed, so this card focuses on keeping the reference trail intact for auditors.
Segregation-of-duties review for go-live access
Before go-live, someone should review who holds access to create, approve and post transactions in the new system and confirm no individual can perform conflicting steps. The review also covers administrator and developer access to production, which often remains broader than planned. Document the conflicts found, the remediation chosen and the date access was reduced. This record links directly to the access controls that will run after launch.
Dated go-live authorization
The go-live authorization is the formal approval, signed by the accountable owners, that moves the system into production on a stated date. It should reference the test results, open issues, conversion reconciliation and access review it relies on. Auditors look for an authorization that predates the cutover and matches the change record in production. Any issue accepted at go-live needs a named owner and a remediation date in the register.
What a SOX-compliant system implementation costs to govern
This table breaks down the cost components of governing a new financial system under SOX, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Use it to frame a request for a written scope and quote, since no figures are published here and actual amounts depend on system scale, control count and your own environment.
| Cost component | Who is paid or who bears it | One-time or recurring, and main driver | Cost-reduction lever |
|---|---|---|---|
| Implementation partner or consultant fees | External implementation or SOX advisory firm | One-time. Driven by the number of modules, interfaces, controls designed and the depth of documentation required | Agree a fixed written scope with defined deliverables, and separate design work from build work |
| Internal project staff time | Your finance, IT and business process owners | One-time. Driven by the number of approvers, testers and data owners pulled into requirements, testing and go-live sign-off | Name accountable owners early and reuse existing change and access templates |
| PMO or ticketing licenses | Software vendor or hosting provider | Recurring. Driven by named users, modules and support tier of commercial tools that record approvals and change tickets | Evaluate self-hosted open-source ticketing, such as GLPI or Zammad, which can remove license spend while you keep the evidence in your own environment |
| Evidence upkeep | Your internal control, IT and compliance staff | Recurring. Driven by how often approvals, test results and reconciliations are collected and retained across the year | Standardize evidence templates and capture it inside the workflow tool rather than rebuilding it at audit time |
| External testing or independent review | Independent security firm or reviewer, if you commission one | Optional and recurring when re-performed. Driven by scope of the new system, interfaces and whether testing is repeated after changes | Limit review to high-risk interfaces and configurations, and ask for a written scope that lists exactly what is tested |
| Auditor sampling | Your independent external auditor | Annual. Driven by the number of controls tested, sample sizes, and whether the system go-live falls inside the audit period | Keep evidence complete and organized so samples can be pulled quickly, and confirm testing expectations with the auditor early |
Who owns the system implementation controls and who can help
Management owns internal control over financial reporting, so the people who approve a new financial system must be employees with the authority to accept its design, its testing results and its go-live. Business process owners define the requirements and the accounting outcomes the system must produce. The controller or finance leadership confirms that the configured system supports the reporting and close process. IT owners manage the environment, access and change process after go-live. The approval authority, often a steering committee or a named executive, signs the decisions that are recorded as evidence. Typical points to document:
- Named business owner: the person who accepts requirements, configuration choices and user acceptance results.
- Controller sign-off: confirmation that financial reporting, close and reconciliation outputs match the accounting policy.
- IT owner accountability: responsibility for environments, access, interfaces and the post-go-live change process.
- Approval authority: a documented decision to move the system into production, with its date and conditions.
- Retained records: approvals, meeting minutes and sign-offs stored where the auditor can request them.
Confirm that each approver has the authority and the knowledge to assess the decision they sign.
An implementation partner can carry much of the preparation work, but it works for management and does not replace it. Typical work includes drafting the system design and control documentation, configuring tooling such as ticketing and source control so that approvals are captured, and assembling evidence packs for testing and go-live. The partner can also run test scripts and record results, provided management reviews them and accepts the outcome. Typical contributions include:
- Design documentation: drafts of system design, interface maps and control descriptions for management to review and approve.
- Tooling configuration: setting up ticket workflows, repository branch protections and test records so approvals are captured automatically.
- Evidence packs: organized test scripts, results, defect logs and sign-offs, indexed to each control.
- Testing support: executing test cases and documenting outcomes under management's direction.
- Knowledge transfer: training internal owners so they can operate the controls after the project closes.
Ask the partner which documents it will prepare, which decisions remain with your staff, and how the work will be handed over at the end of the engagement.
The external auditor tests internal control over financial reporting under PCAOB AS 2201, including the IT general controls that support automated controls. It samples evidence, inspects approvals and re-performs selected tests. The auditor cannot design or operate the controls it tests, because that would impair its independence. It may review management's documentation and report deficiencies, but the decisions and the records belong to the company. Points to understand before go-live:
- Testing role: the auditor evaluates whether controls were designed and operated effectively, based on evidence management provides.
- Independence limit: the auditor cannot prepare the controls, approve the system or make the go-live decision.
- Early engagement: agree with the auditor in advance which evidence will be requested for a major implementation.
- Change disclosure: a major system change may affect the assessment of internal control, so involve finance and legal early.
- Evidence requests: expect requests for approvals, test results, migration reconciliations and access listings.
Confirm with your audit firm what evidence it expects and which activities it considers permissible for its own independence.
Where new system go-lives usually fail SOX review
Most failed go-live reviews do not involve a broken system. They involve missing or late evidence that the new system was approved, tested, limited to authorized people and assessed for ICFR impact. Each card below is a gap auditors repeatedly find, paired with the closing action that prevents it.
Go-live approved after cutover
The formal go-live approval is dated after data was loaded or the system began processing transactions, so the approval confirms a decision already made. Auditors test whether approval preceded production use. Close it by making the signed approval a hard gate in the cutover runbook, with the approver's name, date and the production change record referenced in the same document.
User acceptance not documented
Business users tested the system informally, but no signed test scripts, results or defect dispositions exist. Without them, an auditor cannot confirm that the financial calculations and reports matched the approved requirements. Close it by requiring written acceptance scripts, recorded results, and sign-off by the process owner for each in-scope report and automated calculation.
Developers with production access at go-live
Build staff retain administrative or write access to production at cutover, which weakens the separation between building and operating the system. Auditors look for who could change production data or code after approval. Close it by removing developer access before go-live, documenting any break-glass access with a named approver, and reviewing the production user list before sign-off.
No link between requirements and tests
Requirements, test cases and results are kept in separate files, so no one can show that each financially relevant requirement was tested. Auditors trace from a control or report back to a requirement and then to a passed test. Close it by maintaining a traceability matrix that maps each requirement to its test cases, results and defects, and reviewing gaps before approval.
Decisions made in email only
Scope changes, workarounds, risk acceptances and design choices were agreed in email threads or chat, with no formal record. Auditors cannot tell who approved an exception or when it was accepted. Close it by logging every material decision in the project ticketing system with an approver, a date and a link to the affected requirement or test.
No SOX impact assessment for upgrades
Major upgrades and configuration changes proceed without asking whether they change internal control over financial reporting. Management must evaluate such changes each fiscal quarter, and a major implementation can require disclosure. Close it by adding a documented SOX impact assessment to every upgrade and new-system project, signed by the controller or finance owner before go-live.
Questions buyers ask about SOX system implementation controls
How much extra effort does a SOX-ready ERP implementation add?
A SOX-ready implementation adds effort mainly in documentation, testing and approval steps that a project without financial reporting controls would skip. The added work depends on how many financially significant modules are going live, how many interfaces feed the general ledger, and whether the company already has a documented change and project governance process. Expect extra time for requirements sign-off, test evidence retention, data conversion reconciliations and a formal go-live approval that names who accepted the system. Ask your auditor which of these they will inspect and how far back they want evidence to go before you size the project plan.
Do we need an outside partner for a SOX system implementation?
Not always, but many organizations bring in a partner to prepare systems and evidence while the company keeps ownership of the controls. Management owns the controls and the sign-off, and only the independent external auditor issues the attestation under Section 404 where it applies. A partner is most useful when the internal team lacks people who have built or tested financial systems before, or when the go-live date leaves little room for rework. Under a fixed scope, ask for written deliverables such as test scripts, configuration baselines and evidence checklists, and confirm in writing which decisions stay with your staff.
What does the finance team have to do during implementation?
The finance team owns the business side of the controls, so its involvement is continuous rather than limited to user acceptance testing. Finance must define the financial reporting risks the system supports, approve requirements and role designs, validate that converted balances reconcile to the legacy ledger, and perform or review the test cases that cover reporting logic. Someone in finance should also sign the go-live approval and confirm that approvals for future configuration changes route to the right people. Naming these owners before design starts prevents evidence from being reconstructed later, which is a common source of audit findings.
How long does it take to prepare SOX evidence for a new system?
The time needed to prepare evidence depends on the auditor's testing approach, the period the auditor will cover, and whether the new system goes live before or during a fiscal year. Evidence must show the controls operated as designed for the period under audit, so a system that goes live late in the year may need a different testing plan than one live for the full year. Confirm with your external auditor which controls they will rely on, the sample sizes and the period they expect evidence to cover, and whether they want walkthroughs before go-live. Build that confirmation into the project schedule before choosing a go-live date.
Is open-source tooling acceptable for SOX system implementation evidence?
Open-source tooling can produce acceptable evidence when the tool generates records that are complete, attributable and retained, and when management can show the control worked as designed. Auditors generally assess the control and its evidence rather than the license of the software behind it. For example, a protected branch setting in GitLab Community Edition can restrict who may push or merge to a branch and keep force pushes disabled, which supports change authorization evidence for custom code. A ticketing tool such as GLPI, with its Assistance module, can record change requests and approvals following ITIL practices. Confirm with your auditor that the tool's logs and exports meet their evidence expectations before you rely on them.
Does a major upgrade of an existing financial system need SOX testing?
A major upgrade usually needs SOX testing when it changes automated controls, reporting logic, security configuration or interfaces that feed financially significant balances. Under Item 308(c) of Regulation S-K, a change in internal control over financial reporting during the last fiscal quarter that has materially affected, or is reasonably likely to materially affect, it must be disclosed, and a major system implementation can be such a change. Rule 13a-15(d) also requires management to evaluate such changes each fiscal quarter. Consult your auditor and your disclosure counsel early, since the answer depends on what the upgrade changes and how the business relies on it.
What should we ask a partner before agreeing to a SOX implementation scope?
Ask for a written scope that lists the systems, modules, interfaces, controls and evidence the partner will prepare, along with the deliverables and the decisions that remain with your team. Confirm that the partner does not issue audit reports or attestations, because only independent auditors and certification bodies do. Ask how the work will be tested before go-live, how data conversion will be reconciled, and who approves each change after go-live. A fixed-scope agreement makes it easier to compare proposals, and a quote should follow directly from that written scope rather than from a general estimate.
How DeployOpen prepares implementation evidence
DeployOpen scopes implementation controls in a written, fixed-scope agreement before any build work starts. That agreement names the systems, interfaces, environments and roles in scope, the deliverables for each phase (requirements, configuration, testing, data conversion and go-live), and who approves each step. For a new financial system or a major upgrade, the scope should also say which automated controls and reports the new system must support, because those are the items the auditor will ask to baseline. Before signing, ask the proposed partner to show a sample scope document and to state which decisions remain with your management, such as approving requirements, accepting test results and authorizing cutover. DeployOpen prepares systems, configuration records, test packs and evidence for management and the external auditor. It does not issue audit reports, attestations or opinions on ICFR. Those come only from the independent auditor, and management keeps ownership of its controls and its sign-off.
In practice, the evidence package is built as the project runs rather than reconstructed after go-live. Typical items include approved requirements, change tickets linked to build and configuration work, test scripts with recorded results, user acceptance sign-offs, data conversion reconciliations, and a dated go-live approval. Where open-source tooling is used, such as GLPI for change and ticket records or GitLab protected branches to restrict who can merge configuration code, confirm with the platform owner that the configuration matches your own change policy before relying on it as evidence. Agree with your auditor early on what sample period and format they expect, and confirm with them whether a system-generated report or a screenshot is acceptable. Those decisions shape the work more than the tools do.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so new financial systems and major upgrades arrive with the approvals, test records and change history an auditor will ask for. We prepare the systems and evidence; your organization owns the controls and the go-live decision, and only an independent auditor issues opinions on ICFR.
How we scope
- Agree in writing which financial system, upgrade or interface is in scope before work starts.
- Map each project phase to the approvals, testing and cutover records your auditor will expect to see.
- Confirm which parts of the project belong to your team, your vendor, and DeployOpen, with named owners.
How we build
- Configure the platform with change control in place, so every build step has a ticket, an owner and an approver.
- Store source, configuration and infrastructure code in version-controlled repositories with protected branches and reviewed merges.
- Run test scripts and data conversion checks, capturing results and reconciliations as dated, retained records.
How we hand over
- Deliver system documentation, test packs, sign-off records and a go-live evidence binder for your control owners.
- Walk your internal audit and control teams through the evidence so they can explain it to the external auditor.
- Document known gaps and compensating steps in the handover so open issues do not disappear at cutover.
How we support
- Support the platform after go-live under a retainer, covering upgrades, patches and change records.
- Re-test affected controls when a major upgrade or interface change occurs, and update the evidence set.
- Confirm with your auditor and counsel whether a change is material before deciding on Item 308(c) disclosure.
