Every travel desk in Chennai knows the pattern: a quiet stretch, then a festival fortnight when bookings triple, temporary staff arrive, and logins get passed around like spare umbrellas. By the time the rush ends, nobody can say who still has access to the booking system, the supplier portals or the shared payments account. This list is for the person who ends up responsible for that mess, whether you are an office manager, a small-agency owner or the one colleague who “knows computers”. It condenses the practical side of IdentityOps into eight checks you can run without buying anything, using the structure suggested by the Ops Atlas.
1. Name one owner and put the date in the diary
Nothing else on this list happens without a named person. Give the role a title, a recurring hour or two each month, and permission to say “no” to a shared login. The Atlas concedes that a tiny shop can skip building a formal team for this; what it cannot skip is somebody who treats the topic as a recurring job rather than an emergency.
2. Write the register before you fix anything
Start a spreadsheet naming every service your staff log into. Add columns for the owner, the people who have access, whether a second factor is on, and the date you last checked. Then add a second tab for software-to-software connections: the key between the booking tool and the accounts package, the link to the payment gateway, the calendar feed. These are the entries that get forgotten, and the Atlas gives them their own lifecycle: owner, purpose, expiry and review date for each, with a disable-wait-delete exit.
3. Set three clocks you can actually hit
Deadlines turn good intentions into a measurable routine. The Atlas offers sample figures, and a small agency can borrow them directly: disable a leaver’s central login within four hours of the departure being recorded, remove access from every connected tool within a day, and let no robot credential grow older than ninety days. If four hours is unrealistic because the owner travels, pick something you can achieve and tighten it later. A reachable number beats an aspirational one that nobody tracks.
4. Run a dormant-login sweep every quarter
Seasonal teams leave a trail of unused accounts. Sort your user lists by last sign-in and look for anyone idle for three months or more; the Atlas mentions windows from ninety to one hundred eighty days. Switch those accounts off. Skip people on formal leave, keep any emergency account that is meant to be sealed, and leave alone any machine account whose owner deliberately chose a longer review cycle. A twenty-minute sweep often removes a surprising number of ghosts.
5. Treat the password policy as a short list
Current national guidance, which the Atlas follows, boils the topic down to a few lines. Prefer long passwords (fifteen characters or more where the password is the only factor, eight when a second factor is present). Do not impose complicated composition rules. Drop the forced changes on a timetable. Screen new passwords against a blocklist of commonly breached choices. If your handbook says “change every sixty days, include a symbol”, rewrite it; the old rule mostly produces predictable variations.
6. Upgrade the sign-in of the few who matter most
Not everyone needs a hardware key tomorrow. The Atlas’s rollout order is practical: first the people who administer the sign-in service and the cloud, next anybody who reaches email, remote desktops or the money, and last everyone else. Only methods built on FIDO2/WebAuthn or smart cards count as truly phishing-resistant, and while an SMS code or an approve-on-your-phone prompt beats nothing, neither deserves a “fully protected” label. For a small agency, a handful of security keys for the owner, the accountant and whoever holds the payments account is a sensible first purchase.
7. Write the recovery script and tape it by the phone
Festival season is when impostors phone the office claiming to be an exhausted freelancer who has lost a phone. A half-page script removes the pressure from whoever answers. According to the Atlas, ordinary recovery leans on a second authenticator the person already owns; assisted recovery needs the manager to see the requester, by video or face to face; and call-backs to a phone number are not to be trusted, since numbers can be swapped. Each recovery should also ping the contact address already on file. Make it a rule that nobody, however senior or sympathetic, is exempt from the script.
8. Rehearse a departure once a quarter
The check that proves all the others is a drill. Choose a real or pretend leaver, start a stopwatch when the departure is recorded and walk the sequence: record, disable the central account, cancel sessions, tell connected apps to switch the user off, note timestamps. Count how many applications were clean at the deadline, not just at the central service. The Atlas’s worked example shows why: forty leavers, thirty-six handled in time, three of those quietly keeping a login in a minor tool, so a ninety percent score at the front door becomes eighty-two and a half when measured end to end.
Extra: what a bad week looks like without these checks
Consider an ordinary scenario, clearly invented. A tour desk takes on four seasonal coordinators in October. Each is given the manager’s shared login “just for the week” because creating individual accounts feels slow. When two of them leave in November, nobody can tell which one made a rate change on the supplier portal, and changing the shared password disrupts the remaining staff mid-shift. Every item above would have prevented some part of that headache: the register shows the shared login as a temporary exception, the clocks force a decision at departure, the drill reveals the supplier portal is outside the central switch, and the recovery script stops the manager from reading out the new password over a crackly phone line.
A rhythm that keeps the list alive
Put the checks on a calendar. The Atlas suggests daily reconciliation of the people list against live accounts, a weekly spot-check of how lockouts were handled, a monthly list of credentials about to lapse and a quarterly drill. If you are small, compress it: a monthly hour for the register and sweeps, a quarterly drill and a reminder at every season change. It is not exciting, and that is the point.
If you only have thirty days
The Atlas’s thirty-day plan is a good shape for a small team: name the owner, list the applications and machine accounts, give hardware keys to the admins, and draft the recovery script. In the following month add automatic account creation for one group of staff and an inventory of machine credentials. In the third month add session cancellation, your first drill and alerts for password resets and trust-setting changes. And a caution worth repeating: do not purchase a heavyweight governance product before the personnel records behind it are accurate. Tools multiply whatever data you feed them.
For the whole framework, with the standards, metrics and incident summaries behind each point, see the reference page on IdentityOps from the Ops Atlas. It is long and organised so you can read one section per sitting.
How to know the checks are working
Pick two numbers and chart them month by month. The first is the share of departures fully closed inside your one-day target, counted across every tool. The second is the count of accounts with no named owner, which should fall toward zero. If both lines move the right way for three months, you have a routine. If either stalls, the stall is information: it points at the tool or the habit that needs attention next.
Planning your own Chennai days
When the rush is over and you finally want a day for yourself, this guide to how many days Chennai deserves helps you pace it, and the roundup of first-visit experiences in the city gives you places to start. Run the eight checks first, though. A rested mind is easier to find when you know nobody unexpected can sign in to your bookings while you are away.
