What PM-5 system inventory asks for and why assessors start with it
PM-5 requires the organization to develop and maintain an inventory of its organizational systems, and to update that inventory at a defined frequency. If you are preparing for an SP 800-53 assessment or building a program from scratch, this is the control that tells an assessor whether you know what you run before they test anything else. The risk it addresses is simple: a system nobody has listed cannot be categorized, assessed, patched, monitored or authorized. Because the inventory is organization-wide, it is a program-level control deployed across the enterprise rather than a control implemented separately for each system. It is also not allocated to the low, moderate or high baselines and is not in the privacy baseline, so its scope does not shift with system impact level. The one enhancement, PM-5(1), adds an inventory of PII processed by those systems, and the privacy baseline includes it.
The control is hard in practice for reasons that have little to do with tooling. Shadow IT, software-as-a-service accounts bought on a corporate card, and business units that stood up their own cloud tenants all produce systems the central team never sees. Boundaries are also unclear: is a shared platform one system, or the set of applications running on it? Before you collect evidence, agree on a definition of an organizational system, name the owner who maintains the inventory, and confirm the update frequency your organization has defined and can actually meet. Keep PM-5 separate from CM-8, which inventories system components such as hardware, software and firmware within a system. PM-5 answers "what systems do we operate," while CM-8 answers "what components make up each system." An assessor will check that the two agree, so a system listed under PM-5 should map to component records under CM-8.
Which systems, data and teams the PM-5 inventory must cover
PM-5 is an organization-wide inventory of systems, so the hard work is deciding what counts as a system and who owns each entry. The cards below cover the scoping choices that change the size and accuracy of the inventory, from cloud and SaaS services to the PII flags that feed the privacy baseline enhancement.
Defining an organizational system
PM-5 asks for an inventory of organizational systems, not of every component. Set a written definition that states what boundary makes a system: for example, a set of components that share an authorization, a business purpose and an owner. Confirm the definition with the assessor before the inventory is built, because a narrow definition can leave shadow applications out of scope and a broad one can bury useful entries. This separates PM-5 from the component-level records that CM-8 requires.
Cloud and SaaS services
Cloud accounts and SaaS subscriptions are often bought by business teams and never reach the IT register. Inventory each tenant, subscription or workspace as its own entry where it carries organizational data, and record the service provider and the region where data is stored. Check payment records, single sign-on logs and identity provider application lists to find services that were adopted without procurement review.
Third-party hosted systems
Systems run by a vendor or partner on the organization's behalf still belong in the inventory when they support organizational missions. Record the hosting party, the contract or agreement that governs the service, and the internal owner who accepts the risk. Missing entries here often surface later in supply chain reviews, so ask procurement to flag any new hosted service before it goes live.
Business owners and IT owners
Each system entry needs a named accountable owner, and for many systems the business unit that funds and uses the system is the right one, while IT operates it. Record both roles separately so that questions about purpose, data and risk go to the business owner and questions about operation and patching go to IT. Review ownership whenever a team reorganizes, since stale owners are a common finding during interviews.
Flagging systems that process PII
Systems that process personally identifiable information need a flag in the inventory so the PM-5(1) enhancement can be met, and the privacy baseline applies to them. Ask each owner to state the PII categories, the individuals affected and the purpose of processing. Treat any system that holds customer, employee or patient records as flagged until a data review shows otherwise, and link each flag to the data inventory maintained for privacy purposes.
Keeping the inventory current
PM-5 requires the inventory to be updated at a defined frequency, so the organization must set that frequency in writing and show that it runs. Confirm the review cadence with your own policy and the assessor, then compare the register against discovery sources such as cloud inventories, endpoint agents and procurement records. Keep a dated change log so an assessor can see how entries were added, retired or reassigned.
How the PM-5(1) PII inventory changes the privacy baseline work
PM-5 itself sits outside the security baselines, but its PII enhancement, PM-5(1), is part of the privacy baseline. SP 800-53B treats the Program Management controls as deployed organization-wide, independent of system impact level, so PM-5 is not allocated to the low, moderate or high baseline. The privacy baseline is different: it adds PM-5(1), which extends the system inventory to cover the systems that process personally identifiable information. For a privacy program, this means the organization must be able to show which systems hold PII before any privacy control can be assessed against them. A team that already maintains a systems register for security purposes should not assume it satisfies PM-5(1) until it confirms that PII processing is recorded for each entry.
The PII inventory is the factual base for much of the privacy work that follows. Controls in the PT family, which cover the authority for processing, purposes, consent and privacy notices, all need a clear answer to the question of which systems process which categories of PII. Risk assessment work under RA, including privacy impact assessments, also depends on that answer, because a risk assessment cannot be scoped to systems the organization has not identified. In practice, the inventory should record, for each system, the PII categories involved, the purpose of processing and the owner who answers for it, so that PT and RA assessments can draw on the same record rather than rebuilding it.
Before relying on the inventory, confirm the following with your privacy office: which official is the senior agency official for privacy or equivalent, how often the inventory must be updated under your own privacy requirements, and whether the inventory is expected to cover processing by external service providers. Ask the privacy office to state in writing how a PII inventory will be reviewed when a new system is onboarded or when an existing system changes its data. The control text and the privacy baseline status should be checked against the current SP 800-53B release and the CPRT entry for the control before the inventory design is finalized.
How an assessor tests PM-5 under SP 800-53A
The examine method asks the assessor to read documents and records that show the organization has an organization-wide inventory of systems and procedures for building and maintaining it. The assessment objects named for this method are the system inventory itself and the procedures that address its development and maintenance. The assessor checks that the inventory exists, covers organizational systems, and carries a review or update date that matches the frequency the organization defined in its own procedures.
- The inventory artifact: A dated export or register listing each organizational system, with an owner, purpose and boundary or hosting location for each entry.
- The procedure: A written procedure that names who maintains the inventory, what triggers an update and how often the review happens.
- Version history: Records of past updates showing the inventory is maintained rather than created once for the audit.
- Scope check: Evidence that the inventory covers systems, not only the hardware and software components tracked under CM-8.
- Common finding: An inventory that lists servers and laptops but omits cloud accounts, SaaS services or systems owned by business units.
Before the assessment, confirm the inventory matches the organization's defined frequency and that the procedure and the artifact agree.
The interview method asks the assessor to speak with personnel who plan and implement the information security program. For PM-5, the people to interview are those who own the inventory process, who approve systems entering production and who are accountable for the program plan. The assessor uses the conversation to test whether the written procedure matches what people actually do, and whether responsibilities are understood across teams. Interviews produce findings when answers differ from the documents.
- Process owner: Someone who can describe how a new system is added, who is notified and how decommissioned systems are removed.
- Program planners: Staff who can explain how the inventory feeds the information security program plan and risk decisions.
- Business and IT leads: Owners of systems outside central IT who can confirm they register their systems.
- Consistency check: Answers that match the procedure, the artifact and each other.
- Common finding: Interviewees who describe a process the written procedure does not mention, or who do not know the inventory exists.
Before the interview, confirm which people hold program planning and implementation roles and prepare them to walk through a recent system addition.
The test method asks the assessor to observe or trial the processes that develop and maintain the inventory. Instead of reading about the process, the assessor follows a real or sample system through it, from discovery or request to registration, periodic review and retirement. This method shows whether the process runs reliably and whether its outputs reach the inventory without gaps. Discovery tooling, including open-source inventory platforms, can support this step by producing data the assessor can compare against the register.
- Sample trace: The assessor selects one or more systems and follows them through the intake, registration and review steps.
- Discovery comparison: Scan or agent data, such as from GLPI or Wazuh, compared with the register to find systems missing from it.
- Review run: Evidence that a periodic review took place at the defined frequency, with reviewer names and outcomes.
- Retirement check: Proof that decommissioned systems are removed or marked inactive with a date.
- Common finding: A discovery run that finds systems absent from the register, or reviews that are scheduled but not recorded.
Before the test, run a discovery comparison yourself and resolve any gaps, so the assessor sees a process that works in practice.
Steps to build and maintain a defined-frequency system inventory
This sequence turns PM-5 from a policy statement into an organization-wide system inventory that has a named owner, a documented update frequency, consistent records and a periodic check that it still matches reality. Each step produces an artifact an assessor can examine.
Define inventory scope and owner
Decide what counts as an organizational system for this inventory, including cloud tenants, data centers, SaaS services and systems operated by third parties on the organization's behalf. Name one accountable owner, usually in the security or IT governance function, and record which business units must report to that owner. The output is a scope statement and a role assignment approved by the official who owns the information security program plan. Confirm the boundary with your assessor early, because PM-5 covers systems, not the components tracked under CM-8.
Set update frequency in a procedure
Write the inventory procedure with a defined update frequency and the triggers that force an earlier update, such as a new system going live, a decommissioning, a major change in hosting or an acquisition. Specify who submits changes and who approves them. The frequency you choose must be the one you actually follow, so assessors will test it against change records. The output is a approved procedure that an assessor can examine alongside the inventory itself.
Establish the system record fields
Define the fields every system record must carry, such as system name, unique identifier, business owner, technical owner, purpose, hosting location, data classification, security categorization, connection to other systems, status and last review date. Keep the schema short enough that owners will maintain it. The output is a field dictionary and a template that the inventory tool enforces, so that records can be compared and filtered across the organization.
Reconcile sources of record
Populate the inventory from several sources and compare them: the configuration management database, cloud provider account lists, identity provider applications, endpoint and network discovery, and procurement, contract and HR records that reveal business-owned SaaS and unmanaged tools. Record every discrepancy and assign it to an owner for resolution. The output is a reconciliation log showing which sources were compared, when, and how each gap was closed. Ask your tooling vendor which discovery sources it supports natively before you commit to a design.
Add PII flags for PM-5(1)
For organizations that include the PM-5(1) enhancement, add a field that records whether each system stores or processes personally identifiable information, the categories of PII involved and the data owner responsible for it. Work with privacy staff to define the categories so that the flag means the same thing in every business unit. The output is an inventory of PII-bearing systems that privacy officials can review, and it links the inventory to privacy controls in the PT and PM families.
Connect the inventory to security tooling
Feed the inventory from the tools that already see systems, such as GLPI for asset records or Wazuh Syscollector for endpoint-level hardware and software data. Keep the inventory as the system-level record and let the tools supply component detail, so the two levels stay distinct. The output is a documented data flow showing which tool populates which fields and how stale data is flagged. Confirm the exact capabilities of any tool against its current documentation before you rely on it for evidence.
Run the periodic review and retain evidence
At the defined frequency, the owner reviews the full inventory against the reconciliation sources, closes open discrepancies, retires systems that no longer exist and signs off the review. Keep dated snapshots, change records and sign-off records so that an assessor can see the inventory was updated as the procedure requires. The output is a completed review record for each cycle and an updated inventory version. Review findings that affect risk should flow into the POA&M process under PM-4.
Evidence that passes a PM-5 assessment
An assessor testing PM-5 examines the organization-wide inventory and the procedure that keeps it current, then tests whether the process runs as written. The cards below cover the artifacts that answer those checks and how to keep each one current between assessments.
Organization-wide system inventory
The core artifact is a register of organizational systems, with each system's name, business owner, technical custodian, purpose, hosting location and last review date. Assessors check that it covers systems rather than individual components, which belong in the CM-8 component inventory. Ask who approves additions and removals, and confirm that the register links to the system security and privacy plans for each entry. Review it at the frequency the organization has defined, not only when an assessment is scheduled.
Documented inventory procedure
The examine method looks for procedures that address how the system inventory is developed and maintained. The procedure should name the owner of the register, the sources used to populate it, the defined update frequency, the approval step for new systems and the retirement steps for decommissioned ones. A procedure that matches what staff actually do is what passes. Confirm that the frequency in the procedure matches the frequency the organization has defined elsewhere in its program documents.
Review records and change logs
Dated review records show that the inventory was checked at the defined frequency, who checked it and what changed. Change logs record each addition, reclassification and retirement with the request or ticket behind it. Assessors test whether the log accounts for every system that appears in other sources, such as cloud accounts or procurement records. Keep the history rather than overwriting entries, so an assessor can see when a system entered or left the register.
Reconciliation reports
A reconciliation compares the register against independent sources such as cloud account listings, network discovery, endpoint agents and the asset records kept by finance or procurement. Each gap, meaning a system seen in one source but missing from the register, needs a recorded disposition. Open-source tools like GLPI's Assets module and the Wazuh Syscollector can supply the discovered side of the comparison, but the organization must confirm their coverage in its own environment before relying on them as evidence.
PII inventory for PM-5(1)
The PM-5(1) enhancement is present in the privacy baseline and requires an inventory of systems that contain personally identifiable information. Each entry should record the categories of PII held, the purpose, the data owner and the systems that store or transmit it. Assessors check that the PII inventory is consistent with the main system register, so a system holding PII cannot appear in one list and be absent from the other. Refresh it whenever a system's data holdings change.
Evidence that stays current
Assign an owner for each artifact and set a recurring calendar reminder tied to the defined frequency. Record the date and reviewer on every update, and keep a dated snapshot of the register at each review so the assessment period can be reconstructed. Ask your implementation partner or internal team to confirm that discovery tools feed the register on a schedule, since stale automated data is a common gap between audits.
What meeting PM-5 costs in money and effort
This table breaks the PM-5 system inventory work into its cost components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so use the table to structure your own estimate and to check written quotes against the same components.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Discovery and reconciliation | Internal staff, with optional implementation partner time | One-time, then recurring as sources drift | Number of systems, number of unmanaged or shadow systems, and whether ownership is recorded for each system |
| Tooling or licenses | Software vendor or none if self-hosted open source is used | Often recurring if commercial; self-hosted open source avoids license spend | Choice of platform, licensing model, and hosting capacity you must provision and operate yourself |
| Engineering time to integrate sources | Internal platform engineers or an implementation partner under written scope | One-time build, with recurring maintenance | Count of authoritative sources such as CMDB, cloud accounts, identity systems and procurement records |
| Periodic review effort | System owners and the inventory owner | Recurring at the frequency you define | How often you set the review cycle, how many owners must confirm entries, and whether reviews are automated |
| PII classification effort | Privacy office, data owners and system owners | One-time initial pass, then recurring on system change | Volume of systems that process PII and the level of detail your privacy program requires for PM-5(1) |
| External review or assessor support | Independent assessor or consultant, paid under a written engagement | Recurring at each assessment cycle | Scope of the assessment, quality of existing evidence, and whether the inventory is already traceable to CM-8 records |
| Auditor sampling | Independent assessor, who samples inventory records and interviews staff | Recurring at each assessment cycle | Number of systems in the inventory, consistency of records, and how quickly you can produce supporting history |
Who owns the PM-5 inventory, who helps and what the auditor checks
Your organization owns PM-5. Leadership must decide what counts as an organizational system, who maintains the inventory, how often it is updated at the frequency you define in your own procedures, and who approves changes to it. The inventory is a program record, so it cannot be delegated away from the people accountable for the information security program. Your staff also decides how the inventory connects to other programs, such as risk assessments, authorization decisions and the system security plans that depend on an accurate list of systems.
- Scope decisions: Define what qualifies as a system, including cloud accounts, SaaS services, shadow IT and systems owned by third parties.
- Update frequency: Set and document the frequency in a procedure, then record each update against it.
- Ownership: Assign a named owner for each system entry, along with a business owner and a technical owner.
- Approval and review: Record who reviews the inventory and how exceptions are approved and tracked.
- Data quality: Decide which attributes each entry must carry, such as purpose, location, classification and status.
Before engaging anyone, confirm that your own procedure names the inventory owner and the update frequency, because an assessor will ask for both first.
An implementation partner can configure the tools that feed the inventory and prepare the evidence an assessor will examine. Partners typically work on discovery and collection, then deliver reconciliation scripts and reports so your staff can review the output. The partner does not decide what is in scope, approve entries or attest that the inventory is complete. Those decisions stay with your organization, and the partner's deliverables should say so in the written scope.
- Tool setup: Configure discovery and asset collection, for example with GLPI for asset records or Wazuh for endpoint inventory, inside your own infrastructure.
- Reconciliation scripts: Compare tool output against the authoritative list and flag systems that are missing, duplicated or stale.
- Evidence preparation: Export inventory snapshots, change logs and review records in a form an assessor can sample.
- Documentation: Write the inventory procedure drafts and runbooks, which your organization then adopts and approves.
- Knowledge transfer: Train your staff to run the reconciliation and to answer questions about the data.
Ask the partner to state in writing which deliverables are scripts and reports and which are decisions made by your staff.
An independent assessor tests PM-5 against the assessment procedure in SP 800-53A. For PM-5, the procedure contains two determination statements and uses examine, interview and test methods. The assessor examines the inventory and the procedures for developing and maintaining it, interviews personnel with information security program planning responsibilities, and tests the processes that keep the inventory current. The assessor forms the findings. Only an independent auditor, assessor or certification body issues reports or attestations, and no implementation partner can do that on the organization's behalf.
- Examine: Review the inventory, the procedure and the record of updates against the defined frequency.
- Interview: Ask program leaders how systems are added, retired and reviewed.
- Test: Choose a sample of systems from network or cloud records and check whether each appears in the inventory.
- Findings: Document deficiencies in the assessor's own report, which the organization then tracks in its plan of action and milestones.
- Independence: Assessors must not design or build the controls they test, which is why the partner's role stays on the preparation side.
Before the assessment, confirm with your assessor which evidence formats and sampling methods they accept, and whether they expect the inventory to be produced directly from tool output.
Common PM-5 gaps and how to close them
PM-5 looks simple on paper, but most assessors find the same weaknesses: a list that is out of date, no agreed update rhythm, and no clear owner. The cards below cover the gaps we see most often and the closing action for each, so the inventory can answer an assessor's questions with current, traceable evidence.
Point-in-time spreadsheet
A spreadsheet exported once for an audit shows the systems that existed on one day and nothing after. PM-5 expects the inventory to be developed and maintained, so an assessor will ask how the list stays accurate between reviews. Move the inventory into a system of record with an audit trail, such as an asset management database, and keep dated exports as evidence of each update. Ask who can change entries and how changes are reviewed.
No defined update frequency
PM-5 requires updates at a frequency the organization defines, but many programs never write one down. Without a stated frequency, the assessor has no standard to test against, and staff cannot tell whether a stale list is a failure. Set the frequency in the inventory procedure, tie it to events such as new system approvals and decommissioning, and record each review with a date and reviewer. Confirm the chosen frequency matches what your policy and authorization process say.
Confusing systems with CM-8 components
PM-5 inventories organizational systems, while CM-8 inventories the individual components that make them up, such as servers, network devices and endpoints. Teams often answer PM-5 with a hardware list and then cannot show which systems those components belong to. Keep the two records separate and link them, so each system in the PM-5 inventory points to its component records under CM-8. Confirm with your assessor that the boundary between the two controls is drawn where they expect.
Missing SaaS and cloud accounts
Systems bought as SaaS, or run in cloud accounts that IT did not create, are the most common gap in a PM-5 inventory. Business units often adopt them directly, so they appear in no central list. Build the inventory from several sources at once: cloud account lists, identity provider application catalogs, expense and procurement records, and network discovery. Compare them each cycle and record which systems were found only by one source, since those are the ones most likely to be unmanaged.
No owner for each system
An inventory entry without an accountable owner cannot be validated, updated or retired. When an assessor picks a system and asks who approves its security decisions, a blank owner field becomes a finding. Require a named owner, and where useful a delegate, for every system record, and make owner confirmation part of each review cycle. Ask the owner to confirm the system's purpose, boundary and status at each update so the record reflects an accountable decision.
No PII flag on system records
The PM-5(1) enhancement, which applies in the privacy baseline, asks for an inventory of systems that process personally identifiable information. Many inventories list systems without recording whether they hold PII, so the privacy program cannot scope its work. Add a required field for PII processing to each record, with the data categories involved and the owner who confirmed the answer. Reconcile these flags with your privacy impact assessments and data flow records so the answers agree.
PM-5 system inventory questions buyers ask before hiring help
How much effort does PM-5 system inventory take?
The effort depends mainly on how many systems the organization runs, how scattered its records are and whether anyone already keeps a current list. PM-5 asks for an organization-wide inventory of systems that is developed, maintained and updated at a frequency the organization defines. The one-time work is reconciling existing sources such as CMDBs, cloud accounts, procurement records, application registers and business unit spreadsheets into a single list with an owner for each system. The recurring work is keeping that list current as systems are added, retired or changed. Ask a partner to show how the inventory will be fed, who approves changes and how the update frequency will be evidenced.
How long does building a system inventory usually take?
No single duration applies, because the timeline is set by the number of systems, the number of teams holding system records and how much discovery the organization must do before it can trust its own list. Discovery across unmanaged cloud accounts or business-owned applications usually takes longer than reconciling a well-maintained asset register. Expect the work to split into discovery, validation with system owners, and setting an update process. Ask any partner to state the assumed system count, the data sources in scope and the owners who must sign off, because those inputs drive the schedule.
What does the work need from our team?
The work needs named owners more than it needs tooling. Someone must be accountable for the inventory, system owners must confirm the entries that describe their systems, and IT operations must provide access to the asset and cloud data that already exists. Security or compliance staff must agree on what counts as a system and how often the list is reviewed. Ask the partner which people they expect to interview, what access they need to records and how many hours of staff time they assume for validation, so that your team can plan its availability before work starts.
Can we build the PM-5 inventory in-house?
Yes, many organizations maintain this inventory internally, provided the team has authority across IT, cloud and business units and can keep the list current. In-house work is most practical when a central asset or service catalog already exists and the owners are willing to maintain it. External help is more useful when records are fragmented, when no one has the mandate to reconcile them or when the organization wants an independent review before an assessor arrives. A partner can prepare the inventory and evidence, but the organization must own the list, its approvals and its update cycle.
What should a fixed-scope quote for PM-5 include?
A fixed-scope quote should name the systems in scope, the data sources to be reconciled, the deliverables and the acceptance criteria before work begins. Ask for the inventory format and fields, the process for validating entries with system owners, the update procedure and the evidence package that shows PM-5 operating. Confirm which items are one-time and which recur, who will maintain the list after handover, and what changes would reopen the scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for the same level of detail from any partner you evaluate.
Does PM-5 apply to systems at the low baseline?
PM-5 is not allocated to the low, moderate or high security control baselines. SP 800-53B describes Program Management controls as deployed organization-wide and independent of system impact level, so the requirement does not attach to a particular system's baseline. It also sits outside the privacy baseline. This means an organization may still need an organization-wide inventory of its systems to run its information security program, even if individual low-impact systems do not carry PM-5 in their own control sets. Confirm with your assessor or agency how they expect the organization-wide inventory to be scoped and evidenced.
How does PM-5(1) differ from PM-5?
PM-5(1) adds an inventory of personally identifiable information to the organization-wide system inventory. PM-5 is the base control, and SP 800-53 Release 5.2.0 defines one active enhancement for it. In SP 800-53B, the privacy baseline adds PM-5(1), so organizations handling PII in scope of that baseline must also record which systems process PII and what kinds of PII they hold. Ask your privacy office to confirm the PII categories and data elements it expects in that inventory, because the entries will need to match how the organization describes its processing activities.
How DeployOpen prepares PM-5 inventory evidence
DeployOpen starts by agreeing the inventory scope in writing before any configuration begins. Because PM-5 covers organizational systems rather than the components tracked under CM-8, the scope document should name each system boundary, its owner, its environment (production, test, development, backup sites) and the data classes it holds. The client decides the update frequency that PM-5 requires them to define, and that frequency goes into the written scope so an assessor can compare what the organization said it would do with what the records show. Confirm with your own assessor which system definition your organization uses, since the PM-5 discussion ties the inventory to the organization's own view of its systems.
Inside the client's infrastructure, DeployOpen can configure self-hosted sources that feed the inventory. GLPI's Assets module can hold system-level records, entered manually or populated by the GLPI Agent, and Wazuh's Syscollector module collects hardware, software, network and service data from each enrolled endpoint into the Wazuh indexer. Those two sources answer different questions, so the design should show which system record each source supports, how records are reconciled when the two disagree, and who approves a change to a system record. The procedure should also say how systems that are not enrolled in Wazuh are captured, because an inventory built only from agent data will miss systems that never report.
DeployOpen then prepares the procedure and evidence an assessor will examine, interview and test against the two PM-5 determination statements in SP 800-53A. That package usually includes the written inventory procedure, the scope document, dated exports from GLPI and Wazuh, records of periodic reviews, and a short walkthrough for the officials responsible for information security program planning. DeployOpen prepares these artifacts and the systems behind them. It does not issue audit reports, attestations or certifications. Only an independent assessor or certification body can reach a conclusion on PM-5, so the organization should agree the evidence format with its assessor before the package is assembled.
