If you manage a website, you probably know the quiet dread of opening the admin user list and finding names you do not recognise. A freelancer from two redesigns ago. An agency login nobody has used since launch. A shared “webmaster” account whose password lives in a chat thread. This checklist walks through a friendly AccessOps audit for a content-managed site: a practical routine for deciding who may do the risky things, for how long, and how you will know afterwards. Grab a coffee and a spreadsheet.

First, what we mean by AccessOps here

In web work, “access” is more than editor versus subscriber. It includes the hosting panel, the database, the DNS settings, the analytics account, the payment plugin and the code repository. AccessOps is the habit of handling requests for the powerful ones deliberately. The Ops Atlas, in its write-up of AccessOps practice, uses the term for requested and privileged access operations, and it is open that the name is an editorial label, not an official standard. What it describes, though, is solid: eligibility instead of permanent rights, time limits, an approval step, an emergency route and regular review. All of that scales down nicely to a small web team.

Part A: Take inventory (do this first)

1. List every system with admin power. CMS dashboard, hosting control panel, domain registrar, DNS, CDN, email-sending service, tag manager, backup storage, code host.
2. List every human and every shared login for each one. Shared accounts get a red flag straight away, because you cannot tell who did what.
3. Mark each as standing or on-request. If the right is always on, it is standing.
4. Note the age of each grant. When was it last used, and who asked for it originally?

Most teams find this takes an afternoon and ends in a mildly embarrassing sheet. That is normal. The Atlas suggests a very similar first month for any organisation: inventory the most sensitive rights, then test the emergency route.

Part B: Trim what is old

5. Disable accounts unused for 45 days. A widely used controls list suggests flagging dormant accounts at about that point, and one cloud vendor’s review tooling recommends denying anyone with no sign-in after 30 days. Pick a number that fits your site and write it down.
6. Remove former contractors completely. Do not just demote them to subscriber; delete the account and rotate any key they ever saw.
7. Cut agency access to a short leash. Third-party access is called out in the Atlas scope as its own concern. Give vendors a named person, an end date and a reason, exactly as you would an employee.

For a reminder of why the front of the site deserves as much care as the back, see our note on how a good service page turns visitors into clients. The pages that earn trust are the same ones an attacker would love to deface.

Part C: Replace permanent power with short grants

8. Make admin an elevated state, not a default. Daily work happens as an editor; to change plugins, templates or DNS, a person requests a window.
9. Use five fields on every request. Who, what, why, until when, approved by whom or by which rule. A spreadsheet is fine to start with.
10. Set default lengths by risk. The Atlas sketches windows that start short for the touchiest systems and stretch to a working day for routine ones; ordinary requests may live ninety to one hundred eighty days with review.
11. Close sessions when the window closes. The Atlas lab showed a connection surviving its credential by about twenty seconds, so expiry alone does not end a session. Log out the user explicitly on sensitive changes.
12. Prefer scoped keys to master keys. If a deployment tool only needs to publish posts, it should not be able to change billing.

Part D: Build one emergency route and test it

13. Create a break-glass admin. Two such accounts are better than one, strong multi-factor sign-in, credentials stored offline.
14. Alarm every use. An email and a chat ping to at least two people is plenty.
15. Drill it every quarter. The Atlas cites a vendor expectation of validation at least every ninety days.
16. Write down the rule for when it may be used. “The site is down and nobody else can approve” is a rule. “It’s quicker” is not.

Part E: Watch and measure

17. Turn on activity logs for the CMS, hosting panel and DNS, and know where they live.
18. Count standing admins monthly. Watch the number fall. A drop from thirty-four to nine is the kind of improvement the Atlas uses in its worked example for the top two tiers.
19. Review emergency use within one business day.
20. Check grant use. If a quarter of approved requests expire untouched, the defaults are too generous or the requests are too casual.

What the audit looks like in a five-person studio

Picture a small studio that maintains a dozen client sites. On Monday morning the owner exports every admin user across the hosting accounts and finds forty-one accounts with full rights. After an hour of questions, nineteen turn out to belong to people who left, to test logins, or to a plugin vendor who finished a job last year. Those are removed on the spot, and two are replaced by named, time-limited grants.

Next the owner sets one rule: to touch DNS or the payment settings, a team member posts a short request in a shared channel using the five fields, and a second person reacts with approval. The window is two hours. A shared spreadsheet logs each one, and a rolling monthly look shows which clients generate the most elevated work. Three months on, the studio has fewer standing admins, a record of why each change happened, and a surprise benefit: handovers to new staff became much faster, because access stopped living in people’s heads.

Nothing in that story needed an expensive product. The discipline mattered far more than the tooling, a point the Atlas makes when it says buying a vault does not by itself mean access is under control.

A few traps to avoid

Do not assume a security plugin equals managed access; it may only add a lock to a door that has twenty keys. Do not let one manager rubber-stamp everything, since approvals soon fill with vague reasons. And do not run every change through an infrastructure script that blindly overwrites roles; the Atlas notes that authoritative templates can wipe out privileged-access settings without a trace.

Finally, give the audit a face. Our piece on building online trust through an About Us page makes a point worth repeating here: visitors trust a site whose owners are visible and accountable. Your admin list deserves the same clarity. Run the checklist once, schedule it again in ninety days, and you will have turned a vague worry into a calm routine.