Test whether a financial report reveals another team's records

Before sharing a payroll, customer, or departmental finance report, identify which records each audience may see. A company selector on the page is a navigation feature unless the underlying access design enforces the same boundary. The test must show what an ordinary reader can retrieve when filters, links, and export options change.

Use a small approved test population with recognizable fictional records for two companies or departments. Specify which test identity should see each record and which actions it may perform. Do not use unauthorized access to real employee or customer data as a convenient way to check the design.

PostgreSQL documents that superusers and roles with bypass privileges can bypass row security; table owners normally do so too. A successful test performed only as a database administrator therefore does not establish the ordinary reader's restrictions. Ask the implementer to demonstrate the actual application or reporting role involved.

Microsoft's Power BI guidance describes another important product-specific behavior: membership in multiple row-security roles can combine the permitted rows. One restrictive role does not necessarily cancel a broader role. Include direct membership, inherited group membership, and unexpected or unrecognized identities in the acceptance review.

Keep the evidence free of passwords, tokens, and live confidential records. Record the role configuration, test identity, permitted population, observed output, and reviewer instead. The result should be repeatable after a permission change without retaining secrets in a spreadsheet.

Check detailed tables, drill-through pages, downloaded files, shared links, and any underlying-data access available to that audience. A report can appear correctly filtered while an export or linked detail page exposes a wider population. Have the technical owner explain where each path obtains its permissions.

Inspect summary measures as well. Suppose a reader is allowed to see one division's payroll but a displayed company total includes exactly one other division. The reader may infer the other division's amount by subtraction. Decide whether that disclosure is permitted before approving the summary. A hidden detail table alone does not settle the question.

Repeat the checks after switching between permitted entities and after removing a test identity's access. Cached pages, downloaded copies, and already distributed files have different behaviors. Document the limits of revocation instead of promising that removing a role retrieves every copy a recipient already obtained.

If a test exposes prohibited records, stop the affected distribution and involve the responsible security and data owners. Preserve enough evidence to identify the route and scope without circulating the confidential material further. Follow the organization's incident process for any actual disclosure; this technical check does not determine legal notification duties.

After the owner corrects the permission path, rerun the failed scenario and adjacent paths that share it. Confirm that legitimate readers still receive the information they need. Blocking every report may contain an issue temporarily, but it is not evidence that the intended permission design now works.

Retain the accepted audience matrix and focused tests with the report's release record. Revisit them when a company is added, a group changes, a report gains an export, or a model relationship changes. Those events can alter access even when the report's visible layout stays the same.