PM-26 Complaint management: requirements and evidence

What PM-26 complaint management asks your organization to run

PM-26 asks your organization to run a working process for receiving and answering complaints, concerns and questions about its security and privacy practices. When an assessor, a contract counterparty or a privacy team asks how people raise these issues and what happens next, the answer has to be a documented process with public access, clear guidance on what a complainant must provide, tracking that shows each item is reviewed and addressed, and defined periods for acknowledgment and response. A form on a website does not satisfy the control on its own. The assessor will expect to see the process operating, with records of complaints received and what was done with them.

PM-26 is a program management control. NIST places the Program Management family across the organization rather than inside a single system boundary, and SP 800-53B does not allocate PM-26 to the low, moderate or high baselines. It does appear in the privacy baseline, which applies regardless of system impact level. That means the process should be owned at the organizational level, with a named owner who can direct privacy and security staff, and with a path from complaints into the incident response, privacy impact and risk management activities that the related controls (IR-7, IR-9, PM-22 and SI-18) describe. Confirm with your privacy office which systems and business units fall under the privacy baseline in your environment, since that determines where the process must be evidenced.

Most programs fail on tracking and closure rather than on intake. Complaints arrive through email, phone, web forms and forwarded regulator letters, and without one queue they are lost between teams. Assessors test whether each complaint has a timestamp, an owner, a disposition and a closure record, and whether the defined time periods were met or the misses were escalated. Decide before you build the process which channels are public, which internal teams review each category, and who approves the response. A ticketing platform such as the open-source GLPI Assistance module or Zammad can hold that record, but the organization must still define the periods and monitor them. Confirm the periods with your privacy and legal teams before you configure any tool.

Which complaints, channels and teams PM-26 reaches

PM-26 is scoped by who complains, where they can reach you, and who handles the case once it arrives. The decisions below change how much work the control creates, and each one should be settled and written down before anyone builds a channel or a queue.

Privacy baseline status

SP 800-53B places PM-26 in the privacy control baseline, which applies to systems regardless of impact level. It is not allocated to the low, moderate or high security baselines. Confirm with your privacy office whether PM-26 applies to every system that processes PII or only to a defined subset, and record that decision in the privacy program documentation so assessors can trace it.

Complaint sources in scope

Decide which senders the process must accept: customers, employees, members of the public, regulators, and internal reporters such as staff who raise concerns about privacy handling. Each source group brings different identity checks, language needs and expectations for a response. Document which groups are covered so the intake form, the acknowledgment template and the tracking fields match the population you have chosen.

Public-facing channels

PM-26 expects mechanisms that are easy for the public to use and that give filers the information they need to submit a complaint. Typical channels include a web form, a published email address and a postal address, each linked from the privacy webpage. Test each channel from outside the network, confirm that the mailbox is monitored, and keep a record of the test so the public-facing claim matches what actually works.

Intake and routing teams

Name the team that receives each channel, the team that triages the complaint, and the team that writes the response. Privacy, security operations and legal often share ownership, so write down the handoff rules. Without a named owner for each step, complaints sit in a shared inbox, and the defined acknowledgment and response periods in PM-26 cannot be shown in records.

Adjacent controls to scope

The catalog links PM-26 to IR-7, IR-9, PM-22 and SI-18. Treat these as neighboring work to scope, not as equivalents. A complaint about a suspected breach may trigger incident response under IR-7 or IR-9, a complaint about inaccurate PII falls under PM-22, and PII quality issues may connect to SI-18. Decide in advance which complaint types move into those processes and how the hand-off is recorded.

Review and oversight owners

PM-26 assessors examine the complaint documentation and the procedures for reviewing complaints, and they interview the personnel with privacy program responsibilities. Assign a reviewer who looks at complaint trends and open items on a set cadence and reports to the privacy program lead. Confirm the reviewer's name, the review frequency and the escalation path with the organization, because these are the records an assessment will request.

How an assessor tests PM-26 complaint management

This table compares the three SP 800-53A assessment methods (examine, interview and test) against the assessment objects an assessor reviews for PM-26, the evidence requested for each, and the findings that commonly appear. Read each row as the question an assessor will ask and the material you should have ready before the assessment begins.

Assessment method	Assessment objects reviewed	Evidence requested	Common findings
Examine (documents)	Privacy program plan, procedures addressing complaint management, complaint documentation, procedures addressing reviews of complaints	Current privacy program plan section covering complaints, written intake and response procedures, complaint log with dated entries, review records	Complaint procedure exists but is not referenced in the privacy program plan; log missing dates or outcomes
Examine (public channels)	Published mechanisms for submitting complaints and the information needed to file one	Screenshots or archived copies of the public contact page, form instructions and required fields, dated for the assessment period	Intake channel is undocumented or only reachable through internal staff
Interview	Organizational personnel with privacy program responsibilities	Named owners and their documented roles, short walkthrough of how a complaint moves from intake to closure	Staff cannot describe the process consistently or name who reviews complaints
Test (processes)	Organizational processes for complaint management, operating as designed	Sample of complaints traced from receipt through acknowledgment, response and closure against defined time periods	Acknowledgment or response periods defined on paper but not met or not measured
Test (mechanisms)	Mechanisms supporting complaint management, such as ticketing or tracking tools	Tool configuration, ticket workflow and status fields, audit trail of changes, reporting output used for review	Tracking is done in email or spreadsheets with no record of review or escalation
Review of complaints	Procedures addressing the reviews of complaints and their outputs	Review cadence, meeting notes or sign-offs, corrective actions linked to complaint trends	No evidence that recurring complaints were reviewed or fed back into privacy practices

Implementing PM-26 complaint management in sequence

This sequence turns PM-26 from a policy statement into a working intake, tracking and review process that an assessor can test end to end, with each step leaving a record the organization can show.

Approve the complaint procedure in the privacy program plan
The privacy program leadership, with the senior agency official for privacy, writes the complaint management procedure and places it in the privacy program plan so that scope, roles and the decision-maker for responses are settled before any channel goes live. The output is a versioned privacy program plan section with documented approval and a date, which covers the first determination statement an assessor examines. Confirm with your assessor how they expect the procedure to be named and where it must sit within your plan documents.
Define public and internal complaint channels
Privacy and security owners list every route a complaint, concern or question can arrive by, such as a published web form, a privacy mailbox, a phone line or a staff referral path, and state what information a submitter needs to provide. Publish the public mechanisms in a place people can find without an account, and confirm that the internal path reaches the same queue. The output is a channel register and a screenshot or copy of each published mechanism, dated and tied to the procedure.
Set acknowledgment and response periods
The procedure sets the acknowledgment and response periods that PM-26 requires the organization to define, and records who measures them and how breaches are reported. Because NIST does not prescribe a number in the supplied facts, the organization chooses its own periods based on its legal and contractual obligations and should confirm them with counsel and its privacy officials. The output is a documented service standard that the ticketing system can enforce, which an assessor can compare against actual ticket timestamps.
Configure the ticketing system and its categories
The team configures a ticketing system so every complaint becomes a tracked record with a unique identifier, a category, a status and time stamps for receipt, acknowledgment and closure. Open-source options such as GLPI, whose Assistance module supports tickets, problems and changes following ITIL practices, or Zammad, which gathers email, chat, telephone and social media messages into one ticket system, can serve this role if they meet your requirements. Confirm each platform's capabilities before selecting it. The output is a configuration export, a category list and a test ticket showing the full life cycle.
Assign owners and escalation paths
Named owners receive complaints by category, and the procedure defines who reviews privacy-related matters, who handles security concerns and who escalates to the senior agency official for privacy when a complaint raises legal or systemic issues. Access to complaint records is limited to people with a need to know, which protects the submitter's information. The output is a responsibility matrix, the escalation rules configured in the ticketing system and signed acknowledgments from the people named, which supports the interview method an assessor will use with privacy program staff.
Run a pilot with controlled test complaints
Before public launch, the team submits test complaints through each channel, including a question, a concern and a formal complaint, and walks each one through acknowledgment, assignment, response and closure. Gaps found here, such as a missing category, an unmonitored mailbox or an escalation that never fires, are logged and fixed before go-live. The output is a pilot report listing each test, the observed time stamps, defects found and the fixes applied, which shows that the process has been tested rather than only documented.
Launch and set a periodic review of complaint trends
After the pilot, the organization opens the channels publicly and schedules a periodic review in which owners analyze complaint volumes, categories, overdue items and recurring root causes, then feed findings into privacy and security improvements. The review frequency is set in the procedure and recorded in the privacy program plan. The output is dated review minutes, a trend summary and any corrective actions tracked to closure, which show the reviews the assessor will examine in complaint documentation and review procedures.

Evidence that shows PM-26 works in practice

PM-26 is tested through documents, records and live mechanisms, so an assessor expects the procedure, the public channel, the logs and the review trail to agree with one another. The cards below describe each artifact, what a complete version looks like and how to keep it current between assessments.

Documented complaint procedure

The written procedure defines what counts as a complaint, concern or question about security or privacy practices, who receives it, how it is triaged, who decides the outcome and when it is escalated. Assessors use it as the baseline for the procedures-addressing-complaint-management determination statement. Check that the procedure names the owning role, the defined acknowledgment and response periods, and the link between complaint review and the privacy program plan. Review it on a set schedule and after any change to privacy or security governance.

Public contact mechanism

The public channel must be easy to find and use, and it must tell people what information to include when filing a complaint. Confirm that the mechanism is published on the principal public website, that it accepts submissions without an account, and that the instructions state what details help the organization act. Test the form or address periodically from outside the network, and record the test date. Broken forms and unmonitored mailboxes are common findings in test procedures.

Complaint logs with status history

A complaint log records each item with a unique identifier, receipt timestamp, category, assigned owner and a timestamped history of every status change through closure. Assessors sample entries to confirm that complaints are tracked from receipt to resolution rather than handled informally. Confirm that the tool keeps an audit trail of edits, so the history cannot be silently rewritten. Ticketing systems such as GLPI or Zammad can hold this record, provided the fields and status values are configured to match the procedure.

Acknowledgment and response records

For each sampled complaint, the file should show when acknowledgment was sent, when a substantive response was issued and whether both fell within the periods the organization defined. Late items need a recorded reason and an escalation trail. Ask the team to report the count of overdue complaints each review cycle, because an assessor will compare the records against the defined periods rather than the procedure's intent. The metric is only meaningful if the periods themselves are stated in the procedure.

Review minutes and reports

PM-26 expects complaints to be reviewed, not only closed. Keep minutes or a short report from periodic reviews that show which complaint themes were examined, which decisions were made and which follow-up actions were assigned, with owners and dates. Reports also feed PM-27 privacy reporting and PM-31 monitoring where those controls apply. Confirm that the reviewing body is the one named in the procedure and that attendance and sign-off are recorded.

Closed complaints with outcomes

Keep a set of closed complaints, anonymized where needed, that show the full path from intake to a documented outcome, including any change to a practice, notice or system. Assessors use these examples to test whether the process produces results. Include cases where the complaint was not upheld, with reasons, so the record does not look selective. Maintain them under the same retention and access rules as the source log.

Retention and access controls

Complaint records often contain personal data, so the retention period, the people allowed to read them and the deletion method should be written down and enforced. Restrict access to the named complaint owners and reviewers, log access where the tool supports it, and check that exports and attachments follow the same rules. Ask the privacy office to confirm the retention period against applicable law and the organization's records schedule, since this page does not set one.

What meeting PM-26 costs in money and effort

This table breaks down the cost components of running a PM-26 complaint process, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a written scope and to see where open-source helpdesk tooling removes license spend while staff, configuration and review effort remain.

Cost component	One-time or recurring	Who is paid	What drives it
Helpdesk tooling and licenses	Recurring for commercial licenses, one-time for setup	Software vendor, or no license fee for self-hosted open-source tools such as GLPI or Zammad	Number of named agents, hosting choice, and whether vendor support is bought
Hosting and infrastructure for the ticket system	Recurring	Internal platform team or cloud provider	Where complaints are stored, availability expectations and backup retention
Configuration and channel integration	One-time, with later changes	Internal engineers or an implementation partner under a written scope	Number of public channels (web form, email, phone, social), and how many need connecting to the ticket system
Procedure drafting and approval	One-time, with periodic review	Privacy office, legal counsel and senior approver time	Number of complaint types, the defined acknowledgment and response periods, and how many approvers sign off
Staff time to triage and respond	Recurring	Internal privacy, security or customer staff	Complaint volume, complexity of each case, and whether regulated personal data is involved
Integration with privacy and incident processes	One-time build, recurring upkeep	Internal staff or implementation partner	Links to incident response and privacy reporting, and whether escalations trigger incident workflows
Periodic review and reporting	Recurring	Privacy office and senior leadership	Review frequency set by the organization, and the volume of tracking data reported
Independent assessor time	Recurring per assessment cycle	Independent auditor or assessor, not the implementation partner	Breadth of evidence requested, number of complaint samples examined, and interview scope

Self-hosted open-source tools that keep complaint records

PM-26 asks for a complaint process that is easy to reach, tracked to resolution and reviewed on defined timelines. Two self-hosted ticketing platforms, GLPI and Zammad, can hold the records that show this happened. Each card below covers one tool or one check that matters before you rely on it as evidence.

GLPI Assistance module for tickets

GLPI's Assistance module lets users create, follow and process tickets, problems and changes using ITIL practices. For PM-26, a complaint can be logged as a ticket with its own history, so the record shows when it arrived, who handled it and how it was closed. Confirm that your chosen GLPI version supports the ticket categories, approval steps and retention settings your complaint procedure needs before you configure it. Test the workflow with sample complaints.

GLPI plannings and statistics

GLPI includes plannings and statistics that can show how many complaints were opened, how long they stayed open and where they stalled. These reports support the review of complaints that PM-26 expects, and they give the privacy or security lead material for periodic reporting. Confirm which report types your version produces and whether they can be scheduled, exported or filtered by complaint category. Keep exports with the review minutes they support.

GLPI recurrent tickets and Kanban view

Recurrent tickets help teams handle complaints that return on a schedule, such as periodic privacy review requests. The Kanban view lets reviewers see open complaints by stage and spot those that are close to a response deadline. Neither feature replaces a documented response time, so define acknowledgment and response periods in your procedure and confirm that the Kanban view and recurrence rules can reflect them.

Zammad multichannel ticket intake

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. This matters for PM-26 because complaints often arrive through channels other than a formal web form, and each one should still create a record. Confirm which channels your installation connects, how inbound messages are linked to a ticket and how the public contact point is published.

Zammad ticket history for evidence

Zammad keeps the conversation and state changes on each ticket, which an assessor can use to test whether complaints were acknowledged and resolved within defined periods. Check that timestamps, agent assignments and status changes are retained and cannot be silently edited by ordinary users. Confirm the audit and export options of your version, and decide where closed ticket records are archived.

License obligations for GLPI and Zammad

GLPI is licensed under GPL-3.0-or-later and Zammad under AGPL-3.0-only. The AGPL adds obligations for users who modify Zammad and make it available to others over a network, so a customized, hosted helpdesk can carry duties that a standard installation does not. Confirm your obligations with counsel before you modify either product, especially if you expose a portal to outside complainants or to customers.

Who owns PM-26 and who can help prepare it

Your organization owns PM-26 in full. The complaint procedure is a governance document, so it must be approved by the people accountable for the security and privacy program, and it must reflect how your organization actually receives and resolves concerns. Staff who triage complaints, decide on privacy questions and sign off on responses are your employees or contracted personnel acting under your authority. A partner can draft procedure text, but it cannot decide what your organization commits to or how a privacy concern is resolved. Assessors interview these people, so they must know the process and be able to explain it.

Procedure ownership: Approve the complaint procedure, name its owner and set how often it is reviewed.
Triage staffing: Assign who reads incoming complaints, who escalates them and who covers absences.
Privacy decisions: Keep determinations about privacy impact, data correction and disclosure with the privacy officials.
Response commitments: Define the acknowledgment and response periods yourself, and confirm they match your contracts and regulatory obligations.
Interview readiness: Make sure personnel with privacy program responsibilities can describe the process and point to records.

Before engaging anyone, confirm internally who holds each of these roles and where the approved procedure is stored.

Questions buyers ask about PM-26 complaint management

How much effort does PM-26 complaint management take to put in place?

The effort depends mostly on how many channels already receive privacy and security concerns, how many teams touch those concerns today, and whether a ticketing process exists to track them. An organization that already routes customer and staff questions into one queue has far less to build than one where complaints arrive by email to several mailboxes and are handled informally. Work typically splits into defining the complaint categories and response periods, setting up a public mechanism, configuring tracking, writing the procedure, and training staff to follow it. Ask any partner to list each of these items in the written scope, with the systems and teams involved, so the effort can be checked against your environment.

Can an in-house team meet PM-26 without an outside partner?

Yes, in principle. PM-26 is a process requirement, and an internal privacy or compliance team can write the procedure, select a tool, and keep the records itself. The harder parts are usually the ones that cross teams: getting engineering, legal and customer support to agree on who investigates a complaint and who signs off on the response, and producing evidence that the process ran as written. An outside partner can help with the technical setup and with preparing evidence for an assessor, but it cannot decide what your organization promises, and it does not issue assessment results. Confirm internally whether your team has the capacity to run the process continuously, not just to build it once.

How long does preparation usually take, and what sets that timeline?

No duration is fixed for PM-26, and any figure a vendor gives should be tied to a written scope. The timeline is driven by the number of complaint channels to be consolidated, whether a ticketing system is already in use, how many approvals the response procedure needs, and how quickly your teams can review and agree the defined acknowledgment and response periods. Migration of existing mailboxes or forms into a tracked queue often takes longer than the policy writing. Ask for a schedule that separates design, configuration, procedure approval and a trial period in which real or sample complaints move through the process end to end.

What does the work need from our organization?

The work needs a small set of named people and access, and most delays come from leaving these undefined. Name an accountable owner for the complaint process and a reviewer for each complaint category. Provide access to the channels that receive complaints, such as the privacy mailbox, web forms or support desk. Supply sample complaints, anonymized where needed, so the workflow can be tested against realistic cases. Identify who approves the procedure and the response wording, and who has authority to close a complaint. Confirm these items in writing before work starts, since each one affects the scope and the testing.

Does PM-26 apply to a system that is not in the privacy baseline?

PM-26 is a program management control, and SP 800-53B does not allocate it to the low, moderate or high security baselines. It is included in the privacy baseline, which applies to systems regardless of impact level. For a system outside the privacy baseline, the practical question is whether that system processes personally identifiable information or whether your organization has a complaint obligation under its own policy, contract or regulator. Confirm with your privacy office how the control is scoped in your SP 800-53 program, and document that decision in the privacy program plan so an assessor can trace it.

What evidence will an assessor ask to see for PM-26?

SP 800-53A organizes the assessment around examining the privacy program plan, the complaint management procedures, complaint documentation and the procedures for reviewing complaints, interviewing the personnel with privacy program responsibilities, and testing the complaint management processes and supporting mechanisms. Practically, that means a current procedure, a public contact mechanism that is easy to find, complaint records with timestamps and outcomes, and evidence that reviews happened. Confirm with the assessor which samples they will select and which records they will accept, because the format of the evidence matters as much as its existence.

How DeployOpen scopes and prepares PM-26 evidence

DeployOpen helps organizations set up the complaint intake, tracking and response records that PM-26 asks for, inside their own self-hosted infrastructure. The organization owns its complaint process and decisions, and DeployOpen prepares the systems, procedures and evidence for an independent assessor to review.

How we scope

The written scope names the public complaint channels, intake fields and privacy contacts to be configured for PM-26.
The scope lists which tracking, acknowledgment and response periods the organization has defined and must evidence.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the agreed open-source ticketing platform in your environment and configure intake, categories and routing.
We set up ticket fields and status workflows so each complaint shows receipt, review, response and closure dates.
We test the intake and tracking mechanisms against the examine and test methods in SP 800-53A for PM-26.

How we hand over

We document the complaint management procedure, roles and escalation paths in a form your assessor can examine.
We deliver sample ticket records, configuration exports and review logs that show how complaints were addressed.
We walk your privacy and security staff through daily operation so they can answer interview questions with confidence.

How we support

Ongoing support, upgrades and continuous testing of the complaint platform are available as a retainer.
A retainer can cover periodic review of tracking reports and updates to procedures as the privacy program changes.
Your organization remains responsible for engaging an independent auditor or assessor, who alone issues any report.