IGA Compliance, SoD, and the Role Metadata Model - A Deep Dive

Introduction

When you work with Identity Governance and Administration (IGA) at enterprise scale - hundreds of applications, thousands of roles, millions of entitlements - you quickly discover that the hard part is not only connecting systems. The hard part is making access objects governable.

IGA platforms can run access certifications, evaluate Segregation of Duties, produce audit evidence, and surface access risk. But all of that depends on metadata: SOX Criticality, Sys Criticality, Risk, Confidentiality, Privileged flags, Functions, Rulesets, and SoD rules.

Those fields can look like simple labels in a governance tool. Architecturally, they are the governance substrate. They determine which access is reviewed more often, which access creates conflicts, which violations require mitigating controls, and which evidence can be shown to auditors.

This article explains how those concepts fit together in IGA generally. Where a concrete implementation helps, it uses Saviynt as an example because its Functions, Rulesets, risk metadata, and SoD model make the architecture visible.

Role-Level Risk Metadata in IGA

Every role, entitlement, group, permission set, or privileged access object can carry risk classification metadata. The exact field names differ by platform, but the governance dimensions are common.

Two of the most operationally significant dimensions are SOX Criticality and Sys Criticality.

SOX Criticality

SOX Criticality flags whether an access object gives access to systems or functions under Sarbanes-Oxley scope.

Practically, this applies to access that can affect financial reporting: posting invoices, approving payments, changing vendor master data, modifying GL accounts, or administering financial systems.

SOX-critical access is usually reviewed more frequently in certification campaigns and may require a stronger reviewer model, such as compliance, audit, or a control owner rather than only the line manager.

Scope: Regulatory - specifically financial controls under SOX.

Saviynt example: Saviynt exposes this concept through fields such as soxcritical on roles and entitlements.

Sys Criticality

Sys Criticality classifies access by IT and security blast radius, independent of SOX. Admin roles, privileged access, production write access, security infrastructure access, and sensitive platform access usually sit at the high or critical end. Read-only reporting roles usually sit lower.

Sys Criticality drives internal risk scoring, SoD sensitivity, certification prioritisation, and dashboards for security and IAM teams.

Scope: Operational - IT and security risk regardless of regulatory framework.

Saviynt example: Saviynt exposes this concept through fields such as syscritical.

Other metadata fields, such as Risk, Privileged, and Confidentiality, serve the same broader purpose. They provide the context that lets an IGA platform decide how access should be reviewed, escalated, scored, and explained.

The important point: these fields do not usually grant or revoke access by themselves. They influence the governance behavior around access.

The Classification Problem at Scale

This is where theory meets reality.

At enterprise scale, manually classifying every access object with SOX Criticality, Sys Criticality, Risk, and Confidentiality is not feasible. The reasons are structural.

1. No single owner knows everything. Who knows whether a specific SAP entitlement is SOX-critical? Usually the SAP finance team. Who knows whether an AWS IAM role is Sys-critical? Usually the cloud or platform team. IGA sits in the middle, but it does not naturally hold the business meaning for every system it governs.

2. Import does not carry context. When an IGA platform imports entitlements from a connected system, it usually receives technical data: name, ID, account mappings, descriptions if available, and endpoint metadata. It does not automatically receive business meaning. A role called FI-AP-INVOICE-POST in SAP carries useful semantic hints. A role called role-12847 in an internal tool carries almost none.

3. Maintenance is harder than initial setup. Even if 100,000 entitlements are classified correctly today, new ones appear constantly. Roles change. Applications are renamed. Business processes move. Without a repeatable classification pipeline, the metadata goes stale quickly.

4. Business owners often do not speak IGA language. Ask an application owner whether an entitlement is SOX critical, and many will not know how to answer. They may understand what the access does, but not how to translate that into governance metadata.

How Organisations Actually Solve It

Most mature programmes use a mix of imperfect but practical techniques:

• Risk-based scoping: Classify entitlements deeply only in systems actually under SOX or high-risk scope, such as SAP FI/CO, Oracle Financials, Coupa, or payment platforms.
• Inheritance from system level: Classify the application once, then let entitlements inherit baseline risk unless overridden.
• Naming pattern heuristics: Auto-classify based on patterns such as ADMIN, WRITE, DELETE, FINANCE, AUDIT, APPROVE, or PROD.
• Crowdsourcing via certifications: Ask certifiers to confirm or correct metadata during review cycles, improving quality over time.
• Focused data quality: Classify the top 5-10% of highest-risk entitlements well, while leaving low-risk access at documented defaults.

Auditors generally accept a risk-based approach if it is documented, consistently applied, and backed by evidence.

The Compliance Landscape IGA Supports

IGA platforms support compliance through common underlying mechanisms: access certifications, Segregation of Duties controls, audit trails, risk metadata, approval history, revocation evidence, and reporting.

Different frameworks look at those mechanisms through different lenses.

SOX - Sarbanes-Oxley

SOX is a US financial regulation requiring controls over systems that affect financial reporting. In IGA, SOX relevance typically appears through risk metadata, certification scoping, SoD rules, control owner reviews, and audit evidence.

Practically, SOX access includes the ability to post invoices, approve payments, change vendor master data, modify financial configuration, or administer systems that support financial reporting.

ISO 27001

ISO 27001 is an international certification standard for an Information Security Management System. Organisations are audited against it and receive a certificate from an accredited body.

IGA supports ISO 27001 evidence through access control documentation, periodic access reviews, approval history, revocation evidence, and audit trails.

NIST

NIST provides US government security guidelines, especially NIST SP 800-53 and the Cybersecurity Framework. It is generally not a commercial certification in the same way ISO 27001 is, but it is used heavily for internal security rigour and government-aligned control programmes.

IGA contributes to NIST-style controls through identity lifecycle governance, access review evidence, privileged access visibility, least-privilege controls, and audit trails.

SOC 2

SOC 2 is an audit report issued by a licensed CPA firm. It evaluates controls against Trust Service Criteria such as Security, Availability, Processing Integrity, Confidentiality, and Privacy.

• Type I evaluates whether controls are designed correctly at a point in time.
• Type II evaluates whether controls operated effectively over a period, usually 6-12 months.

SOC 2 is especially relevant for SaaS and cloud providers because enterprise customers use it as assurance that customer data is handled properly. IGA contributes evidence for access reviews, approval workflows, least privilege, revocation, and administrative access controls.

Practical Positioning

The important architectural point is that these frameworks do not require completely separate IGA mechanisms. They reuse the same foundation: access metadata, certifications, SoD controls, audit trails, and evidence.

Segregation of Duties - The Core Governance Mechanism

Segregation of Duties is the principle that no single person should be able to execute a complete high-risk business process end-to-end without a check.

The classic example: the person who can create a vendor should not also be the person who approves payment to that vendor.

IGA platforms support SoD in two broad modes:

• Preventive SoD: Evaluated at access request time to stop or challenge new risky combinations.
• Detective SoD: Evaluated in batch against existing access to detect drift, inherited conflicts, or previously approved exceptions.

The SoD Model - Functions, Risk Rules, Rulesets

Most mature SoD models have three conceptual layers: Functions, Risk Rules, and Rulesets. Different platforms use different names, but the structure is common.

Layer 1: Function

A Function is the abstraction layer between raw entitlements and SoD rules. It represents a discrete business action.

Examples:

• “Accounts Payable Posting” maps to SAP t-codes such as FB60, FB65, or an entitlement like FI-AP-INVOICE-POST.
• “Vendor Master Change” maps to actions such as MK01 or MK02.
• “Payment Approval” maps to approval or payment-run capabilities such as F110.

The Function layer exists because SoD rules cannot be maintained directly against thousands of individual entitlements. Functions group access into business actions. When new entitlements are added, they can be mapped to the appropriate function and automatically participate in existing rules.

Saviynt example: Saviynt exposes Functions as importable SoD objects, often sourced from SAP GRC, Approva, or manually defined models. Implementations may use jobs such as FUNCTIONIMPORTJOB to import function metadata.

Layer 2: Risk Rule (SoD Rule)

A Risk Rule defines a conflict between functions:

If a user simultaneously holds Function A and Function B, the user has a violation.

Example:

• Function A: Accounts Payable Posting
• Function B: Accounts Payable Approval
• Risk Rule: AP Posting + AP Approval = high-risk SoD violation

Each rule has a name, description, risk level, and the conflicting functions. At request time, the violation can be surfaced in the access request UI. In detective mode, it appears in SoD reports and certification context.

Layer 3: Ruleset

A Ruleset is the governance container. It holds the Functions and Risk Rules for a given scope.

Ruleset  (e.g. "Global SoD Ruleset" or "SAP Finance SoD 2024")
    -> Risk Rules
        -> "AP Posting vs AP Approval" (High)
        -> "Vendor Create vs Vendor Approve" (High)
        -> "GL Posting vs GL Approval" (Critical)
            -> each rule references two Functions
                -> each Function maps to entitlements

Functions are scoped to a ruleset. The same business action can be defined differently in different rulesets. A “Vendor Master Change” function in an SAP-only ruleset may map only to SAP t-codes. In a cross-system ruleset, it may include SAP, Coupa, Ariba, or internal platform access.

Saviynt example: Saviynt supports built-in or imported rulesets, custom rulesets for non-SAP systems, and cross-system rulesets. Third-party SoD models can also be imported from tools such as SAP GRC or Approva.

Mitigating Controls

Not all SoD violations can be removed. When the business requires one person to hold conflicting access, a Mitigating Control is applied. Examples include monthly reconciliation, independent review, dual approval, monitoring reports, or temporary exception tracking.

Mitigating controls should have ownership, evidence, and time bounds. Temporary mitigations should expire and require renewal.

The Full SoD Evaluation Flow

When a user requests new access:

User requests entitlement or role
    -> IGA maps requested access to Functions
    -> IGA checks Functions the user already holds
    -> IGA compares the combination against Risk Rules
    -> Violation found?
        -> Yes: surface in request UI for rejection, justification, or mitigation
        -> No: proceed normally

For existing access:

Scheduled SoD evaluation runs
    -> evaluates active users against relevant rulesets
    -> writes violations to SoD violation records or reports
    -> surfaces conflicts in certifications and compliance reporting

Platform Evaluation vs Third-Party Evaluation

An IGA platform may run its own SoD evaluation and also import violation results from an external SoD engine. Both can appear in access request conflict panels and reports.

This matters at scale. If SAP GRC already owns the SAP SoD ruleset, you usually do not rebuild the entire SAP model in the IGA platform. You import or consume the SAP GRC view and layer platform-native evaluation on top for non-SAP and cross-system governance.

The LLM Classification Opportunity

The classification problem is a natural fit for LLM assistance, but the role of the model should be precise.

The task is bounded: classify structured access objects using names, descriptions, endpoint context, existing classified examples, and surrounding governance data. Outputs can be constrained to values such as High/Medium/Low, True/False, or candidate function mappings.

One practical architecture:

IGA platform
  -> read unclassified roles, entitlements, and existing classified examples
  -> enrich context with endpoint, system type, owner, descriptions, and SoD mappings
  -> LLM classifier / reviewer
      -> output: soxcritical, syscritical, risk, confidentiality, candidate function, explanation, confidence
  -> decision router
      -> high confidence: propose or auto-apply where policy allows
      -> medium confidence: human review queue
      -> low confidence: manual classification
  -> write-back with provenance and audit note

Key advantages:

• LLMs generalise across many application naming styles better than static rules alone.
• Explanations help certifiers and auditors understand why a classification was proposed.
• Nightly classification can catch newly imported access before metadata drift becomes permanent.
• The same model can help propose Function mappings, not only risk labels.

What to validate first:

1. Can the IGA platform update the relevant metadata fields safely without provisioning side effects?
2. Which fields can be auto-applied, and which must remain human-approved?
3. Will auditors accept LLM-proposed plus human-approved classifications for SOX-scope access?
4. How will provenance be stored so reviewers can distinguish manual, inherited, rule-based, and LLM-assisted classifications?

The strongest AI story is not “let the LLM be the authority.” The stronger story is: let the LLM accelerate classification, detect weak metadata, explain risk, and route uncertain cases to humans.

Connecting the Dots

The full governance chain looks like this:

Access object imported from connected system
    -> metadata assigned or inherited:
       soxcritical, syscritical, risk, confidentiality
    -> entitlement mapped to Function inside a Ruleset
    -> Function paired with conflicting Function in a Risk Rule
    -> SoD evaluated at request time and in scheduled batch runs
    -> violations surfaced in certifications and compliance reports
    -> approved exceptions tied to Mitigating Controls
    -> evidence exported for SOX, ISO 27001, SOC 2, and internal audit

This is why metadata quality matters so much. If the role is not classified correctly, certification scope is wrong. If the entitlement is not mapped to the right Function, SoD results are incomplete. If the violation is not linked to a mitigating control, audit evidence is weak.

IGA platforms can govern metadata once it exists. The harder problem is getting accurate business meaning into the platform early enough and reliably enough.

That is where the next architectural step appears: source-side governance metadata. Instead of asking the IGA platform, IAM team, or an LLM to infer all meaning after import, the system that creates the access object should carry a machine-readable declaration of what the access does.

That is the idea behind IGTS - Identity Governance Tagging Standard: make governance meaning explicit at the source, then let IGA parse, validate, and govern it.

Key Takeaways

1. IGA metadata is the governance substrate. SOX Criticality, Sys Criticality, Risk, Privileged, Confidentiality, Functions, and Rulesets determine how access is reviewed, scored, challenged, and evidenced.

2. Compliance frameworks reuse the same underlying IGA mechanisms. SOX, ISO 27001, NIST, and SOC 2 all depend on access controls, certifications, SoD controls, audit trails, and evidence - just evaluated through different lenses.

3. Classification is the scaling bottleneck. Enterprises do not fail because IGA platforms lack fields. They fail because business meaning is missing, stale, or maintained after the fact.

4. Functions make SoD manageable. Without Functions, every entitlement combination must be considered directly. With Functions, raw access maps to business actions and Risk Rules operate at the right abstraction level.

5. Rulesets make SoD governable. They scope Functions and Risk Rules to a system, process, domain, or cross-system control model.

6. SoD must be both preventive and detective. Preventive controls stop new risky combinations. Detective controls catch inherited access, drift, exceptions, and historical violations.

7. LLMs are useful, but better as accelerators than authorities. They can propose classifications, detect inconsistencies, explain risk, and support human review. For audit-sensitive access, provenance and approval remain essential.

8. The future is source-side metadata. The highest-confidence model is to capture governance meaning when access is created, then let IGA consume and enforce it.

Further Reading

• Identity Governance and Administration overview
• SOX, ISO 27001, NIST, and SOC 2 control framework references
• IGA platform documentation for risk metadata, certification campaigns, SoD evaluation, Functions, Rulesets, and mitigating controls
• IGTS - Identity Governance Tagging Standard - source-side governance metadata