Using GLPI change approvals as SOX ITGC evidence
Yes, GLPI change records can be part of the evidence for program change controls, but they cover only the workflow side. A finance or IT leader preparing for fiscal year end needs to show that changes to in-scope financial applications were requested, reviewed, approved and tracked before release. GLPI change records, approval steps and business rules that route major changes to a Change Advisory Board group can show that workflow. SEC Release 33-8810 names program changes as one IT general control area management may consider, but it says the relevant areas vary with each company's facts and circumstances. No SEC rule or PCAOB standard publishes an IT general control catalog, so your team must define which controls matter for its own ICFR scope. DeployOpen plans, configures and documents the GLPI side and prepares the evidence, but it does not audit, attest or certify. Your auditors make those determinations.
GLPI helps most with the approval and traceability questions: whether a change record exists, who requested it, which validation step approved it, and whether routing rules sent major changes to the CAB group and set them to pending validation. GLPI 11 added group approval requests and grouped approvals by validation step, which matters when more than one approver must sign off. Confirm with your auditors how they want approvals sampled and whether they accept exports from the GLPI history and approval records as populations. GLPI does not show what code was changed, who reviewed the diff, whether tests passed, or whether the deployed artifact matched the approved change. Those assertions usually depend on your source control, CI/CD and deployment logs, so the change ID in GLPI should be linked to those systems.
Before the period closes, check three things: that the routing rules in your GLPI instance match the change policy your auditors saw, that no emergency or standard changes bypass the approval steps without a documented reason, and that the link from each GLPI change to the corresponding commit, pipeline run and deployment record can be followed in both directions. Ask your auditors to confirm which program change attributes they need, such as approver identity, timestamps and the link to the release. Plan for the cases GLPI cannot cover on its own, including direct production access and changes made outside the ticketing workflow, and decide how those will be detected and explained.
Mapping SOX program change requirements to GLPI capabilities
This table pairs each SOX-related change requirement with the GLPI change feature that can support it and the configuration it needs. Read the middle column for what to set up in GLPI and the last column for what still has to come from the code system, the ticketing discipline or the auditor's own testing. The main takeaway is that GLPI can hold the approval record, but it does not prove that the approved change is the one deployed.
| Requirement area | GLPI support and configuration | Dependencies outside GLPI |
|---|---|---|
| SEC 33-8810 program change area | Change records with a business rule that routes major changes to a CAB group and sets status to pending validation automatically | Defined criteria for what counts as a major change, and documented program change policy |
| COSO Principle 11, general control activities over technology | Business rules in GLPI 12 that enforce routing and status, with rule changes restricted to administrators | Change management policy approved by management, and review of rule configuration exports |
| AS 2110 Appendix B, understanding of ITGCs | Change templates, categories and the approval history on each change showing who approved and when | Mapping of which applications and automated controls the change process covers, documented by the team |
| Approval steps by validation step (GLPI 11) | Group approval requests and approvals grouped by validation step, so each required group signs off in sequence | Named approver groups kept current through directory or user management, and proof of approver authority |
| Rule 13a-15(c) annual evaluation | Exported change records, rule definitions and approval history for the review period, kept with the evaluation file | Management's evaluation memo, framework selection and the conclusion reached by management |
| Linking change to deployed code | Change record can reference the request, ticket or release identifier from the delivery tool | Source control, CI/CD and deployment logs that show the approved change matches what reached production |
| Emergency and out-of-cycle changes | Change record with urgency and a post-implementation review task, if the team creates and closes them in GLPI | Emergency change procedure, retrospective approval evidence and logs from the system that was changed |
| Segregation of duties | Separate profiles so requesters, approvers and implementers hold different rights in GLPI | Access reviews for the code repository and production environment, which GLPI does not control |
How GLPI change records, CAB routing and approvals fit together
The change initiator opens the change record in GLPI and describes what will be altered, why, and which assets or services are affected. The record is the starting point for everything an auditor will later ask about, so the fields the initiator fills in carry weight. GLPI's business rules for changes can inspect the record as it is created and route it automatically, which means the initiator's choices can decide which approval path applies.
- Complete the change record: Enter the description, category, affected items and planned dates at creation, since later edits are harder to explain.
- Classify the change accurately: Set the change type or priority the way your change policy defines it, because the business rule conditions read these values.
- Link related items: Attach the affected assets, related tickets and any problem records so the change is traceable to the reason it exists.
- Avoid editing after submission: Changes to a record after approval should be made deliberately and noted, not silently overwritten.
- Keep the requester visible: The initiator is the person accountable for the request, so confirm that the requester field matches the person who actually asked for the change.
Confirm with your change policy which fields are mandatory for a major change and whether initiators can edit a record once it reaches validation.
The Change Advisory Board or an individual approver reviews the change and records a decision in GLPI. The business rules documentation for GLPI 12 describes how a major change can be routed to a CAB group and moved into a pending validation status without manual intervention. Approvers then act on the validation request, and their decision becomes part of the change history.
- Routing to the CAB group: A business rule can assign a major change to the CAB group when its conditions match, so approvers see only the changes that require their review.
- Pending validation status: The same rule can set the status to pending validation, which holds the change until a decision is made.
- Approval steps in GLPI 11: The GLPI 11 changelog added group approval requests and approvals grouped by validation step for changes, so each stage of approval is visible on its own.
- Decision record: Approvers should record the basis for each decision in the change itself, not only in an email or chat thread.
- Separation of duties: Confirm that the approver is not the same person who implements the change, because the approval only counts as control evidence if the roles are distinct.
Check that the CAB group membership matches your current approval matrix and that routing conditions are tested against real change types before go-live.
The compliance lead decides what the change records must prove for SOX IT general controls over program changes and then checks that GLPI produces it. The lead needs to know which business rule routes which change, who approved each validation step, and whether the record was altered after approval. GLPI can show much of this workflow, but it does not show what happened inside the code repository, and that gap must be documented.
- Map rules to the control narrative: Document which business rule routes which category of change to the CAB, so the auditor can trace the design of the control.
- Sample approved changes: Select changes from the period under review and confirm each has an initiator, an approval by someone other than the implementer, and a recorded decision.
- Review rule changes: Keep a record of who modified the business rules and when, because a changed rule alters the population of changes that get reviewed.
- Identify the code system boundary: Record where the deployment and source change evidence lives, because GLPI change records alone may not prove what code was released.
- Ask the auditor early: Confirm the sample population, retention period and evidence format the auditor expects before the period begins.
Ask your external auditor which evidence they will accept for the code side of the change and confirm the retention settings for GLPI history in your environment.
Evidence GLPI produces and how to keep it for auditors
GLPI can hold most of the change record an auditor will ask for, but the evidence is only as durable as the database, the configuration keys and the export routine behind it. The cards below cover each record type, how to preserve it, and which parts still need to come from the code system and the change board.
Change tickets with timestamps and requester
Each change record carries an opening date, the requester and the description of the modification. Auditors use these fields to confirm that a change was documented before it reached production. Check that requesters are linked to named user accounts rather than shared logins, and that the change number can be matched to the deployment ticket in your code system. Export the change list on a fixed schedule and store it outside the GLPI host so the record survives an instance rebuild. Confirm which fields your version exposes in exports before you design the report.
CAB routing records
Business rules for changes can route a major change to a Change Advisory Board group and set its status to pending validation automatically. The rule itself is evidence of the control design, so keep an export of the rule set with its version history. Test each rule with a sample change and record the outcome, because an auditor will ask whether the routing worked as written during the period under review. GLPI business rules for changes and problems describes the rule conditions to document.
Approval steps and approver identity
GLPI 11 added group approval requests and groups approvals by validation step, so each approval can show which group was asked, who answered and when. This is the core evidence for segregation between the requester and the approver. Confirm that approvers are individual accounts, that group membership was accurate on the approval date, and that no one approved their own change. Group membership changes are not stored as part of the change record, so export the group membership history from your directory source as well.
Status history and change log
The history log records status moves such as new, pending validation, approved and closed, together with the user who made each move. Auditors read it to find changes that skipped a step or were closed without approval. Preserve it with the database backup, because history rows are the first thing lost when logs are purged. Review the automatic actions and purge settings that affect history retention, and document any purge that ran during the audit period.
Linked problem and incident records
A change that resolves a problem or an incident should link to that record, so the reason for the change is traceable. Auditors use these links to test whether emergency changes were justified and followed up. Check that links survive your export format and that closed problem records remain readable. GLPI shows the relationship but does not decide whether an emergency change was appropriate, so the approval rationale still has to be written by the people who made the decision.
Database backups and retention settings
The GLPI update documentation requires a database backup, a file backup and a copy of the config directory including glpi.key and glpicrypt.key before any upgrade. Those backups are the only way to restore change history and to show what the record looked like at a past date. Keep the backup set for the audit retention period your policy defines, store the key files separately under access control, and test a restore into a non-production copy. Confirm the retention period with your auditors, since no standard fixes it for this evidence.
Configuring GLPI change approvals for an ICFR evidence trail
This sequence turns GLPI change records into a documented, repeatable approval trail that finance, internal audit and the external auditor can walk through. Each step closes with a check, so the evidence exists before the first audit request arrives.
Confirm scope with finance and the external auditor
Start with a short working session between the CIO or IT controls owner, the finance controller and the external auditor's IT team. Agree which financial systems and reporting processes depend on the programs being changed, and which IT general control areas the company's ICFR evaluation will rely on. Ask the auditor which change evidence they expect and in what format. The step is done when the agreed scope and the evidence list are written down and signed off by both sides.
Define which changes fall in scope
Using the agreed scope, classify change types that touch financial reporting programs, their infrastructure, data feeds and access to them. Separate these from changes that only affect operational efficiency, since the SEC guidance does not require evaluating controls that only affect efficiency. Record the categories, the owning teams and the systems in each category. The step is done when a reviewed classification table exists and each in-scope system is mapped to a change category.
Deploy GLPI on supported database and PHP versions
Install GLPI on infrastructure your organization controls, using the PHP and database versions listed in the GLPI installation documentation for the release you select. Check the current prerequisites page, since the GLPI 11.0 requirements and the main branch README differ. Put the web server document root on GLPI's public directory and back up the configuration keys before any upgrade. The step is done when the instance runs on a supported stack and a documented baseline backup exists.
Configure business rules for change routing
Create business rules for changes that route in-scope changes to the Change Advisory Board group and set their status to pending validation automatically. Test each rule against sample entries so that a change with the right category always reaches the correct group. Keep rule names, criteria and owners in a version-controlled record, since the rule set is itself a control. The step is done when test changes in each category route to the expected group and status.
Define approval groups and validation steps
Set up approval groups for each change category and define the validation steps, including who must approve before implementation and who must confirm closure. GLPI 11 supports group approval requests and approvals grouped by validation step, so use that model rather than individual approvers where the policy requires a group decision. Document segregation of duties, so the requester cannot approve their own change. The step is done when the approval matrix matches the written policy and a walkthrough shows each step recording who approved and when.
Link change IDs to commits and release tags
Require every in-scope change record to reference the commit hashes, pull or merge request IDs and release tags that carry the change into production. Use a consistent naming convention in your source control and deployment pipeline so the change ID appears in commit messages or pipeline metadata. Confirm with your code system team which fields your pipeline can populate. Auditors still need the code system's own records, including reviewer approvals, branch protection settings and deployment logs, because GLPI records the approval rather than the code. The step is done when a sample change traces from GLPI to a commit, a review and a deployment.
Set access control for approvers and administrators
Restrict who can approve changes, edit business rules and modify approval groups. Use GLPI profiles and entity-based access so approvers see only the changes they are assigned to, and keep administrative rights to change routing separate from approval rights. Review who holds these rights before the first audit period starts and record the review. The step is done when an access report shows that approvers, rule editors and administrators are distinct populations, with the review date recorded.
Test the workflow with sample changes
Run a set of sample changes through the full path, including a change that should be rejected, one that is approved, and one that is routed to the wrong group and then corrected. Include a change that bypasses the expected step to confirm that the record shows the gap. Compare each record against the evidence list agreed in the first step. Illustrative example: a sample change for a ledger interface should show the routing rule, the group approval, the linked commit and the production deployment tag. The step is done when every test case produces the evidence the auditor requested.
Document the procedure for audit walkthroughs
Write a procedure that explains the change lifecycle, the business rules, the approval matrix, the linkage to source control and how a reviewer pulls evidence for a given period. Include the export queries or reports that produce the change list, and name the owner of each control. Ask the external auditor to review the document before the audit period begins, and keep it under version control. The step is done when the procedure has been walked through with the auditor and the owners can produce a complete sample on request.
Questions buyers ask before outsourcing SOX change evidence work
Does GLPI alone satisfy SOX change management requirements?
No. SOX does not name a product, and no SEC rule or PCAOB standard publishes a catalog of IT general controls. GLPI can hold change records, approval steps and business rules that route major changes to a Change Advisory Board group, which gives management a system of record for part of the evidence. The SEC guidance in Release 33-8810 says the relevant IT general controls vary with each company's facts and circumstances. Program changes are one area management might consider. Auditors will still need the code side of the story, including source control history, build and deployment records and access to production, and those usually sit in other systems that must be linked to the GLPI change record.
What drives the effort of configuring GLPI change approvals for SOX?
Effort follows the number of change types, the approval rules and the systems whose changes touch financial reporting. Each change type needs a defined approver path, business rules for when a change is routed to a CAB group, and a clear status flow from submission to validation. GLPI 11 added group approval requests and approvals grouped by validation step, which affects how the steps are modeled. The work also includes deciding which IT general controls matter for the company's ICFR, since management only needs to evaluate controls that support reliable financial reporting. Ask any partner to show how each change type maps to a control objective before pricing the build.
What do finance, IT and the external auditor need to provide?
Finance should confirm which systems and processes feed the financial statements and what level of change risk is acceptable. IT owns the change policy, the CAB membership, the approver lists and the connection to source control and deployment tooling. The external auditor should be consulted early on the control design, because the auditor tests ICFR under PCAOB AS 2201 and assesses IT risks under AS 2110. Ask the auditor which change samples they will pull, what evidence format they accept and how they want to see approval timestamps and reviewer identity. Agreeing these points before the build avoids rework after the first walkthrough.
Can an internal team configure GLPI change evidence without a partner?
Often yes, if the team already knows GLPI administration and has SOX experience in change management. The harder parts are usually control design, documenting the rationale for each rule, and testing that approvals cannot be bypassed. An internal team also needs time to keep the design current as the GLPI version changes. A partner can be useful for scoping the control set, building the rules and producing a test pack that an auditor can follow. Whichever path you choose, ask who will own the control narrative after delivery and who will run the periodic review of routing rules.
How long does scoping and delivery take for SOX change evidence?
Duration depends mainly on how many change types, approval paths and source systems are in scope, and on how quickly finance and the auditor confirm the control design. A narrow scope with one change type and one code system is far shorter than a multi-entity program with several CAB groups and separate deployment pipelines. Scoping usually comes first and should produce a written list of change types, systems and control objectives. Ask for a schedule that separates scoping, configuration, testing and evidence walkthrough, and for the dependencies on each stakeholder. Because most engagements are fixed-scope, the written scope should state these milestones before work starts.
How does the GLPI version and upgrade path affect audit evidence?
The version determines which change features and approval steps exist, so the control design must match the release in production. GLPI 11.0 introduced grouped approval steps, and GLPI 12.0.0 added features such as step-up authentication for certain administrative actions, which can strengthen control over who changes business rules. During an upgrade, the update procedure requires backing up the database, files and config directory including glpi.key and glpicrypt.key, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Evidence created before and after an upgrade should be retained and explained, so the auditor can see that routing rules did not change without approval.
What should a quote for SOX change evidence work include?
A quote should follow from a written scope and list the deliverables clearly. Ask for the list of change types and systems covered, the control objectives each piece of evidence supports, the GLPI business rules and approval workflows to be built, and the integration points with source control and deployment tools. It should also state what the client must provide, such as policy documents and auditor input, and what is excluded, such as the audit itself. DeployOpen does not publish a price list. Costs are one-time for design and build, and may recur if the client retains ongoing support or periodic evidence reviews. Note that DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or attestations. For context on why some companies weigh attestation costs, the SEC's Release 34-88365 (March 2020) estimated that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average.
How to present the change evidence to the external auditor
The most useful preparation is a walkthrough of one change from request to deployment, traced through the same records the auditor will see. Pick a change that went through the CAB routing rule, then show the GLPI change record, the approval step and the group approval requests that cleared it, the status moving to pending validation and then to approved, and the link to the code review, pipeline run and deployment that followed. Walk the auditor through who raised the request, who approved it, and whether the approver was a member of the group the business rule routed to. Where a step happened outside GLPI, such as a code merge in a source control system, say so and show the reference that ties the two records together. Confirm before the walkthrough that the approval history and the change history still show the complete chain for that record.
Auditors usually select changes across the fiscal year rather than relying on one walkthrough, so build the population first. Export all changes to in-scope systems with their status, dates, requester, approvers and deployment references, and confirm with the auditor how they want the population defined and whether a report from GLPI is acceptable as the source. Ask whether the business rules for changes were active for the whole period, because a rule change partway through the year changes what a sample should prove. Document any changes that bypassed the normal route, such as emergency changes, and record how they were approved after the fact. Management's evaluation under Rule 13a-15(c) is documented separately: state the framework used, normally COSO's 2013 Internal Control, Integrated Framework with its general control activities over technology, map the program change control to that framework, and record the evaluation as of fiscal year end. The auditor, under PCAOB AS 2201 and AS 2110, decides whether the evidence is sufficient. DeployOpen prepares the records, population exports and documentation, but it does not issue attestations or audit conclusions.
How DeployOpen scopes and delivers SOX change evidence in GLPI
DeployOpen plans, implements, customizes, documents and supports self-hosted GLPI inside your own infrastructure. For change approvals as SOX ITGC evidence, we start from the change types and approval routes your finance and IT teams already use, then configure GLPI to produce records that map to them. Engagements are fixed-scope and agreed in writing before work starts.
How we scope
- Inventory which program changes touch financially relevant systems and which ones fall outside the ICFR evaluation.
- Document current change approval routes, approver roles and emergency change handling before any GLPI configuration begins.
- Agree in writing which GLPI change types, validation steps and CAB group routing rules are in scope, and which code system records are out of scope.
How we build
- Configure GLPI business rules that route major changes to the Change Advisory Board group and set pending validation automatically.
- Set up approval steps grouped by validation step, using the group approval requests added in GLPI 11, and test each route with sample changes.
- Link GLPI change records to the ticket, asset and problem records they reference, and verify the history log captures each status change.
How we hand over
- Deliver a written control narrative describing each GLPI change type, approver, routing rule and evidence location.
- Provide a test script and recorded results showing approved, rejected and emergency changes moving through the workflow as designed.
- Document the boundary between GLPI records and the source control, build and deployment evidence your auditors will still request.
How we support
- Support ongoing operation of GLPI change workflows through a retainer covering rule changes, upgrades and periodic control checks.
- Review business rule and group changes against the control narrative whenever approval routes or CAB membership change.
- Confirm with your external auditor which evidence formats and sample periods they expect before the first assessment cycle.
Sources and further reading
- GLPI 12 documentation: Business rules for changes and problems ↗
- GLPI 11.0 changelog ↗
- Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting, Release 33-8810 ↗
- 15 U.S.C. 7262, Management assessment of internal controls ↗
- PCAOB Auditing Standard No. 5 (now AS 2201) as filed with the SEC ↗
- COSO Internal Control, Integrated Framework Principles (2013) ↗
