PM-32 Purposing: requirements and evidence

What PM-32 purposing requires and why it matters

PM-32 asks the organization to analyze the systems and components that support its mission-essential services or functions and confirm that they are used consistently with their intended purpose. When an assessor, contract owner or program lead asks for PM-32 evidence, they want to see that someone has identified what the essential services are, which systems and components sustain them, and that a documented review shows those resources are not being repurposed in ways that expand their exposure. PM-32 sits in the Program Management family, so it is deployed across the organization rather than being attached to a single system. SP 800-53B places Program Management controls outside the low, moderate and high baselines and outside the privacy baseline, so PM-32 is not a line item that a system security plan can satisfy on its own. Confirm with your assessor whether they expect the analysis at the program level, the system level, or both, and where the output will be held.

The risk logic is straightforward. A server, database or service account built for one purpose and then quietly used for another, such as a test workload running on a production database host or a reporting job sharing credentials with a payment process, widens the attack surface of something the mission depends on. The control targets that drift. It is hard for two reasons. First, the organization must agree on what its mission-essential services and functions are, which usually requires business owners, not only IT staff, to state them and rank them. Second, tracing which components support each essential service means following dependencies across hosts, containers, identity providers, network paths and third-party services, and those relationships often exist only in people's heads. A practical first step is to ask the owners of each essential service for a dependency list, then check it against your asset inventory. Tools such as GLPI's Assets module or Wazuh's Syscollector inventory can supply the component data, but they cannot tell you which components are essential or what they were meant to do.

Which PM-32 scope decisions change the work

PM-32 has no baseline to fall back on, so the organization's own list of mission-essential services or functions sets how much analysis is needed. The decisions below determine how many systems, components, providers and teams end up in that analysis, and each one moves the work up or down.

Defining mission-essential services

A broad definition that counts every business service as mission-essential produces a long analysis with thin findings. A narrow definition that lists only a few revenue or safety functions may miss services that depend on shared infrastructure. Check the definition against the organization's mission and business process documentation, and confirm that the list is approved and dated so an assessor can trace it to the PM-32 determination statement.

Mapping systems that support each service

Scope widens quickly once dependencies are counted. Mapping only the primary application for each essential service is faster, but shared identity, logging, backup and network systems often sit underneath several services and carry the same risk. Ask whether the analysis follows dependencies down to shared components, and record which inventory source (for example, the system inventory under PM-5) is the authoritative list.

Including components and their configuration

Analyzing only system-level purpose misses components that are repurposed quietly, such as a reporting database that begins serving an external partner or a test server that hosts production data. Deciding whether the analysis covers components, not just systems, changes how much configuration and asset data you need. Inventory tooling such as GLPI's Assets module can supply the component records that this check depends on.

Covering third-party and cloud hosting

Essential services hosted by a cloud provider, managed service or outsourced operator raise a separate question: is the provider's environment used only for its intended purpose? Narrow scope limits the analysis to systems you operate directly. Broad scope requires contractual and evidence requests to providers, and that work often takes longer than the internal review. Confirm which provider attestations, service descriptions and shared responsibility records you can actually obtain before fixing the boundary.

Assigning security, privacy and supply chain owners

Whether one team or three own the analysis changes the coordination load. The PM-32 assessment draws on people with security, privacy and supply chain risk program responsibilities, so an analysis owned only by security may miss purpose drift that involves personal data or supplier changes. Name a single accountable owner, define who reviews each service, and agree how disagreements about intended purpose are escalated.

Setting the review trigger and cadence

A one-time analysis is quick to finish but goes stale once a service adds a new integration, a new user population or a new data source. Setting the review as an event-driven trigger (for example, a change to the essential services list or a new hosting arrangement) costs more to operate than an annual review, but it catches purpose drift earlier. Confirm the review frequency with your own risk management strategy and document it in the program plan.

How an assessor tests PM-32 purposing

This table breaks down the single SP 800-53A determination statement for PM-32 into the examine and interview objects an assessor uses. Read each row as a question the assessor asks, the evidence that answers it, and where organizations usually fall short. The main takeaway is that PM-32 is tested mostly through program-level documents and people, so the mission-essential services list must tie directly to the analysis of information resources.

Assessment object	What the assessor checks	Evidence requested	Common findings
Information security program plan	Whether the program plan addresses purposing of systems and components that support mission-essential services or functions	Current program plan, approval record, and the section covering purposing or information resource use	Plan is silent on purposing, or the section is generic and not linked to essential services
Privacy program plan	Whether privacy considerations are reflected in how information resources are confirmed for their intended use	Current privacy program plan and the sections on processing scope tied to essential services	Privacy plan is not coordinated with the security program plan, so purposing gaps go unnoticed
List of essential services and functions	Whether the list is defined, current, and identifies the systems and components the analysis must cover	Approved list of mission-essential services and functions with owners and dependent systems	List is outdated, missing dependencies, or does not map to system inventory
Organizational analysis of information resources	Whether the analysis confirms each defined system or component is used consistently with its intended purpose	Analysis records, purpose statements per resource, dated review results, and documented exceptions	Analysis is not performed, covers only some resources, or does not record use beyond intended scope
Risk management strategy	Whether the strategy considers threat exposure created by use outside intended purpose	Risk management strategy document and links to purposing analysis results or risk decisions	Strategy does not reference purposing, so out-of-scope use is not treated as a risk
Personnel with security, privacy and supply chain risk responsibilities (interview)	Whether these personnel can describe how essential resources are checked for intended use and who acts on the results	Role descriptions, walkthrough of the analysis process, and examples of recent findings and follow-up	Staff describe the purpose check differently, or responsibilities are split with no clear owner

How to implement PM-32 in sequence

This sequence turns PM-32 from a single sentence in the control catalog into a documented, repeatable analysis that shows mission-essential services run only on systems and components used for their intended purpose. Each step produces an artifact an assessor can examine or discuss in interview.

Confirm the list of mission-essential services and functions
Start with the business owners of each service, not the security team. Ask them which services and functions the organization cannot lose or must restore first, and record the answers in a list of essential services and functions approved by the accountable official. The assessor will expect this list as an examined artifact, so it should name each service, its owner and the date it was last confirmed. The step is complete when every owner has signed off and the list is referenced from the information security program plan.
Map supporting systems and components to each service
For each essential service, trace the systems, applications, network segments, cloud accounts and components that deliver it, including third-party services it depends on. Use an existing system inventory and component inventory as the starting point, and confirm gaps with the people who run the service. Open-source asset tools such as GLPI can hold this mapping, and agent-based inventory from tools such as Wazuh can confirm what is actually running on endpoints. The output is an organizational analysis of information resources that links each service to its supporting assets.
Define the intended purpose of each resource
For every mapped system or component, write down its intended purpose in terms the business owner and the system owner both accept. Include the approved users, the permitted functions and the data it is meant to handle. This baseline is what makes later analysis possible, because purpose cannot be checked against an undocumented expectation. Confirm that the statements align with the system security and privacy plans and the risk management strategy. The output is a purpose statement per resource that can be compared against observed use.
Analyze actual use against intended purpose
Compare the documented purpose with observed use. Review configurations, installed software, running services, user and group membership, network flows and access logs, and interview the operators about any use outside the stated scope. Look for workloads that serve other purposes, such as a server for an essential service also hosting unrelated applications or a laptop used for administration of several unrelated environments. The output is a dated analysis record for each resource showing what was checked, what was found and whether use matches purpose.
Record findings and track corrective actions
Document each deviation with its risk, the owner, the corrective action and the target status. Route findings that cannot be resolved promptly into the plan of action and milestones process under PM-4, and record accepted deviations with a named risk owner and a review date. Keep the evidence for each closed item, such as a changed configuration, a removed workload or a revised purpose statement. The output is a findings register that an assessor can trace from the original observation to closure or documented acceptance.
Tie results to the risk strategy and program plans
Feed the results into the organization-wide risk management strategy under PM-9, the risk assessment results under RA-3, and the continuous monitoring strategy under PM-31. Update the information security program plan under PM-1 where the analysis changed how essential services are defined or protected. Where an analysis reveals a control weakness, connect it to the relevant CA-7 monitoring activity and PL-2 system security plan. The output is a cross-reference showing that purpose analysis results influenced risk decisions and program documents.
Set a review cadence and rerun the analysis on change
Define how often the essential service list and purpose statements are reviewed, and specify triggers for an out-of-cycle analysis, such as a new workload, a merger, a cloud migration or a significant change to a system. Assign the review to a named role and record each review in the program's documentation. The organization sets the cadence, so confirm it with the accountable official rather than adopting an external figure. The output is an approved review schedule and a log of completed reviews that shows the analysis stays current.

PM-32 evidence that passes an examination

PM-32 is assessed through one determination statement, using examine and interview methods, so the evidence is a small set of organization-level records rather than system screenshots. The cards below cover the artifacts an assessor is likely to request and how each one stays current between assessments.

Approved list of essential services and functions

This is the starting point for PM-32, because purpose analysis only applies to the systems and components that support mission-essential services or functions. Keep the list short, name each service in plain terms, and record the date and approver. Review it when mission priorities, business processes or regulatory obligations change, and confirm that the owner who signs it has the authority to define what is essential.

Organizational analysis of information resources

This analysis explains how each essential service depends on information resources and what those resources are meant to do. An assessor will check whether the analysis is specific enough to define an intended purpose for each resource. Update it when a service changes its dependencies, and record who reviewed each revision so the analysis reflects current use rather than the original design.

Service-to-system and component mapping

A mapping links each essential service to the supporting systems and components that deliver it. Without it, an analysis of purpose cannot be tied to actual assets. Generate the mapping from your asset inventory where possible, then have service owners confirm it. Check it for orphaned systems that support no listed service, and for shared components that serve both essential and non-essential functions.

Dated purpose-of-use findings and decisions

This is the record of what each mapped system is actually used for, compared with its intended purpose, and what was decided when use drifted. Each finding should show the date, the observed use, the decision (such as restricting, reclassifying or retiring the use) and the accountable official. Assessors look for evidence that findings lead to action, so track each decision to closure in your plan of action and milestones process.

Links to program plans and risk strategy

The purpose analysis should be traceable to the information security program plan, the privacy program plan and the risk management strategy. These documents set the rules that define intended purpose, so cross-references show that PM-32 is part of the organization-wide program rather than a standalone exercise. Confirm that the plans name the analysis, that version numbers match what was reviewed, and that updates to the plans trigger a review of the purpose findings.

Interview notes and review sign-offs

Because the interview method is part of the assessment, assessors will ask staff with information security, privacy and supply chain risk responsibilities how the analysis is done. Keep dated interview notes, attendance records and sign-offs from each reviewer. Record who was interviewed, their role, and the topics covered, so an assessor can confirm that the people who run the program understand and apply the analysis.

What meeting PM-32 costs in money and effort

This table compares the cost components of meeting PM-32, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for scoping and for reviewing a written quote. No price or duration is stated because none is supplied for this control, so ask for each line item in writing.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Defining essential services and functions	Internal staff with business owners; any advisor time is billed by the hour or as a fixed-scope deliverable	One-time, then reviewed on change	Number of essential services and how many business owners must agree on them
Mapping services to supporting components	Internal engineers or an implementation partner building the analysis of information resources	One-time build, recurring upkeep	Number of supporting components, depth of dependencies and how much the mapping is automated
Third-party dependency analysis	Procurement, supplier management and technical staff reviewing externally hosted components	Recurring with each supplier change	Count of external providers and how often contracts or hosting change
Inventory tooling (GLPI and Wazuh)	Platform and security engineers to deploy, tune and integrate; GLPI and Wazuh are open-source, so no license fee applies to the inventory data itself	One-time setup, recurring operations	Number of endpoints and network devices, agent coverage and integration with existing records
Evidence upkeep	Staff who keep the program plan, analysis and risk management strategy current and retain records	Recurring	Frequency of change to essential services, system ownership and purpose statements
External review or testing	Independent assessor or security testing provider if the organization buys one	Periodic, scoped per engagement	Scope of services under review and whether results need independent validation
Auditor sampling and assessment support	Independent assessor tests the evidence; the organization pays the assessor and staff time to answer requests	Recurring per assessment cycle	Number of samples requested, quality of prepared evidence and number of open questions

Who owns PM-32 and what a partner can take on

PM-32 asks the organization to analyze the systems and components that support mission-essential services or functions and confirm they are used consistently with their intended purpose. The judgment behind that analysis belongs to your organization. Only your leaders know which services are mission-essential, what each system was approved to do, and how much deviation from that purpose your risk appetite allows. Your team owns the decisions and the sign-off, and it must be able to explain them to an assessor.

Essential services list: Maintain the list of mission-essential services or functions that the purposing analysis is anchored to, approved by the accountable owner.
Purpose-of-use decisions: Record the intended purpose of each in-scope system or component and decide what counts as use outside that purpose.
Analysis and sign-off: Document the organizational analysis of information resources and obtain formal approval from the accountable official.
Risk strategy link: Connect findings to the risk management strategy and to any plans of action and milestones for deviations.
Interview readiness: Make sure the personnel responsible for security, privacy and supply chain risk can explain the analysis.

Confirm with your governance owner exactly which officials must approve the analysis and how often your organization reviews it.

Open-source tools that support PM-32 evidence

Two open-source platforms can produce part of the evidence PM-32 calls for: a component inventory that maps assets to the services they support, and endpoint records that show what those systems actually run. Neither tool decides whether a use is consistent with its intended purpose, so the cards separate what each can show from what still needs an accountable reviewer.

GLPI Assets component inventory

GLPI's Assets module records computers, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in by hand or pushed automatically by the GLPI Agent through native inventory, which is built into GLPI since version 10. For PM-32, the useful output is a component list mapped to each mission-essential service. Check that every in-scope component has an owner and a recorded service link, because an inventory without that mapping cannot support a purpose analysis.

GLPI records what exists, not purpose

GLPI can show that a server, switch or application exists, who owns it and where it sits. It does not determine whether that asset is being used for its intended purpose. That judgment belongs to the organization and its system owners, and it must be written into the essential services analysis that PM-32 requires. Confirm that your GLPI fields and relationships can hold this service mapping and that reviewers can export the records for assessors.

Wazuh Syscollector endpoint inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint. It stores the results in the Wazuh indexer, where the dashboard presents inventory views and reports. For PM-32, these records can show whether an endpoint runs software, services or open ports beyond its documented role, such as an unexpected application on a dedicated service host. Confirm agent coverage across the systems in scope before relying on the output.

Wazuh limits and license caveats

Syscollector reports what is installed and running, but it cannot tell you whether that use matches the function a system is meant to serve. An analyst must compare the inventory with the service analysis and decide whether a deviation is a purpose problem. Wazuh is licensed under GPL-2.0-only and GLPI under GPL-3.0-or-later, so review the license terms that apply to your distribution and any modifications before you build either tool into a service. Confirm fit with your environment and your legal counsel.

Where PM-32 programs usually fall short

PM-32 is short, but it depends on several organization-wide records lining up: an approved list of essential services, an inventory that maps to those services, and documented purpose-of-use analysis. The gaps below tend to appear where those records are missing, disconnected or never reviewed.

No approved list of essential services

PM-32 starts from the systems and components that support mission-essential services or functions, so an assessor will ask for the list that defines them. Many organizations have no single approved list, only informal knowledge held by a few managers. Get the list approved by the accountable officials, tie each entry to a named owner, and reference it from the information security program plan so the assessor can trace the scope.

Inventories that do not connect to services

A system inventory alone does not show which assets support which essential service. Check that each asset record carries a service or function tag, and that the tag is set by the owner rather than inferred later. In an open-source stack, GLPI's Assets module can hold the asset records and custom fields, while Wazuh's Syscollector data can confirm what software and services are actually running on each endpoint.

Purpose-of-use analysis left undocumented

Assessors look for evidence that the analysis was done, not only that the inventory exists. For each in-scope system, record its intended purpose, the services it is allowed to support, and the analysis that found any use outside that purpose, such as a reporting server running a development tool. Keep the analysis dated and signed so a later reviewer can see what was checked and when.

Supply chain and third-party components omitted

Purpose-of-use drift often starts with components the organization does not run itself, such as a managed database, a vendor appliance or a contractor's remote tool. Include these in the analysis and ask suppliers to confirm the purpose their service is intended for. Where a component sits outside your control, record that limit and the compensating review you perform.

No link to the risk strategy or POA&M

When the purpose analysis finds use beyond intended scope, the finding has to flow into the organization's risk decisions. Check that findings are logged, scored against the risk management strategy, and tracked in the plan of action and milestones (POA&M) process, which is the route PM-4 defines. An unlinked finding is hard to show as remediated or accepted with a reason.

No periodic review record

PM-32 expects the analysis to stay accurate as services change, so a single analysis from years ago will not satisfy an assessor. Set a review cadence in the program documentation, record each review with its date, participants and changes, and retain the records. Interviews with security, privacy and supply chain personnel usually test whether the review actually happens.

PM-32 questions buyers ask before hiring help

How much effort does PM-32 Purposing take in practice?

PM-32 is a single determination statement in SP 800-53A, so the assessed work is small, but the analysis behind it is not. The effort depends on how many systems and components your organization has classified as supporting mission-essential services or functions, how well those services are already documented, and how many business owners must confirm intended purpose. Organizations with a current list of essential services and a recent analysis of information resources usually have less to assemble than those starting from nothing. Ask any partner to size the work from the number of in-scope systems and the state of your existing documents, and to show that sizing in a written scope.

How long does a PM-32 assessment take to prepare?

No duration is supplied for this work, so treat any timeline you receive as an estimate to test, not a fact. The schedule depends on how quickly your owners can confirm the list of essential services and functions, how fast evidence can be gathered from inventory and configuration sources, and when your independent assessor is available. Confirm the timeline with your auditor or assessor before work starts, since they decide what evidence they will accept, and agree internal review dates with the owners who must sign off on intended purpose.

What does PM-32 need from our business owners?

PM-32 depends on decisions that only business owners can make. The assessment procedure points to the list of essential services and functions, the organizational analysis of information resources and the risk management strategy, and it asks staff with program responsibilities to explain how those are applied. In practice, business owners need to:

Confirm which services and functions are mission-essential
State the intended purpose of the systems and components that support them
Identify any use outside that purpose and agree whether it is acceptable
Review and approve the analysis and any resulting risk decisions

Can a small security team handle PM-32 in-house?

Often yes, provided the team has access to the business owners and to the inventory data that shows how each system is used. The control is organization-wide and does not require a separate tool, so the main constraint is time and authority rather than technical skill. A small team should assign one accountable person, keep the essential services list current, and record each analysis with a date and an approver. Where the team lacks inventory data, open-source asset and inventory tools such as GLPI's Assets module or Wazuh's system inventory can help show what runs where, but you should confirm that each tool captures the fields your analysis needs.

What can a partner do for PM-32, and what can it not do?

A partner can help you prepare: it can structure the analysis, collect inventory and configuration evidence, draft the essential services documentation for owner review, and set up the records an assessor will examine. DeployOpen works this way for compliance readiness. It does not issue audit reports, attestations or certifications, and it should not decide whether your controls pass. Only an independent assessor or certification body can do that. Because the assessor must test work independently, the people who prepared the analysis should not also be the people who judge it, and your organization still owns the determination that intended purpose is being met.

Is PM-32 required under the low, moderate or high baseline?

No. SP 800-53B places Program Management controls organization-wide and independent of system impact level, so PM-32 is not allocated to the low, moderate or high baseline. It is also not in the privacy control baseline. That does not remove the obligation from your program if a contract, agency or assessor asks for it, because the requirement comes from the organization-wide program rather than from a system's baseline. Confirm with the party requiring SP 800-53 whether they expect a documented PM-32 analysis, and check the SP 800-53B baseline profiles in OSCAL to confirm the allocation for your release.

How DeployOpen prepares PM-32 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems that support mission-essential services can be shown to run for their intended purpose. We prepare the systems, records and evidence for PM-32 Purposing, while your organization owns the control and an independent assessor reaches the conclusion.

How we scope

We confirm with your team which mission-essential services and functions the PM-32 analysis must cover.
The written scope names the systems, components and infrastructure accounts in each review, agreed before work starts.
Engagements are fixed-scope, and ongoing support for periodic purpose reviews is available as a retainer.

How we build

We deploy inventory tooling such as GLPI and Wazuh Syscollector to record what each system hosts and runs.
We configure asset records so owners, roles and approved uses can be compared with observed software and services.
We document where inventory data is incomplete so your team can close gaps before the assessment.

How we hand over

We deliver the purpose analysis records, inventory exports and configuration notes mapped to the PM-32 assessment objects.
We provide documentation for the program plan and essential services list that your staff keep current.
We walk your interview participants through the evidence so they can explain how purpose is confirmed in practice.

How we support

We help your team repeat the purpose review on the cadence your risk management strategy sets.
We can retest inventory coverage and report changes to owners when systems or services are added or retired.
Your organization decides the findings, and an independent auditor or assessor issues any report or certification.