A financial platform must restrict which rows and columns each analyst can see. Where should that be enforced?

Where it must be enforced

In the data platform itself, not in the reporting tool. A restriction applied in a dashboard is bypassed by anyone querying directly, and direct query access is exactly what a data platform provides.

Enforcement in the engine — row-level policies and column masking evaluated at query time — means a query without the appropriate role returns fewer rows or masked values rather than being trusted to filter itself.

What that requires

• Roles and attributes that map to a real access model, derived from the organisation's own identity system rather than maintained separately. A parallel access list drifts within a quarter.
• Policies as code, reviewed and version-controlled, since an access policy edited in a console has no history and no review.
• Column-level classification driving the masking, so the policy is derived from the data's sensitivity rather than enumerated per column — enumeration does not survive schema change.
• Testing. Automated tests that a given role sees exactly what it should, run on every change, treating isolation as a fitness function rather than as a practice.
• Audit of access, including denied attempts, since a denied attempt is frequently the more interesting record.

The paths that are usually forgotten

Derived datasets. A restricted column copied into an aggregate, a model's training set, an export or a reverse-ETL destination has escaped the policy. The classification must propagate through lineage, and enforcement must apply to the derived table too — otherwise the control exists on the source and nowhere else.

And internal tooling: the support console, the analytics job, the data export. These are written by people solving a different problem and routinely have unrestricted access — which means the access model is rigorous against external threats and permissive against the paths an insider would use.

The trade-off to design around

Fine-grained policies slow queries, because the engine evaluates them per row. For a large analytical scan that cost is real.

The usual resolution is coarse separation plus fine-grained policy: sensitive data in separate tables with role-based access, and row-level policy only where genuinely per-row restriction is needed. That is cheaper and easier to reason about than a policy engine evaluating a complex rule over billions of rows.