.svg)
.svg)
In a word, yes. A PowerShell script edit affecting a system within SOX ITGC or ISO 27001 scope belongs in change management. There are two objects to govern here: the automation asset (including the code and execution configuration) and each run. Changing the asset requires change control while running an approved asset requires an execution record. Additional authorization is necessary when the run falls outside a preauthorized procedure.
Why script changes belong in the audit sample
A script that changes financial processing or access to an in-scope system can affect the controls an auditor relies on. Its file extension does not put it outside the audit boundary.
In SOX IT General Controls: What Auditors Test, Bullium’s William Bradshaw describes a typical change sample that includes a request, testing evidence, approval before deployment, and evidence that development and deployment responsibilities were separated. If your change-management process requires those records, an undocumented production script edit leaves you unable to prove that the required steps were followed.
The expectation extends beyond SOX. For entities in its scope, Annex 6.4 of Commission Implementing Regulation (EU) 2024/2690 for example requires procedures for managing changes to network and information systems.
ScriptRunner’s State of Microsoft Automation 2026 benchmark, drawing on more than 180 IT teams and over 45,000 automated scripts and workflows, reports that only 28% of respondents enforce full governance policies. This points at a clear governance gap even though it doesn't specify what percentage of script edits go undocumented.
The practical risk is that scripts accumulate in shared folders, administrators edit production copies, and nobody can connect the version that ran to its approval. Regardless of how clear that approval may have been from a company policy perspective, the evidence gap remains.
Best practices for Microsoft-centric IT operations
Start by defining what can change. The automation asset includes the script, parameter definitions and defaults, permitted targets, and execution credentials. Changing any of these can change the asset's behavior, even when the code remains untouched.
ISO 27001:2022 Annex A control 8.32 addresses change management for information processing facilities and systems. Applied to production automation, that means bringing script and configuration changes into the relevant change procedure.
ITIL 4 change enablement distinguishes standard changes, which are low-risk and preauthorized under a documented procedure, from normal changes requiring assessment and authorization. A routine script run can implement a standard change when it meets those conditions. But an approved script alone does not mean every possible run is then preauthorized.
Give every asset an owner and an approved, versioned state. Require edits to follow the applicable change process, with a second person approving production changes under your segregation-of-duties policy. Record each run’s version, initiator, parameters, targets, and result. Keep both histories connected throughout the required retention period.
Use that model consistently across Entra ID, Active Directory, Exchange, and Intune. The automation governance maturity path progresses from folders to Git, then to Git connected to controlled execution. Routine automation stays fast because its permitted use is defined in advance.
How to evaluate where the change boundary sits
Pick one production run from last quarter. Starting from its execution record, answer these three questions:
- Which approved script version ran?
- Who approved that version for production?
- Who or what triggered the run?
You should be able to follow the evidence without reconstructing events from filenames or asking an admin to remember specifics. A centralized automation platform brings the evidence together so you can trace a run back to its approved version. When records are scattered across repositories, tickets, and logs, answering the same questions takes additional research and cross-checking.
Git does record code changes. But it cannot by itself establish which working copy executed. A pull request approval only serves as deployment authorization when your release process explicitly makes it so and enforces that decision.
Microsoft’s PowerShell logging documentation explains that event 4104 captures script block content when logging is enabled. These host-level events provide useful execution evidence, but they do not inherently connect business requester, release approval, and repository version. The executing security context in many cases is just a service account.
Use this comparison to assess the evidence your operating model produces.
For financial entities subject to the relevant requirements, DORA Article 9(4)(e) calls for ICT change controls based on risk assessment. Peer approval may suit a low-risk edit; changes affecting financial processing or privileged access warrant deeper review. Define who may execute the approved automation separately.
Where ScriptRunner fits
The ScriptRunner platform combines Git-based version control with governed execution. Any Git provider including BitBucket, GitLab, or GitHub can be used. Scripts synchronize form the external repository, which is an advantage in multi-server environments.
Changes to Scriptrunner Actions are recorded in a change history that includes script content, parameter definitions and defaults, target systems and execution credentials, and approval or release status, with timestamps and user attribution. Roles distinguish between permission to modify Actions, execute them, and view audit data.
Execution records capture the initiating user or service, script version, parameters used, and result. Approval workflows support the ability to separate responsibilities between roles and record the approval. Retention settings control how long audit and execution data remain available.
These security, reporting, and compliance capabilities help teams document automation changes and executions. To evaluate your setup, select a recent run and check whether the available records identify the script version used, who approved the run, and who or what triggered it.
Put the change boundary into practice
Choose an automation that affects an important production service. Identify its owner, confirm its approved state, and trace one recent run back to the authorization. Any missing link gives you a concrete place to improve the process.
Then extend the review with five auditor questions for PowerShell automation, or assess the broader operating model in enterprise PowerShell automation for Microsoft IT.
Ready to see how ScriptRunner can help your organization stay audit-ready with PowerShell change management? Just book a demo and we'll be glad to walk you through it.