An RFC inspection request is an audit team asking the customer to grant SAP a live connection into the productive system, with sufficient privilege to run extracts directly, query the database, and execute measurement transactions in real time. The request is presented as a procedural convenience — "we will just run a few extracts ourselves" — and is sometimes accompanied by an assertion that the audit cannot proceed without the access. Neither characterisation is accurate. The contractual basis for the request is thin, the operational risks are material, and the production alternative is straightforward.
This article explains why the requests appear, the five grounds on which they should be declined, and the production alternative that satisfies the legitimate underlying audit need.
Why the requests appear
SAP audit teams request RFC inspection for several reasons, some defensible and some not. The defensible reasons centre on data integrity: the audit team wants to confirm that the extracts the customer produces are pulled from the productive system without intermediate manipulation, that the system parameters match the documentation, and that the measurement transactions return the figures the customer is reporting. These concerns are reasonable. The right response is to address them, not to grant the access.
The less defensible reasons centre on convenience and on scope expansion. A live connection lets the audit team run additional queries beyond the agreed extracts, explore the customer's system landscape, and observe configurations that may inform unrelated commercial inquiries. The implicit scope expansion is the real cost of granting the access, and it is usually invisible to the customer's audit response team until the additional queries appear in the audit report.
The five grounds for declining
1. The contract does not require it
Most SAP customer contracts grant SAP the right to audit the customer's use of the licensed software. The grant typically includes the right to request extracts, measurement output, and supporting documentation. It does not typically include a right to direct access to the customer's productive system. The audit clause is the contractual basis for everything that happens in the audit, and a careful reading of the clause usually returns a clear position: the customer is required to produce data, not to grant access. See our document request analysis for the broader boundary management.
2. The customer's security policy does not permit it
Most customer security policies impose strict controls on external access to productive systems. The policies are not just procedural — they reflect regulatory requirements, internal audit findings, and lessons from prior security incidents. Granting external access for an audit usually requires explicit security-team approval, and most security teams will decline the approval given the available alternatives. The security policy is a legitimate constraint that the customer should articulate to the audit team and document in the response.
3. The data protection framework constrains it
For customers operating in jurisdictions with strong data protection frameworks — GDPR, similar regimes — granting external access to systems containing personal data raises distinct compliance questions. The customer's data protection officer has a legitimate interest in restricting access to the data subjects' personal information. The audit team can typically observe metrics and aggregates without accessing personal data, and the production alternative supports that distinction.
4. The audit trail is harder to reconstruct
A live RFC connection produces a different audit trail than a managed extract process. Queries executed during the live session need to be reconstructed from the system logs after the fact, and the reconstruction can be incomplete. The customer's defensive position requires a clean audit trail of what was extracted and reviewed, and the production alternative produces that trail naturally.
5. The production alternative satisfies the legitimate need
The legitimate underlying need — verifying that the customer's extracts are produced from the productive system without intermediate manipulation — is satisfied by the production alternative described below. Once the alternative is established, the live access request becomes a request for convenience or scope, neither of which is contractually required.
The production alternative
The production alternative is straightforward to describe and not difficult to implement. The customer's basis team runs the requested extracts in a controlled session, with two specific characteristics. The first is recorded execution: the session is screen-recorded or transcribed so the customer can demonstrate exactly which transactions were executed and what output was produced. The second is observed execution: an SAP audit team representative is invited to observe the session, either in person or via a screen-sharing tool, with the customer's basis team executing the commands.
The observed-execution model satisfies the audit team's legitimate concern — they can see the extracts produced live from the productive system, with no intermediate processing — while preserving the customer's control over what happens in the system. The recorded session becomes part of the audit documentation and supports any subsequent escalation.
The written response
The customer's response to an RFC inspection request should be a written letter that articulates four things: the contractual position (no requirement under the audit clause), the security policy position (external access not permitted), the production alternative (observed execution with recording), and the timeline (when the production alternative can be scheduled). The letter is professional and unemotional. The objective is to establish the boundary while signalling that the customer is cooperating with the audit's legitimate purpose.
The escalation handling
When SAP escalates an RFC inspection refusal, the conversation typically shifts from procedural to commercial. The customer's response needs to shift in parallel. The procedural arguments — security policy, contract clause, data protection — remain valid but are not the most useful in a commercial conversation. The commercial conversation centres on the customer's overall relationship with SAP, the renewal economics, and the audit's likely outcome under different scenarios. The customer's preparation for the procedural pushback should include preparation for the commercial conversation, because the second conversation usually follows the first within a week or two.
The audit conclusion
An audit conducted under the production alternative reaches the same conclusion as an audit conducted under live RFC inspection in the overwhelming majority of cases. The defensible measurements that drive the audit conclusion — user counts, engine metrics, digital access volumes — do not change based on how the extracts were produced. The audit team's concerns about extract integrity are addressed by the observed-execution model. The conclusion proceeds on the same data and reaches the same position.
The customer's defensive posture should be that the audit is welcome to proceed and that the customer will produce whatever the audit clause requires, under the production alternative. The framing matters: the customer is cooperating, not obstructing, and the documentation of the cooperation supports any subsequent regulatory or commercial proceeding.
The standard letter
The customer's RFC inspection refusal letter should follow a defined template. The template contains five elements: a clear statement that the customer is declining the live RFC inspection request, the contractual basis for the declination (the audit clause does not require live access), the security policy basis (external access not permitted under customer policy), the production alternative offer (observed execution with recording, on a defined timeline), and a closing that signals continued cooperation with the audit's legitimate scope. The tone is professional and the objective is to keep the audit moving toward the negotiated conclusion. See our audit defence service for the full template and the surrounding engagement framework.
For the broader audit response context, see our audit response composition analysis. For the methodology, see our audit defence playbook. For a worked example of an RFC refusal, see our financial services audit defence case study.