PR.PS-03: Hardware is maintained, replaced, and removed commensurate with risk

To meet the pr.ps-03: hardware is maintained, replaced, and removed commensurate with risk requirement, you must run a risk-based hardware lifecycle control: keep accurate inventories, define maintenance and end-of-life triggers by risk tier, and prove timely replacement and secure removal (including sanitization and chain of custody). Document owners, procedures, and recurring evidence. ¹

Key takeaways:

• Set risk-tiered rules for maintenance, replacement, and removal; “same schedule for everything” fails PR.PS-03. ¹
• Build audit-ready evidence from day one: tickets, approvals, wipe certificates, and asset records tied to each lifecycle event. ²
• Assign clear ownership across IT, Security, Facilities, and Procurement; lifecycle gaps often sit between teams. ¹

PR.PS-03 is a deceptively simple requirement that becomes operationally messy because hardware exists everywhere: endpoints, servers, network gear, OT/IoT, lab devices, and “shadow” equipment purchased outside standard channels. The requirement is not asking you to replace hardware on a fixed calendar. It’s asking you to make maintenance, replacement, and removal decisions that match the risk the asset creates for your organization. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing PR.PS-03 is to translate it into three measurable control outcomes: (1) you know what hardware you have and where it is, (2) you have defined risk-based criteria that determine how it is maintained and when it must be replaced, and (3) you can prove that removed hardware is handled securely (data sanitization, custody, and disposition). ¹

This page gives requirement-level implementation guidance you can hand to control owners. It prioritizes what auditors and assessors will test: governance, repeatable workflows, and durable evidence. ²

Regulatory text

Requirement (excerpt): “Hardware is maintained, replaced, and removed commensurate with risk.” ¹

What an operator must do: implement a hardware lifecycle program that:

• Maintains hardware appropriately for its role and exposure (patch-relevant firmware maintenance, break/fix processes, controlled configuration, and physical upkeep where applicable). ¹
• Replaces hardware when its continued operation creates unacceptable risk (for example: end-of-support, inability to patch, repeated failure, or inability to meet security baselines). ¹
• Removes hardware safely when it leaves service (secure wipe/sanitization where data is present, custody controls, and disposition records). ¹

Plain-English interpretation

PR.PS-03 means you must treat hardware like a managed risk object across its lifecycle. If an asset is higher impact (stores sensitive data, provides authentication, connects to production networks, supports safety operations), it needs tighter maintenance discipline, earlier replacement triggers, and stricter removal handling than low-impact assets. ¹

Target keyword (for audit mapping)

Use this exact control statement in your control library: “pr.ps-03: hardware is maintained, replaced, and removed commensurate with risk requirement.” ²

Who it applies to

Entities: any organization running a cybersecurity program, including regulated and non-regulated organizations adopting NIST CSF 2.0 as a baseline. ¹

Operational scope (include these explicitly):

• Corporate IT hardware: laptops, desktops, mobile devices, printers, peripherals with memory/storage. ¹
• Data center and cloud-adjacent hardware you own or control: servers, HSMs, network appliances, backup devices. ¹
• OT/IoT and facilities: badge readers, cameras, HVAC controllers, manufacturing equipment controllers, medical/lab devices, conference room systems. ¹
• Third-party managed hardware where you retain risk (colocation gear, leased devices, MSP-managed endpoints). Contractual ownership may differ, but your risk exposure remains. ¹

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

1) Assign ownership and governance

• Name a control owner (often IT Asset Management or Security) and define RACI across IT Ops, Security, Facilities/OT, and Procurement. ¹
• Define “hardware” for scope: include any device with compute, storage, or network connectivity that could affect confidentiality, integrity, or availability. ¹

Operator tip: Most PR.PS-03 failures are handoff failures: Procurement buys it, IT deploys it, Security never sees it, and Facilities disposes it. Fix the seams first.

2) Build a complete hardware inventory with lifecycle attributes

Minimum inventory fields to operationalize PR.PS-03:

• Asset ID, type, model, serial number (where available), location, business owner, technical owner.
• Environment and criticality: production vs. non-production; user endpoint vs. infrastructure; OT/IoT classification if applicable.
• Data handling: does it store sensitive data locally, cache credentials, or log sensitive content.
• Supportability: vendor support status (supported / end-of-support), firmware update capability, warranty/service coverage. ¹

If your CMDB is incomplete, start with what you can measure (endpoint management + network discovery + procurement records) and track exceptions with an explicit remediation queue. ²

3) Define a risk-tiering method that drives lifecycle decisions

Create tiers that map to actual operational differences. Example tier dimensions:

• Impact: business criticality, safety implications, regulatory data exposure.
• Exposure: internet-facing, remote access enabled, located in public areas, unmanaged network segments.
• Control strength: EDR present, disk encryption, secure boot, centralized logging, physical controls. ¹

Output: each hardware class or asset gets a tier (for example: “High / Moderate / Low”) and the tier dictates:

• maintenance requirements,
• replacement triggers,
• removal and sanitization requirements. ¹

4) Operationalize “maintained” with workflows (not policy text)

Implement three maintenance workflows and tie them to tickets:

• Preventive maintenance / health: monitoring alerts, capacity signals, failure prediction, periodic inspection for physical hardware in controlled spaces.
• Security maintenance: firmware updates, configuration baseline checks, crypto module health checks for specialized devices.
• Break/fix: incident intake, triage, replacement parts, escalation, post-repair validation. ¹

Define “maintenance complete” criteria for each tier (e.g., high-tier hardware requires documented validation steps and change approval). Keep the criteria short and testable. ²

5) Define replacement triggers that are explicitly risk-based

Replacement should happen because risk crossed a threshold, not because someone remembered. Common triggers to codify:

• End-of-support / end-of-life: hardware or firmware no longer receives security updates, or vendor support ended. ¹
• Inability to meet baseline: device cannot support encryption, secure boot, or required management agent. ¹
• Repeated reliability failures: recurring outages degrade availability beyond tolerance for critical services. ¹
• Role change: device is reassigned to a higher-risk function (e.g., promoted into production) and no longer meets tier requirements. ¹

Control design choice: document approved exception paths (risk acceptance) with compensating controls and a defined review cadence you can defend to auditors. ¹

6) Make removal and disposal defensible (security + traceability)

Removal is where breaches happen: “decommissioned” devices still contain data, keys, configs, or VPN profiles.

Minimum removal steps:

• Deauthorize and disconnect: remove from identity systems, MDM/EDR, VPN, monitoring, and network access control. ¹
• Sanitize data: apply a documented wipe/sanitization method appropriate to the asset’s data sensitivity and media type; capture wipe evidence. ¹
• Chain of custody: record who took possession, when, where it was stored, and who approved disposition. ¹
• Disposition: resale, recycle, return to lessor, destruction. Keep third-party disposition receipts where applicable. ¹

If a third party performs disposal, treat it like third-party risk: contract terms, service tickets, certificates, and spot checks. ¹

7) Prove the control operates continuously

Set recurring evidence collection so you can show the control works across time, not as a one-off cleanup. A lightweight approach:

• Monthly sample of completed maintenance and decommission tickets for each risk tier.
• Quarterly review of inventory for “unknown owner,” “unknown location,” and “unsupported” flags, with tracked remediation. ²

Daydream can help by mapping PR.PS-03 to a named control owner, required artifacts, and a recurring evidence request schedule so you are not rebuilding proof at audit time. ²

Required evidence and artifacts to retain

Keep artifacts that demonstrate policy + execution + traceability:

Governance

• Hardware lifecycle policy or standard referencing maintenance, replacement, and removal tied to risk. ¹
• RACI and control ownership assignment. ²

Inventory and risk

• Hardware inventory export with tier/criticality fields populated. ¹
• Risk-tiering methodology and decision criteria. ¹

Operations evidence

• Maintenance tickets (firmware/config changes, break/fix, inspections) with approvals where required. ¹
• Replacement records: purchase/refresh approvals, change records, asset swap documentation. ¹
• Decommission evidence: wipe logs/certificates, custody logs, disposal certificates/receipts, system removal screenshots/exports (MDM/EDR/NAC). ¹

Exceptions

• Risk acceptances with compensating controls and expiry/review condition. ¹

Common exam/audit questions and hangups

Auditors and assessors tend to test PR.PS-03 through these angles:

• “Show me how you decide when hardware must be replaced. Where is ‘commensurate with risk’ documented?” ¹
• “Prove removed assets no longer have access and no longer contain data.” ¹
• “How do you cover non-standard hardware: labs, OT, conference rooms, and one-off purchases?” ¹
• “What happens when you cannot replace an unsupported device?” Expect to defend compensating controls and risk acceptance governance. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails PR.PS-03	Practical fix
Treating lifecycle as an IT-only process	Facilities/OT/procurement actions create risk you still own	Add cross-functional RACI and require disposal handoffs into tickets. 1
Inventory without lifecycle fields	You can’t prove “commensurate with risk” without tier and supportability	Add required fields: tier, support status, owner, location, data sensitivity. 1
Replacement based on age alone	Age does not equal risk; auditors want rationale	Use explicit triggers: end-of-support, inability to patch, role change, baseline failure. 1
Decommission “checkbox” without wipe proof	Data exposure risk remains	Require wipe evidence and custody documentation before closure. 1
Exceptions with no expiry	Unsupported hardware becomes permanent	Require time-bound exception approvals and track them as a risk register item. 1

Enforcement context and risk implications (no case citations)

NIST CSF is a framework, so enforcement usually arrives indirectly: customers, regulators, or auditors treat lifecycle controls as baseline cyber hygiene. The practical risk is concrete: unsupported hardware tends to accumulate known vulnerabilities, and poorly controlled disposal creates data exposure through lost or resold devices. PR.PS-03 reduces both by forcing a defensible lifecycle posture tied to asset risk. ¹

Practical execution plan (30/60/90-day)

Because source-backed timelines are not provided for this requirement, use phases rather than day counts.

Phase 1: Immediate (stabilize and define)

• Confirm scope and define “hardware” categories (IT, network, OT/IoT, facilities devices). ¹
• Assign owner and publish a short lifecycle standard: maintenance, replacement triggers, removal steps, and required evidence. ¹
• Identify your highest-risk hardware classes and create interim removal requirements (wipe + custody) even before inventory is perfect. ¹

Phase 2: Near-term (operationalize workflows)

• Enrich inventory with owners, locations, support status, and risk tiers. ¹
• Implement ticket templates for maintenance, replacement, and decommission; include mandatory evidence fields. ²
• Establish an exception workflow for non-replaceable assets with compensating controls and tracked approvals. ¹

Phase 3: Ongoing (prove and improve)

• Run recurring sampling and evidence capture; keep exports and closed tickets in an audit repository. ²
• Review unsupported or unowned hardware lists and drive remediation through operational leadership. ¹
• Use tooling (asset management, MDM, EDR, NAC) to reduce “unknowns,” and track coverage gaps as risk items. ¹

Frequently Asked Questions

Does PR.PS-03 require a specific hardware refresh cycle?

No. PR.PS-03 requires maintenance, replacement, and removal decisions that match risk, not a fixed calendar rule. Your evidence should show the criteria you use and how you apply them. ¹

What counts as “hardware” for PR.PS-03—do printers and IoT devices count?

If the device has compute, storage, or connectivity that could affect confidentiality, integrity, or availability, treat it as in-scope. Printers and IoT commonly store data or credentials and often get missed in inventories. ¹

How do we handle hardware managed by a third party (MSP, colocation, leasing company)?

Document shared responsibility in contracts and procedures, then collect evidence that the third party performed maintenance and secure disposition. Keep tickets, certificates, and custody records as if you did the work yourself. ¹

What evidence is most persuasive for “secure removal”?

Auditors look for wipe/sanitization proof tied to the asset ID, plus chain-of-custody and disposition records. Also show deauthorization from MDM/EDR/VPN and removal from the inventory. ¹

We can’t replace an end-of-support device in an OT environment. How do we stay defensible?

Use a formal exception with documented risk acceptance and compensating controls, such as segmentation, restricted access, monitoring, and physical safeguards. Track the exception to closure with a plan, even if replacement depends on a larger program. ¹

What should a GRC team automate first for PR.PS-03?

Automate evidence collection and reminders: scheduled inventory exports, exception registers, and sampling of maintenance/decommission tickets. Daydream is a practical fit when you need consistent evidence requests mapped to PR.PS-03 and assigned owners. ²

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes