PowerShell Script Policy Template for IT Teams (SC.L2-3.13.13)

A powershell script policy template should define who may create and run scripts, which systems may execute them, how scripts are approved and signed, what telemetry is retained, and how unauthorized execution is remediated. The template below gives IT teams an assessable policy structure for NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice SC.L2-3.13.13, which requires organizations to control and monitor mobile code.

Why does policy come before tooling?

Technical controls can block unsigned scripts, record PowerShell activity, and alert on suspicious behavior, but tools do not establish the organization’s authorized use cases. An assessor reviewing SC.L2-3.13.13 will generally need to see that the organization has defined which mobile code is allowed, who authorizes it, where it may run, and what happens when activity falls outside those boundaries.

For this practice, PowerShell should be treated as mobile code when scripts or commands are downloaded, transferred, distributed, or executed across endpoints, servers, and managed devices. The policy must address both administrator-created automation and scripts obtained from vendors, repositories, email, removable media, collaboration platforms, or the internet. A PowerShell policy template is most defensible when it names the technical configurations that enforce the written restrictions while avoiding a claim that a single setting, such as PowerShell execution policy, is a complete security boundary.

For example, Northline Engineering & Design, a 280-person engineering and design services firm, uses PowerShell to provision Autodesk Vault access, update project-file permissions, and maintain a Microsoft 365 CUI collaboration enclave. Its policy can authorize signed administrative scripts on designated servers while prohibiting project teams from running downloaded scripts on design workstations. The resulting boundary is understandable to users, enforceable by IT, and traceable for an external assessor.

What should a powershell script policy template include?

The following policy body is ready to customize. Replace every bracketed field before approval, retain the version history, and map the resulting technical evidence to the policy clauses.

POLICY TITLE: PowerShell and Mobile Code Control Policy
POLICY OWNER: [INFORMATION SECURITY MANAGER]
APPROVING AUTHORITY: [CIO OR AUTHORIZED EXECUTIVE]
VERSION: [VERSION]
EFFECTIVE DATE: [DATE]
REVIEW DATE: [DATE]

1. PURPOSE
[ORGANIZATION] controls and monitors the use of PowerShell scripts and
other authorized mobile code to reduce the risk of unauthorized code
execution, malicious downloads, unapproved automation, and misuse of
organizational systems or Controlled Unclassified Information (CUI).

2. SCOPE
This policy applies to all [ORGANIZATION]-owned, managed, leased, or
authorized endpoints, servers, virtual machines, cloud workloads, mobile
devices, administrator accounts, service accounts, and users that process,
store, or transmit organizational information or CUI.

3. AUTHORIZED USE
PowerShell may be used only for approved business, administrative,
security, development, or vendor-supported purposes. Authorized users are:
a. Members of [APPROVED ADMINISTRATOR GROUP];
b. Members of [APPROVED AUTOMATION OR DEVOPS GROUP];
c. Users specifically approved through [TICKET OR CHANGE MANAGEMENT SYSTEM].

PowerShell scripts must be associated with an approved ticket, change record,
standard operating procedure, or documented vendor requirement. Approval
records must identify the script owner, business purpose, affected systems,
approval date, expiration or review date, and required execution privileges.

4. SCRIPT SOURCES AND INTEGRITY
Scripts executed on production systems or CUI assets must originate from:
a. [APPROVED INTERNAL SOURCE REPOSITORY];
b. A vendor source approved by [SECURITY OR IT AUTHORITY]; or
c. A documented emergency response activity authorized by [INCIDENT RESPONSE AUTHORITY].

Production scripts must be code-signed using a certificate issued or approved
by [ORGANIZATION]. Scripts may not be executed from email attachments,
personal cloud storage, removable media, temporary download folders, or
unapproved public repositories unless specifically authorized and reviewed.

5. EXECUTION RESTRICTIONS
[ORGANIZATION] shall enforce the following:
a. PowerShell execution is restricted to approved users and approved devices;
b. PowerShell version 2.0 is disabled where technically feasible;
c. Windows PowerShell and PowerShell 7 logging is enabled on managed systems;
d. Application control permits approved signed scripts and approved
   administrative tools and blocks unauthorized scripts where supported;
e. Remote PowerShell access is limited to approved administrative systems,
   approved accounts, and approved network paths;
f. Users may not bypass execution restrictions through encoded commands,
   alternate hosts, downloaded interpreters, or unauthorized scripting tools;
g. Local administrator rights shall not be used to circumvent this policy.

6. MONITORING AND LOG RETENTION
[ORGANIZATION] shall collect and review PowerShell activity using endpoint
security tooling, Windows event logs, and [SIEM NAME]. At a minimum, monitoring
shall capture PowerShell script block logging, module logging, transcription
where enabled, security product alerts, and application-control events.

PowerShell security events shall be retained for at least [RETENTION PERIOD]
and protected from unauthorized alteration. [SECURITY OPERATIONS ROLE] shall
review high-severity alerts and investigate activity that indicates unauthorized
script execution, suspicious encoded commands, credential access, lateral
movement, defense evasion, or policy bypass.

7. EXCEPTIONS
Exceptions require documented approval from [INFORMATION SECURITY MANAGER]
and [SYSTEM OWNER], must include compensating controls, and shall expire no
later than [MAXIMUM EXCEPTION PERIOD] unless reapproved. Emergency use must be
documented in [TICKET SYSTEM] within [BUSINESS HOURS] after execution.

8. REMEDIATION
When unauthorized mobile code or prohibited PowerShell activity is detected,
[SECURITY OPERATIONS ROLE] shall isolate the affected device when warranted,
preserve relevant evidence, disable or reset affected accounts as appropriate,
remove unauthorized code, investigate root cause, and document corrective
actions in [INCIDENT OR TICKET SYSTEM]. Repeat violations may result in access
removal or disciplinary action under [ACCEPTABLE USE OR HR POLICY].

9. RESPONSIBILITIES
The Information Security function maintains policy requirements and monitoring
standards. IT maintains technical controls and approved script inventories.
System owners authorize business use. Script owners maintain code, signatures,
and supporting documentation. Users report suspected unauthorized scripts or
unexpected PowerShell prompts to [SERVICE DESK OR SECURITY CONTACT].

Which clauses should an auditor test first?

For Northline, an approved script that creates Autodesk Vault project folders would have an Azure DevOps repository link, a change ticket, a designated infrastructure owner, and a code-signing record. If Defender for Endpoint detects an encoded PowerShell command launched from a user’s Downloads folder, the incident record should show whether the endpoint was isolated, the file was quarantined, and the user’s permissions or training were reviewed.

Which attachments and exhibits are required?

A written script authorization policy is stronger when its operational records are controlled as attachments or exhibits. These documents let an auditor sample actual implementation rather than relying on verbal descriptions.

• Exhibit A: Approved Script Inventory. Include script name, repository URL, SHA-256 hash or release version, owner, purpose, affected systems, approval reference, signing status, and review date.
• Exhibit B: PowerShell Baseline Configuration. Document Windows Event IDs 4103 and 4104, transcription destination, PowerShell 2.0 removal status, AMSI coverage, and approved remoting configuration.
• Exhibit C: Application Control Rules. Export current Microsoft Defender Application Control or AppLocker policies showing approved publishers, paths, and signed-script requirements.
• Exhibit D: Monitoring Use Case Register. Include realistic detections such as encoded PowerShell command lines, Invoke-Expression, DownloadString, execution from user-writable directories, and attempts to disable Microsoft Defender.
• Exhibit E: Exception Register. Record exception owner, systems, justification, compensating controls, approver, start date, and expiration date.
• Exhibit F: Remediation Procedure. Define triage ownership, containment authority, evidence preservation steps, incident severity criteria, and required closure evidence.

How often should the policy be approved and reviewed?

The approving authority should approve the policy before it becomes effective, with the Information Security Manager maintaining the authoritative copy. Review it at least annually and whenever a material change affects PowerShell use, such as deployment of a new endpoint platform, acquisition of a managed service provider, migration to cloud administration, a significant incident, or a change to CUI system boundaries.

What common edits are needed by industry?

The control objective does not change by industry, but the authorized-use clause, approval workflow, and evidence set should reflect operational realities. The core script execution policy should remain consistent across environments that handle CUI.

Before the external assessment, map each clause in this policy to a live configuration, a retained record, and an interviewable owner so the organization can demonstrate both control and monitoring of PowerShell mobile code.