PM-20 Dissemination of privacy program information

PM-20 asks for a central privacy resource page on your principal public website that shows privacy practices, reports and the senior official for privacy, with ways for the public to ask questions. Here is what passes assessment and what it costs to meet.

On this page

PM-20 dissemination of privacy program information: what the requirement asks for

PM-20 requires a central privacy resource webpage on the organization's principal public website, one that gives the public access to privacy activities, names the senior agency official for privacy, publishes privacy practices and reports, and offers public email addresses or phone lines for privacy questions and feedback. In plain terms, an assessor or a privacy-aware customer should be able to find, in one place, how the organization handles personal information, what it has reported about that work, and who to contact. The risk this addresses is simple: individuals cannot learn how their PII is handled or who to ask when they have a concern, and that gap undermines trust in the rest of the privacy program.

What usually makes this hard is not the webpage itself but the material behind it. Privacy notices sit on one site, annual reports on another, and policies in a document repository that the public cannot reach. Reports go stale because no one owns the update cycle, and the contact route for privacy questions goes to a general mailbox that nobody monitors. The first decision is ownership: name the team that maintains the page, the senior agency official for privacy whose role it describes, and the person who approves each posting. The second is inventory: list every privacy practice document and report the organization already publishes, then check which are current, which are missing and which contradict each other.

Before any assessor interview, confirm three things: the page is reachable from the principal public website's main navigation, every link resolves, and the privacy contact routes are monitored and tested. Ask the organization's privacy office to confirm the publication date and review cycle for each document, and ask whether the page also covers the website and app privacy policies that the PM-20(1) enhancement adds in the SP 800-53B privacy baseline. The NIST SP 800-53A assessment procedures show how an assessor will examine the site, interview responsible staff and test the page. Whether a particular privacy practice satisfies the requirement is a judgment the organization and its independent assessor make, not one a web team can settle alone.

Which websites, documents and teams PM-20 reaches

PM-20 is a Program Management control deployed across the organization, not allocated to the low, moderate or high baselines, but it sits in the privacy baseline that applies regardless of impact level. The decisions below determine which pages, documents and contact channels an assessor will test.

Identifying the principal public website

PM-20 asks for a central privacy resource webpage on the organization's principal public website. Start by confirming which domain the public treats as the main presence, which may differ from a holding company site, a product marketing site or a regional subdomain. Record that decision in the privacy program documentation, because an assessor will examine that specific site and check that the privacy page is reachable from it. Confirm with the privacy office and the web owner before building anything.

Deciding whether app privacy policies count

The PM-20(1) enhancement, which the privacy baseline adds, expects website and app privacy policies to be posted and kept consistent. Decide whether mobile apps, browser extensions or customer portals are in scope, and list each one with its store listing or login page. An app that collects personal data but links only to a generic policy is a common gap. Ask the product owners to confirm the policy text matches what the app actually does.

Choosing which privacy documents to post

The assessment examines publicly posted privacy program documents, including policies, procedures, plans and reports. Decide which of these the organization will publish, such as the privacy program plan under PM-18, privacy reports under PM-27 and the notice of privacy practices. Anything posted must match the internal version, so set a single document owner and a review date. Documents kept only internally need a recorded reason for not publishing them.

Assigning the contact channels

PM-20 requires public email addresses or phone lines for privacy questions and feedback. Assign each channel to a named team, such as the privacy office, the data protection contact or a shared mailbox with a monitored owner. Confirm who receives messages overnight, who logs them and who answers. Assessors interview the people with dissemination responsibilities, so each person must know what the channel is for and what the organization has promised publicly.

Treating third-party hosted pages and portals

Privacy pages are often hosted by a vendor, a consent management platform or a regional affiliate. Decide whether a page on a third-party domain counts as the organization's principal website, and whether a link from the main site to that page is enough. Record each hosted component in the inventory, confirm contractual responsibility for uptime and content changes, and test that the page loads and the contact details work from the public site. Do not assume the vendor's default page meets the control.

Confirming the privacy baseline reach

PM-20 is a Program Management control deployed organization-wide, so it is not tied to a system's impact level. It is included in the SP 800-53B privacy baseline, which applies to systems irrespective of impact level. Scope the control once for the organization, then confirm which systems processing PII fall under the privacy baseline. Ask the assessor how they expect the organization-level evidence to be linked to those systems.

Why PM-20 applies to every system that processes PII

PM-20 sits in the privacy baseline rather than the low, moderate or high security baselines because SP 800-53B treats Program Management controls as deployed across the organization, supporting the information security program, and not as system-level controls tied to an impact level. The practical effect is that the control is not selected by categorizing a system as low, moderate or high. Instead, it applies to any system that processes personally identifiable information, regardless of impact level. A low-impact system that handles PII therefore carries the PM-20 requirement even though it carries no security baseline control for this purpose. Confirm the baseline selection with your privacy office before you assume a low-impact system is out of scope. Record the decision in the system security and privacy plan so an assessor can trace it.

The privacy baseline adds the PM-20(1) enhancement, which expects the organization to post website and application privacy policies. This is the point where the organizational webpage requirement reaches into the systems themselves. For each public website and each mobile or web application that collects PII, check that a privacy policy is published, that it is reachable from the entry point users actually use, and that it matches the processing the system performs. Confirm the exact wording of the enhancement in the NIST CPRT and the 800-53B privacy profile before you write test procedures, because the discussion text, not just the control title, shapes what an assessor will look for.

The catalog links PM-20 to AC-3, PM-19, PT-5, PT-6, PT-7 and RA-8. The overlap is practical. PM-19 covers the senior agency official for privacy whose position description PM-20 expects to be posted, PT-5 and PT-6 cover privacy notices and system of records notices that often become the published content, PT-7 covers specific categories of PII, and RA-8 covers privacy impact assessments whose summaries may be shared publicly. AC-3 covers access enforcement that the privacy webpage's contact channels should not bypass. Confirm the detailed mapping for each of these in the NIST CPRT, since the relationships are stated there and should be reviewed against your own control implementation statements.

How an assessor tests PM-20 under SP 800-53A

This table maps the three SP 800-53A assessment methods for PM-20 (examine, interview and test) to the evidence an assessor will ask for and the findings that commonly come up. Read each row as a check the organization should run on its own privacy webpage before an assessor does.

Assessment methodEvidence the assessor will requestCommon findings
Examine the public websiteLive URL of the central privacy resource page, its location on the principal public website, and a dated screenshot or crawl recordPrivacy page buried several menus deep or only reachable by site search; page not linked from the site footer
Examine posted privacy program documentsPrivacy policies, procedures, plans and reports published on the page, with publication or revision datesOutdated reports still presented as current; plans referenced on the page but not actually posted
Examine the senior agency official for privacy position descriptionCurrent position description or role charter for the senior agency official for privacy, and confirmation that it matches the public contact listedPosition description missing, out of date, or naming a role that no longer exists
Interview dissemination responsibility holdersNamed owners for page content, publication approvals, update schedule and the process for answering public privacy questionsStaff unable to say who updates the page or how often; no documented ownership
Test location and accessNavigation path from the homepage, search results, and sitemap entry for the privacy page, with the date testedPage blocked by robots settings, requires login, or sits on a subdomain with no link from the main site
Test availability and functionalityLink-check results across all posted documents, uptime records, and a sample of working public contact routesBroken links to reports or policies; contact form that returns errors; phone line or mailbox unmonitored
Test public contact routesEvidence that a public email address or phone line reaches a privacy official, including a test message and recorded responseNo working contact route; email address goes to a generic inbox with no privacy owner

Implementing PM-20 in five steps

This sequence turns PM-20 into a public privacy resource that an assessor can find, read and test, with each step producing a record the organization can show as evidence. It starts with ownership of the website and ends with proof that the page and contact channels work for the public.

  1. Confirm the principal website and page owner

    Identify the organization's principal public website, the page that will serve as the central privacy resource, and the named owner who keeps it accurate. Confirm with the senior agency official for privacy, or whoever holds that role, which site is authoritative, since PM-20 ties the page to the principal public site rather than to internal portals. The output is a short ownership record naming the site, the page location and the accountable owner, approved by the privacy leadership. Treat this as done when the owner can state who approves changes to the page.

  2. Inventory privacy documents and reports

    List every privacy document and report the organization intends to publish, such as privacy policies, procedures, program plans and periodic privacy reports, and record the owner, the current version and the review cycle for each. Compare the list against the privacy program documents already maintained under PM-18 and PM-27 so the public set is consistent with internal records. The output is a publication register with one row per item, its update trigger and its next review date. Done means every item has an owner and a stated review cycle that someone is accountable for meeting.

  3. Build the central privacy resource page

    Create or consolidate the central privacy page on the principal website. It should describe privacy activities, link to the publication register items, state the role and contact details of the senior agency official for privacy, and explain how the public can raise privacy questions. Draft the content from the register and have privacy counsel review wording before publication. The output is the published page and a content record showing the approver and publication date. Done means every item in the register is reachable from the page and the senior official's role is described in the page's own words.

  4. Set up monitored public contact channels

    Establish a public email address or phone line for privacy questions and feedback, and assign each channel to a monitored queue with named staff who can respond. Confirm where messages go when staff are absent and who reviews the queue. Link the channel to the complaint handling process under PM-26 so questions and complaints are logged consistently. The output is a channel record with the address or number, the queue owner, the coverage arrangement and a sample log showing how a test message was received and routed. Done means a test message reaches a person who can act on it.

  5. Test availability, links and mobile access

    Test the page as an outside visitor would. Check that it loads, that every link to a publication opens the correct current version, that contact details are accurate, and that the page works on common mobile devices and browsers. Confirm that the page is reachable without an internal login and that search engines or site navigation can find it from the home page. Record results in a test log with the date, tester, the pages and links checked, and any defects with their fixes and retest results. Done means the log shows a clean retest.

  6. Test app and website privacy policy content

    Where the organization operates websites or mobile apps that process personal data, confirm that the website and app privacy policies are published on the central page, are current, and match what the software actually does. This is the PM-20(1) enhancement in SP 800-53B's privacy baseline context, so check the enhancement wording in the NIST catalog before scoping it. Compare each policy against the system's data flows and record discrepancies for correction. The output is a policy test record listing each app or site, the policy version, the reviewer and any gaps with owners. Ask the reviewer to confirm that the policies are consistent with the privacy program documents in the register.

Evidence that satisfies PM-20 and how to keep it current

An assessor testing PM-20 looks for proof that the privacy resource page exists, works, and reflects current practice. The artifacts below cover the page itself, the documents it links to, the people behind the contact channels, and the review records that show the page is maintained between assessments.

Dated captures of the privacy page

Keep dated screenshots and full-page captures of the central privacy resource page on the principal public website, stored with the URL, capture time and the reviewer's name. Capture it at a fixed cadence and after every change to navigation, footer links or the privacy section. An assessor comparing a capture to the live site will ask whether the page reached the public, so record the path from the homepage as well. Illustrative: a quarterly capture set with a footer-link check beside each entry.

Publication register of posted documents

Maintain a register listing every privacy practice document, report and policy published on the page, with its title, version, publication date, owner and the URL where it sits. The register is the evidence that practices and reports are actually made public rather than drafted internally. Add an entry when a document is posted and mark retired documents instead of deleting them, so the history stays intact for the assessment period.

Senior agency official position description

Keep the current position description for the senior agency official for privacy, since PM-20 expects the page to give public access to that role. Confirm the description matches the official's appointment record and the name and role shown on the page. Revisit it when the appointment changes, and keep prior versions so the assessor can see who held the role during the period under review.

Contact channel and routing records

Document the public email addresses or phone lines listed for privacy questions and feedback, along with who receives each message and the routing path to the privacy office. Test that each channel reaches a monitored inbox, and keep a log of test messages and replies. Review the list whenever staff change, because a dead address on a public page is a common finding that undermines the rest of the evidence.

Link check and availability test results

Run scheduled link checks and availability tests against the privacy page and every document it links to. Save the results with timestamps, including broken links, redirects, and load failures, and record how each was fixed. The assessor's test method checks location, access, availability and functionality of the page, so these logs show the page worked across the period rather than only on the day of testing.

Change log and review cycle records

Keep a change log for the page and its documents showing what changed, when, who approved it and why, along with the review cycle that triggers updates. Tie reviews to changes in privacy law, organizational structure or the privacy program plan so the page does not drift. Confirm the review frequency with the privacy office and your own policy, since the control does not set one in the supplied facts.

What meeting PM-20 costs in money and effort

This table lists the cost components of publishing a central privacy resource page under PM-20, who typically carries each one, whether it is one-time or recurring, and what pushes it up or down. No figures are given because none are supplied for this control, so use the table to structure a written scope and quote request.

Cost componentWho is paid or who spends effortOne-time or recurringWhat drives it up or down
Content and document preparationPrivacy staff, with legal input on policy text, reports and the senior agency official for privacy descriptionOne-time build, then recurring updatesUp: number of policies, reports and languages. Down: reusing existing privacy notices and a defined document inventory
Web development and page buildInternal web team or an implementation partner building the privacy hub on the principal public websiteOne-timeUp: custom templates, integration with a separate CMS or many sites. Down: one hub page linked from the main site navigation
Hosting and web platform operationInternal platform team or hosting provider; with a self-hosted open-source web stack, the organization still pays for infrastructureRecurringUp: traffic, redundancy and availability requirements. Down: sharing the existing public website infrastructure
Legal and privacy review of published textLegal counsel and the privacy office reviewing wording before each publicationRecurring, per changeUp: frequent policy changes and multiple jurisdictions. Down: a fixed review cycle and change log
Contact channel operationPrivacy office staff or a shared service handling public email addresses and phone linesRecurringUp: volume of inquiries and response expectations. Down: clear routing rules and published contact guidance
Testing and link monitoringWeb or QA staff checking that the page is reachable, functional and its links resolveRecurring, with a one-time test planUp: number of linked documents and apps. Down: automated link checks run on a schedule
Assessor timeIndependent assessor examining the public site, documents and interviewing dissemination staffPer assessment cycleUp: number of sites, apps and documents in scope. Down: a single, well-indexed privacy hub with current documents
Written scope and quoteAny implementation partner or internal project lead produces the scope before work beginsOne-timeAsk for named deliverables, document count, site and app count, languages and expected update frequency

Who owns PM-20 and what an implementation partner can take on

Your organization owns PM-20 in full. The control requires a central privacy resource webpage on your principal public website, so the accountable senior agency official for privacy, the privacy office and the people who publish content must agree on what the page says, who keeps it current and how the public reaches privacy officials. Nothing in the control transfers to a vendor or consultant.

  • Accountable senior official: Confirms the privacy activities, practices and reports that the page must show, and signs off on the public-facing position.
  • Content owners: Maintain privacy practices, reports and the position description content, and decide when each item is updated or withdrawn.
  • Web and legal reviewers: Check accuracy of wording, consistency with the published privacy notices and the legal basis for each statement before publication.
  • Contact-channel owners: Operate the public email addresses or phone lines, monitor them and keep them working, since assessors can test whether they respond.

Confirm early who holds each of these roles by name, because assessors will ask to interview the people responsible for dissemination.

Where PM-20 programs usually fall short

Most PM-20 gaps are not missing policies. They are privacy information that is hard to find, out of date, or has no one accountable for keeping it working. The cards below cover the failure points an assessor is most likely to test, and what to change before the test.

Privacy page buried in the site

PM-20 asks for a central privacy resource webpage on the organization's principal public website. A page that exists but can only be reached through search, a footer link to a legal archive, or an old domain does not give the public the access the control describes. Check that the homepage or the main footer links to the privacy page in one step, and that the page sits on the principal domain rather than a microsite. Record the navigation path as test evidence, since the assessor will likely follow it themselves.

Senior official with no public route

PM-20 expects the public to have access to the senior agency official for privacy, and the discussion expects public email addresses or phone lines for privacy questions. Naming the official in an internal document or org chart is not enough. Publish the role title and a monitored contact route on the privacy page, and confirm that the position description used in assessment matches what the page says. Ask legal and privacy leads to agree who is named publicly and whether a role mailbox is used instead of a personal address.

Reports posted but stale

Privacy practices and reports must be publicly available, and an assessor will compare the posted documents with the current program. Reports that stop at a past year, policies that name retired systems, or plans that reference superseded roles signal that no one owns the refresh cycle. Assign each posted document an owner and a review date, and add a check that flags any document older than its review cycle. The privacy program plan and privacy reporting outputs under PM-18 and PM-27 are the usual sources to reconcile against.

Mobile app privacy policies missing

The PM-20(1) enhancement, included in the privacy baseline, asks for website and app privacy policies. Teams often publish a web policy and forget that a mobile app needs its own, linked from the app store listing and from inside the app. Inventory every public app and website, confirm each has a policy that matches the data it collects, and test the in-app link after each release. An app without a reachable policy is a visible gap that is easy for an assessor to find.

Contact channels with no owner

A privacy mailbox or phone line that nobody watches looks compliant on the page and fails in practice. PM-20 contact routes need a named owner, a triage process, and a record of questions received and how they were answered. Without that record, the organization cannot show the channel works. Set up a ticketed inbox or log, define who responds and within what internal timeframe, and keep the log as interview and examination evidence. Confirm the expected response times with privacy leadership rather than assuming them.

No test after each release

The assessment procedure for PM-20 includes testing the location, access, availability and functionality of the privacy resource webpage. Pages break after site redesigns, certificate changes, CMS migrations and app releases, and nobody notices because the page is outside the normal release checks. Add the privacy page, its links and its contact forms to the release checklist and to scheduled uptime monitoring. Keep dated screenshots or automated check results so the organization can show the page worked when the assessor asks.

PM-20 questions buyers and practitioners ask

How much effort does PM-20 take for a single public website?

For a single principal public website, PM-20 is usually a bounded content and publishing task rather than a technical build. The effort comes from three things: assembling the privacy materials the control expects the public to find, such as privacy practices, reports and the senior agency official for privacy, keeping them current, and making sure the contact channels work. The control does not prescribe a page design or a content management system. Your effort rises if privacy documents are scattered across legal, HR and product sites, if the privacy program has no single owner for publication, or if contact routes are not staffed. Ask your team to inventory the existing privacy content before estimating anything, because that inventory sets the scope.

Can we implement PM-20 in-house without outside help?

Yes, an organization can implement PM-20 with its own staff, and many do. The organization owns the control, and only it can decide what the privacy page says and who answers questions. Outside help is most useful when the privacy content is fragmented, the site is hard to change, or the team lacks someone who can map privacy artifacts to the control's expectations. An implementation partner can prepare the page, consolidate documents and organize evidence, but it does not issue assessment conclusions. Independent assessors or auditors test the control. If you bring in help, agree the scope, deliverables and handover in writing before work starts.

What does PM-20 need from the privacy and web teams?

PM-20 needs a shared plan between the privacy function and the team that runs the public website. The privacy team must confirm the senior agency official for privacy, select the reports and practices to publish, and provide public contact routes that someone monitors. The web team must host a central privacy resource page on the principal public site, keep it reachable and functional, and manage updates. Typical responsibilities include:

  • Privacy team: approve content, name the official, define who answers public email or phone inquiries
  • Web team: build and maintain the page, check links and availability, control change history
  • Legal or communications: review wording so the published material matches actual practice

Write these responsibilities down, because an assessor will test whether the page and its owners match.

How long does PM-20 take to implement?

The timeline depends on your own scope, and NIST does not set implementation timelines for SP 800-53 controls. Its risk management guidance leaves timing decisions to the policy that governs your organization, so take the duration from your own inventory of privacy content, the number of sites and contact channels in scope, and the approval steps your legal and communications functions require. Ask any implementation partner to tie its schedule to a written scope with defined deliverables. Be cautious of any timeline that is not connected to that scope.

Does PM-20 apply to low-impact systems?

Yes, PM-20 applies to low-impact systems through the privacy baseline. SP 800-53B places Program Management controls at the organization level, independent of system impact level, so PM-20 is not allocated to the low, moderate or high security baselines. It is included in the privacy baseline, which applies to systems regardless of impact level. The privacy baseline also adds PM-20(1), the website and app privacy policy enhancement. Confirm with your privacy office which systems fall under the privacy baseline in your environment, because that determines how far the enhancement reaches.

What will an assessor ask to see for PM-20?

An assessor follows the SP 800-53A procedure for PM-20, which uses examine, interview and test methods. Expect to show the public website, the privacy documents posted there, including policies, procedures, plans and reports, and the position description of the senior agency official for privacy. Expect interviews with staff who handle privacy information dissemination. For testing, expect the assessor to confirm that the privacy resource page is locatable, accessible, available and functional, and that public email or phone channels work. Keep a record of page versions, publication dates, responsible owners and test results so you can show the control operating over time. Only the independent assessor issues the conclusion.

How DeployOpen prepares PM-20 evidence

DeployOpen prepares the systems, content and records that show PM-20 is in place, including the privacy resource webpage and the public contact routes. The organization owns its privacy program and its public statements, and an independent assessor makes the determination.

How we scope

  • We agree in writing which public websites, privacy pages and contact channels fall within the PM-20 scope.
  • We confirm with the senior agency official for privacy which privacy reports and practices must be published.
  • Engagements are fixed-scope, so deliverables and timelines for PM-20 are agreed before work begins.

How we build

  • We set up or configure a central privacy resource page on the principal public website in your own environment.
  • We organize privacy policies, program plans and reports so they can be located, dated and published on that page.
  • We test the location, access, availability and functionality of the page and its public contact routes.

How we hand over

  • We document the page structure, publication steps and owners so staff can keep the content current.
  • We deliver an evidence pack that maps the webpage, published documents and contact tests to the PM-20 assessment procedure.
  • We walk your privacy and web teams through the handover so they can answer assessor questions directly.

How we support

  • Ongoing support, upgrades and periodic checks of the privacy page are available as a retainer.
  • We can review the page again when privacy reports, officials or contact details change.
  • Assessment itself stays with your independent auditor or assessor, who reviews the evidence we prepared.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.