IT can run the workflow, but business owners should decide whether access still fits the job. That accountability split matters because technical role names rarely describe business authority clearly enough for safe approval. Ownership belongs with the people who understand the process risk, while IT provides the control record.
Who should own access certification for business applications like D365 BC?
access certification works best when the business owns the decision and IT owns the workflow. Business leaders understand whether a role still matches the person’s job, while IT can supply the evidence, route the review, and keep the control auditable. For applications like D365 BC, that split is what prevents rubber-stamping and stale access.
Why business ownership matters more than technical role labels
Application roles often look precise from an IT perspective but still fail to reflect actual business authority. A role name can describe a system function, not the business process, approval chain, or segregation-of-duties risk behind it. The certifier therefore needs process context, not just entitlement names, to judge whether access remains appropriate.
That is especially important when the application supports finance, procurement, order management, or customer operations. In those environments, the wrong approver can keep access alive because they know the employee, not the job. Business ownership keeps the certification tied to operational need, while IT preserves consistency in the control record and evidence trail.
IAM and IGA Basics is the best place to anchor that split between authorization judgment and governance execution. When the review process is owned by the business, access decisions stay connected to the actual duty being performed rather than the shape of the application role.
How to run certification without turning it into a compliance checkbox
Access certification should be designed around accountable reviewers, clear scope, and enough context to make a real decision. The reviewer should see the application, the role or entitlement, the person’s function, and any risk signal that changes the default answer. If the reviewer cannot tell what business authority the access confers, the process is not giving them enough information.
Access Reviews and Certification Guide is useful here because it focuses on reducing volume and improving context, which is exactly what certification campaigns need when they start to feel mechanical. The goal is not to ask business users to understand system internals; it is to present access in business terms they can actually approve or remove.
Role Mining and Role Design Guide matters whenever reviewers are confronted with technical roles that are too broad, too fragmented, or too opaque. If a role model cannot be explained in business language, certification will drift into guesswork and the review loses value.
Where ownership breaks down in practice
The common failure is assigning certification to the help desk, the IAM team, or the application admin simply because they can operate the tool. Those teams are necessary for execution, but they usually do not own the business risk of excessive access. When that boundary blurs, reviews become fast but shallow, and risky access survives because no one with process accountability is making the call.
Another failure is treating every app as if one reviewer model fits all. Some D365 BC access should be certified by line managers, while privileged or sensitive business roles may need process owners, application owners, or control owners. The right owner is the person who can answer, “Does this access still fit the job and the risk?”
Segregation of Duties (SoD) Guide is relevant because certification is often where SoD conflicts are discovered, tolerated, or accidentally approved. If the reviewer cannot recognise conflicting authority, the review becomes a formality instead of a control.
Risk and Threat Considerations
When certification is owned by the wrong team, excessive access tends to persist, especially in roles that are infrequently challenged or poorly understood. That creates avoidable exposure for fraud, unauthorized changes, and privilege creep, and it also weakens the value of downstream audit evidence because the approval no longer reflects informed business judgment.
Failure mechanism: Technical reviewers approve access based on role names, peer familiarity, or workflow speed instead of process ownership and actual job need. Over time, that turns certification into rubber-stamping and leaves high-risk access unchallenged.
Impact: Business applications retain access that no longer matches duty, increasing the chance of misuse, control failure, and audit findings, especially where SoD or financial authority is involved.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access certification is a review activity within account governance. |
| AC-6 — Least Privilege | Certification should confirm access still matches minimum business need. | |
| AU-6 — Audit Review, Analysis, and Reporting | Certification needs evidence trails showing who approved or removed access. | |
| Recommendation — Require periodic account reviews and remove unnecessary access promptly. Re-certify entitlements against least-privilege business need and revoke excess access. Retain review evidence and monitor approvals for anomalous or rubber-stamped decisions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Business access certification is a core access-control governance activity. |
| A.5.18 — Access rights | Periodic access recertification governs whether rights remain appropriate. | |
| Recommendation — Define access approval authority and review frequency for business applications. Review, adjust, and revoke access rights when business need changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certification is part of governing and reviewing application accounts and entitlements. |
| Recommendation — Review application access routinely and remove accounts that no longer have a business need. | ||
Practitioner Guidance
What to prioritise: Put business ownership on the approval decision, not just on the report distribution list. IT should assemble the campaign, normalize entitlements, and retain evidence, but the decision to keep or remove access should sit with someone who understands the process.
What to verify: For each reviewer, confirm they can speak to the business function behind the entitlement, not just the user’s manager title. If they cannot explain why the access is needed, the review should be escalated or reassigned.
Common mistake: Treating “manager approves all access” as universally sufficient. For business applications, especially ERP-style systems, process ownership and role authority often matter more than reporting lines.
Practitioner takeaway: The safest operating model is business-owned decisioning with IT-managed execution, because certification only works when the person approving access can judge the business risk behind it.
Related resources from NHI Mgmt Group
- What is the difference between protecting applications and protecting access?
- Who should own access governance when business applications affect audit and licensing?
- Why do manual access certification campaigns fail in business applications?
- Who should own access certification decisions when responsibility spans business and IT teams?