To give people access to company data without exposing restricted information, start by defining profiles by role and deciding, area by area and table by table, what each profile may query. Then choose a tool that enforces those rules before any answer is shown and that logs who asked what. The team stops queuing requests with the finance department, and not everyone ends up seeing everything.
In small and mid-sized businesses, data access tends to swing between two extremes. Either every figure goes through the one or two people who know how to pull reports out of the ERP, and questions wait for days, or someone exports everything to a spreadsheet that travels by email and is no longer controlled by anyone. Neither suits an organisation that wants to make decisions on data. This article explains how to design access, which profiles make sense and what changes when the team starts asking the data questions in natural language.
Why is data access hard to get right in a small business?
The difficulty is rarely technical. It lies in deciding, for each type of information, who needs it to do their job.
- The data is mixed together. Sales, margins, salaries and customer details all sit in the same ERP. Opening up the whole system is almost never the right answer.
- Exports escape control. A spreadsheet sent by email stays in the recipient's mailbox, even after that person moves to another role.
- Questions change every week. Fixed reports answer what was anticipated. When a new question comes up, it goes back to whoever has full access.
- Nobody knows where a figure came from. Two different values for the same thing turn up at the management meeting, and it is hard to tell who produced them and how.
How do you design a data access matrix?
A data access matrix is a table that crosses the company's data areas with the profiles of the people who query them and states, for each combination, whether access is allowed. It is a simple document, but it forces the decisions that usually go unmade.
- List the data areas. Sales, purchasing, stock, treasury, human resources, customers. For each area, identify the tables or files where the information is held.
- Classify sensitivity. For example general, internal and restricted. Salaries and margins by customer are usually restricted.
- Define profiles by role, not by person. Management, sales, finance, operations. When someone changes role, they change profile, and the rules follow them.
- Fill in the matrix. For each profile and each area, decide whether there is access. When in doubt, start closed and open up when there is a specific request.
- Review the matrix regularly. Once a quarter, or whenever a new data source is added.
Imagine a distribution company with four profiles. Its matrix could look like this.
| Data area | Management | Sales | Finance | Operations |
|---|---|---|---|---|
| Sales by customer and by product | Yes | Yes | Yes | No |
| Margins | Yes | No | Yes | No |
| Stock and orders | Yes | Yes | No | Yes |
| Treasury and payments | Yes | No | Yes | No |
| Salaries | Yes | No | No | No |
This example controls access by table, in other words by data area. Some tools can also filter by row, so that each salesperson sees only their own customers. That is a different level of detail, and it is worth knowing which of the two the chosen tool applies.
Which user profiles make sense?
Beyond what each person can see, it is worth deciding what each person can do. Three user profiles cover most small and mid-sized businesses.
- Administrator. Connects the data sources and decides who has access to what. This should be a small group.
- Analyst. Asks the data new questions, prepares reports and shares them. This is the profile for people who need to explore.
- Viewer. Opens reports and dashboards that are already prepared, without asking new questions. This is the profile for people who only need to keep track.
The two dimensions work together. A sales analyst can ask whatever they like, but only about the tables the matrix opens to them.
What changes when the team asks the data in natural language?
With a conversational analytics tool, the person asking simply writes the question and the tool turns it into a database query. That opens the data to far more people, which is exactly why access rules matter even more.
- Rules apply before the answer. A question about a table the profile does not cover should be refused, not answered with the data hidden afterwards.
- The refusal must give nothing away. The refusal message should not allow anyone to guess values or names from the restricted information.
- Every question is logged. Who asked, against which source, which query ran and what the outcome was. That log is what tells you where a figure came from.
- The query can be inspected. Whoever receives the answer should be able to open the query that produced it and check what was measured.
We covered that last point in how to check an AI's answers about company data.
Which criteria should you use to choose a tool?
These criteria help you judge whether a tool respects the access matrix in day-to-day use, and not only in the demonstration.
- Access defined by profile and by table. Not just an all-or-nothing switch.
- Immediate refusal outside scope. Ask to see what happens when someone asks about an area they cannot query.
- Separate user profiles. Those who administer, those who analyse and those who only view.
- A log of every question. With who asked, the source, the query and the outcome, and a clear answer on whether the data returned is stored.
- Where the platform runs. On the company's infrastructure or the supplier's, and where the artificial intelligence model is hosted.
- It connects to what already exists. Without copying the data somewhere else, which would create yet another copy to protect.
How does EngiAnalytics control access to data?
In EngiAnalytics, the Engibots conversational data analytics platform, access profiles define, table by table, what each person can query. A question outside that scope is refused immediately, without exposing the restricted information.
There are three user profiles, Administrator, Analyst and Viewer, each with its own capabilities. Analysts ask in natural language and get the answer right away, while read-only users open the reports and dashboards already saved. Every question is logged, with who asked, the source, the query run, the number of rows returned, the duration and the outcome, and the data returned is not stored. The SQL query behind each answer can be opened and copied.
EngiAnalytics connects to MySQL and PostgreSQL databases, including ERP and CRM databases running on those engines, and to CSV and Excel files, without migration or system replacement. The platform can run on the organisation's infrastructure or on Engibots' infrastructure and, when security requirements call for it, the artificial intelligence model can also be hosted on the organisation's infrastructure.
A good place to start is to draw up the matrix for three data areas and two profiles, try it for a month and only then extend it. The team gains the freedom to ask, and management knows exactly who sees what.
Frequently asked questions
What is a data access matrix?
It is a table that crosses the company's data areas with the profiles of the people who query them and states, for each combination, whether access is allowed. It lets you make access decisions once and in writing, rather than case by case.
Is it better to grant access by person or by role?
By role. Profiles defined by role keep up with changes in the team, and when someone changes role you only need to change their profile.
What is the difference between table-level and row-level access control?
Table-level control decides which data areas each profile can query, for example sales yes and salaries no. Row-level control decides which records in a table each person sees, for example only their own customers. They are different levels, and it is worth confirming which one the tool applies.
What should happen when someone asks about data they cannot access?
The question should be refused immediately, without showing or hinting at the restricted information, and the request should be logged.
Does EngiAnalytics store the data returned in its answers?
No. Every question is logged, with who asked, the source, the query run, the number of rows returned, the duration and the outcome, but the data returned is not stored.