.svg)
.svg)
An enterprise automation governance policy defines the rules leadership approves for who may run which automation, on which systems, under which identity, with which approval, from which code, and with what record. The seven rules below connect those decisions to practical controls and evidence across Active Directory, Entra ID, Microsoft 365, and Azure.
Where does an automation governance policy sit among the policies you already have?
Our article on extending NIS2 and ISO 27001 controls to scripts explains how existing controls reach automation. The next step is writing the rules into security, access-control, and change-management policies, supported by an automation standard where useful. That is where automation governance and compliance for Microsoft IT becomes operational.
ENISA, the EU’s cybersecurity agency, lists topic-specific policies in its June 2025 technical implementation guidance, without a separate automation policy. Its advice supports the NIS2 implementing regulation, whose obligations apply to specified provider categories.
Missing enforcement has visible consequences. In a January 2026 audit of one Florida agency’s retirement system, the state auditor found application code could bypass the build process, no system-generated change list was available, and no mechanism prevented edits after peer review.
Who can run which automations, and when is approval required?
The italicized policy statements provide starting wording to adapt to your environment.
1. Scope and ownership. Every automation must have a named owner; listed change types must use the approved execution path. Enforce this at onboarding and release, linking runs to the registered automation. Leadership approves the controlled-change list: NIST’s SP 800-53 control catalog, Revision 5, places that organizational decision in CM-3.
2. Who and where. Roles may execute only their assigned operations against approved targets. Configure role checks, target restrictions, and execution permissions accordingly; delegated users need no administrator rights on targets. Retain the initiating identity, applicable role, operation, and target. Germany’s BSI, in its English 2022 IT-Grundschutz Compendium, likewise calls for binding administrator responsibilities and reserves security-relevant changes for administrators.
3. Approval by tier. Every operation must follow its assigned approval route. Leadership approves the lists; operators cannot waive approval because a task feels routine. NIST’s catalog includes dual authorization for designated privileged commands. ENISA supports different change workflows by criticality, scope, and urgency. The following tiers translate that approach into policy:
Emergency handling is an approved route with follow-up obligations. It gives nobody discretion to skip the process.
4. Identity and credentials. Use designated execution identities with minimum permissions; obtain secrets at runtime, never from script code. Enforce this through identity permissions and credential access, retaining the identity and associated access record. Shared accounts require approved exceptions. At Essential Eight’s highest maturity level, the Australian Cyber Security Centre’s June 2026 Information Security Manual specifies least privilege for users and services and just-in-time administration. Give AI agents the same governed execution roles, without standing administrator rights.
What must the policy say about code, records, exceptions, and review?
Several items involving sources, records, and exceptions should be covered by your automation governance policy.
5. Code source. Execute approved releases from the designated branch; route edits through change management. Enforce this through release controls and configured script sources, retaining the approved version and its script-change record.
Name an owner for execution elsewhere, including laptops, jump hosts, and batch files. Endpoint controls limit that activity, but their behavior varies: Microsoft documents that PowerShell scripts disallowed by App Control can still run in Constrained Language Mode. They do not replace the approved automation path.
6. Records. Each run must be traceable to its initiator, code version, execution identity, target, approval, and result. Assign responsibility for collecting and retaining that evidence. BSI’s administration guidance calls for attributable activities and documented changes. Microsoft’s script block logging records processed code content; that alone does not establish release approval or credential provenance.
For each rule, ask: what does the run record contain, and where does the supporting evidence live? Link it to the release record, applicable vault-access record, and change record. Specify retention for the complete chain.
7. Exceptions and review. Exceptions require a request, management approval, compensating controls, an owner, and an expiry date. Restrict break-glass accounts to authorized activities and centrally log their use. Australia’s ISM warns in the Australian Information Security Manual from June, 2026 that their activity is not directly attributable to individuals, so require supporting attribution records.
Management should review policy implementation at least annually, using violations, exceptions, and defined indicators, consistent with ENISA’s approach. Assign corrective action when records are missing, exceptions expire, or execution bypasses the approved path. Record review decisions and follow them through: an unreviewed exception can become the operating policy.
Where ScriptRunner fits
ScriptRunner provides controls you can configure to apply these rules when automation runs:
- Who and where: access groups assign roles; Actions bind scripts, parameters, credentials, and targets; server groups organize targets.
- Approval: four-eyes approval records approval details in the run report. Scheduled Actions use release approval in the change record, since they cannot use that approval workflow.
- Identity: connected vaults keep secrets out of scripts; gMSAs provide another supported execution identity.
- Code: Git synchronization uses the designated branch. A server-wide signed-scripts-only setting is optional, with locations under $PSModulePath exempt.
- Records: reports capture the starter, target, parameters, status, and result, with 365-day default retention.
Release records remain in Git, credential-access records in the vault, and change approvals in the change-management system. Your implementation must connect the applicable records. ScriptRunner governs runs routed through it; endpoint controls and their assigned owner cover execution elsewhere.
Where should an automation governance policy start?
Start with three lists: controlled change types, preapproved operations, and commands requiring a second person. IT leadership must approve those choices and assign responsibility for maintaining them.
Configure the execution path around those decisions, then verify that a sampled run connects to the required records. Give outstanding exceptions an owner, expiry date, and review date.
An effective automation governance policy states how each rule is enforced and which records show it was followed.
Once those rules operate, decide who else may use the approved operations through secure delegation and RBAC-controlled PowerShell automation.
Visit our website if you are interested to know more about how ScriptRunner handles Automation Governance and Compliance for Microsoft IT operations with a single source of truth for all your scripted automations.