It wasn’t encrypted. It wasn’t locked down. It shouldn’t have been visible.
Legal compliance for sensitive data requires more than encryption and access controls. For regulated industries—finance, healthcare, government—Row-Level Security (RLS) is not optional. RLS enforces rules at the most granular level, ensuring that each query returns only the rows a user is authorized to see. Done right, it aligns application logic directly with compliance mandates like GDPR, HIPAA, and PCI DSS. Done wrong, it leaves audit gaps that lawyers and regulators will find.
RLS works by binding visibility to identity. Policies are defined at the database level—PostgreSQL, SQL Server, and other systems have built-in features for this. Rules are expressed in SQL, checked automatically on every query. Because the enforcement happens inside the database engine, it is immune to bugs in application code that could bypass filters. This creates a clean compliance boundary: access checks live in one place, enforced everywhere.
For legal compliance, RLS must be integrated with authentication systems. User IDs, roles, and jurisdiction flags must be part of the policy logic. If a customer in one country has a privacy right to block certain data views, the policy needs explicit condition checks. Every clause must be testable, audit-ready, and provable. Regulators want evidence that no unauthorized row can be returned, even in direct SQL sessions.