Identify lawful basis

To meet the ISO/IEC 27701 “identify lawful basis” requirement, you must determine the lawful basis for processing PII for each defined processing purpose and document that determination in a way you can defend during audits, DPIAs, and change reviews. Operationally, this means mapping each purpose to a named lawful basis, recording the rationale, and tying it to your records of processing and notices. ¹

Key takeaways:

• You need a lawful-basis decision per purpose, not per system or per dataset.
• Documentation must include rationale and be kept current through change management.
• Lawful basis drives downstream controls: notices, consent flows, retention, and third-party contract terms.

“Identify lawful basis” is a requirement that looks simple until you try to operationalize it across dozens of products, regions, and teams. ISO/IEC 27701 makes it explicit: for each processing purpose you have identified, you must determine what makes that processing lawful and document the decision. ¹

For a Compliance Officer, CCO, or GRC lead, the practical goal is defensibility. You want a repeatable method that (1) produces a clear lawful-basis decision for each purpose, (2) ties to your records of processing, privacy notices, and consent/opt-out mechanisms, and (3) stays correct as products, data uses, and third parties change.

This page gives you requirement-level implementation guidance: who owns the decision, how to structure the decision record, what artifacts auditors ask for, and how to avoid common failure modes (like mixing “purpose” with “processing activity,” or treating consent as a default). It is written for operators who need a working approach quickly and need it to survive audit scrutiny.

Regulatory text

Requirement. “The organization shall determine, for each identified purpose, the lawful basis that makes the processing of PII lawful and shall document this determination.” ¹

Operator meaning. You must:

1. enumerate processing purposes (for example, “customer billing,” “fraud prevention,” “marketing emails,” “employee payroll”),
2. assign a lawful basis to each purpose, and
3. document the decision so it can be reviewed, approved, and audited.

ISO/IEC 27701 does not prescribe which lawful bases exist in your jurisdiction; it requires that you make a purposeful determination and can prove you made it. ¹

Plain-English interpretation (what the requirement is really testing)

Auditors are testing whether your organization can answer, consistently and with evidence:

• “Why are you allowed to process this PII for this reason?”
• “Where is that recorded?”
• “What changed since last review, and how did you reassess lawful basis?”

This requirement also acts as a dependency for other privacy controls. If you cannot state lawful basis per purpose, you cannot reliably implement aligned notices, consent collection, objection handling, retention rules, or third-party processing instructions.

Who it applies to

Entity scope: PII Controllers. ¹

Operational scope: Any business unit, product team, or function that defines why PII is processed, including:

• Customer onboarding, account management, billing, support
• Marketing and analytics functions
• HR, payroll, benefits, workplace security
• Security operations (logging, monitoring) where logs contain PII
• Procurement and third-party management where third parties process PII on your instructions

If you operate in multiple jurisdictions, treat “lawful basis” as jurisdiction-dependent. The standard’s requirement remains the same: you must determine and document the lawful basis for each purpose in the relevant context. ¹

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

Step 1: Build a purpose inventory you can govern

Start from your existing record of processing, data map, or system inventory. Normalize it into a Purpose Register with entries that are stable and business-readable. A useful purpose statement format:

• Verb + object + outcome (example: “Send password reset emails to restore account access.”)

Keep purposes distinct from:

• Processing activities (technical steps like “store,” “transmit,” “encrypt”)
• Systems (“CRM,” “data lake”)
• Data categories (“email address,” “IP address”)

Output: a list of unique purposes with owners.

Step 2: Define your lawful-basis taxonomy (controlled list)

ISO/IEC 27701 expects you to identify a lawful basis “such as consent, contractual necessity, legal obligation, or legitimate interest.” ¹

Operationalize this as a controlled vocabulary in your GRC tool, RoPA workflow, or privacy management platform. Keep it simple:

• Consent
• Contractual necessity
• Legal obligation
• Legitimate interest
• (Add jurisdiction-specific bases where needed, but keep the list controlled and documented.)

Step 3: Run a lawful-basis determination for each purpose

For each purpose, run a structured decision that produces:

• Selected lawful basis
• Rationale (why that basis fits this purpose)
• Conditions and constraints (what must be true for the basis to remain valid)
• Dependencies (notices, consent records, opt-out paths, retention, third-party clauses)

A practical decision workflow:

1. Describe the purpose in one sentence.
2. Identify the data subjects (customers, prospects, employees) and PII categories at a high level.
3. Select the lawful basis from your controlled list.
4. Write a short justification that is specific to the purpose (avoid copy/paste).
5. List required operational controls driven by the choice:
   • If consent, specify where consent is captured, how it is recorded, and how withdrawal works.
   • If contract, identify the contract type or product terms that make processing necessary.
   • If legal obligation, reference the internal obligation source (policy requirement, statutory requirement as interpreted by counsel) and who monitors changes.
   • If legitimate interest, document the balancing rationale at a level appropriate for your risk posture, and record how objections are handled.
6. Approve the decision (privacy, compliance, and the business owner).
7. Link the decision to the RoPA entry, privacy notice section, and any DPIA/PIA if applicable.

Step 4: Embed lawful basis into change management

Most programs fail here. Lawful basis documentation becomes stale unless you force reevaluation on change events. Add a trigger to your intake process for:

• New purpose or expanded purpose
• New PII category (example: adding precise location)
• New data subject group (example: minors, employees, patients)
• New third party or new sharing use case
• New region/market launch

Require a “lawful basis confirmed/updated” checkbox tied to the Purpose Register entry before release approval.

Step 5: Operationalize through third-party and product controls

Lawful basis choices must be reflected in operational artifacts:

• Third-party contracts and DPAs: ensure processing instructions align with the purposes and bases you documented.
• Privacy notices: ensure your external statements match internal lawful basis decisions.
• Product UX: consent and preference settings must align with the purposes that rely on consent.
• Retention and deletion: retention logic should not contradict the lawful basis rationale for keeping data.

If you use a system like Daydream to manage third-party risk and due diligence workflows, connect lawful-basis fields to third-party onboarding and change reviews. That linkage prevents the classic gap where a new third party is added for a “new” purpose without updating the lawful basis record.

Required evidence and artifacts to retain

Keep evidence in a form that survives staff turnover and tool migrations.

Minimum artifacts:

• Purpose Register (purpose, owner, systems involved, PII categories at a high level)
• Lawful Basis Determination Record for each purpose (basis selection + rationale + approver + date)
• Approval evidence (ticket, workflow approval, meeting minutes, or e-sign)
• Cross-references:
  • Link to RoPA entry
  • Link to privacy notice section or internal notice mapping
  • Link to consent logs where consent is the basis
  • Link to DPIA/PIA where performed
• Change log showing when a purpose/basis was updated and why

Auditors look for traceability: “Show me Purpose X, its lawful basis, and where you prove it is implemented.”

Common exam/audit questions and hangups

Expect these:

• “Show the lawful basis for each purpose in your RoPA. Who approved it?”
• “How do you ensure marketing purposes aren’t mixed into service delivery purposes?”
• “What triggers reassessment of lawful basis when a product changes?”
• “Where do you store evidence of consent and withdrawal?”
• “How do you govern third parties so they only process for the documented purposes?”

Hangups that slow audits:

• Purpose statements that are too broad (“analytics”).
• Lawful basis recorded per system rather than per purpose.
• No clear owner accountable for a purpose entry.

Frequent implementation mistakes (and how to avoid them)

1. Defaulting everything to consent. Consent has operational overhead and failure modes (withdrawal, proof, UX). Only choose it where you can operate it cleanly and where it fits the purpose. ISO/IEC 27701 expects a determination, not a one-size-fits-all answer. ¹

2. Writing vague rationales. “Business need” is not a rationale. Tie the basis to the purpose and the relationship with the data subject.

3. Forgetting internal processing. Security logs, HR workflows, and finance operations often process PII. Those purposes still need lawful basis decisions and documentation.

4. No link to external statements. If your privacy notice implies one basis while your internal register uses another, you create compliance and reputation risk. Add a notice-mapping field per purpose.

5. Not integrating third parties. If a third party receives PII for a purpose, your lawful basis documentation should reflect that sharing and the contractual controls that constrain the third party.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases.

Practically, weak lawful-basis documentation increases:

• Audit nonconformities under ISO/IEC 27701 (you cannot show the required determination and documentation). ¹
• Operational privacy risk: teams may process PII for new or expanded purposes without governance, which then cascades into notice gaps, consent gaps, and uncontrolled third-party sharing.

Practical 30/60/90-day execution plan

First 30 days (stabilize and get coverage)

• Assign an executive owner (privacy/compliance) and operational owners per business area.
• Create the Purpose Register template and lawful-basis decision template.
• Triage to “top risk” purposes first: customer acquisition/marketing, behavioral analytics, data sharing with third parties, and employee monitoring use cases.
• Stand up an approval workflow (even a ticketing queue) with required fields and an approver list.

Days 31–60 (make it repeatable)

• Complete lawful-basis determinations for remaining purposes in scope.
• Link each purpose to RoPA entries and privacy notice mapping.
• Add change triggers to product intake, procurement intake, and data governance requests.
• Train product, marketing, HR, and procurement on how to write a purpose statement and when to escalate to privacy counsel.

Days 61–90 (embed and audit-proof)

• Run an internal audit-style sample: pick several purposes, trace to evidence, confirm the basis matches actual implementation.
• Remediate mismatches (notice text, consent capture, third-party instructions).
• Put lawful basis reviews on a recurring governance cadence tied to roadmap planning and major releases.
• If you use Daydream, configure required lawful-basis fields in workflows for new third parties and significant change reviews, and require attachment of the lawful-basis record before approvals.

Frequently Asked Questions

Do I need a lawful basis per dataset or per system?

ISO/IEC 27701 calls for a lawful basis “for each identified purpose.” Organize decisions by purpose, then map purposes to systems and datasets for traceability. ¹

Can one purpose have more than one lawful basis?

Keep one primary lawful basis per purpose where possible so controls remain clear. If different populations or regions require different bases, split the purpose into scoped sub-purposes and document each determination separately.

What counts as “documented” for an ISO audit?

A durable record that shows the purpose, the selected lawful basis, the rationale, and an approval trail. A spreadsheet can work short-term, but auditors will still expect version control, ownership, and change history.

How detailed does the rationale need to be?

Detailed enough that a reviewer who was not in the meeting can understand why the basis fits the purpose and what must remain true. One to several purpose-specific paragraphs usually beats a generic sentence.

How do we handle third parties that process PII for multiple purposes?

Document the lawful basis per purpose first, then map which purposes each third party supports. Your contract, DPA, and onboarding due diligence should restrict processing to those documented purposes.

What is the fastest way to operationalize this across many teams?

Standardize templates and force completion through intake workflows (product changes, new data uses, new third parties). Automation in tools like Daydream helps by making “lawful basis selected + rationale attached” a gating requirement for approvals.

Footnotes

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