Open source ITSM for SOX change management

Each incident affecting an in-scope system should be logged as its own ticket and linked to the affected configuration item (CI) in the CMDB, such as the application server, database, or interface that supports financial reporting. In GLPI, the ticket is linked to the asset or item record; in iTop, the incident is related to the CI through the data model. The link matters because an auditor asking which systems were disrupted in a period needs to start from the CI and find every incident against it. Confirm with your implementation partner which CI classes are flagged as in scope, and that required fields such as category, impact, urgency and the affected CI cannot be left blank when the ticket is closed.

A problem record is required when the root cause of one or more incidents is unknown or not yet fixed, especially when incidents recur on the same CI or affect the same financial process. Your policy should define the trigger in writing, for example a threshold of repeat incidents on an in-scope CI within a period, or any incident that caused incorrect processing or a data integrity issue. The threshold is a policy decision, not a standard value, so set it with your internal audit and control owners. Problem records should stay open until a permanent fix is either implemented through a change or formally accepted as a known error with a documented workaround.

The problem record should reference the root cause analysis and the change record that implements the permanent fix, and the change should reference the problem and the incidents it resolves. This two-way link lets an auditor trace from an incident to the problem, from the problem to the change, and from the change to its approval, testing and post-implementation review. In GLPI and iTop, these relationships are modeled as linked objects, so the chain can be exported or reported. Ask your partner to demonstrate the full chain on a sample incident during design, because a link that exists in the data model but is not filled in by staff provides no evidence.

Recurring incidents should trigger a change request when analysis shows the fix requires a modification to a production system, such as a configuration correction, patch or code change. The step is only evidence if the trigger is written down and followed. Reporting that counts incidents per CI each month, reviewed in a problem board, gives management a documented basis for deciding whether to raise a change. The review should record who decided, when, and why no change was raised if none was. Your partner can configure the reporting, but the thresholds and review cadence come from your control design.

SLA timestamps are reliable when the ticket system records each status change automatically, including opened, assigned, responded, resolved and closed times, with the user who made each change. Manual edits to these fields should be restricted to specific roles and logged, because an auditor will test whether timestamps were altered after the fact. Review the audit log settings, confirm that the database and application servers are synchronized to a trusted time source, and test the timestamps by comparing a sample of tickets with independent records such as monitoring alerts. The exact configuration depends on the GLPI or iTop version and your hosting, so confirm the audit trail features with the vendor documentation during design.

An auditor will typically ask whether each emergency change raised from an incident was authorized, by whom, and when, and whether it was reviewed after implementation. They will want to see the incident that triggered it, the reason the normal change process could not be followed, the approval given before or promptly after the change, and evidence that a retrospective review occurred. Your process should set a deadline for retrospective approval and make it visible in reporting. Emergency changes that bypass approval altogether are a common finding, so sample testing will focus on whether the record exists and whether the approver had the authority to approve. Confirm these expectations with your external auditor before the control is designed.

Your team can run the process day to day if the roles, categories, approval rules and reports are designed and tested first, and the design is the part where outside help is most often used. A partner typically covers configuration of the GLPI or iTop ticket types, the CI links, the audit trail settings, reporting for problem and recurrence reviews, and evidence collection for the auditor. Scope is agreed in writing before work starts, and the cost depends on the number of in-scope systems, integrations with monitoring tools, and the amount of historical data to be reconciled. Ask any partner to show how the design maps to your written control descriptions before quoting.

Effort depends mostly on how many systems are in scope, how complex the approval matrix is, and how far the change record must reach into the deployment pipeline. A narrow scope with one approval path and manual deployment is a small configuration job. Many in-scope systems, multiple approval tiers by system or dollar exposure, and automated links to CI/CD tools add workflow design, integration and testing work. Ask any partner to size the effort from a written list of in-scope systems, the approval rules as your change board actually applies them, and the pipeline tools that would feed the change record. Effort figures should come from that written scope, not from a generic estimate.

Many IT teams can configure basic ticket types, change statuses and approval steps in GLPI or iTop themselves, provided someone owns the design and the administration. The harder parts are translating control objectives into workflow rules, setting up segregation of duties in roles, testing that approvals cannot be skipped, and producing evidence that an auditor will accept. Internal teams often underestimate the testing and documentation load. A practical test is whether one administrator can explain every approval path, role and exception to internal audit without reference notes. If not, a partner can design and document the configuration while your team keeps administration.

Each function owns a different part of the design. IT owns the systems inventory, the deployment pipeline, the administration of GLPI or iTop and the operating procedures. Finance identifies which applications and reports feed financial statements, since only those systems drive the scope of ICFR controls. Internal audit reviews the control objectives, the evidence standard and the test approach before configuration is locked. Management is responsible for the control itself under the SEC guidance on management's ICFR evaluation. Agree these responsibilities in writing before work starts so the approval matrix, the in-scope list and the evidence retention rules are signed off by the right people.

The timeline is set by scope agreement, the number of in-scope systems, the state of existing change records and how quickly approvers are available for design reviews and testing. Rollouts usually move in phases: define the in-scope systems and approval matrix, configure workflows and roles, integrate with the pipeline, run a parallel period where changes are recorded in both the old and new process, then cut over. Each phase depends on decisions from finance, IT and audit. DeployOpen agrees timelines in a written, fixed-scope plan before work starts, so ask for the phase plan and the decision points that gate each phase.

The software is open source, so licensing is not the main cost. The paid work includes configuration of workflows and approval rules, migration of existing change and asset records, integration with identity and deployment tools, testing, documentation and ongoing administration. Support subscriptions are optional but can be a recurring cost if you want vendor-level support. One-time costs cover design, configuration, migration and testing. Recurring costs cover administration, upgrades, backups, support and periodic access reviews. When requesting a quote, ask for each cost line separately, the assumptions behind it and which items recur after go-live.

Only if you choose GLPI Network. The GLPI Network subscriptions page lists public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Those figures are published by the GLPI project and are not DeployOpen prices. A self-hosted GLPI deployment can run without a GLPI Network subscription. Confirm with the vendor which tier, user count and asset count your scope would need, and check whether the features you require are included at that tier.

No. DeployOpen plans, configures, documents and supports the systems and the evidence trail, and prepares controls for assessment, but it does not issue audit reports, attestations or certifications. Under Section 404 of the Sarbanes-Oxley Act, management performs the annual ICFR assessment, and for certain filers an independent auditor attests to it. Your external auditor tests the controls under PCAOB standards. DeployOpen's role is to make the change records, approvals and access evidence complete and retrievable so your team and auditors can test them.

Auditors typically look for a clear record of each change, who requested it, who approved it before implementation, what was tested, who deployed it and whether the deployment matched the approval. Emergency changes need their own path with retrospective review. In GLPI or iTop, this means change tickets with mandatory approval steps, timestamps, linked assets and configuration items, role-based access, and retained history. Confirm with your external auditor which population, sampling approach and retention period they expect, since the SEC guidance says the relevant IT general control areas vary with each company's facts and circumstances.