Determine when and how consent is to be obtained

Consent is easy to “collect” and hard to defend in an audit. ISO/IEC 27701 clause 7.2.3 focuses on one point: if you’ve chosen consent as the lawful basis for a processing activity, you need a documented way to obtain that consent and you must retain records of it. That sounds simple until you map how PII actually moves across your apps, third parties, marketing tags, support tools, and analytics.

For a CCO or GRC lead, the fastest path is to treat consent like an access control decision: defined conditions, consistent enforcement points, and a reliable log. You’ll want a consent decision matrix (when consent is required), a standardized consent pattern library (how it’s obtained in each channel), and a consent register (what you can prove later). This page gives requirement-level implementation guidance you can hand to Privacy Ops, Product, Marketing Ops, and Engineering with minimal translation, including what to document, what evidence to retain, and what auditors commonly challenge.

Regulatory text

Requirement (excerpt): “Where consent is determined to be the lawful basis for processing, the organization shall determine and document a process by which consent can be obtained from PII principals and shall maintain records of consent.” ¹

Operator meaning: If your privacy assessment says “we rely on consent,” you must (1) define exactly when consent is needed, (2) implement a consistent method to capture it in practice, and (3) keep retrievable records that show what the person agreed to and when.

Plain-English interpretation (what the requirement expects)

This requirement expects you to be able to answer, without improvising:

1. When do we need consent? For each processing purpose, you’ve explicitly chosen consent as the lawful basis. That choice should not be implicit (“marketing always needs consent”) or buried in product code.
2. How do we obtain it? You have a defined, repeatable process by channel (web, mobile, call center, in-product, paper forms) that produces consent that is freely given, specific, informed, and unambiguous, and supports withdrawal.
3. Can we prove it later? You maintain records of consent that are complete enough to support an audit, complaint, or customer dispute, tied to the exact purpose and the notice/wording shown at the time. ¹

ISO 27701 is not asking you to “add a cookie banner.” It is asking you to operationalize consent as a controlled, documented process with evidence.

Who it applies to (entity + operational context)

Applies to: Organizations acting as PII Controllers (you determine purposes and means of processing). ¹

Operational contexts where this becomes real work:

• Marketing and advertising: email/SMS marketing subscriptions, cross-site tracking, lead enrichment, retargeting audiences.
• Product analytics and personalization: telemetry tied to an identifiable user, behavioral profiling, “recommended for you.”
• Sensitive or high-impact uses: any processing you’ve internally decided requires consent due to risk tolerance, even if another basis might exist.
• Third-party disclosures: sharing PII with third parties for their purposes, or adding third-party scripts/SDKs that collect PII.

If different business units capture consent differently, you are exposed. ISO 27701 wants a single coherent process, even if implemented through multiple tools.

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

Step 1: Build a “consent required” decision matrix

Create a register that lists each processing purpose and explicitly states the lawful basis you’ve chosen. For the purposes where the lawful basis is “consent,” record:

• Purpose name (plain language)
• Data categories involved
• Channels where collection occurs (web, app, offline)
• Systems/third parties receiving the data
• What event constitutes consent (checkbox, toggle, signature, verbal script)
• How withdrawal is performed and propagated
  This becomes your operational definition of “when.”

Practical tip: Keep the purpose list tight. Auditors will challenge vague purposes like “improving services.” Use language a person would understand.

Step 2: Define “how consent is obtained” per channel, using standard patterns

Document your consent capture patterns so teams don’t invent them:

• Web/app UI pattern: clear notice + affirmative action; no pre-ticked boxes; separate consent per distinct purpose when needed.
• Email/SMS pattern: subscription capture, confirmation flow if you use it, and how you handle forwarded/shared signups.
• Call center pattern: approved script, how the agent records consent, and where call logs/CRM notes are stored.
• Paper pattern: form version control, scan/retention, and indexing by identity and purpose.

Store these patterns in a controlled document (policy/procedure) and in your product requirements templates so they show up in the SDLC. This is your documented “process by which consent can be obtained.” ¹

Step 3: Implement a consent system of record (and integrate it)

You need one place you can query: “Does this person have valid consent for purpose X right now, and what is the history?”

Minimum functional requirements:

• Identity reference (account ID, email/phone, or another stable identifier)
• Purpose identifier (not just “marketing”)
• Consent status (granted/withdrawn)
• Timestamp(s) for grant/withdrawal
• Capture source (web form name, app screen, call center)
• Consent text or a version reference to the exact notice presented

Engineering then integrates this with:

• Preference centers
• Marketing automation suppression lists
• Tag manager / SDK configuration
• Data sharing pipelines to third parties

Step 4: Operationalize withdrawal and change control

Withdrawal must be as operationally real as collection:

• A user-facing method to withdraw (preference center, unsubscribe, in-app settings).
• Back-end propagation to downstream systems and third parties.
• A defined SLA target internally (write your own target; don’t guess what regulators want) and monitoring for failures.

Treat consent language as a controlled artifact:

• Version the consent copy.
• Record which version was presented.
• If copy changes materially, assess whether re-consent is required for the purpose.

Step 5: Add QA, monitoring, and periodic checks

Build lightweight controls that prevent regressions:

• Pre-release checklist: “New PII purpose? Lawful basis chosen? If consent, capture + record + withdrawal tested?”
• Automated tests for default states (no consent assumed).
• Quarterly sampling of consent records to confirm completeness and match to actual UX flows (screenshots and logs).

If you use Daydream to manage third-party risk and privacy controls, map consent-dependent processing to the third parties involved (ad networks, analytics, messaging providers). That linkage makes it easier to show that withdrawal propagates beyond your own systems during audits.

Required evidence and artifacts to retain

Auditors look for proof that your documented process matches reality. Retain:

• Consent decision matrix / processing register showing which purposes rely on consent.
• Consent procedure describing capture methods by channel.
• UI evidence: screenshots of consent prompts, preference center screens, and notices (with version/date).
• Consent record samples: exported records showing identity, purpose, timestamp, and text/version reference.
• System diagrams/data flows showing where consent signals are enforced (marketing platform, analytics, third parties).
• Withdrawal evidence: test cases or tickets demonstrating withdrawal propagation.
• Change records: approvals for consent copy changes and releases that modify consent flows.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where you decided consent is the lawful basis for this processing purpose.”
• “Demonstrate how a user gives consent in the mobile app and where it is recorded.”
• “What exactly did the user see when they consented?” (They will want the wording or version.)
• “How do you prevent processing when consent is missing or withdrawn?”
• “How do third parties receive consent status, and how do you validate they honor it?”

Hangup: teams can show a banner but cannot produce the underlying record tied to purpose and notice version.

Frequent implementation mistakes (and how to avoid them)

1. Overbroad purposes (“marketing”)
   Fix: Break into distinct purposes that match actual processing and sharing patterns.

2. No linkage between consent and downstream enforcement
   Fix: Treat consent as a control input to systems. If analytics fires before consent is recorded, you have a gap.

3. Record exists, but not what was agreed to
   Fix: Store consent text version or immutable reference, not just “true/false.”

4. Third-party scripts/SDKs collect before consent
   Fix: Implement tag/SDK gating tied to consent state, and test it routinely.

5. Withdrawal handled only in one system
   Fix: Build a propagation map. Tie it to your third-party inventory so you can prove coverage.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so treat ISO 27701’s text as your primary audit driver. The practical risk is evidentiary: if you cannot prove valid consent and its scope, you may need to stop processing, purge data collected under unsupported consent, or renegotiate third-party sharing arrangements.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an owner for consent operations (Privacy Ops or GRC with Product support).
• Draft the consent decision matrix for the highest-risk processing purposes (marketing, tracking, sharing with third parties).
• Inventory current consent capture points and identify mismatches (different wording, missing records, unclear purposes).
• Choose or confirm the consent system of record and required fields.

Days 31–60 (Build and integrate)

• Publish documented consent capture procedures per channel.
• Implement or fix consent recording with purpose-level granularity and consent text versioning.
• Connect consent state to enforcement points: marketing suppression, tag manager/SDK gating, and key third-party disclosures.
• Stand up a withdrawal workflow with clear ownership and operational runbooks.

Days 61–90 (Prove it and keep it correct)

• Run an internal audit: sample real users/records and replay the evidence trail (what they saw, when they agreed, what happened downstream).
• Add release gates in the SDLC for new/changed consent flows.
• Train Marketing Ops, Product, and Support on approved patterns and escalation paths.
• If Daydream is in your stack, link consent-dependent processing to third-party records and assessments so you can show end-to-end control during audits.

Frequently Asked Questions

Do we need consent for every type of PII processing?

No. This requirement triggers “where consent is determined to be the lawful basis for processing.” Your job is to clearly document which purposes rely on consent and ensure those purposes have a working capture-and-record process. ¹

What counts as a “record of consent” in practice?

A defensible record ties a person (or account), a specific purpose, the consent status, timestamps, the capture source, and the consent language or version shown. A simple “opt_in=true” without purpose and notice context is usually hard to defend.

How should we handle consent collected offline (events, paper forms, phone)?

Use a controlled script or form with versioning, then enter consent into the same system of record as online consent. Keep scans, call logs, or CRM entries indexed so you can reproduce evidence for a specific person and purpose.

If we update the consent wording, do we need to re-consent everyone?

ISO 27701 does not prescribe a universal rule. Treat material changes as a trigger for a risk review: if the purpose or scope changed, re-consent may be appropriate; if it’s a clarity edit, version the text and continue.

Can a third party manage consent for us?

A third party can provide tooling, but you still need to document the process and maintain consent records you can produce on demand. Make sure your contracts and integrations let you retrieve records and propagate withdrawals.

How do we audit that consent is actually enforced, not just recorded?

Test from the user experience to the data layer: confirm tags/SDKs do not fire before consent, confirm downstream systems respect withdrawal, and confirm third parties receiving data have the right signals. Keep test evidence and samples as audit artifacts.

Footnotes

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