"Every IGA programme eventually hits a brick wall. IGTS is how you break through it."

The Problem: The Mapping Nightmare

Identity Governance and Administration (IGA) has a scaling problem. We build beautiful certification campaigns, robust workflows, and complex Segregation of Duties (SoD) matrices. But underneath the shiny interface, the engine relies on a fundamental, flawed assumption: that we can accurately map millions of granular, disparate technical entitlements back to business functions.

When a new API role is created in AWS, or a new permission set is deployed in Salesforce, the IGA platform doesn't know what it means. It just sees strings: IAM-Role-7824 or Del_Cust_Rec. The burden of translation falls entirely on the IGA administrator — or increasingly, an error-prone LLM inference engine — to manually classify these entitlements against the SoD matrix.

The result? Rule bloat. A typical enterprise IGA deployment requires tens of thousands of custom SoD mapping rules. It is slow, brittle, and provides dangerously low confidence during audits.

$ cat /var/iga/entitlements.log | head -5
IAM-Role-7824  ·  Del_Cust_Rec  ·  A_FIN_INV_APPROVER  ·  PROD-DB-ADMIN-RO  ·  GRP_FINANCE_AP_003
Raw Entitlements
(cryptic strings)
Manual Rules
10,000+ mappings
IGA Engine
slow · brittle
⚠ Low audit confidence  ·  Rule bloat  ·  Brittleness on every schema change

The Core Blueprint: The IGTS Tag

The Identity Governance Tagging Standard (IGTS) flips the paradigm. Instead of the IGA engine trying to interpret raw entitlements after they are created, the source system embeds a standardised, machine-readable tag directly into the identity object at the moment of creation.

Click each segment below to explore the tag anatomy:

igts/v1/
finance
accounts-payable
critical
inscope
post
financial
permanent

Domain

The high-level business area that owns this entitlement. Drives top-level SoD scoping and certification routing.

finance hr tech legal sales ops

Process

The specific business process within the domain. SoD rules are evaluated at this level — process + function = conflict detection.

accounts-payable vendor-master general-ledger payroll deployment

Sensitivity

Risk level of the system or data touched by this entitlement. Drives certification frequency, approver tier, and monitoring intensity.

critical high medium low

SOX Scope

Whether this entitlement is in scope for Sarbanes-Oxley (or equivalent regulatory compliance). Determines audit evidence requirements.

inscope outscope

Function

The action being performed. This is the SoD engine's primary conflict axis — post vs approve in the same process = violation.

post approve read create delete configure

Data Class

The type of data accessed. Feeds data governance, privacy controls, and DORA article obligations around data confidentiality.

financial pii internal public operational

Lifecycle

Duration of the access grant. Temporary and emergency access require tighter review cycles and automatic expiry enforcement.

permanent temporary emergency

By adopting this standard, the source of truth is embedded within the entitlement itself. The IGA engine no longer needs to guess or rely on manual mappings. Classification becomes deterministic.

Why This Unlocks SoD

With IGTS tags flowing into the IGA platform, the SoD evaluation engine transforms from a complex web of custom rules into a stable, highly efficient conflict matrix based strictly on domain, process, and function.

If a user holds finance/accounts-payable/.../post/... and requests finance/accounts-payable/.../approve/... — the engine flags it instantly. No custom rules. No manual lookup. Just tag comparison.

Before IGTS

  • Tens of thousands of SoD rules
  • Manual entitlement classification
  • Rule logic owned by individuals
  • Brittle on system/schema changes
  • Low audit confidence
  • LLM inference as last resort

After IGTS

  • Clean domain × function conflict matrix
  • Tags embedded at source creation
  • Logic owned by the standard
  • Resilient to system changes
  • High audit confidence
  • LLM validates tags, not guesses

DORA: Five Gaps to Bridge

The Digital Operational Resilience Act (DORA) introduces strict new requirements for financial entities in the EU. Standard IGA practices, optimised for SOX compliance, fall short in five key areas. Here is how IGTS can be extended to bridge each gap.

1

Resilience Dimension (RTO/RPO)

DORA prioritises business continuity. A system might be out of SOX scope but still control critical banking infrastructure — it must be tagged for resilience tier so IGA can enforce stricter review cycles.

;rto=tier1
2

Third-Party & Vendor Concentration Risk

DORA Pillar IV demands strict management of ICT third-party risk. If an identity grants admin rights to a Critical Third-Party Provider (CTPP) or external MSP, that dependency must be explicit in the tag.

;vendor=azure;ctpp=yes
3

Elevating 'Read' Permissions

In standard SoD, function=read is low risk. Under DORA, read-only access to network topologies, IAM policies, or backup configs is a critical reconnaissance asset. The IGA engine must treat read on sensitivity=critical with elevated monitoring — a policy change, not a tag extension.

4

Non-Human Identities (NHIs)

DORA covers service accounts, CI/CD pipelines, and API integrations. The base lifecycle segment is human-centric. NHIs need explicit typing so IGA can apply appropriate governance, rotation policies, and audit trails.

;identity-type=service-account
5

Tag Integrity & Configuration Drift

IGTS tags reside in mutable fields — AD descriptions, Kubernetes annotations, database notes. A malicious actor could alter a tag to evade compliance detection. The IGA platform must cross-reference tag changes against SIEM and audit logs. Trust but verify.

Community Questions

IGTS is early-stage. These questions are worth debating with your team and across the IGA community. If you have an answer, an experience, or a challenge — open a GitHub issue and let's build the body of knowledge together.

Q Does your IGA platform support custom metadata fields for DORA extensions like ;rto=tier1 or ;vendor=azure;ctpp=yes? How do you store them today?
Q How do you handle tag integrity when entitlements live in mutable AD Description fields or freeform spreadsheet notes? What's your drift detection approach?
Q What's your approach to classifying NHIs — service accounts, CI/CD tokens, API keys — in the IGTS taxonomy? Same segments, or a parallel namespace?
Q Are your auditors asking for IGTS-style structured evidence yet? What does that conversation look like?