Data platforms collect accounts the way warehouses collect pallets: quickly, and with little thought for what happens when something is no longer needed. Analysts come and go, ingestion jobs multiply, BI tools get their own logins, and a notebook server somewhere still holds a password from three reorganisations ago. IdentityOps is the working label for keeping those accounts honest. This FAQ answers the questions data teams ask most often, in the order they tend to come up, with no padding.

What is IdentityOps, and why does a data team care?

Put briefly, it is the upkeep of a roster: who exists across your systems, and what evidence each of them offers. People, yes, but also pipelines, connectors and scheduled queries. The Ops Atlas entry, a catalogue kept by xOps School, treats the term as new and unsettled; its page on IdentityOps and its boundaries says plainly that vendors scope it differently. What that means on a data floor: a table is protected only to the extent that its readers’ accounts are.

How is it different from permission design?

The Atlas offers an editorial split. IdentityOps asks who exists. A sibling topic asks what each identity may touch, and another asks how elevated access gets requested and reviewed. In a warehouse that means: this discipline decides that an analyst account exists and is genuinely theirs; the permission model decides which schemas that account sees. Mixing the two causes arguments about ownership, so keep them apart on the org chart even if one person covers both.

Where do most data-team accounts come from?

Three places. First, the HR system, which should drive human accounts. Second, the directory or sign-in provider, which should feed your applications. Third, whoever needed a quick service login on a Friday afternoon. The third source is the problem. If you run a review and find accounts that match no HR record and no ticket, you have located the untidy edge of your platform.

What should happen when someone leaves?

Here is the order the Atlas describes, which is worth copying into a runbook:

1. The HR termination event arrives.
2. The central directory entry is switched off.
3. Open sessions and issued tokens get cancelled.
4. Each connected application receives an inactive flag.
5. Timestamps for each step are stored.

Step three trips up data teams more than anyone. Dashboards and notebooks often hold long-lived sessions, and a disabled account can keep a connected tool open for hours. Ask your tool owners how long a session survives after the account goes dark, then write down the answer.

Is switching off an account the same as offboarding?

No. It appears on the Atlas’s list of habits to unlearn. A disabled directory entry can leave behind a database role, an API key in a repository or a saved connection inside a BI tool. Offboarding is finished only when every downstream copy is gone or inert, and the extra checking pays off, because those leftovers are what attackers look for. Measure it that way. To see why, take the Atlas’s illustration. Out of forty leavers, thirty-six were disabled inside the agreed time at the front door. Subtract the three who kept a working account in a downstream tool, and a headline of ninety percent shrinks to 82.5 once you look past the directory.

How do I deal with service accounts in pipelines?

Treat each as a small employee with a file. The Atlas sketches a lifecycle you can adopt as is: enumerate every one, attach an owner and a purpose, set an end date, lean on credentials with a short life, swap them on a rhythm, and close each out with a paper trail. Retirement goes more safely in stages: disable, wait, then delete. If something breaks during the wait, you restore access in minutes instead of rebuilding from scratch.

Teams that already run careful pipelines, like the ones in our earlier note on stopping streaming pipelines from snapping, tend to find this natural. A credential that fails silently is just another pipeline break, only with a security tint.

Can two engineers share one service login?

They can, and they should not. The Atlas names shared service accounts among the habits to retire. Once two people use one login, you lose the ability to say who ran a query, and when an incident occurs the audit trail ends in a shrug. Give each pipeline its own identity and each human their own.

What does a good second factor look like for analysts?

The Atlas separates methods that resist phishing, specifically hardware keys and smart cards, from codes sent by text and approve-on-your-phone prompts. A report claiming that everyone is covered can still be counting weaker methods. A second worked figure in the entry sets enrolment beside usage. Of 1,400 staff, 1,190 have registered a strong method, which looks like 85 percent. Yet counted by login events, only 41,000 of 62,000 used one, roughly two in three. A gap that wide means the weak route is still open, and users will keep taking it because it is easier. Close the gap by removing weak options for admins first, then for people with access to sensitive data, then for everyone.

What if someone loses their device?

Have a script before it happens. The Atlas recommends self-service recovery through a second registered method first. When a human needs to step in, the one-time access should be handed over only once the requester’s manager vouches for them over a camera in real time or in the same room. Phone call-backs are discouraged because of SIM-swap attacks. Privileged users go through supervised proofing and a second administrator. And every recovery should trigger a notification to the account holder, so a stolen reset is noticed quickly.

How often should we check things?

The Atlas proposes a cadence you can adapt:

• Daily: reconcile the directory against application exports.
• Weekly: sample a few recent recoveries and confirm they followed the script.
• Monthly: read an expiry report for machine credentials.
• Quarterly: run a departure drill and review which external sign-in providers you still trust.

Notice that reconciliation uses application exports, not provisioning logs. Logs tell you what the sync tool attempted; exports show what actually exists. It is a small difference that regularly uncovers surprises.

How do dormant accounts fit in?

Set a window, ninety to one hundred eighty days according to the Atlas, and disable anything unused beyond it. Exclude accounts on authorised HR leave, emergency break-glass logins and machine identities with a registered slower rhythm. Quarterly data jobs, for example, will look dormant to a naive sweep. Registering that cadence in advance prevents an awkward morning when the finance close fails.

Does this matter across several clouds?

More, not less. With several providers, every one brings its own account store, token lifetime and quirks. Practitioners who work through running data operations across multiple clouds already know the cost of inconsistency. One practical note from the Atlas: some cloud credential reports cover only part of the picture, such as the first two access keys and users but not roles. Know what each report omits before trusting it.

What is the quickest start for a small data team?

For a first quarter, the Atlas sketches three stages. Month one is about foundations: name owners, build an application register, hand hardware keys to administrators and draft the recovery script. By day sixty, feed one population from the HR system, connect your ten most important applications through SCIM and inventory machine identities. By ninety, add session cancellation, run your first departure drill and set alerts for resets and federation changes. It also advises against purchasing an access-governance product before your HR data is clean. Fix the data, then buy the tool if you still need it.

Which mistakes appear in real incidents?

The Atlas gathers several public cases, among them a data-warehouse customer breach where accounts lacked a second factor and credentials had gone unrotated for years, and a test tenant compromised through a password spray. Its reading is that process lapses, not broken cryptography, were the cause each time. That is good news, because process is something a data team can change by Friday.

If you take one thing away, make it this: write the owner and expiry next to every machine login, and check the application exports on a schedule. The rest follows from there.