Privacy Notice

To meet the privacy notice requirement, you must give individuals a clear, accurate notice that explains what personal information you collect, why you use it, how long you keep it, and what rights they have over it. Operationalize this by tying the notice to your actual data inventory, retention schedule, and request-handling workflows, then publishing and maintaining it as a controlled compliance artifact. ¹

Key takeaways:

• Your privacy notice must match reality: data collected, purposes, retention, and rights must trace to documented processes. ¹
• The fastest path is a crosswalk: data inventory → purposes → retention schedule → rights workflow → notice text. ¹
• Treat the notice as a controlled document: versioning, approvals, change triggers, and evidence for audits. ¹

A “privacy notice requirement” becomes audit friction when the notice is treated as a marketing webpage instead of an operational control. HITRUST CSF v11 Control 13.a expects a notice that is both clear to individuals and accurate to your practices, including four specific content areas: collection, purpose, retention, and rights. ¹

For a Compliance Officer, CCO, or GRC lead, the practical question is not “do we have a privacy policy?” It’s: can you prove the notice is complete, is delivered to the right people at the right time, and stays aligned with what systems actually do. The work is mostly integration and governance: you need a reliable source of truth for what data you handle, a defensible retention model, and a repeatable process for privacy rights requests. Then you translate that into customer-facing language with approvals and version control.

This page gives requirement-level implementation guidance you can execute quickly, including steps, artifacts to retain, and the questions auditors tend to ask.

Regulatory text

Requirement (HITRUST CSF v11 13.a): Organizations must provide individuals a “clear and accurate notice” of privacy practices. The notice must describe: (1) what information is collected, (2) the purposes for which it is used, (3) how long it is retained, and (4) the rights individuals have regarding their information. ¹

Operator interpretation:
You need a published, accessible privacy notice that is understandable to a typical user and demonstrably consistent with your internal records and operations. “Clear” is a drafting and delivery obligation. “Accurate” is an operational truth obligation: what the notice says must trace to your systems, processes, and retention rules. ¹

Plain-English interpretation of the requirement

A compliant privacy notice answers four questions for an individual:

1. What do you collect about me? Categories and common sources of personal information (and, where relevant, sensitive categories).
2. Why do you collect and use it? Concrete purposes, not vague statements.
3. How long do you keep it? Retention periods or retention criteria that map to your schedule.
4. What can I do about it? Rights and how to exercise them through your intake and verification process. ¹

If you cannot confidently answer those questions using your internal documentation, the privacy notice will be hard to defend in an assessment.

Who it applies to (entity and operational context)

Applies to: All organizations implementing HITRUST CSF controls. ¹

Operational contexts where it commonly becomes “real”:

• Customer-facing web and mobile products collecting account, usage, device, or support data.
• Healthcare-adjacent workflows handling identifiers, clinical/claims-adjacent data, or patient engagement records.
• B2B services that still collect personal data (admin users, end users, prospects, employees, contractors).
• Third-party sharing: analytics, customer support platforms, payment processors, hosting providers, subcontractors.

If any part of your service touches personal information, you need a notice that reflects those flows.

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

Step 1: Build a “privacy notice source of truth” pack

Create (or refresh) the minimum internal inputs your notice must reflect:

• Data inventory / records of processing: data categories, data subjects, sources, systems, and disclosures.
• Purpose map: each category mapped to one or more purposes (e.g., account provisioning, security monitoring, customer support).
• Retention schedule: retention periods or criteria by category/system.
• Rights workflow: intake channels, identity verification, fulfillment steps, and exceptions/escalations. ¹

Practical tip: if your data inventory is incomplete, start with the systems that touch user onboarding, authentication, payments, support, analytics, and marketing automation. Those drive most notice content.

Step 2: Draft notice content that mirrors operations (not aspirations)

Draft the notice in sections that directly satisfy the requirement:

• Information we collect: categories, examples, and collection methods (direct, automated, third parties).
• How we use information: purposes tied to your purpose map.
• How long we retain it: either specific periods by category or a criteria-based model that references your retention schedule.
• Your rights and choices: list rights you support and how to submit requests.
• Disclosures/sharing: who you share with (types of third parties) and why, aligned to your inventory and contracts.
• Contact and updates: how to reach privacy, how material changes are communicated. ¹

Keep language customer-facing. Avoid internal system names. Use category-based descriptions that can stay stable even as tools change.

Step 3: Add delivery mechanics (the “notice” part)

A notice has to be provided, not just drafted. Implement:

• Publication: a stable URL for public notices; in-product links for authenticated users.
• Point-of-collection references: links at sign-up, form collection points, and employee/contractor onboarding portals where personal information is collected.
• Version visibility: “Effective date” and a way to access prior versions for dispute handling. ¹

Step 4: Put governance around change

Define change triggers and owners:

• Owners: privacy/compliance for content, security for monitoring/security-use statements, legal for review, product for collection changes.
• Change triggers: new data category, new purpose, new third party sharing pattern, new retention rule, new user rights process.
• Workflow: ticket-based review, approvals, and publish steps; update the source-of-truth pack first, then the notice. ¹

This is where many teams fail: product ships a new telemetry event, and the notice never changes.

Step 5: Prove it works with a traceable crosswalk

Create a “privacy notice crosswalk” table that maps every promise in the notice to an internal artifact:

• “We collect X” → system/data inventory entries
• “We use X for Y” → purpose map
• “We retain X for Z” → retention schedule
• “You may request A/B/C” → rights workflow + intake evidence ¹

If you use Daydream for GRC work, this crosswalk is a strong candidate for automation: keep the inventory, retention, and notice text linked so changes in data handling trigger an update task rather than a missed obligation.

Required evidence and artifacts to retain

Auditors typically want proof of both content and process. Retain:

• Current privacy notice and prior versions (with effective dates).
• Approval records (privacy/compliance/legal) and change log.
• Data inventory/records of processing used to draft the notice.
• Purpose map and retention schedule referenced by the notice.
• Rights request procedures (SOP), intake channels, and training/desk guides.
• Evidence of publication and point-of-collection links (screenshots or release artifacts).
• Third-party disclosure list categories and contract clauses that support your statements about sharing and processing. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me where the notice explains retention. Is it specific or criteria-based, and where is the retention schedule approved?”
• “How do you know this notice is accurate? Walk me from a data category in the notice to the system that collects it.”
• “What changed since the last version? Who approved it?”
• “How do individuals exercise rights, and how do you ensure requests reach the right team?”
• “Where do you provide notice at the point of collection (web forms, in-app, support intake)?” ¹

Hangups usually arise when the notice says “we may collect” without specifying categories, or when retention is omitted or hand-waved.

Frequent implementation mistakes and how to avoid them

Mistake 1: Notice text that isn’t tied to a data inventory.
Fix: require a crosswalk entry for every collection statement, and treat unmapped text as a defect. ¹

Mistake 2: Retention described as “we retain as long as necessary” with no backing rules.
Fix: publish retention periods or defensible criteria, and maintain an internal schedule that matches. ¹

Mistake 3: Rights listed but no operational workflow.
Fix: document intake, verification, routing, response templates, and escalation. Align staff training and tooling. ¹

Mistake 4: Third-party sharing buried or outdated.
Fix: maintain a living list of third-party categories and purposes, and connect it to procurement onboarding so new third parties trigger a notice review. ¹

Mistake 5: No “point of collection” linkage.
Fix: add privacy notice links to every collection surface (product, marketing forms, support portals) and validate during release QA. ¹

Enforcement context and risk implications

No public enforcement sources were provided for this requirement in the supplied materials, so this page does not cite specific cases.

From an operational risk standpoint, the exposure is straightforward:

• An inaccurate notice creates misrepresentation risk and undermines your ability to defend how and why you process data.
• A missing retention description often correlates with weak retention controls, which increases breach exposure and discovery risk.
• Rights promises without fulfillment capability create complaint escalation risk and audit findings because you cannot show execution against stated rights. ¹

Practical execution plan (30/60/90)

Timelines below are phases, not guaranteed durations; scale depends on system sprawl and ownership clarity.

First 30 days (Immediate)

• Assign an owner for notice content and an owner for the data inventory inputs.
• Inventory the top systems that collect personal information and document data categories, purposes, sharing, and retention.
• Draft or revise the privacy notice to explicitly cover collection, purposes, retention, and rights.
• Publish the notice and add links at primary collection points (sign-up, key forms, in-app settings/help). ¹

By 60 days (Near-term stabilization)

• Build the privacy notice crosswalk that maps notice claims to inventory, retention schedule, and SOPs.
• Formalize the rights request SOP and route requests through a ticketing system with defined owners.
• Add a change-management trigger: any new data category/system integration requires privacy review before release. ¹

By 90 days (Operational maturity)

• Expand inventory coverage to lower-visibility collection points (support tooling, logs, HR/contractor systems if in scope).
• Implement recurring reviews tied to product releases and third-party onboarding.
• Run an internal test: submit a rights request end-to-end and confirm the notice accurately describes the process, timing expectations (if stated), and outcomes. ¹

Frequently Asked Questions

Do we need separate privacy notices for different products or regions?

If practices differ materially (data collected, purposes, retention, rights), separate notices or clearly separated sections reduce accuracy risk. If you use a single notice, keep a product/region appendix that maps differences to specific offerings. ¹

How specific does “how long it is retained” need to be?

The notice must meaningfully describe retention, either through specific periods by category or clear criteria that tie to your retention schedule. Whatever approach you choose, it must match your approved internal retention rules. ¹

Our systems retain logs for security. Do we have to disclose that?

If logs contain personal information (directly or indirectly), the notice should describe that category, the security purpose, and the retention approach. Your security logging and retention settings should support what you publish. ¹

What counts as “rights individuals have” if we operate globally?

Don’t overpromise. List the rights you actually operationalize for your user base and clearly state how to submit requests and what verification you require. Align the notice to your request-handling SOP. ¹

Can marketing write the notice if Compliance reviews it?

Marketing can draft for readability, but Compliance/Privacy must own accuracy and traceability to internal artifacts. Treat the notice like a controlled compliance document with approvals and a change log. ¹

What evidence is most persuasive to an assessor?

A crosswalk that ties each notice statement to your data inventory, purpose map, retention schedule, and rights SOP is high-value evidence. Pair it with version history and screenshots showing where the notice is presented to individuals. ¹

Footnotes

1. HITRUST CSF v11 Control Reference