Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

Lawful-basis-of-processing tracking

lawful-basis-trackingDomain: data-privacyType: process

Description

GDPR Article 6 enumerates six lawful bases for processing personal data: consent, contract, legitimate interest, vital interest, public task, and legal obligation. Most non-EU privacy regimes have converged on a similar enumeration; LGPD Article 7 names ten in Brazil with substantive overlap, PIPL distinguishes consent from statutory processing in China, POPIA mirrors the EU framework in South Africa, and the UAE, Saudi, Kenyan, Indonesian, and Philippine laws each carry their own variant of the same structure. The point is that lawful-basis selection is a substantive question with a small fixed set of answers, not a free-form box. Lawful basis is not a one-time selection at product launch. It attaches per processing activity, which means a product that does account creation, marketing analytics, third-party advertising, customer support, fraud detection, and product analytics is running six lawful-basis selections that frequently have different answers, that may have different answers in different jurisdictions, and that may have different answers for different cohorts of users (the lawful basis for processing a child user's data is rarely the same as for an adult user's). Tracking the basis per processing activity is therefore a per-activity table rather than a single product-level setting, and the table feeds three downstream surfaces: the records-of-processing-activities document under GDPR Article 30, the legitimate-interest assessment documents (LIAs) where the basis chosen was legitimate interest, and the privacy notice that surfaces the basis to data subjects. The regulators read this as a structural triangle. The activity-to-basis mapping in the ROPA establishes what the operator claims. The LIA documents the assessment behind any legitimate-interest claim with a written record of the necessity test (is the processing necessary for the legitimate interest), the legitimate-interest test (what is the interest and is it legitimate), and the balancing-against-data-subject-rights test (does the data subject's rights and freedoms override the interest in this case). And the privacy notice surfaces the result of the analysis to data subjects in language they can engage with. A claim in the ROPA that does not match the LIA, or an LIA that does not match the privacy notice, is the most common failure mode and the one regulators surface during examinations. The place this typically breaks is the conflation of consent with contract. Consent is one of the six options and is not the easy one, because it has to be freely given (not bundled into a take-it-or-leave-it terms-of-service acceptance), specific (one consent per purpose rather than blanket), informed (the data subject has to understand what they are consenting to), unambiguous (silence or pre-ticked boxes do not count), and revocable at the same friction level as the giving (the EDPB has been explicit on this). Most product teams reach for consent reflexively because it is the most familiar of the six bases, then discover that contract necessity or legitimate interest would have been a better structural fit. The cost of the wrong choice is real: the consent UX shipped at launch becomes the path of least resistance for years because changing it requires either a re-consent campaign that visibly degrades the metric the team is being measured on or a switch of lawful basis mid-stream that the data-protection authorities read as a confession that the original basis was wrong. Picking the right basis at launch is materially cheaper than relitigating it later.

Applicability

Applies when: markets include EU, UK, brazil, or canada.

How predicates are evaluated

Required by (10 regulations)

  • GDPR

    Article 6 — lawfulness of processing; Article 30 — records of processing activities.

    Regulation (EU) 2016/679 of the European Parliament and of the Council

  • Indonesia PDP
  • Kenya DPA
  • LGPD

    Article 7 — legal bases for processing.

    Lei nº 13.709, de 14 de agosto de 2018 (as amended by Lei nº 13.853/2019 and Emenda Constitucional nº 115/2022)

  • Philippines DPA
  • PIPL

    Personal Information Protection Law of the People's Republic of China (adopted August 20, 2021, effective November 1, 2021)

  • PDPL

    Royal Decree M/19, dated 9/2/1443 AH (September 16, 2021), Personal Data Protection Law, effective September 14, 2023

  • POPIA
  • UAE Data Protection Law
  • Chile Law 19.628

    Chile's data-protection regime requires a lawful basis (typically consent) for processing personal data.

    Ley N° 19.628 sobre Protección de la Vida Privada (1999); to be substantially superseded by Ley N° 21.719 (2024) effective 2026-12-01

    Source →

Fulfilled by (3)

  • onetrust · full · medium effort · $$
  • transcend · partial · medium effort · $$
  • In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • ROPA (Article 30 record)
  • legitimate-interest assessments (LIAs)
  • consent receipts

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn