Appointment calendars, front-desk tools, invoicing systems and marketing dashboards: even a modest healthcare organisation runs a surprising number of cloud accounts, and each one carries rules about who may do what. This ten-part walkthrough explains how a small operations or IT team can bring order to those rules using IAMOps habits. It is a practical, non-clinical walk-through of administrative systems only, so treat it as general reading, not a plan fitted to one organisation.
Before you start: what you are building
The word IAMOps is informal. In its entry on the subject, the Ops Atlas explains the term as treating authorisation as code, which here means: the rules are files, files get reviewed, and reviews include tests. No new software is required at the start, just a spreadsheet, a repository for text files and an hour of uninterrupted focus.
Step 1: List every identity
Open each cloud account and write down every human user, service account, application integration and automated job that can act in it. Include contractors and old projects. Record the creation date and the last activity date if the console shows them. Expect the list to be longer than anyone guessed.
Step 2: Name an owner for each line
Add a column with a person and a backup. For identities that nobody can claim, mark them for review rather than deleting at once. The Atlas relates a January 2024 incident in which a leftover test application with raised rights was the doorway into a large company’s mail system, so unowned identities are the first place to look.
Step 3: Look for anything open to the outside
Use the provider’s built-in external-access analysis, which the Atlas notes is available without charge in one major cloud. Review storage areas, shared resources and trust arrangements with other accounts. Fix anything that has no business reason to be reachable from outside.
Step 4: Freeze the creation of permanent keys
From today, no new long-lived access keys. Programs should use short-lived credentials obtained on demand. The Atlas calls this the entry point to its second maturity level and cites a 2025 survey where year-old keys were still active for 59% of AWS users. A new rule costs nothing to announce and prevents the list from growing while you tidy it.
Step 5: Move one important pipeline to short-lived identity
Choose the automation that deploys your website or booking tool and replace its stored secret with token-based federation. The Atlas notes that after a 2023 incident at a build-service company, in which customer secrets were taken, the company itself advised this approach. When you configure the trust, use exact, per-environment identifiers. A pattern that admits every repository under an organisation’s name is too loose.
Step 6: Put policies in a repository
Export the rules of your most powerful roles and store them as text files. Create a rule that any change needs one reviewer. This gives you history, accountability and the ability to roll back. If you are comparing ways to hold and test policies, our article on researching software wisely before committing to a choice offers a framework for the decision.
Step 7: Test every guardrail in a sandbox
Before a new restriction goes live, try it in a throwaway account. Test the case where information is missing, since the Atlas warns that “not equal” conditions can match when a value is absent. Validate the rule against the language’s schema too, because at least one popular engine skips a rule that errors, which turns a prohibition into a silent no-op.
Step 8: Trim what nobody uses
- Take the widest role and list its permitted actions.
- Pull the activity record for a long enough window to include seasonal tasks.
- Ask the owner about anything periodic, such as quarterly reports.
- Remove a small batch, write the change as a file and merge it after review.
- Watch for denied requests for two weeks and restore a permission if a real need appears.
The Atlas’s illustration involves a role that exercised only 15% of what it was allowed, 27 actions out of 180. Over a quarter of work like this, the median across 120 roles climbed from 22% to 41%.
Step 9: Choose your measures and set a rhythm
Track four numbers monthly: credentials past 90 days, refusals per hundred changes following each release, the share of wildcard allow rules, and the average wait for a grant. Do not be alarmed if the last one creeps up; in the sample the wait lengthened by twelve hours and the team accepted that.
Step 10: Hold the first monthly review and open an exception register
Invite owners to a thirty-minute meeting. Walk through the four numbers, discuss anything that surprised you and record each exception with its approver, its reason and an end date. Put the next meeting in the calendar before everyone leaves.
Budget and timeline
Plan for attention rather than money. The Atlas’s pricing example for late 2026 puts one provider’s unused-access scan at roughly $170 a month for 850 roles, and a few hundred policy checks at a handful of dollars. Prices change, so confirm current rates. As for time, a team of two or three people can usually complete steps one to four in a month if they protect an hour a day, and the later steps fit into the following two months without disrupting daily work.
Roles in the team
You need three kinds of people. Someone technical writes and tests the policy files. Someone from the business side, perhaps a practice manager or billing supervisor, confirms what each role is for. And a sponsor makes sure the review meeting actually happens. Small organisations often combine these, and that is fine as long as every task has a named person.
Common stumbling blocks
- Treating a limit as a permission. Organisation-wide control policies never grant anything. If a rule is not working, check whether you wrote a grant.
- Relying on ready-made bundles. The Atlas says even the provider cautions that managed policies may not be least privilege.
- Stalling on tooling. Do not wait for the perfect engine. Files, reviews and tests come first.
If you want to strengthen the engineering side of the work, our guide to building dependable skills for keeping cloud systems steady pairs well with these steps.
Finish the ten steps in roughly a quarter and you will have owners, short-lived credentials on your busiest pipeline, reviewed policy files and a monthly routine. That is a solid foundation, and everything after it is refinement.