[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-cloud-access-vendor-transition-en":3,"blog-post-cloud-access-vendor-transition-en":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"NIST SP 800-53 doesn't set a fixed number; it leaves review frequency organization-defined based on risk. In practice, tools like Microsoft Entra let you schedule reviews weekly through annually. Systems touching customer data or carrying admin rights deserve a tighter cycle than an ordinary internal tool.","oxuwa1vh2ldgkmt","How often should we review Cloud account access when there's been no team change?",{"answer":9,"id":10,"question":11},"Start with the service accounts and API keys that person managed, since those aren't protected by MFA and get skipped in routine checks. Then disable their human account across every system, rotate any shared secrets they knew, and finish by reviewing the audit log covering the period before their last day.","jvc4hidx88gn4ff","When an employee or developer leaves a project, what access should be revoked first?",{"answer":13,"id":14,"question":15},"A service account is often wired into an automated pipeline that's still running, and it isn't tied to MFA the way a human account is. Deleting it immediately can silently break something else, so it should be disabled first and deleted only once you're sure nothing still depends on it. A human account can usually be closed the moment the person leaves.","r0f9a32kcq6dh4z","How is a service account different from a human account for offboarding purposes?",{"answer":17,"id":18,"question":19},"Confirm every access the vendor's team held has been revoked, both personal accounts and any service accounts they created, rotate secrets that were shared with them, and review the audit log from the period leading up to contract end, before signing off the engagement as closed.","zt8063e7bn0q7di","When a vendor's development contract ends, what should be checked before closing it out?",{"answer":21,"id":22,"question":23},"HR should trigger the process the moment an employee's last day is confirmed. Procurement or legal should trigger it when a vendor contract ends. The system owner should sign off that revocation is complete, and security or compliance should own the audit-log review. IT carries out the work once notified.","i8uxozth9fl4ia9","Who inside the organization should own the Cloud access offboarding process, not just IT?",{"answer":25,"id":26,"question":27},"If it's a small internal system with a handful of users, no customer personal data, and little turnover in who administers it, a manual quarterly check is enough. There's no need to invest in a full identity-governance platform or automated access reviews at that scale.","kxzdbee2f6dwmcr","Does a small organization with only a few systems need a formal access offboarding process?",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"6o9fgxbwojdvkxm","k15mzy5f9l0f12r","Who Actually Holds the Keys to Your Cloud Account? Managing Access When Your Dev Team Changes","When a developer leaves or a vendor contract ends, unrevoked Cloud access is a risk nobody scheduled a review for. Revoke order, review cadence, and ownership.","\u003Cp>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.\u003C\u002Fp>\u003Cp>No one schedules that review.\u003C\u002Fp>\u003Ch2>Why the transition moment is where access control breaks down\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Ch2>The revoke order that actually matters when someone leaves a project\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>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. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcloud.google.com\u002Fiam\u002Fdocs\u002Fbest-practices-service-accounts\">Google Cloud's own guidance\u003C\u002Fa> 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.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Disable the person's human account or SSO identity across every connected system, not just the one that comes to mind first.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>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.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>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.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>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.\u003C\u002Fp>\u003Ch2>Reviewing least privilege on a cycle, not just when someone leaves\u003C\u002Fh2>\u003Cp>The least privilege principle, as \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Fleast_privilege\">NIST SP 800-53\u003C\u002Fa> 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 \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Fsp\u002F800\u002F53\u002Fr5\u002Fupd1\u002Ffinal\">SP 800-53 Rev. 5\u003C\u002Fa> leaves the review frequency organization-defined, and we recommend scaling it to the risk of what's being protected. In practice, tools like \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fid-governance\u002Faccess-reviews-overview\">Microsoft Entra let you schedule recurring access reviews weekly, monthly, quarterly, or annually\u003C\u002Fa>, 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 — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Fai-agent-readiness-before-system-access\">a topic with its own review questions\u003C\u002Fa> — even though the detail differs from a human or vendor account.\u003C\u002Fp>\u003Ch2>Who should own this, not IT alone\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Ch2>When this level of process isn't worth building\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Ch2>The objection we hear most often\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>Where to start\u003C\u002Fh2>\u003Cp>If this has never been handled systematically, there are four steps a team can realistically complete this quarter.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>Build an inventory of who — and which service account — currently has access to what, across Google Cloud, Microsoft Azure, and Cloudflare.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Write the revoke-order checklist in advance, before the next departure happens, so nobody has to invent the sequence under pressure.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Assign clear ownership: who notifies, who executes, and who signs off that the list was completed.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Build the revocation condition into employment and vendor contracts from the start, not as an addition near the contract's end.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Our team at \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\">Superdev\u003C\u002Fa> treats this as part of system design from day one, not as an afterthought handled once the handover is already underway.\u003C\u002Fp>\u003Cp>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 contact@superdev.tech. 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.\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F6o9fgxbwojdvkxm\u002Fcover_cover_zzeg38teh9.webp","September 29, 2026","2026-09-29 04:12:30.990Z",109,"Enterprise","enterprise","cloud-access-vendor-transition","\u002Fblogs\u002Fcloud-access-vendor-transition",7,false,0,"",[47,48,49,50,51,52],"IAM","access management","cloud security","offboarding","least privilege","vendor access"]