STOA Scenario Pack

PLATFORM ROLE-BASED ACCESS.

Define system, tenant, client, vendor, and assignee access layers so users see only what they need, responsibilities survive role changes, and every sensitive action is auditable.

7
Users
4
Triggers
42
Cards
82
Quality Score
↓ Scroll to explore
01

The Users

Seven role families operate across layered boundaries: system, tenant, client, vendor, and assignee portal. Each needs a fixed permission baseline, scope boundary, and audit behaviour.

Actor · Gallagher · Admin Tier
Platform Administrator
Gallagher's internal platform admin who manages tenant-level configuration: creates and modifies roles, assigns permission sets, manages SSO/IdP integration, configures MFA policies, and audits access logs. Has full system access but operates under change-management controls — all role changes are logged and require a second admin to approve in production.

Scope: All tenants · All settings · Dual-approval required
Permissions: Full access to all 11 platform capabilities including user/role management, audit logs, SSO config, and API access.
Actor · Gallagher · Operator Tier
Service Delivery Consultant
Gallagher's operational consultant who manages day-to-day assignment coordination for specific clients. Has read/write access to assignee records and workflow actions for their assigned client portfolio only. Cannot access platform admin settings, other consultants' client portfolios, or billing/contract data.

Scope: Assigned client portfolio only
Permissions: View/edit assignees (portfolio-scoped), read policies, read financial data, scoped API access. No approval, user management, audit log, or SSO access.
Actor · Client · Admin Tier
Client Organisation Admin
The client's designated admin (typically IT or senior HR) who manages their organisation's users within the platform. Can invite/remove users, assign roles within their tenant, configure approval workflows, and view audit logs for their organisation. Cannot access other client tenants or modify platform-level settings.

Scope: Own tenant only · User management · Approval config · Audit logs
Permissions: Full assignee access (tenant), tenant-scoped export, full policy config, tenant user/role management, tenant audit logs, read-only SSO, full financial data, tenant API access.
Actor · Client · Operator Tier
HR Manager / Mobility Lead
Client-side HR professional who manages assignee records, initiates and approves assignments, runs reports, and configures policy parameters within their granted scope. Sees all assignees in their business unit or region. Cannot modify RBAC settings, SSO configuration, or access other business units unless explicitly granted cross-unit visibility.

Scope: Business unit or region
Permissions: View/edit/approve assignees (BU/region), opt-in export, read policies, BU-scoped financial data and documents, scoped API access. No user management, audit logs, or SSO access.
Actor · Client · Consumer Tier
Assignee (End User)
The relocating employee who accesses the self-service portal to view their assignment details, upload documents, track relocation milestones, and submit expense claims. Sees only their own data. Cannot view other assignees, access admin panels, or modify policies.

Scope: Own data only
Permissions: View own assignee record, edit own PII, export own data, upload own documents. No policy config, user management, audit logs, SSO, financial data, or API access.
Actor · Client · Consumer Tier
Finance / Payroll Viewer
Client finance team member with read-only access to cost estimates, compensation data, tax equalisation reports, and budget dashboards. Cannot view personal assignee documents (passport, medical), cannot modify records, and cannot approve assignments.

Scope: Cost centre hierarchy · Read-only financial data · No PII access
Permissions: Financial data export (read-only), read-only API access. No assignee viewing, editing, approvals, policy config, user management, audit logs, SSO, or document/PII access.
Actor · Vendor · Scoped Tier
Vendor / Provider Portal User
A third-party provider that may update only the screens or milestones they are assigned to: household goods, destination services, immigration, tax, housing, or other provider-owned work. Vendor users must not see the full assignee page unless explicitly required.

Scope: Assigned provider work only
Permissions: Update scoped milestones, upload provider documents, view assigned tasks, no tenant-wide data, no unrelated assignee records, no financial exports unless contracted.
02

Starting Point

The current state of access control on the platform — the conditions that make a formalised RBAC system necessary.

Starting Context
Multi-tenant platform needs explicit layered access
The platform must support Gallagher system users, client tenant users, consultants scoped to specific clients, possible vendor portal users, and assignee portal users. Current thinking needs to move from broad role labels to explicit permission layers: system level, client/tenant level, vendor/provider scope, and assignee self-service. Data residency, retention, audit trail, API scoping, and responsibility reassignment all need to be designed up front.
03

Triggers

What kicks off the RBAC workflow — the events and actions that activate provisioning, modification, reassignment, and review cycles.

Trigger
Layered role hierarchy design and approval
Platform team defines system, tenant/client, vendor, and assignee access layers. Each role has a documented permission matrix covering data scope, action permissions, UI visibility, API access, reporting access, and audit visibility.
Trigger
Permission provisioning workflow activated
When a user is invited, SSO-provisioned, assigned to a client, added to a vendor scope, or given assignee portal access, the system grants only the relevant layer and permission set. No access should rely on informal project knowledge.
Trigger
Access review cycle initiated
Every review checks active accounts, inactive users, vendor access, client changes, consultants assigned to clients, and whether each user still needs their current permission set. Reviews should also confirm data-retention and residency obligations.
Trigger
Case ownership or access is withdrawn
When a consultant, client user, vendor user, or admin loses access, active responsibilities must be reassigned before work disappears. Revocation should remove access immediately and route open tasks to a named replacement or queue.
04

Expected Outcomes

What must be true when RBAC is fully implemented — the observable results that prove the access control system is working.

Expected Outcome
Tenant isolation enforced at every layer
Every API request, database query, and UI render is scoped to the authenticated user's tenant. A user in Client A's tenant can never retrieve, modify, or even detect Client B's data — regardless of direct API calls, URL manipulation, or parameter tampering. Enforced at the middleware layer, not just the UI.
Expected Outcome
Least-privilege access by default
New users receive the minimum permission set for their role. No role includes admin or export permissions by default. Elevated permissions require explicit opt-in by the Client Org Admin with documented justification. The system warns when a user has permissions exceeding their role's baseline.
Expected Outcome
Complete audit trail for all access changes
Every permission change — role assignment, modification, user activation/deactivation, escalation — is captured in an immutable audit log with: who, what (before/after), when, and from which IP/session. Retained for 7 years. Client Org Admins view their tenant's log; Platform Admins view cross-tenant logs.
Expected Outcome
Role changes propagate in real-time
When a user's role is changed or revoked, the change takes effect immediately — active sessions are invalidated, cached permissions flushed. No grace period allows a revoked user to continue accessing resources. SSO group membership changes sync within 5 minutes via SCIM or webhook.
Expected Outcome
Permission matrix documented and testable
A complete permission matrix maps every role to every platform capability. Version-controlled, reviewed quarterly, and enforced by automated integration tests. Any code change that modifies permission boundaries must update the matrix and pass permission regression tests.
Expected Outcome
Active responsibilities are reassigned before access is removed
When a user's access is revoked, cases, tasks, approvals, provider updates, and open escalations move to a named replacement or managed queue. Nothing falls into the void because someone left, changed role, moved client portfolio, or lost permissions.
Expected Outcome
Vendor and assignee access stay screen-scoped
Vendors can update only assigned screens or provider tasks, and assignees can see only their own portal view. Neither role can infer broader assignment, tenant, financial, or unrelated provider data.
05

Guardrails

What must never happen — the hard boundaries that protect client data, prevent privilege abuse, and ensure regulatory compliance.

Must Not Happen
Cross-tenant data leakage
A user in one client tenant must never access, infer, or enumerate data belonging to another tenant — via API, UI, error messages, search results, autocomplete, or export. Cross-tenant leakage is a critical security incident that breaches contracts and potentially violates GDPR, SOC 2, and data residency requirements.
Must Not Happen
Privilege escalation without approval
No user may grant themselves a higher permission level, modify their own role, or bypass role restrictions through API manipulation, direct database access, or URL parameter injection. Self-service role changes are architecturally impossible, not just policy-prohibited. All escalation requires a different authorised approver.
Must Not Happen
Orphaned accounts with active access
When an employee leaves a client organisation, their platform access must be revoked within 24 hours. Deprovisioning must be triggered automatically via SCIM/HRIS sync or manually by the Client Org Admin. Accounts deactivated in the identity provider but still active in the platform represent a security gap that must not persist beyond one sync cycle.
Must Not Happen
Permission changes without audit capture
No role assignment, permission modification, or access change may occur without being recorded in the immutable audit log. If the audit system is unavailable, the permission change must be queued or blocked — never silently applied. Audit gaps are treated as security incidents.
Must Not Happen
Active case work loses an owner after revocation
Access removal must not leave case tasks, approvals, vendor updates, data requests, or client communications unassigned. If the replacement owner is unknown, the work must route to a managed queue and alert a service delivery manager.
Must Not Happen
Data residency, retention, or deletion obligations are bypassed
Client data must not be stored, processed, exported, retained, or deleted in a way that conflicts with contract, residency, retention, or evidence requirements. Deletion and retention events need attestable proof, not just a hidden database change.
06

Evidence

Measurable signals that prove the RBAC system is working — from penetration testing to provisioning speed.

Evidence
Zero cross-tenant access violations
Measure: Cross-tenant data access attempts that succeed during quarterly penetration tests.
Target: Zero. Any non-zero result triggers a P0 security incident.
Source: Penetration test reports and automated tenant isolation test suite.
Evidence
Provisioning time under 5 minutes
Measure: Time from user creation to confirmed, correct permissions.
Target: Under 5 minutes (SSO auto-provisioned) · Under 48 hours (manual invite, includes admin confirmation).
Source: Platform provisioning logs.
Evidence
Access review completion rate above 95%
Measure: Percentage of quarterly access reviews completed within the 14-day window.
Target: 95% of client tenants complete their access review on time.
Source: Access review workflow system.
Evidence
Full activity audit trail answers who did what and when
Measure: Percentage of sensitive actions with actor, tenant, affected record, before/after state, timestamp, and source channel captured.
Target: 100% for permission, case, financial, provider, and data-export changes.
Source: Immutable activity audit log and client/internal audit report.
Evidence
Data residency and deletion evidence is reportable
Measure: Client can identify where data is hosted, retention rule applied, deletion status, and relevant incident/recovery procedures.
Target: Available for every client tenant before production go-live.
Source: Tenant configuration, retention jobs, deletion attestations, and security documentation.
07

Risks

Concrete failure modes that could undermine the access control system — each with a specific mitigation strategy.

Risk
SSO group mapping drift causes role misassignment
If the client's identity provider group structure changes (reorg, group renaming, nested group changes) without corresponding platform updates, users may receive incorrect roles. Mitigation: validate group mappings during each quarterly access review, alert when unmapped groups are detected, maintain a fallback "minimum access" role for unmapped users.
Risk
Role proliferation makes permissions unmanageable
If clients request too many custom roles (per-department, per-country, per-project), the hierarchy becomes unmanageable and hard to audit. Mitigation: limit custom roles to 10 per tenant, provide composable permission sets instead of monolithic roles, require annual role consolidation reviews.
Risk
Emergency access bypasses standard controls
In production incidents, engineers or admins may need emergency elevated access that bypasses normal approval. If the break-glass process is poorly defined, it creates an unaudited backdoor. Mitigation: formal break-glass procedure with automatic time-limited escalation (max 4 hours), mandatory post-incident audit, and automatic de-escalation.
Risk
Data residency conflicts block client adoption
A client may object to data being stored or processed in the wrong region, or to support access from an unapproved geography. Mitigation: tenant-level data residency metadata, region-aware admin rules, and documented answers for client security review.
Risk
Pen-test and security evidence is hard to share
Clients may request penetration testing, incident recovery, hosting, or security documentation, but some evidence may require NDA or careful redaction. Mitigation: create an approved security evidence pack and a controlled process for client-facing disclosure.
08

Decisions & Open Questions

Architectural decisions already made and questions that still need judgment before the RBAC system can be fully locked down.

Decision · Accepted
Adopt layered access with composable permissions
Implement system-level, client/tenant-level, consultant/client-portfolio, vendor/provider, and assignee portal scopes. Each role has a fixed baseline across platform capabilities: assignee data, approvals, exports, policy config, user management, audit logs, SSO/MFA, financial data, API access, provider updates, and PII/document access.
Decision · Accepted
Enforce tenant isolation at the middleware layer
Tenant scoping is implemented as a mandatory middleware filter on every API route — not optional application logic. Every database query is automatically scoped by tenant ID from the authenticated session. Middleware enforcement makes cross-tenant access architecturally impossible regardless of developer error.
Decision · Accepted
Treat audit, retention, and residency as platform requirements
Audit trails, data-retention rules, deletion evidence, hosting location, and client security documentation are not optional reporting extras. They must be designed into the access model because client trust and contract review depend on them.
Open Question · Product + Security
Should consultants have client-specific permissions?
Current design gives all Service Delivery Consultants the same permission set, scoped to their assigned clients. But some clients want consultants to have restricted access (e.g., no financial data for one client, full access for another). Should consultant permissions be per-client configurable?
Open Question · Legal + Engineering
How should data residency affect role architecture?
Some clients require data to remain in specific regions (EU, APAC). If the platform expands to multi-region deployment, should RBAC roles be region-aware? Can a US-based Platform Admin manage an EU tenant's configuration, or does data residency require region-scoped admin roles?
Open Question · Security + SRE
What is the break-glass process for production emergencies?
Options: (A) time-boxed admin token with automatic expiry, (B) dual-key approval from two Platform Admins, (C) dedicated emergency role activated via PagerDuty/incident management integration. Each has different audit and speed trade-offs.
Open Question · Product + Service Delivery
Which vendor and assignee portal roles are in MVP?
If vendor portal access or assignee portal access is included, define which screens they can update, which provider categories are first, and whether vendor users are assigned by Gallagher, client admins, or the provider organisation.
09

Scenario Quality Score

Completeness assessment of this scenario based on STOA card coverage.

82
out of 100
Strong — layered access model
7
The Users
1
Starting Point
4
Triggers
7
Outcomes
6
Guardrails
5
Evidence
5
Risks
3
Decisions
4
Open Questions