SAP Indirect Access Explained: From Definition to Count

Why indirect access is its own category

Indirect access is the SAP licensing concept that the SAP customer position must address whenever a third party application reaches into the SAP data or process. The concept emerged from the Diageo and the Anheuser Busch cases and matured into the digital access document model that SAP launched in 2018. The category has its own pricing scheme, its own measurement approach, and its own audit pattern. The defensible position requires a map of integration points, a classification of the trigger pattern, and a documented commercial position for each integration. Reference the license audit complete guide and the licensing models explained pillar and the indirect access detection analysis and the digital access conversion analysis and the indirect access expertise.

The trigger patterns

The trigger patterns are four. The first is the human user that accesses SAP data through a third party application user interface without an SAP named user. The second is the system integration that reads or writes SAP data through RFC, IDoc, or OData without a corresponding named user behind the integration. The third is the bot or RPA process that posts transactions to SAP through a service account. The fourth is the analytics layer that extracts SAP data on a schedule for downstream reporting. Each pattern produces an indirect access risk that the customer assesses against the use rights notice and the integration scope. Reference the indirect access detection analysis and the RPA licensing analysis and the license API analysis and the RFC security analysis and the digital access conversion analysis.

Customer programs that map the integration plane and produce the document count alongside the named user fallback in a single evidence pack close the indirect access reclassification proposal before the auditor opens the data room.

The digital access document model

The digital access document model counts the SAP document type that the third party access creates or updates. The nine document types include the sales order, the invoice, the purchase order, the financial posting, the time entry, the goods movement, the master data record, the service entry sheet, and the quality notification. SAP measures the document count per type per year through the Passport tool and the audit data collection. The customer counts the same document types through the integration log and the SAP transaction log. The reconciliation produces the document position that informs the renewal commercial total. Reference the digital access conversion analysis for the migration pattern from the named user fallback to the document model. Reference the digital access conversion analysis and the indirect access detection analysis and the licensing models explained pillar and the audit data collection analysis and the annual measurement analysis.

The named user fallback

The named user fallback is the older indirect access measurement approach. SAP counts the human user behind the third party application as a named user, regardless of whether the user has an SAP login. The fallback applies to contracts written before the digital access model and to scenarios that the customer chose to keep on the named user basis. The fallback measurement is sensitive to the user count growth in the third party application. The customer position rests on the documented user list and the activity test. The reclassification cycle covers both the named user fallback and the digital access document model. Reference the named user types analysis and the license reclassification analysis and the licensing models explained pillar and the contract review analysis and the indirect access expertise.

The defensible indirect access position

The defensible indirect access position has five components. The integration map that lists every third party application connection. The classification of each connection against the four trigger patterns. The digital access document count or the named user fallback count per integration. The commercial position per integration documented in the contract amendment or the side letter. The evidence pack that retains the integration log, the document count, and the named user list. The five components produce the indirect access position that withstands the SAP audit. Reference the security audit pillar for the cross cluster control surface and the compliance framework pillar for the regulatory map. Reference the security audit pillar (cross cluster reference) and the compliance framework pillar and the license audit complete guide and the indirect access expertise and the audit defense expertise.

For the broader context, our license audit complete guide (cross cluster reference) and compliance framework pillar document the response posture and the regulatory map that govern SAP risk. The GRC and security expertise page documents the senior advisor methodology, and the audit defense expertise page documents the senior advisor playbook. Confidential consultation is available through the contact form.