Lawful Basis Assessment
A Lawful Basis Assessment documents the justification for processing personal data under the applicable privacy framework(s). It records the processing purpose, the lawful basis relied on (e.g., consent, contract, legal obligation, legitimate interests, or equivalent permitted grounds), necessity and proportionality rationale, safeguards, retention alignment, and any notice or opt-out requirements. Maintaining a consistent assessment helps organizations demonstrate accountability, support audits, and re-evaluate processing when systems, vendors, or purposes change.
Command Line Examples
cp templates/lawful-basis-assessment.md assessments/<process-or-system>-lawful-basis-<YYYY-MM-DD>.mdA lawful basis assessment is a documented evaluation that explains why a specific personal data processing activity is permitted under the applicable privacy framework(s). It captures the purpose, the lawful basis relied on, the necessity rationale, and the safeguards used to reduce risk.
Documentation supports accountability: it shows that the organization considered the purpose, selected an appropriate lawful basis, and implemented reasonable safeguards. It also helps maintain consistency across teams and speeds up audits, privacy reviews, and incident investigations.
Start with the purpose and relationship context. If the processing is required to provide a requested service or fulfill an agreement, contract-related grounds may apply. If processing is required by law, legal obligation may apply. If the processing is optional (e.g., marketing, analytics), consent or other permitted grounds may be needed depending on the framework and context.
Consent is one possible lawful basis (in frameworks that recognize it), but not the only one. Other bases can include contractual necessity, legal obligation, legitimate interests, or equivalent permitted grounds. If you rely on consent, you typically need a clear affirmative action and an easy method to withdraw.
Some organizations document a primary lawful basis and note secondary or fallback grounds for edge cases. However, mixing bases can create confusion. A common practice is to define one primary basis per purpose and clearly document how exceptions are handled.
Switching bases can be risky and may require new notices, updated expectations, and potentially re-collection of data depending on the framework. If a basis changes, document the rationale, the new controls/communications, and the impact on retention and user choices.
Typical fields include: processing purpose, data subjects, data types, systems/vendors involved, lawful basis selection, necessity and proportionality rationale, safeguards, notice content, opt-out/withdrawal mechanisms where applicable, retention/deletion alignment, and review triggers.
Explain why the processing is directly connected to the stated purpose and why a less intrusive approach would not reasonably achieve the same outcome. Consider data minimization, shorter retention, fewer recipients, or alternative design options.
An LIA is a specific type of lawful basis assessment used in some regimes when relying on legitimate interests. It commonly documents the purpose, necessity, and a balancing analysis to ensure impacts on individuals are appropriately mitigated.
It depends on the jurisdiction, channel, and context. Many regulators expect opt-in consent for certain marketing channels and tracking technologies. A practical approach is to document the marketing purpose, user expectations, opt-out controls, and applicable local requirements.
This varies by jurisdiction and the context of processing (payroll, benefits, access control, security monitoring). Many organizations document the purpose, the relevant employment or legal/contractual ground (as applicable), and safeguards such as access limits, retention controls, and transparency to employees.
Security-related processing is often justified under permitted grounds connected to protecting services, preventing misuse, meeting legal/security obligations, or maintaining system integrity (depending on the framework). Document the security purpose, logging scope, access restrictions, retention, and monitoring controls.
A lawful basis assessment explains why processing is permitted. A DPIA evaluates risks to individuals and records mitigation measures. High-risk processing often benefits from both: the lawful basis assessment for justification and the DPIA for risk management.
A data inventory map/ROPA captures what data is processed, where it flows, and why. The lawful basis assessment focuses on the justification for that processing and the controls that make it appropriate. Many organizations link them so changes in one trigger review in the other.
Keep artifacts that show purpose and controls in practice: notices, consent logs (if used), contracts/data processing terms with vendors, retention schedules, access control evidence, security safeguards, and decision notes documenting why the basis was selected.
Document which vendors support the processing, what data they receive, and what contractual and technical safeguards apply. Many teams link the assessment to vendor records (DPA, security review outcomes, data residency, and sub-processor disclosures).
Document the primary lawful basis and note regional variations where requirements differ (e.g., consent requirements for tracking/marketing, local employment rules). Many organizations maintain a common baseline plus an annex for jurisdiction-specific adjustments.
Common issues include: unclear purpose statements, copying a basis without explaining necessity, relying on consent where it is not practical to manage withdrawal, failing to link to safeguards/retention, and not revisiting assessments when the processing changes.
Review when the processing changes materially (purpose, scope, data types, sharing, vendors, or technology) and periodically for higher-risk workflows. A simple trigger-based review process prevents assessments from going stale.
If you cannot justify an appropriate basis, redesign the processing (reduce scope/data, change workflow), obtain valid consent where appropriate, or stop processing until a compliant basis exists. Document the decision and next steps.
Truly anonymized data may fall outside many personal data regimes, but the boundary is strict. If there is a realistic possibility of re-identification, treat the data as personal and document the lawful basis accordingly.
Tracking requirements vary by jurisdiction and technology type. Document what trackers do, whether they are essential or non-essential, what notice/choice mechanisms are used, and what basis is relied on. Many teams keep a tracker inventory and link it to the lawful basis assessment and cookie notice.
Make the assessment repeatable: use consistent fields, record rationale for each decision, link to supporting evidence, assign an owner, and define review triggers. Audit readiness comes from traceability—being able to show what changed, who approved it, and what safeguards were in place.
A checklist confirms whether controls exist; a lawful basis assessment explains the justification for a specific processing purpose and ties that justification to safeguards, notices, and retention. It is purpose-specific rather than a broad control inventory.
ICO (UK) — Lawful basis for processing
UK Information Commissioner's Office (ICO)
ICO (UK) — Legitimate interests
UK Information Commissioner's Office (ICO)
EDPB — Guidelines 05/2020 on consent
European Data Protection Board (EDPB)
NIST Privacy Framework
National Institute of Standards and Technology (NIST)
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-13 | WatchDog Security GRC Wiki Team | Initial publication |