Who Actually Holds the Keys to Your Cloud Account? Managing Access When Your Dev Team Changes

The month a project's lead developer resigns, the remaining team usually asks two questions at once. Does that person still have access to the company's Google Cloud account? And does anyone know what service accounts or API keys they created along the way? This isn't only an employee-departure problem. It repeats every time a vendor's development contract ends, or an outsourced team moves on to another client. These transition moments are exactly when access control slips out of anyone's direct view, because revoking access was never assigned as someone's job in the first place.

No one schedules that review.

Why the transition moment is where access control breaks down

When someone joins a project, granting access gets attention, because work cannot start without it. The approval has a clear owner and someone follows up until it's done. Offboarding works the opposite way. Nobody's work is blocked if an account stays open by mistake, so the daily pressure to close it never materializes. The risk isn't visible on day one. It accumulates as IAM roles nobody wants to delete because they're unsure what still depends on them, as service accounts created for a one-off test and never disabled, and as shared credentials the whole team knows but nobody has rotated since the day they were set up.

The revoke order that actually matters when someone leaves a project

An easy mistake is closing the departing person's human account and treating the job as done, while the real exposure usually sits in access that isn't tied directly to a named person. The order that holds up better has four steps.

• Review and disable or rotate the service accounts and API keys that person created or managed, before touching their human account. Service accounts typically aren't protected by MFA and get skipped in routine reviews. Google Cloud's own guidance recommends disabling a service account that is no longer needed and deleting it only after a certain period has elapsed. A deleted account recreated under the same name gets a new identity and none of the old IAM bindings, while a disabled account keeps them all when re-enabled. In practice, that means an automated pipeline nobody knew was relying on it can be restored without losing its original permissions.

• Disable the person's human account or SSO identity across every connected system, not just the one that comes to mind first.

• Rotate shared secrets the team used together, such as database passwords or API keys more than one person has seen in plain text, since the departing person may know values that were never tied to their own account.

• Review the audit log covering the period before their last day, looking for newly created permissions, unusually large data exports, or configuration changes that don't match normal work.

Documenting this order in the contract or handover documentation ahead of time means the team isn't inventing the sequence under pressure on the day it actually happens.

Reviewing least privilege on a cycle, not just when someone leaves

The least privilege principle, as NIST SP 800-53 defines it, means each entity is granted the minimum system resources and authorizations it needs to perform its function. The principle only holds if access gets reviewed on a cycle, rather than granted once and left alone until an event forces a check. NIST itself doesn't fix a specific number of days: control AC-6(7) in SP 800-53 Rev. 5 leaves the review frequency organization-defined, and we recommend scaling it to the risk of what's being protected. In practice, tools like Microsoft Entra let you schedule recurring access reviews weekly, monthly, quarterly, or annually, matched to how sensitive each group of permissions is. Systems that touch customer data or carry admin-level rights deserve a tighter cycle than an internal tool nobody outside the team ever opens. The same cycle should eventually cover AI agent identities that connect to systems on their own — a topic with its own review questions — even though the detail differs from a human or vendor account.

Who should own this, not IT alone

The common mistake is treating access revocation as purely an IT task, even though IT is often not the first to know someone has left a project. HR knows an employee's last day before anyone else, so that's where the trigger to IT should start automatically. Procurement or legal knows when a vendor's contract ends or won't be renewed, so that notification should come from them too. The system owner should be the one who signs off that every item on the revoke list is actually done. Security or compliance should own the audit-log review and keep the evidence an external auditor may ask for. IT still does the work, but it shouldn't be the only function that knows when the work needs to happen.

When this level of process isn't worth building

To be direct about the limit here: a small internal system with a handful of users, no customer personal data, and almost no turnover in who administers it or which vendor supports it, doesn't need a full identity-governance platform or automated access reviews. A manual check every quarter, against a real list of who currently has access, covers that level of risk adequately. What a team that size actually needs is someone who reliably does the check on schedule, not tooling built for a risk profile it doesn't have.

The objection we hear most often

The most common pushback is that a team or vendor has worked with the organization for years, trust has been established, so why rush to close access the moment a contract isn't renewed. That's a fair question, and the answer isn't that the relationship didn't matter. The point is that trust isn't a control you can audit. Once a contract ends, legal liability and the boundary of responsibility have already shifted. Revoking access on schedule isn't an accusation against anyone — it's closing out the engagement the way both sides should want it closed, and it's the kind of evidence an external auditor often asks to see during a security or PDPA review.

Where to start

If this has never been handled systematically, there are four steps a team can realistically complete this quarter.

• Build an inventory of who — and which service account — currently has access to what, across Google Cloud, Microsoft Azure, and Cloudflare.

• Write the revoke-order checklist in advance, before the next departure happens, so nobody has to invent the sequence under pressure.

• Assign clear ownership: who notifies, who executes, and who signs off that the list was completed.

• Build the revocation condition into employment and vendor contracts from the start, not as an addition near the contract's end.

Our team at Superdev treats this as part of system design from day one, not as an afterthought handled once the handover is already underway.

In short, the risk to a Cloud account during a transition doesn't only come from outside. It also sits in the access nobody scheduled a review for when someone left the team. If there's one thing to take from this article, write the revoke order down in advance, and assign clear ownership today. To discuss your project in more detail, reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok. If your organization is still reviewing its internal access policies, we're glad to talk it through before any documentation is finalized.