SAP IT Audit Software Consulting
SAP IT audit software supports testing of IT general controls (ITGCs) — access management, change management, and computer operations — specifically inside a SAP landscape, where the underlying evidence lives in Basis-administered tables and logs (SUIM, STMS, system logs) rather than in a generic ticketing system. IT audit against SAP has a narrower and more technical evidence base than application-control testing: it is testing whether the platform itself is administered safely, which requires software capable of reading Basis-level configuration and access data, not just business-process transaction history. A weak ITGC finding undermines reliance on every application control tested downstream, which is why auditors typically test ITGCs first.
Access management testing at the Basis level
IT audit software testing SAP access management needs to distinguish between business-role access (governed through PFCG and typically tested via GRC Access Control) and Basis-level administrative access — SAP_ALL and SAP_NEW profile assignments, debug-and-change authorization (S_DEVELOP with ABAP debug flags enabled), and direct table maintenance access (SM30/SE16N with edit rights) that bypasses application-layer controls entirely. This second category is disproportionately high-risk because it can override any application control the audit already tested, and it is frequently under-scrutinized because it looks like routine Basis administrator access rather than a financial-reporting risk.
A recurring finding in SAP ITGC testing is SAP_ALL or equivalent broad-access profiles assigned to non-Basis users for convenience during a project and never revoked afterward. IT audit software that can pull a full list of users holding these high-privilege profiles directly from SAP — rather than relying on a Basis team's self-reported list — closes the most common gap in this control area, because the self-reported version tends to miss exactly the access nobody remembers granting.
Change management testing beyond the transport log
Transport log evidence (covered under application change management) tells you what moved into production and when. ITGC testing at the infrastructure level goes one layer deeper: whether the underlying transport system configuration itself — who can create transport routes, who can modify the STMS landscape configuration, who has direct access to the operating-system or database layer beneath the SAP application — is appropriately restricted. A perfectly logged transport process is undermined if someone with database-level access can bypass the transport layer entirely and change financially relevant tables directly.
IT audit software needs to test for this bypass path explicitly: direct table access outside the transport process, direct SQL access to the underlying database, and emergency-change (firefighter) access used to modify production without a corresponding transport. Each of these is a legitimate operational necessity in a well-run SAP landscape, but each also needs its own logging and after-the-fact review control, and testing software that only checks the transport log will systematically miss all three.
Computer operations and system logging
The third classic ITGC domain — computer operations — covers backup and recovery, batch job scheduling integrity, and system availability, all of which have SAP-specific evidence: background job logs (SM37), system log (SM21), and backup confirmation from the Basis team's operations tooling. For SOX purposes, the relevant question is narrower than general IT operations health: does a failure or manipulation of a scheduled financial batch job (a nightly interface, a period-end close job) get detected and remediated in a way that would prevent it from silently corrupting financial data.
IT audit software that can pull SM37 job logs and cross-reference expected job schedules against actual execution — flagging failed, skipped, or manually re-triggered jobs touching financially relevant interfaces — turns this from a narrative control ('the Basis team monitors batch jobs') into an evidenced one. This is a control area SOX programmes frequently under-scope relative to access and change management, even though a corrupted or silently-failed interface job can produce a material misstatement just as easily as an unauthorized access event.
What actually differentiates the options
- ·Ability to distinguish and separately test business-role access (PFCG/GRC Access Control) from Basis-level administrative access (SAP_ALL, debug authorizations, direct table maintenance).
- ·Direct extraction of high-privilege profile assignments from SAP rather than reliance on Basis team self-reporting.
- ·Coverage of the transport-bypass risk — direct database or table access outside the STMS process — not just transport log review.
- ·Ability to pull and analyze SAP background job logs (SM37) and system logs (SM21) for financially relevant batch processes.
- ·Reporting structured around the three classic ITGC domains (access, change, operations) so findings map cleanly to what an external auditor's ITGC workprogram expects.
Requirement, control, evidence
| Requirement | Control | Evidence |
|---|---|---|
| ITGC — access management (foundational reliance for all application controls) | Restricted and periodically reviewed assignment of SAP_ALL and other high-privilege administrative profiles. | System-extracted list of users holding SAP_ALL or equivalent broad profiles, reviewed quarterly with justification for each retained assignment. |
| ITGC — change management beyond the application layer | Restricted access to direct table maintenance (SM30/SE16N edit) and database-level access outside the transport process. | Access report showing users with direct table-edit or database access, cross-referenced against a documented business justification. |
| ITGC — emergency/firefighter access | Emergency access to production requires logging and mandatory retrospective review, typically via SAP GRC Emergency Access Management. | Firefighter access log showing session start/end, actions taken, and a signed retrospective review for each use. |
| ITGC — computer operations (batch processing integrity) | Scheduled financial batch jobs are monitored for failure or manual re-triggering, with exceptions investigated. | SM37 job log extract showing scheduled vs. actual execution for in-scope jobs, with documented resolution for any failures or manual reruns. |
What this actually costs
| Cost driver | Low | High | What moves it |
|---|---|---|---|
| ITGC scoping and Basis-level gap assessment | $55,000 | $160,000 | Scales with landscape complexity — number of SAP systems, whether database-level access controls have ever been formally reviewed. |
| Access and change-management remediation (Basis level) | $80,000 | $300,000 | Driven by how many high-privilege profiles must be redesigned or revoked, and whether a firefighter/emergency-access process needs to be built from scratch. |
| Ongoing ITGC testing and batch job monitoring support | $40,000/yr | $140,000/yr | Includes quarterly high-privilege access review, firefighter log review, and batch job exception monitoring. |
- · Ranges assume a single primary SAP landscape (dev/QA/production) with standard Basis administration; multiple parallel landscapes trend toward or beyond the high end.
- · Figures are illustrative estimates based on typical enterprise engagements, not a quote for a specific organization.
- · External audit fees for ITGC-related 404(b) testing are excluded — this reflects internal remediation and advisory labor only.
A representative scenario
A hypothetical logistics company running SAP ECC has passed application-control testing for three consecutive years but receives its first ITGC finding when a new external audit team requests a list of SAP_ALL profile holders directly from the system rather than accepting the Basis team's prior self-reported list. The system extract typically surfaces a materially larger number of high-privilege assignments than the self-reported version — commonly including several developer accounts retained from a completed S/4HANA readiness project and a handful of interface service accounts with broader access than their function requires. Remediation for a company in this position typically involves formally scoping and revoking unnecessary SAP_ALL assignments, standing up SAP GRC Emergency Access Management for legitimate firefighter needs with mandatory logging, and establishing a quarterly high-privilege access review owned by the Basis team but independently verified by internal audit using a fresh system extract each cycle. This pattern — self-reported Basis access lists undercounting actual high-privilege assignments — is common enough in SAP ITGC testing to be presented here as illustrative, not as a specific client outcome.
Common questions
Application controls operate within a business process — a three-way match, a journal entry approval workflow. ITGCs operate beneath that layer — who can access the system at all, who can change its configuration, whether scheduled processing runs reliably. An ITGC failure (like uncontrolled SAP_ALL access) can bypass or invalidate an otherwise well-designed application control, which is why auditors test ITGCs before relying on application-control results.
Book an assessment
Get a scoping call on sap it audit software for your organisation's platform and entity structure.
Book an Assessment →