The Compliance Tax on Provisioning: Why Regulated Industries Have It Worst

TL;DR

The same regulations that protect your business created the permission structures that now take hours to configure.

SOX requires separating "Create Vendor" from "Pay Vendor" - so SAP has thousands of authorization objects. HIPAA requires need-to-know access at the field level - so Epic has six-layer security hierarchies. Every compliance requirement added granularity. Over decades, that granularity became unmanageable.

This isn't legacy debt from bad architecture. It's the accumulated weight of regulations doing exactly what they were designed to do. The complexity exists for good reasons - but your IT team still has to navigate it manually, for every user, every time.

The compliance → granularity → chaos pipeline

Here's how it happens:

Year 1: Regulation requires that certain functions be separated (e.g., the person who creates a vendor can't also pay that vendor). The software adds a permission flag to enforce this.

Year 5: Auditors want more granularity. Now you need separate permissions for Create, Change, Display, and Delete. Four flags instead of one.

Year 10: Different business units need different rules. Now those four flags need to be scoped by company code, cost center, and plant. The permission matrix expands.

Year 20: New regulations layer on. GDPR adds data residency requirements. Industry-specific rules add more constraints. Each requirement adds more permission dimensions.

Year 30: You have thousands of permission combinations. No single person understands all of them. New employees need weeks of training before they can safely configure access. And you still have to do it manually, because the system was built for compliance, not for ease of administration.

This is where SAP, Epic, Oracle, and the other systems on the Provisioning Hell Index ended up. Not because of bad design - because compliance requirements accumulated faster than anyone could simplify them.

SOX and financial systems

The Sarbanes-Oxley Act (SOX) fundamentally shaped how financial software handles permissions.

The requirement: Segregation of Duties (SoD). The same person cannot perform conflicting actions - like creating a vendor AND approving payments to that vendor. This prevents fraud.

The implementation: Every financial transaction gets broken into atomic permission units. In SAP, these are "authorization objects" with specific activity codes:

• ACTVT 01 = Create
• ACTVT 02 = Change
• ACTVT 03 = Display

A simple task like "manage vendors" becomes a matrix:

• Create Vendor (FK01) - requires ACTVT 01
• Change Vendor (FK02) - requires ACTVT 02
• Display Vendor (FK03) - requires ACTVT 03

Now multiply by every business object (vendors, customers, purchase orders, invoices, payments, journal entries...) and every organizational dimension (company codes, plants, cost centers...).

The result: SAP has thousands of authorization objects. Configuring a role means navigating a tree of these objects, setting specific field values for each. Miss one, and the user gets "Access Denied." Set one wrong, and you've created a SOX violation that auditors will flag.

IT admin quote: "From my experience we had to deal with s_actvt remediations a lot... getting specific with the values (removing * wildcard values) and work with the trace analysis results."

HIPAA and healthcare systems

The Health Insurance Portability and Accountability Act (HIPAA) requires healthcare organizations to protect patient information. Only people with a legitimate need should access a patient's records.

The requirement: Need-to-know access. A cardiologist shouldn't see psychiatry notes unless there's a clinical reason. A billing clerk shouldn't see clinical details beyond what's needed for coding. Access should be limited by role, location, and care relationship.

The implementation: Epic's security is defined at six hierarchical levels:

1. System Definitions (global defaults)
2. Service Area (clinical vs administrative)
3. Location (hospital, clinic, department)
4. Department (cardiology, surgery, ED)
5. Security Class (physician, nurse, clerk)
6. User (individual overrides)

Each level can override the levels above it. A user's actual access is "compiled" from the intersection of all these layers.

The result: Troubleshooting why a physician can't see a particular tool requires tracing through six layers of configuration to find which one is blocking access. Adding a new physician means configuring settings at multiple levels and verifying the compiled result matches intent.

Epic requires formal certification training - often weeks - before administrators can touch security. This isn't gatekeeping; it's recognition that misconfiguration can mean a provider can't access critical information during an emergency, or conversely, that sensitive records are exposed to people who shouldn't see them.

IT admin quote: "Check her department role overrides and verify they are working as intended. Check her Stork security class to verify that she has access to these tools."

Why it won't simplify

Here's the uncomfortable truth: these systems can't get simpler without removing compliance protections.

SAP can't collapse its authorization objects without breaking SOX segregation. If "Manage Vendors" becomes a single permission, you can no longer prevent the same person from creating and paying vendors.

Epic can't flatten its hierarchy without breaking need-to-know access. If location-based restrictions go away, any provider could see any patient's records regardless of care relationship.

Oracle can't unlock its seeded roles without breaking upgrade paths. If customers modify core roles, Oracle can't safely apply patches and updates.

The complexity exists because the business requirements demand it. The regulations aren't going away. The compliance audits aren't getting less rigorous. And every year, new requirements add more dimensions to the permission matrix.

The systems will stay complex. The only question is whether your IT team navigates that complexity manually, or whether something else handles it for them.

The compliance tax breakdown

Each regulation added legitimate requirements. Each requirement added permissions. Each permission added complexity. Over 20-40 years, the systems became what they are today: powerful, compliant, and incredibly difficult to administer.

What this means for IT

If you work in a regulated industry - finance, healthcare, government, or any company handling sensitive data - your core systems were built to satisfy auditors, not to make your job easier.

That's not going to change. The compliance requirements exist for good reasons. The permission granularity protects the business from fraud, protects patients from privacy violations, protects customers from data breaches.

But the cost of that protection falls on IT. Every new hire needs permissions configured across systems that have thousands of possible settings. Every role change requires navigating permission matrices that no single person fully understands. Every audit requires proving that the right people have the right access - and only the right access.

The compliance tax isn't the regulations themselves. It's the hours your team spends translating those regulations into correctly-configured permissions, over and over, for every user.

Stitchflow handles the complexity

Stitchflow delivers SCIM-level provisioning through resilient browser automation, backed by 24/7 human in the loop. We build the integration. We maintain it. <$5K/app/year.

For compliance-driven systems like SAP, Epic, and Oracle - we map the permission structures once. We understand which authorization objects map to which job functions. We know which hierarchy levels need configuration and which can use defaults.

You assign groups in Okta. We translate those assignments into correctly-configured permissions across systems that were built for compliance, not for ease of administration.

The regulations aren't going away. The complexity isn't going away. But the hours your team spends navigating it can.