Providing information to PII principals

To meet the “providing information to PII principals” requirement, you must publish a clear, easy-to-find privacy notice that identifies who the PII controller is and explains your PII processing activities in plain language. Operationalize it by inventorying processing, mapping it to notice content, publishing it at every collection point, and keeping versioned evidence. ¹

Key takeaways:

• Your notice must clearly identify the PII controller and describe processing activities. ¹
• “Easily accessible” means available where PII is collected and simple to locate later (web, app, onboarding, offline scripts).
• Evidence matters: keep versions, publication points, approval records, and a traceable link to your processing inventory.

ISO/IEC 27701 Clause 7.3.3 is a notice-and-transparency control aimed at a simple outcome: a person whose PII you process should not have to guess who you are (as controller) or what you do with their data. If your privacy notice is generic, hard to find, inconsistent across products, or disconnected from actual processing, this is where auditors and customers will press.

For a CCO, Compliance Officer, or GRC lead, the fastest path is to treat this as a production system, not a one-time legal document. You need (1) a reliable source of truth for processing activities, (2) a controlled method to convert that truth into customer-facing language, and (3) deployment discipline so the notice is present at each PII collection point and remains accessible over time.

This page translates the requirement into an implementable checklist with artifacts to retain, audit questions to anticipate, and a practical execution plan. The focus is requirement-level: what must be true for you to credibly claim conformance, and how to run the control so it stays true as products, third parties, and data uses change. ¹

Regulatory text

Requirement (verbatim): “The organization shall provide clear and easily accessible information to PII principals identifying the PII controller and its processing activities.” ¹

Operator interpretation (what you must make true):

• Clear information: Written for the intended audience, in plain language, without hiding key facts in dense text.
• Easily accessible: A PII principal can find it at the moment you collect PII (or before) and later without friction.
• Identifying the controller: The notice unambiguously states the controller’s identity (legal entity) and how to contact it for privacy matters.
• Processing activities: The notice describes what PII you collect and how you process it, in a way that matches real operations. ¹

Plain-English interpretation of the requirement

If you decide the purposes and means of processing, you owe people a readable explanation of:

1. who you are (the controller), and
2. what you do with their PII (processing activities),
   delivered in a place and format they can actually access.

In practice, the control fails less often because a notice is missing, and more often because the notice is not connected to the processing reality: new analytics tools, new data sharing, new uses for fraud prevention, or a new third party gets added and the notice never changes.

Who it applies to (entity and operational context)

Applies to: PII controllers. ¹

Operational contexts where this becomes concrete:

• Web and mobile collection: sign-up flows, checkout pages, demo requests, newsletter forms, SDK-based collection.
• Employee and applicant data: recruiting portals, onboarding, background checks.
• B2B product telemetry: product analytics, monitoring, crash reporting tied to an identifiable user.
• Offline collection: call centers, in-person events, paper forms, recorded calls.
• Third-party collection on your behalf: affiliates, resellers, outsourced support, managed service providers collecting PII for your purposes.

If you have multiple brands or legal entities, the controller identification piece becomes a governance problem: the notice must match the entity actually acting as controller for each product/service.

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

Step 1: Define ownership and an approval path

• Assign a single accountable owner for the notice (often Privacy, Legal, or Compliance).
• Set a lightweight review/approval workflow that includes Product and Security input so the notice reflects reality.
• Decide where the “system of record” lives (document repository with versioning and approvals).

Operational tip: Treat this like a controlled policy document with release management, not a marketing webpage.

Step 2: Build a “processing-to-notice” mapping

You need a traceable link between processing activities and the public explanation.

Create (or reuse) a processing inventory and map each entry to notice language:

• Processing purpose (why)
• Data elements / categories (what)
• Data sources (where from)
• Recipients / third parties (who it goes to, at a category level)
• Retention logic (high-level, if you state it)
• User-facing touchpoints (where to show the notice)

You do not need to publish internal technical diagrams, but you do need the notice to be consistent with the inventory. ¹

Step 3: Draft notice content that meets the clause

Minimum content to satisfy the explicit text of 7.3.3:

• Controller identification: legal entity name(s). If more than one, clearly state which entity controls which service.
• Processing activities overview: a clear explanation of key processing activities tied to your services.

Common practice structure (keep it readable):

• Who we are (controller identity + contact)
• What information we process (high-level categories)
• How and why we process it (purposes by category)
• How to reach us for privacy questions (email/address or form)

Step 4: Make it “clear” in practice (readability and UX)

Clarity is measurable in operational terms:

• Use short headings that match user intent (“What we collect,” “Why we use it,” “Who we share it with”).
• Avoid burying controller identity only in footers or terms pages.
• Use layered notice design: summary bullets up top with deeper detail below (still one page if possible).

Step 5: Make it “easily accessible” at every collection point

Build a distribution checklist and confirm coverage:

• Web forms: link next to the submit button (not just in the footer).
• Mobile apps: link in onboarding and in settings (persistent access).
• Contracts / order forms (B2B): reference the notice and ensure the right legal entity is named.
• Call scripts: short spoken notice plus a way to access the full notice (URL or email).
• Offline forms: printed short notice plus a URL/QR code for the full notice.

If you operate multiple products, maintain a “notice routing table” that maps product → correct notice version/entity.

Step 6: Operationalize change management

Most breakdowns happen after launch. Add triggers:

• New product features that introduce new data categories or purposes
• New third party that receives PII for your purposes
• Material changes in how you identify the controller (reorg, acquisition, new entity)

Tie these triggers to your SDLC, procurement/third-party intake, and privacy review gates. Daydream can help by turning third-party onboarding and system changes into trackable notice update tasks, with evidence capture and reminders embedded in the workflow.

Required evidence and artifacts to retain

Auditors will ask two questions: “Show me the notice,” and “Prove it matches reality and is accessible.”

Retain:

• Current privacy notice (public copy) and historical versions with effective dates.
• Approval records (ticket, email, or GRC workflow showing Privacy/Legal sign-off).
• Processing inventory extract showing the activities described in the notice and the mapping from inventory items to notice sections.
• Publication evidence:
  • Screenshots of web/app placement at each collection point
  • App store release notes or internal release artifacts showing when notice updates shipped
  • Call center scripts and training acknowledgments (if applicable)
• Change logs documenting why/when updates were made (feature launch, third-party change).

Common exam/audit questions and hangups

Expect these:

• “Who is the controller for Product A versus Product B? Show me where the notice states this.”
• “Where is the notice presented at data collection? Walk through the user flow.”
• “How do you ensure the notice stays accurate after a feature release?”
• “Show examples where a third party was added. Was the notice evaluated/updated?”
• “Do you have multiple notices? How do you prevent the wrong one from being linked?”

Hangups that slow audits:

• No version history (only the current webpage).
• Notice maintained by Marketing with no compliance approvals.
• Processing inventory exists but isn’t referenced in notice maintenance.

Frequent implementation mistakes and how to avoid them

1. Mistake: Generic controller identification.
   Fix: Name the legal entity and provide a clear privacy contact path.

2. Mistake: “Easily accessible” interpreted as “somewhere on the website.”
   Fix: Require placement at each collection point and persistent availability in-account/app.

3. Mistake: Notice content not aligned to real processing.
   Fix: Build the processing-to-notice mapping and make it part of release governance.

4. Mistake: Separate notices across brands without governance.
   Fix: Maintain a notice inventory and a routing table with owners and effective dates.

5. Mistake: Third-party changes bypass privacy updates.
   Fix: Add a checkpoint in third-party onboarding so any new PII sharing triggers notice review.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so you should treat enforcement risk here as a general transparency and trust risk rather than tying it to a specific regulator action in this page.

Practically, weak notice controls increase:

• Customer due diligence friction (enterprise buyers will test transparency maturity).
• Audit findings in ISO-aligned assessments, since the clause is explicit about controller identification and processing activities. ¹
• Incident response complexity, because you cannot easily explain “what we told people” at the time data was collected without versioned evidence.

A practical 30/60/90-day execution plan

First 30 days (stabilize and publish)

• Confirm controller legal entity/ies per product and who owns the notice.
• Inventory all PII collection points (web, app, offline, third parties).
• Publish or refresh the notice so it clearly identifies the controller and describes processing activities at a service level. ¹
• Add notice links at the highest-risk collection points (sign-up, checkout, account creation).
• Start versioning: capture the published page and store it with an effective date.

Days 31–60 (connect notice to operations)

• Build the processing-to-notice mapping from your processing inventory to notice sections.
• Implement an approval workflow (ticketing or GRC tool) for any notice change.
• Add SDLC and third-party onboarding triggers for notice review.
• Create an evidence pack template (screenshots list, approvals, mapping).

Days 61–90 (make it durable)

• Expand coverage to remaining collection points (events, call scripts, partner flows).
• Test accessibility: have someone outside Privacy find the notice from each collection point.
• Run a tabletop change: simulate a new analytics tool addition and prove the workflow updates the mapping, notice, and evidence.
• If you manage these workflows in Daydream, standardize intake forms and auto-generate an audit-ready record with approvals, version history, and publication screenshots attached.

Frequently Asked Questions

Do we need a separate privacy notice for every product?

Not necessarily. You need clarity on the controller identity and processing activities for the service in scope. If one notice becomes confusing or mixes different controllers, split it or add clear service-specific sections.

What counts as “easily accessible” for mobile apps?

Put the notice in onboarding (or before account creation) and keep it available later in settings or a help/privacy menu. A footer link on a marketing site is not enough for in-app collection.

We collect PII through a third party (reseller/partner). Who must provide the notice?

As the controller, you remain responsible for providing clear, accessible information to PII principals about your processing. Operationally, require partners to present your notice (or an approved short notice that links to it) at the point of collection.

How do we prove what notice a user saw last year?

Keep versioned copies with effective dates and publication evidence (screenshots, release artifacts). Store them in a controlled repository and link versions to change approvals.

Can Marketing own the privacy notice page?

Marketing can publish and format it, but Compliance/Privacy should own content approval and version control. Auditors will look for a controlled process and evidence that the notice reflects actual processing.

What’s the minimum content we must include to satisfy ISO/IEC 27701 Clause 7.3.3?

The notice must identify the PII controller and its processing activities, and it must be clear and easy to access. ¹

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management