Why this keeps getting postponed
Access review appears in every security control framework, and in most organisations it also appears on the list of things to do when there is time. The reason is not that it is hard. It is that it sounds like a project: enumerate every identity, reconcile against HR records, build a role matrix, get sign-off from each system owner. Framed that way it genuinely takes weeks, so it never starts.
This article frames it differently. The goal is not completeness, it is finding the largest risks in the least time. The eight items below are ordered by risk-to-effort ratio and add up to about three hours for a mid-sized environment. Run it quarterly and each round gets faster, because you have already cleared the backlog.
Fifteen minutes of preparation
Get three things ready. First, a list of every cloud account, project or subscription your organisation uses. This is harder than it sounds, because there is usually an account a department opened on a corporate card, or a project account from work that finished. Cross-checking cloud provider charges with finance is the fastest way to surface them.
Second, an identity export. On AWS, the credential report gives you most of what the first three items need in a single file:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > creds.csvOn Google Cloud, export the IAM policy for each project:
gcloud projects get-iam-policy PROJECT_ID --format=jsonThird, an empty spreadsheet with columns for item, finding, severity, owner, action and due date. Every finding goes there. Without a written record, the review only produces a feeling that something was done.
1. Root and privileged accounts (20 minutes)
The highest-value item and one of the fastest, so it always goes first.
What to check: the root or owner identity of each cloud account, the list of principals with full administrative rights, and the last sign-in time for root. On AWS that means identities carrying full administrative policies; on Google Cloud, owner roles and organisation-level admin roles.
What good looks like: root has no active access keys, is protected by MFA, and has no sign-ins during the period other than documented ones. The number of people with full admin fits on one hand, all of them still work here, and all of them genuinely need it for daily work.
What to do with findings: root access keys get deleted during the review, not scheduled. Administrative rights held by people who no longer need them get revoked. Where people need elevated rights occasionally rather than constantly, move them to time-limited elevation with approval instead of standing access.
2. MFA coverage (15 minutes)
What to check: the proportion of human accounts with multi-factor authentication enabled, and more usefully, the specific list of those without it. If you use a central identity provider, check there, and also check whether any local cloud accounts bypass the identity provider entirely.
What good looks like: every human account that can authenticate with a password has MFA, with no exemptions by department or seniority. Shared accounts, where they must exist, use MFA bound to an organisation-managed device rather than one person’s personal phone.
What to do with findings: set a short, specific deadline, usually within the week. After that deadline, disable password sign-in rather than sending another reminder. Where the platform allows it, enforce MFA by organisation policy so the next review does not need to check manually.
3. Stale human accounts (20 minutes)
What to check: accounts that have never signed in, accounts with no sign-in for ninety days or more, and accounts belonging to people who have left or changed roles. Reconcile the identity list against the current employee list from HR.
What good looks like: every account maps to a current employee who currently needs access. No never-used account survives more than a few weeks past creation.
What to do with findings: disable first, delete later. Disabling is safe and reversible if you got it wrong; delete after thirty days if nobody objects. More important than the cleanup is the cause: if you found a leaver’s account, the offboarding process has a gap and needs fixing, otherwise next quarter produces exactly the same findings.
4. Service accounts and long-lived keys (25 minutes)
This item usually produces the most findings, because machine identities never resign and so never trigger a cleanup process.
What to check: every access key, service account key and long-lived token, with creation date and last-used date. Focus on three groups: keys older than a year, keys never used, and keys attached to highly privileged identities.
What good looks like: no static keys at all for workloads running inside the cloud, since those should use resource-attached identity such as an instance role or workload identity. The keys that remain, for external systems or CI/CD, each have a named owner, a narrow permission scope, and a rotation schedule.
What to do with findings: never-used keys get disabled immediately, since the risk of breaking something is close to zero. Used keys with no known owner need a log query to find where the calls originate before you touch them. Old keys in genuine use get a scheduled rotation rather than an abrupt disable, and where the workload runs inside the cloud, prioritise moving it off static keys entirely. Also check whether any key has ever been committed to a source repository, because a key exposed in git history remains fully valid to whoever finds it.
5. Over-broad wildcard policies (20 minutes)
What to check: custom policies with a wildcard in the action or resource field. Pay particular attention to policies allowing all actions on all resources, and to policies granting permission-management actions such as creating users, attaching policies, creating access keys, or assuming other roles. An identity that can modify its own permissions is effectively an administrator regardless of what its policy nominally says.
What good looks like: application policies list only the actions the application actually calls, scoped to specific resources. Permission-management rights sit only with the administrator group.
What to do with findings: do not tighten a production policy during the review itself, because narrowing permissions is the fastest way to break a running service. Record it, assign it to the team that owns the application, and ask them to replace it with a narrower policy derived from real usage logs. Policies that allow privilege escalation are the exception worth escalating sooner.
6. Cross-account trust and federation (15 minutes)
What to check: roles that allow principals from other accounts to assume them, federation links to external identity providers, and permissions granted to service providers or partners. Read the trust conditions carefully: who exactly is on the other side, and are there additional conditions constraining it.
What good looks like: every trust relationship corresponds to a contract or an active project you know about. Third-party roles carry additional binding conditions such as an external identifier, and have minimum necessary scope.
What to do with findings: an unexplained trust relationship is high severity and needs tracing immediately. Relationships with partners whose engagement has ended get removed. If you cannot determine who created one, check the administrative activity log around its creation time.
7. Public exposure (20 minutes)
What to check: object storage buckets allowing anonymous access, snapshots or machine images shared publicly, databases with public addresses, and security groups opening administrative ports to the whole internet. SSH and RDP open to an unrestricted source range is the first thing to look for.
What good looks like: no public storage other than content that is deliberately and documentedly public, such as website static assets. No administrative port reachable from the internet; administrative access goes through VPN or a bastion.
What to do with findings: this is the item you can and should fix during the review, because the risk is high and the operational impact of closing it is usually low. For data that was public, closing it is not the whole job: review access logs to assess whether anyone actually retrieved it, and escalate to management if there are signs they did.
8. Granted but unused permissions (15 minutes)
What to check: the gap between permissions granted and permissions actually exercised. The major cloud providers each have access analysis tooling that reports which services an identity has never called within the observation window.
What good looks like: for important identities, the granted permission set is close to the used permission set. An identity that has not touched a service in six months does not need rights on it.
What to do with findings: treat this as gradual improvement rather than urgent remediation. Pick the three to five broadest identities, assign the narrowing work to the next cycle, and ignore the long tail. Cutting permissions from usage data needs a long enough observation window that you do not remove rights used only by monthly or quarterly jobs.
Handling the findings
At the end you have a list. Sort it into three tiers so you avoid the state where everything is urgent and therefore nothing gets done.
| Tier | Examples | Action |
|---|---|---|
| Fix today | Root access keys, unintended public data, admin ports open to the internet, active accounts for departed staff | Fix same day and record who did it and when |
| Fix this cycle | Missing MFA, unrotated long-lived keys, unexplained trust relationships | Assign an owner with a two-week deadline |
| Improve over time | Wildcard policies, excess permissions, shared accounts | Put on the quarterly plan and track across reviews |
Two closing steps make the next round faster. Write the commands and filters you used into a short internal document, and for every finding that recurs between cycles, ask whether it can become an automated alert instead. A periodic review exists to catch what automation cannot.
How HiTechCloud can help
HiTechCloud helps businesses in Vietnam review access configuration across AWS and Google Cloud, implement MFA policy and centralised identity management, move workloads off static keys onto resource-attached identity, and set up automated alerting on permission changes. We are an AWS partner and a Google Premier Partner, and we operate in-country infrastructure for systems that need data to stay in Vietnam.
