---
title: "PeopleOps"
slug: peopleops
category: industry
term_status: established
evidence_status: partially_verified
summary: "PeopleOps (people operations) runs an organisation's employee lifecycle (hiring, onboarding, moves, pay, performance and exits) as a reliable, measured operation built on one trusted system of record, clear owners and service levels."
audience: [Beginners, People Ops and HR practitioners, HRIS and people-analytics analysts, Engineers integrating HR data, Founders and leaders]
last_verified: 2026-10-16
key_takeaways:
  - "\"People Operations\" is largely a newer name for HR, most closely associated with Google; renaming changes nothing unless the operating model changes."
  - "The core asset is one effective-dated system of record for workers, positions and pay, whose events other systems consume instead of re-keying data."
  - "Joiner–mover–leaver is a shared control: PeopleOps owns the HR trigger and the data, IdentityOps owns the account changes, and the gap between them must be measured."
  - "Measure services and outcomes (day-one readiness, revocation latency, regretted attrition, pay equity), not activity, and protect individuals with minimum reporting groups."
  - "Employee data and AI that screens or ranks people are regulated in more and more places (as of October 2026: the EU AI Act, New York City audits of hiring and promotion tools, California's automated-decision rules); map your jurisdictions before buying."
  - "Do not build a PeopleOps department before the basics exist: a small, single-country company usually needs one accountable owner and a good provider, not a team."
related: [identityops, bizops, privacyops, legalops, eduops, devexops, supportops, complianceops]
---

## What PeopleOps is

### In 30 seconds

**PeopleOps (people operations) is the discipline of running everything that happens to a person at work, from offer to exit, as a
dependable operation:** one trusted record of who works here, in which role, for whom and at what pay; documented processes that
change that record; services that answer people's questions on time; and measurements that show whether the whole system treats
people well and fairly.

Every hire, promotion, move, pay change and exit changes data that payroll, IT, finance, managers and the law depend on.
PeopleOps makes those events happen correctly, on time, once, and with evidence: a new hire has a laptop and accounts on day one, a
leaver loses access the moment they leave, pay decisions can be explained, and leaders can trust the headcount number.

Written for beginners, People Ops practitioners, HRIS analysts and engineers integrating HR data, and leaders deciding how to
organise the function. Sources were last verified on **2026-10-16**.

::: note Scope of this page
This page treats PeopleOps as **HR run as a data-and-process operation**, an editorial emphasis (see
[the naming story](#is-peopleops-just-hr-the-naming-story)). Nothing here is legal advice; every legal statement names its
jurisdiction and a date.
:::

### At a glance

| Question | Short answer |
|---|---|
| Goal | A correct, timely, fair and humane employee lifecycle, with people data that leaders can trust |
| Primary users | People Ops and HR teams, HRIS and people-data analysts, managers, every employee as a customer |
| In scope | Lifecycle transactions, the HR record, people analytics, performance, engagement measurement, the learning *programme*, pay governance, HR policy, compliance and privacy, HR service delivery |
| Handed off | Accounts → [IdentityOps](../identityops/); planning cadence → [BizOps](../bizops/); course delivery → [EduOps](../eduops/); legal advice → [LegalOps](../legalops/); privacy programme → [PrivacyOps](../privacyops/) |
| Prerequisites | None; spreadsheet or SQL skills help |
| Key outputs | System of record, lifecycle SOPs, data dictionary, service catalogue, pay structure, scorecard, policies, audit evidence |
| Minimum vocabulary | **HRIS**: the HR system of record. **Effective-dated**: each change carries the date it takes effect. **JML**: joiner–mover–leaver (hire, internal move, exit). **Regretted attrition**: leavers you wanted to keep. **Minimum reporting group**: the smallest group whose survey results may be shown. More in the [glossary](#glossary-and-mental-model) |
| Term status | **Established** as a name for the HR function or its operations team; largely a rebrand of HR (explained below) |
| Evidence status | Partially verified: footnoted claims checked against opened sources; gaps (such as the year Google adopted the name) are disclosed |

### Is PeopleOps just HR? The naming story

Mostly, yes. "People Operations" is a name, not a standard: the CIPD says its Profession Map "sets the international
standard for our profession", meaning the people profession,[^cipd-map] and ISO/TC 260 publishes its standards under the title "Human resource management".[^iso-tc260]

The label is most closely associated with Google. Laszlo Bock was Google's Senior Vice President of People Operations until
2016,[^bock-wiki] and his publisher calls him the "head of People Operations".[^bock-hachette] Secondary accounts say he was hired
into that role in 2006;[^d3] no primary source opened here dates the renaming, so treat "2006" as reported and "Google coined it"
as unproven: Google is the best-known adopter, not a documented inventor.

The label is used in three ways; ask which one a speaker means:

1. **A new name for the whole HR function**: recruiting, employee relations, pay, policy, everything.
2. **The operations team inside a larger People function**, running the system of record, lifecycle transactions, HR service
   delivery and people data next to business partners and specialists. In GitLab's public handbook, for example, People
   Operations owns the onboarding template and runs offboarding cases.[^gitlab-onb][^gitlab-offb]
3. **A philosophy**: HR run with the habits of an operations team (data, documented processes, self-service, service levels).
   Google says its People Analytics team was founded so that "all people decisions and strategy are informed by data".[^rework-pa]

::: decision Editorial distinction used on this page
This page teaches the **third meaning applied to the scope of the first**: the whole employee lifecycle, run as a
data-and-process operation. This is the Atlas's choice, not an industry definition.
:::

What changes when an organisation adopts PeopleOps, rather than only renaming HR, is observable: **one effective-dated system of
record** with an owner for every attribute; **events, not emails**, so a hire or termination entered once drives payroll, identity
and equipment; **written service levels** ("access removed within one hour of termination"); **self-service documentation**;
**programmes tested against data**; and **privacy by design**. If none of these change, the rename is cosmetic.

### What PeopleOps is not

- **Not identity management.** PeopleOps decides *that* someone joins, moves or leaves; identity teams change the accounts
  ([IdentityOps](../identityops/), [AccessOps](../accessops/)).
- **Not surveillance.** Keystroke and individual commit counts are not people analytics; [DevExOps](../devexops/) measures
  engineering systems, not individuals.
- **Not legal counsel.** PeopleOps applies law through policy and process; advice comes from lawyers ([LegalOps](../legalops/)).
- **Not culture by decree.** Leaders and managers shape culture; PeopleOps measures it and supports it with processes.
- **Not only administration.** A team that only processes forms leaves the expensive problems (bad hires, unfair pay, avoidable
  attrition) alone.

### The problem it solves

Every organisation already "does HR"; the question is whether the work is reliable. The "before" column is a composite of common
failure patterns, not a report about a company.

| Area | Without a working PeopleOps model | With one |
|---|---|---|
| Headcount | Finance, HR and IT each have a different number | One effective-dated record, reconciled daily |
| Joiners | Laptop and accounts arrive in week two | Day-one readiness planned from the accepted offer and measured |
| Leavers | Former employees keep access for days or weeks | Termination drives account disabling within a defined time |
| Moves | Promotions are emailed; payroll and access lag | One effective-dated transaction; access re-reviewed |
| Pay | Offers negotiated case by case; differences unexplained | Ranges, approval rules, periodic pay-equity screens |
| Questions | Answers depend on whom you ask | Service catalogue, knowledge base, tracked cases |

The cost of not doing this work lands on **security** (NIST treats personnel termination as a security control: disable access
within an organisation-defined period, revoke credentials[^nist-oscal]); **legal deadlines** that run on the HR calendar (US Form
I-9 Section 2 within three business days of the first day of employment;[^i9] UK right-to-work checks before employment
starts[^uk-rtw]); **money and fairness** (payroll errors, unexplained pay gaps, growing reporting duties); and **people** (Google
found that teams with highly effective managers were more likely to achieve better results, be happier and experience lower
turnover,[^rework-oxygen] one company's finding about itself).

## Vocabulary, origins and neighbours

### Glossary and mental model

- **Worker:** anyone working for the organisation; the worker type says employee, contractor or intern.
- **System of record (SoR); HRIS / HCM:** the system whose value wins for an attribute; the HR information system or suite, usually the SoR for job, manager and pay.
- **Effective dating:** history is kept and each change carries its effective date (entered 20 March, effective 1 April).
- **Position, job, grade:** a seat in the organisation; a role definition; a group of jobs of similar value for pay.
- **Joiner–mover–leaver (JML):** hire, internal move and exit; "birthright" access is what every joiner in a role gets automatically.
- **Pay range (band); range spread:** minimum, midpoint and maximum pay for a grade (G4: 60,000–75,000–90,000); spread = (maximum − minimum) ÷ minimum, here 50%[^waw].
- **Compa-ratio; range penetration:** pay ÷ range midpoint[^compa] (70,000 ÷ 75,000 = 0.93); position between minimum (0%) and maximum (100%), here 33%.
- **eNPS:** % promoters (9–10) − % detractors (0–6) on "recommend as a place to work", adapted from customer NPS[^bain-nps][^peakon].
- **Minimum reporting group:** for example, five respondents[^glint].
- **People Partner, CoE, shared services:** a generalist for a business area; a specialist centre of expertise; a central hub for administrative HR work[^cipd-ss].
- **PEO; EOR:** professional employer organisation, a co-employment payroll and tax provider (the US runs a voluntary certification programme)[^irs-peo]; employer of record, which legally employs your worker where you have no entity.
- **DSAR:** data subject access request.
- **Adverse-impact screen:** each group's selection rate ÷ the highest group's rate (15% ÷ 25% = 0.60), often checked against the US "four-fifths" (0.80) rule of thumb.
- **Reduction in force (RIF):** several dismissals for reasons unrelated to the individuals (layoffs, collective redundancy).

#### A mental model: a ledger, a state machine and a service desk

Hold three pictures at once:

1. **A ledger.** The system of record is an append-only, effective-dated history of facts about workers and positions; you can
   always answer "what was true on 1 March?".
2. **A state machine.** Each person moves through states (candidate to alumni); every transition has a trigger, an owner, checks
   and downstream effects. Bugs live in transitions nobody owns.
3. **A service desk.** Employees and managers are customers with a [service catalogue](#reference-implementation-operating-artefacts),
   intake forms, owners and service levels.

Most PeopleOps failures are one of these pictures breaking: the ledger is wrong (bad data), a transition misfires (an orphan
account, a missed payroll change), or the desk is a black box (nobody knows who answers what).

### Origins and evolution

Only milestones traceable to sources are listed; this is not a history of human resource management.

- **1978:** US agencies adopt the Uniform Guidelines on Employee Selection Procedures and their "four-fifths" screen,[^ugesp] making
  selection something to measure for fairness.
- **2000s–2016:** Google runs HR as People Operations, with people analytics, under Laszlo Bock;[^d3][^bock-wiki] the name and the
  data-first habit spread through technology companies.
- **2015:** SCIM 2.0 (RFC 7643, RFC 7644) gives HR attributes a standard path into identity systems.[^scim][^scim-protocol]
- **2018, 2025:** ISO 30414 on human capital reporting is published, then revised.[^iso-30414]
- **2018–2027:** the GDPR,[^gdpr88] California's CCPA for employee data,[^ccpa] New York City's hiring-tool law,[^nyc-aedt] the EU AI
  Act, the Pay Transparency Directive and India's Digital Personal Data Protection (DPDP) Rules[^ai-act][^eu-ptd][^dpdp] make employee privacy, algorithms and pay
  externally accountable (dates in the [regulatory map](#regulatory-map-as-of-16-october-2026)).

### How PeopleOps relates to other Ops

PeopleOps sits in a web of hand-offs. The figure shows what crosses each boundary; the table names the owners.

::: figure PeopleOps and its neighbours: what crosses each boundary
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 12, "rankSpacing": 18, "padding": 8}}}%%
flowchart LR
  BZ["BizOps: headcount plan in, hiring data out"]
  PV["PrivacyOps: privacy rules, DSAR process"]
  AC["AccessOps: review results after moves"]
  DX["DevExOps: aggregate signals only"]
  SP["SupportOps, ITOps: service-desk patterns"]
  P["PeopleOps"]
  ID["IdentityOps: JML events out, account status back"]
  ED["EduOps: enrolments out, completions back"]
  LG["LegalOps: employment questions"]
  CO["ComplianceOps: control evidence"]
  BZ <--> P
  PV --> P
  AC --> P
  DX -.-> P
  SP --> P
  P <--> ID
  P <--> ED
  P --> LG
  P --> CO
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class P core
  class ID,AC,BZ,LG,PV,CO,ED,DX,SP neutral
```
Text equivalent: Left, neighbours that mainly inform PeopleOps: BizOps (headcount plan in, hiring data out; two-way), PrivacyOps
(privacy rules, DSAR process), AccessOps (review results after moves), DevExOps (aggregate signals only, dotted) and SupportOps/ITOps
(service-desk patterns). Right, neighbours it feeds: IdentityOps (JML events out, account status back) and EduOps (enrolments out,
completions back), both two-way; LegalOps (employment questions); ComplianceOps (control evidence).
:::

| Neighbour | PeopleOps owns | The neighbour owns | Hand-off artefact |
|---|---|---|---|
| [IdentityOps](../identityops/) | The HR trigger, effective date, attribute quality | Creating, changing, disabling accounts | Lifecycle event; daily reconciliation |
| [AccessOps](../accessops/), [IAMOps](../iamops/) | Signalling that a move happened | Access requests, reviews, permission design | Mover event; review results |
| [BizOps](../bizops/) | Positions, requisitions, hiring data | Company cadence, OKRs, headcount budget | Approved headcount plan |
| [LegalOps](../legalops/) | Applying law through policy and process | The legal function and counsel | Matter intake; policy sign-off |
| [PrivacyOps](../privacyops/) | Minimisation, access, retention in HR systems | Records of processing, DSAR workflow, DPIAs | Inventory entries; HR data for DSARs |
| [ComplianceOps](../complianceops/) | Operating HR controls | Control framework, audit coordination | Evidence packages |
| [EduOps](../eduops/) | The learning *programme*: needs, budget, records | Delivering and measuring courses | Enrolments; completions |
| [DevExOps](../devexops/) | Individual performance, under fairness rules | Developer friction in systems and teams | Aggregates only |
| [SupportOps](../supportops/), [ITOps](../itops/) | HR service catalogue and cases | Customer support; IT service desk | Shared tooling patterns |
| [RevOps](../revops/), [SalesOps](../salesops/) | Pay structures and governance for sales roles | Quotas, territories, commission mechanics | Approved plan; payroll inputs |
| [ProcurementOps](../procurementops/) | Worker records where policy requires | Contracting suppliers of temporary staff | Contractor onboarding request |

::: tip Contractors are a real boundary
Organisations differ on who onboards temporary service providers; GitLab, for example, routes them through Procurement, not its
People team.[^gitlab-onb] Write your choice down: contractors who fall between teams are a common source of orphan accounts.
:::

## Principles and operating model

### Charter and principles

No official PeopleOps manifesto exists. The charter below is **this Atlas's proposal** for a team to adopt, edit and sign; its
numbers are examples, not benchmarks. **Mission:** make every moment of working here, from offer to exit, correct, timely, fair and
humane, with people data the organisation can trust.

1. **One record, many consumers:** one system of record and one owner per attribute; other systems subscribe, never re-key.
2. **Effective-dated truth:** every change has an effective date, author and reason; history is never overwritten.
3. **Transitions are controls:** joining, moving and leaving are security, payroll and legal events with owners and evidence.
4. **Services have service levels,** written down and measured.
5. **Measure systems, protect individuals:** analytics answer group questions; individual decisions follow fair, documented
   processes with a right to be heard.
6. **Minimum necessary data:** a stated purpose and recorded lawful basis, restricted sensitive fields, deletion on schedule.
7. **Write it down** where employees can read it, and **adopt on evidence**: check that a practice worked.

**Measurable goals (examples).** Day-one readiness ≥ 95%; access disabled within one hour of termination for ≥ 99% of leavers;
zero overdue statutory deadlines; every flagged pay gap explained or fixed (the [scorecard](#templates) tracks them).

**Non-goals.** Tracking individual activity, owning strategy or headcount budgets, or replacing managers' responsibility for their
teams; counsel confirms legal requirements per jurisdiction.

**Invariants.** Whatever the tools: nobody is active in payroll and terminated in HR (or the reverse) for longer than the
reconciliation interval; nobody sees pay, health, diversity or investigation data without a role that needs it; every termination
has an effective date and time before access is removed; and no report lets an individual's answers be inferred.

### Fundamentals and building blocks

Six layers, each depending on the one below:

| Layer | What it contains | Typical artefacts | If it is missing |
|---|---|---|---|
| 1. Data | Worker, position, job, organisation, pay and event records | Data dictionary, attribute ownership matrix, [retention schedule](#templates) | Everyone keeps their own spreadsheet |
| 2. Transactions | Hire, onboard, move, leave, leave of absence, pay change | SOPs, checklists, approval rules | Changes are emailed and lost |
| 3. Services | HR service catalogue, case handling, self-service, knowledge base | [Service catalogue](#reference-implementation-operating-artefacts), intake forms, SLAs | Answers depend on who you ask |
| 4. Programmes | Performance, goals, learning, engagement, reward, wellbeing | Programme designs, calendars, manager guides | Programmes happen by habit |
| 5. Governance | Policy, employment compliance, privacy, controls, audit | Policy library, control register, evidence | Compliance by luck |
| 6. Insight | Metrics, dashboards, analyses, experiments | Metric definitions, scorecard, analysis notes | Decisions by anecdote |

Three technical ideas carry most of the weight:

- **Stable identifiers.** Key every record on an immutable worker ID, never on email or name; emails change at marriage, rehire
  and rebranding.
- **Effective and future dating.** Entering changes before they take effect (a hire two weeks out, a termination at 17:00 next
  Friday) lets downstream systems prepare and act on time.
- **Attribute ownership.** For every attribute, decide which system wins: the HRIS might own legal name, job, manager and cost
  centre; the identity provider username and email; payroll tax setup. Microsoft's documentation of HR-driven provisioning calls the
  HR system "the source of authority" for new identities, with changes flowing to accounts and terminations disabling them.[^entra-hr]

### Roles, ownership and RACI

| Role | Accountable for |
|---|---|
| Head of People / Chief People Officer | People strategy, the People function, policy approval |
| PeopleOps lead | Lifecycle processes, HR service delivery, system of record, data quality |
| HRIS analyst or engineer | Configuration, integrations, security roles, reports |
| People analyst | Metrics, analyses, surveys |
| People Partner (HRBP) | Advising leaders in a business area; employee-relations escalations |
| Talent acquisition; total rewards | Hiring; job architecture, ranges, pay cycles, benefits |
| Payroll (often in Finance) | Accurate, lawful pay runs |
| Managers | Expectations, feedback, development, day-one plans (see [Project Oxygen](#playbook-performance-and-goals)) |
| Identity and IT; Legal and privacy | Accounts, devices, access; counsel and the privacy programme |

**How the team is organised as it grows** (**editorial heuristics**, not benchmarks; thresholds vary with countries, unions and
complexity)

| Size | Typical shape | What to get right first |
|---|---|---|
| Under ~50 people | A founder or operations lead; a payroll provider, PEO or EOR | One record (even a governed spreadsheet), contracts, payroll, joiner and leaver checklists |
| ~50–250 | First People hire, often a generalist with ops skills; an HRIS | System of record, JML automation with IT, pay ranges, basic metrics |
| ~250–1,000 | People Partners, a PeopleOps team (desk, HRIS, data), talent and reward specialists | Service catalogue and SLAs, integrations, analytics with privacy rules, calibration |
| 1,000+ / multi-country | Shared-services hub, centres of expertise, regional partners | Global data model with local fields, controls and audit, country compliance calendar |

The shared-services, partner and expertise split ([glossary](#glossary-and-mental-model)) is a common pattern, not a requirement.

**RACI for the core lifecycle**

R = responsible, A = accountable, C = consulted, I = informed. One A per row.

| Activity | PeopleOps | Hiring manager | Talent acquisition | IT / Identity | Payroll | Employee |
|---|---|---|---|---|---|---|
| Create pre-hire record from accepted offer | A/R | I | R | I | I | C |
| Pre-employment checks (right to work, background where lawful) | A | I | R | – | – | R |
| Accounts and device ready for day one | C | I | – | A/R | – | I |
| Day-one welcome and 30/60/90 plan | C | A/R | – | – | – | I |
| Job, manager or location change | A/R | R | – | I | I | I |
| Access review after a move | I | R | – | A | – | – |
| Termination entry with effective date and time | A/R | R | – | I | I | I |
| Account disablement at termination | I | I | – | A/R | – | – |
| Final pay | C | – | – | – | A/R | I |
| Exit survey and knowledge handover | A | R | – | – | – | R |

### The employee lifecycle

The lifecycle is the spine of PeopleOps. The diagram shows the states a worker record passes through and the events that move it;
the first state usually lives in the applicant tracking system (ATS) before any HR record exists.

::: figure Employee lifecycle states and the events that change them
```mermaid
stateDiagram-v2
  state "Candidate (ATS record)" as Candidate
  state "Pre-hire" as PreHire
  state "Not hired" as NotHired
  state "Active (moves stay Active)" as Active
  state "On leave" as OnLeave
  [*] --> Candidate
  Candidate --> PreHire: offer accepted
  Candidate --> NotHired: rejected
  PreHire --> NotHired: no-show
  PreHire --> Active: start date
  Active --> OnLeave: leave
  OnLeave --> Active: return
  Active --> Notice: resign, dismiss
  OnLeave --> Notice: separation
  Notice --> Terminated: effective time
  Active --> Terminated: summary exit
  Terminated --> Alumni: retention
  Alumni --> PreHire: rehire
  Alumni --> [*]: deleted
```
Text equivalent: A candidate (an applicant-tracking record) becomes pre-hire on an accepted offer, or "not hired" if rejected. A
pre-hire becomes active on the start date once checks pass, or "not hired" after a rescinded offer or no-show. Moves keep a worker
active. Active workers can go on leave and return, or enter notice (also from leave), which ends in termination at the effective
time; a summary exit (summary dismissal, death, fixed-term expiry) goes straight to terminated. Terminated records become alumni,
who can be rehired or deleted on schedule.
:::

Every arrow needs an owner and a list of downstream effects, and **the risky arrows are the forgotten ones**: no-shows (accounts
already created), separations during leave, rehires (old access reactivated) and moves (access accumulates).

| Stage | Trigger | Owner | Key controls | Data written |
|---|---|---|---|---|
| Attract and select | Approved requisition | Talent acquisition | Structured interviews; adverse-impact screen (Lab 4) | Candidate record, offer |
| Pre-board | Offer accepted | PeopleOps | Contract; right-to-work or equivalent checks; equipment | Pre-hire record, future start date |
| Onboard | Start date | Manager with PeopleOps | Statutory deadlines (for example US I-9 Section 2 within three business days[^i9]); day-one access | Active worker; payroll enrolment |
| Perform and develop | Cycle dates | Manager | Documented criteria; calibration; development separate from pay[^cipd-pm] | Goals, reviews, training records |
| Move | Promotion, transfer, manager change | PeopleOps with manager | Pay within range; access review (NIST PS-5[^nist-oscal]) | Effective-dated job, manager, pay |
| Leave | Resignation, dismissal, contract end, retirement, death, [reduction in force](#playbook-reductions-in-force-and-collective-redundancy) | PeopleOps | Effective time; access disabled; property (NIST PS-4[^nist-oscal]); final pay per local law | Termination record, regretted flag |
| Alumni | Termination | PeopleOps | [Retention schedule](#templates); rehire eligibility | Retained records only |

**Day 0, 1 and 2 for the function itself:** design (operating model, attribute ownership, job architecture, legal obligations per
country), go-live (migration with reconciliation, integrations, parallel payroll) and run (queues, reconciliation, audits, the
annual calendar); the [30/60/90-day roadmap](#adoption-roadmap-306090-days) sequences it.

### Operating model and governance

**Service delivery tiers**

Tiers answer simple questions fast and send complex or sensitive ones to the right expert; the exact split is yours to design, and
the [service catalogue](#reference-implementation-operating-artefacts) says which tier owns each request.

::: figure HR service delivery tiers and escalation paths
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  E["Employee or manager: question or request"]
  T0["Tier 0: self-service portal and knowledge base"]
  T1["Tier 1: PeopleOps service desk, cases with SLAs"]
  T2["Tier 2: specialists (payroll, benefits, reward, HRIS, mobility)"]
  T3["Tier 3: policy owners, counsel, CoE leads"]
  ER["Confidential channel for employee relations"]
  PP["People Partner for the area"]
  E --> T0
  T0 -->|"not resolved"| T1
  T1 -->|"specialist"| T2
  T2 -->|"policy or legal"| T3
  E -->|"`grievance, harassment, health`"| ER
  ER --> PP
  T2 -.->|"articles"| T0
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class T0,T1,T2,T3 core
  class ER risk
  class E,PP neutral
```
Text equivalent: Requests start at Tier 0 self-service and escalate to Tier 1 PeopleOps cases with SLAs, Tier 2 specialists and
Tier 3 policy owners, counsel and CoE leads. Grievances, harassment and health issues bypass the tiers through a confidential
employee-relations channel to the People Partner. A dotted arrow returns patterns from the case tiers to Tier 0 as knowledge
articles.
:::

The critical design choice is the **confidential bypass**: a grievance must never sit in a queue many people can read.

**Governance, cadences and controls**

| Cadence | Forum | Outputs |
|---|---|---|
| Daily | Automated HRIS–identity–payroll reconciliation | Fixed records; root-cause tickets |
| Weekly | Operations review: queue ageing, SLA breaches, upcoming joiners and leavers | Actions with owners |
| Monthly | People metrics review with leadership ([scorecard](#templates)) | Decisions; questions for analysis |
| Quarterly | Data-quality sample, HRIS role review, policies past review, pay and selection screens | Corrections; role clean-up |
| Twice yearly or yearly | Performance and pay cycles; engagement survey | Calibrated, screened decisions |
| Yearly | Policy review; compliance calendar; retention deletions | Updated policies; deletion evidence |

Three controls are worth adopting from day one: **change control for HRIS configuration** (one click on a security group can
expose everyone's pay); **a policy lifecycle** (owner, review date, versions, plain-language summary); and **role-based, logged
access to HR data**, with analysts on pseudonymised extracts unless identity is necessary.

## Architecture and workflow

### Reference architecture: the people-data platform

People data flows from hiring into a system of record and out to every system that needs to know who works here (a
vendor-neutral, logical view).

::: figure Logical reference architecture for people data and lifecycle automation
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 112, "nodeSpacing": 18, "rankSpacing": 30}}}%%
flowchart TB
  PLAN["Headcount plan"] --> HRIS
  ATS["Applicant tracking"] -->|"accepted offer"| HRIS
  HRIS["HRIS or HCM: effective-dated record, audit log"]
  HRIS --> EVT["Integration layer: events and APIs, also to IT assets, learning, cases"]
  HRIS -->|"`minimised extract`"| WH["Analytics store and dashboards (restricted: pseudonymised, minimum group sizes)"]
  EVT --> PAY["Payroll and finance"]
  EVT --> IDP["Identity provider, then SaaS apps via SCIM"]
  PAY --> REC["Daily reconciliation; exceptions go back to the HRIS"]
  IDP --> REC
  REC -.-> HRIS
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class HRIS,EVT core
  class WH risk
  class ATS,PLAN,PAY,IDP,REC neutral
```
Text equivalent: The headcount plan and accepted offers from applicant tracking feed the HRIS, an effective-dated record with an
audit log. An integration layer sends events to payroll and finance, to the identity provider (which provisions SaaS apps by SCIM)
and to IT assets, learning and HR cases. Daily reconciliation compares payroll and identity with the HRIS and sends exceptions back
(dotted arrow). A minimised extract feeds a restricted, pseudonymised analytics store with minimum group sizes.
:::

**Integration patterns and trade-offs**

| Pattern | How it works | Strengths | Risks |
|---|---|---|---|
| Native connector | Vendor-built HRIS-to-target integration | Quick to start, supported | Limited mapping; changes with vendor releases |
| Event or webhook | HRIS emits a change event; consumers react | Near real time; clear audit trail | Needs ordering, retries and replay for future-dated events |
| Scheduled API pull | Consumer polls for changes | Simple; works with most systems | Latency equals the polling interval; terminations can lag |
| Flat file (SFTP/CSV) | Periodic export and import | Universal fallback | Fragile formats; sensitive data at rest |

Choosing between a suite, best-of-breed tools and provider bundles is covered in the [decision framework](#decision-framework).
**Design rules that prevent most integration incidents:**

1. Build the three [fundamentals](#fundamentals-and-building-blocks) into every mapping: the immutable worker ID as the key (email
   only as an attribute), future-dated events that consumers schedule for the effective time, and the attribute-ownership matrix.
2. Make terminations the highest-priority event type, with alerting if delivery fails.
3. Reconcile daily: "terminated in HR but active in identity" must be an alert, not a report.
4. Treat rehires explicitly: reactivate the old identity with **no** previous access, or create a new one by policy.

### End-to-end workflow: a joiner, a mover and a leaver

#### Joiner: happy path and exception path

::: figure Joiner sequence from accepted offer to day one, with a delayed-check exception
```mermaid
%%{init: {"sequence": {"wrap": false, "width": 100, "actorMargin": 30, "messageMargin": 22, "noteMargin": 8, "boxMargin": 6, "diagramMarginX": 6, "diagramMarginY": 6}}}%%
sequenceDiagram
  participant IT as IT, identity
  participant HR as PeopleOps
  participant M as Manager
  Note over IT,M: Recruiting: offer accepted, start in 15 days
  Note over HR: Pre-hire record,<br>worker ID
  HR->>IT: Prepare disabled<br>account, device
  HR->>M: Day-one plan<br>reminder
  rect rgb(232, 243, 242)
    Note over IT,M: Happy path: all checks complete
    HR->>IT: Enable account<br>at start
    Note over HR: Payroll and<br>benefits active
    M->>HR: Day-one ready
  end
  rect rgb(251, 236, 235)
    Note over IT,M: Exception: a check is delayed or fails
    Note over HR: Move the date<br>or rescind
    HR->>IT: Hold account<br>and device
    HR->>M: New date or<br>cancellation
  end
```
Text equivalent: Three lanes, with PeopleOps between IT and the manager. Recruiting reports an accepted offer starting in 15 days.
PeopleOps creates the pre-hire record and worker ID, asks IT to prepare a disabled account and a device, and reminds the manager
about the day-one plan. Happy path (green band): all checks complete, the account is enabled at the start, payroll and benefits
become active and the manager confirms readiness. Exception (red band): a check is delayed or fails, PeopleOps moves the date or
rescinds, IT holds the account and device, and the manager is told.
:::

GitLab opens each onboarding issue at least four days before the hire date, with common tasks due within 30 days;[^gitlab-onb]
Google measures the result with surveys at 30, 90 and 365 days (Scenario 2 in [use cases](#use-cases-and-scenarios)).

#### Mover: the forgotten event

Moves are where access accumulates and payroll goes wrong. A mover workflow should:

1. Record the change once, effective-dated (job, manager, location, cost centre, pay), and check pay against the new range.
2. Notify identity so birthright access changes, and review everything else; NIST's PS-5 control asks organisations to confirm
   ongoing need for access when people are reassigned.[^nist-oscal]
3. Update the manager everywhere, because approvals follow the manager attribute.
4. For cross-border moves, start the country checklist (tax, work authorisation, contract) before the effective date.

#### Leaver: happy path and exception path

::: figure Leaver workflow with the late-entry exception that creates orphan accounts
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 22, "rankSpacing": 30}}}%%
flowchart TD
  A["Resignation or dismissal decision"] --> B{{"Termination entered with date and time before the effective moment?"}}
  B -->|"yes"| C["Future-dated termination event published"]
  C --> D["At effective time: identity disables account; sessions and tokens revoked"]
  D --> E["Property return, final pay per jurisdiction, exit survey, handover"]
  E --> H["Record moves to alumni; retention clock starts"]
  B -->|"`no: entered late or not at all`"| X["Account stays active after departure"]
  X --> R["Daily reconciliation flags it: terminated in HR, active in identity"]
  R --> S["Emergency disablement and access review"]
  S --> T["Root cause logged, process fixed"]
  T --> E
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class C,D,E,H core
  class X,R,S,T risk
  class B decision
```
Text equivalent: Was the termination entered before the effective moment? If yes, a future-dated event disables the account and
revokes sessions and tokens at the effective time; property return, final pay, exit survey and handover follow, then alumni
retention. If not, the account stays active until daily reconciliation flags it; emergency disablement, an access review and a
root-cause fix follow, and the case rejoins the normal path at property return and final pay.
:::

NIST leaves the time limit for disabling access to each organisation,[^nist-oscal] so set yours by risk (this page's examples use one
hour); Scenario 1 in [use cases](#use-cases-and-scenarios) shows one company's published windows. For involuntary exits, pre-enter
the termination with restricted visibility and an effective time matching the meeting, so access goes as the conversation happens
(Artefact 5).

## Practices and playbooks

Beyond joiner, mover and leaver handling: the workloads near the law, then playbooks for onboarding, performance, pay, listening,
data quality and reductions in force. The learning *programme* (needs, budget, mandatory training) is PeopleOps work; course
delivery is [EduOps](../eduops/).

### Other recurring workloads and their hand-offs

Three workloads sit close to the law; this page covers the operating work and the hand-off to counsel
([LegalOps](../legalops/)), not the legal tests.

- **Worker classification:** record a worker type and rationale at intake and review it when the work changes. Status is decided
  by legal tests that differ by country and between employment and tax law (for example GOV.UK;[^uk-status] the US
  IRS[^irs-status]).
- **Leave and workplace adjustments:** entitlements per country and contract, return-to-work plans and payroll inputs, with health
  data in restricted fields.
- **Employee-relations investigations:** confidential intake, a named investigator, restricted records. A fair process, as in the
  UK Acas Code (being updated as of October 2026), establishes the facts, hears the employee before a decision, allows
  accompaniment, offers an appeal and, where practicable, separates investigator and decision-maker in misconduct cases.[^acas-code]

### Playbook: onboarding that works

Talya Bauer's SHRM Foundation guide names four building blocks, and calls organisations Passive, High Potential or Proactive by
how far beyond the first one they go.[^bauer] Use them as a checklist:

1. **Compliance** (legal and policy rules): contracts, statutory forms on time, policy acknowledgements, equipment and access.
   Automate it; it is necessary, not sufficient.
2. **Clarification** (the job and its expectations): a written 30/60/90-day plan from the manager by day three.
3. **Culture** (formal and informal norms): how decisions are made and work is documented; the team's behaviour matters more than
   the handbook.
4. **Connection** (relationships and information networks): a named buddy, introductions, a joiner cohort.

### Playbook: performance and goals

The evidence is more modest than the practice built on it. The CIPD's evidence review, based on rapid evidence assessments by the
Center for Evidence-Based Management,[^cipd-pm-report] found that specific, challenging goals work for straightforward tasks but
less for complex ones, that feedback is crucial for goal setting, and that appraisal generally helps performance but "by no means
always"; it recommends separating developmental conversations from administrative ones (pay and promotion) and stresses perceived
fairness.[^cipd-pm] Design rules that follow:

- **Decide each conversation's purpose;** mixing development, pay and under-performance makes every conversation defensive.
- **Keep goals and evaluation separate.** Google's guide states that "OKRs are not synonymous with performance evaluation" and
  targets a 0.6–0.7 average for ambitious goals;[^rework-okr] pay people for hitting OKRs and they will set easy ones.
- **Calibrate where ratings drive money,** and compare rating and promotion distributions across groups where numbers allow.
- **Train managers.** Google's Project Oxygen drew on more than 10,000 data points from reviews and feedback surveys, plus
  interviews, to define ten behaviours of effective managers, such as coaching and empowering without micromanaging.[^rework-oxygen]

### Playbook: pay governance

Pay governance turns individual negotiations into a system that can be explained to employees, auditors and regulators.

::: figure Pay governance cycle from job architecture to pay-equity correction
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  JA["Job architecture: families, levels, grades"] --> MK["Market data matched to jobs"]
  MK --> RG["Pay ranges: minimum, midpoint, maximum"]
  RG --> OF["Offers within range; exceptions approved"]
  RG --> MV["Moves priced against the new range"]
  OF --> CY["Pay review cycle with budget and guidelines"]
  MV --> CY
  CY --> SC{{"Screens: out of range, compa-ratio by group, pay gaps"}}
  SC -->|"explained"| DOC["Document the legitimate factors"]
  SC -->|"unexplained"| FIX["Adjust pay and fix the cause"]
  DOC --> RP["Reporting where law requires it"]
  FIX --> RP
  RP -.->|"next cycle"| JA
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class JA,MK,RG,OF,MV,CY,DOC,RP core
  class SC decision
  class FIX risk
```
Text equivalent: Job architecture is matched to market data to set ranges (minimum, midpoint, maximum). Offers and moves are priced
against ranges and feed the pay review cycle. Screens check out-of-range pay, compa-ratio by group and pay gaps: explained gaps are
documented, unexplained ones fixed. Both feed legally required reporting; the next cycle starts again at job architecture.
:::

Keep definitions written and stable (range spread and compa-ratio are in the [glossary](#glossary-and-mental-model)). The midpoint
differential is the gap between adjacent grade midpoints as a percentage of the lower one; broadbands typically span 100% or more
from minimum to maximum.[^waw] If your compa-ratio uses a reference point other than the midpoint, such as a market rate, say so.

**EU pay transparency.** The Directive requires pay information before employment, bans salary-history questions and gives
workers a right to request average pay levels by sex for equal work or work of equal value, through national laws due by 7 June
2026.[^eu-ptd] Gap reporting is phased by employer size: 250+ workers by 7 June 2027 and yearly; 150–249 by 7 June 2027 and every
three years; 100–149 by 7 June 2031 and every three years. A joint pay assessment with workers' representatives follows when a
category of workers shows a gap of at least 5% that is neither justified by objective, gender-neutral criteria nor remedied within
six months.[^eu-ptd] The thresholds are written per employer ("employers with 250 workers or more") and the Directive does not
mention corporate groups; national law may go further, since Member States may require employers under 100 workers to report
(Art. 9(5)) and may keep rules more favourable to workers (Art. 27).[^eu-ptd]

### Playbook: listening and engagement

Surveys are useful only if they lead to action and protect respondents.

::: figure Employee listening loop with confidentiality gates
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TB
  Q["Questions tied to decisions; thresholds set"] --> C["Collect responses"]
  C --> G{{"Group large enough to report?"}}
  G -->|"no"| SUP["Suppress it, and a neighbour if subtraction would reveal it"]
  G -->|"yes"| A["Analyse trends, drivers, comments"]
  SUP --> A
  A --> P["Share results; teams pick one to three owned actions"]
  P --> F["Follow up in public on what changed"]
  F -.->|"next round"| Q
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q,C,A,P,F core
  class G decision
  class SUP risk
```
Text equivalent: Questions tied to decisions and thresholds are set first, then responses collected. Groups too small to report are
suppressed, along with a neighbour if subtraction would reveal them. Results are analysed and shared, teams pick one to three owned
actions, and the follow-up is public before the next round.
:::

Confidentiality thresholds are a concrete control. Microsoft's Viva Glint, for example, hides rated scores for groups below five
respondents by default (adjustable to three), applies "suppression" so hidden scores cannot be recovered "using simple math", and
needs ten respondents before showing comments.[^glint] Write yours down before launch.

**eNPS** borrows the customer Net Promoter method (taught in [CXOps](../cxops/)).[^bain-nps] Workday Peakon, for example, asks
"How likely is it you would recommend [Company] as a place to work?" and says it follows eNPS methodology.[^peakon] No standards
body defines eNPS, and one number hides the reasons; pair it with driver questions and comments.

### Playbook: people-data quality

Keep a data dictionary (meaning, owner, allowed values, sensitivity, retention per field); validate at entry (a manager must be an
active worker, a cost centre must exist); audit samples quarterly against source documents; and fix root causes with form
changes, not reminders. ISO 30435:2023 covers workforce data quality.[^iso-tc260]

### Playbook: reductions in force and collective redundancy

A reduction in force (RIF) is the riskiest leaver event PeopleOps runs: many exits at once, each with legal deadlines, a fair
selection, accounts to revoke, pay to calculate and people to support, usually under confidentiality. The rows are dated orientation
(checked 16 October 2026), not legal advice; plan every RIF with counsel ([LegalOps](../legalops/)).

| Where | Trigger | What the calendar must carry |
|---|---|---|
| Great Britain | 20 or more redundancies proposed at one establishment within 90 days | Form HR1 to the Redundancy Payments Service before consultation starts; consultation for at least 30 days (20–99) or 45 days (100+) before the first dismissal; written reasons, numbers, selection method and pay calculation[^uk-redundancy] |
| US (federal WARN) | Plant closing or mass layoff by an employer with 100+ employees as the rules count them | At least 60 days' notice, subject to the rules' thresholds and exemptions; check state law too[^warn-employer][^warn-notice] |
| EU states | Collective redundancies as national law defines them | Specified information to workers' representatives, and consultation[^eu-involvement] |
| Elsewhere | National rules | Ask counsel before the plan is fixed |

The sequence adds the statutory clock to the involuntary-exit SOP
([Artefact 5](#reference-implementation-operating-artefacts)).

::: figure Reduction-in-force sequence with the statutory clock and same-day verification
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 28}}}%%
flowchart TB
  D["Decision, confidential group, calendar per country"] --> POOL["Selection pool and documented criteria"]
  POOL --> SCR{{"Screen and legal review clear?"}}
  SCR -->|"no"| REV["Revise criteria or pool; record why"]
  REV --> POOL
  SCR -->|"yes"| CON["Consultation where law requires it"]
  CON -.->|"`selection changes`"| POOL
  CON --> PRE["Pay checked; terminations pre-entered with restricted visibility"]
  PRE --> EXE["Meetings held; accounts disabled at each effective time"]
  EXE --> VER{{"List, terminations and disabled accounts match?"}}
  VER -->|"no"| INC["Each mismatch handled as an incident"]
  VER -->|"yes"| SUP["Support leavers and those who stay"]
  INC --> SUP
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class D,POOL,CON,PRE,EXE,SUP core
  class SCR,VER decision
  class REV,INC risk
```
Text equivalent: The eight steps below, from decision to support, with two loops back to the selection pool: a failed screen or
legal review sends the criteria back, and consultation can change the selection (dotted arrow). A same-day check compares the
approved list, terminations and disabled accounts; each mismatch becomes an incident before support for leavers and those who stay.
:::

1. **Decide and protect:** scope, a small project group, no plans in shared HRIS views, calendars or notifications.
2. **Build the calendar backwards** from the exit dates; the latest legal deadline sets the earliest possible exit.
3. **Set the pool and job-related criteria before names,** then run the adverse-impact screen ([Lab 4](#hands-on-labs)) with
   counsel; with small numbers, a screen starts an investigation rather than ending one.
4. **Consult where required,** record proposals and responses, and expect the selection to move.
5. **Prepare notices and money:** payroll checks notice pay, severance and final pay before letters go out.
6. **Pre-enter every termination** with restricted visibility and an effective time matching each meeting; give system owners the
   full list, including non-SSO tools.
7. **Verify the same day:** approved list = terminations entered = accounts disabled; every mismatch is an incident.
8. **Support leavers and those who stay:** outplacement, manager briefings, re-planned workloads.

Keep the selection evidence (criteria, scores, screen results, consultation records): it is what a challenge will examine. Success
means every statutory deadline met, zero mismatches, no payroll errors and no avoidable rise in regretted attrition over the next
two quarters.

## Frameworks, regulation and tools

### Methods, standards and frameworks

Separate what you **must** do (law, contracts, collective agreements) from what you **may** adopt (standards, frameworks). Legal
facts are dated once, in the regulatory map below; other sections link to it.

- **NIST SP 800-53 PS-3, PS-4, PS-5:**[^nist-80053][^nist-oscal] screening, termination and transfer controls; required for US
  federal information systems through FIPS 200 (national security systems excepted),[^fips200] a good model elsewhere.
- **SCIM 2.0 (RFC 7643, RFC 7644):**[^scim][^scim-protocol] an optional standard for provisioning people attributes.
- **ISO/TC 260 standards (voluntary):**[^iso-tc260] among them vocabulary (ISO 30400), recruitment (30405), cost-per-hire
  (TS 30407) and workforce data quality (30435); **ISO 30414:2025** for human capital reporting, with 14 required baseline
  metrics.[^iso-30414]
- **Frameworks and definitions (voluntary):** the CIPD Profession Map,[^cipd-map] Bauer's Four C's,[^bauer] OKRs as documented by
  re:Work,[^rework-okr] BLS JOLTS turnover terms[^bls] and the WorldatWork–Deloitte pay-structure glossary.[^waw]

### Regulatory map (as of 16 October 2026)

- **GDPR Arts. 6, 9, 12(3), 88 (EU):**[^gdpr6][^gdpr9][^gdpr12][^gdpr88] lawful basis per purpose, special-category limits,
  one-month rights responses, national employment rules (see [lawful basis](#lawful-basis-and-special-category-data)).
- **CCPA (California)[^ccpa] and DPDP Act and Rules (India):**[^dpdp] employee-data rights; the CCPA since 1 January 2023; the DPDP
  Rules (notified 14 November 2025) phase in over 18 months and give ninety days to answer rights requests. How the Indian Act
  treats employment processing without consent was not verified here.
- **Form I-9 (US)[^i9] and right-to-work checks (UK):**[^uk-rtw] mandatory checks and deadlines at hire.
- **Gender pay gap reporting (GB, 250+ employees)[^uk-gpg][^uk-gpg-calc] and Pay Transparency Directive (EU):**[^eu-ptd] gap
  reports, pay information, joint assessments; EU transposition was due 7 June 2026, first reports by 7 June 2027 (phasing in
  [pay governance](#playbook-pay-governance)).
- **AI Act (EU):**[^ai-act] employment and worker-management AI, such as CV-sorting, is classified high-risk; its obligations apply
  from 2 December 2027, the date set by the AI Omnibus (in force 27 July 2026). Workplace emotion recognition has been prohibited
  since 2 February 2025.
- **Local Law 144 (New York City):**[^nyc-aedt][^nyc-faq] for tools that assess candidates for **hiring or promotion** only, an
  independent bias audit within one year before use (rates and impact ratios by sex, race/ethnicity and intersectional categories),
  a public summary and notices; enforced since 5 July 2023; no pass mark and no required action, but anti-discrimination law applies.
- **Automated-decision regulations (California):**[^ca-ads] anti-discrimination law applied to automated decisions about applicants
  and employees, with records kept at least four years; in effect since 1 October 2025.
- **Other states:** Colorado's SB26-189 (signed 14 May 2026) re-enacts its 2024 AI law as rules on automated decisions in
  employment and other areas, some duties from 1 January 2027;[^co-adm] for Illinois, a law-firm alert reports AI-in-employment
  duties in force since 1 January 2026 and proposed notice rules withdrawn in June 2026 (statute not opened).[^il-ai]
- **Uniform Guidelines, 29 CFR 1607 (US federal):**[^ugesp] the four-fifths screen and a validation framework. **Contested:** still
  in the CFR,[^ecfr-1607] but a 9 June 2026 Justice Department opinion, binding on the executive branch, calls them
  unconstitutional and reads disparate impact narrowly;[^olc-2026] OPM dropped them from federal personnel rules on 31 July
  2026;[^opm-ugesp] the EEOC lists rescission for November 2026.[^eeoc-agenda] The statute's disparate-impact provision and state
  laws remain. Ask counsel.
- **Redundancy and layoff rules:** see [reductions in force](#playbook-reductions-in-force-and-collective-redundancy).

::: warning Jurisdiction caveat and refresh cadence
Checked on 2026-10-16 for orientation only. Employment law also comes from contracts, collective agreements, works-council rights
and court decisions. Re-verify every row each quarter (contested rows sooner) and confirm obligations per country with counsel.
:::

### Tooling landscape

Start with jobs, not brands. Product names are examples whose official pages or repositories were opened on 2026-10-16, not
endorsements; features change.

| Category (job) | Examples (checked 2026-10-16) | Selection criteria | Risks |
|---|---|---|---|
| HRIS / HCM suite (system of record) | Workday HCM[^workday-hcm]; SAP SuccessFactors[^entra-hr] | Effective dating, APIs, field-level security, audit log, country coverage, export | Lock-in; long implementations |
| Open-source HRMS (self-hosted record) | OrangeHRM, GPL-3.0[^orangehrm]; Frappe HR, GPL-3.0[^frappehr] | Community activity, patching, hosting skills | You run backups, patching, access control |
| Payroll; EOR / PEO | Many providers | Country coverage, statutory filing, data access, exit terms | Silent errors; provider holds your records |
| Applicant tracking | Many vendors | Structured interviews, fairness reporting, candidate retention | Biased screening features |
| HR-driven provisioning | Microsoft Entra, with Workday, SuccessFactors or API-driven inbound[^entra-hr] | Attribute mapping, scoping, future-dated handling | Wrong mapping disables the wrong people |
| Listening (surveys, comments) | Microsoft Viva Glint[^glint]; Workday Peakon[^peakon] | Confidentiality controls, action planning | Fatigue; weak anonymity |
| Cases, performance, pay, analytics | HCM modules, service-management tools, BI on a restricted store | Restricted case types, calibration, row-level security, suppression | Sensitive data too visible; re-identification |

Before you sign, test the **exit**: can you export full effective-dated history, attachments and audit logs in a documented
format?

### Automation and AI in people operations

**Automate** where events are frequent, rules are clear and errors are costly: lifecycle events to identity, payroll, equipment and
learning; reminders for statutory forms, probation reviews, contract ends and visa expiries; documents from approved data;
reconciliation; case routing. **A human decides** hiring and rejection, termination, out-of-guideline pay, discipline,
accommodations and investigations: automation prepares the file, a person is accountable, and the affected person is heard.

| AI or LLM use | Value | Main risks | Controls |
|---|---|---|---|
| Policy answers with citations | Faster Tier 0 | Invented or outdated policy | Retrieve only approved policies; show the source; route edge cases to people |
| Summarising survey comments | Themes at scale | Re-identification; distorted themes | Same minimum groups as scores; spot checks |
| Screening or ranking candidates | Throughput | Discrimination, opacity, regulation | Treat as high-risk; bias audits; human review; legal sign-off |
| Predicting individual attrition | Early warning | Self-fulfilling labels, privacy, fairness | Usually avoid; use group-level insight |

Regulation of these uses is growing and uneven (dated in the [regulatory map](#regulatory-map-as-of-16-october-2026)): map every
jurisdiction where candidates or workers are before you buy. A vendor's model is still your decision process, so get its
documentation, run your own adverse-impact screen and keep a human who can explain the outcome (procurement checklist in the
[toolkit](#checklists)).

## PeopleOps in practice

### Reference implementation: operating artefacts

::: example Illustrative scenario: ExampleCo
ExampleCo is a fictional software company with about 420 employees in three countries, one HCM suite as system of record, a
cloud identity provider, a payroll provider per country and a small People team, including a three-person PeopleOps team with one
HRIS analyst. Everything below is an example.
:::

**Artefact 1: attribute ownership matrix**

| Attribute | System of record | Consumers | Change rule |
|---|---|---|---|
| Worker ID | HRIS (immutable) | All | Never changes or reused |
| Legal and preferred name | HRIS (self-service; legal name approved) | Identity, payroll | Effective-dated |
| Work email, username | Identity provider | HRIS (write-back), apps | Generated at hire |
| Job, grade, manager, cost centre, location | HRIS | Identity, payroll, finance, LMS | Effective-dated; approved |
| Base pay | HRIS compensation | Payroll | Approved; range-checked |
| Bank and tax details | Payroll provider | — | Self-service in payroll |
| Termination date and time | HRIS | Identity, payroll, IT assets, finance | Future-dated; top-priority event |

**Artefact 2: a lifecycle event**

_Example status: syntax-checked by the Atlas validator, not executed (illustrative schema for an internal event bus)._

```json
{
  "event_type": "worker.terminated",
  "event_id": "8f0c2a7e-5d3b-4f61-9a2e-1b7c3d9e4f10",
  "occurred_at": "2026-10-12T09:14:03Z",
  "effective_at": "2026-10-16T17:00:00+01:00",
  "worker_id": "W-004211",
  "worker_type": "employee",
  "termination": {
    "category": "voluntary",
    "regretted": true,
    "last_working_day": "2026-10-16"
  },
  "changed_by": "W-000317",
  "source_system": "hris",
  "schema_version": "1.2"
}
```

Note what is absent: no reason narrative, health or performance data. Downstream systems need the fact and the time.

**Artefact 3: a SCIM update for a mover**

For a worker who moves department and manager, a SCIM PATCH with RFC 7643's enterprise user attributes and RFC 7644's PatchOp
message.[^scim][^scim-protocol]

_Example status: syntax-checked, not executed (requires a SCIM 2.0 service provider; IDs are placeholders)._

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department",
      "value": "Payments Platform"
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter",
      "value": "CC-4410"
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager",
      "value": { "value": "2819c223-7f76-453a-919d-413861904646" }
    }
  ]
}
```

**Artefact 4: onboarding checklist as code**

Checklists in version control (GitLab uses issue templates[^gitlab-onb]) give history, review and reuse.

_Example status: syntax-checked, not executed (a template format for a generic workflow tool)._

```yaml
template: onboarding
version: 3
applies_to:
  worker_types: [employee]
  countries: [all]
due_window_days: 30
tasks:
  - id: preboard-contract
    owner: peopleops
    due: "start-10d"
    description: Contract signed and stored in the HRIS
  - id: preboard-device
    owner: it-assets
    due: "start-5d"
    description: Device shipped with tracking number recorded
  - id: day1-access
    owner: identity
    due: "start"
    description: Account enabled at local start time; birthright groups assigned
  - id: day1-plan
    owner: manager
    due: "start+3d"
    description: Written 30/60/90 plan shared with the new joiner
  - id: week1-buddy
    owner: manager
    due: "start+5d"
    description: Buddy assigned and first meeting held
  - id: us-i9-section2
    owner: peopleops
    due: "start+3 business days"
    when: { country: US }
    description: Form I-9 Section 2 completed
  - id: survey-30
    owner: people-analytics
    due: "start+30d"
    description: 30-day onboarding survey sent
completion_rule: every task is either done or marked not applicable with a reason
```

**Artefact 5: offboarding SOP (involuntary exit)**

1. **T−2 working days.** People Partner confirms decision and timing with the manager; PeopleOps prepares the termination record
   with restricted visibility and an effective time matching the meeting.
2. **T−1.** IT and identity list the systems, including non-SSO tools, shared credentials and bots the person owns.
3. **T (meeting start).** Manager and People Partner hold the conversation; the termination takes effect, identity disables the
   account and revokes sessions, and IT locks the device if policy requires.
4. **T+1 hour.** PeopleOps confirms disablement in the reconciliation report; system owners confirm non-SSO removals.
5. **T+1 working day.** Files, repositories and shared mailboxes transferred; property return arranged.
6. **Payday rules.** Final pay per the contract and local law.
7. **T+5 working days.** Checklist closed with evidence; exceptions escalated.

Variants: voluntary exits skip the choreography and add an exit survey; death in service needs family liaison and benefits
claims; a move to contractor status is a full offboarding plus a new, limited onboarding (GitLab's documented practice[^gitlab-offb]).

**Artefact 6: HR request intake form**

_Example status: syntax-checked, not executed (a form definition for a generic case-management tool)._

```yaml
form: employment-change-request
audience: managers
fields:
  - name: worker_id
    type: worker_lookup
    required: true
  - name: change_type
    type: choice
    options: [promotion, transfer, manager_change, location_change, hours_change]
    required: true
  - name: effective_date
    type: date
    required: true
    validation: "must be today or later; not more than 90 days ahead"
  - name: new_grade
    type: grade_lookup
    required_if: { change_type: [promotion] }
  - name: proposed_base_pay
    type: money
    visibility: [requester, total_rewards, peopleops]
    validation: "warn if outside the range for new_grade"
  - name: justification
    type: text
    required: true
routing:
  approvals: [requester_manager, people_partner]
  extra_approval_if_outside_range: total_rewards
sla:
  first_response_working_days: 1
  completion_working_days: 5
```

**Artefact 7: HR service catalogue (extract)**

Each request has one owner, a channel, a service level and a confidentiality class that decides which queue may see it. Five of
ExampleCo's rows:

| Request | Owner (tier) | Channel | Service level | Confidentiality class |
|---|---|---|---|---|
| Pay or payslip question | PeopleOps desk (1), then payroll (2) | Portal case | First response 1 working day; resolved in 5 | Restricted: pay |
| Employment change (promotion, transfer, manager) | PeopleOps desk (1) | Intake form (Artefact 6) | Entered within 5 working days of approval, before the effective date | Restricted: pay fields |
| Employment verification letter | Self-service (0); desk (1) as fallback | Portal; letter generated from HRIS data | Instant; 2 working days by hand | Internal |
| Leave or workplace adjustment | Desk (1), then leave specialist (2) | Portal case of a restricted type | First response 1 working day | Special category: health |
| Grievance or harassment report | Employee relations (confidential bypass) | Confidential channel, named handlers only | Acknowledged in 1 working day; investigator named in 5 | Confidential: investigation |

Review the catalogue quarterly against case data: requests that keep arriving outside it need a row or a Tier 0 article.

### Hands-on labs

Four labs on **synthetic data only**: Python 3.8 or later and a bash shell, standard library only, no accounts, no cost. Each lab
was run on 2026-10-16 exactly as printed (Python 3.8.10, Ubuntu Linux); expected outputs are copied from those runs.

::: warning Never practise on real employee data
Real people data needs an approved purpose, access rights and secure storage; do not copy HR exports to a laptop for these labs.
:::

#### Lab 1 (beginner): people metrics from an event log

**Objective.** Compute headcount, hires, separations, separation rates and first-year leavers from an effective-dated event
log, and understand each formula. **Prerequisites.** Python 3.8+. **Time.** 20 minutes. **Risk.** None (synthetic data).

1. Create a working folder and the event log.

_Example status: verified by execution on 2026-10-16 (bash, Linux)._

```bash
mkdir -p ~/peopleops-labs/lab1 && cd ~/peopleops-labs/lab1
cat > events.csv <<'EOF'
employee_id,event,effective_date,hire_date,reason,regretted,department
E001,hire,2026-01-05,2026-01-05,,,Engineering
E002,hire,2026-01-12,2026-01-12,,,Sales
E003,termination,2026-01-30,2024-03-01,voluntary,yes,Engineering
E004,hire,2026-02-02,2026-02-02,,,Support
E005,termination,2026-02-13,2025-11-03,voluntary,no,Sales
E006,termination,2026-02-27,2021-06-14,involuntary,no,Support
E007,transfer,2026-03-02,2023-09-04,,,Engineering
E008,hire,2026-03-09,2026-03-09,,,Engineering
E009,termination,2026-03-20,2025-08-18,voluntary,yes,Engineering
E010,termination,2026-03-31,2019-02-11,voluntary,no,Finance
EOF
```

2. Save the script as `metrics.py`.

_Example status: verified by execution on 2026-10-16 (Python 3, standard library)._

```python
"""Quarterly people metrics from an effective-dated event log (standard library only)."""
import csv
from datetime import date

START_HEADCOUNT = 120          # active employees on 2026-01-01 (from the HRIS snapshot)
PERIOD_START = date(2026, 1, 1)
PERIOD_END = date(2026, 3, 31)

with open("events.csv", newline="") as f:
    events = list(csv.DictReader(f))

hires = [e for e in events if e["event"] == "hire"]
leavers = [e for e in events if e["event"] == "termination"]
voluntary = [e for e in leavers if e["reason"] == "voluntary"]
regretted = [e for e in voluntary if e["regretted"] == "yes"]

def tenure_days(e):
    return (date.fromisoformat(e["effective_date"]) - date.fromisoformat(e["hire_date"])).days

first_year = [e for e in leavers if tenure_days(e) < 365]

end_headcount = START_HEADCOUNT + len(hires) - len(leavers)
avg_headcount = (START_HEADCOUNT + end_headcount) / 2

def rate(n):
    return round(100 * n / avg_headcount, 2)

print(f"Period {PERIOD_START} to {PERIOD_END}")
print(f"Headcount start={START_HEADCOUNT} end={end_headcount} average={avg_headcount}")
print(f"Hires={len(hires)} Separations={len(leavers)} Transfers={sum(e['event'] == 'transfer' for e in events)}")
print(f"Separation rate (quarter)       = {rate(len(leavers))}%")
print(f"Voluntary separation rate       = {rate(len(voluntary))}%")
print(f"Regretted voluntary rate        = {rate(len(regretted))}%")
print(f"Leavers with < 1 year tenure    = {len(first_year)} of {len(leavers)}")
print(f"Annualised separation rate      = {round(rate(len(leavers)) * 4, 1)}% (naive x4; see caveats)")
```

3. Run it with `python3 metrics.py`.

**Expected output.**

```text
Period 2026-01-01 to 2026-03-31
Headcount start=120 end=119 average=119.5
Hires=4 Separations=5 Transfers=1
Separation rate (quarter)       = 4.18%
Voluntary separation rate       = 3.35%
Regretted voluntary rate        = 1.67%
Leavers with < 1 year tenure    = 2 of 5
Annualised separation rate      = 16.7% (naive x4; see caveats)
```

**Validation.** By hand: 5 ÷ 119.5 × 100 = 4.18%, mirroring the US Bureau of Labor Statistics convention (separations ÷
employment × 100) with average headcount as a documented internal denominator. The transfer (E007) is not a separation; BLS also
excludes transfers within the same location.[^bls] Multiplying by four is naive when leaving is seasonal.

**Troubleshooting.** `FileNotFoundError`: run the script in the folder that contains `events.csv`.

**Teardown.** `rm -rf ~/peopleops-labs/lab1`

#### Lab 2 (intermediate): find orphan accounts and measure revocation latency

**Objective.** Reconcile the HR record with an identity-provider export, find terminated-but-active accounts and accounts with no
HR record, and measure on-time revocation. **Prerequisites.** Lab 1. **Time.** 30 minutes. **Risk.** None (synthetic data).

1. Create the two exports.

_Example status: verified by execution on 2026-10-16 (bash, Linux)._

```bash
mkdir -p ~/peopleops-labs/lab2 && cd ~/peopleops-labs/lab2
cat > hris.csv <<'EOF'
employee_id,work_email,status,termination_effective_utc
E101,ana@example.com,active,
E102,ben@example.com,terminated,2026-10-01T17:00:00Z
E103,chen@example.com,terminated,2026-10-02T09:00:00Z
E104,dev@example.com,terminated,2026-10-05T12:00:00Z
E105,eva@example.com,active,
E106,femi@example.com,terminated,2026-10-06T16:30:00Z
EOF
cat > idp.csv <<'EOF'
email,status,disabled_at_utc
ana@example.com,active,
ben@example.com,disabled,2026-10-01T17:20:00Z
chen@example.com,disabled,2026-10-03T11:00:00Z
dev@example.com,active,
eva@example.com,active,
femi@example.com,disabled,2026-10-06T16:45:00Z
gil@example.com,active,
EOF
```

2. Save as `reconcile.py`. (It joins on email because many identity exports lack the HR worker ID; real systems should join on
   the immutable ID.)

_Example status: verified by execution on 2026-10-16 (Python 3, standard library)._

```python
"""Compare the HR system of record with the identity provider export (standard library only)."""
import csv
from datetime import datetime, timedelta

SLA = timedelta(hours=1)   # policy: access disabled within 1 hour of termination effective time

def load(path, key):
    with open(path, newline="") as f:
        return {row[key].lower(): row for row in csv.DictReader(f)}

def ts(value):
    return datetime.fromisoformat(value.replace("Z", "+00:00"))

hris = load("hris.csv", "work_email")
idp = load("idp.csv", "email")

orphans = [e for e, r in hris.items() if r["status"] == "terminated" and idp.get(e, {}).get("status") == "active"]
unknown = [e for e in idp if e not in hris and idp[e]["status"] == "active"]
missing = [e for e, r in hris.items() if r["status"] == "active" and e not in idp]

within, breached = [], []
for e, r in hris.items():
    acct = idp.get(e)
    if r["status"] != "terminated" or not acct or not acct["disabled_at_utc"]:
        continue
    latency = ts(acct["disabled_at_utc"]) - ts(r["termination_effective_utc"])
    (within if latency <= SLA else breached).append((e, latency))

leavers = sum(r["status"] == "terminated" for r in hris.values())
print(f"Leavers in HRIS: {leavers}")
print(f"ORPHAN active accounts (terminated in HRIS, active in IdP): {orphans}")
print(f"Active IdP accounts with no HRIS record: {unknown}")
print(f"Active employees without an IdP account: {missing}")
for e, lat in breached:
    print(f"SLA BREACH {e}: disabled {lat} after termination")
print(f"Revocation within SLA: {len(within)}/{leavers} = {round(100 * len(within) / leavers)}%")
```

3. Run `python3 reconcile.py`.

**Expected output.**

```text
Leavers in HRIS: 4
ORPHAN active accounts (terminated in HRIS, active in IdP): ['dev@example.com']
Active IdP accounts with no HRIS record: ['gil@example.com']
Active employees without an IdP account: []
SLA BREACH chen@example.com: disabled 1 day, 2:00:00 after termination
Revocation within SLA: 2/4 = 50%
```

**Validation.** Ben (20 minutes) and femi (15 minutes) met the one-hour policy; chen took 26 hours; dev is still active: 2 ÷ 4 =
50%. The denominator is *all leavers*, so the orphan counts as a failure.

**Troubleshooting.** `ValueError: Invalid isoformat string`: Python before 3.11 rejects a trailing `Z`, which is why the script
replaces it with `+00:00`.

**What to do next.** Disable dev@example.com and follow the [runbook](#worked-incident-a-leaver-who-kept-access); find an owner for
gil@example.com (perhaps a contractor created outside the HR process).

**Teardown.** `rm -rf ~/peopleops-labs/lab2`

#### Lab 3 (intermediate): eNPS with confidentiality protection

**Objective.** Calculate eNPS overall and by team, hide small teams, and apply complementary suppression so hidden teams cannot be
recovered by subtraction. **Prerequisites.** Python 3.8+; Lab 1. **Time.** 30 minutes. **Risk.** None (synthetic data).

1. Create the responses (team and score only; no names).

_Example status: verified by execution on 2026-10-16 (bash, Linux)._

```bash
mkdir -p ~/peopleops-labs/lab3 && cd ~/peopleops-labs/lab3
printf '%s\n' "team,score" \
  Platform,8 Platform,6 Platform,9 Platform,3 Platform,9 Platform,10 Platform,7 Platform,8 Platform,9 \
  Payments,3 Payments,9 Payments,7 Payments,4 Payments,5 Payments,8 Payments,6 \
  Mobile,9 Mobile,7 Mobile,10 Mobile,9 Mobile,6 Mobile,8 \
  Data,9 Data,8 Data,3 Data,10 Data,5 Data,7 \
  Design,10 Design,2 > responses.csv
```

2. Save as `enps.py`.

_Example status: verified by execution on 2026-10-16 (Python 3, standard library)._

```python
"""eNPS by team with a minimum reporting group and complementary suppression (standard library only)."""
import csv
from collections import defaultdict

MIN_GROUP = 5        # do not show a team score with fewer respondents than this
MIN_HIDDEN = 5       # hidden respondents must total at least this, or the next-smallest team is hidden too

scores = defaultdict(list)
with open("responses.csv", newline="") as f:
    for row in csv.DictReader(f):
        scores[row["team"]].append(int(row["score"]))

def enps(values):
    promoters = sum(v >= 9 for v in values)
    detractors = sum(v <= 6 for v in values)
    return round(100 * (promoters - detractors) / len(values))

everyone = [v for vs in scores.values() for v in vs]
print(f"Company: n={len(everyone)} eNPS={enps(everyone)}")

hidden = {t for t, vs in scores.items() if len(vs) < MIN_GROUP}
# Complementary suppression: if the hidden teams are few, a reader could subtract the
# visible teams from the company total and recover them, so hide the next-smallest team as well.
while hidden and sum(len(scores[t]) for t in hidden) < MIN_HIDDEN:
    visible = sorted((len(vs), t) for t, vs in scores.items() if t not in hidden)
    if not visible:
        break
    hidden.add(visible[0][1])

for team in sorted(scores):
    n = len(scores[team])
    shown = "suppressed" if team in hidden else f"eNPS={enps(scores[team])}"
    print(f"{team:<9} n={n:<2} {shown}")
```

3. Run `python3 enps.py`.

**Expected output.**

```text
Company: n=30 eNPS=3
Data      n=6  suppressed
Design    n=2  suppressed
Mobile    n=6  eNPS=33
Payments  n=7  eNPS=-43
Platform  n=9  eNPS=22
```

**Validation.** Company: (11 promoters − 10 detractors) ÷ 30 × 100 ≈ 3. With only Design (two respondents) hidden, anyone could
subtract the visible teams from the company total, so the script also hides the next-smallest team (Data), as commercial tools'
suppression setting does.[^glint] Payments' −43 from seven people is a conversation starter, not a verdict: one changed answer moves
it by about 14 points.

**Troubleshooting.** Scores too large? Passives (7–8) must count in the denominator but in neither group.

**Teardown.** `rm -rf ~/peopleops-labs/lab3`

#### Lab 4 (advanced): pay-band and selection-rate screens

**Objective.** Compute compa-ratio and range penetration, flag out-of-range pay, compute mean and median gender pay gaps (GOV.UK
formula) and run a four-fifths screen on selection rates. **Prerequisites.** Python 3.8+; Lab 1; the
[glossary](#glossary-and-mental-model) terms for pay ranges. **Time.** 45 minutes. **Risk.** None with synthetic data; with real data
this is restricted analysis needing an approved purpose, a recorded lawful basis and legal input.

1. Create bands, pay and selection data.

_Example status: verified by execution on 2026-10-16 (bash, Linux)._

```bash
mkdir -p ~/peopleops-labs/lab4 && cd ~/peopleops-labs/lab4
cat > bands.csv <<'EOF'
grade,minimum,midpoint,maximum
G3,48000,60000,72000
G4,60000,75000,90000
EOF
cat > pay.csv <<'EOF'
employee_id,grade,sex,annual_base,weekly_hours
P01,G3,F,52000,40
P02,G3,M,61000,40
P03,G3,F,58000,40
P04,G3,M,66000,40
P05,G3,F,47000,40
P06,G4,M,78000,40
P07,G4,F,70000,40
P08,G4,M,88000,40
P09,G4,F,74000,40
P10,G4,M,93000,40
EOF
cat > selection.csv <<'EOF'
group,applicants,selected
A,120,30
B,80,12
EOF
```

2. Save as `fairness.py`.

_Example status: verified by execution on 2026-10-16 (Python 3, standard library)._

```python
"""Pay-band and selection-rate screens on synthetic data (standard library only).
A screen flags things to investigate; it is not a legal or statistical conclusion."""
import csv
from statistics import mean, median

with open("bands.csv", newline="") as f:
    bands = {r["grade"]: {k: float(v) for k, v in r.items() if k != "grade"} for r in csv.DictReader(f)}
with open("pay.csv", newline="") as f:
    people = list(csv.DictReader(f))

print("id   grade sex compa  penetration flag")
for p in people:
    b = bands[p["grade"]]
    pay = float(p["annual_base"])
    compa = pay / b["midpoint"]
    penetration = (pay - b["minimum"]) / (b["maximum"] - b["minimum"])
    flag = "BELOW-MIN" if pay < b["minimum"] else "ABOVE-MAX" if pay > b["maximum"] else ""
    print(f"{p['employee_id']}  {p['grade']}    {p['sex']}   {compa:.2f}   {penetration:6.0%}      {flag}")

def hourly(p):
    return float(p["annual_base"]) / (52 * float(p["weekly_hours"]))

men = [hourly(p) for p in people if p["sex"] == "M"]
women = [hourly(p) for p in people if p["sex"] == "F"]
print(f"Mean hourly gap   = {100 * (mean(men) - mean(women)) / mean(men):.1f}% of men's mean pay")
print(f"Median hourly gap = {100 * (median(men) - median(women)) / median(men):.1f}% of men's median pay")

for grade in sorted(bands):
    m = [p for p in people if p["grade"] == grade and p["sex"] == "M"]
    w = [p for p in people if p["grade"] == grade and p["sex"] == "F"]
    cm = mean(float(p["annual_base"]) for p in m) / bands[grade]["midpoint"]
    cw = mean(float(p["annual_base"]) for p in w) / bands[grade]["midpoint"]
    print(f"{grade}: mean compa-ratio men={cm:.2f} women={cw:.2f} (n={len(m)}+{len(w)})")

with open("selection.csv", newline="") as f:
    groups = {r["group"]: int(r["selected"]) / int(r["applicants"]) for r in csv.DictReader(f)}
top = max(groups.values())
for g, r in sorted(groups.items()):
    ratio = r / top
    print(f"Group {g}: selection rate {r:.1%}, impact ratio {ratio:.2f}{'  < 0.80: investigate' if ratio < 0.8 else ''}")
```

3. Run `python3 fairness.py`.

**Expected output.**

```text
id   grade sex compa  penetration flag
P01  G3    F   0.87      17%      
P02  G3    M   1.02      54%      
P03  G3    F   0.97      42%      
P04  G3    M   1.10      75%      
P05  G3    F   0.78      -4%      BELOW-MIN
P06  G4    M   1.04      60%      
P07  G4    F   0.93      33%      
P08  G4    M   1.17      93%      
P09  G4    F   0.99      47%      
P10  G4    M   1.24     110%      ABOVE-MAX
Mean hourly gap   = 22.0% of men's mean pay
Median hourly gap = 25.6% of men's median pay
G3: mean compa-ratio men=1.06 women=0.87 (n=2+3)
G4: mean compa-ratio men=1.15 women=0.96 (n=3+2)
Group A: selection rate 25.0%, impact ratio 1.00
Group B: selection rate 15.0%, impact ratio 0.60  < 0.80: investigate
```

**Validation.** Men's mean pay is 77,200 and women's 60,200: (77,200 − 60,200) ÷ 77,200 = 22.0%, the GOV.UK gap
formula,[^uk-gpg-calc] with hourly pay simplified (annual base ÷ 52 ÷ weekly hours; GOV.UK uses ordinary pay in the relevant pay
period). Group B's rate (15%) ÷ group A's (25%) = 0.60, below the four-fifths threshold of the US Uniform Guidelines, which also
warn that small samples need care.[^ugesp] Treat 0.80 as an internal trigger for investigation, not a safe harbour: the
Guidelines' federal status is contested in 2026 (see the [regulatory map](#regulatory-map-as-of-16-october-2026)).

**Interpretation.** The unadjusted gap mixes grade mix and pay within grade (see
[adjusted gaps](#metrics-and-kpis)); women's mean compa-ratio is lower in both grades, but with two or three people per cell
nothing is statistically meaningful. Review P05 and P10, look for documented legitimate factors, and involve counsel.

**Teardown.** `rm -rf ~/peopleops-labs/lab4`

### Use cases and scenarios

Two cases are documented by the organisations involved, one applies documented rules to a fictional employer, and one is
illustrative (a post-acquisition HRIS merger follows the [go-live preflight](#checklists)).

#### Scenario 1: event-driven offboarding at GitLab (documented)

GitLab's offboarding standard says a termination approved and completed in Workday automatically creates parent and child cases on
the last working day; system owners revoke access within five working days (critical systems within 24 hours), laptops come back
within two to four weeks, and each ticked checkbox records that access was revoked or never given.[^gitlab-offb] Automation makes
the HR entry the single point of failure, so its timing becomes a control; the standard flags one manual fallback step as needing
confirmation, a reminder that fallbacks drift. *Trade-off:* speed and evidence versus dependence on a timely HR entry. *Success:*
tasks closed within the stated windows.

#### Scenario 2: onboarding measured over the first year at Google (documented)

Google repeats the same short, voluntary, confidential survey at 30, 90 and 365 days (tools, productivity and skills, culture and
connection), analyses it by segment, and used the results to link company orientation with local onboarding and add
community-building.[^rework-onb] Copying the survey without that follow-through gains nothing. *Trade-off:* trend data versus
survey fatigue. *Success:* improvement across cohorts and lower first-year attrition (measured as in
[cohort and survival views](#metrics-and-kpis)).

#### Scenario 3: an AI screening tool in New York City (rules documented, employer illustrative)

::: example Illustrative scenario
A fictional retailer hiring 2,000 seasonal staff in New York City wants a vendor tool that ranks applications.
:::

The tool assesses candidates for hiring, so Local Law 144 applies ([regulatory map](#regulatory-map-as-of-16-october-2026)),
including notices to candidates who live in the city ten business days before use.[^nyc-faq] PeopleOps and Legal commission and
publish the bias audit, add notices to adverts and the application flow, and offer a human review path. The law sets no pass mark,
so they add **their own control**, not a city rule: monthly impact ratios, any group below 0.80 investigated (Lab 4). Pitfalls:
treating last year's audit as permanent, and reading a passed audit as proof of fairness. *Trade-off:* throughput versus legal and
fairness risk. *Success:* a current audit, provable notices, every flagged ratio investigated.

#### Scenario 4: preparing for EU pay transparency (illustrative)

::: example Illustrative scenario
A fictional 300-person company employs people in three EU countries and has never published pay ranges.
:::

Build the job architecture, set ranges from market data, analyse gaps for equal work and work of equal value, close unexplained
gaps, stop asking about salary history, then publish ranges as each country's law requires; ranges published before the
architecture is fixed cannot be defended. **Timeline** (phasing in [pay governance](#playbook-pay-governance)): three national
entities of 100–149 people would first report gaps by 7 June 2031 (an entity under 100 has no directive duty unless national law
adds one), a single employer of 300 by 7 June 2027; the pay-information and salary-history rules have no size
threshold.[^eu-ptd] *Trade-off:* exposing legacy inconsistencies versus future claims. *Success:* a range for every job and every
unexplained gap closed or scheduled.

## Measurement, risk and cost

### Metrics and KPIs

Measure the **service** (is the lifecycle working?), the **outcome** (are people staying, growing, treated fairly?) and the
**data** (can we trust the numbers?), with written, stable definitions.

| KPI | Definition / formula | Pitfall |
|---|---|---|
| Day-one readiness | Joiners with account, device and plan ready on day one ÷ joiners | Unchecked self-reports |
| Revocation within SLA | Leavers disabled within the policy time ÷ all leavers (identity logs) | Orphans left out of the denominator |
| Terminations entered on time | Entered before the effective time ÷ terminations (HRIS audit log) | Back-dating hides lateness |
| Separation rate | Separations ÷ average headcount × 100 per period (BLS divides by employment)[^bls] | Mixing separation types |
| Voluntary, regretted attrition | Voluntary (or regretted) separations ÷ average headcount × 100 | "Regretted" decided after the fact |
| First-year attrition | Hires who left within 12 months ÷ hires in the cohort | Counting hires not yet observed for a year |
| Cost per hire | (Internal + external recruiting costs) ÷ hires; see ISO/TS 30407[^iso-tc260] | Inconsistent cost scope |
| HR case SLA attainment | Cases resolved within target ÷ cases (case tool) | Closing unsolved cases |
| Data accuracy | Sampled fields matching sources ÷ sampled fields | Sampling easy fields only |
| eNPS and response rate | % promoters − % detractors; responses ÷ invited[^bain-nps] | Small groups; eNPS as a target |
| Out-of-range pay | Employees below minimum or above maximum | Stale ranges |
| Pay gap (unadjusted) | (Men's mean or median hourly pay − women's) ÷ men's × 100, GOV.UK method[^uk-gpg-calc] | Reading it as an equal-pay result |

**Leading** indicators (terminations entered on time, readiness, open SLA breaches) can be acted on now; **lagging** ones
(attrition, pay gaps, audit findings) confirm results. Report attrition as rolling twelve-month rates.

**Worked calculation**

::: example Illustrative numbers for a fictional 400-person company over twelve months
Headcount was 380 at the start and 420 at the end, so the average is 400. There were 56 separations: 40 voluntary (22 of them
regretted), 12 involuntary and 4 other.
:::

- Separation rate = 56 ÷ 400 × 100 = **14.0%**. Voluntary = 40 ÷ 400 = **10.0%**. Regretted = 22 ÷ 400 = **5.5%**.
- Of 80 people hired in the previous year's cohort, 12 left within twelve months: first-year attrition = 12 ÷ 80 = **15.0%**.
- Day-one readiness: 88 of 96 = **91.7%**, below a 95% goal; late contract signature, not IT, caused six of the eight misses.
- Access revoked within one hour: 50 of 56 = **89.3%**; all six misses were involuntary exits entered after the event.

The numbers point to early-career issues and to late HR entries behind the access and readiness misses: a process fix, not a
technology purchase.

#### Analysis beyond the headline number: cohorts, survival and adjusted gaps

**Cohorts and survival curves.** A period attrition rate mixes last month's hires with twenty-year veterans, so track each hiring
cohort's share still employed at 3, 6 and 12 months. On any snapshot date most people have not left; their final tenure is unknown
(*censored*), and averaging leavers alone is biased. The Kaplan–Meier method handles this: the probability of staying past a point
is the product of the conditional probabilities of staying through each interval, and censored people count as "at risk" until
they drop out of view. Its key assumption, that people whose observation ends early have the same prospects as those still
followed, is "not easily testable",[^km] so write down how you treat transfers, dismissals and the snapshot date.

::: example Illustrative cohort of 20 hires, observed for up to a year
Months 0–3: 20 at risk, 2 leave: 18 ÷ 20 = 0.90 stay. Four late joiners reach the snapshot date after three months (censored).
Months 3–6: 14 at risk,
1 leaves: 13 ÷ 14 = 0.929. Three more are censored. Months 6–12: 10 at risk, 2 leave: 8 ÷ 10 = 0.80. Twelve-month retention =
0.90 × 0.929 × 0.80 ≈ **0.67**, so about one hire in three leaves within a year; the naive 5 of 20 (25%) understates it because
seven people were never observed for a full year.
:::

**Adjusted and unadjusted pay gaps.** The headline gap is computed "without correcting for differences in individual and job
characteristics"; Eurostat explains that it reflects both differences in the average characteristics of men and women and
differences in the financial returns for the same characteristics.[^eurostat-gpg] An adjusted analysis estimates the gap that
remains among comparable workers, for example by regressing pay on documented legitimate factors (grade, job family, location,
tenure) plus sex. Two cautions: a control can carry the bias you are looking for (if women are graded lower for the same work,
controlling for grade hides it), so also analyse who reaches which grade; and equal pay is judged per category of equal work or
work of equal value, which is how the Directive's 5% joint-assessment trigger is framed.[^eu-ptd]

**Causation, noise and traps.** Google's people-analytics guide warns against confusing correlation with causation and against
regression to the mean.[^rework-pa] Small groups swing wildly: use rolling windows and counts. Activity counts (trainings delivered,
policies published) say little about outcomes, and eNPS as a target raises scores and lowers information (see the
[judgement call](#a-judgement-call-should-manager-bonuses-depend-on-team-engagement-scores)). "Industry average attrition" rarely
states its denominator, so this page gives none: compare yourself with yourself. Constructs differ too: Gallup's engagement
measure (20% of employees worldwide engaged in 2025, by its count) is not an eNPS.[^gallup] Every dashboard states its worker
types, treatment of rehires and transfers, suppression rules and extraction date.

### Privacy, security and compliance

People data is among the most sensitive an organisation holds: identity documents, bank details, pay, health, family, diversity,
performance and investigations. This is not legal advice; laws are dated in the
[regulatory map](#regulatory-map-as-of-16-october-2026).

| Risk | Likelihood / impact | Signal | Mitigation | Owner |
|---|---|---|---|---|
| Leaver keeps access | Medium / high | Terminated-but-active accounts | Future-dated terminations, event-driven disablement, daily reconciliation (NIST PS-4[^nist-oscal]) | PeopleOps (trigger), Identity (action) |
| Access accumulates after moves | High / medium | Access from several old roles | Mover-triggered review (NIST PS-5[^nist-oscal]) | Identity, AccessOps |
| Pay or health data over-exposed | Medium / high | Broad HRIS roles; reports emailed | Field-level security; quarterly role reviews | HRIS analyst |
| Investigation leak | Low / very high | Grievances in shared queues | Restricted case types, named handlers, audit log | Employee relations |
| Re-identification in analytics | Medium / high | Results for tiny groups | Minimum group sizes and complementary suppression[^glint] | People analytics |
| Unlawful monitoring | Medium / high | Activity tracking adopted without assessment | Purpose and proportionality test, transparency, consultation; national rules (for the UK, the ICO's monitoring guidance, under review after the Data (Use and Access) Act[^ico-monitor]) | Privacy with PeopleOps |
| Discriminatory selection or pay | Medium / high | Impact ratios below your threshold; unexplained gaps | Structured processes, screens, documented factors | Talent acquisition, total rewards |
| Over-retention | High / medium | Records of long-gone leavers | [Retention schedule](#templates) with automated, evidenced deletion | PeopleOps with privacy |

**Least privilege inside HR systems.** Define HRIS roles by need (managers see their reports' job data, not health data; payroll
sees bank details; analysts see pseudonymised extracts; very few see investigations); keep diversity and health data in restricted
fields; log access to sensitive fields; and review HRIS role assignments quarterly, because people inside HR change jobs too.

### Lawful basis and special-category data

Under the GDPR and laws modelled on it, the first design question for any use of HR data is not "is it useful?" but "on what
lawful basis?", recorded per purpose (Article 6).[^gdpr6] Typical bases at work are the contract (the European Data Protection
Board's example: salary and bank details so wages can be paid), a legal obligation (tax, right-to-work records) and legitimate
interests, which need a balancing test against the worker's interests and rights.[^edpb-consent][^gdpr6]

**Consent rarely works at work.** The Board "deems it problematic for employers to process personal data of current or future
employees on the basis of consent as it is unlikely to be freely given"; employees can consent freely only in exceptional
circumstances, when refusing has no adverse consequences at all.[^edpb-consent] A clicked box does not make a survey or a
monitoring tool "consented".

**Special-category data** (among others racial or ethnic origin, trade-union membership, biometric data used to identify people,
health, sex life or sexual orientation) needs an Article 9 exception, such as obligations "in the field of employment and social
security and social protection law" authorised by Union or Member State law or a collective agreement (Art. 9(2)(b)), or
occupational medicine and assessing working capacity (Art. 9(2)(h)); Member States may add conditions for genetic, biometric and
health data.[^gdpr9] Operating rules that follow:

- A lawful-basis column in the HR record of processing (with [PrivacyOps](../privacyops/)) and on every analytics request
  ([request form](#templates)).
- Diversity data only as a voluntary, separate purpose with a "prefer not to say" option, stored apart and reported only in
  aggregate above the minimum group size; health data only as leave, adjustments and occupational health need, in restricted fields.
- For surveys, analytics and monitoring, a documented basis and proportionality assessment, and national rules such as
  works-council consultation checked before launch.

**Rights requests and evidence.** Former employees often exercise data rights during disputes; the deadlines are in the regulatory
map and the workflow belongs to [PrivacyOps](../privacyops/), while PeopleOps makes sure HR data can be found, reviewed for
third-party information and released on time. Keep proof that controls ran (disablement logs, checklist completions, HRIS role
reviews, pay-screen decisions, survey thresholds, deletion logs); framework-level evidence belongs to
[ComplianceOps](../complianceops/).

### Cost, capacity and sustainability

The cost drivers are the People team (levers: self-service, automation, clear tiers), software (often priced per employee or
module), payroll and benefits providers, integration, and rework from late entries and re-keying.

This page gives no benchmark costs or HR-to-employee ratios: published figures use different definitions and samples, and none
could be verified. Compute your own: **people-team cost per employee** (People salaries, software and providers
÷ average headcount), **cases per PeopleOps FTE** alongside SLA attainment, **cost per hire**, and the **cost of a late termination**
(incident hours plus accepted risk), which often justifies automation.

**Capacity.** Load is lumpy (hiring waves, pay and performance cycles, surveys, reorganisations, layoffs): keep the pay and
performance cycles apart and keep a tested [RIF playbook](#playbook-reductions-in-force-and-collective-redundancy). A custom HRIS is
rarely justified; when buying, count lifecycle cost (implementation, integration, yearly configuration, audits, eventual migration).

**Sustainability.** PeopleOps' own footprint is small (reuse returned laptops; onboarding travel). Workforce well-being is a people
topic in its own right; ISO lists it among the topics of new metrics in the 2025 edition of its human capital reporting
standard.[^iso-30414]

### Assurance of the operating model

Monitor PeopleOps like a production system; the [governance cadences](#operating-model-and-governance) list the routine checks.
The alarms: a terminated-but-active account past the SLA (daily HRIS–identity reconciliation); HRIS–payroll mismatches in status,
pay or cost centre before each pay cut-off; lifecycle checklists past due (weekly); and a selection or scoring tool that fails its
by-group audit (before use and at least yearly, required for some tools: see the
[regulatory map](#regulatory-map-as-of-16-october-2026)), which is suspended pending review.

**Key risk indicators:** late terminations, overdue statutory tasks, people with access to pay data, surveys launched without
thresholds, policies past review.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Fix | Prevention |
|---|---|---|---|---|
| No laptop or accounts on day one | Late contract or HR entry | Compare offer, HR-entry and device-order dates | Loaner device; ticketed manual account | Pre-hire record at offer acceptance |
| Leaver still active in an app | Late entry; non-SSO app; failed event | Reconciliation; app user list; integration logs | Disable now; review sign-ins | Future-dated entries; app owners; failed-event alerts |
| Payroll pays a leaver | Termination missed the payroll cut-off | Payroll vs HRIS status | Recovery per local law | Reconcile before every cut-off |
| Approvals go to the wrong manager | Stale manager attribute after a reorganisation | HRIS hierarchy vs org chart | Bulk effective-dated fix | Hierarchy step in the reorganisation checklist |
| Finance and HR headcounts differ | Different definitions or extraction dates | Compare both | One definition; reconciliation report | Data dictionary; monthly sign-off |
| Survey results identify people | Thresholds too low; combined filters | Smallest reported group | Withdraw; raise thresholds | Thresholds set before launch |
| Duplicate accounts after a rehire | New worker ID; old identity not linked | Restricted identity search | Merge per policy | Rehire rule: reuse or link the ID |

### Worked incident: a leaver who kept access

::: example Illustrative incident (fictional company, realistic pattern)
A sales manager is dismissed on Monday at 10:00. Because the People Partner waited for signed paperwork, the termination is entered
on Wednesday afternoon, effective Monday. That evening the reconciliation report flags the person as terminated in HR but active in
the identity provider and in the CRM, which uses a local login.
:::

::: figure Runbook for a terminated-but-active account
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 30}}}%%
flowchart TD
  A["Reconciliation alert: terminated in HR, still active"] --> B["Disable identity and non-SSO accounts; revoke sessions and tokens"]
  B --> D{{"Any sign-in or data access after the termination time?"}}
  D -->|"no"| E["Record exposure window; close as near-miss"]
  D -->|"yes"| F["Open security incident; preserve logs"]
  F --> G["Assess data accessed; notify per policy and law"]
  E --> H["Root cause: why was the HR entry late?"]
  G --> H
  H --> I["Fix the process; track terminations entered on time"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,F,G risk
  class D decision
  class B,E,H,I core
```
Text equivalent: On a reconciliation alert, disable identity and non-SSO accounts and revoke sessions and tokens. With no access
after the termination time, record the exposure window as a near-miss; otherwise open a security incident, preserve logs, assess
the data accessed and notify as required. Either way, find why the HR entry was late, fix the process and track terminations
entered on time.
:::

**Runbook steps, owners and timings.**

1. **Contain (Identity, 15 minutes):** disable the account; revoke sessions, refresh tokens and API keys; remove from groups.
2. **Contain non-SSO (system owners, 1 hour):** disable local accounts listed in the application inventory (here, the CRM).
3. **Assess (Security with PeopleOps):** pull sign-in and audit logs from termination to containment; here, one CRM sign-in on
   Tuesday and a customer-list export.
4. **Respond (Security, Legal, Privacy):** open an incident, preserve evidence, decide whether the export is a notifiable personal
   data breach under applicable law, and contact the former employee through Legal.
5. **Fix (PeopleOps, Identity):** pre-enter terminations with restricted visibility (Artefact 5), bring the CRM under SSO or name
   its owner in the checklist, and alert on past-dated terminations; report terminations entered on time monthly (target ≥ 98%).

**Lesson.** An HR process step caused the security failure, which is why PeopleOps owns the trigger even though identity owns the
action.

### Anti-patterns and myths

1. **The rebrand:** HR renamed People Ops with the same spreadsheets. *Instead:* deliver three of the observable changes in
   [the naming story](#is-peopleops-just-hr-the-naming-story).
2. **The HRIS as a filing cabinet,** updated after the spreadsheets. *Instead:* make the HRIS where changes happen.
3. **Email-driven lifecycle** ("please set up X for Y on Monday"). *Instead:* events.
4. **Copying Google** without context or follow-through. *Instead:* adopt the reasoning and test the practice.
5. **Surveillance analytics:** keystroke or activity scores called insight. *Instead:* group-level, purpose-limited analysis.
6. **Survey without action,** **one rating for everything,** **tool before process.** *Instead:* see the listening and performance
   playbooks and the attribute-ownership matrix.
7. **Myth: "AI will make hiring objective."** Tools can encode historic bias, which is why the EU classes such uses as high-risk
   and several jurisdictions regulate them ([regulatory map](#regulatory-map-as-of-16-october-2026)).[^ai-act]

## Deciding and adopting

### When to use and when not to use

**Use a deliberate PeopleOps model when** several of these hold: you hire or lose people every month; you employ in more than one
country or state; several systems need people data; you have had day-one misses, orphan accounts or payroll errors; leaders distrust
the headcount; you face pay-reporting, AI or privacy obligations; or an acquisition, audit or funding round will examine people data.

**Do not build a separate team (yet) when** you are small, in one country, hire rarely and have one payroll: one accountable owner, a
reputable payroll provider or PEO, two checklists and one well-kept record are enough. **Do not rename HR** only to sound modern.

**Alternatives:** a PEO, an employer of record (where you have no entity), outsourced payroll with in-house HR, or a fractional HR
leader; each trades control and data access for speed and lower fixed cost. **Hidden responsibilities:** data quality,
integrations, reconciliations, rights requests, country calendars and policy upkeep; if nobody has time for them, the model
decays.

### Decision framework

::: figure Decision tree for choosing a people-operations model, including not building a team
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 110, "nodeSpacing": 14, "rankSpacing": 26}}}%%
flowchart TD
  S["Start: size, locations, pace of change"] --> Q1{{"Staff where you have no entity?"}}
  Q1 -->|"yes"| EOR["Employer of record there; keep your own HR record"]
  Q1 -->|"no"| Q2{{"Under about 50 people, own-entity staff in one country?"}}
  EOR --> Q2
  Q2 -->|"no"| Q3{{"More than five people-data systems, or JML failures?"}}
  Q2 -->|"yes"| SMALL["No team yet: one owner, a provider, checklists"]
  Q3 -->|"no"| GEN["People generalist with ops skills, plus an HRIS"]
  Q3 -->|"yes"| Q4{{"Integration skills in-house?"}}
  Q4 -->|"yes"| BEST["Team: suite plus specialised tools"]
  Q4 -->|"no"| SUITE["Team: one suite with native connectors"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class EOR,SMALL,GEN,BEST,SUITE core
  class S neutral
```
Text equivalent: Staff in a country without an entity: use an employer of record there and keep your own HR record (EOR staff do
not count as a second country next). Under about 50 people with own-entity staff in one country: no team yet, just one owner, a
provider and checklists. Otherwise, with five or fewer people-data systems and no lifecycle failures, hire a generalist with an
HRIS; if not, build a team on a suite plus specialised tools (integration skills in-house) or one suite with native connectors.
:::

The thresholds (about 50 people, five systems) are **editorial heuristics**; legal context, growth and risk appetite matter more.
Re-run the tree every six months or after a major change.

**Weighted matrix: choosing a system-of-record approach**

**Assumptions.** A fictional 400-person company in three countries with two engineers who can maintain integrations and customers
who audit access controls. Scores run 1 (poor) to 5 (strong), set after demonstrations; weights sum to 100.

| Criterion | Weight | HCM suite | Suite + specialised tools | Open-source HRMS (self-hosted) | PEO/EOR bundle |
|---|---|---|---|---|---|
| Effective-dated data and audit trail | 20 | 5 | 5 | 3 | 3 |
| Integration with identity and payroll | 20 | 4 | 4 | 3 | 2 |
| Multi-country fit | 15 | 4 | 4 | 2 | 4 |
| Employee and manager experience | 15 | 3 | 5 | 3 | 3 |
| Security and access control | 15 | 5 | 4 | 3 | 3 |
| Total cost over five years | 10 | 2 | 2 | 4 | 3 |
| Exit and data portability | 5 | 3 | 3 | 5 | 2 |
| **Weighted score (out of 500)** | 100 | **395** | **410** | **305** | **290** |

Suite: 20×5 + 20×4 + 15×4 + 15×3 + 15×5 + 10×2 + 5×3 = 395. Suite plus specialised tools differs only in experience (+30) and
security (−15), giving 410.

::: note Read the matrix, not just the total
A 15-point lead is inside the uncertainty of demo-based scores. Decide on the criteria that differ (experience versus a simpler
security model) and vary one weight at a time to test whether the ranking holds.
:::

### Maturity model

This is **this Atlas's maturity model**, not an official standard: locate yourself and pick the next step.

| Level | Observable behaviours | Evidence | Exit criteria (to move up) | Typical constraints |
|---|---|---|---|---|
| 1. Reactive | HR data in spreadsheets and inboxes; lifecycle tasks by email; numbers disagree | Ad hoc lists | One system of record holds every worker with effective dates | No owner; founder bandwidth |
| 2. Defined | HRIS is the record; documented SOPs and checklists; named owners | SOPs, data dictionary | Joiners and leavers flow to identity and payroll without re-keying | Integration skills; data quality |
| 3. Integrated | Event-driven JML; daily reconciliation; service catalogue with SLAs | Reconciliation reports, SLA dashboards | ≥ 95% day-one readiness and ≥ 99% on-time revocation for two quarters | Legacy systems; non-SSO apps |
| 4. Measured | Defined metrics; minimum group sizes; pay and selection screens each cycle | Metric definitions, screen results | Leadership decisions cite people metrics and their limits; screens lead to documented actions | Analyst capacity; trust in data |
| 5. Adaptive | Programmes tested and changed on evidence; regulation tracked proactively | Experiment notes, audit reports | Sustain: improvement is routine | Change fatigue; complacency |

Most organisations do not need Level 5 everywhere: a 150-person company at Level 3 for lifecycle and Level 2 for analytics may be
exactly right.

### Adoption roadmap: 30/60/90 days

Assumes a 150–500-person organisation with an under-used HRIS and a new PeopleOps lead; larger or regulated organisations need
longer. The sequence matters more than the dates.

| Phase | Actions | Metrics | Milestone |
|---|---|---|---|
| Days 1–30: see the system | Map real joiner, mover and leaver flows; list systems holding people data; write the attribute-ownership matrix; first reconciliation; legal calendar per country | Baselines: readiness, on-time terminations, terminated-but-active count, data accuracy | Current-state map and baseline scorecard agreed |
| Days 31–60: fix the dangerous transitions | Future-dated terminations with restricted visibility; termination events to identity; daily reconciliation alert; onboarding template with owners; catalogue for the ten commonest requests | Terminated-but-active older than 24 hours = 0; readiness rising | Joiner and leaver flows automated or checklisted end to end |
| Days 61–90: measurable and fair | Publish metric definitions; first monthly people review; survey threshold policy; range check in the change form; first pay screens; HRIS role review | SLA attainment; out-of-range count; HRIS roles reduced | Monthly review running; screen actions documented |

**Quick wins:** a shared joiner and leaver calendar for IT; no termination effective in the past; one intake form for employment
changes; no pay data in email. **Dependencies:** identity capacity for connectors, payroll cut-offs, legal review, leadership
agreement on metric definitions.

## Toolkit

### Checklists

**Quick start (first week)**

- [ ] Name one accountable owner for the employee lifecycle
- [ ] List every system that stores people data, with an owner, and decide the system of record per core attribute
- [ ] Write the joiner checklist (with statutory steps per country) and the leaver checklist (with non-SSO systems)
- [ ] Share a weekly list of upcoming joiners and leavers with IT and payroll

**Preflight before an HRIS go-live**

- [ ] Effective-dated history migrated; headcount, pay totals and manager hierarchy reconciled record by record
- [ ] Security roles tested with real scenarios (manager, payroll, analyst, employee)
- [ ] Integrations tested for hire, move, termination, rehire and cancelled hire
- [ ] Parallel payroll run planned or waived with a reason; rollback plan ready; data export (exit) tested
- [ ] After an acquisition: non-urgent changes frozen in the old system; jobs mapped by work, not titles, with every grade change
  explained in writing; identity provisioning switched only once reconciliation is clean

**Survey launch and AI tool procurement**

- [ ] Survey: purpose and lawful basis written down (not "consent" by default); group, suppression and comment thresholds set
  before launch; "confidential", not "anonymous", unless that is true
- [ ] AI tool: use classified (screens, ranks, schedules, evaluates or monitors workers?); jurisdictions mapped against the
  [regulatory map](#regulatory-map-as-of-16-october-2026); lawful basis recorded; vendor bias audit reviewed; own screen planned;
  human decision-maker and appeal route defined; privacy assessment done

For a reduction in force, use the eight [RIF steps](#playbook-reductions-in-force-and-collective-redundancy) as the checklist; the
quarterly audit items are in the [governance cadences](#operating-model-and-governance).

### Templates

**One-page PeopleOps charter**

```text
PEOPLEOPS CHARTER                                     Version: 1.0   Owner: <name>   Review: <date>
Mission:      <one sentence: what the employee lifecycle should feel like and guarantee>
Scope:        Lifecycle transactions, HR system of record, HR service delivery, people data and metrics,
              performance and pay processes, policy, HR compliance and HR data privacy
Out of scope: Accounts and access (Identity), company planning (BizOps), course delivery (EduOps), legal advice (Legal)
Principles:   1 One record, many consumers  2 Effective-dated truth  3 Transitions are controls
              4 Services have SLAs  5 Measure systems, protect individuals  6 Minimum necessary data
Service levels: Day-one readiness >= <x>%   Access disabled within <t> of termination >= <y>%
                HR cases answered within <d> working days >= <z>%
Metrics reviewed monthly: <list>
Decision rights: <who approves policy, pay exceptions, HRIS changes, survey thresholds>
Signed: <Head of People>  <CIO or Identity owner>  <Finance or Payroll owner>
```

**Architecture decision record (filled example)**

```text
ADR-007: The HRIS is the system of record for the manager attribute
Status: Accepted (2026-10-16)
Context: Managers were maintained in the HRIS, the identity provider and the expense tool. Approvals went to former managers
         after reorganisations, and identity groups based on manager were wrong.
Decision: The HRIS owns the manager attribute. The identity provider and all tools read it through the provisioning
          connector. Local edits in other tools are disabled.
Consequences: Reorganisations must be entered in the HRIS with effective dates before they take effect. The PeopleOps
              team adds manager changes to the reorganisation checklist. A daily report flags manager mismatches.
Alternatives considered: Identity provider as owner (rejected: HR approvals live in the HRIS);
                         per-tool ownership (rejected: the cause of the problem).
```

**Retention schedule (structure only).** Counsel and PrivacyOps fill each period, with its legal source, per country; this page
gives no periods because none was researched at source. Header fields: owner (PeopleOps lead), approvers (Privacy, Legal),
countries covered, review date.

| Record class (system) | Clock starts at | Period and source, per country |
|---|---|---|
| Candidate, not hired (ATS) | Hiring decision | *to be filled* |
| Core worker record (HRIS) | Termination date | *to be filled* |
| Payroll and tax records (payroll provider) | End of tax year | *to be filled* |
| Right-to-work evidence (HRIS, restricted) | Hire or exit date, per the rule | *to be filled* |
| Health and adjustment data (restricted store) | Case closed | *to be filled* |
| Investigation files (employee-relations case tool) | Case closed | *to be filled* |
| Survey raw responses (survey tool) | Survey closed | *policy period* |
| RIF selection evidence (restricted store) | Last exit date | *to be filled* |

Rules: disposal means deletion or anonymisation, and every run is logged as evidence; a legal hold suspends disposal; a record class
without a source is not approved.

**Monthly people scorecard (one page)**

| Area: metric | Target (example) | Owner |
|---|---|---|
| Service: day-one readiness | ≥ 95% | PeopleOps lead |
| Service: revocation within SLA (all leavers) | ≥ 99% | Identity with PeopleOps |
| Service: HR cases within SLA | ≥ 90% | PeopleOps desk |
| Outcome: regretted attrition, rolling twelve months | Own baseline | People Partners |
| Outcome: twelve-month retention of last year's hires (cohort) | Own baseline | PeopleOps lead |
| Fairness: out-of-range pay; unexplained flagged gaps open | 0 | Total rewards |
| Data: sampled field accuracy | ≥ 98% | HRIS analyst |

Each month adds two columns, the value and its twelve-month trend; definitions are in [Metrics and KPIs](#metrics-and-kpis). Every
number states its period, denominator and worker types; groups below the reporting threshold are not shown.

**People-data request form**

```text
Requester: <name, role>         Date: <date>
Question to answer:             <decision this will inform>
Data needed (fields):           <minimum fields>
Population and period:          <who, when>
Identifiable data needed?       <no / yes, with justification>
Lawful basis:                   <basis per purpose; Art. 9 condition if special-category data>
Output audience:                <who will see results>
Minimum group size applied:     <n>
Retention of extract:           <delete by date>
Approved by (People analytics lead / Privacy):  <names, date>
```

### Deep comparisons: PeopleOps and the other business-function Ops

Hand-off boundaries are in [How PeopleOps relates to other Ops](#how-peopleops-relates-to-other-ops). The business-function pages
share habits (one source of truth, defined hand-offs, service levels) but serve different customers, so success is measured
differently.

| Page | Whom it serves | Core workflow | Measures of success |
|---|---|---|---|
| PeopleOps (this page) | Employees, candidates, managers | Hire, move and exit; the HR record; pay governance | Day-one readiness, on-time revocation, regretted attrition, pay equity |
| [BizOps](../bizops/) | The leadership team | Planning cadence, KPI tree, headcount plan | Goals met with the planned resources |
| [RevOps](../revops/) with [SalesOps](../salesops/) and [MarketingOps](../marketingops/) | Go-to-market teams | Shared funnel definitions, pipeline, forecast | Forecast accuracy; fewer leaks at hand-offs |
| [SupportOps](../supportops/), [CustomerOps](../customerops/), [CXOps](../cxops/) | Customers with a problem; existing customers; the whole journey | Tickets and SLAs; renewals; feedback from signal to fix | Resolution times; retention; measured effect of fixes |

The useful contrast is the customer: workers cannot switch HR provider, so their experience must be measured deliberately; the
alternative signal, people leaving, arrives late and costs the most.

### FAQ

::: answer Our layoff selections pass the four-fifths screen. Are we safe?
No. Passing proves little: small numbers make ratios unstable, the threshold's legal status is contested, other laws still apply,
and consultation and notice duties are separate. Document job-related criteria and involve counsel.
:::

::: answer Are "anonymous" surveys really anonymous?
Most workplace surveys are confidential (the organisation could link answers to people but promises not to report small groups)
rather than anonymous. Say so precisely and enforce minimum group sizes and suppression.
:::

::: answer Can we use people analytics to predict who will resign?
You can; whether you should is another matter. Individual predictions create privacy, fairness and self-fulfilling-label risks,
and the EU classifies AI for worker management as high-risk. Group-level analysis of why people leave is usually more useful.
:::

::: answer What is the difference between a pay gap and unequal pay?
A pay gap compares average or median pay of groups across the organisation; unequal pay means people doing equal work, or work of
equal value, are paid differently without a legitimate reason. A large gap can coexist with equal pay (because of who is in which
job), and a small gap with unequal pay in some roles.
:::

::: answer Does a PEO or EOR remove our compliance responsibility?
No. It shifts tasks and some legal roles depending on the contract and country, but you still decide who is hired, how they are
managed and how their data is used.
:::

::: answer Should the HRIS belong to HR or to IT?
Split it by what each owns: PeopleOps owns the processes, the data, the attribute-ownership rules and change control over HR
configuration such as security roles; IT and identity own integrations, single sign-on and the accounts the HRIS drives. Record
the split in an ADR (template above).
:::

::: answer What should a new PeopleOps lead measure first?
The leading measures of the dangerous transitions: terminations entered before the effective time, revocation within SLA over all
leavers, day-one readiness, plus a sampled data-accuracy check. Baseline them in the first 30 days
([roadmap](#adoption-roadmap-306090-days)) before buying anything.
:::

## Going further

### Advanced topics and emerging direction

**Established:** event-driven HR-to-identity integration[^entra-hr][^scim]; survey confidentiality through minimum groups and
suppression[^glint]; fairness screens whose arithmetic is stable even where their legal status changes. **Changing:** the rules in
the [regulatory map](#regulatory-map-as-of-16-october-2026) and ISO 30414's 2025 edition with auditable
requirements.[^iso-30414] **Emerging, evidence still forming:** skills-based organisation (pilot in one job family, because skill
taxonomies decay); lifecycle-triggered listening (timelier, but tiring and riskier for anonymity); LLM assistants that answer
policy questions with citations; causal methods in people analytics. **Treat with caution:** vendor claims to predict performance
from personality, video or language, and engagement scores with undisclosed questions.

### Learning path

**Prerequisites:** none; spreadsheets, basic statistics and awareness of local employment and data-protection law help.

- **1 day:** "What PeopleOps is" and "Vocabulary, origins and neighbours"; draw your joiner and leaver flows; list the systems holding people data.
- **1 week:** Labs 1–3, an attribute-ownership matrix and a leaver SOP. **30 days:** baselines for readiness, revocation and data
  accuracy; fix one transition; Lab 4.
- **Specialise and build a portfolio:** HRIS engineering (a tested reconciliation script), people analytics (a cohort retention
  analysis), total rewards (a pay-structure model) or HR service delivery (a service catalogue).

**Paths by persona.** *Beginner:* the first three parts (to "Principles and operating model"), the onboarding playbook, Labs 1 and 3. *Practitioner or engineer:* architecture and
workflow, the reference implementation, Labs 2 and 4, failures. *Leader:* the problem, operating model, metrics, privacy, the
decision framework, maturity and the judgement call. For a career framework, see the CIPD Profession Map.[^cipd-map]

## Wrap-up

### Executive recap and cheat sheet

**Decide:** the system of record per attribute; the lifecycle owner; service levels; the lawful basis for each use of people data;
minimum group sizes; how pay ranges are set and checked; which AI uses are allowed where.

**Practise:** future-dated entries; events, not emails; daily reconciliation; the Four C's; development separate from pay; fairness
screens each cycle; a service catalogue with a confidential path.

**Measure:** day-one readiness; on-time revocation and termination entry; regretted attrition and cohort retention; case SLAs; data
accuracy; out-of-range pay and pay gaps; eNPS with response rate.

**Watch out for:** the cosmetic rebrand; surveillance analytics; "consent" as the default basis at work; metrics as targets; AI
without audit; layoffs without a statutory calendar; benchmarks without definitions.

### A judgement call: should manager bonuses depend on team engagement scores?

**The situation.** A 600-person company proposes that 20% of each manager's bonus depends on their team's eNPS improvement (option
A). Option B: use survey results for diagnosis, and judge managers on documented behaviours (regular one-to-ones, acting on survey
results, developing people) plus outcomes such as regretted attrition, reviewed with context.

**Assumptions.** Teams average eight people; the survey is confidential with a minimum group of five; managers see their team's
aggregates; the policy would run for at least two years.

**Why the attractive option A is likely wrong here.**

1. **Noise.** With eight respondents, one person moving from promoter to passive shifts the score by 12.5 points; year-on-year
   changes will be dominated by noise and turnover, not management quality.
2. **Goodhart's law.** Once the measure is a target, managers can raise it without improving anything (pressuring participation,
   hinting at the "right" answers), and the survey stops telling the truth.
3. **Confidentiality pressure.** Managers with money at stake will push for finer cuts of data, and respondents will sense it.
4. **Fairness.** The CIPD review stresses perceived fairness in appraisal;[^cipd-pm] pay on a noisy number managers only partly
   control is unlikely to feel fair to them either.

**What option A gets right** is accountability, so option B needs teeth: survey follow-through in managers' development plans,
leaders reviewing action completion, and a behaviour-based performance process for persistent problems.

**Decision under these assumptions:** option B. Revisit only for large teams (say 50+ respondents) with strong survey-integrity
controls, and even then reward action completion, not the score. This is a reasoned recommendation, not a proven result; a pilot
of option A should watch response rates, score distributions and comments for gaming.

### Learning objectives and mastery check

You should now be able to **explain** the three usages of "PeopleOps"; **design** joiner, mover and leaver flows with owners and
effective dates; **specify** attribute ownership that prevents orphan accounts; **calculate and interpret** separation rates, eNPS,
compa-ratio, pay gaps and cohort retention; **protect** individuals with minimum group sizes and a recorded lawful basis; **plan** a
reduction in force against its statutory calendar; and **evaluate** which operating model fits.

::: answer 1. A dashboard shows 99% "access revoked within SLA", yet several terminated-but-active accounts exist. What went wrong?
The denominator probably counted only leavers with a disablement timestamp. Use all leavers; orphans count as failures (Lab 2).
:::

::: answer 2. A quarter has an average headcount of 200, 9 separations, 6 voluntary, 2 regretted. Compute the three rates.
Separation 9 ÷ 200 = 4.5%; voluntary 3.0%; regretted 1.0%, all for the quarter. State period and denominator; prefer a rolling
twelve-month view to multiplying by four.
:::

::: answer 3. A four-person team has an eNPS of −50 and its manager wants to see it. What do you do?
Do not show it: the group is below a typical minimum of five. Check that visible teams do not allow subtraction, and offer the next
level of aggregation.
:::

::: answer 4. Group A has 30 of 120 applicants selected and group B 12 of 80. Does the four-fifths screen flag it?
Yes: 15% ÷ 25% = 0.60, below 0.80. Check sample sizes, find the step where the difference arises, and involve counsel: the screen
starts an investigation, not a conclusion.
:::

::: answer 5. Of 40 hires, 4 left in the first six months and 10 have not yet been employed for six months. Is first-year attrition 10%?
No. 4 ÷ 40 counts people who have not had a full year in which to leave. Track the cohort to twelve months, or estimate retention
with a survival curve that treats the ten as censored.
:::

::: answer 6. A 30-person, single-country start-up asks you to design its PeopleOps department. What do you recommend?
Not a department: one accountable owner, a reputable payroll provider or PEO, joiner and leaver checklists, one well-kept record and
a statutory calendar. Revisit at around 50 people, faster hiring or a new country.
:::

::: answer 7. Leadership wants an AI tool that ranks applicants in Germany and New York City. Name three things to do before go-live.
(1) Treat it as a high-risk EU AI Act use (obligations from 2 December 2027, as of the Commission's August 2026 update). (2) For New
York City: a bias audit within one year before use, its published summary and candidate notices; the audit has no pass mark, so
decide in advance what a poor impact ratio triggers. (3) Run your own adverse-impact screen, name the human decision-maker and
appeal route, record a lawful basis, complete a privacy assessment and consult the works council where national law requires it.
:::

::: answer 8. A manager in Germany wants staff to "consent" to a new productivity-monitoring tool. Is consent the right basis?
Almost never: the EDPB considers consent at work unlikely to be freely given. First decide whether the monitoring is necessary and
proportionate at all; if it is, document another lawful basis with a balancing test, assess privacy impact and check works-council
rights before launch.
:::

::: answer 9. You propose 120 redundancies at one site in Great Britain, with exits on 1 March 2027. When must consultation start?
At least 45 days before the first dismissal (100 or more redundancies): no later than 15 January 2027, with form HR1 sent before
consultation starts. Notices are issued once consultation is complete, so if notice periods must also run before 1 March, start
earlier still.
:::

### Conclusion

PeopleOps is an honest name only when it describes a real change: the employee lifecycle run as an operation that can be designed,
measured and improved, while its "units" remain people with rights. Three ideas carry most of the value: **one effective-dated
record** that every other system trusts; **transitions treated as controls**, so joining, moving and leaving happen correctly and
on time; and **measurement that protects individuals**, so data informs decisions without becoming surveillance.

Everything else is scaffolding, and much of it should wait until the basics work. A small company with a careful owner and two
good checklists is doing PeopleOps; a large company with an expensive suite and emailed spreadsheets is not. One test: when someone
leaves on Friday at five, does every system know by five past, and can you prove it?

## Sources and further reading

All sources were opened on 2026-10-16. Legal sources are for orientation; check the official text (for EU law, EUR-Lex) before
relying on them.

[^cipd-map]: [Explore the Profession Map](https://www.cipd.org/uk/the-people-profession/the-profession-map/explore-the-profession-map/) — CIPD, 2023. Checked 2026-10-16.
[^iso-tc260]: [ISO/TC 260 Human resource management: projects](https://committee.iso.org/sites/tc260/home/projects.html) — ISO/TC 260 (titles only; texts not read). Checked 2026-10-16.
[^iso-30414]: [ISO 30414:2025 – Strengthening human capital reporting and disclosure](https://committee.iso.org/sites/tc260/home/news/content-left-area/news-and-updates/iso-30414-2025-strengthening-hum.html) — ISO/TC 260, 2025-08-24. Checked 2026-10-16.
[^bock-wiki]: [Laszlo Bock](https://en.wikipedia.org/wiki/Laszlo_Bock) — Wikipedia (tertiary source). Checked 2026-10-16.
[^bock-hachette]: [Work Rules! by Laszlo Bock](https://www.hachette.co.uk/titles/laszlo-bock/work-rules/9781473610576/) — Hachette UK, 2015. Checked 2026-10-16.
[^d3]: [People analytics at Google: using data to make Google a great place to work](https://d3.harvard.edu/platform-digit/submission/people-analytics-at-google-using-data-to-make-google-a-great-place-to-work/) — pseudonymous MBA student post, HBS Digital Initiative forum (weak), 2017-04-02. Checked 2026-10-16.
[^rework-pa]: [People analytics: from inquiry to action](https://rework.withgoogle.com/intl/en/guides/people-analytics-from-inquiry-to-action) — Google re:Work, updated March 2026. Checked 2026-10-16.
[^rework-onb]: [A data-driven approach to optimizing employee onboarding](https://rework.withgoogle.com/intl/en/guides/a-data-driven-approach-to-optimizing-employee-onboarding) — Google re:Work, August 2025. Checked 2026-10-16.
[^rework-oxygen]: [Following the data: the research behind great managers](https://rework.withgoogle.com/intl/en/guides/following-the-data-the-research-behind-great-managers) — Google re:Work, August 2025. Checked 2026-10-16.
[^rework-okr]: [Set goals with OKRs](https://rework.withgoogle.com/en/guides/set-goals-with-okrs) — Google re:Work, first published 2016. Checked 2026-10-16.
[^bauer]: [Onboarding New Employees: Maximizing Success (T. N. Bauer)](https://studentaffairs.uga.edu/wp-content/uploads/2021/08/Onboarding-New-Employees.pdf) — SHRM Foundation, 2010 (copy hosted by the University of Georgia). Checked 2026-10-16.
[^gitlab-onb]: [GitLab Onboarding](https://handbook.gitlab.com/handbook/people-group/general-onboarding/) — GitLab Handbook, 2026-09-13. Checked 2026-10-16.
[^gitlab-offb]: [GitLab Offboarding Standards](https://handbook.gitlab.com/handbook/people-group/offboarding/offboarding_standards/) — GitLab Handbook, 2026-10-05. Checked 2026-10-16.
[^nist-80053]: [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) — NIST, release 5.2.0, 2025. Checked 2026-10-16.
[^fips200]: [FIPS 200: Minimum Security Requirements for Federal Information and Information Systems](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf) — NIST, March 2006. Checked 2026-10-16.
[^nist-oscal]: [SP 800-53 Rev. 5.2.0 control catalog in OSCAL (PS-3, PS-4, PS-5)](https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json) — NIST OSCAL content, 2026-05-11. Checked 2026-10-16.
[^scim]: [RFC 7643: System for Cross-domain Identity Management: Core Schema](https://www.rfc-editor.org/rfc/rfc7643.html) — IETF, September 2015. Checked 2026-10-16.
[^scim-protocol]: [RFC 7644: System for Cross-domain Identity Management: Protocol](https://www.rfc-editor.org/rfc/rfc7644.html) — IETF, September 2015. Checked 2026-10-16.
[^entra-hr]: [What is HR-driven provisioning with Microsoft Entra ID?](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/what-is-hr-driven-provisioning) — Microsoft Learn, updated 2026-02-05. Checked 2026-10-16.
[^gdpr88]: [Art. 88 GDPR: Processing in the context of employment](https://gdpr-info.eu/art-88-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-16.
[^gdpr12]: [Art. 12 GDPR: Transparent information, communication and modalities](https://gdpr-info.eu/art-12-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-16.
[^gdpr6]: [Art. 6 GDPR: Lawfulness of processing](https://gdpr-info.eu/art-6-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-16.
[^gdpr9]: [Art. 9 GDPR: Processing of special categories of personal data](https://gdpr-info.eu/art-9-gdpr/) — gdpr-info.eu (unofficial text). Checked 2026-10-16.
[^edpb-consent]: [Guidelines 05/2020 on consent under Regulation 2016/679, version 1.1](https://www.edpb.europa.eu/system/files/documents/files/file1/edpb_guidelines_202005_consent_en.pdf) — EDPB, 2020-05-04 (paras 21–22, 30). Checked 2026-10-16.
[^ico-monitor]: [Employment practices and data protection: monitoring workers](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/) — UK ICO (under review). Checked 2026-10-16.
[^ccpa]: [California Consumer Privacy Act (CCPA)](https://oag.ca.gov/privacy/ccpa) — California DOJ, 2026-08-28 (FAQ A.11). Checked 2026-10-16.
[^dpdp]: [DPDP Rules, 2025 Notified](https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf) — Press Information Bureau, India, 2025-11-17. Checked 2026-10-16.
[^ai-act]: [AI Act: regulatory framework for AI](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — European Commission, updated 2026-08-03. Checked 2026-10-16.
[^nyc-aedt]: [Automated Employment Decision Tools (AEDT)](https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page) — NYC DCWP. Checked 2026-10-16.
[^nyc-faq]: [Automated Employment Decision Tools: Frequently Asked Questions](https://www.nyc.gov/assets/dca/downloads/pdf/about/DCWP-AEDT-FAQ.pdf) — NYC DCWP, 2023-06-29. Checked 2026-10-16.
[^ca-ads]: [Civil Rights Council secures approval for regulations to protect against employment discrimination related to artificial intelligence](https://calcivilrights.ca.gov/2025/06/30/civil-rights-council-secures-approval-for-regulations-to-protect-against-employment-discrimination-related-to-artificial-intelligence/) — California Civil Rights Department, 2025-06-30. Checked 2026-10-16.
[^co-adm]: [SB26-189 Automated Decision-Making Technology](https://leg.colorado.gov/bills/sb26-189) — Colorado General Assembly, signed 2026-05-14. Checked 2026-10-16.
[^il-ai]: [Illinois Department of Human Rights issues proposed rules on AI notice requirements in employment decisions](https://ktslaw.com/insights/alert/2026/6/illinois-department-of-human-rights-issues-proposed-rules-on-ai-notice-requirements-in-employment-decisions) — Kilpatrick Townsend (law-firm alert, secondary), 2026-06-01, updated 2026-06-10. Checked 2026-10-16.
[^ugesp]: [29 CFR § 1607.4 Information on impact](https://www.law.cornell.edu/cfr/text/29/1607.4) — Uniform Guidelines (1978, amended 1981), Cornell LII. Checked 2026-10-16.
[^ecfr-1607]: [eCFR versions of 29 CFR part 1607](https://www.ecfr.gov/api/versioner/v1/versions/title-29.json?part=1607) — eCFR API: last amended 2017-01-03, current to 2026-10-14. Checked 2026-10-16.
[^olc-2026]: [Constitutionality of Disparate-Impact Liability Under Title VII](https://www.justice.gov/olc/media/1444871/dl) — US DOJ Office of Legal Counsel, 2026-06-09. Checked 2026-10-16.
[^opm-ugesp]: [Removal of References to the Uniform Guidelines on Employee Selection Procedures in Federal Personnel Regulations](https://www.govinfo.gov/content/pkg/FR-2026-07-31/pdf/2026-15586.pdf) — OPM interim final rule, 91 FR 48234, 2026-07-31. Checked 2026-10-16.
[^eeoc-agenda]: [Rescission of Uniform Guidelines on Employee Selection Procedures (RIN 3046-AB43)](https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=3046-AB43) — Unified Agenda, US EEOC. Checked 2026-10-16.
[^eu-ptd]: [Directive (EU) 2023/970 on pay transparency](https://publications.europa.eu/resource/celex/32023L0970) — Official Journal L 132, 2023-05-17 (EU Publications Office). Checked 2026-10-16.
[^uk-gpg]: [Gender pay gap reporting: overview](https://www.gov.uk/guidance/gender-pay-gap-reporting-overview) — GOV.UK, updated 2026-05-21. Checked 2026-10-16.
[^uk-gpg-calc]: [Gender pay gap reporting: making your calculations](https://www.gov.uk/government/publications/gender-pay-gap-reporting-guidance-for-employers/making-your-calculations) — GOV.UK, updated 2026-05-21. Checked 2026-10-16.
[^uk-rtw]: [Check a job applicant's right to work](https://www.gov.uk/check-job-applicant-right-to-work) — GOV.UK. Checked 2026-10-16.
[^uk-redundancy]: [Making staff redundant: redundancy consultations](https://www.gov.uk/staff-redundant/redundancy-consultations) — GOV.UK. Checked 2026-10-16.
[^uk-status]: [Employment status](https://www.gov.uk/employment-status) — GOV.UK. Checked 2026-10-16.
[^acas-code]: [Acas Code of Practice on disciplinary and grievance procedures](https://www.acas.org.uk/acas-code-of-practice-on-disciplinary-and-grievance-procedures/html) — Acas (being updated). Checked 2026-10-16.
[^eu-involvement]: [Employee involvement](https://employment-social-affairs.ec.europa.eu/policies-and-activities/rights-work/labour-law/employee-involvement_en) — European Commission. Checked 2026-10-16.
[^i9]: [M-274, 4.0 Completing Section 2: Employer Review and Verification](https://www.uscis.gov/i-9-central/form-i-9-resources/handbook-for-employers-m-274/40-completing-section-2-employer-review-and-verification) — USCIS, 2025-07-15. Checked 2026-10-16.
[^warn-employer]: [20 CFR § 639.3 Definitions](https://www.law.cornell.edu/cfr/text/20/639.3) — WARN regulations, Cornell LII. Checked 2026-10-16.
[^warn-notice]: [20 CFR § 639.2 What does WARN require?](https://www.law.cornell.edu/cfr/text/20/639.2) — WARN regulations, Cornell LII. Checked 2026-10-16.
[^irs-status]: [Independent contractor (self-employed) or employee?](https://www.irs.gov/businesses/small-businesses-self-employed/independent-contractor-self-employed-or-employee) — IRS, 2026-05-19. Checked 2026-10-16.
[^irs-peo]: [Certified professional employer organization](https://www.irs.gov/tax-professionals/certified-professional-employer-organization) — IRS, 2026-07-15. Checked 2026-10-16.
[^km]: [Survival probabilities (the Kaplan-Meier method)](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1114388/) — J. M. Bland and D. G. Altman, BMJ Statistics Notes, 1998 (BMJ 317:1572; PubMed Central copy). Checked 2026-10-16.
[^eurostat-gpg]: [Gender pay gap statistics](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Gender_pay_gap_statistics) — Eurostat Statistics Explained, data extracted February 2026. Checked 2026-10-16.
[^bls]: [State Job Openings and Labor Turnover: Technical Note](https://www.bls.gov/news.release/jltst.tn.htm) — US BLS, 2026-07-22. Checked 2026-10-16.
[^waw]: [Salary Structures Policies and Practices Study 2026: Glossary of Terms](https://worldatwork.org/media/_Users/Salary%20Structures%20Glossary%20of%20terms_2026.pdf) — WorldatWork and Deloitte, 2026. Checked 2026-10-16.
[^compa]: [Classified Service Pay Plan and Compensation Report, Fiscal Year 2025](https://www.spo.state.nm.us/wp-content/uploads/2025-Annual-Compensation-Plan.pdf) — New Mexico State Personnel Office, 2025-12-12. Checked 2026-10-16.
[^bain-nps]: [Measuring your Net Promoter Score](https://nps.bain.com/about/measuring-your-net-promoter-score/) — Bain & Company. Checked 2026-10-16.
[^peakon]: [Engagement question library and theory references](https://doc.workday.com/peakon/en-us/workday-peakon-employee-voice/surveys/survey-questions/core-question-sets/engagement/hms1660252159488.html) — Workday Peakon docs, 2026-04-03. Checked 2026-10-16.
[^glint]: [Manage Viva Glint confidentiality thresholds](https://learn.microsoft.com/en-us/viva/glint/setup/manage-confidentiality-thresholds) — Microsoft Learn, 2026-05-06. Checked 2026-10-16.
[^gallup]: [State of the Global Workplace: 2026 Report](https://www.gallup.com/workplace/697904/state-of-the-global-workplace-2026.aspx) — Gallup, April 2026. Checked 2026-10-16.
[^cipd-ss]: [Shared services](https://www.cipd.org/uk/knowledge/factsheets/shared-services-factsheet/) — CIPD factsheet, 2025-12-10. Checked 2026-10-16.
[^cipd-pm]: [Performance management: could do better?](https://www.cipd.org/en/knowledge/evidence-reviews/what-works-in-performance-management/) — CIPD evidence review summary page, 2016-12-06. Checked 2026-10-16.
[^cipd-pm-report]: [Could do better? Assessing what works in performance management](https://peopleprofession.cipd.org/globalassets/media/knowledge/knowledge-hub/reports/could-do-better_2016-assessing-what-works-in-performance-management_tcm18-16874.pdf) — CIPD research report, December 2016. Checked 2026-10-16.
[^workday-hcm]: [Human Capital Management](https://www.workday.com/en-us/products/human-capital-management.html) — Workday product page. Checked 2026-10-16.
[^orangehrm]: [orangehrm/orangehrm](https://github.com/orangehrm/orangehrm) — GitHub, GPL-3.0. Checked 2026-10-16.
[^frappehr]: [frappe/hrms](https://github.com/frappe/hrms) — GitHub, GPL-3.0. Checked 2026-10-16.

**Further reading.**

- Laszlo Bock, *Work Rules!* (2015): the People Operations origin story in Bock's words (not opened for this page).

**Changelog.** Legal rows are due for re-verification by 2027-01-16.

- 2026-10-16, first version: labs executed on synthetic data.
- 2026-10-16, revision 1 after the fact-check: regulatory map, reductions in force, lawful basis.
- 2026-10-16, revision 2 after scoring: diagrams redrawn for phones, service catalogue, retention schedule, AI Act wording,
  repetition cut.
- 2026-10-16, revision 3 after the second score: regrouped into 14 parts; people-analytics method (cohorts, Kaplan–Meier survival,
  adjusted pay gaps); retention schedule as a table; scorecard template; two FAQs; EU threshold wording; Figure 5 redrawn; OKR
  artefact and acquisition scenario folded into other sections; repetition cut.
- 2026-10-16, follow-up to the third score (orchestrator): CIPD Profession Map quoted verbatim; learning path names its parts.