PR.PS-02 Software maintenance: requirements and evidence

What PR.PS-02 software maintenance and removal asks for

To show PR.PS-02 is met, you must demonstrate that software on your systems is kept current, replaced when it reaches end of life and removed when it is unauthorized or unneeded. PR.PS-02 sits in the PROTECT Function, inside the Platform Security (PR.PS) Category, and its outcome, paraphrased, is that software is maintained, replaced and removed in proportion to risk. The Subcategory is practical rather than abstract: an assessor will look for a working cycle of patching, replacement and retirement, tied to the risk your organization has accepted. NIST publishes six Implementation Examples for PR.PS-02. They cover routine and emergency patching within the timeframes set in your vulnerability management plan, replacing container instances with updated images instead of patching them in place, replacing software that has reached end of life, removing unauthorized or unneeded software, and planning for end-of-life support before it lapses. Read the exact wording in the NIST CSWP 29 PDF and confirm which examples apply to your environment. According to NIST's transition spreadsheet, PR.PS-02 absorbs part or all of CSF 1.1 PR.IP-12 and PR.MA-2, so programs that mapped to those earlier Subcategories should check their evidence against this one.

The risk behind this Subcategory is straightforward: unpatched or unsupported software is one of the most common ways attackers gain a foothold. Three things usually make it hard. First, inventory gaps mean you cannot patch what you have not recorded, so the asset inventory under ID.AM is a prerequisite. Second, container images are often rebuilt rarely and inherit vulnerable base layers, so ownership of image refresh must be explicit. Third, vendor-controlled software, such as appliances and SaaS components, may update on the vendor's schedule, so you need to know what the vendor patches and what you must do yourself. Cross-check your mapping against the SP 800-53 controls CM-11, MA-3(6), SA-10(1), SI-2 and SI-7, the ISO/IEC 27001:2022 Annex A controls 5.9 and 8.7, SP 800-171 requirement 03.14.01 and CIS Safeguards 2.2 and 2.3, using the NIST CSF 2.0 Reference Tool export. Treat those references as pointers to check, and confirm the wording of each standard with its owner.

Which software, systems and teams fall under PR.PS-02

PR.PS-02 covers software maintenance, replacement and removal in proportion to risk, so the scope decides which patches, images and retirements count. The cards below separate the component types that usually cause disputes and name who owns each one. Whatever the scope is, it must match what the vulnerability management plan covers, because that plan sets the timeframes.

Operating systems and vendor firmware

Host operating systems and the software packages on them are in scope because they are the most common targets for routine and emergency patching. Firmware-adjacent components such as BIOS or device firmware often sit with hardware teams under PR.PS-03, so record which team owns each update path. Check that every host appears in the asset inventory with an owner and a patch source, and that the plan states who approves out-of-cycle updates.

Applications and their dependencies

Internally built and self-hosted applications fall in scope with their runtime, frameworks and libraries. The application owner usually decides when to upgrade a framework, but security teams should confirm that end-of-life runtimes are flagged for replacement rather than left running. Include the test environment for any application that stores or processes sensitive data, since unmaintained staging systems are a common path into production.

Container images and base layers

Containers are in scope at two levels: the application image and the base image it is built on. Replacing a container instance with an updated image is an explicit PR.PS-02 practice, so the scope should say who rebuilds base layers and how often. The platform team typically owns base image rebuilds, while application teams own their own image contents. Confirm that a rebuild triggers redeployment, not just a new image tag in the registry.

Shared libraries and transitive packages

Shared libraries, including those pulled in indirectly by other packages, are easy to omit from a scope list because no one installs them by hand. Include them explicitly, along with the package manager lockfiles that pin their versions. Ask who receives alerts for a vulnerable transitive dependency and whether the vulnerability management plan treats it on the same timeline as a directly installed package.

SaaS and third-party managed components

Software that a provider operates is partly out of your hands, but it stays in scope for the parts you configure, integrate or depend on. Record which maintenance duties the contract assigns to the provider, which ones remain yours, and how you receive notice of changes or end-of-life dates. Supplier obligations belong with the GV.SC supply chain work, so the scope should cross-reference those contract terms rather than restate them.

Developer tooling and build pipelines

Compilers, CI runners, scanners and other developer tools can carry vulnerabilities and run with broad access to source code and deployment credentials. Include them in scope when they run on organizational infrastructure, and assign an owner for version tracking and removal of unused tools. The engineering leadership should confirm that abandoned build agents and unused plugins are retired on the same basis as production software.

How an assessor tests software maintenance and removal

This table walks through the testing steps an assessor typically takes for PR.PS-02, paired with the records requested and the findings that most often appear. Read it top to bottom as the sequence of an assessment, starting with the plan that sets the timeframes and ending with removal of software that should not be present. The organization owns the control and its evidence; the independent assessor tests it and issues the findings.

Test area	Test approach and evidence requested	Common findings
Vulnerability management plan and timeframes	Read the plan to confirm it defines patching timeframes by risk, names owners for routine and emergency patches, and states how exceptions are approved. Confirm the plan is current and was approved by the accountable role.	Timeframes exist only in an informal runbook, or no timeframe is set for emergency changes.
Sample of routine patch cycles	Select a sample of patch cycles across different asset groups and compare each deployment date with the timeframe in the plan. Request scan or patch management reports, change tickets and deployment logs. The sample size and selection method are set by the assessor.	Patches applied after the defined window with no documented exception, or assets missing from the patch scope.
Emergency patch records	Select emergency changes and trace them from the vulnerability identification to the approval, deployment and verification steps. Request the change record, the approval trail and the post-deployment scan showing the fix.	Emergency changes approved after deployment, or no record that the fix was verified.
Container image replacement records	Confirm that container instances are replaced with updated images rather than patched in place. Request image build records, registry tags or digests, and deployment history showing the running image changed.	Running containers still use outdated base images, or image rebuilds are not linked to the vulnerability that prompted them.
End-of-life tracking	Review the software inventory for versions past vendor support and check whether each has a documented replacement, a funded plan or a risk acceptance with an expiry date. Request the inventory, vendor support status records and any approved exceptions.	End-of-life components with no owner, no replacement plan or open-ended exceptions.
Removal of unauthorized or unneeded software	Compare installed software on a sample of systems against the approved inventory and the removal records. Request removal tickets, configuration baselines and the results of recent discovery scans.	Unapproved packages or unused services remain on production hosts, and removals are not recorded.
Ownership and independence	The organization owns the control and produces the evidence. The independent assessor selects samples, tests the evidence and issues the findings. A partner that prepared systems and records does not issue findings on them.	Evidence is assembled only for the assessment window, with no routine records between assessments.

How to put a patch, replace and remove cycle in place

This sequence turns PR.PS-02 from a policy statement into a repeatable cycle in which each piece of software is kept current, replaced before support lapses, or removed, with a record that shows why. It produces the timeframes, tickets and decisions an assessor will ask to see.

Confirm the software inventory
Start from a list of every software product, version and host in scope, including operating systems, container base images, libraries, agents and SaaS components that run on your infrastructure. The owner of the asset inventory (usually IT operations or platform engineering) produces it, and it is done when each entry names an accountable owner, a version and the systems where it runs. Without this list, patching and removal decisions cannot be proven, so confirm the inventory against your CMDB or discovery tooling before moving on.
Set risk-based timeframes in the vulnerability plan
Write the timeframes for applying patches into your vulnerability management plan, separated by severity, exposure and asset criticality. The security lead drafts them and the risk owner approves them. The output is an approved timeframe table that states, for each risk class, how quickly routine and emergency fixes must be applied. Confirm the exact periods with your own policy and any contractual or regulatory requirements, because NIST does not prescribe them in the Core.
Define routine and emergency patch paths
Document two paths: a routine path for scheduled updates and an emergency path for vulnerabilities that are actively exploited or exposed to the internet. Each path names who approves the change, how testing is done in a non-production environment, and how rollback works. Operations staff own the procedure, and the output is a written runbook that the change process references. A path is in place when a test change moves through it from ticket to verified deployment.
Schedule container image rebuilds
Containers do not patch in place, so the platform team schedules rebuilds of container images from updated base images and replaces running instances with the new ones. Each rebuild is recorded with the image digest and the scanner report. GitLab Community Edition container scanning, which uses Trivy, can produce a JSON report and a CycloneDX SBOM for each build, and that output becomes the evidence that the replacement happened. Confirm that your registry and deployment pipeline support this flow before relying on it.
Track end-of-life dates for every product
Record the vendor end-of-life or end-of-support date for each product in the inventory, and assign an owner to plan replacement before that date. The output is a life cycle register with a review date and a documented replacement or accepted-risk decision for any product nearing the end of support. Ask each vendor for its published support dates in writing, because these dates drive replacement budgets and should not be assumed.
Run removal reviews for unneeded software
Review installed software on a set cadence to find packages that are unauthorized, unused or superseded. Owners justify each retained item, and the rest are scheduled for removal. Detection can use scanner output and runtime tools such as Falco, which evaluates Linux syscalls against YAML rules and can alert on unexpected process execution. The output is a removal decision log that records the item, the owner, the decision, the approver and the completion date.
Verify closure and feed results back
Confirm each patch, rebuild, replacement or removal is closed by checking that the scanner no longer reports the finding and the inventory reflects the change. DefectDojo, which imports findings from more than 500 tool report formats and deduplicates them, can hold these records in one place so that findings are tracked from detection to closure. Feed missed timeframes and recurring exceptions into the next plan review. This closing step is the one most teams skip, and assessors often find that tickets were closed without a scanner re-check.

Which evidence shows software is maintained and removed

PR.PS-02 is tested by records that show decisions, actions and outcomes over time, not by a single snapshot. The cards below cover the artifacts an assessor usually asks for, what each one must prove, and how to keep it current between assessments.

Vulnerability management plan timeframes

The written plan sets the patching windows that PR.PS-02 refers to, with separate timeframes for routine and emergency patches. An assessor checks that the windows match the risk ratings in the plan and that the owners named in it actually follow them. Keep the plan under version control and record each approved change with a date and approver. Confirm that the plan is reviewed on a set schedule and that the review is recorded.

Before and after scan results

Scan reports taken before and after a patch cycle show whether the vulnerability was actually removed. Greenbone Community Edition stores results in PostgreSQL and schedules scan tasks, so the same scan task can produce comparable reports over time. Assessors look for matching scope, consistent scan settings and a clear link between each finding and the change that closed it. Export the reports on a schedule and keep them with the change record they support.

Patch change records

Each patch needs a change record showing what was applied, to which assets, when, by whom and whether it was tested first. Assessors sample records and trace them back to the vulnerability and forward to the scan that confirmed the fix. Records that exist only in a chat thread are hard to defend. Keep tickets linked to the affected asset identifiers and retain them for the period your own policy or contracts require.

Container image version history

For containerized systems, PR.PS-02 is evidenced by rebuilt images that replace older instances. Trivy, run by GitLab container scanning, produces a JSON report and a CycloneDX SBOM for each image build, which shows the packages and base image in use. Assessors check that images are rebuilt on a schedule or after critical fixes and that running instances match the approved tag. Keep the build artifacts and the registry history together, so the rebuild dates can be shown for any period.

End-of-life register with planned replacements

A register lists each software product in use, its vendor support end date, its owner and the planned replacement or upgrade path. Assessors check that products nearing end of life appear before support ends and that exceptions carry a documented risk acceptance with an expiry date. A register that is not updated after an upgrade misleads the reader. Review it on the same cycle as the asset inventory and export a dated copy each time.

Removal and decommissioning records

Removal records prove that unauthorized or unneeded software was uninstalled, not just disabled. For each removal, the record should name the software, the systems affected, the reason, the approver and the verification step, such as a rescan or a package inventory showing it gone. Assessors often compare these records with discovery results to see whether removed software reappears. Keep the verification output with the ticket and refresh the software inventory on a schedule so the comparison is possible at any time.

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

This table compares the main cost components of keeping software maintained and removed by risk under PR.PS-02, who is paid for each, and what moves it up or down. Read it as a checklist for a written scope: most of the effort is recurring staff time, and tooling spend can be low when scanners are self-hosted, but that does not remove the work of running the pipelines and evidence.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Scanning tooling and licenses	Recurring where commercial	Number of assets, container images and report formats; commercial scanner subscriptions	Self-hosted open-source scanners such as Greenbone Community Edition and Trivy-based GitLab container scanning remove license spend, but staff still operate them
Findings management platform	One-time setup, then recurring upkeep	Number of tools feeding findings and volume of duplicate results	Use DefectDojo (BSD-3-Clause) to import and deduplicate results from multiple scanners instead of tracking them by spreadsheet
Engineering time for patch pipelines	Recurring	Number of operating systems, applications and fleet changes; how often emergency patches are needed	Standardize build images, automate routine updates and define the timeframes in the vulnerability management plan so patching follows a repeatable path
Engineering time for container image replacement	Recurring	Number of base images, rebuild frequency and dependency churn	Rebuild images on a fixed schedule from maintained base images and retire unused images from the registry
Retirement and removal of end-of-life software	One-time per product, then recurring tracking	Number of end-of-life products, custom software and dependencies that block upgrades	Keep a software inventory with support end dates so removal planning starts before support ends
Evidence upkeep	Recurring	Frequency of audits, number of systems in scope and manual report assembly	Generate scan reports, SBOMs and change records automatically and store them in a single retained location
External testing or independent review	Recurring or per engagement	Depth of testing, scope size and whether an independent assessor reviews the process	Agree the scope in writing before work starts and test a defined sample of systems rather than the whole estate
Auditor sampling effort	Recurring per assessment cycle	Size of the population the assessor samples and how quickly the team can produce patch and removal records	Keep patch dates, approvals and removal tickets linked to each asset so samples can be pulled without manual reconstruction

Which open-source tools produce PR.PS-02 evidence

PR.PS-02 asks for software to be maintained, replaced and removed in proportion to risk, and the evidence is a record of findings, actions and removals over time. The four tools below each produce or consolidate part of that record, but none of them decides the timeframes, owns the decisions or closes findings on its own. Confirm coverage against your own environment before you rely on any of them.

DefectDojo for finding consolidation

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and offers a generic findings import. It deduplicates findings using per-tool hashcode fields, so a vulnerability reported by several scanners appears once in the record. For PR.PS-02, the team must still define patch timeframes in the vulnerability management plan, assign owners, and review open and closed findings against those timeframes. Confirm that each scanner you run has a supported parser.

Greenbone Community Edition for scan results

Greenbone Community Edition (OpenVAS) is licensed under AGPL-3.0-or-later. Its gvmd service schedules scan tasks, manages users and permissions, and stores results in PostgreSQL, while users run scans and review results in the Greenbone Security Assistant web interface. The stored results give you dated records of which installed software versions were flagged. You still need to decide scan frequency, define what counts as an unsupported or unneeded package, and document how flagged software was patched, replaced or removed.

Falco for runtime software changes

Falco (Apache-2.0) parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules. Its rules can flag events such as unexpected process execution or unauthorized file modification, and alerts can go to stdout, files, syslog, HTTP endpoints or programs. For PR.PS-02, these alerts help show whether software was changed or started outside the maintenance process. Rule tuning is your responsibility, and you should confirm that the rules you enable cover the removal and replacement events your procedure depends on.

GitLab Community Edition with Trivy scanning

GitLab Community Edition (MIT) includes container scanning that uses Trivy to find vulnerabilities in container images, including base images and OS packages. Each scan emits a JSON report job artifact and a CycloneDX SBOM file, which list the packages in the image. This supports PR.PS-02's container replacement outcome, because a rebuilt image can be compared with the previous SBOM and report. Your team must still set rebuild and redeploy rules for emergency and routine patches, and confirm that the pipeline stores the artifacts for the retention period your audit requires.

What to keep in-house and what to outsource

Your organization owns PR.PS-02. No partner or auditor can accept accountability for whether software is maintained, replaced and removed in proportion to risk. Your internal team sets the rules that everything else depends on, and it must be able to explain those rules to an assessor without outside help.

Vulnerability management plan: Write or approve the plan that defines which findings are patched routine, which are patched as emergencies, and which timeframes apply to each severity. NIST's implementation examples for PR.PS-02 refer to timeframes set in this plan.
Timeframe approval: Decide and sign off the patching windows, container image replacement rules and end-of-life dates. Record who approved each exception and why.
Asset and software ownership: Name an owner for each application and platform so that someone can accept risk, schedule downtime and confirm removal of unneeded software.
Change and exception handling: Run the approval path for deferred patches and retained end-of-life software, with compensating controls and an expiry date.
Operating the plan: Review scan results, track remediation and report trends to leadership.

Before engaging any partner, confirm that your team can name the approvers, the timeframes and the owners for each system in scope.

Where organizations usually fall short on PR.PS-02

PR.PS-02 asks that software be maintained, replaced and removed in proportion to risk. The gaps below share one root cause: the work happens, but nobody defined the timeframe, owner or record that would let an assessor verify it. Each card pairs one gap with the fix that closes it.

No defined patching timeframes

Teams patch when a vendor advisory catches their attention, so there is no baseline to measure against. PR.PS-02 implementation examples tie routine and emergency patching to the timeframes in the vulnerability management plan, so an assessor will ask for those timeframes first. Fix it by writing separate windows for routine and emergency patches, then checking scan results against them each cycle. Confirm the exact windows with your risk owners rather than copying a generic figure.

Container images rebuilt only by memory

Application containers keep running the image they shipped with long after a base image or library has a known fix. NIST's implementation examples expect instances to be replaced with updated images, which only happens when a rebuild is triggered on a schedule or by a scan result. Fix it by making image rebuilds a pipeline step that runs on a defined cadence and whenever a new base image is published, then redeploying the replaced instances.

Base images unpatched between releases

Teams often patch application code but leave the base image and OS packages untouched between feature releases. Container scanning tools such as Trivy, used in GitLab's container scanning job, report vulnerabilities in base images and OS packages, so the gap is visible if someone reviews those reports. Fix it by scanning base images on the same schedule as application code and recording which findings were accepted, deferred or fixed.

End-of-life software with no owner

Software past vendor support stays in production because no one is accountable for replacing it. PR.PS-02 covers replacing end-of-life software and planning for end-of-life support, and an assessor will look for a named owner and a dated replacement plan. Fix it by keeping an inventory of versions and support end dates tied to asset records, and assigning each end-of-life item to an owner with a replacement or documented risk acceptance.

Unauthorized software removal not recorded

Unneeded or unauthorized packages are sometimes removed quietly, so there is no evidence that the removal happened or why. PR.PS-02 includes removing unauthorized or unneeded software, and that outcome cannot be shown without a change record. Fix it by logging each removal with the asset, the reason, the approver and the date, and by checking that the asset inventory reflects the change.

How much effort does PR.PS-02 take and can we do it ourselves?

How much effort does meeting PR.PS-02 take?

No researched figure exists for the effort, so ask any partner for a written estimate tied to your scope. PR.PS-02 asks that software is maintained, replaced and removed in proportion to risk, so the effort follows from how many systems, operating systems, container images and applications you run and how mature your patch process already is. Effort rises when inventories are incomplete, when patch windows require manual coordination, or when many components have reached end of life. It falls when patching is automated, container images are rebuilt from maintained base images, and the vulnerability management plan already defines timeframes.

How long does it take to be ready for an assessment?

No researched duration is available, so confirm timing against your own environment and the assessor's requirements before you commit to a date. Readiness depends on whether you already have a software inventory, a documented vulnerability management plan with timeframes, a record of patch and removal decisions, and evidence that end-of-life software has been retired or has a plan. Gaps in any of these usually take the longest to close. Ask your implementation partner to break the schedule into phases with deliverables you can check.

What does the work need from our internal team?

Your internal team owns the decisions: which software is in scope, the patch timeframes by risk, which versions are retired and who approves exceptions. Engineers must provide access to asset inventories, scanner and pipeline output, and change records, and they must run or approve the patch and rebuild cycles. A partner can prepare the tooling and write the procedures, but the people who operate the systems must be able to explain and repeat the process. Plan for named owners in platform engineering, security and the business units that run the applications.

Can a small team do PR.PS-02 alone?

A small team can cover the outcome if the environment is small and the process is simple, and NIST's Small Business Quick-Start Guide (SP 1300, February 2024) cites PR.PS-02 when it suggests that small businesses patch software and operating systems regularly and turn on automatic updates. Where the estate spans many systems or regulated data, one or two people usually cannot run inventory, scanning, patching and documentation alongside daily operations. Consider a fixed-scope engagement to build the process, then decide which steps your staff can sustain.

Can an assessor help us implement PR.PS-02?

No. An independent assessor evaluates whether your controls work and can report on them, but it should not design or implement them, because that would compromise its independence. Implementation help comes from an implementation partner, which prepares systems, scanning and patch workflows and evidence, and the organization keeps ownership of its controls. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications.

How does NIST CSF 2.0 differ from certification?

NIST CSF 2.0 is a voluntary framework, and NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans to develop a conformity assessment program. Your customers may still ask you to show alignment, and that alignment is usually shown through your own documented assessment or a third-party assessment report, not a NIST certificate. Standards such as ISO/IEC 27001 do have accredited certification, so confirm with your customer which form of evidence they accept.

What should we ask for in a written quote?

Ask for a fixed scope listing the systems, operating systems, container images and applications included, plus the Subcategory outcomes and the evidence each deliverable produces. Request the assumptions behind the estimate, the phases and their acceptance criteria, which costs are one-time and which recur, such as scanning, patch support and retainers, and what the client must provide, including access and named staff. Also ask who performs the final review, what happens when scope changes, and which parts remain the organization's responsibility. Confirm the figures in writing before work starts.

How DeployOpen prepares PR.PS-02 software maintenance evidence

DeployOpen helps organizations build the patching, replacement and removal records that show PR.PS-02 is working in practice. The organization owns its software maintenance decisions and its CSF outcomes, while DeployOpen plans, implements and documents the self-hosted tooling and evidence trail behind them inside the client's own infrastructure.

How we scope

Each engagement starts with a written scope that names the systems, software inventories and vulnerability management timeframes covered by PR.PS-02.
We confirm which patch windows, emergency change paths and end-of-life review cycles the client already defines and which need to be written.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work begins, with quotes following from that scope.

How we build

We deploy self-hosted scanning and findings tools, such as Greenbone Community Edition and DefectDojo, to record vulnerabilities and track remediation against agreed timeframes.
We configure container image scanning in GitLab Community Edition so image updates and SBOM outputs are generated as part of the delivery pipeline.
We test the workflow end to end with the client's team, confirming that findings, patches, image replacements and removals each leave a reviewable record.

How we hand over

We document the maintenance procedures, owner roles and evidence locations so the client's staff can run the process without DeployOpen present.
We deliver an evidence map linking each PR.PS-02 Implementation Example to the logs, scan reports, change tickets and removal records that support it.
Assessors, auditors or certification bodies remain responsible for any independent review, and we confirm with the client which evidence they expect to receive.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered and accepted.
We can review scanner coverage, tool upgrades and end-of-life dates for the self-hosted platforms as part of a retainer agreed in writing.
Changes to scope, such as new asset classes or new software platforms, are handled through a written change to the original scope before work proceeds.