Your Auditor Flagged Access Controls. Here Is the SOX Remediation Plan.

SOX remediation starts the day the finding is written, not the day you finish understanding it. The finding is dated, the remediation date is already on a committee calendar, and the problem in front of you is not comprehension. It is producing a control that holds and the evidence that proves it ran, inside an estate that has to keep running while you fix it.

Quick answer: SOX remediation on the Microsoft stack is a four-part sequence rather than a product decision. Scope exactly which systems and identities the finding covers, rebuild the control so access is granted and removed by a repeatable process rather than by request, run the review on a fixed cadence with named approvers, and capture evidence automatically so the next audit reads a log rather than a reconstruction. Entra ID Governance supplies the mechanism; the program discipline is what closes the finding.

Key takeaways

• The finding is a statement about control design and operation, not about tooling. Buying a governance product does not close it. Running a control that produces its own evidence does.
• Scope comes before remediation. SOX scope and Microsoft tenancy boundaries rarely line up, and remediating the wrong population wastes the window you have.
• The control shape that survives audit is joiner, mover, leaver: access granted by role at entry, adjusted at every move, and removed at exit by a process rather than by someone remembering.
• Privileged access is its own control, reviewed on its own cadence. Standing administrative rights are the single most common cause of a repeat finding.
• Reconstructed evidence fails. If proving the control ran requires someone to assemble screenshots after the fact, the auditor is looking at an artifact of the audit, not an artifact of the control.
• Remediating in place is often correct, and sometimes it is not. Knowing which situation you are in before you commit is the difference between one remediation cycle and two.

What the Finding Actually Says: SOX IT General Controls and What Auditors Accept as Closed

Audit language compresses meaning, and that compression is where remediation programs go wrong. A finding that reads “user access was not reviewed on a periodic basis for in-scope financial systems” is not a request to run a review. It is a statement that a control which should have been operating was not operating, or was operating without evidence, during the period under audit. Those are different defects with different fixes, and the remediation plan has to name which one it is answering.

SOX IT general controls sit underneath the financial statement assertions rather than beside them. The logic an auditor follows runs downhill: if access to the system that produces a financial number is not controlled, then the number itself is not reliable, no matter how correct it looks. That is why access findings escalate the way they do, and why “we tightened permissions” does not close them. The auditor is not asking whether access is currently correct. They are asking whether a control exists that makes access reliably correct, and whether that control demonstrably operated across the period.

So what is the SOX access review, in the terms the finding is using? It is a periodic recertification: a named owner examines who currently holds access to an in-scope system, decides for each identity whether that access is still warranted, and the decisions are acted on and recorded. What is the purpose of the user access review, then, is a question with a narrower answer than most teams give. Its purpose is not to find bad actors. It is to prove, on a repeating schedule, that access matches current business need, and to catch the drift that accumulates silently between reviews.

What auditors accept as closed comes down to four properties, and they are worth stating in the reader’s own words before any remediation work starts. The control is defined, meaning someone can produce a written statement of who reviews what, on what cadence, and against what criteria. The control is assigned, meaning a named person owns each decision rather than a distribution list. The control operated, meaning it ran on the stated cadence during the period, not once in a panic before fieldwork. And the control produced evidence at the time it ran, meaning the proof is a byproduct of the process rather than an assignment given to someone afterward.

Miss any one of those and the finding stays open even when the underlying access is clean. This is the part that surprises delivery owners most often: a tenant can be in genuinely good shape and still fail, because the control was undocumented and left no audit trail an outsider can follow. Remediation is therefore a program question rather than a configuration question, and it runs in four phases (scope, rebuild, review, evidence) that the rest of this page walks in order. The configuration matters, but it is the last mile, and teams that start there tend to arrive at fieldwork with a tidy estate and nothing to show for it.

Scoping a SOX Access Review: Which Systems, Which Identities, Which Period

Scope is the cheapest place to save the program and the most common place to lose it. Before anything is rebuilt, three questions need documented answers, because each one changes what the remediation has to cover.

Which systems are in scope. SOX scope follows the flow of financial data, so it includes the systems of record for financial reporting and everything with a path into them. In a Microsoft estate that usually means more than the ERP: the identity layer that grants access to it, the SharePoint sites where supporting schedules and reconciliations live, the Power Platform apps and flows that move data between systems, and any integration account that writes to a financial system on a schedule. Teams routinely scope the ERP and miss the automation feeding it, which is exactly the gap an auditor probes second.

Which identities are in scope. A user access review Microsoft 365 teams scope from the employee directory alone is an incomplete review, because employee accounts are the easy population. The ones that generate findings are the others: service accounts and application registrations that hold standing access, external and guest identities that were invited for a project and never removed, shared or generic accounts that cannot be attributed to a person, and administrative roles held by people who no longer need them. Any identity that can reach an in-scope system is in scope, whether or not it belongs to a human, and an inventory that only counts people is an incomplete inventory.

Which period is in scope. The finding names a period, and the remediation has to address both the period under audit and the period going forward. Those are different obligations. For the period under audit, the honest answer is often that the control did not operate and no amount of present-tense work changes that; what remediation can do is establish the control and demonstrate it operating for a meaningful stretch before the next assessment. Committing to retroactive proof that does not exist is how a remediation program acquires a second finding.

Where SOX scope and Microsoft tenancy boundaries fail to line up is worth naming plainly, because it is common and it derails schedules. Tenancy is drawn around organizations, subsidiaries, and acquisitions; SOX scope is drawn around financial materiality. One tenant frequently contains both in-scope and out-of-scope entities, and a single security group can span both. When that happens, group membership is no longer a usable scoping instrument, and the remediation needs identity-level scoping with the in-scope population explicitly enumerated and maintained. Discovering that during fieldwork rather than during scoping is the difference between an inconvenience and a missed remediation date.

If the scoping exercise is where your team runs out of hands rather than knowledge, that is a reasonable place to bring in borrowed expertise. You can hire US-based senior Microsoft integration developers who have scoped this population inside regulated Microsoft estates before and know where the automation hides.

Rebuilding the Control: From Request-Based Access to a Governed SOX Access Review

Most access findings trace to the same root: access is granted by request and removed by exception. Someone asks, someone approves, the entitlement persists, and removal depends on a person remembering at the moment a role changes. That model can produce correct access on any given day and still fail every audit, because correctness is accidental rather than produced by a process.

A global professional services firm brought i3solutions in to modernize this exact layer, replacing request-driven access with governed identity lifecycle management at enterprise scale, and the engagement is documented in Related Reading below.

The control shape that survives is joiner, mover, leaver. At joining, access is granted by role rather than by ticket, so the entitlement set is derived from a definition an auditor can inspect. At every move, the previous role’s access is removed as deliberately as the new role’s access is added, which is where most estates leak: promotions and transfers accumulate entitlements that nobody ever revokes, and the resulting accounts are the ones that fail a review five years later. At leaving, deprovisioning is automatic and tied to the authoritative source for employment status rather than to a manual notification. Each of the three transitions is a separate control point, and auditors test them separately.

Privileged access is its own case and deserves its own cadence. What are some of the risks of privileged access, stated concretely rather than abstractly? A standing administrator can grant themselves access to any in-scope financial system without leaving a request behind, can alter or delete the logs that would show they did, and can act as more than one person in a process that was designed to require two. Each of those breaks a different control: authorization, evidence integrity, and segregation of duties. Standing administrative rights in an identity system, a financial application, or the tenant itself are the highest-value target in the estate and the most common source of a repeat finding. The defensible pattern is that privilege is requested for a window, approved by a named person, used, and then removed automatically when the window closes, with the entire cycle logged. Reviewing privileged roles on the same annual rhythm as general user access is a design decision an auditor will question, and reasonably so.

Microsoft supplies the mechanism for all of this natively. Microsoft Entra ID Governance provides the identity governance layer, with access reviews as the recertification instrument and entitlement management as the way role-based access packages are defined and assigned rather than assembled by hand. The product scope, the licensing questions, and the audit-defensible implementation detail are covered in depth on our Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation page, which is the right next stop when the program moves from design into configuration. This page deliberately stops at the mechanism, because the part that closes findings is not the configuration.

What closes the finding is the program discipline wrapped around the mechanism: the written control definition, the named approvers, the cadence, and the escalation path when an approver does not act. A review that nobody completes is not a control, and an access review campaign that expires with half its decisions outstanding produces a worse audit position than no campaign at all, because it documents that the control was designed and then did not operate.

Automated validation at this scale is well-trodden ground rather than a novelty. A federal home loan bank network engaged i3solutions to implement automated validation against mortgage-compliance rules across 7,700 institutions, and the pattern is the same one that applies here: encode the rule once, apply it continuously, and let the system rather than a person carry the burden of consistency. That work is documented in Empowering Mortgage Acquisition Through Digital Innovation.

The SOX Audit Evidence Problem: Proving the Control Ran

The evidence question is where remediation programs that look finished turn out not to be. A control that operates correctly and cannot prove it operated is, from the auditor’s position, indistinguishable from a control that did not operate. That is not auditor pedantry. It is the only position available to someone whose job is to form an opinion from observable artifacts.

What an auditor needs to see is narrower and more specific than most teams expect. They need the population the review covered, so they can test whether it matched the in-scope definition. They need the decisions, attributed to named approvers with dates. They need proof that the decisions were acted on, which means the removal actually happened and can be shown to have happened. They need the exceptions and what was done about them, because a review with zero exceptions across a large population invites more scrutiny than one with documented exceptions and resolutions. And they need all of it for each occurrence in the period, not a single specimen.

Reconstructed evidence fails, and it is worth being precise about why, because the failure is not about honesty. When evidence is assembled after the fact from screenshots, exported spreadsheets, and email threads, the artifact proves that someone looked at the system on the day they built the packet. It does not prove the control operated on the date it was supposed to operate. Auditors are trained to notice the difference, and metadata makes it visible whether anyone intends it to be. The consequence is that a team can do the remediation work honestly, in good faith, and still fail the evidence test because the proof was produced by the audit rather than by the control.

The design answer is that evidence capture is built in rather than assembled later. The review campaign records its own population, decisions, approvers, and timestamps as it runs. The deprovisioning action leaves a log entry tied to the decision that caused it. The exception path writes its own record. When this is done properly, preparing for the next audit stops being a project and becomes a query, which is the single most useful thing a remediation program can leave behind.

This is a solved problem, and at considerable scale. A federal defense program brought i3solutions in to replace a weeks-long manual consolidation process across 41 subcontracting agencies with real-time automated compliance and audit reporting, documented in Executive Information System Streamlines Project Management and Reporting for the Army. The applicable lesson for a SOX remediation is not the scale. It is that the reporting stopped being an assembly exercise, which is exactly the transition an access-control finding is asking you to make. That engagement ran under Enterprise Delivery Assurance, the standard that exists so work of this kind lands on-time, in-scope, and in-production rather than becoming an open-ended program.

If you would rather talk through your specific finding than read another framework, start a conversation with our team and bring the finding language with you. The wording tells an experienced reader most of what the remediation has to cover.

Remediate In Place Versus Rebuild: Two SOX Remediation Paths, and When Each Wins

The honest comparison matters here, because the answer is genuinely situational and the wrong choice costs a full cycle. Remediating in place means keeping the existing access model and fixing what the finding named: define the control, assign approvers, run the reviews, capture the evidence. Rebuilding means changing the underlying model, typically moving from directly assigned permissions and ad hoc groups to role-based access packages with defined entitlement sets.

In-place remediation wins more often than program-rescue instincts suggest. It wins when the existing group structure is comprehensible, meaning someone can explain what each group grants and why it exists. It wins when the in-scope population is bounded and stable. It wins when the finding is genuinely about operation rather than design, which is the case when the access itself is defensible and what was missing was the review and its evidence. And it wins decisively when the remediation date is close, because a rebuild that is half-finished at the deadline is worse than a modest control that operated on schedule.

The rebuild becomes necessary when the model itself is what fails the test. The signals are recognizable. Nobody can state what a group grants without opening it. Entitlements were assigned directly to individuals at a scale that makes review meaningless, because a reviewer confronted with thousands of individual assignments will approve them in bulk and produce evidence that proves nothing. Group membership spans in-scope and out-of-scope entities, so scoping cannot be expressed in the model’s own terms. Or the same finding has appeared before, which is the clearest signal available: a repeat finding after an in-place remediation is evidence that the model, not the operation, is the defect.

There is a middle path worth naming because it is frequently the right one. Remediate in place for the current audit cycle to close the finding on schedule, and run the model rebuild as a separate program with its own timeline, sequenced so the new model is operating and evidenced before the following assessment. This is more work in total and it is often the lower-risk sequence, because it separates the dated obligation from the structural one. The failure mode to avoid is the opposite pattern: starting a rebuild because it is the more satisfying engineering answer, then discovering at the deadline that the finding is still open and the new model is not yet operating either.

Whichever path applies, the decision belongs at the start and in writing. An auditor who sees a documented decision with stated reasoning reads a program under control. One who sees a remediation that changed direction midway reads something else.

What a Defensible SOX Remediation Plan Looks Like at the Next Audit

Exit criteria turn a remediation from an anxiety into a status. Hold your own program against these, and the answer to “are we ready” stops being a judgment call.

The scope is documented and current: the in-scope systems, the in-scope identities including service accounts and external identities, and the basis on which each was included. The control is defined in writing, with cadence, criteria, and the specific decision each reviewer is being asked to make. Every review has a named owner rather than a group mailbox, and each named owner has an escalation path with a deadline. The control has operated on its stated cadence for a demonstrable stretch of the period rather than once. Evidence is generated by the process at the time it runs, covering population, decisions, approvers, dates, resulting actions, and exceptions with their resolutions. Privileged access is governed separately, with time-bound elevation and its own review cadence. Deprovisioning is tied to the authoritative source for employment status rather than to a notification someone has to send. And the exceptions from the last cycle have documented resolutions, because unresolved exceptions carried forward are the fastest route to a repeat finding.

Add one more that is not a control but predicts whether the others survive: someone owns the program after the remediation closes. Remediation programs decay in a specific way. The reviews run on schedule during the year the finding was open, then the owner changes roles, the cadence slips, and two years later the same finding appears with the same root cause. Naming the ongoing owner and putting the cadence somewhere durable is the cheapest insurance in the entire program.

For the enterprise deciding whether to run this internally or bring help, the split is usually about which knowledge is missing rather than about capacity. Your team knows the estate: which system produces which number, which integration account nobody dares touch, which subsidiary sits inside the wrong tenant. What an outside partner brings is the shape of the finished thing, which auditors accept, which artifacts fail, and where the remediation that looks complete has a hole in it. When both kinds of knowledge are present the program tends to close in one cycle. When either is missing, it tends to take two.

If a dated finding is sitting on your desk and you want the remediation scoped by people who have closed these inside Microsoft estates, hire US-based senior Microsoft integration developers and bring the auditor’s exact wording to the first conversation.

About i3solutions

i3solutions has been a Microsoft partner since 1997 and has delivered 600+ implementations across aerospace and defense, financial services, and health sciences. Remediation and identity governance engagements run under Enterprise Delivery Assurance, the delivery standard that exists so the work lands on-time, in-scope, and in-production.

Related Reading

• Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation
• Microsoft 365 Access and Permissions: The Complete Governance Guide

Frequently Asked Questions

Who is responsible for SOX compliance?

Responsibility is layered, and the layers matter because remediation stalls when they are confused. Under Section 302 the chief executive and chief financial officer personally certify the financial statements and the effectiveness of the controls behind them, which is why an access finding travels upward quickly. Management owns the design and operation of the controls themselves. For an access control in a Microsoft estate, that ownership lands on the IT function that operates the identity layer, usually the VP of IT or IT Director, working with the business owners who make the actual keep-or-remove decisions. Internal audit tests whether the control works and reports independently. The external auditor forms the opinion and writes the finding. Nobody in that chain can delegate their part to the tooling, which is the practical point: a governance product can run a campaign, but it cannot own a control.

Is a user access review a detective control?

Primarily yes. A user access review detects inappropriate access that already exists rather than preventing it from being granted, which places it in the detective category in most control frameworks. The nuance worth understanding is that it rarely operates alone. Paired with role-based provisioning and automated deprovisioning, which are preventive controls, the review becomes the backstop that catches what the preventive controls missed. Auditors read the combination, not the review in isolation. A detective control operating without preventive controls beneath it signals an estate where access is fixed after the fact, and that pattern invites deeper testing even when the review itself is clean.

How often should user access be reviewed?

SOX does not name a frequency, which surprises teams looking for a number to comply with. The cadence is set by your own control definition and has to be defensible against the risk of the system in scope. In practice, general user access to in-scope financial systems is commonly reviewed quarterly or semi-annually, privileged and administrative access on a tighter cycle because the risk per identity is higher, and both supplemented by event-driven reviews triggered by role changes, transfers, and departures rather than waiting for the next scheduled cycle. The two things auditors test are whether the stated cadence is reasonable for the risk and whether it actually ran on that cadence. A quarterly cadence documented and missed is a worse position than an annual cadence documented and met.

What are the risks of no user access review?

The first risk is the one that brought you here: the control gap itself becomes an audit finding, with a remediation date and management attention attached. Underneath that sit the exposures the review exists to catch. Access accumulates with every promotion and transfer until individuals hold combinations of entitlements that break segregation of duties, which means one person can both initiate and approve a financial transaction. Departed employees and closed contractor engagements retain live access that nobody revoked. Service accounts hold standing privileges nobody has examined since the integration was built. And because none of this is being examined, the organization cannot state who can reach its financial systems, which is the condition that turns a single set of compromised credentials into a material event rather than a contained one.

What are the 4 SOX controls?

In an IT audit context, the four commonly refer to the IT general control domains that SOX testing covers: access to programs and data, program changes, program development, and computer operations. Access to programs and data governs who can reach systems and information, and it is where access-control findings sit. Program changes governs how modifications to production systems are authorized, tested, and approved. Program development governs how new systems are built and moved into production. Computer operations governs the running of the environment, including job scheduling, backup, and incident handling. The four are tested together because a weakness in one undermines the others. Strong access controls mean less when an unreviewed change process lets someone alter the system that enforces them, which is why an access finding often arrives alongside questions about the other three.

By Scott Singleton, Managing Consultant. Scott Singleton has spent more than 19 years at i3solutions and more than 30 years designing, developing, migrating, and implementing enterprise technology solutions. His expertise is grounded in SharePoint architecture, large-scale migration, custom application development, workflow modernization, technical training, and hands-on delivery across Microsoft platforms, including SharePoint, SPFx, Power Apps, Power Automate, Power BI, and enterprise database systems. LinkedIn