Audit and Compliance

Public

May 2026

Executive Summary

Organizations that process revenue-bearing transaction data, across industries such as telecom, finance, and digital services, operate under increasing scrutiny from auditors to assess controls over financial reporting. When that processing relies on mediation platforms like SAP Convergent Mediation by DigitalRoute, a critical question emerges: how does the platform support the control environment required for SOC 1 compliance?

This post is for control owners, IT auditors, and compliance teams evaluating how SAP Convergent Mediation fits into a SOC 1 (SSAE 18 / ISAE 3402) control framework. It covers the platform's built-in capabilities, what customers must implement independently, and how configuration properties map to confidentiality, integrity, and availability objectives.

Key distinction: DigitalRoute develops and ships SAP Convergent Mediation. Customers deploy, operate, and govern the platform within their own environments. This means SOC 1 control ownership sits with the operating organization. The platform provides capabilities that support those controls, but does not replace the governance, approval workflows, or segregation of duties that auditors expect.

Note: SAP Convergent Mediation is a component in Billing and Revenue Innovation Management (BRIM). Its primary role is to collect revenue-bearing usage and priced transactions from the outside world (operational domain) and feed high quality data into the BRIM financial processes. Hence, the SOC 1 compliancy scope described here covers SAP Convergent Mediation as such, and not the whole of BRIM. 

This blog post was co-authored with Yaad Karim, CISO DigitalRoute.

The Shared Responsibility Model

Before mapping specific controls, it is essential to understand who owns what. SOC 1 auditors will look for clear boundaries between the product vendor and the operating entity.

 

The platform generates evidence. The customer governs the process around that evidence. Auditors assess both.

Mapping to SOC 1 ITGC Control Objectives

SOC 1 reports typically address IT General Controls (ITGCs) across several domains. SAP Convergent Mediation provides relevant capabilities in three of the four core ITGC areas.

 1. Change Management

Control Objective: Ensure that all changes to system configurations are recorded, traceable to an individual, and reviewable for accuracy, completeness, and authorization.

This is typically the most scrutinized ITGC domain in a SOC 1 audit. Auditors want to see that changes are authorized before implementation, that a record exists of what changed, and that changes can be traced back to a specific individual and point in time.

What the platform provides

  System Log with Filter dialog. Events are recorded with timestamp, severity, type, and user attribution. Filters allow targeted evidence extraction by severity, date range, username, and message content.

  Configuration Diff showing side-by-side comparison of two APL code versions. Green highlights (left) show the source version; red highlights (right) show the target. Each version displays the timestamp and username of the change, providing the what/who/when triad for change management evidence.

  Workflow History dialog listing every configuration version with modified date, user, and free-text comment. Each entry captures who update the workflow and when it was updated. Optionally, the system implementor can add a comment to describe the why, aligning the platform's technical traceability with the approval trail in the customer's ITSM system.

What the customer must implement

• Operate a formal change management process (e.g., change advisory board, ticket-based approvals) in their own ITSM tooling
• Ensure segregation of duties between change requestors, approvers, and implementers
• Retain evidence of approval outside the platform (e.g., ServiceNow, Jira tickets)
• Periodically reconcile platform change logs against approved change records

Auditor note: The Configuration Tracer/Diff capability is particularly valuable for walkthrough testing. It provides the “what changed” evidence that auditors can match against approved change tickets in the customer's change management system.

2. Logical Access – Sensitive Access Monitoring

Control Objective: Identify and review activities of privileged users to ensure that sensitive access is used appropriately and that access rights remain commensurate with job responsibilities.

Logical access controls are the second pillar auditors examine. For mediation platforms processing financial transaction data, this means demonstrating that administrative access is controlled, monitored, and periodically reviewed.

What the platform provides

What the customer must implement

• Define and enforce a formal access provisioning and deprovisioning process
• Conduct periodic access reviews (quarterly or per policy) using exported access data
• Implement segregation of duties so that users who provision access are not the same users being provisioned
• Route System Log data to a SIEM or log management platform for independent monitoring and alerting
• Establish account lockout and password policies aligned with organizational standards

SSO and centralized credential storage

In modern deployments, SAP Convergent Mediation integrates with corporate identity providers via Single Sign-On so that authentication inherits enterprise policies: MFA, password complexity, session timeout, and conditional access. Credentials for downstream systems can be held in a cloud KMS or hyperscaler keystore rather than local configuration files. For SOC 1 purposes, this aligns platform onboarding and offboarding with the organization's IAM lifecycle and reduces the attack surface around locally stored secrets.

3. Logical Access – User Access Review

Control Objective: Periodically review all user accounts, roles, and access rights to confirm they are appropriate.

Periodic access reviews are a distinct control from day-to-day access monitoring. Auditors test whether the organization conducts structured reviews at defined intervals and whether inappropriate access is remediated.

What the platform provides

  Access Controller – Users Tab showing all user accounts with username, full name, email, group membership (role), enabled status, and SSO indicator. This view provides the complete user access listing required for periodic access reviews. Data can also be exported programmatically via the SCIM REST API.

What the customer must implement

• Schedule periodic user access reviews (typically quarterly for SOC 1)
• Define review procedures: who reviews, what constitutes appropriate access, how exceptions are handled
• Document review completion and any remediation actions
• Integrate SCIM API exports into identity governance tooling where applicable

4. Processing Integrity: Counters and Reconciliation

Control Objective: Ensure that in-scope transaction data is processed completely and accurately, that errors are detected and investigated, and that records are neither lost nor duplicated between source systems and downstream financial applications.

Because mediation sits between raw operational data and the systems that drive revenue recognition, auditors will ask how you demonstrate that every in-scope record is accounted for. Process descriptions alone are not enough; auditors expect reconciled evidence.

What the platform provides

   Audit trail showing per-file processing activity. Each row records source file, record type, record count, and activity reason (collected, aggregated, routed to billing, sent to error correction, filtered as non-billable or duplicate). This level of detail reconciles what entered the platform against what reached downstream billing.

   Monthly summary report breaking down total records in and out of the system by activity and error code. Reports like this let Revenue Assurance monitor completeness trends, investigate spikes in specific error codes, and produce reconciliation evidence for the SOC 1 control owner.

Example: daily reconciliation

A typical high-volume deployment ingests millions of usage records per day, processes them through rating and account-assignment workflows, and forwards rated usage to downstream charging and invoicing systems. Counters expose the gap between input and output: for example, 10,000,000 records ingested, 9,995,000 successfully processed, 5,000 rejected with specific error codes (unknown subscriber, invalid product mapping, duplicate). Recoverable rejections are corrected and reprocessed; the monthly reconciliation pack becomes the audit evidence.

What the customer must implement

• Define in-scope data flows and establish reconciliation thresholds aligned with materiality
• Assign a Revenue Assurance or equivalent function to investigate anomalies and error-code spikes
• Retain reconciliation packs and investigation notes as audit evidence for the SOC 1 period
• Integrate processing-chain alerts with the organization's incident response process

5. Configuration Hardening: The Property-Level SOC 1 Mapping

Beyond the three core control areas above, SAP Convergent Mediation provides something uncommon for enterprise software: a property-level SOC 1 relevance mapping across the platform's entire configuration surface.

Every configurable property has been assessed and tagged with:

• SOC 1 Scope: Whether the property is relevant to SOC 1 compliance (Yes / No / Depends)
• Category: The control objective it supports (Confidentiality, Integrity, or Availability)
• Reason: A specific explanation of how misconfiguration could impact the control environment

 What this means in practice

 

The full property mapping spans Cell, Container, Execution Context, Platform, High Availability, Log, Database, and Desktop property categories.

For full properties mapping see the following DigitalRoute InfoZone: here 

This level of detail enables customers to:

1. Baseline their configuration against SOC 1 expectations before an audit
2. Prioritize hardening by focusing on properties tagged as SOC 1 relevant
3. Provide evidence that configuration choices were deliberate and risk-informed

Evidence Flow: From Platform to Audit

The following diagram shows how evidence generated by SAP Convergent Mediation flows into a customer's SOC 1 control framework.

 Complementary User Entity Controls (CUECs)

When a product vendor does not operate the environment, auditors expect a clear statement of Complementary User Entity Controls, meaning controls that the customer must implement for the overall control environment to be effective.

Getting Started

For organizations beginning their SOC 1 alignment with SAP Convergent Mediation:

1. Review the shared responsibility model. Understand which controls the platform supports versus which your organization must own.
2. Map your control objectives. Align the three capability areas (change management, sensitive access monitoring, user access review) to your SOC 1 control matrix.
3. Harden configuration. Use the property-level SOC 1 mapping to baseline and harden your deployment.
4. Implement Complimentary User Entity Controls. Ensure all complementary controls are in place before the audit period begins.
5. Establish evidence collection. Configure log forwarding, schedule access exports, and integrate with your ITSM and IGA platforms.

References

The following documentation provides detailed guidance for each area covered in this post:

SAP Convergent Mediation by DigitalRoute provides the capabilities. Your organization provides governance. Together, they form a control environment that auditors can assess with confidence.