Identity work is usually spread across directory administrators, the service desk, security, HR and application teams, and nobody owns the outcome end to end. The result is predictable: access decisions made by IT on behalf of a business that never agreed them, service accounts with no owner, and an IGA platform run by one overloaded engineer. This guide sets out how to design an identity team operating model: the services the team provides, the organisational patterns that work, the roles and skills required, a RACI for the core processes, how to size and source the team, and how to measure whether it is working. It is written for identity leaders, CISOs and CIOs restructuring identity, and for HR partners doing the workforce planning.
Key takeaways
- Define services before structure: list what the identity function delivers (lifecycle, authentication, access governance, privileged access, federation, non-human identity) and only then decide how to organise people around it.
- The business owns access decisions: process and data owners are accountable for who should have access; the identity team is responsible for the tools and processes that enforce it, not accountable for the decisions.
- Hub and spoke suits most organisations: a central team owns platforms, standards and policy, while named contacts in application, cloud and HR teams carry out the work locally.
- Size from workload drivers, not ratios: there is no authoritative staff-to-user ratio; size from applications to onboard, lifecycle event volume, review campaigns, privileged estate and non-human identity count.
- Identity is a specialist skill set: work roles, competency levels and vendor-neutral training stop identity tasks falling to people with only product knowledge.
Start with a service catalogue
An operating model describes how a function delivers its services. The US Federal ICAM (FICAM) Architecture is a useful, vendor-neutral starting point because it already breaks identity into domains and services. Adapt it, and add the areas FICAM covers lightly, such as customer identity and non-human identity.
| Domain | Services (FICAM naming where it exists) | Typical output |
|---|---|---|
| Identity management | Creation, identity proofing, provisioning, maintenance, identity aggregation, deactivation | Accurate identities from authoritative sources, timely joiner and leaver handling |
| Credential management | Sponsorship, registration, generation and issuance, maintenance, revocation | MFA enrolment, smart cards, certificates, recovery processes |
| Access management | Digital policy administration, authentication, authorisation, privileged access management | SSO, conditional access policy, PAM, authorisation models |
| Federation | Policy alignment, authentication broker, attribute exchange | Partner and B2B access, cross-tenant trust |
| Governance | Identity governance, analytics, mitigation | Access reviews, role management, segregation of duties, identity threat detection |
| Non-human identity (addition) | Inventory, ownership, credential rotation, decommissioning | Owned service accounts, workload identities and agent identities |
| Customer identity (addition, if in scope) | Registration, authentication, consent, account recovery | CIAM platform run with product teams |
For each service, record its owner, its consumers, its service levels (for example leaver processing within a defined time of the HR termination) and the platform it depends on. This catalogue becomes the scope document for every later decision.
Organisational patterns
| Pattern | How it works | Strengths | Weaknesses | Fits |
|---|---|---|---|---|
| Centralised | One identity team does all design, engineering and operations | Consistency, clear accountability, deep expertise | Bottleneck for application teams; can drift from the business | Small and mid-sized organisations, early-stage programmes |
| Federated | Each business unit or region runs its own identity function to shared standards | Close to the business, scales with autonomy | Inconsistent controls, duplicated tools, weak enterprise view | Conglomerates after acquisitions, until consolidation |
| Hub and spoke | Central team owns platforms, policy and standards; spokes in application, cloud, HR and regional teams carry out local work | Balance of consistency and scale; clear escalation | Spokes need training and time allocation, or the model exists on paper only | Most large organisations |
| Platform team | Identity treated as an internal product with self-service APIs and paved paths | Scales well for engineering-led organisations and cloud workloads | Needs strong product management; governance can be under-served | Software and cloud-native companies, workload and agent identity |
Where identity reports also matters. Common lines are into the CISO (strongest on risk and privileged access), the CIO or infrastructure (strongest on operations and directories) or a split, with engineering under the CIO and governance under the CISO. Splits work only with a single identity strategy and a shared roadmap; otherwise the two halves buy different tools. The IDPro Body of Knowledge workforce planning article recommends that the identity programme manager reports to an executive. See the Security Operating Model and Organisation Design Guide.
Accountability: who decides access
André Koot's IDPro article on strategic alignment and access governance makes the point that authorisation management is not an IT responsibility: IT provides tools, while process owners are accountable for access policy such as segregation of duties rules. He advises creating roles and business rules only when a named business stakeholder is accountable for them, and describes the IGA product owner as responsible but not accountable for authorisations. Build the RACI on that principle.
| Process | Identity team | Business / process owner | Line manager | HR | Application owner | Security / risk |
|---|---|---|---|---|---|---|
| Define roles and access policy | R | A | C | I | C | C |
| Approve access requests | I | C | A/R | I | R (for sensitive entitlements) | I |
| Joiner, mover, leaver data | R | I | C | A | I | I |
| Access reviews | R (run campaigns) | A | R (review) | I | R (review) | C |
| Application onboarding to IGA and SSO | R | I | I | I | A | C |
| Privileged access policy | R | C | I | I | C | A |
| Non-human identity ownership | R (inventory, tooling) | I | I | I | A (for their workloads) | C |
| Identity incident response | R | I | I | I | C | A |
R = responsible, A = accountable, C = consulted, I = informed. Adapt the columns, but keep one A per row. Non-human identities deserve particular care: the application or platform team that runs a workload should be accountable for its service accounts and keys. See the NHI Ownership Guide.
Roles and skills
Ken Myers' IDPro article on IAM workforce planning argues that identity work needs agreed tasks, knowledge and skills, and that job titles are not work roles: a title is set by the organisation, whereas a work role describes a type of work consistently. He derives seven core roles from NIST NICE work roles, noting that the NICE Framework does not itself define identity-specific roles.
- Programme manager: owns the programme, the roadmap and alignment with business priorities.
- Enterprise or identity architect: designs the target architecture and requirements; in small organisations a senior administrator often fills it.
- System administrator: runs directories, identity providers and PAM, and handles accounts and credentials day to day.
- Software developer: builds integrations, connectors, login flows and federation configuration.
- System security analyst: translates business needs into identity workflows, including role mining, access requirements and attribute mapping.
- Test and evaluation specialist: tests identity processes and changes before production.
- Network specialist: network authentication and authorisation services, often shared with other teams.
Most organisations add three roles the article does not separate: an identity governance analyst who runs reviews and role management, an identity threat detection engineer who works with the SOC on identity telemetry, and a non-human identity engineer who covers service accounts, secrets, certificates and AI agent identities. See the IAM Engineer Career Guide and the NHI and Machine Identity Engineer Career Guide.
Describe skills as observable actions, as the article does: matching an authenticator to an assurance level, choosing an authorisation model for a use case, running a recertification, implementing PAM. Build a competency ladder (foundation, practitioner, expert) for each role. The article warns that vendor-only training can create overconfidence, so pair product certifications with vendor-neutral identity training. See the Role-Based Security Training Programme Guide.
Sizing the team
No authoritative source publishes a reliable ratio of identity staff to users, and the IDPro workforce article does not offer one. Size from workload instead. For each driver, estimate effort per unit from your own ticket and project data.
| Workload driver | How to measure | Effort lands on |
|---|---|---|
| Applications to onboard to SSO and IGA | Application catalogue, priority tiers, integration type (SCIM, connector, manual) | Engineers, developers, analysts |
| Lifecycle event volume | Joiners, movers and leavers per month from HR | Operations, automation engineers |
| Access review campaigns | Campaigns per year, entitlements in scope, reviewers | Governance analysts |
| Privileged estate | Privileged accounts, target systems, sessions | PAM engineers and operators |
| Non-human identities | Service accounts, workload identities, secrets, certificates, agents | NHI engineers, platform teams |
| Platforms run | Directories, identity providers, IGA, PAM, CIAM, secrets managers | Platform engineers (each platform needs cover for leave and on-call) |
| Change demand | Projects, mergers, cloud migrations, audit actions | Architects, programme manager |
Two rules of thumb are safe because they are about resilience, not ratios: every production identity platform needs at least two people who can operate it, and project work should be staffed separately from run work so incidents do not stall the roadmap.
Sourcing: build, partner or managed service
- In-house: keep architecture, policy, governance decisions and the platform owner role internal. These carry accountability and organisational knowledge that cannot be outsourced.
- Integrator or consultancy: suited to time-boxed work such as platform deployment, migrations and connector backlogs. Require knowledge transfer and documentation as deliverables.
- Managed service: suited to repeatable operations such as access request fulfilment, review campaign administration and out-of-hours monitoring. Define service levels, and treat the provider's administrative access as privileged third-party access. See the Vendor Privileged Access Management (VPAM) Guide.
- Size matters: the IDPro article notes that task ownership changes with organisation size; large organisations may outsource identity proofing and run dedicated PKI teams, while small ones rely on HR and a few administrators.
How the team evolves
The IDPro workforce article uses Tuckman's group stages to describe how identity teams form. Use them to plan the next step rather than the end state.
- Forming: a programme manager is appointed, often after an audit finding or incident, and tracks identity risks without a dedicated team. Next step: build the service catalogue and the case for a core team. See the IAM Business Case and ROI Guide.
- Storming: responsibility is centralised, operating divisions give up some control, and a core team is formed from existing administrators and developers, with an architect added. Next step: agree the RACI with business owners and executive backing.
- Norming: the team is stable and extends collaboration to HR, legal, privacy, physical security and compliance, often through a governance body. Next step: stand up the spokes and the identity governance board.
- Re-forming: new initiatives such as cloud migration, zero trust or AI agents can send the team back a stage. Plan for it rather than treating it as failure.
A practical rollout of a new model runs: publish the service catalogue and RACI; pilot the hub and spoke model with two or three application teams; measure service levels for a quarter; adjust; then extend. Keep the old escalation routes working until the new ones have been shown to work, so that nothing falls between teams during the transition.
Governance forums
- Identity steering group (quarterly): executive sponsor, CISO, CIO, HR and business representatives. Approves the roadmap, accepts risks and resolves ownership disputes.
- Identity design authority (monthly or per change): architects and platform owners. Approves standards, patterns and exceptions.
- Operations review (weekly): service levels, backlog, incidents and connector failures.
- Spoke community (monthly): application and cloud team contacts; training, changes, feedback.
Interfaces with other teams
- Security operations: the SOC owns detection and response; the identity team supplies telemetry, playbooks for disabling accounts and revoking sessions, and engineers on call during identity incidents. Agree who can disable an executive's account at 3am.
- Cloud and platform engineering: they create most workload identities and roles. Give them paved paths (approved patterns for workload identity federation and secrets) rather than tickets.
- HR: the authoritative source for workforce data. Agree data quality targets and an escalation route for urgent leavers. See the Identity Lifecycle Event Design Guide.
- Internal audit: consulted on review design and evidence so that controls are tested once, not argued about every year.
Measuring the operating model
Measure the service, not activity. Report these monthly to the steering group.
- Leaver service level: share of leavers fully deprovisioned within the agreed time.
- Request fulfilment time: median time from approved request to access granted.
- Onboarding throughput: applications connected to SSO and IGA per quarter against plan.
- Ownership coverage: share of roles, entitlements and non-human identities with a named accountable owner.
- Review completion: campaigns completed on time, and revocation rate as a signal of real reviewing.
- Key person risk: platforms with fewer than two trained operators.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01, GV.RR-02, GV.RR-03, GV.RR-04 | Leadership accountability, defined roles and authorities, resources, cybersecurity in HR practices |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05 | The identity and access outcomes the team delivers |
| NIST SP 800-53 Rev. 5 | PM-3, AC-2 | Security resources; account management roles |
| NIST NICE Framework (SP 800-181 Rev. 1) | Work roles, tasks, knowledge and skills | Common language for role definitions and training |
| ISO/IEC 27001:2022 Annex A | 5.2, 5.3, 5.15, 5.18 | Roles and responsibilities, segregation of duties, access control, access rights |
| Federal ICAM Architecture | Identity, credential and access management, federation, governance | Service catalogue structure |
Common failure patterns
- IT accountable for business access: the identity team approves roles it cannot judge, reviews become rubber stamps and audit findings repeat.
- Spokes on paper only: application teams are named as spokes but given no time, training or targets, so work flows back to the hub.
- Single points of failure: one engineer understands the IGA connectors or the PAM vault, and leave or resignation stalls the programme.
- Non-human identities owned by nobody: service accounts fall between the identity team, cloud platform and application teams. The Dropbox Sign breach, which began with a compromised back-end service account, shows what an under-governed machine identity can expose.
- Run work eats project work: the same people handle tickets and the roadmap, and the roadmap slips every quarter.
- Product-only skills: staff can configure the tool but not choose between assurance levels or authorisation models.
Practitioner checklist
- Publish an identity service catalogue with owners, consumers and service levels.
- Choose an organisational pattern and reporting line, and document why.
- Agree a RACI with one accountable party per process, with business owners accountable for access policy.
- Define work roles and competency levels separately from job titles.
- Size the team from workload drivers and staff run and project work separately.
- Ensure every production identity platform has at least two trained operators.
- Name spokes in application, cloud and HR teams with time allocation and training.
- Assign accountable owners for non-human identities in the teams that run the workloads.
- Report service-level metrics monthly to an identity steering group.
Standards and references
- IDPro Body of Knowledge: Identity and Access Management Workforce Planning
- IDPro Body of Knowledge: Strategic Alignment and Access Governance
- GSA IDManagement.gov: Federal ICAM Architecture
- NIST: NICE Framework Resource Center
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Identity Security Programme Guide · Security Operating Model and Organisation Design Guide · IAM Business Case and ROI Guide · NHI Ownership Guide · IAM Engineer Career Guide