Skip to main content
DataRidge
Category: Access Control

Row-Level Security

Also known as: RLS, Row Security Policies
Simply put

Row-Level Security (RLS) is a database access control that limits which rows within a table a given user can see or modify, based on their identity, role, or session context. Rather than granting or denying access to an entire table, it filters the data so users only see the specific rows they are permitted to access. It is implemented within database platforms and analytics tools such as PostgreSQL, Power BI, Databricks, and CockroachDB.

Formal definition

Row-Level Security is an access control mechanism, typically enforced at the database or semantic-model layer, that restricts read and/or write operations to a subset of rows in a table according to policies evaluated against a user's identity, role, or session attributes. In implementations such as PostgreSQL, row security policies are applied per-table and, by default, tables have no policies so table-level access privileges otherwise govern access; in tools like Power BI, filters restrict data at the row level within a semantic model. RLS is a security control (part of confidentiality enforcement) rather than a data governance construct, and this definition does not address whether the data being restricted is personal data, nor does it cover pseudonymization, anonymization, retention, cross-border transfer, or any specific regulatory obligation. Applying RLS does not by itself render restricted data non-personal or satisfy any particular legal requirement; compliance depends on broader context and implementation.

Why it matters

Row-Level Security addresses a common gap in data access control: coarse, table-level permissions frequently grant users far more visibility than they need. Where a single table holds records belonging to many customers, business units, or tenants, granting access to the table as a whole can expose rows that a given user has no legitimate reason to see. RLS narrows access to the specific rows a user is permitted to view or modify, supporting the principle of least privilege at a finer granularity than table-level grants alone.

For organizations enforcing confidentiality, RLS is a practical control for multi-tenant systems and shared analytics environments, where the same table or semantic model serves users with different entitlements. It can help reduce the risk of inadvertent over-exposure of data within a shared store. However, RLS is a security control focused on confidentiality enforcement; it is not a data governance construct and does not, on its own, establish ownership, stewardship, data quality, or lineage.

It is important not to overstate what RLS achieves. Restricting which rows a user can access does not change the nature of the underlying data: applying RLS to personal data does not render that data non-personal, and it does not by itself satisfy any particular legal or regulatory obligation. Whether RLS is sufficient in any given deployment depends on broader context, the correctness of the policies configured, and the surrounding controls; this definition does not address retention, cross-border transfer, pseudonymization, anonymization, or specific compliance requirements.

Who it's relevant to

Privacy engineers and data platform teams
Teams building multi-tenant or shared analytics platforms use RLS to enforce least-privilege access at the row level within shared tables and semantic models. They should validate that policies are applied per table where required and remember that, in platforms such as PostgreSQL, tables without a defined policy default to table-level access privileges, which can leave data unexpectedly exposed.
Information security professionals
RLS is a confidentiality control that constrains which rows a user can read or change based on identity, role, or session context. Security teams should treat it as one layer within a broader access control design rather than a standalone assurance, and verify policy correctness across the specific platforms in use, such as Databricks or CockroachDB.
Data protection officers and compliance leads
Where the restricted data includes personal data, DPOs should note that RLS does not render that data non-personal and does not by itself satisfy any particular regulatory obligation. Its adequacy depends on jurisdiction, context, and implementation; this control does not address retention, cross-border transfer, or lawful basis, which must be handled separately.
Data governance and stewardship leads
Governance teams should recognize RLS as a security enforcement mechanism rather than a governance construct. It does not establish data ownership, stewardship, quality, or lineage, though it can support governance policies once those responsibilities and access decisions are defined elsewhere. Demonstrable accountability requires evidence that policies reflect approved access decisions, not merely that RLS is enabled.

Inside RLS

Row-Level Security (RLS)
An access control mechanism, typically implemented at the database or analytics platform layer, that restricts which rows within a table a given user or role can read or modify based on defined policies. It filters data horizontally so that different users querying the same table see different subsets of records.
Security Policy or Predicate
The rule or filter expression that determines row visibility, often evaluated against user attributes, roles, or session context. The predicate is applied automatically at query time so that unauthorized rows are excluded from results.
User or Role Context
The identity, role, group membership, or session attributes against which the policy is evaluated. RLS decisions generally depend on reliable authentication and role assignment upstream; the mechanism enforces filtering but does not itself establish identity.
Enforcement Point
The layer where the policy is evaluated, commonly the database engine, a data warehouse, or a business intelligence tool. Where enforcement occurs affects consistency, because filtering applied in one tool may not carry over to direct database access through another path.
Relationship to Data Governance and Security
RLS is primarily an information security control supporting confidentiality by limiting access to specific records. It can support governance objectives such as data minimization and need-to-know access, but governance concerns like ownership, stewardship, lineage, and policy definition remain distinct from the technical enforcement itself.

Common questions

Answers to the questions practitioners most commonly ask about RLS.

Does row-level security anonymize or de-identify the data it restricts?
No. Row-level security is an access control mechanism that filters which rows a given user or role can see; it does not alter, mask, or de-identify the underlying values. The data remains fully intact and, where it relates to identified or identifiable individuals, remains personal data regardless of who can view it. Row-level security should not be confused with anonymization (which, where genuinely irreversible, is generally treated as out of scope for most data protection regimes) or with pseudonymization (which remains personal data). It also does not, on its own, remove or reduce controller obligations.
Is implementing row-level security sufficient to make our processing compliant with data protection law?
No single control guarantees compliance. Row-level security is one confidentiality-oriented access control and typically contributes to a broader control set, but compliance depends on context, jurisdiction, and implementation. It does not by itself establish a lawful basis for processing, satisfy transparency or retention requirements, or discharge accountability obligations. Under most frameworks, accountability requires demonstrable evidence of appropriate measures rather than the mere presence of a technical control. Row-level security is generally best characterized as an information security measure that supports, but does not replace, governance and legal-basis analysis.
How is row-level security typically implemented in a database or analytics platform?
Row-level security is generally implemented by attaching a predicate or policy to a table so that queries automatically return only the rows a user or role is entitled to access, often keyed on attributes such as role, department, region, or tenant. Some database engines and analytics platforms provide native policy features for this, while others rely on parameterized views, security predicates, or application-layer filtering. The specific mechanism varies by platform; this entry does not endorse a particular product or describe vendor-specific configuration syntax.
How does row-level security differ from column-level security or data masking?
Row-level security restricts which records (rows) a user can retrieve, whereas column-level security restricts which fields (columns) are visible, and masking transforms displayed values so that some or all of a field is obscured. These controls address different exposure surfaces and are frequently combined. None of them, individually or together, converts personal data into non-personal data; they govern who sees what rather than changing the regulatory character of the data.
What governance elements should accompany a row-level security deployment?
Because row-level security enforces access decisions, it generally needs to be underpinned by governance artifacts such as documented data ownership and stewardship, defined roles and entitlement criteria, and clear policy on who may access which categories of data. These governance elements determine the correctness of the access rules, while row-level security is the enforcement layer. This separation matters: governance covers ownership, stewardship, and policy, whereas the control itself sits within information security. This entry does not cover retention rules or cross-border transfer mechanics.
How can an organization demonstrate that row-level security is operating as intended?
Demonstrable accountability typically calls for evidence such as documented policy definitions, records of who is assigned to which roles or entitlements, logs of access decisions, and periodic review or testing that the predicates return only authorized rows. Under governance frameworks, stated intent is generally insufficient; auditable evidence of design and operating effectiveness is expected. The precise evidentiary expectations depend on the applicable framework and internal audit requirements, which are out of scope for this definition.

Common misconceptions

Row-level security makes the underlying data anonymized or non-personal for users who cannot see certain rows.
RLS restricts visibility; it does not alter or de-identify the data. The records remain personal data, and the data controller's obligations persist. Restricting who can view rows is an access control, not anonymization or pseudonymization.
Implementing row-level security by itself demonstrates or guarantees compliance with data protection requirements.
RLS is one control that can support principles such as data minimization and access limitation, but no single control guarantees compliance. Compliance depends on lawful basis, purpose limitation, retention, accountability evidence, and broader context that RLS does not address.
Row-level security is equivalent to column-level or field-level protection and covers all data-limiting needs.
RLS filters records horizontally by row, whereas restricting sensitive attributes within a record requires separate controls such as column-level security, masking, or tokenization. These techniques address different exposures and are typically combined rather than substituted.

Best practices

Define row-level security policies from documented access requirements tied to roles and need-to-know, and maintain that mapping as demonstrable evidence to support accountability under governance frameworks.
Ensure RLS depends on a reliable authentication and role-assignment layer, since the mechanism enforces filtering but does not itself verify identity.
Apply enforcement as close to the data as practical, generally at the database or warehouse engine, so that policies remain consistent across the different tools and query paths that may access the same data.
Combine RLS with complementary controls such as column-level restrictions, masking, or encryption where sensitive attributes within visible rows require protection, recognizing these serve distinct purposes.
Do not treat RLS as de-identification; continue to apply retention, lawful basis, and other data protection obligations to the underlying records, which remain personal data regardless of who can view them.
Test and periodically review policies against representative user roles to confirm that intended row filtering behaves as expected and that no unintended access paths bypass the enforcement point.