Determining information for PII principals

To meet ISO/IEC 27701 Clause 7.3.2, you must decide and document exactly what privacy information you will provide to PII principals (data subjects) about how you process their PII, and when you will provide it. Operationally, this means maintaining a documented “notice content standard” mapped to your processing activities, plus procedures that trigger the right notice at the right time. ¹

Key takeaways:

• You need a documented set of required notice elements (content) and a documented “timing model” for when each notice is delivered. ¹
• The work is mainly operational: connect your RoPA/data map to customer-facing notices, just-in-time disclosures, and intake scripts. ¹
• Auditors will look for consistency between documented processing reality and what you tell PII principals, plus evidence that your timing triggers actually fire. ¹

“Determining information for PII principals” is a deceptively simple requirement: write down what you tell people about your processing of their personal data, and when you tell them. In practice, teams fail this control because the “truth” about processing lives in engineering tickets, vendor contracts, and product analytics setups, while the notices live in legal templates and website footers. ISO/IEC 27701 Clause 7.3.2 forces you to close that gap with a documented, repeatable approach. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a spec: define mandatory notice fields, define timing rules (collection, change, new purpose, new recipient class), define owners and approvals, and implement triggers in your operational workflows (product releases, procurement onboarding, DPIAs, and marketing launches). This page gives you requirement-level implementation guidance, evidence expectations, and an execution plan you can run without turning it into a long policy project. ¹

Regulatory text

Requirement (excerpt): “The organization shall determine and document the information to be provided to PII principals regarding the processing of their PII and the timing of such notification.” ¹

Operator interpretation (plain English)

You must:

1. Decide what privacy information your organization will provide to individuals whose PII you process (PII principals). ¹
2. Document that decision in a controlled format (policy/standard + supporting procedures). ¹
3. Decide and document when you provide that information (timing). ¹

The “information” should cover, at minimum, what you process and why, the legal basis, who receives it, how long you keep it, and what rights the individual has. ¹

Who it applies to

Entity scope

This requirement applies to PII controllers. ¹

Operational contexts where it shows up

• Customer/user onboarding and sign-up flows (first collection and first notice).
• HR and candidate processing (employee and applicant notices).
• B2B contacts (sales/marketing outreach, event leads, prospect enrichment).
• Product telemetry and analytics (collection that may be non-obvious to users).
• Third-party sharing (processors, sub-processors, affiliates, and other recipient categories).
  All of these contexts require consistent, documented notice content and timing rules tied to the real processing activity. ¹

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

Step 1: Establish your “PII principal notice content standard”

Create a controlled document (a standard, not a long policy) that lists the required notice elements your organization will provide to PII principals for each processing context. Include, at minimum:

• Categories of PII processed
• Purposes of processing
• Legal basis (where applicable in your compliance design)
• Recipient categories (including relevant third parties)
• Retention period (or the logic used to determine it)
• PII principal rights and how to exercise them
• Contact point for privacy inquiries
  This aligns to the clause summary expectation for content scope. ¹

Practical tip: Write the standard in “fields” so it can drive templates (web notice, in-app notice, call-center script, HR notice). Auditors like structured requirements because they can test completeness. ¹

Step 2: Define and document the “timing model” (notification triggers)

Document when notice is provided. Your timing model should cover:

• At collection (or before collection, depending on channel design)
• When purposes change
• When recipient categories change (new sharing patterns, new processor type, new disclosure pathway)
• When retention logic materially changes
• When rights or contact channels change
  Your clause obligation includes timing, so write timing triggers as operational rules with owners and workflow hooks. ¹

Make timing testable: Each trigger should have (a) who detects it, (b) how it gets approved, (c) where it gets published, and (d) what evidence is saved. ¹

Step 3: Map notice content to your processing inventory (RoPA/data map)

Take your processing inventory and map each activity to:

• The notice template(s) it impacts
• The exact fields it populates (purpose, recipient categories, retention logic, rights)
• The channel where notice is delivered (web, app, email, paper, phone script)
  This is where most programs break: the notice is written once, while processing changes continuously. The mapping makes change control possible. ¹

Step 4: Put change control around notices (like any other compliance artifact)

Implement:

• Version control for notices and scripts
• Defined approvers (privacy, legal, product, security as needed)
• A release gate: product/procurement changes that affect PII cannot ship or go live without a notice impact review
• A documentation rule: every notice update links back to the underlying processing change (new purpose, new recipient category, new retention logic)
  This operationalizes the “determine and document” requirement into a living system. ¹

Step 5: Operationalize delivery (prove it happens)

Define evidence-generating mechanisms per channel:

• Web/app: publish log + screenshot/PDF capture of the effective notice version
• In-app “just-in-time” notices: product requirement + test case + release note
• Call center: approved script + training completion proof + QA sampling results (qualitative)
• HR: onboarding packet version + delivery acknowledgement mechanism (where your HR process supports it)
  The goal is not “we have a notice,” it is “the right people receive the right notice at the right time.” ¹

Step 6: Use tooling to keep the mapping from rotting

Most failures come from drift: new third parties, new analytics events, new retention rules, and no notice update. A system like Daydream helps you maintain a single place to track processing activities, third parties, and the downstream notice fields they affect, then route updates through review and evidence capture so your audit package stays current. ¹

Required evidence and artifacts to retain

Keep artifacts that prove (a) determination, (b) documentation, and (c) timing execution:

• Notice content standard (required fields; templates it governs; ownership; review/approval rules) ¹
• Timing model (trigger events; responsible roles; delivery channels; escalation path) ¹
• Processing-to-notice mapping (matrix linking processing activities to notice fields and templates) ¹
• Current and historical notice versions (with effective dates and approval records) ¹
• Evidence of delivery/publishing (publication logs, screenshots, configuration exports, training records for scripts) ¹
• Change tickets showing notice review as part of product/procurement change control ¹

Common exam/audit questions and hangups

Auditors tend to probe these points:

• “Show me where you documented what information is provided to PII principals.” ¹
• “How do you ensure your notice reflects actual processing activities today?” Expect sampling against your processing inventory and third-party list. ²
• “What triggers a notice update, and who approves it?” ¹
• “How do you handle non-obvious collection?” Common hangup: telemetry/analytics not covered in plain language. ¹
• “Prove timing.” They may ask for examples of a change event and the associated notice update and publication evidence. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating the privacy notice as a static legal page. Fix: manage it like a controlled compliance artifact with change triggers and approvals. ¹
2. No mapping between processing inventory and notice content. Fix: maintain a matrix linking each processing activity to the exact notice fields it affects. ¹
3. Vague recipient language that doesn’t match third-party reality. Fix: define recipient categories and keep them aligned to your third-party register and sharing paths. ¹
4. Retention hand-waving. Fix: document retention periods or the retention determination logic, then ensure the notice reflects that logic in readable form. ¹
5. Timing triggers exist on paper only. Fix: embed triggers in workflows (procurement onboarding, product release checklists, DPIA/PIA intake) and retain ticket evidence. ¹

Enforcement context and risk implications

No public enforcement sources were provided for this requirement, so treat this section as risk-driven implementation guidance rather than case-law recap. The risk is straightforward: if PII principals are not told accurate, complete information in a timely way, you create exposure across privacy complaints, regulator inquiries, contract breaches (customer DPAs), and failed audits against ISO/IEC 27701. The operational risk is drift between what engineering/procurement changes and what the notice says. ¹

Practical execution plan (30/60/90-day)

First 30 days: Set the spec and owners

• Draft and approve the notice content standard (required fields, templates, owners). ¹
• Draft and approve the timing model with clear triggers and workflow hooks. ¹
• Identify primary notice channels and assign operational owners (web, app, HR, support). ¹

By 60 days: Build the mapping and the change gates

• Build the processing-to-notice mapping for high-impact processing and major third-party sharing. ¹
• Implement notice impact review in product and procurement intake so changes trigger review before go-live. ¹
• Establish version control and an evidence capture routine for publication/delivery. ¹

By 90 days: Prove it works and close gaps

• Run an internal test: pick recent processing changes and show the notice timing and content updates end-to-end with evidence. ¹
• Update notices where gaps exist (common gaps: analytics, new third parties, retention clarity). ¹
• Move to steady-state: periodic review cadence tied to processing inventory updates and third-party onboarding. ¹

Frequently Asked Questions

Do we need a separate notice for every product feature or processing activity?

No, but you do need a documented method to ensure every processing activity is covered by notice content somewhere, and that timing is defined for when notice is provided. A mapping matrix is the fastest way to prove coverage and prevent drift. ¹

What does “determine and document” mean in audit terms?

Auditors typically expect a controlled document (standard/procedure) that lists required notice elements and timing triggers, plus evidence that your notices and scripts implement that standard. They will also test that your notice reflects actual processing. ¹

How do we handle just-in-time notices for non-obvious data collection like analytics?

Treat analytics/telemetry as a processing context with its own notice fields and timing trigger, then route tracking plan changes through notice impact review. Keep evidence of the tracking configuration and the notice version that covers it. ¹

Do third-party processors need to be named, or can we describe categories?

ISO/IEC 27701 Clause 7.3.2 requires you to determine the information provided, including recipients, and document it. If you use categories, make them precise and keep them aligned to your third-party register so the notice stays accurate as third parties change. ¹

Who should own the timing triggers, Legal or Product?

Make Legal/Privacy accountable for the standard and approvals, and make Product/Engineering and Procurement responsible for triggering reviews when processing changes. The control fails when accountability and operational triggers sit in the same team’s inbox without workflow hooks. ¹

What is the minimum evidence to show the notice was provided “on time”?

Keep a traceable chain: the triggering change (ticket or intake), the approval record, the published notice version, and objective publication or delivery evidence for the relevant channel. That package demonstrates both timing design and execution. ¹

Footnotes

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

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