Group identity tenancy — extend KSA Entra ID vs separate India tenant with B2B federation.it.decisions.d02

P0 G

Summary

Drives every SSO integration and license model. Decision owner (sheet): IT Head + CISO. Sheet target: Wk 2.

Rationale prompt skeleton

Capture the rationale for this decision. Sheet-recorded justification: "Drives every SSO integration and license model.". Reference the evidence questions, name the alternatives considered, and explain how this decision propagates to design, BoM, and operating model.

Default options (2)

extend_ksa_tenant Extend KSA Entra ID tenant

Single Entra ID tenant rooted in KSA; subsidiaries (incl. India GCC) added as domains/branches.

Pros

+ Single SSO surface
+ Easier conditional access
+ Lower licensing total

Cons

− Single blast radius
− Cross-border data implications
− Compliance review needed (PDPL / India DPDP)

b2b_federation B2B federation across separate tenants

Each holding/subsidiary keeps its own tenant; cross-tenant guest / B2B trust for shared apps.

Pros

+ Smaller per-tenant blast radius
+ Cleaner residency posture

Cons

− More SSO surfaces to maintain
− Conditional access fragmentation
− Higher operational toil

Default approval chain

Admin
ExecutiveViewer

Linked evidence questions (3)

id	prompt	workstream
it.identity_security.q01	Identity provider(s) in use across the group — Entra ID (Azure AD), Okta, on-prem AD, Google. Tenant model: one tenant for everything, per-holding, per-subsidiary?	it.identity_security
it.identity_security.q02	Confirm preferred identity model: extend KSA Entra ID tenant to subsidiaries (and to India GCC) vs. B2B federation across separate tenants. Driver: compliance / license / blast radius.	it.identity_security
it.gcc_context.q03	Identity tenancy decision — extend KSA Entra ID to India, or separate India tenant with B2B federation?	it.gcc_context