An SAP audit notification will, in most engagements, eventually arrive at a request for the customer to run a specific RFC-based measurement script and to return the output to the SAP audit team. The script — sometimes a USMM extract, sometimes a LAW consolidation, sometimes a bespoke ABAP package delivered by the auditor — is the means by which SAP gathers the measurement data on which the audit claim will rest. The customer's posture on this request, including whether the script itself can be inspected before execution, is one of the more important procedural decisions in the engagement.
This article walks through what the disclosure request looks like, what the customer's contractual position actually permits, the technical and audit-defence reasons to inspect the script before execution, and the framing that produces the best outcome.
What the disclosure request actually looks like
The request typically arrives midway through the engagement, after the scope-setting and the data-exchange protocol discussion. SAP sends a package — frequently delivered as an ABAP transport, occasionally as a set of standalone scripts — with instructions to import the transport into the customer's system, execute the measurement, and return the output. The instructions specify the systems against which the script is to be run, the measurement period, and the output format.
The script is presented as a routine technical measurement, and most customers treat it as such. The default response is to import the transport, execute the script, and return the output without inspection.
Why inspection is appropriate
The script is, in fact, not a routine technical measurement. It is a piece of executable code that runs with elevated authorisations inside the customer's SAP production system. Its outputs are inputs to a commercial discussion in which the customer's interest is to minimise exposure and the auditor's interest is to maximise it. The customer has both a security obligation and a commercial-defence interest in understanding what the script is doing before it runs.
The contractual basis for the inspection request
Most SAP enterprise agreements grant SAP the right to measure the customer's use of SAP software through reasonable measurement procedures. The contracts rarely specify that the customer must execute a particular script or transport without inspection. The reasonable interpretation, and the one we recommend customers adopt, is that the customer can request disclosure of the script before executing it, with the right to apply standard security and code-review controls.
The disclosure request is therefore neither a refusal to cooperate nor an obstruction of the audit. It is a reasonable application of the customer's standard internal controls to a piece of executable code that will run in production. Framed correctly, the request is procedurally difficult for the auditor to refuse.
How to frame the request
The framing matters. The request should be procedural — the customer's internal change control and security review process requires inspection of any code being imported into production. The request should be specific — the customer requires the script source, the documentation of what the script measures and how the measurement is computed, and a representation that the script does not perform any function beyond the measurement described. The request should be cooperative — the customer is requesting the disclosure in order to enable timely execution within the engagement timeline.
For more on the broader engagement protocol, see our audit defence service, the Audit Defence Playbook, and the USMM/LAW measurement topic page.
What the inspection actually finds
Inspection of audit scripts has, in our practice, surfaced several patterns worth flagging. The first is the scope-creep pattern — the script measures more than the auditor's stated scope, frequently because the same script is used across multiple engagements with different scope parameters and the customisation for the specific engagement is incomplete. The second is the measurement-methodology pattern — the script applies a measurement methodology that is favourable to the auditor's position, where a customer-side methodology applied to the same underlying data would produce different results. The third is the disclosure pattern — the script extracts customer data beyond what is necessary for the stated measurement, particularly personally identifiable information of system users.
None of these patterns is necessarily malicious; all of them are commercially relevant. The customer who has inspected the script and understands its behaviour is materially better positioned for the discussion that follows.
What to do if the auditor refuses disclosure
The auditor's response to a disclosure request falls into one of three patterns. The most common is partial disclosure — the script's documentation and high-level methodology are provided, but the source is held back as proprietary. The customer can usually accept this with an additional commitment from the auditor that the script performs only the documented measurement.
The second pattern is conditional disclosure — the script source is provided subject to a non-disclosure agreement. The customer can usually accept this, with appropriate review by the customer's legal team of the NDA terms.
The third pattern is refusal of disclosure, with the auditor's position that the script must be executed without inspection. This pattern is rare but occurs. The customer's response in this case should be a formal letter, escalated above the auditor's level, citing the customer's internal controls and proposing alternative measurement approaches — for example, the customer-led measurement using standard SAP tools, with the output exchanged with the auditor. For applied examples, see our Fortune 100 case file and the RFC inspection refusal grounds article.
The data-protection dimension
Beyond the security and commercial questions, the audit script often raises a data-protection question. Where the script extracts personally identifiable information — typically user names, email addresses, and role information — the customer has a GDPR or equivalent regulatory obligation to control the transfer of that information to a third party. The customer's data-protection officer needs to be in the inspection process, and the data-protection assessment of the script may itself produce a basis for modifying the measurement methodology or the data exchanged.
For more on this dimension, see our data-protection grounds article.
The right posture from the start
The customer who establishes the inspection posture at the start of the engagement — as part of the data-exchange protocol discussion in the first written reply — finds that the disclosure request, when it arrives, is handled procedurally rather than as a confrontation. The customer who tries to introduce the inspection request after the script has already been delivered faces a more difficult conversation. The lesson is operational: build the inspection requirement into the engagement protocol from day one.