.svg)
.svg)
Your ISO 27001 controls cover administrators, production systems, and the changes made to them. NIS2 holds management accountable for the same. Neither framework names the PowerShell scripts that run Active Directory, Entra ID, Microsoft 365, and Azure, and a script executing under a service account on a schedule is not an administrator, not a production system in the change-management sense, and not a change. It can therefore run outside every control even though they're fully implemented. Governance and compliance for PowerShell automation closes that gap by extending the controls you already operate to script execution: each applicable requirement gets a named PowerShell control, a named owner, and evidence produced during normal runs.
Why do PowerShell scripts slip past the controls you already run?
Access policies cover administrators. Your change process covers production systems. Meanwhile, a scheduled script can run under a service account, outside the approval and reporting processes those controls depend on.
ScriptRunner’s State of Microsoft Automation 2026 benchmark surveyed 180 IT managers and senior system engineers at enterprises with 1,000 or more employees between October and December 2025. Among respondents, 28% reported enforcing full governance policies, 58% applied partial controls, and 14% had none.
In many cases, partial governance can be difficult to spot because the paperwork looks complete. Consider a scheduled task on a jump host using a service-account password stored in plain text. Its log records a successful run. When an auditor asks who authorized the activity, however, the service-account name can't provide the answer. The questions auditors ask about PowerShell automation expose that gap.
Leadership accountability makes these types of situations even harder to leave unresolved. For covered entities, NIS2 Article 20(1) requires management bodies to approve and oversee cybersecurity risk-management measures and provides that they can be held liable for infringements.
An automation control gap therefore belongs on leadership’s agenda. It can also surface during an ISO 27001 surveillance audit, leaving teams to resolve nonconformities under a remediation deadline.
What does good PowerShell governance look like inside your existing controls?
Start with one control set and add a PowerShell column. For each applicable requirement, specify how it governs scripts, who owns implementation, and which evidence is available for review. A governed execution path makes gathering that evidence automatic during routine operations.
ENISA’s June 2025 NIS2 Technical Implementation Guidance supports building on frameworks already in use. Its accompanying mapping table, version 1.2 from August 2025, connects implementing requirements to standards including ISO 27001:2022 and NIST CSF 2.0.
The underlying Implementing Regulation (EU) 2024/2690 applies to specified digital infrastructure, ICT service management, and digital providers, including MSPs. ENISA’s guidance is advisory and can be useful beyond those entities; other organizations must assess their obligations under applicable national NIS2 law. The guidance is technology-neutral, so translating requirements into PowerShell controls remains your organization’s responsibility.
Begin with inventory and authorized scripts: you need to know which scripts exist before you can govern their execution. A log proves that a script ran on Tuesday at 2 a.m. It does not, by itself, prove permission to run.
The Center for Internet Security’s CIS Controls v8.1, Safeguard 2.7 sets the minimum technical control and explicitly covers PowerShell .ps1 files. This IG3 safeguard calls for technical controls, including digital signatures and version control, to allow authorized scripts and block unauthorized ones. Treat that as the floor. The mature target is authorized execution with evidence for every run: who requested it, which script version ran, under which identity, and with which approval. Signatures and version control are inputs to that evidence; they do not, however, produce it.
PowerShell execution policy cannot carry that responsibility alone; Microsoft states that it is not a security system that restricts user actions.
How do you prove only authorized PowerShell scripts run?
The best way is to build the proof across two layers.
Within the automation path, make privileged credentials available only to approved scripts whose identity and version are controlled through signing or version control. A signature or Git commit by itself does not suffice for approval. Your release process must establish which script version may perform which action, against which targets, and under whose authority. This is the layer that answers the auditor’s question, because it records who requested the run, which version executed, and under which identity.
At endpoints, App Control for Business works with PowerShell to block or restrict unapproved scripts, depending on the host, version, and policy. It is the backstop for scripts that have not yet been routed through the governed path. You'll still want to test the actual behavior: restriction is not the same as preventing execution altogether.
Automation controls by themselves can't govern scripts launched elsewhere on laptops or jump hosts. And endpoint enforcement does not establish the business requester or approver. Both layers must contribute evidence.
A simple test shows whether they do: can your team produce last week's privileged script runs and show the authorization for each one? Ideally, the answer will connect the executed version, the initiating person or service, the execution identity, the target, and the applicable approval. For scheduled jobs, it connects the run to the authorization for the job and its released configuration.
The same standard applies to every row in the matrix: for each mapped requirement, the question is whether evidence from actual script runs shows the control was applied. ENISA cautions that its mapping does not establish equivalence between frameworks, so an ISO control reference helps you locate the relevant work in your existing control set; it does not prove that PowerShell execution meets the NIS2 requirement.
The following starting matrix uses the implementing regulation’s point numbers and ENISA’s ISO mappings. Evidence examples adapt the guidance to PowerShell operations. Assign a named owner to every row in your working control register.
Make the operational decisions explicit. Define when script edits count as changes, establish who may run which actions and when approval is required, and keep automation credentials vaulted, scoped, and traceable in use. Each decision should leave evidence in the same governed workflow.
Where ScriptRunner fits
ScriptRunner is the execution layer behind the PowerShell column. Every run routed through it produces the evidence the matrix asks for.
Its central script repository and Git branch synchronization connect execution to the branch you release from while code review remains in Git. An optional, server-wide signed-scripts-only setting adds signature checking (locations listed in $PSModulePath fall outside that check).
Roles let delegated users run defined actions without receiving administrative rights on target systems. Connected vaults can hold execution credentials, while Just Enough Administration endpoints limit the remote operations that are permitted.
Execution reports show who or what started an action, which systems it ran against, the inputs it used, and the execution status and result. They also include approval details when an approval workflow is used.
Scheduled actions, however, cannot use ScriptRunner’s approval workflow. If your policy requires approval for these jobs, you'll need to record it through your change-management process.
This traceability has practical value. In Star-shl’s customer story, Senior IT Specialist Axel Haringa describes audits against NEN 7510, the Dutch healthcare information security standard: “The auditors are really satisfied with our system.”
The objective is to route privileged execution through that governed path so that what runs outside it shrinks to documented exceptions, with Windows endpoint controls as the backstop for what remains. The smaller the unrouted set, the less evidence has to be reconstructed by hand at audit time. Together, the two layers support the controls and evidence your organization must maintain.
Where should implementation start?
Open the control register your organization already uses. Add a PowerShell column, beginning with script inventory and authorized execution. Name an owner for each row, define the evidence required, and test whether the team can produce it before the next audit request.
Start with a bounded group of privileged production scripts. Account for their versions, credentials, execution locations, and approvals. Route that group through the governed execution path before you test, so the evidence in the matrix is produced by the run rather than assembled afterwards. Test an unauthorized execution attempt as well as a successful approved run. Expand coverage as the evidence becomes repeatable.
IT leadership should own this operating-model decision. The next step is choosing the enterprise PowerShell automation foundation beneath those controls and assessing the cost of building and maintaining it yourself.
Extending your existing controls to script execution, with explicit execution rules, accountable owners, and evidence generated during everyday operations is a practical method for establishing solid governance and compliance for PowerShell automation. It's also a great way to avoid unknowingly creating FrankenScripts.