Picture a woman who runs a twelve-person online business, call her the owner of a small studio. One Monday she learns that a former contractor, gone for eight months, could still open the company’s design storage. Nothing bad had come of it, yet the discovery rattled her, and she asked her operations lead a blunt question: how many people can get into our systems right now, and are all of them supposed to? This is a made-up scene, yet the question is real, and answering it properly is what IdentityOps is about. Below is a self-run audit that fits in one afternoon, woven together with her story.<\/p>\n
The Ops Atlas, a reference site that catalogues operations disciplines, treats IdentityOps as the routine care of the question of who exists in your systems and how they prove it. It also admits the term is young and that vendors disagree on its edges. You can read how it frames the scope in its write-up of the discipline<\/a>. For a small business, the useful part is the practical one: a handful of repeatable checks, each with an owner and a rhythm.<\/p>\n Grab a spreadsheet, a pen and an hour of uninterrupted time. The studio owner did the same and sat with her operations lead and her bookkeeper, because the bookkeeper knew which finance tools had separate logins.<\/p>\n Write down every application the business uses: email, file storage, accounting, design tools, the website admin panel, the social media scheduler, the payroll portal. Most small teams are surprised by the length. The studio had twenty-three, and four were tools somebody had signed up for during a trial and never mentioned.<\/p>\n Export the user list from each application and set it beside the current staff list. Every account should map to a living, employed human or to a documented automation. The Atlas insists on exports taken from the applications themselves instead of trusting the log of what the provisioning tool says it did, because the log shows intent and the export shows reality.<\/p>\n In the studio’s case the mismatch was uncomfortable: seven accounts belonged to people who no longer worked there, and two belonged to nobody anyone could name.<\/p>\n Take the most recent leaver and trace them through every system. The Atlas separates disabled from offboarded, a distinction the studio owner found clarifying. Switching off a main login is the first step, not the last. Applications that hold their own accounts need their own removal, and live sessions may survive for a while after the account is disabled.<\/p>\n The Atlas also offers a useful way to score this. Count leavers whose accounts were fully removed everywhere within your target time, divide by all leavers, and be sure the numerator comes from the applications and not only the central directory. It gives a worked case where a flattering ninety percent turned into eighty-two and a half once lingering application accounts were counted.<\/p>\n Find accounts that have not signed in for a long stretch. The Atlas suggests a window anywhere from ninety to one hundred eighty days, and it names exceptions you should write down in advance: people on approved leave, break-glass emergency accounts, and automations that legitimately run on a slower schedule. The owner chose ninety days and put a reminder in the calendar.<\/p>\nCheck 1: Make the list of everything that has a login<\/h2>\n
\n
Check 2: Compare accounts against real people<\/h2>\n
Check 3: Test one departure, all the way through<\/h2>\n
Check 4: Look for logins that are asleep<\/h2>\n