PM-20(1): Privacy Policies on Websites, Applications, and Digital Services

PM-20(1): privacy policies on websites, applications, and digital services requirement means you must publish an accurate, accessible privacy policy anywhere your organization collects, uses, shares, or stores personal data through an external-facing digital experience. Operationalize it by inventorying all public digital services, mapping data practices, publishing policy links in-product, and keeping versioned evidence of what was posted and when. ¹

Key takeaways:

• Treat this as an “every external digital surface” control: websites, mobile apps, and any public digital service need a posted privacy policy. ¹
• Your policy must match real data flows; the fastest path is a data-practices mapping tied to each app/site release cycle. ¹
• Auditors will ask for proof of posting and governance, not just a PDF; retain screenshots, URLs, timestamps, and change history. ¹

PM-20(1): privacy policies on websites, applications, and digital services requirement sits at the point where privacy governance meets customer experience. If your organization operates an external-facing website, a mobile app, a portal, or an online service that processes personal data, your privacy commitments need to be visible to the people whose data you handle. This is more than “have a policy somewhere on the corporate site.” Assessors typically interpret PM-20(1) as requiring consistent, accessible posting across each customer-facing digital service, with content that reflects actual data practices. ¹

For a Compliance Officer, CCO, or GRC lead, the quickest way to make this real is to turn PM-20(1) into a repeatable operating mechanism: a system inventory, a minimum posting standard (where the link appears and what the policy covers), a review workflow connected to product changes, and evidence that survives an audit. This page gives you a requirement-level implementation playbook you can hand to Privacy, Product, Engineering, Marketing, and Legal and then measure. ¹

Regulatory text

Control excerpt (provided): “Develop and post privacy policies on all external-facing websites, mobile applications, and other digital services, that:” ¹

What the operator must do with this text

PM-20(1) requires two things you can operationalize:

1. Develop privacy policies (create and maintain policy content that describes your practices for the digital service). ¹
2. Post those privacy policies on all external-facing websites, mobile applications, and other digital services (make them available to the public/user in the context where data is collected/used). ¹

The excerpt ends with “that:”, which signals there are additional specifics in the full control text. If you are implementing against a federal contract or a system authorization boundary, pull the complete PM-20(1) enhancement text from the NIST catalog you are using for your assessment and implement the remaining bullets as acceptance criteria. ²

Plain-English interpretation

Publish a privacy policy anywhere a user can interact with you digitally, and keep that policy aligned to how the digital experience actually processes personal data. If the user downloads an app, signs into a portal, chats with support, submits a lead form, or uses a public API console, they should have a clear path to the privacy policy from that surface, not only from a corporate footer that may not be visible in-app. ¹

A practical test you can use internally: For each external digital service, can a reasonable user find the privacy policy within the same experience, and does the policy accurately describe what data is collected, why, and with whom it is shared? ¹

Who it applies to (entity and operational context)

Entity types commonly scoped

• Federal information systems and agencies implementing NIST SP 800-53 controls. ³
• Contractor systems handling federal data (for example, where NIST SP 800-53 is flowed down through contracts, ATO requirements, or program security requirements). ³

Operational context triggers

You should scope PM-20(1) in if you have any of the following:

• External-facing websites (marketing sites, support sites, authenticated portals). ¹
• Mobile applications (iOS/Android) that collect telemetry, identifiers, contact details, payment data, or any personal data. ¹
• “Other digital services” such as SaaS platforms, web apps, hosted forms/surveys, identity and access experiences, chatbot interfaces, or developer portals. ¹

What you actually need to do (step-by-step)

Step 1: Build a complete inventory of external digital services

Create a list of every public-facing digital surface, including:

• Domains/subdomains, microsites, and campaign landing pages
• Mobile apps and region-specific app store listings
• Authenticated portals and public-facing app entry points (login screens, sign-up pages)
• Hosted third-party experiences you operate (embedded forms, scheduling tools, chat widgets)

Owner: GRC or Privacy, with input from Product/Engineering and Marketing.
Output: “External Digital Services Register” with service name, owner, environment, URLs, and user entry points. ¹

Step 2: Map data practices for each service (minimum viable)

For each service, document:

• Data elements collected (categories are fine if you lack field-level mapping)
• Sources (user input, device data, cookies/SDKs, third parties)
• Purposes (account creation, fraud, analytics, customer support)
• Sharing/recipients (processors, analytics providers, hosting, support tools)
• Retention approach (where defined elsewhere, reference it)
• Contact method for privacy questions

Keep this mapping tied to the service, not only to the enterprise. Assessors often see a gap where an enterprise policy exists but the app’s embedded SDKs create additional collection not reflected anywhere. ¹

Step 3: Draft or update the privacy policy content and align it to the mapping

Set up a policy template with required sections your teams can maintain. Common sections include:

• What data you collect (by category)
• How you use data (by purpose)
• Sharing and third parties (categories of recipients)
• Cookies/trackers and similar technologies (where applicable)
• User choices and rights request mechanism (if your broader privacy program supports it)
• Security statement (high level; avoid unverifiable claims)
• Effective date and change notice mechanism
• Contact details

Control intent: “Develop” a policy that matches real practices. ¹

Step 4: “Post” the policy in every required location (define a posting standard)

Create a posting standard with acceptance criteria you can test. Examples:

• Websites: link in global footer and on any page that collects data (signup, checkout, contact forms).
• Mobile apps: link in the app’s settings/about menu and in the app store privacy link field where available, plus a link at account creation/login screens if those are primary entry points.
• Authenticated portals: link on login page and inside the authenticated UI (e.g., profile/help menu).
• Other digital services: if you run a standalone experience (chat, forms), include a “Privacy” link adjacent to the submission action or in the widget menu.

Then test like an auditor: open the experience as a new user and confirm the link exists, works, and points to the correct policy version. ¹

Step 5: Put governance around change (release-driven review)

You need a reliable trigger to revisit posting and content:

• New tracking technology (cookies, SDKs, pixels)
• New user data fields or onboarding flows
• New third party processors
• New regions/user populations
• Material changes to purposes (e.g., adding targeted advertising)

Embed a privacy-policy impact check into your SDLC change management or release checklist. Make “privacy policy update required: yes/no” a required field in the release ticket when data practices change. ¹

Step 6: Assign ownership and build recurring evidence

Document a control owner (often Privacy with GRC oversight) and operational owners per digital service (Product or Engineering). Then define recurring evidence collection so you can show it is consistently “posted” across your footprint. ¹

If you use Daydream to manage control-to-evidence mapping, set PM-20(1) to automatically request artifacts from each service owner on a schedule tied to release cycles and web updates, not only annual policy reviews. That keeps evidence current without chasing screenshots during an audit. ¹

Required evidence and artifacts to retain

Use an evidence pack that proves development, posting, and maintenance:

Core artifacts

• Approved privacy policy document (versioned) with effective date.
• Change log or redlines showing what changed and why.
• External Digital Services Register (system/app inventory with owners).
• Data-practices mapping per service (can be a matrix).

Posting evidence (the part teams forget)

• Screenshots of privacy policy links in each website footer and key collection pages.
• Screenshots of in-app privacy link placement (settings menu, signup/login).
• URLs showing public access, plus timestamped captures (for example, from your ticketing system or release artifact repository).
• App store listing screenshots showing the privacy policy link field populated (if applicable).

Governance evidence

• SDLC/release checklist item for privacy-policy impact assessment.
• Tickets/approvals for policy updates and posting changes.
• Owner assignment (RACI) for policy content and posting implementation. ¹

Common exam/audit questions and hangups

Assessors commonly probe:

• “Show me every external-facing service and where the privacy policy is posted.”
• “How do you ensure the policy stays accurate when product teams add SDKs or new data fields?”
• “Is the policy accessible before data collection (e.g., before form submit / during signup)?”
• “Who approves changes and how are they communicated?” ¹

Hangups to expect:

• Marketing microsites not covered by the corporate footer template.
• Mobile apps that link to a generic corporate policy that does not match in-app telemetry/SDKs.
• Third-party hosted forms where the only “policy” link is buried on a separate corporate page. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
One enterprise policy, no service-level validation	Policy drifts from reality across apps/sites	Maintain a per-service data-practices mapping and reconcile it to policy at release time. 1
Policy exists but isn’t “posted” in-product	Users can’t find it in the actual experience	Define posting standards and test each entry point (signup, login, form submit). 1
No evidence of what was live	Auditors need point-in-time proof	Store timestamped screenshots/URLs per release and keep a versioned archive. 1
App updates add trackers without policy review	Creates accuracy gap	Add a mandatory privacy-impact check in change management for SDK/cookie additions. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat this section as assessment and operational risk rather than enforcement prediction. ¹

Risk you are managing:

• Assessment risk: inability to demonstrate PM-20(1) implementation because posting is inconsistent and evidence is missing. ¹
• Trust and incident risk: if a security or privacy incident occurs, inaccurate or missing posted policies can intensify stakeholder scrutiny because your public statements do not match practice. ¹

Practical 30/60/90-day execution plan

Use a phased plan that matches how privacy policy work actually moves through Product, Legal, and Engineering.

First 30 days (Immediate stabilization)

• Name the PM-20(1) control owner and service owners; publish a RACI. ¹
• Build the External Digital Services Register and identify gaps (no policy link, broken link, wrong policy).
• Capture baseline evidence (screenshots and URLs) of current posting state for every service.

Next 60 days (Operationalize accuracy + posting consistency)

• Complete minimum viable data-practices mapping per service (include trackers/SDKs).
• Update privacy policy content to match mapped practices; route approvals.
• Implement posting standard across websites, apps, and hosted experiences; add link placement to UI acceptance criteria.

By 90 days (Make it durable)

• Embed privacy policy impact checks into SDLC change management and marketing launch checklists.
• Automate recurring evidence requests and storage ¹.
• Run an internal “mystery shopper” test across services: can a new user find the policy quickly and does it match observed collection points? ¹

Frequently Asked Questions

Does one corporate privacy policy satisfy PM-20(1) for all products?

It can, but only if it accurately covers the data practices of each external-facing website, mobile app, and digital service and is posted where users interact with those services. If practices differ, add product-specific disclosures or separate policies. ¹

What counts as “posted” for a mobile application?

A practical standard is: users can access the privacy policy from within the app (settings/about or onboarding) and from the app store listing where supported. Retain screenshots showing both placements. ¹

Do we need a privacy policy link on every web page?

Put it in a global footer and ensure it is present on pages where users submit personal data (contact forms, signup, checkout) and on login pages for portals. The goal is accessibility in context, not a single hidden link. ¹

How do we handle third-party tools like embedded forms or chat widgets?

Treat them as “other digital services” if they are external-facing and collect personal data on your behalf. Add a visible privacy link in or adjacent to the widget/flow, and document the third party as a recipient/processor in your data-practices mapping. ¹

What evidence will an auditor accept to prove the policy was live?

Keep versioned policy documents plus point-in-time posting evidence: screenshots, URLs, and change tickets tied to releases or web deployments. Evidence should show location (where the link appears) and destination (the correct policy). ¹

Who should own PM-20(1): Legal, Privacy, Product, or GRC?

Assign Privacy or Legal as the content owner, and Product/Engineering as posting implementers for each service, with GRC tracking evidence and control operation. Clear ownership prevents gaps across marketing sites and apps. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5