SOX compliance in Business Central

What is SOX compliance?

SOX compliance means meeting the Sarbanes-Oxley Act of 2002, the US law that sets rules for the financial reporting of public companies. Section 404 is the part that affects IT.

Section 404 requires a public company to include management's own assessment of its internal control over financial reporting in the annual report.

For larger companies, the external auditor adds an attestation on that assessment.

The SEC does not prescribe how to build those controls. It points to the COSO internal control framework as guidance.

A large part of the testing lands in the ERP system, because that is where transactions are created, approved and posted.

Does SOX apply to your company?

By law, SOX applies to companies whose shares are publicly traded in the US. Smaller public companies have been exempted from the auditor's attestation, but management still has to assess its own controls.

Private companies have no legal SOX obligation. Many still end up working to the same standard, because the same controls come up from other directions:

The external auditor wants to rely on the system instead of testing every transaction.
A lender or investor asks for evidence that financial processes are under control.
The company is preparing for an IPO or a sale and wants the controls in place before due diligence starts.

Whichever applies, the questions about Business Central are largely the same.

What auditors test in Business Central

An auditor looks at two kinds of control. IT general controls cover how access and changes are managed. Application controls are the checks built into the process itself, such as an approval before a payment goes out.

In Business Central, expect questions like these:

Who can do what, and does that match their job?
Can one person both start and complete a sensitive transaction, such as creating a vendor and paying it?
How is access requested, approved and revoked when someone leaves or changes roles?
Who changed a permission set, and did anyone look at that change?
Who can change sensitive master data, such as a vendor's bank account or a customer's credit limit?

For the basics of how permission sets, security groups and effective permissions work, see our page on Business Central permissions.

Where standard Business Central falls short

Business Central has a fair number of control features of its own. Before you buy anything, check what is already there.

What standard Business Central gives you

Permissions are assigned through permission sets and security groups.

The Effective Permissions page shows what a user can actually do after all sets are combined. To view it for other users, you need the SECURITY or SUPER permission set.

The change log records changes to the tables and fields you select. Field monitoring sends an email when someone changes a sensitive field, Microsoft's own example being the company's IBAN.

Ready-made approval workflows exist for purchase and sales documents, payment journals, customer cards and item cards.

Where it stops

Those features help, but they leave gaps that show up during an audit:

Effective Permissions shows a user's access but does not compare it with conflict rules. A risky combination of permission sets goes unnoticed until someone checks by hand.
There is no place to record that access was reviewed, by whom, and what they concluded.
Granting a permission set is not on the list of ready-made approval workflows.
The built-in log covers permission sets you created yourself, not system permission sets changed by an app update.
Permissions work per table. Anyone allowed to edit a vendor can edit every field on it, bank details included.
The change log is switched off while Business Central is upgraded.

How to implement SOX compliance in Business Central

1. Map the financial processes

Start with the processes that feed the financial statements, such as purchase to pay, order to cash and the period-end close. For each one, write down which Business Central pages, journals and master data it touches.

2. Design roles per job

Build roles that match a job, such as accounts payable clerk or purchasing manager, and assign people to those roles. If every new hire gets a copy of a colleague's permissions, access grows with each hire.

3. Define your segregation of duties rules

Write down which combinations no single person may hold. Creating vendors and posting payments is a common example. Our guide to segregation of duties in Business Central includes a conflict matrix you can start from.

4. Protect sensitive fields

Decide which fields need extra control: vendor bank accounts, credit limits, posting groups. Field monitoring tells you after the fact. To stop the change itself, you need field-level security.

5. Control how access is granted and revoked

Every new permission should go through a request and an approval that you can show later.

Plan the revoke at the same time: access that stays active after someone leaves is easy to miss, as our article on employee offboarding explains.

6. Review access on a schedule

Run an analysis of critical permissions and conflicts every quarter, and after major changes to roles. Record the outcome of each finding, including the risks you accept and why.

7. Log changes and review them

Log changes to permissions and to critical data, and have someone other than the person who made the change review them. The Dynamics 365 audit trail page covers what to track.

The evidence your auditor will ask for

A screenshot of today's permission sets proves little. An auditor wants to see what changed over the period, who changed it, and that someone looked at it.

The auditor asks	Evidence	Where
Who can approve payments or change vendors?	Analysis of critical permissions per user, role and permission set	Authorization Box
Are there SoD conflicts, and what did you decide?	Conflict results marked Agreed or Disagreed, with comments, review history and Excel export	Authorization Box
Who granted this access, and who approved it?	The authorization request with its approvers	Authorization Box
Who changed this permission set, and when?	Every change with user, time and the permissions before and after, app updates included	Advanced Permissions Management
Did anyone review those changes?	Completed reviews with each change marked Reviewed or Flagged	Advanced Permissions Management
Which users can change this field?	The security rule and its effect per user	Field Security
Does the system enforce this data rule?	The validation, its results and the records that break it	Field Validation

Make the review a routine. A review completed every month or quarter, with comments, gives your auditor more to go on than one big review in the week before the audit.

Tell your auditor about the limits as well.

A review records a decision after the fact, because a permission change is already live by the time someone reviews it. Saying so up front makes the rest of your evidence more credible.

The full list of auditor questions and where to find each answer is in our compliance evidence overview.

How 2-Controlware supports SOX compliance

2-Controlware software is designed by IT auditors. It adds the controls and the evidence that standard Business Central leaves to you. The assessment itself stays with management and the external auditor.

Authorization Box

Authorization Box manages permissions through organization roles, with an optional approval step on each request.

Authorization Monitoring analyzes critical permissions and SoD conflicts, and records the review of every result.

The Continuous Monitoring module adds alerts when someone gains access to a critical permission, daily, weekly, monthly or straight away.

Compliance apps for Business Central

Advanced Permissions Management logs every change to permission sets, including changes from app updates, and lets you review them period by period.

Field Security locks individual fields, records and actions per permission set. Field Validation enforces data rules as users work and finds existing records that break them.

2-Controlware holds a SOC 2 Type 2 assurance statement covering Authorization Box and the Compliance Essentials apps, received in August 2024.

Frequently asked questions

Is SOX compliance mandatory for private companies?

SOX compliance is not mandatory for private companies, because the law applies to companies publicly traded in the US. Many private Business Central users still build SOX-style controls, since their external auditor, lender or investor asks for the same evidence on access and segregation of duties.

Does Business Central have built-in SOX controls?

Business Central has building blocks for SOX controls: permission sets, security groups, approval workflows, the change log and field monitoring. It does not check permissions against segregation of duties rules or record access reviews. Those parts you set up yourself or add with software such as Authorization Box.

How often should you review user access for SOX?

User access for SOX is reviewed on a fixed schedule. 2-Controlware recommends a quarterly analysis and one after major role changes, or monthly under strict compliance rules. A documented review every quarter gives an auditor more to rely on than a single review right before the audit.

What evidence does an auditor want for Business Central access?

An auditor wants evidence that access in Business Central is controlled over the whole period. That means an analysis of critical permissions and SoD conflicts, the decisions taken on each finding, the approvals behind granted access, and a log of permission changes with proof that someone reviewed them.

Can 2-Controlware make my company SOX compliant?

2-Controlware cannot make a company SOX compliant on its own, because compliance is assessed by management and the external auditor. The software provides the access controls and the evidence: SoD analysis, approved authorization requests, reviewed permission changes and field-level security in Business Central.

Does SOX require segregation of duties?

SOX requires segregation of duties in practice, because Section 404 asks for effective internal control over financial reporting. Auditors test segregation of duties in the ERP as part of that control, including conflicts such as one user who can both create and pay a vendor.