Obtain and record consent

To meet the “obtain and record consent” requirement, you need a documented consent process that captures valid consent from the PII principal and preserves auditable evidence of what they agreed to, when, and how. Operationally, that means standardizing consent language, implementing a consent-capture mechanism in your systems, and maintaining a consent record that can be produced on demand. ¹

Key takeaways:

• Treat consent as a controlled record: scope, timestamp, method, and versioned notice text must be retrievable.
• Build for audit: you should be able to prove consent for a specific person and processing purpose, not just claim it.
• Make consent lifecycle-ready: withdrawal, refresh, and change management must update downstream processing.

Consent breaks in real operations for predictable reasons: teams can’t prove exactly what a person saw, consent language drifts across products, third parties receive data without a traceable permission trail, and withdrawals don’t propagate. ISO/IEC 27701 clause 7.2.4 is simple on paper and unforgiving in practice: obtain consent according to documented processes, and keep auditable evidence of the consent obtained. ¹

This page is written for a Compliance Officer, CCO, or GRC lead who needs to turn that sentence into a working control. It focuses on the minimum set of decisions, workflow steps, and evidence you need so you can defend consent in an audit without rebuilding your product. You’ll get: a plain-English interpretation, applicability boundaries (where consent is and isn’t your right basis), a step-by-step build/run checklist, the artifacts to retain, and the audit questions that typically expose gaps. Where tooling helps, Daydream is referenced as a practical way to keep consent evidence, process documentation, and control testing in one place, without turning your privacy program into a spreadsheet maze.

Regulatory text

Text (requirement): “The organization shall obtain and record consent from the PII principal in accordance with documented processes, maintaining auditable evidence of the consent obtained.” ¹

What the operator must do:

1. Obtain consent from the individual (PII principal) using a documented process (not ad hoc, not product-team-specific tribal knowledge).
2. Record the consent in a way that is auditable. An auditor should be able to inspect records and confirm what the person agreed to, when they agreed, and how consent was collected. ¹

Plain-English interpretation (what “good” looks like)

You can demonstrate, for a given person and a given processing purpose, that:

• the person took an affirmative consent action (or the consent method you rely on),
• the consent statement/notice they saw is known (versioned and retrievable),
• the time and collection channel are logged (web, mobile, phone, paper, API),
• and the consent record is linked to downstream processing (so you can stop or change processing if consent is withdrawn). ¹

This is not satisfied by a generic policy statement like “users consent in our Terms,” unless your documented process and evidence show the specific consent event and the exact statement presented at that time.

Who it applies to (entity and operational context)

Applies to: PII Controllers (as identified in the applicability metadata). ¹

Operationally, you should treat this as in-scope when:

• You collect personal data directly from individuals (sign-ups, lead forms, support intake, cookie banners, marketing subscriptions).
• You share personal data with third parties based on consent (marketing platforms, analytics tools, data enrichment, communications providers).
• You run product features that require permission (optional profiling, personalized recommendations, optional data collection).
• You rely on consent as the basis for specific processing activities, and need proof for audits, customer assurance, or internal governance. ¹

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

Step 1: Define the consent “objects” you will manage

Create a controlled list of consent items you collect, written as:

• Purpose (what processing occurs),
• Data categories (what PII is involved),
• Processing scope (systems/teams/third parties),
• Consent UX text (the statement shown to the person),
• Validity rules (what counts as consent, what does not),
• Withdrawal method (how a person revokes it). ¹

Practical tip: start with the highest-risk and highest-volume consents (marketing, analytics, optional sensitive features). Keep the list small enough to govern.

Step 2: Document the consent process (so it’s repeatable)

Your documented process should answer:

• Who owns consent language approvals (privacy/legal) vs implementation (product/engineering).
• Where consent is captured (UI surfaces, call center scripts, paper forms, APIs).
• How consent is stored (system of record), and how systems query it.
• How withdrawals/changes are handled and how long updates take operationally.
• How you handle consent for different products/regions (if applicable). ¹

Daydream can store the process narrative, link it to control evidence, and assign process owners so you can show “documented processes” plus operational proof in one audit package.

Step 3: Implement consent capture with versioning

Build or configure a consent capture mechanism that records:

• Identifier for the person (account ID, email hash, customer reference; avoid storing more PII than needed).
• Consent item/purpose ID (from Step 1).
• Status (granted/denied/withdrawn).
• Timestamp and time source.
• Collection method (web form, checkbox, preference center, verbal, paper, API).
• Notice/statement version (the exact text or a version pointer).
• Context (product, locale, IP/device if you use it, without over-collecting). ¹

Versioning is where most teams fail. If you cannot reconstruct what statement the person saw, you weaken “auditable evidence.”

Step 4: Make consent enforceable downstream

Consent is operational only if downstream systems honor it:

• Add a consent check before sending data to third parties tied to that purpose.
• Implement suppression rules for marketing systems.
• Ensure data pipelines and analytics respect “no” or “withdrawn.”
• Create an exception workflow for “break-glass” cases, if you allow them, and log them. ¹

Step 5: Run lifecycle operations (withdrawal, refresh, change control)

Your process must cover:

• Withdrawal intake (preference center, support ticket, unsubscribe, written request).
• Propagation to third parties (stop sharing; request deletion where needed).
• Change control when consent language or purposes change (new version, possible re-consent depending on your rules).
• Periodic internal checks: sample records, verify links to notice versions, confirm suppression is working. ¹

Required evidence and artifacts to retain (audit-ready set)

Keep these artifacts in a place you can export quickly (GRC system, Daydream, or controlled repository):

1. Documented consent procedure (process doc, roles, and flow).
2. Consent inventory (list of consent items/purposes; mapping to systems and third parties).
3. Consent text library with version history (what changed, when, who approved).
4. System design evidence (data model fields, event logs, screenshots of UX, call scripts).
5. Consent records (samples showing identifier, purpose, status, timestamp, method, version pointer).
6. Withdrawal records and proof of propagation (tickets, logs, suppression list updates).
7. Access controls over consent records (who can edit; audit trail for changes). ¹

Common exam/audit questions and hangups

Auditors typically probe:

• “Show me the consent record for this individual and this purpose. What exactly did they consent to?” ¹
• “How do you prove the text shown at the time of consent?”
• “Who can modify a consent record, and how do you detect inappropriate edits?”
• “What happens when a user withdraws consent? Which systems stop processing and how do you confirm?”
• “How do you ensure third parties only receive data for purposes with consent?” ¹

Hangup to expect: teams can demonstrate a checkbox exists, but cannot produce evidence that ties the checkbox event to the purpose and the versioned disclosure.

Frequent implementation mistakes (and how to avoid them)

1. Storing “consented: yes/no” without purpose granularity.
   Fix: model consent as purpose-specific records.

2. No versioned consent text.
   Fix: store a version ID and retain the exact text or immutable reference.

3. Consent captured in one system, processing happens in others.
   Fix: publish consent status as a queryable service or synced dataset used by downstream tools.

4. Withdrawal handled manually with no trace.
   Fix: route withdrawals through a ticketed workflow and retain system logs of suppression.

5. Third-party sharing not mapped to consent.
   Fix: maintain a mapping of consent purposes to outbound data flows and third parties; block transfers where consent is absent. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so this page does not cite specific regulator actions. From an assurance standpoint, weak consent evidence creates two practical risks: you cannot demonstrate compliance during customer audits, and you may be forced into conservative operational decisions (turning off processing you cannot justify) during incidents or complaints. ISO/IEC 27701’s emphasis on “auditable evidence” signals that proof quality matters, not just policy intent. ¹

Practical 30/60/90-day execution plan

Numeric timelines below are presented as phases, not elapsed-day promises.

First phase: establish control design (immediate)

• Name an owner for the consent control and an engineering counterpart.
• Build the consent inventory: purposes, systems, third parties, and capture points.
• Draft the documented consent process and approval workflow for consent text.
• Identify where you lack versioning, logging, or withdrawal propagation. ¹

Second phase: implement system-of-record and evidence capture (near-term)

• Select the system of record for consent (or formalize an existing one).
• Add required fields (purpose, timestamp, method, version pointer, status).
• Implement consent export/reporting that can answer audit prompts quickly.
• Create a standard evidence packet in Daydream: process doc, consent text versions, screenshots, sample records, and test results. ¹

Third phase: operationalize lifecycle and monitoring (ongoing)

• Implement withdrawal propagation to downstream systems and third parties.
• Add routine testing: sample a consent record, trace it to processing, confirm suppression.
• Put consent text changes under change control; ensure version updates are recorded and discoverable.
• Train support and product teams on what must be logged for non-digital consent capture. ¹

Frequently Asked Questions

Do we need consent for all PII processing to satisfy ISO 27701?

Clause 7.2.4 requires you to obtain and record consent when you rely on consent and have defined consent-based processing. The control is about having a documented process and auditable evidence for consent you do collect. ¹

What does “auditable evidence” mean in practice?

You should be able to retrieve a record that shows what was consented to, when it happened, and how you obtained it, tied to the exact consent statement version. If you cannot reconstruct those elements, your evidence will usually be treated as weak. ¹

Is a screenshot of the checkbox enough evidence?

A screenshot helps prove the user experience existed, but it does not prove a specific individual consented at a specific time. Pair screenshots with event logs or database records that link the person, purpose, timestamp, method, and text version. ¹

How should we handle consent collected by phone or paper?

Treat it as the same control with a different capture method. Use scripts or forms with version IDs and record the consent event with timestamp, method, and a pointer to the exact script/form version used. ¹

What if multiple products collect consent differently today?

Standardize the consent inventory and minimum required fields, then allow product-specific UI as long as it records the same auditable elements. Your documented process should explain permitted variations and how versioning stays consistent. ¹

How can Daydream help without becoming another system engineers hate?

Keep consent capture in your operational systems, then use Daydream to organize the control narrative, map consent purposes to evidence, collect samples, and track testing and exceptions. That gives you a clean audit trail without forcing engineers to change how they log events. ¹

Footnotes

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