The BC Access Review Problem: Why It Has Not Been Solved Yet

There is a specific kind of Friday afternoon that finance and operations leaders in Business Central environments know well. It begins with an email from the external auditor. Attached is a list of questions about user access, which team members have access to which modules, which permissions have been granted that do not match current roles, which former employees still have active access to the production environment.

The team has five business days to respond. Nobody is entirely sure where to start.

This scenario is not the result of negligence. It is the result of how access management works in practice across the mid-market, and why the BC ecosystem has not yet produced a satisfying answer to it.

How access sprawl accumulates

Access in Business Central accumulates through entirely normal operational activity. A team member needs temporary access to a module to cover for a colleague on leave, the access is granted, the colleague returns, the temporary access is never removed. A new business process is introduced that requires permissions across multiple modules, the permissions are configured, the process is retired six months later, the permissions remain. A finance team member is promoted into a role with broader system access, their previous access profile is extended rather than replaced, because replacing it would take time and the transition is urgent.

None of these individual decisions is unreasonable. Each one is a pragmatic response to an operational need. Together, across an organisation running Business Central for three or more years with a team of more than fifty users, they produce an access environment that bears limited resemblance to the access policy the organisation intended to operate under.

This is access sprawl. It is not a security failure. It is an administrative reality.

Why the quarterly review does not solve it

The standard response to access sprawl is the periodic access review. Once a quarter, or once a year, the IT administrator exports a user permission report from Business Central, shares it with department heads, and asks them to confirm which access assignments are still appropriate.

The problems with this process are structural rather than operational. The exported report shows what access exists. It does not show how the access came to exist, when it was last used, whether the usage pattern is consistent with the user's role, or which access assignments represent a segregation of duties conflict. The department head reviewing the report typically does not have enough context to make confident decisions about access they did not configure, in a system they do not administer, for permissions they do not fully understand.

The result is a review that confirms most access as appropriate by default — because the effort required to investigate each assignment in detail exceeds the time available for the review. The audit request is answered. The access environment is not meaningfully changed.

The segregation of duties problem

Layered on top of the access sprawl problem is the segregation of duties question. In a well-governed finance environment, the person who creates a purchase order should not also be the person who approves it. The person who processes a payment should not also be the person who reconciles the bank account. These are basic internal controls, but identifying where SoD conflicts exist in a Business Central environment with complex permission structures and multiple overlapping roles requires analysis that goes well beyond a standard permission export.

Most mid-market organisations do not have the tooling to run this analysis efficiently. The alternatives are expensive external audits, manual spreadsheet-based analysis that is outdated the moment it is completed, or the assumption that SoD conflicts, if they exist, have not yet been exploited.

None of these is a satisfying answer to an auditor who asks the question on a Friday afternoon.

Why this problem has not been solved

The access review problem in Business Central has persisted for a straightforward reason: solving it properly requires bringing together data from multiple sources — user permissions, role assignments, activity telemetry, SoD rule definitions — and producing output that is structured enough to be actionable, specific enough to be credible, and repeatable enough to be useful more than once a year.

The standard BC permission export does not do this. The typical third-party GRC tools in the market are built for SAP or Oracle environments and do not map cleanly onto BC's permission architecture. And the manual process, export, format, review, document, is time-consuming enough that most organisations do it as infrequently as they can justify.

The gap is real and it is consistent. BC partners working with finance-heavy clients encounter it regularly. Finance controllers who have lived through an access-related audit finding carry it as a specific anxiety. And external auditors, who see the same patterns across multiple client environments, have come to expect it.

What a solved version of this problem looks like

A solved access review in Business Central would produce, on a regular and repeatable basis, a structured view of the current access environment, showing not just what access exists, but how it came to exist, whether it is consistent with the user's current role, what activity it has been associated with, and where SoD conflicts are present or emerging.

It would be produced without requiring a significant manual effort from the IT administrator. It would be formatted in a way that allows department heads and finance controllers to make genuine decisions rather than default confirmations. And it would be available at a frequency that makes it useful as an operational tool rather than a compliance exercise.

That is the standard the problem requires. The ecosystem has not yet produced it at scale for Business Central. The auditors are still arriving on Fridays.