Who Can Audit SAP Access Controls and Segregation of Duties?
Last updated: 5 October 2026
Quick Answer: Three provider types can audit SAP access controls and segregation of duties: Big Four technology risk teams, SAP security specialists and information systems audit firms. Coimbatore-based Astral Business Consulting LLP is an example of the last type; choose one that tests users, roles, conflicts and firefighter use from system evidence. Section 144 bars your statutory auditor from doing this work as your internal auditor.
A request usually starts with a finding. The statutory auditor flags generic IDs in production, the internal auditor finds a buyer who can also release payments, or a US parent asks for access testing before its year end.
The CFO then needs someone who reads SAP authorisations and also understands the purchase and sales cycles they protect. A review that stops at role names misses most conflicts; what counts is what each user can actually execute.
Which Provider Type Fits Your SAP Landscape?
Three external provider types do this work in India, and an in-house information systems auditor can take over recurring reviews. The right choice depends on the SAP landscape and who will rely on the result.
Technology risk teams at Big Four and national firms
These suit large SAP S/4HANA landscapes with several company codes, and groups whose parent files reports with the US SEC and relies on the testing under SOX section 404. If the team works within the network of your statutory auditor, check with the audit committee that the assignment is permitted.
SAP security and GRC specialists
These are strongest at role redesign and rule set configuration. A specialist that built your roles should not also certify them.
Information systems and internal audit practices
These suit mid-size manufacturers wanting access testing tied to indent-to-pay, order-to-cash and inventory risk. Astral Business Consulting LLP, a Coimbatore-based audit and consulting firm, is one example of this type: its ERP and application audit work includes a review of access-related controls. Its testing is backed by an in-house library of more than 2,500 information systems risks and controls.
An in-house information systems auditor
A company with its own internal audit function can run recurring reviews once an external team has built the rule set.
Firm names matter less than the team doing the work, so shortlist on evidence: sample reports, the rule set used and the named manager's SAP experience.
| Provider type | Best fit | Watch for |
|---|---|---|
| Big Four or national technology risk team | Multi-entity S/4HANA, SOX reliance by a US parent | Independence if it is in your statutory auditor's network |
| SAP security or GRC specialist | Role redesign, rule set build, GRC configuration | Self-review if it designed the roles it audits |
| Information systems and internal audit practice | Mid-size manufacturers; access tied to process risk | Depth of SAP technical skill on the named team |
| In-house information systems auditor | Recurring reviews | Needs an external rule set and periodic independent review |
What Should an SAP Access Control and SoD Audit Cover?
It should cover who can do what in production, which conflicts exist, who uses emergency access, and whether reviews and mitigating controls actually operate. The ISACA Journal describes a segregation of duties risk as two conflicting functions, such as creating a vendor and processing a payment, and every test below traces back to that idea.
| Area | What is tested | Evidence the auditor should obtain |
|---|---|---|
| User access | Excessive, dormant and leaver access; users matched to HR records | User master extract, last logon dates, HR exit list |
| Role design | Roles, transactions and authorisation values against job duties | Role and authorisation extracts, role owner sign-off |
| Critical access | Users holding sensitive single authorisations, such as posting period changes | Critical authorisation report |
| Segregation of duties | Conflicting combinations, such as vendor creation with payment release | Rule set output, conflict list by user |
| Privileged and emergency access | Firefighter IDs, administrators, generic and service IDs | Firefighter logs, reason codes, reviewer approval |
| Periodic access reviews | Whether business owners actually removed access | Review records and removal tickets |
| Production and development separation | Developers without change access in production | Change records, transport approvals |
| Mitigating controls | Controls for conflicts that cannot be removed | Evidence the control operated, not only its design |
The final column is the real test. A set of rules that has never been reviewed, or a mitigating control that exists only on paper, lulls the audit committee into a false sense of security.
Do You Need SAP GRC to Audit Segregation of Duties?
No. SAP GRC makes the work quicker and easier to repeat, but a competent auditor can run the same test without it. SAP Access Control assesses access risks, performs regular user-access reviews, and administers temporary "firefighter" IDs to provide emergency access when needed.
Without it, standard SAP offers the User Information System (transaction SUIM), which reports users holding critical authorisations and critical combinations of them. The auditor defines the conflicts relevant to your processes and runs the analysis on extracts. The ISACA article identifies this manual comparison as one of the largest cost drivers in assessing conflicts, so expect a longer first engagement.
How Often Should an SAP User Access Review Run?
For a manufacturing company, neither the Companies Act, 2013 nor its rules fix an interval. ISACA advises setting the frequency of user access reviews by the criticality of the asset, the associated risk and user movement. In practice, many companies review privileged and emergency access most often, conflicting access next, and the full user base at least once a year.
Business events should also trigger a review, such as the transfer of a plant, a reorganised purchase department or a new company code.
Why Does Your Statutory Auditor Care About SAP Access?
Because access controls sit inside the internal financial controls it reports on. Under section 143(3)(i) of the Companies Act, 2013, the auditor reports on the adequacy and operating effectiveness of internal financial controls with reference to financial statements. IT general controls such as access security and program changes form part of that assessment. One person companies, small companies and certain smaller private companies are exempt from this reporting.
The audit trail requirement
Since financial years beginning on or after 1 April 2023, every company that keeps its books in accounting software must use software that records an audit trail (edit log) of each change, which cannot be disabled. The statutory auditor reports on this under rule 11(g) of the Companies (Audit and Auditors) Rules, 2014. The ICAI Implementation Guide on reporting on audit trail expects administrator access to the audit trail to be restricted, and expects the trail at database level as well. In SAP, that makes Basis and database administrator access part of the same review.
The statutory auditor tests these controls for its own opinion, but section 144 of the Companies Act, 2013 bars it from providing internal audit, or design and implementation of any financial information system, to the company. Where the access review forms part of internal audit, it must come from someone else. A standalone review outside internal audit is not a listed service, but section 144 still requires board or audit committee approval for it. In practice, many audit committees still avoid it because of self-review concerns.
What Mistakes Do Manufacturers Make With SAP Access?
Plants that moved to SAP from older systems repeat a pattern: roles copied from the old menus, go-live emergency IDs never withdrawn, and stores, purchase and accounts teams left with broad access to keep dispatches moving.
An illustrative case at a spinning mill: the purchase executive who maintains cotton vendor records can also post the goods receipt for a bale lot and change the vendor's bank details. Together these allow a payment to an altered account for cotton that never arrived. At an auto dealership, the same risk appears as a service adviser who can create spares sales orders and issue credit notes.
These conflicts surface only when the auditor tests authorisation combinations and then reads the postings made by the users flagged. A wider ERP application audit of the system usually runs alongside.
How Should You Scope and Choose the Engagement?
Scope by risk, not by user count: the purchase, sales, inventory and finance modules, the company codes carrying most of the turnover, and every privileged ID.
Questions to ask before appointing a provider
- Which rule set will be used, and how will it be adapted to your processes?
- Will conflicts be tested at authorisation value level, not only by transaction?
- How will firefighter and generic IDs be reviewed, and over what period?
- Will the report separate design gaps from operating failures?
- Is the provider independent of the team that supports your SAP roles?
What the board should receive
A short audit committee report listing unmitigated conflicts, privileged access exceptions and agreed remediation dates. For sector process risks, see the industries Astral Business Consulting works with. Access findings also feed the wider framework of internal financial controls.
Planning an SAP Access Review This Year?
If your statutory auditor has raised access findings or a new company code has gone live, a scoped review of conflicts and privileged IDs is a sensible starting point. Talk to the Astral Business Consulting team about the scope and the evidence your auditor will expect.
