An analyst can query the customer table. A regulator asks whether she was allowed to use it for the marketing model she built. Role-based access answers one of those questions and not the other. What is the difference between role-, attribute- and purpose-based access, and what does purpose add?

The mechanism, in one line each

• Role-based (RBAC): permission is attached to a named role, and people are put in roles. "Members of analytics-eu can read customers_eu." The check is a set membership test, which is why it is fast and easy to audit.
• Attribute-based (ABAC): permission is computed from attributes of the user, the data and the context. "A user in country X may read rows whose data_region is X during working hours." The check is a policy evaluation, so it can express rules that would need hundreds of roles.
• Purpose-based: access is granted for a declared reason, recorded with the access and bounded in time. "This dataset may be read for fraud investigation, not for marketing."

What purpose adds that the other two cannot express

RBAC and ABAC both answer who may read what. Neither records why, and most data protection regimes constrain the why: personal data collected to deliver a service generally cannot be repurposed for unrelated modelling without a fresh basis.

Purpose-based access makes the reason a first-class part of the grant, which has three practical consequences: the grant can expire when the purpose ends, the access log becomes evidence of compliance rather than just a list of queries, and a second use of the same table by the same person can be refused without removing their original access.

The cost is real. Someone must maintain the purpose taxonomy, and users must pick honestly from it, so it works where purposes are few and consequential (clinical research, fraud, credit decisioning) and collapses where a team invents a purpose per query.

Choosing between them

Start with roles. Under roughly 50 roles with stable teams and data in 1 or 2 regions, RBAC is sufficient and its audit story is the simplest. Add attributes when roles start multiplying by region, tenant or classification — role explosion is the signal, and it is unmistakable because the roles begin to have names like analytics-eu-pii-readonly-contractor.

Add purpose only where a law or a contract asks for it, because it is the most expensive of the three to run. Purpose limitation has been an explicit principle of EU data protection law since the GDPR became applicable in 2018, so choose it when that obligation is in scope and not otherwise.

Common weak answers

• "ABAC is more modern so it is better." ABAC's policies are code, and code without tests fails open in ways a role list does not. Many estates run both: coarse roles for shape, attributes for the fine-grained rules.
• "We log queries, so we have purpose." A log tells you what happened. It does not constrain it, and it does not record a reason anyone committed to.
• Treating row-level security as an access model. It is an enforcement mechanism; the model is the thing that decides what the rules should be.