.svg)
.svg)
Things your next auditor will want to know regarding Microsoft Powershell automation will likely include who triggered it, who authorized it, what exactly ran, and under what credentials. If you want to be audit-ready, every automated action in your organization must have these answers. The way you get there for Microsoft IT is through solid automation governance and compliance.
Why audits are scrutinizing automation
Auditors are now required to look at automation itself, not only the systems it touches, because of NIS2 Article 21, which covers access control and logging duties, as well as SOX ITGC change management sampling if one of your scripts touches a SOX-relevant system. At the same time, the scope of automation has steadily expanded to include identity, configuration, patching, monitoring, remediation, and more. For a handful of automated workflows, it's possible to use screenshots, ticket exports, and collecting log files manually from multiple locations. Most organizations, however, have a great deal more automation running. The recent survey by ScriptRunner, The State of Microsoft Automation 2026, found only 28% of organizations have implemented full governance for their Microsoft IT automation. That creates an audit-readiness problem.
The 5 big audit questions
1. Who triggered this run?
The auditor will be looking for the name of the human behind the execution, not the service account. But native Windows PowerShell logging records the security context under which a script executes. When automation runs under a shared or service account, the resulting log may identify that service account as the executor without identifying the individual who requested or approved the action. This is often the case for scheduled tasks. And in the case of shared admin accounts, it's impossible to know which human was in control at a given time, breaking the identity chain.
What allows you to always have the right answer to this question is binding requester identity to the execution record at the moment the automation runs. If you're not doing that, it's possible you might have a execution layer governance gap, also known as a Frankenscript.
2. Who authorized it, and before or after it ran?
The right answer here involves being able to provide evidence that goes beyond mere intent. ISO 27001:2022 control 5.3 for example requires organizations to separate the person requesting a change from the one authorizing it for sensitive systems. The person who requests or initiates a privileged change should not in such cases be the same person who approves, executes, or verifies it. This is referred to as the segregation of duties. An ad hoc approval in a ticket or chat may practically fulfill the requirement for a specific case, but that doesn't mean you're ready to answer the question during an audit. What works here is when you bind approval (and the person executing the automation) to the record that it ran.
3. Which version ran, with which parameters, against which systems?
Here, the auditor's goal is to determine whether you are managing changes properly. That means being able to provide evidence not only that a change took place, but what its content included and which systems were involved. Git history can offer proof of what was written and approved in source control. It does not answer on its own what actually ran in production.
For US organizations, the Public Company Accounting Oversight Board AS 2201 auditing standard for example tells auditors of U.S. public companies how to evaluate whether the controls that support reliable financial reporting are properly designed and operating effectively. Auditors need evidence of operating effectiveness here, not just written policies or source code. That applies for instance when PowerShell automation affects a financial system. To have the right answers, you need a centralized audit trail for your enterprise automation.
4. Which credentials were used, and where did they live?
Who ran the automation is not enough, auditors also need to know which credentials were used and how those credentials are managed (or aren't): which identity granted access, where was the credential stored, and whether its use was controlled.
NIS2 Article 21 access-control and MFA requirements apply to automation identities, too. Embedded secrets and shared service accounts weaken that evidence because they make it difficult to prove which automation was authorized to use a credential.
A stronger model for managing credentials retrieves credentials at runtime from a managed vault, scopes them to the automation, and records their use per run.
5. Can you show all of that for the whole audit period, from one place?
Retention and consolidation are the most frequent destroyers of audit readiness. Microsoft notes in its Azure Automation data security documentation that automation job data is retained for 30 days, while its guidance on auditing solutions in Microsoft Purview describes a standard audit retention window of 180 days.
That means a fiscal-year SOX sample cannot be supported from a 180-day window without a separate retained store. ISO 27001 control 8.15 likewise requires logs to be stored and protected against alteration, including by privileged users whose actions they record.
The solution is to retain one execution record for each run inside a single source of truth that you can query as necessary without reconstructing evidence across systems.
For more on PowerShell governance reporting for NIS2 and SOX compliance, see our reporting guide.
Scattered vs. centralized: the five questions side by side
The difference between scattered automation and governed execution becomes clearest when you put the auditor’s questions side by side.
Audit questionScattered scripts and scheduled tasksCentralized, governed execution
The risk with decentralized automation is not that you will have no evidence at all. It is that the evidence is incomplete, short-lived, or spread across too many systems to answer an auditor quickly and consistently. This is where decentralized PowerShell compliance blind spots begin to appear.
How ScriptRunner helps you stay compliant
ScriptRunner provides the centralized, policy-driven execution layer that turns each automation run into a traceable record rather than a collection of disconnected evidence.
Its core governance capabilities include an audit trail showing who ran what and when, with which parameters, built-in approval workflows for sensitive actions, and credential vaulting so privileged credentials can be managed outside the script itself.
That combination helps close the gaps described above by linking execution, authorization, and credential use in one governed workflow instead of leaving auditors to reconstruct the event from logs, tickets, and source control.
See our guide on making Microsoft automation audit-ready by default, for ways to eliminate governance gaps with a centralized platform.
Ready to discuss how we can work together to make your next audit a day in the park? Get in touch today to schedule a free, no obligation product demo.