Data Access Control for Growing Teams: A Practical Checklist
Most analytics tools ask you to decide, per person, whether they can see the data. The honest answer is usually "some of it". A good access model lets you say exactly which part. This checklist covers the controls that matter for a team that is growing, with what to look for in each.
Trinetro Labs · Published 2 October 2026 · 3 min read
The checklist
- Default deny. A new member should see nothing until someone grants access. If the default is "everything", you are relying on people being careful.
- Scope below the source. Grants should narrow to named tables or sheets, so someone can be given one sheet of a workbook and nothing else.
- Enforcement on the server. Hiding a menu is not access control. Every query, dashboard and model load should be filtered by scope on the server.
- Members ask, admins decide. A person can connect their own data, but its tables stay closed until an admin approves.
- No double approvals. Re-connecting something already approved should not create a second request.
- Delegation that cannot widen access. When an admin configures something for a colleague, the check should run against the colleague's scope, not the admin's.
- Models that are not shared by accident. One person's data model should never be served to another.
- Clean-up on sign-out. Connections and credentials should not outlive the session.
- An audit trail. Who requested, who approved, at what scope, kept separately from the data itself.
- Rate limits on sign-in and data-connection endpoints.
A simple test you can run today
- Create a test member with no grants and confirm they see no data.
- Grant one table, and confirm they cannot reach a second table in the same source.
- Ask a question that would need the second table, and confirm the answer refuses rather than guesses.
- Have the member sign out, and confirm what is left behind.
How Trinetro maps to the checklist
Trinetro follows each of these: a new member has no data access until an admin grants it; grants are per source and can be narrowed to tables or sheets; every query is filtered server-side; members request and admins approve; delegated actions carry the member's own permissions; models are held per member; connections and encrypted credentials are deleted when the last person signs out; and an audit trace outlives the data. Details are on the security page.
For the reasoning behind it, read who should see which numbers.
Frequently asked questions
What is default-deny access?
It means a new user has no access to anything until an administrator explicitly grants it, rather than starting with access to everything and having it removed.
What is table-level access control?
It is the ability to grant access to specific tables or sheets within a data source, so a person can use some of the data without seeing the rest.
Why must access be enforced on the server?
Because hiding something in the interface does not stop it being requested directly. Server-side checks apply to every request.
What should happen to connections when people sign out?
Connections and stored credentials should be removed when the last person in a workspace signs out. Trinetro does this, and one person leaving does not affect a colleague who is still working.