Beyond SAP access review: 8 systems, one platform

When the financial auditor signals "qualified opinion" because eight of your business-critical systems have no access review process, you don't have a compliance problem. You have a P&L problem.

This is the story of how a major Polish telco-media conglomerate extended smartReview beyond SAP to cover eight non-SAP systems carrying the rest of its accounting and customer data. Six months of design and integration, four discarded alternative architectures, one platform-neutral GRC adapter pattern, and an audit defence that finally stopped costing tens of person-days every year.

The trigger was concrete. The group's external auditor had spent two consecutive financial-year audits raising the same issue: SAP was under periodic access review (with smartGRC since several years prior), but eight other business-critical systems carrying material accounting, billing and customer data were not. During the 2019 audit, the topic almost crossed the line into a qualified opinion on the financial statements. Internal teams spent dozens of person-days in compensating evidence work — pulling reports, defending sample populations, mapping permissions to ledger postings — for findings that a real access review would have prevented from existing in the first place.

The decision the group faced in mid-2020 was not "should we run access reviews on non-SAP systems". The decision was how, given the time pressure of the next audit cycle, organisational complexity, and a parallel IDM selection project that had already chosen to not include the GRC functions in its scope.

This is a write-up of how that decision played out, what we evaluated, what we rejected, what we built, and what the engagement taught us about the limits of every other architecture in this category. Names, exact figures, and identifying system names have been anonymised; structural patterns and orders of magnitude are unchanged. Five enterprise customers, including one publicly-listed group, run smartReview beyond SAP in production today.

The scoreboard at the start

Why non-SAP access review never gets done

The question is not why a complex organisation wants access reviews. The question is why, in practice, they happen for SAP and almost never for the rest of the application portfolio. The answer is a four-way ownership gap and a tooling gap that mirrors it.

Internal audit oversees the control framework but does not operate it. IT understands roles and database grants but rarely understands the business consequence of a specific authorisation in a specific application. Business application administrators often know the technical detail, but they are the population the review is meant to scrutinise, so they cannot be the reviewers. The business owner of a customer-file application, a data warehouse, or a billing platform usually has neither the technical vocabulary to read role definitions nor the organisational mandate to act on what they would find. The seat that should run periodic reviews on a non-SAP system frequently does not exist on the org chart.

The tooling gap mirrors the ownership gap. GRC platforms historically grew out of SAP audit practice — they speak SAP, they ship SoD libraries calibrated for SAP transactions, and their connectors target SAP ERP first. IDM platforms operate at a different layer entirely: they manage account lifecycle in technical language ("role AA_KSIEGOWANIE_130"), which is not the language a business reviewer can decide in. The result is that the seventy-plus percent of an enterprise's access risk that lives outside SAP — billing platforms, data warehouses, CRM, accounting sub-ledgers, custom applications — falls into a no-man's land where neither the GRC tool nor the IDM tool is the obvious answer.

That gap is what this engagement set out to close.

The four variants we evaluated, in order of growing seriousness

Every meaningful change in a regulated environment starts with the discipline of listing the alternatives. The group evaluated four options before settling on the one that worked.

The decision was taken in mid-June 2020. The vendor committed to readiness by end of October. The first non-SAP review cycle ran later that same year.

The eight systems we connected

Eight systems is enough to surface every interesting integration pattern that exists in a typical enterprise application portfolio. The matrix below describes them anonymously, ordered roughly by integration difficulty:

System type	User count	Technical complexity	Business complexity
Telco billing platform (Sybase/VMS/S2K backend)	~2,600	High	Medium
Billing customer-service UI (AD-native)	~2,000	Low	Low
Enterprise data warehouse (Teradata)	~1,200	Very high	Very high
Billing data-transmission backend (MS SQL)	~30	High	Medium
Telemarketing CRM (multi-application)	~8,000	Medium	High
Accounting sub-ledger (web app)	~30	Medium	Low
Consolidated customer-file accounting overlay	<20	Low	Low
DTH billing reconciliation app	~1,000	Medium	Low

Across these eight systems we encountered every identity-to-account binding pattern an enterprise integration team will recognise:

• Active Directory direct binding — the easy case. The application authenticates against AD, the AD login is the identity, the mapping table is implicit.
• AD plus admin mapping table — most users are AD-native, administrators have dedicated technical accounts that require a separate mapping from a side table.
• NTLM cross-domain authentication — login validated against the user's home domain but the application sits in a different one; the EmployeeNumber attribute bridges the two.
• EmployeeNumber bridge between two domains — the application predates AD federation; identity has to be reconstructed by joining HR system attributes with two AD trees.
• External mapping for technical accounts — system has user_##, exp_*, load_*, apl_* account categories, only some of which map to human identities; the rest are service accounts that need separate treatment.

If your portfolio looks anything like a portfolio that has grown through fifteen years of acquisitions and replatformings, you have all five.

The four permission model archetypes

Permission models are where systems differ the most, and where the abstractions in a GRC platform have to do the most work to hide that difference from the business reviewer.

Profile-based with advisory IDM — the application has user accounts and granular database-level permissions; an IDM layer defines "profiles" as bundles of those granular permissions; but the profile in the IDM is advisory, not binding. The administrator of the source system can deviate from the profile at will, and the deviation is not visible in the IDM view. Reviewing the IDM tells you what should be true. Reviewing the underlying system tells you what is true. Only the second is useful for an audit.

AD-group only — the application authorises by membership in a small number of AD groups. The review is clean: list the users, list their group memberships, decide whether each user-group pair is still appropriate.

Database-role with inheritance — the application is a thin client over a database, and the database has roles, plus per-table or per-view explicit grants on top of roles, plus role-inheritance hierarchies. Permissions are computed dynamically at query time. The number of distinct "effective permissions" a user can hold is combinatorial, and most of them are never exercised. A naïve report lists thousands of permission rows per user; an audit-useful report lists the dozen permissions that matter and shows whether the user has any of them.

Atomic permissions plus location context — the hardest. Permissions are granular operations ("create order", "upgrade contract", "sell"), but the operation is only meaningful in the context of an organisational location ("create order, for store #4781, for customer category X"). The review question is not "can this user create an order" but "can this user create an order at this location for this customer category". The data model has to support that level of conditioning, and the reviewer interface has to surface it in business language. Without that, the review produces volume without signal.

The universal pattern: an XSD-described XML adapter

The architectural decision that made the engagement deliverable on time and on budget was this: do not build N system-specific connectors. Build one well-defined ingestion schema and require every system to produce it.

The schema described, for any source system: the user population (with identity binding metadata), the permission catalogue (atomic and composite), the user-to-permission assignments, the assignment timestamps and statuses, the optional risk-class tags. An XSD made the schema enforceable and self-documenting. Any source system that could be persuaded to write an XML file in that schema could be ingested.

This had three practical consequences. First, the engineering work for each new system was scoped: produce an XML file in the schema, validate it against the XSD, hand it off. No bespoke connector logic on the GRC side, no protocol negotiation, no waiting on IT calendars to align. Second, the same schema would later be filled by the new IDM platform once it was deployed; the manual upload phase was Phase 1, the automated IDM feed was Phase 2, and the GRC ingestion logic did not need to be rewritten between phases. Third, the schema gave each business owner a precise specification of what their system was contributing to the review process, which turned out to be the single fastest way to surface "this attribute is actually empty in our system" type discoveries.

The platform-neutral primitive a GRC system operates on is the same across every application: a user, a permission, a business risk, a reviewer, a verdict, an evidence trail. Everything else is integration glue.

What smartReview needed to add

Extending an existing tool always involves a feature set the existing tool does not yet have. For smartReview the deltas were:

Multiple parallel review cycles. The SAP review had run once a year. Eight non-SAP systems meant cycles staggered through the calendar, sometimes overlapping, sometimes triggered by ad-hoc events (joiners, movers, regulatory changes). The data model and the reviewer queue had to support multiple active cycles addressing different system populations at the same time, without bleeding into each other.

Non-SAP risk definitions in business language. SAP SoD libraries describe risks in transaction codes. A non-SAP risk catalogue describes risks in actions ("post a bank reconciliation entry", "approve a credit adjustment over €X", "modify a customer's billing address"). The risk definitions had to be authored per system, then expressed in the reviewer interface in the language the reviewer's role expected.

Audit-friendly evidence trail. Every reviewer decision had to leave a clean record: who reviewed, when, what they were shown, what they decided, what evidence was attached. The financial auditor reviewed the evidence trail at the next audit; if the trail did not stand up to scrutiny, the review process itself would not stand up. We over-invested here on purpose.

What we learned

Three lessons travelled with us into every subsequent Beyond-SAP engagement.

Sixty-minute system classification before scoping anything. The complexity matrix above is not a write-up artefact; it is a real classification step performed at the start of every new system integration. The two dimensions — technical complexity of the export, business complexity of mapping the export to risk language — let the team commit to a calendar with confidence. Skip the classification, and the engagement quotes 6 weeks and delivers in 5 months.

The system owner is in the room or the system does not get integrated. Three of the eight systems in this engagement nearly slipped because the original owner had moved on, the new owner had not been formally assigned, and the technical team did not have the authority to commit to a data export format. We learned to refuse to start the work until a named, current system owner was present at the kick-off.

Some systems should be deferred, not forced. Two systems in the original ten-system list did not make the cut for the first review cycle. One had identity binding sufficiently broken that resolving it was a project in its own right; one was scheduled for decommissioning within twelve months and would have produced one review cycle of value at the cost of a full integration effort. Saying "later" or "not at all" is a legitimate outcome of the classification step.

The bigger picture

The standard story about GRC platforms is that they exist to monitor SAP. That story is fifteen years old. The accounting-and-audit-material data in a modern enterprise has migrated to billing platforms, data warehouses, customer-files, CRM, accounting overlays and custom apps that were never in SAP and never will be. SAP is, in many groups, well under half of the access risk surface.

A GRC platform that stops at SAP is solving a fraction of the problem that the audit committee is being asked to attest to. The choice the group made — keep the SAP review running on smartReview, extend the same smartReview to the eight non-SAP systems, build a platform-neutral XML adapter that the future IDM can later feed automatically — was not a clever workaround. It was the architecture this category should have had ten years ago. Every successive customer who has run smartReview Beyond SAP has confirmed the same: the engineering is not the hard part, the ownership and the risk language are. Once the platform is neutral, the conversation moves to where the value is.

The financial auditor stopped raising the access-review topic the following year. The internal audit team stopped spending dozens of person-days on compensating evidence. The IT teams running the eight systems gained, for the first time, a clear yearly cadence for the recertification work that had previously been done ad-hoc and partially. The audit committee gained a defensible answer to a question it had been getting wrong for a decade.

Five customers, including one publicly-listed European group, run smartReview Beyond SAP in production today. The pattern travels. If your audit committee is asking the same question and your GRC platform stops at SAP, the architecture above is what the answer looks like.

About the engagement. The pattern described in this article was developed by GRC Advisory's smartGRC LAB during a 2020 engagement at a major Polish telco-media conglomerate, anonymised here in compliance with confidentiality obligations. Specific user counts, system names, identity binding details and risk catalogues have been adjusted to remove identifying detail; structural patterns and orders of magnitude are unchanged. If you operate a multi-system enterprise where most of the access risk lives outside SAP and want to discuss running a similar engagement on your own portfolio, contact details and a live UX preview are at smartgrc.eu.