{"id":12774,"date":"2026-11-14T20:55:00","date_gmt":"2026-11-14T20:55:00","guid":{"rendered":"https:\/\/www.wakilsahab.in\/news\/?p=12774"},"modified":"2026-11-15T15:55:00","modified_gmt":"2026-11-15T15:55:00","slug":"leaver-and-login-audit-checklist","status":"publish","type":"post","link":"https:\/\/www.wakilsahab.in\/news\/leaver-and-login-audit-checklist\/","title":{"rendered":"IdentityOps Audit Checklist for Law Offices and Legal Desks"},"content":{"rendered":"<p>Legal news readers know that records decide outcomes. A filing is only as strong as the paper trail behind it, and the same logic applies inside any firm, chamber or compliance department that keeps digital accounts for its staff. IdentityOps is the working name for the routine that keeps those accounts honest: who exists in your systems, how they prove it, and what happens when they leave. This is a plain checklist you can walk through in an afternoon. Treat it as general information on operations hygiene; it is not legal advice and interprets no statute.<\/p>\n<p>The core principle fits in a sentence. Every login should map to a real person or a registered machine, and every one of them should be removable on a schedule you can demonstrate. The checklist below turns that into questions you can answer yes or no.<\/p>\n<h2>Why a legal desk should care about IdentityOps<\/h2>\n<p>News coverage regularly touches questions of privacy and data handling in India, such as a <a href=\"https:\/\/www.wakilsahab.in\/news\/no-law-yet-to-protect-womans-privacy-orissa-hc\/\">report on the Orissa High Court&#8217;s remark that no law yet protects a woman&#8217;s privacy<\/a>. Whatever the legal position, an office holding client files has a practical duty of care that no judgment can substitute for. The practical part is account control. If a former intern still has a working mailbox, the problem is operational long before it becomes legal.<\/p>\n<p>The Ops Atlas, which xOps School publishes as a reference, calls this field emerging. Its entry notes that vendors draw the boundaries differently and no founding document exists, which is why a checklist beats a definition. If you want the longer treatment, the <a href=\"https:\/\/www.xopsschool.com\/identityops\/\">Atlas entry covering IdentityOps scope and caveats<\/a> is worth an evening.<\/p>\n<h2>Part one: the roster audit<\/h2>\n<p>Start with a list, because you cannot govern what you have not counted. Export every account from your directory and your main applications, then compare the two exports. Do not compare the provisioning logs, which show what the system intended; compare what the applications actually hold.<\/p>\n<ul>\n<li><strong>Every account has an owner.<\/strong> A named human, or a named person responsible for a machine account.<\/li>\n<li><strong>Every human account matches an HR record.<\/strong> Anything that matches nobody goes onto a short investigation list.<\/li>\n<li><strong>Shared logins are gone.<\/strong> Two people using one credential means an action cannot be attributed to either.<\/li>\n<li><strong>Machine accounts are registered.<\/strong> Each has a purpose, an expiry date and a review cadence written down.<\/li>\n<\/ul>\n<p>Expect the first pass to be uncomfortable. The Atlas suggests a dormant sweep using a window somewhere between ninety and one hundred eighty days, skipping people on suspension, emergency accounts and machine identities with a longer agreed cadence. Pick one number, document it, and stick to it.<\/p>\n<h2>Part two: the leaver drill<\/h2>\n<p>Departures are where offices leak. The Atlas lays out a sequence that translates well to a small practice: the termination is recorded by HR, the directory account is disabled, sessions and tokens are revoked, downstream applications are told to deactivate the user, and timestamps are written down at each step.<\/p>\n<p>Run the drill against a real recent leaver and tick each line.<\/p>\n<ol>\n<li>Was the directory account disabled within your stated window, say four hours?<\/li>\n<li>Were active sessions cut, or could the person still read mail on a phone that stayed signed in?<\/li>\n<li>Did every application confirm removal, including the minor ones that hold documents?<\/li>\n<li>Is there a time-stamped record of each step?<\/li>\n<\/ol>\n<p>One subtle point from the Atlas deserves emphasis: a disabled account is not the same as an offboarded person. Access tokens issued before the disablement can keep working for a while. The Atlas notes default lifetimes in the region of an hour or so for one major identity platform, and far longer where continuous evaluation is in play. The practical fix is to revoke sessions explicitly rather than assume the disable did it.<\/p>\n<h2>Part three: how you measure it<\/h2>\n<p>Counting only the directory flatters you. The Atlas gives a worked example with forty leavers in a period. Thirty-six were disabled inside the target window, which sounds fine at ninety percent. Three of those thirty-six still had a live account in a lower-tier application, and measured end to end the figure drops to eighty-two and a half percent. The lesson is to publish the harder number.<\/p>\n<p>A useful set of targets for a small office might read like this:<\/p>\n<ul>\n<li>Directory disable for a leaver: four hours.<\/li>\n<li>All applications cleared: twenty-four hours.<\/li>\n<li>Dormant accounts disabled after ninety days of silence.<\/li>\n<li>Machine credentials replaced at least every ninety days.<\/li>\n<\/ul>\n<p>These are the Atlas examples, not legal thresholds. Adjust them to your practice and record the reasoning.<\/p>\n<h2>Part four: sign-in strength<\/h2>\n<p>Before changing anything, pull a sample of last month&#8217;s sign-ins and see which methods people really used. Policy documents describe what is permitted; logs describe what is happening. The Atlas gives a pointed example in which coverage of strong sign-in was eighty-five percent of staff, yet the share of real logins using it sat near sixty-six percent, since the policy still tolerated weaker routes. Closing that gap matters more than enrolling the last few stragglers.<\/p>\n<p>Review how people prove who they are. Text-message codes and push approvals count as multi-factor in many policies, yet the Atlas lists &#8220;MFA at one hundred percent&#8221; built on those methods as an anti-pattern. Only hardware security keys and smart-card style certificates are phishing resistant in the strict sense. For a small chambers, begin with the people who hold the keys to everything: whoever administers the mail system and whoever approves payments.<\/p>\n<p>On passwords, the guidance the Atlas relays from NIST favours length over cleverness: fifteen characters or more when the password stands alone, no forced composition rules, no scheduled expiry, and a blocklist of known bad choices.<\/p>\n<h2>Part five: the recovery path<\/h2>\n<p>The most exploited door is often the front desk. When someone is locked out, how do you verify them? The Atlas is blunt that phone call-backs are unreliable because of SIM swapping, and that the help desk should not be the default recovery route. A sensible small-office script is to let people recover through a second enrolled method first, and for anything unusual to require their manager to confirm identity on live video or in person before a one-time code is issued. Every recovery should send a notification to the person concerned.<\/p>\n<h2>Part six: the rhythm<\/h2>\n<p>Assign each item a named person and a day of the week. Without that, the audit lives in good intentions. A partner or office manager reading a one-line monthly note, such as &#8220;two machine credentials renewed, one retired, no unexplained accounts&#8221;, is enough oversight for a small practice.<\/p>\n<p>A checklist run once is a project; run regularly it becomes a control. The Atlas proposes a cadence you can borrow wholesale:<\/p>\n<ul>\n<li><strong>Daily:<\/strong> reconcile the directory against the HR list.<\/li>\n<li><strong>Weekly:<\/strong> sample a few recoveries and read them.<\/li>\n<li><strong>Monthly:<\/strong> review which machine credentials are close to expiry.<\/li>\n<li><strong>Quarterly:<\/strong> rehearse a leaver drill and review which outside services you trust for sign-in.<\/li>\n<\/ul>\n<h2>A short note on records and disclosure<\/h2>\n<p>Courts and regulators increasingly ask what a party knew and when. Keeping the timestamps from your leaver drill and your quarterly reviews gives a neutral record of what was done. For a legal-news audience that is the useful takeaway: process evidence is cheap to keep and expensive to reconstruct. A <a href=\"https:\/\/www.wakilsahab.in\/news\/telangana-high-court-extends-order-on-data-collection-for-dharani\/\">news item on a High Court extending an order about a state data collection exercise<\/a> is a reminder that data held about people draws scrutiny, and that who may touch it is part of the story.<\/p>\n<p>Whether you consult a lawyer about your obligations is a separate question and a sensible one. This piece only covers the operational housekeeping underneath.<\/p>\n<h2>The one-page version<\/h2>\n<p>If you print only one thing, print this: count the accounts, name an owner for each, disable leavers within a stated number of hours, revoke their sessions, measure end to end, use phishing-resistant sign-in for administrators first, keep recovery strict, and repeat on a calendar. None of it needs a purchase. It needs a spreadsheet, a calendar reminder and someone who owns the result.<\/p>\n<div class=\"fb-background-color\" style=\"background-color:#ffffff\"><div class=\"fb-comments\" style=\"width:100%\" data-href=\"https:\/\/www.wakilsahab.in\/news\/leaver-and-login-audit-checklist\/\" data-numposts=\"5\" data-lazy=\"true\" data-colorscheme=\"light\" data-order-by=\"social\" data-mobile=\"true\"><\/div><\/div>","protected":false},"excerpt":{"rendered":"<p>A practical yes-or-no checklist for keeping staff accounts under control, from roster audit to leaver drill, written for chambers and legal desks.<\/p>\n","protected":false},"author":6,"featured_media":12775,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10013],"tags":[],"class_list":["post-12774","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-legal-tech"],"_links":{"self":[{"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/posts\/12774","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/comments?post=12774"}],"version-history":[{"count":1,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/posts\/12774\/revisions"}],"predecessor-version":[{"id":12871,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/posts\/12774\/revisions\/12871"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/media\/12775"}],"wp:attachment":[{"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/media?parent=12774"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/categories?post=12774"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wakilsahab.in\/news\/wp-json\/wp\/v2\/tags?post=12774"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}