PR.PS-05 unauthorized software: requirements and evidence

What PR.PS-05 requires and why unauthorized software prevention is hard

If a CSF 2.0 gap assessment or a customer questionnaire asks how you control software, the Subcategory behind the question is PR.PS-05. It expects that unauthorized software is prevented from being installed or run. NIST publishes four Implementation Examples that show what this looks like in practice: restricting execution to permitted software or denying prohibited software where risk warrants it, verifying the source and integrity of software before it is installed, using approved DNS services that block known malicious domains, and allowing only approved software to be installed. In plain terms, the organization decides what may run, checks what it is about to run, filters where its endpoints go, and stops installation outside the approved list. PR.PS-05 also absorbs part or all of CSF 1.1 DE.CM-7, which covered monitoring for unauthorized activity, so assessors may look for detection of unauthorized software as well as prevention.

The hard part is rarely the tool. Prevention depends on an accurate list of what is approved, and that list usually decays. Software inventories lag behind real installs, especially on laptops that are offline for long periods, on servers built from old images and on software pulled in by other applications. Exceptions are the second problem: a one-time waiver for a vendor utility or a test tool often never expires, so the exception list quietly becomes the policy. Developer tools are the third. Compilers, package managers, containers and scripting runtimes are needed to do the work, and blocking them outright breaks delivery, so teams need a documented, risk-based decision for each class of tool. Confirm with your own engineering leads which tool classes they depend on before you write the rule.

Before you commit to an approach, decide who owns the approved list, how an exception is requested, approved and reviewed, and which evidence will show the control working over time. NIST offers no certification or conformity assessment for CSF outcomes, so no body will issue a badge for PR.PS-05. An independent assessor will test whether your decisions are documented, applied and monitored. Ask any implementation partner to show how inventory data feeds the allowlist and how exceptions expire, because those two links determine whether the outcome holds up in an assessment.

Which endpoints, servers, pipelines and vendors fall under PR.PS-05

PR.PS-05 does not name which assets it covers. The organization decides that, and the answer determines whether the work is allowlisting on a few servers or a fleet-wide control set. Each asset class below changes who can install software, who approves it, and what evidence an assessor will ask to see.

User endpoints and laptops

Laptops and desktops are where most unapproved installs and browser extensions appear, so they are usually the largest part of the scope. Decide whether standard users can install software at all, or whether installs go through an approval workflow. Check that the endpoint fleet is fully inventoried, including devices that are off the corporate network for long periods, because those devices still need the control when they reconnect.

Servers and container hosts

Production servers should normally run only software that has been reviewed and deployed through change control, so execution restriction often fits here better than install approval. Confirm which hosts run a locked-down process list and which allow ad hoc packages. Container images are a separate question: check whether only images from approved registries can start in each cluster.

Build and release pipelines

Build agents, package repositories and deployment runners can pull and execute third-party code, which makes them a common path for unauthorized software. Scope them explicitly and verify source and integrity for every dependency or artifact they consume. Ask who can add a tool to a pipeline image and whether that change is logged and reviewed.

Privileged admin workstations

Administrative workstations carry the highest risk because a single unapproved tool can reach every system an administrator manages. Many organizations apply the strictest rule here, such as allowing only signed, approved binaries and blocking general web browsing from the same device. Confirm whether these workstations are separate from everyday devices and whether their software list is reviewed on a set schedule.

OT and fixed-function devices

Industrial controllers, kiosks, medical devices and similar fixed-function systems often cannot run endpoint agents or accept frequent changes. For these assets, the usual approach is to permit only the vendor-supplied software set and to document why any restriction tool is absent. Ask the vendor which execution controls the device supports and what changes would void its support terms before you set the rule.

Third-party managed devices

When a managed service provider administers endpoints or servers, the organization still owns the outcome, but the provider may control the installation tooling. Put execution and install rules into the service contract, and require the provider to supply the allowlist, denylist and change records as evidence. Confirm which party can override a block and how those overrides are recorded.

Where allowlisting ends and detection begins

PR.PS-05 is a prevention outcome. An assessor testing it will ask whether software that is not approved can be stopped from being installed or run, and will expect a control that blocks it at the point of execution or installation. Detection has a supporting role. When a prevention control cannot cover a system, such as a legacy host that cannot run an agent or a vendor appliance with a closed execution model, the organization should show a compensating detection capability, a documented reason prevention is not feasible, and a plan to close the gap. Detection alone, such as a query that finds unapproved software after it has already run, will usually not satisfy the outcome on its own.

The choice between allowlisting and denylisting is mainly a question of risk and operational effort. Allowlisting permits only named software, scripts or publishers to execute, which gives strong protection against unknown code but requires a maintained inventory, a change process for every new tool, and testing before updates land. Denylisting blocks known bad files, hashes or publishers, which is cheaper to start with but fails against anything not yet on the list. Many organizations apply allowlisting to high-value systems and denylisting or monitoring elsewhere, and document that split. Confirm with the vendor of your chosen control which rule types it supports (publisher, hash, path, certificate), how it handles scripts and interpreters, and whether it can run in audit mode before enforcement.

Every exception to prevention needs a recorded risk acceptance. The record should name the software, the systems affected, the business owner who requested it, the compensating controls, the approver with authority to accept the risk, and an expiry or review date. An assessor will look for these records and check whether reviews happened on schedule and whether exceptions were retired when the need ended. Ask your control vendor how exceptions are scoped and logged in the console, because a time-limited rule that is never removed becomes a silent gap. Your own change and risk management process should own the approval workflow, and an implementation partner can help define it, but the accepting role must belong to your organization.

How an assessor tests PR.PS-05, what evidence they ask for and where findings occur

This table walks through the five test steps an assessor typically performs for PR.PS-05, the evidence each step asks for, and the findings that appear most often. Read it as a preparation checklist: if your team cannot produce the listed evidence for a step, that step is where a finding is likely. The NIST mappings in the text below are informative only, so confirm how your assessor applies them.

Test approach	Evidence requested	Common findings
Inspect the policy and approved software list	Written software allowlisting or denylisting policy, the current approved list, its owner and the date it was last reviewed. Reference points include SP 800-53 Rev. 5.2.0 CM-7(2) and CM-7(5), which address least functionality and authorized software.	No approved list exists, or the list is out of date and does not match the policy.
Sample endpoints across the estate	Enforcement configuration exported from endpoint management or allowlisting tools, plus a current inventory showing which hosts the policy covers. Assessors often select samples from servers, workstations and cloud workloads.	Unmanaged endpoints or segments sit outside the inventory, so enforcement cannot be shown for them.
Trace an installation or execution attempt	Logs or tickets showing that an unapproved program was blocked, or that a new package was checked for source and integrity before installation. Look for verification records tied to the approved list.	Blocks are configured but no logs exist, or installers can run from user-writable paths without a check.
Test a known malicious domain through the approved DNS service	Resolver configuration showing the approved DNS service, and a test result showing a blocked domain. Reference points include SC-34 and CIS Safeguard 2.5 on software inventory and allowlisting.	DNS traffic bypasses the approved resolver, or the block list is not updated on a stated schedule.
Review exceptions	Exception register listing each approved deviation, its business reason, a named owner, an approval record and an expiry or review date.	Exceptions have no owner or expiry, and some remain open long after the stated need ended.
Confirm the mapping with the assessor	Ask the assessor which ISO/IEC 27001:2022 Annex A control 8.19 and CIS Safeguard 2.5 test procedures they will apply, because assessors use their own procedures.	The organization assumes a framework mapping satisfies the test without checking how the assessor will use it.

Implementing unauthorized software prevention in six steps

This sequence moves an organization from an undefined software posture to one where only approved software can install and run, and each step leaves a record an assessor can test.

Define scope and the execution policy
Start by naming the systems in scope and the risk that justifies control over software execution, such as servers holding regulated data versus general office endpoints. The policy owner, usually the CISO or head of IT with input from system owners, writes a rule set stating which software classes are permitted, which are prohibited and who may approve exceptions. The output is a signed execution policy with a defined scope. Confirm that the policy is consistent with your broader configuration and software management policies before an assessor reads it.
Build a software inventory baseline
Collect what is actually installed and running on each asset group before deciding what to block. Osquery can query running processes, loaded kernel modules and file hashes across hosts, and Fleet can present the results as yes or no policy checks per device. The platform engineering team owns the collection, and the security team reviews the output. The deliverable is a baseline export listing software names, versions, hashes and the hosts where they appear, dated and retained as evidence.
Choose allowlisting or denylisting per asset group
Decide, group by group, whether to permit only known-good software (allowlisting) or block known-bad software (denylisting). Servers with stable workloads usually suit allowlisting, while diverse user endpoints may start with denylisting for specific risks. NIST's Implementation Examples describe restricting execution to permitted software or denying prohibited software when risk warrants. The output is an approved list per asset group, with the rationale for each choice and the enforcement mechanism named, such as an operating system control or an endpoint agent. Confirm what enforcement capability your platform and operating systems actually provide before you commit.
Set source and integrity verification for installs
Define how software is verified before installation: the trusted source repositories, the signature or checksum method, and who may add a new source. Package repositories, internal artifact stores and code signing checks can all contribute, and the configuration should be tested against a sample install that is deliberately unsigned to confirm it is refused. The output is a verification standard document and test results showing both a passing install and a blocked one. These records give an assessor direct proof that the verification step operates.
Deploy approved DNS for outbound traffic
Route endpoint and server DNS queries through a resolver that blocks known malicious domains, so software that reaches command infrastructure is cut off even if it executes. NIST's Implementation Examples list the use of approved DNS services that block known malicious domains. The network or platform team configures the resolver, documents the approved service, and confirms that endpoints and servers cannot bypass it. The output is the resolver configuration, a list of blocked categories or feeds, and a test log showing a query to a blocked test domain returning a block response. Ask the resolver vendor or your operator which threat feeds are included and how often they update.
Run exception management with recurring review
Record every approved exception to the execution policy, including the business reason, the compensating controls, the named owner and the review trigger. Exceptions should be time-bounded in the register and reviewed on a schedule your policy sets, and the review should compare current host data against the approved list. Velociraptor hunts can collect artifacts across a group of systems to check for unapproved software, and Wazuh configuration assessment can flag deviations. The output is an exception register and recurring review records showing who reviewed each exception, what they found and what was changed. Confirm the review cadence with your auditor, since the framework does not set one.

Evidence that passes a PR.PS-05 test and how to keep it current

An assessor testing PR.PS-05 looks for proof that unauthorized software is actually blocked or detected, not only that a policy exists. The cards below cover the artifacts that usually carry that proof and how to refresh each one between assessments.

Approved software list with owners

This is the baseline every other artifact is measured against. Each approved application needs a named owner, a business purpose, the permitted versions or sources, and a review date. Keep the list under change control so every addition or removal has a ticket. Check that the list matches what the enforcement tool actually permits, because a list that drifts from the tool proves little. Schedule a quarterly owner review and export the list with its revision history for the assessor's sample period.

Enforcement tool configuration exports

Allowlisting or denylisting rules in endpoint or application control tools are the strongest evidence that execution is restricted. Export the active policy, including rule scope, target groups and enforcement mode (audit or block), and keep dated copies. An assessor will ask whether rules were in enforcement mode throughout the period, so record any switch from audit to block with a change ticket. Confirm the export format with your tool vendor, since exports differ by product.

Source and integrity check records

PR.PS-05 expects software to be verified for source and integrity before installation. Keep records showing which package repositories, signing keys or checksums were verified, who approved each artifact and when. Automated pipeline logs that show signature or hash verification failures are useful because they prove the check ran and blocked something. Store these records alongside change tickets so each installed version traces back to a verified source.

DNS filtering policy and block logs

Protective DNS that blocks known malicious domains addresses one of the Implementation Examples for PR.PS-05. Keep the current policy, the list of approved resolvers, and the category settings, then export block logs for the sample period. Review the logs for repeated blocks from the same device, since those can signal a compromise. Ask your DNS provider which log retention and export options are available, because retention limits can leave gaps in a sample.

Exception approvals with expiry dates

Every exception to the approved-software rule should be a documented decision with a named approver, a business reason, compensating controls and an expiry date. Assessors often sample exceptions to see whether any ran past expiry without renewal. Track them in a register that links to the enforcement change ticket, and run a recurring check that flags expired exceptions. An empty register can also raise questions, so confirm with your team that exceptions are being requested and reviewed.

Fleet compliance reports over time

Fleet-wide query results show which devices pass or fail checks such as the presence of unapproved software, running processes or unexpected kernel modules. Tools built on osquery, such as Fleet, can present pass and fail status per policy. Schedule regular exports and keep them with dates, so the assessor sees trend data across the period rather than one screenshot. Investigate failing devices and record the remediation, since a report showing failures with no follow-up is weak evidence.

Open-source tools that produce PR.PS-05 evidence

PR.PS-05 asks that unauthorized software be kept from installing or running. None of the tools in this group should be assumed to block execution on their own. osquery, Fleet and Wazuh can show which software is present and where a device drifts from policy, which supports the inventory and compliance evidence an assessor will request. Whether any component can stop a process from starting, through application control, allowlisting or a companion agent, depends on the platform and configuration, so confirm that with the vendor and in your own environment before you cite it as a control.

Inventory as the baseline: Queries that list installed software and running processes produce the data you compare against an approved-software list.
Drift as a tracked item: A Fleet policy that fails on a device, such as a prohibited tool being present, creates a visible item for remediation and a dated record.
Settings that influence execution: Wazuh checks files, directories and running processes against its policies, which helps show that settings meant to limit execution are in place.
Blocking components to confirm: Allowlisting, denylisting and source and integrity checks sit in the operating system, a security product or a deployment pipeline. Name the component that performs each one.
Protective DNS as a separate layer: A resolver that blocks known malicious domains is outside these tools. Confirm whether your DNS service provides this and retain its block logs.

Check, for each tool, whether its blocking action exists in your deployment and who owns the evidence it produces.

What meeting PR.PS-05 costs in money and effort

This table compares the cost components of preventing unauthorized software, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written, scope-based quote and to see where self-hosted open-source telemetry can reduce license spend while staff time remains the main cost.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Enforcement or allowlisting tooling	Mostly recurring license or support fees to the vendor, plus one-time deployment labor. Confirm license terms for each tool before purchase.	Number of endpoints, operating system mix, and whether enforcement is allowlisting or denylisting. Narrower permitted-software lists usually mean more upkeep.
DNS filtering service	Recurring subscription to a DNS provider or internal resolver, plus one-time configuration. Ask whether the service blocks known malicious domains as NIST's example describes.	Number of users and devices resolving through the service, and whether roaming laptops must be covered off-network.
Engineering time to build the baseline and policies	One-time for the initial approved-software list, source and integrity rules, and policy design. Ongoing revisions follow change.	Number of software packages in use, how many business applications need review, and how well current asset inventories (ID.AM) already exist.
Endpoint and fleet telemetry	Recurring if using commercial agents or hosted consoles. Self-hosted open-source query and policy tools can remove license spend while staff run and tune them.	Fleet size, query frequency, and log retention. Scheduling fewer or narrower queries reduces data volume and analyst review time.
Evidence upkeep and exception reviews	Recurring staff time to review exceptions, record approvals, and keep pass or fail results available for assessment.	Number of exceptions, change rate of approved software, and how many teams can request installs. Clear exception criteria and expiry dates keep this manageable.
External testing or review	Optional and periodic, paid to an outside tester or reviewer under a written scope. Confirm whether testing includes allowlist bypass attempts.	Size of the environment in scope, number of enforcement points, and whether results are retested after remediation.
Auditor sampling	Paid to the independent auditor or certification body per engagement. The organization owns the controls and evidence; the auditor does not design them.	Number of systems sampled, quality of evidence available on request, and how many exceptions the auditor must trace.

Who does what for PR.PS-05: your team, a partner and the auditor

Your organization owns CSF outcome PR.PS-05 and the decisions behind it. Your team decides which software is permitted, which execution rules apply to which systems, and whether a prohibited item can ever run under a documented exception. Those decisions reflect your mission, your risk appetite and your contractual obligations, so they cannot be delegated to a vendor without losing accountability.

Policy and approved list: Write the rule that defines approved software, who can request additions, and what happens to software that falls outside the list.
Exception decisions: Approve, time-limit and record every exception to an allowlist or denylist, including the business reason and the compensating control.
Day-to-day review: Review failing devices, unexpected installations and blocked-domain reports on a set cadence, and decide what to remediate.
Source and integrity criteria: Define which publishers, repositories and hash or signature checks are acceptable before software is installed.
Sign-off and records: Keep the signed policy, change approvals and review logs that show the control operates as written.

Before engaging a partner, confirm that named individuals in your organization own each decision above and that they can explain the approved list to an assessor.

Where PR.PS-05 programs usually fall short and how to close each gap

PR.PS-05 programs tend to fail at the edges: the inventory behind the approved list, the devices outside enforcement, and the paperwork that proves control over time. The cards below name six recurring gaps and a concrete remedy for each, so you can check your own program against them before an assessor does.

No software inventory behind the list

An approved-software list is only as good as the inventory it is checked against. If no one can say which applications are installed across the fleet, allowlisting rules are written from memory and drift quickly. Check whether your asset inventory (ID.AM) captures installed software per host and whether that data refreshes on a schedule. A remedy is to run a scheduled osquery query for installed programs and running processes, then reconcile the results against the approved list every month and record the differences.

Unmanaged endpoints outside enforcement

Prevention controls often cover managed laptops and servers while contractor machines, lab hosts and personal devices that touch corporate data sit outside the scope. An assessor will ask for the population the control covers and will test a sample of devices that were never enrolled. Confirm that the enforcement scope matches your device inventory, and where an endpoint cannot be enforced, require network restriction or a documented compensating control. Report the coverage percentage to the owner of the control each quarter.

Exceptions with no owner or expiry

Teams routinely request temporary exceptions to run a blocked tool, and those exceptions often outlive the project that needed them. An exception without a named owner, a business justification and an end date becomes an undocumented gap in PR.PS-05. Require a written record for each exception that states the owner, the risk accepted, the compensating control and the review date. Remove access automatically when the date passes unless the owner renews it with fresh approval.

Protective DNS limited to office networks

Protective DNS blocks connections to known malicious domains only when devices resolve names through the approved service. Many programs configure it on the office network, so laptops on home Wi-Fi, mobile hotspots and cloud workloads resolve names directly and bypass it. Check which resolvers each device class uses, and confirm that remote endpoints are pointed at the protected resolver or routed through an agent that enforces the same policy. Test the setting from an off-network device and keep the result as evidence.

Developer tool install paths left open

Developer endpoints often need package managers, browser extensions and scripted installers, and these are the most common routes for unapproved software to reach production. Standard blocking rules rarely cover them, so the control passes on paper and fails in practice. Identify the install channels each developer group uses, then restrict them to a vetted internal repository, verify package source and hash before installation, and monitor the package managers for installs outside that repository.

Evidence captured as a one-time screenshot

A screenshot of an allowlist taken during an audit shows the control worked once, not that it operates continuously. Assessors typically ask for records that span the audit period, including blocked events, exception approvals and periodic reviews. Automate evidence collection with a recurring policy or query whose results are stored with timestamps, such as a Fleet policy that reports which devices pass or fail a check, and retain the exports for the period your assessment covers. Confirm the retention period with your assessor before you rely on it.

Common questions about PR.PS-05 cost, effort and outside help

How much effort does PR.PS-05 take to meet?

The effort depends on how much software your organization runs, how many endpoints and servers need coverage, and how strict the permitted-software list has to be. PR.PS-05 has four Implementation Examples: restricting execution to permitted software or denying prohibited software when risk warrants, verifying source and integrity before installation, using approved DNS services that block known malicious domains, and allowing only approved software to be installed. Each one adds a different workload. Building the approved-software baseline is usually the largest one-time task, while keeping it current recurs with every new application, update and business request. Ask any vendor or partner to break its estimate down by these four examples and by the number of hosts in scope, so you can see which items drive the total.

Will an auditor certify that we meet the PR.PS-05 outcome?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Independent assessors can test your program against the CSF outcomes and issue their own findings, but those findings are not a NIST certificate. Your organization owns its controls and decides how to report alignment. An implementation partner can prepare the configurations, records and evidence for that review, but it does not issue reports or certificates. Confirm with any assessor exactly what they will deliver and how they will label it before you commit budget.

Can we run PR.PS-05 in-house without outside help?

Yes, many organizations do. NIST publishes the Subcategory outcomes and Implementation Examples openly, and the work is mostly configuration, process and record keeping. In-house teams usually struggle with three things: maintaining the approved-software list across many teams, testing allowlist rules without breaking business applications, and collecting evidence that is consistent over time. Outside help is most useful for a fixed-scope rollout, such as deploying osquery or Fleet policies across a defined fleet and documenting the results. Compare the cost of your own staff time against a written scope, and decide which parts you will keep internally, such as approval decisions, which should stay with the business owner.

What skills and staff time does this work need?

The work needs people who understand endpoint administration, change management and the applications your business depends on. Typically, the security team defines the rules, the platform or endpoint team deploys and maintains them, and application owners approve software requests. You will also need someone who can read query results and tie them to a Subcategory outcome. Staff time is heaviest during the first baseline review and then recurs as new software arrives. Ask a partner to name the roles it expects from your side and how many hours of staff time it assumes, so you can plan for those people before the engagement starts.

How long does a fixed-scope PR.PS-05 engagement take?

Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. The duration depends on the number of hosts, the number of applications to classify, the platforms in use and how quickly your teams can review approvals. No timeline should be promised before that scope exists. Ask for a written plan with milestones, the systems covered in each phase, the decisions your team must make and the point at which the evidence package is delivered. If a partner cannot tie its timeline to a defined scope, treat the estimate as provisional.

Does allowlisting break developer work and build pipelines?

It can, if it is applied too broadly or without testing. Developer tools, package managers, local scripts and build agents are the common sources of friction. Good practice is to start in a monitoring mode, identify which unapproved software actually runs, then add exceptions for approved development tooling and enforce only where risk warrants it. Source and integrity checks should be designed around your signed artifacts and internal repositories so that legitimate builds are not blocked. Test allowlist rules on a representative group of developer machines and build hosts before a broad rollout, and agree a fast approval path so teams are not blocked for long.

How should exceptions to approved-software rules be recorded?

Every exception should be recorded with the software name and version, the business reason, the named owner, the systems it applies to, the risk accepted, the compensating controls and an expiry or review date. Store these records in your change or risk register so an assessor can trace each exception to an approval. Use a consistent workflow so exceptions do not become permanent by default. Ask any tool or partner how its records can be exported, because the evidence is only useful if it survives an audit cycle and is easy to read.

Does protective DNS replace endpoint software control?

No. Protective DNS helps with one Implementation Example: using approved DNS services that block known malicious domains. It can reduce some outbound connections to known bad destinations, but it does not stop a program from being installed or executed on a host. PR.PS-05 also covers restricting execution, verifying source and integrity, and allowing only approved software to be installed, which require controls on the endpoint or server. Treat protective DNS as one layer alongside allowlisting or denylisting and integrity checks, and confirm with your tool vendor which of these behaviors it actually provides in your environment.

How DeployOpen scopes, implements and prepares PR.PS-05 evidence

DeployOpen plans, implements and documents controls that keep unauthorized software from being installed or run, inside your own infrastructure. We prepare systems and evidence for PR.PS-05, while your organization owns the control and an independent assessor reviews it.

How we scope

The written scope names the hosts, operating systems and fleets where PR.PS-05 controls apply.
It states which approach applies to each fleet: allowlisting, denylisting, approved-software-only installation or protective DNS.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure osquery and Fleet policies to check for unapproved processes and software on enrolled devices.
We set up source and integrity checks for software packages before installation in your build and deployment pipeline.
We test allowlist and denylist rules in a staging group before enforcing them across production endpoints.

How we hand over

You receive the approved software list, rule configurations and the owner assigned to each rule.
Documentation maps each rule to the PR.PS-05 Implementation Examples and the evidence it produces.
Exported policy pass and fail results and change records are delivered so your assessor can sample them.

How we support

Ongoing support, upgrades and continuous testing of these controls are available as a retainer.
Retainer work covers reviewing new software requests and tuning rules after fleet or policy changes.
Your team confirms with your assessor which evidence format and sample periods they will accept.