PR.PS-02: Software is maintained, replaced, and removed commensurate with risk

To meet the pr.ps-02: software is maintained, replaced, and removed commensurate with risk requirement, you need a risk-based lifecycle process that keeps software patched and supported, replaces or retires end-of-life software, and removes unauthorized or unnecessary software. Operationalize it by tying patching, upgrades, decommissioning, and exception handling to asset criticality and documented risk decisions. ¹

Key takeaways:

• Maintain a complete software inventory and classify it by business criticality and exposure; everything else is guesswork.
• Set risk-based rules for patching, replacing unsupported software, and removing unauthorized software, with documented exceptions.
• Keep defensible evidence: tickets, scan results, EOL attestations, change records, and approved risk acceptances. ¹

PR.PS-02 sits in the “Protect” function of NIST CSF 2.0 and translates into one operator expectation: you control software lifecycle risk instead of letting it accumulate. That means you can show, on demand, what software you run, whether it is supported, how it gets updated, and how you retire it safely when the risk is no longer acceptable. ¹

This requirement is easy to describe and hard to evidence. Most audit friction comes from gaps between teams: IT owns patch tools, Security owns vulnerability scanning, Engineering owns CI/CD dependencies, Procurement owns renewals, and GRC owns policy. PR.PS-02 forces a single story across those handoffs with risk-based prioritization, documented exceptions, and proof that actions actually happen. ¹

If you want a fast, exam-ready implementation, focus on three outcomes: (1) you can identify software that must be updated quickly, (2) you can replace or retire unsupported software on a planned path, and (3) you can remove unapproved software and prove you did. Then build the minimum governance needed to keep those outcomes recurring. ¹

Regulatory text

NIST CSF 2.0 PR.PS-02 excerpt: “Software is maintained, replaced, and removed commensurate with risk.” ¹

Operator translation (what you must do):

• Maintain software: keep it in a secure, supported state through patching, upgrades, configuration hardening, and dependency updates, prioritized by risk. ¹
• Replace software: plan and execute migrations away from software that is end-of-life, no longer supported, or cannot be made acceptably secure. ¹
• Remove software: uninstall or disable unauthorized, unnecessary, or high-risk software (including abandoned applications and libraries) and ensure it is not reintroduced without approval. ¹

Risk-based means you do not treat every patch, every system, and every dependency the same. You define categories (critical, high, moderate, low) and tie them to required timelines, escalation, and exception approval. ¹

Plain-English interpretation of the requirement

PR.PS-02 requires a software lifecycle control that prevents “quiet risk drift”: outdated operating systems, unpatched applications, stale third-party libraries, orphaned SaaS accounts, and tools installed by users outside standard controls. You are expected to identify software risk early, prioritize remediation based on business impact, and keep evidence that the process works repeatedly. ¹

Who it applies to

Entity scope: Any organization operating a cybersecurity program and using software to deliver business services, including regulated and non-regulated entities that adopt NIST CSF as their control baseline. ¹

Operational scope (include all that apply):

• Endpoints and servers: OS, agents, productivity tools, browsers, plugins.
• Infrastructure software: hypervisors, container runtimes, orchestration layers, VPN, EDR.
• Applications: internal apps, COTS, mobile apps, thick clients.
• SaaS: admin-managed apps where versions/configurations and access lifecycle matter.
• Development supply chain: open-source and third-party libraries, images, build tools, package registries, CI/CD runners.
  PR.PS-02 is not limited to “IT-owned” assets; it includes software introduced through engineering pipelines and third parties. ¹

What you actually need to do (step-by-step)

1) Assign ownership and define risk tiers

1. Name a control owner (often IT Operations or Security Engineering) and a GRC accountability owner for policy mapping and evidence.
2. Define risk tiers using criteria you can defend in an exam: data sensitivity, internet exposure, privilege level, business criticality, and change tolerance.
3. Map tiers to required actions: patching urgency, upgrade expectations, and when replacement is mandatory (for example, unsupported software).
   This is where “commensurate with risk” becomes testable. ¹

2) Build (or fix) your software inventory

1. Create an authoritative inventory that covers endpoints, servers, and application stacks; include version, owner, location, and business service mapping.
2. Capture software provenance: where it came from (approved catalog, package registry, manual install), who approved it, and how updates are delivered.
3. Track support status: vendor support window, end-of-life date, or internal sustainment plan for in-house software.
   If you cannot answer “where is it, who owns it, and is it supported?” you will struggle to show compliance. ¹

3) Set maintenance controls (patching and updating)

1. Define patch sources and methods by platform (endpoint management, server patching, container rebuilds, dependency updates).
2. Integrate vulnerability intelligence: use scan outputs and advisories to prioritize remediation by asset tier.
3. Operate a patch workflow with tickets or change records, including testing gates for sensitive systems.
4. Measure completion using system reports (patch compliance, scan deltas, package versions) and track exceptions.
   Auditors look for proof that maintenance is continuous, not episodic. ¹

4) Define replacement triggers and decommission pathways

1. Replacement triggers: end-of-life/unsupported software, chronic unpatchable vulnerabilities, failed security requirements, or unacceptable operational risk.
2. Create a replacement plan template: target state, timeline, compensating controls while migrating, and cutover/decommission checklist.
3. Require risk acceptance for any continued use past support, with executive approval tied to risk tier.
   Replacing software is usually a program, not a ticket; treat it like one. ¹

5) Remove unauthorized or unnecessary software (and prevent reintroduction)

1. Define “unauthorized software” (not in catalog, not approved for the tier, or installed outside managed channels).
2. Detect with endpoint tools, software inventory reconciliation, and CI/CD dependency scanning for engineering.
3. Remove or disable the software; document approvals for any exceptions.
4. Prevent recurrence: application allowlisting where appropriate, package repository controls, golden images, and least privilege to limit installs. ¹

6) Establish exception handling that will survive scrutiny

1. Document an exception process: request, risk rationale, compensating controls, approver, expiration, and review cadence.
2. Tie exceptions to inventory items (asset + software + version) so exceptions cannot become “blanket approvals.”
3. Expire exceptions by default; force renewal decisions.
   Risk-based programs fail when exceptions are informal or never revisited. ¹

7) Operationalize recurring evidence collection (audit-ready)

You need repeatable, timestamped artifacts. Daydream can help by mapping PR.PS-02 to a control owner, required evidence types, and a recurring collection schedule so the program produces audit-ready outputs continuously rather than during fire drills. ¹

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Governance artifacts

• Software lifecycle / patch management policy mapped to PR.PS-02.
• Risk tiering methodology and asset/software classification rules.
• Exception procedure with approval matrix. ¹

Operational artifacts

• Current software inventory export with versions, owners, and tier.
• Patch job reports and completion logs per platform.
• Vulnerability scan summaries showing remediation progress.
• Change tickets for high-impact patching and upgrades.
• End-of-life tracking list and replacement project plans.
• Unapproved software detections and removal tickets.
• Risk acceptances with compensating controls and expiration dates. ¹

Proving “removed”

• Uninstall logs, endpoint compliance reports, configuration baselines, or MDM/EDR attestations that the software is no longer present. ¹

Common exam/audit questions and hangups

• “Show me your inventory coverage. How do you know it’s complete?” Expect to explain data sources and reconciliation steps. ¹
• “How do you prioritize patching?” You need a documented link between tiering, vulnerability severity context, and required response. ¹
• “How do you handle end-of-life software?” Auditors look for a list, owners, plans, and approved exceptions. ¹
• “Prove you removed unauthorized software.” Screenshots are weak; exports and system-generated logs are stronger. ¹
• “Where are exceptions tracked, and who approves them?” Missing expirations and unclear authority are frequent findings. ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating PR.PS-02 as patching only.
   Fix: Add explicit replacement and removal workflows, with evidence requirements for each. ¹

2. Mistake: Inventory without ownership.
   Fix: Require an accountable owner for every business-critical application and infrastructure component; unresolved ownership becomes unmanaged risk. ¹

3. Mistake: Exceptions managed in email or chat.
   Fix: Centralize in a register tied to inventory items, with expiration and compensating controls. ¹

4. Mistake: Engineering dependencies out of scope.
   Fix: Include SBOM/dependency processes and container image rebuild expectations in the same control narrative. ¹

5. Mistake: No proof of removal.
   Fix: Define what “proof” means per platform (MDM report, EDR inventory delta, uninstall logs) and standardize it. ¹

Enforcement context and risk implications

No PR.PS-02-specific public enforcement cases were provided in the source catalog, so this page avoids naming cases. Practically, PR.PS-02 aligns to common control failures that show up in incident postmortems and regulatory criticism: running unsupported software, failing to patch known issues, and lacking asset/software visibility. The direct business risk is exploitability and operational fragility; the compliance risk is inability to evidence a functioning lifecycle process. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign control owner(s) and document PR.PS-02 mapping in your control library. ¹
• Publish a one-page standard: risk tiers, minimum maintenance expectations, and what triggers replacement/removal. ¹
• Produce an initial software inventory snapshot for in-scope systems; label gaps explicitly.
• Stand up an exception register with required fields and approvers.

Days 31–60 (operate the workflow)

• Connect vulnerability scanning/endpoint inventory outputs to a remediation queue.
• Start reporting maintenance completion by tier (even if coverage is incomplete).
• Build an end-of-life list with owners and either a replacement plan or an exception per item.
• Run an unauthorized software detection sweep and execute removals with tickets.

Days 61–90 (make it durable)

• Add recurrence: scheduled evidence pulls, monthly control checks, and a standard pack for audits.
• Integrate engineering dependency updates (libraries, base images) into the same reporting and exception model.
• Test governance: run a tabletop review of an end-of-life scenario and verify approval paths and evidence quality.
• Use Daydream (or your GRC system) to automate control-to-evidence mapping, reminders, and audit packet assembly for PR.PS-02. ¹

Frequently Asked Questions

Does PR.PS-02 require a formal software inventory, or can I rely on spreadsheets?

PR.PS-02 effectively requires an inventory you can defend and keep current, regardless of format. Spreadsheets can work early, but you still need ownership, versioning, and repeatable update sources. ¹

How do I define “commensurate with risk” without a mandated patch timeline?

Use risk tiers and document the rules that connect tier to maintenance urgency, replacement triggers, and acceptable exceptions. Auditors typically accept a well-reasoned, consistently applied method more than a one-size-fits-all number. ¹

What counts as “software” for PR.PS-02: operating systems, libraries, SaaS?

Treat OS, installed applications, infrastructure components, and engineering dependencies as in scope. Include SaaS where you manage versions/configuration, integrations, or admin-controlled security features. ¹

How do I handle business-critical legacy systems that cannot be patched?

Put them on a replacement track, document compensating controls, and require time-bound risk acceptance with senior approval. Keep evidence that the exception is reviewed and not forgotten. ¹

What evidence is strongest for “software removed”?

System-generated proof beats screenshots: endpoint management exports, EDR inventory deltas, uninstall logs, or configuration baseline compliance reports. Tie the proof to the specific asset and software identifier. ¹

Where does third-party software fit, especially embedded components?

Treat third-party software as part of your software lifecycle: track it in the inventory, monitor support status, and require updates or replacement based on your risk tiers. For embedded components, document how you receive updates from the third party and how you deploy them. ¹

Footnotes

1. NIST CSWP 29