PE-20 Asset monitoring and tracking: requirements

What PE-20 asset monitoring and tracking asks for and when it applies

PE-20 requires the organization to use defined asset location technologies to track and monitor the location and movement of defined assets within defined controlled areas, and no SP 800-53B baseline selects it. The control is therefore a decision the organization makes during tailoring, not a default. Two blanks drive the requirement: the assets (for example, specific servers, storage arrays, laptops, removable media or spare components) and the controlled areas (for example, a data hall, a secure storage room or a defined floor of a facility). The organization also chooses the location technologies, such as radio frequency tags, barcode or RFID scanning at portals, or sensor-based systems. Until those three elements are named in the system security and privacy plan, an assessor has nothing concrete to test.

The risk PE-20 addresses is the loss, diversion or unauthorized movement of equipment and system components. A rack server removed from a cage, a drive carried out of a data hall or a spare controller moved to an unapproved room can expose data or disrupt service without triggering any logical control. Organizations usually add PE-20 when their risk assessment shows that a specific class of hardware is high value, sensitive or hard to replace, or when an applicable requirement or contract calls for location awareness. Because SP 800-53B leaves it out of the low, moderate, high and privacy baselines, the decision should be recorded with its rationale so that an assessor can see why it was included or why it was deliberately excluded.

The hard part is defining the assets and areas precisely. Teams often list "all hardware" or "the data center," and neither gives a tracking program anything it can enforce. Confirm with your asset inventory owner which component classes must be tracked, which areas are controlled, and how movements are authorized, and align that list with the asset inventory maintained under CM-8. Ask whether your tracking method can confirm location at the granularity you chose, and whether it records movement into and out of each defined area. Independent assessors will test whether the defined scope matches what is actually tracked, so keep the definitions, the tracking records and the assessment evidence consistent with one another.

Which assets, areas and teams PE-20 brings into scope

PE-20 only works when the organization defines what it tracks, where it tracks it and who holds custody. Each card below is a scoping decision the organization sets for itself, and the decisions connect because the same asset and delivery records also serve CM-8, PE-16 and PM-8.

Defining the asset classes

Decide which classes of equipment fall under PE-20: servers, network gear, storage arrays, removable media and laptops. Each class needs a defined identifier and location attribute so monitoring can answer where a specific component is. Check whether the component inventory already holds serial numbers and rack positions, since CM-8 inventory records are the most practical starting point for the same list.

Setting the controlled areas

Define which spaces count as controlled areas for tracking, such as data halls, cages and secured rooms. The boundary matters because PE-20 asks for monitoring within defined areas, so a location signal that stops at the building door does not satisfy it. Document each area, its access points and the assets expected to remain inside it, and confirm that the boundaries match the physical access control scope in PE-3.

Including mobile and shipped components

Decide whether components that move, such as spare drives, laptops taken offsite or hardware in transit, are tracked while they leave a controlled area. Movement outside the facility raises different questions about signal coverage and custody handoffs. Record the decision in writing, because an assessor will ask how the organization handles a component that leaves the facility and whether the rule was applied in practice.

Assigning custody across teams

Identify which internal teams hold custody of tracked assets, including facilities, IT operations, receiving and the security team, and which third parties, such as colocation providers, hardware maintainers and logistics firms, handle equipment. Each holder needs a named responsibility for updating location records. Gaps usually appear at handoffs, so write down who records a move and who verifies it.

Aligning with CM-8, PE-16 and PM-8

Confirm that the asset records behind PE-20 are the same records used for CM-8 component inventory, PE-16 delivery and removal, and PM-8 security and privacy program planning. Separate spreadsheets for each control create conflicting answers at assessment. The organization owns the definitions and the decision to adopt them; an implementation partner can help configure the shared records, but the organization approves what the records say.

How an assessor tests PE-20 asset monitoring and tracking

This table compares the three SP 800-53A assessment methods for PE-20 against the objects an assessor looks at, the evidence to prepare, and the findings that commonly come up. The single determination statement means the assessor reaches one conclusion for the whole control, so every row feeds that answer.

Method and object	Evidence to prepare	Common findings
Examine: procedures for asset monitoring and tracking	Written procedure naming the defined assets, the defined controlled areas and the location technologies in use, with owners and review dates	Procedure is generic, does not name assets or areas, or was never approved
Examine: documentation showing use of asset location technologies	Deployment records, tag or sensor inventories, and configuration showing which assets report location and where	Tracking tools exist but cover only part of the defined assets
Examine: system configuration documentation	Configuration exports for location-aware tools, including what is monitored, reporting intervals and alert settings (illustrative: a monitoring agent's inventory scope)	Configuration does not match what the procedure says is tracked
Interview: personnel with asset monitoring and tracking responsibilities	Named owners who can explain the tracking workflow, alert handling and how location exceptions are resolved	Staff describe a process that differs from the written procedure or cannot name an owner
Interview: legal counsel	Confirmation of any legal or privacy limits on tracking people, cameras or staff-carried devices in the defined areas	Monitoring scope was set without review of applicable legal requirements
Test: organizational processes for tracking and monitoring assets	Sample of recent asset movements traced from the location record to the approved change or delivery ticket, plus a walk-through of an alert	Location records do not match the asset inventory, and movements have no matching authorization

Implementing PE-20 asset monitoring and tracking in six steps

This sequence takes PE-20 from a documented tailoring decision to a first evidence set that an assessor can examine, test and interview against. Each step produces a record that the next step depends on.

Record the tailoring decision and its reason
Start by deciding whether PE-20 applies to the system at all. SP 800-53B does not allocate PE-20 to the low, moderate or high baselines or the privacy baseline, so the organization must add it while tailoring, based on risk or on an applicable requirement. The system owner, with the information security office and, where relevant, legal counsel, records the decision, the reason for it, and any requirement that drives it. The output is a signed tailoring entry in the system security and privacy plan. The step is done when an assessor can trace PE-20 from the baseline to a documented reason, including a decision to exclude it.
Define the assets and controlled areas
PE-20 requires the organization to define which assets are tracked and which areas they are tracked within. Assets might include laptops, servers, network equipment, storage media or other system components that move between rooms, buildings or sites. Controlled areas are the physical spaces covered by physical access controls, such as data halls, equipment cages or secure storage rooms. The facilities and asset owners draft both lists and the information security office approves them. The output is a scoped asset class list and a controlled area list. Confirm that every asset class on the list appears in the component inventory from the next steps.
Select and configure location technology
Choose the asset location technologies that will report the location and movement of the defined assets. Options range from badge or access logs tied to equipment, to tag-based or sensor-based location systems, to manual check-in and check-out logs for lower-risk assets. The choice depends on how often assets move, how much accuracy the risk decision requires, and what the facility can support. Engineers configure the tags, readers or logging points and test them against assets moved through the defined areas. The output is a configuration record and a test report showing which movements were detected. Confirm the vendor's accuracy and coverage claims with the vendor before relying on them.
Connect location records to the asset inventory
Location data is useful only when it is tied to a known asset record. Map each tracked identifier to an entry in the configuration management inventory, so that a location event names a specific component, owner and system. Open-source inventory platforms such as GLPI can hold asset records and locations, and endpoint agents such as the Wazuh Syscollector can report hardware and software details that help confirm the asset identity. Engineers build the mapping and an integrity check that flags untagged or unknown assets. The output is a reconciled inventory where each tracked asset has a location history source. The step is done when a sample of assets can be traced from the inventory entry to their recorded movements.
Set monitoring and exception handling procedures
Write the procedures that say who watches the location records, how often they are reviewed, and what counts as an exception. Examples of exceptions include an asset leaving a controlled area without a logged check-out, an asset appearing in an unexpected location, or a tag going silent. Each exception needs a defined path to the incident response or facilities team and a record of the outcome. The procedures should name the personnel with asset tracking responsibilities, since assessors interview them. The output is an approved procedure and an exception log template. Confirm that the review cadence is set by the organization and matches its own risk decision.
Collect a first evidence set
Before the first assessment, gather the artifacts an assessor will examine: the tailoring entry, the asset and area lists, the technology configuration and test report, the inventory mapping, the monitoring procedure, and a sample of location records with their exception follow-up. Run a short walkthrough where the responsible staff demonstrate tracking for a few assets, which also prepares them for interviews. Document any gaps as plan of action and milestones items rather than hiding them. The output is an evidence package indexed to PE-20 and its assessment objects. The step is done when an independent assessor, not the implementation team, can reproduce the trace from decision to recorded movement.

Using GLPI and Wazuh as inventory evidence for PE-20

PE-20 asks for asset location technologies to track defined assets within controlled areas. The tools below can hold and report the asset records and endpoint inventory that such tracking depends on, but neither one determines where a device physically is.

GLPI Assets as the asset register

The GLPI Assets module records computers, monitors, network equipment, peripherals, printers, phones and racks. Entries can be typed in by staff or pushed automatically by the GLPI Agent through native inventory, which is built into GLPI from version 10. Use it to hold the authoritative list of defined assets and their assigned location, room or rack. Before relying on it, confirm which asset classes your scope names and whether location fields are updated by people or by a feed you control.

Wazuh Syscollector endpoint inventory

The Wazuh Syscollector module collects hardware, operating system, network interfaces, installed software, services and users from each endpoint. It stores this data in the Wazuh indexer and shows it in dashboard inventory views and reports. This gives you a system-side record that a device exists and is online, which helps you spot unexpected components. It does not report physical position, so an assessor will still ask how a location is established.

Matching the two inventories

A useful evidence set compares the GLPI asset register with the Wazuh endpoint inventory. Devices seen by Wazuh but absent from GLPI, or listed in GLPI but silent in Wazuh, are exceptions to investigate. For example, a server that reports to Wazuh while GLPI shows it in a different room would be a finding in an illustrative review. Document the reconciliation cadence and who signs off on the exceptions.

What neither tool proves

Neither GLPI nor Wazuh is a physical location technology. They do not use RFID, GPS, Bluetooth or other signals to find equipment, and a recorded room or rack is only as accurate as the people or processes that update it. If PE-20 applies to your system, you must confirm location capability with the vendor of your tracking hardware or a separate location system. Ask the vendor to state exactly what it measures and how often.

What meeting PE-20 costs and what drives the cost

This table breaks the cost of meeting PE-20 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No figures are supplied for this control, so use the table to structure a written scope and quote request rather than to estimate a budget.

Cost component	Who is paid	One-time or recurring	What drives it
Location technology or licenses	Hardware or tag vendor, or software licensor if a commercial tool is chosen	Both: hardware is one-time, subscriptions and maintenance recur	Number of defined assets, number of controlled areas, reader and tag coverage, hardware dependencies
Engineering time to integrate with the asset inventory	Internal staff or implementation partner	One-time, plus updates when the inventory schema or tools change	Number of inventory sources, data quality in the asset register, how location data is linked to records
Open-source inventory platform	Internal staff or implementation partner for setup; no license fee for the GPL-licensed components	One-time setup, recurring hosting and patching in your own infrastructure	Self-hosting capacity, integration with location systems, whether agents can run on each asset class
Evidence upkeep	Internal asset owners and compliance staff	Recurring	Frequency of location reviews, volume of movement records, how often defined assets or areas change
External review or testing	Independent assessor or testing firm, if engaged	Recurring or per engagement	Scope of the assessment, whether location tracking is tested as a control or only as documentation, number of areas sampled
Auditor sampling	Independent assessor (paid by the organization)	Recurring with each assessment cycle	Number of assets and areas sampled, quality of location records, whether reconciliation to physical checks is clear
Scope and risk decision	Internal risk owners, legal counsel, possibly a consultant	One-time, revisited on significant change	Whether PE-20 is added during tailoring, number of asset classes that carry risk, applicable legal requirements

Evidence that passes PE-20 and how to keep it current

PE-20 is assessed through documents, configurations, records and people, and none of them stays accurate on its own. Each card below names one artifact an assessor is likely to request, what it must show for this control, and how to refresh it between assessments so it still matches the facilities and assets as they exist today.

Tailoring decision record

PE-20 is not in any SP 800-53B baseline, so the first thing an assessor asks is why it was added. Record the decision that supplemented the baseline, the risk or requirement behind it, the defined assets and controlled areas it covers, and who approved it. Revisit the record when the system boundary, the regulatory scope or the asset classes change, and note the review date and outcome even when nothing changed.

Defined asset and area lists

The parameters in PE-20 must be defined by the organization, and the assessor will compare the lists against what is physically present. Keep a list of asset types in scope, such as servers, network gear, laptops and removable media, together with the controlled areas where they may be located. Tie each entry to an owner and update the lists when a new room, rack or asset category enters use.

Location technology configuration documentation

Document each asset location technology in use, including the device or tag type, where readers or sensors sit, how location data reaches the monitoring system, and who can change its settings. Configuration exports from the inventory or monitoring platform give assessors a stable reference. Re-export and compare after every hardware change, firmware update or move of a reader, since stale diagrams are a common finding.

Sample tracking records matched to the inventory

Assessors usually select a sample of assets and ask for their movement history, then check that the location in the tracking system matches the asset inventory and the physical location. Keep location events with timestamps and the identity of whoever moved an asset. Reconcile the inventory against tracking data on a schedule you define, and record every mismatch with its resolution.

Exception and review records

Assets that drop out of tracking, such as a device with a failed tag or one moved outside a controlled area without a record, need documented exceptions with a cause, a compensating measure and an owner. Keep the review notes that show someone examined the monitoring output and acted on it. Close exceptions with dated evidence, and track recurring exceptions as a signal that the tracking design needs change.

Interview notes from responsible staff

The assessment procedure calls for interviews with personnel who own asset monitoring and tracking, and with legal counsel on the requirements that drove the control. Prepare the people who run the process to explain the tracking workflow, the exception path and the reasons for the defined scope. Capture interview summaries with dates and roles, and refresh them when responsibilities move to new staff.

Who owns PE-20 work: your team, a partner and the auditor

Your organization owns PE-20 in full. Only you can decide which assets are in scope, which controlled areas they move through, and whether tracking is needed at all after you review the baseline you have selected and the risks you have assessed. SP 800-53B does not allocate PE-20 to the low, moderate or high baselines, so the tailoring decision to add it, and the reasoning behind it, belongs to your team and should be recorded in the system security and privacy plan.

Definitions: Name the defined assets (for example, laptops, racks, removable storage or equipment carrying sensitive data) and the defined controlled areas where tracking applies.
Tailoring decision: Record why PE-20 was added or why it was left out, linked to the risk assessment and any applicable requirement.
Monitoring procedures: Write who reviews location data, how often, what counts as an anomaly and who responds.
Accountability: Assign an owner for the asset location technology, its configuration and its exceptions.
Records: Keep the procedures and the review records that assessors will examine.

Before any partner starts work, confirm that these decisions exist in writing, because every other role depends on them.

Common gaps in PE-20 programs and how to close them

PE-20 is rarely failed for lacking a tracking product. Assessors more often find a control that was never scoped, a tool that was never deployed, or records that cannot be tied back to what the organization owns. The six gaps below are the ones to check before an assessor asks, each with one closing action.

No documented tailoring decision

PE-20 sits outside every SP 800-53B baseline, so it appears in a system's control set only if the organization added it during tailoring. Without a recorded decision that cites the risk or the applicable requirement that drove it, an assessor cannot tell whether the control was considered or simply forgotten. Close it by writing a tailoring entry in the system security plan that either adopts PE-20 with its scope or records why it is not selected, signed by the authorizing official.

Undefined asset or area scope

PE-20 depends on two organization-defined parameters: which assets are tracked and which controlled areas they are tracked within. Many programs leave both undefined, so monitoring covers whatever happens to carry a tag. Close it by listing the asset classes (for example, removable storage, laptops, rack-mounted components) and the named controlled areas in the system security plan, then checking that the list matches the physical areas where those assets are actually kept.

Location records not linked to the inventory

A location technology is only useful if each tracked item can be matched to a record of what it is, who owns it and which system it supports. Location data that lives in a separate tool from the asset register produces orphaned tags that no one can reconcile. Close it by giving every tracked asset one identifier shared between the location system and the inventory, for example by using the asset module of GLPI as the register and the Wazuh Syscollector inventory as a cross-check for endpoints.

No evidence of monitoring review

Showing that a tracking technology exists does not show that anyone looks at its output. Assessors look for a record that someone reviewed asset movements, what they found and what happened next, especially when an asset leaves a controlled area without a matching request. Close it by setting a review cadence in the procedure, keeping dated review records with the reviewer's name, and recording each unexplained movement as a ticket that is closed or escalated.

Procedures describing tools never deployed

Policies often name a location system, an agent or a dashboard that was planned but never rolled out, or that was switched off after a licensing change. An assessor who tests the stated process against the running environment will find the gap quickly. Close it by reviewing each procedure sentence that names a tool and confirming, with a screenshot or configuration export, that the tool is deployed, enrolled for the defined assets and generating records. Remove or correct any sentence that cannot be shown.

Related controls treated as separate work

PE-20 relates to CM-8 (system component inventory), PE-16 (delivery and removal) and PM-8 (critical infrastructure plan). When these are run by different owners, a component can be logged at delivery, tracked on the floor and inventoried under configuration management with three different identifiers. Close it by naming one owner for asset identity, and having the PE-16 delivery and removal records and the CM-8 inventory reference the same asset identifier that the tracking system uses.

PE-20 questions buyers ask before hiring outside help

Can our own team implement PE-20 without an outside partner?

Yes, if you have people who can define the assets in scope, select location technologies and run them. PE-20 asks the organization to define which assets are tracked, which controlled areas apply and which location technologies are used, so those decisions stay with you. An implementation partner can help configure inventory tools and collect evidence, but it cannot decide what your risk requires. Teams without experience in physical security, asset management or inventory tooling usually find the definition work takes longer than the technical setup. Start with an honest inventory of your current asset records to see how much gap there is before deciding who does the work.

What drives the effort and cost of meeting PE-20?

The main drivers are the number and type of assets in scope, the number of controlled areas, and whether location technologies already exist in your environment. Costs fall into a few groups: internal staff time for defining scope and reviewing results, the cost of any location hardware or subscriptions you choose, integration work to connect tracking data with your asset inventory, and periodic review and evidence collection. Setup costs are largely one-time, while monitoring, updates and reviews recur. Ask any quote to separate scoping, configuration, integration, documentation and ongoing support, and to state which assumptions about asset counts and sites it depends on.

How long does a PE-20 implementation take?

The duration depends on scope, and no timeline is supplied for this control. A small, single-site deployment with clear asset definitions can move much faster than a multi-site program with several location technologies and legacy inventories to reconcile. Time is usually lost in deciding which assets and areas count as in scope, in agreeing how movement is detected and escalated, and in producing the records an assessor will examine. A written scope with named deliverables lets you compare timelines between proposals. Ask each candidate to state its assumptions about site count, asset count and existing tooling.

What does PE-20 require from our staff?

PE-20 needs people who own the physical security and asset management processes, not only the systems that hold the data. Expect to involve facilities or physical security staff who know the controlled areas, asset owners who can confirm what should be tracked, IT staff who maintain the inventory and monitoring platforms, and legal or privacy staff if location data about people may be collected. Assessors also interview personnel with asset monitoring responsibilities, so those people must be able to explain the process. Plan time for these reviewers during definition, configuration and the first evidence cycle.

Is PE-20 required in a NIST SP 800-53B baseline?

No. PE-20 is not allocated to the low, moderate or high baselines or to the privacy baseline in SP 800-53B. Your organization adds it by tailoring a baseline when risk assessment or an applicable requirement calls for asset location tracking, such as an agreement, a sensitive facility or a specific asset category. Document the decision and the reason for it, because an assessor will expect the tailoring rationale to match your system security plan. Do not assume that a contract requirement for the baseline controls includes PE-20 unless the contract or agency says so.

What can an implementation partner provide to an auditor, and what can it not?

A partner can prepare the systems, configurations, inventories and evidence that support PE-20, such as tracking configuration, asset records, monitoring reports and process documentation. It can also help map that evidence to the assessment procedure so your team can present it clearly. It cannot issue an assessment report, attestation or certification, and it cannot determine that your controls are effective. Only an independent assessor or certification body does that. The organization remains responsible for its controls and for the accuracy of what it provides. Confirm with any partner, in writing, which deliverables are evidence preparation and which are assessor activities.

Which open-source tools can produce evidence for PE-20?

Asset inventory tools can supply records of the equipment in your environment, while the location technology itself is a separate choice. GLPI's Assets module manages computers, network equipment, peripherals, printers and racks, and its native inventory can record them automatically through the GLPI Agent, which supports the inventory side of asset tracking. Wazuh's Syscollector collects hardware and system data from endpoints for inventory views and reports. Neither tool tracks physical location by itself, so confirm with each vendor what location data it can hold and whether your chosen tracking technology can feed it. Document how the inventory links to the controlled areas named in your plan.

How DeployOpen scopes and prepares PE-20 evidence

DeployOpen treats PE-20 as an organization-selected control, because no SP 800-53B baseline includes it. We start by agreeing with the organization which assets and controlled areas are in scope, then prepare the open-source inventory and location records that would show tracking in practice. DeployOpen prepares systems and evidence only; an independent assessor decides whether PE-20 is met.

How we scope

Agree in writing which asset classes and controlled areas PE-20 covers.
Confirm with the organization the defined asset location technologies and the tracking frequency it has chosen.
Record the related controls CM-8, PE-16 and PM-8 so asset records line up with delivery and inventory processes.

How we build

Deploy a self-hosted GLPI instance inside the client's own environment to hold the asset register and racks.
Configure the GLPI Agent or Wazuh Syscollector to feed hardware and network inventory into that register automatically.
Test that a sample asset change is recorded, reported and traceable to the owning area.

How we hand over

Document the tracking procedure, asset location records and configuration settings for the assessor to examine.
Provide test records showing how tracking processes were exercised during the engagement.
Deliver a written evidence map so the organization can present PE-20 evidence to its independent assessor.

How we support

Fixed-scope engagements end with agreed deliverables, and any further work follows a new written scope.
Ongoing support, upgrades and continuous testing are available as a retainer for the tracking tooling.
Ask the organization's assessor to confirm the evidence format and the scope of assessment objects before work begins.