# Ensure RLS-enabled tables have at least one defined policy

- Source: https://support.icompaas.com/support/solutions/articles/a_1790103901186889-ensure-rls-enabled-tables-have-at-least-one-defined-policy
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Supabase cloud](https://support.icompaas.com/support/solutions/c_1790103054038308) › [supabase checks](https://support.icompaas.com/support/solutions/folders/f_1790103067540538)
- Last updated: 2026-09-22
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure every table that has Row Level Security enabled also has at least one policy that defines who can read or change its rows. Tables should not be left with RLS turned on but no policies, unless the table is intentionally meant to be accessible only through server-side code.

**Rationale**

When RLS is enabled with no policies, the Data API denies all access to the table. This is safe, but it usually means the intended access rules were never written. Teams then often work around it by disabling RLS or using the secret key in the client, which creates a much bigger risk. Defining clear policies keeps access both working and secure.

**Impact**

-   Makes intended access rules explicit
    
-   Prevents risky workarounds such as disabling RLS
    
-   Policies must be tested to confirm they allow only the right rows
    

**Default Value**

By default, enabling RLS on a table does not create any policies, so all Data API access to the table is denied.

**Pre-Requisites**

-   Project Owner, Admin, or Developer role
    
-   An understanding of who should access each table
    

**Test Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open Advisors in the sidebar and select Security Advisor.
    
4.  Check for the finding RLS Enabled No Policy.
    
5.  For each listed table, confirm whether access through the Data API is intended.
    
6.  If a listed table needs API access, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  Create a policy for the table, for example: create policy "Users can read own rows" on public.<table\_name> for select to authenticated using ((select auth.uid()) = user\_id);
    
5.  Add policies for any other operations the table needs (insert, update, delete).
    
6.  Test the policies with a normal user account and rerun the Security Advisor.
    

**Backout Plan**

1.  Sign in to the Supabase Dashboard at [https://supabase.com/dashboard](https://supabase.com/dashboard).
    
2.  Select your project.
    
3.  Open the SQL Editor in the sidebar.
    
4.  Run: drop policy "<policy\_name>" on public.<table\_name>;
    

**Reference**

-   [https://supabase.com/docs/guides/database/postgres/row-level-security](https://supabase.com/docs/guides/database/postgres/row-level-security)
    
-   [https://supabase.com/docs/guides/database/database-advisors?lint=0008\_rls\_enabled\_no\_policy](https://supabase.com/docs/guides/database/database-advisors?lint=0008_rls_enabled_no_policy)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.