Follow the trust, not just the account.

Understand which identities and privileges support critical work

Before any testing begins, you must identify which identities and privileges actually support critical work. This means listing service accounts, application identities, delegated roles and administrative accounts that touch systems handling sensitive data or essential operations. The goal is not to catalogue every account but to establish which ones matter most to business continuity and data protection. Understanding this hierarchy shapes every subsequent decision about scope, depth and evidence collection.

Privileges should be mapped to the work they enable rather than to the systems they touch. A service account that rotates certificates carries different weight than one that reads configuration files. By tying privileges to functions, you avoid treating all elevated accounts as equivalent. This distinction matters when you later decide where to focus examination and what evidence to gather. It also clarifies which identities require closer review and which can be assessed with lighter scrutiny.

Map trust relationships across people, workloads and environments

Trust relationships extend far beyond simple username and password pairs. They include cross-account delegations, workload-to-workload authorisations, federated login chains and conditional access rules that grant access only under certain conditions. Mapping these relationships requires understanding how one identity can act on behalf of another, sometimes through several layers of delegation. The resulting picture often reveals trust paths that were never documented and that no single administrator can fully trace.

These mappings expose where trust assumptions become fragile. A workload identity trusted by one service may be granted permissions it never needed, and those permissions can cascade into other environments. By documenting the actual trust paths rather than the intended ones, you create a reference point for later decisions about tightening controls. The mapping itself is a hypothesis about how access flows, and it should be treated as such until tested against observed behaviour.

The mapping exercise also surfaces gaps in visibility. Where no one can explain why an identity exists or what it trusts, that gap is itself a finding worth recording. It does not prove misuse, but it does indicate that the environment contains unexamined trust assumptions. Treating these gaps as testable hypotheses rather than confirmed weaknesses keeps the assessment honest and focused on what can actually be verified.

Prepare permissions evidence without collecting unnecessary secrets

Collecting permissions evidence requires a clear boundary between what is necessary and what is excessive. You need records of role assignments, permission grants and access control configurations, but you do not need to extract credentials, tokens or secrets that would increase the risk of exposure. The principle is to gather enough information to verify how access is granted without creating new attack surface through the evidence collection process itself.

Evidence should be gathered under explicit written authority and stored with the same care as the production data it describes. This means limiting access to the evidence, recording where it came from and how it was obtained, and retaining or deleting it according to the agreed handling schedule. Collecting more evidence than the scope requires is a common failure mode, and it shifts the assessment from a review of permissions into a broader data handling exercise that introduces its own risks.

Distinguish configuration review from active validation in the agreed scope. A permissions record may support a hypothesis about access, while a controlled observation may be needed to establish behaviour under particular conditions. The engagement can include both when the appropriate authority and controls are already in place. Do not silently move from one activity to the other simply because a graph shows a possible path. Record what was reviewed, what was tested and what the evidence supports.

Examine where intended privilege boundaries become unclear

Examine both individual grants and the way permissions combine. A user may receive access through a role, a group and a direct assignment, making the effective boundary harder to explain. Conversely, one unnecessary grant may be the important issue even where the surrounding model is simple. Compare the business need, intended access and effective conditions rather than assuming that complexity alone establishes a weakness. Keep the provenance of each relationship so owners can verify the interpretation.

Observed behaviour often diverges from intended design. A permission boundary may be documented as restricting access to a specific environment, while actual configurations allow traffic or identity verification across environments. This divergence is a factual finding, not an accusation. It simply indicates that the intended boundary does not match the implemented one, and that gap needs to be understood before any remediation is attempted.

The examination should distinguish between boundaries that are unclear by design and boundaries that have drifted from their original intent. The former may require a deliberate decision to accept or redesign. The latter usually indicates a process gap in how changes are reviewed and recorded. Treating these cases differently prevents overreacting to structural ambiguity while still addressing genuine drift.

Express findings as relationships and conditions rather than scary graphs

Findings are most useful when they describe relationships and conditions rather than abstract risk scores. A statement that an identity can access a system under certain conditions is actionable because it tells the reader exactly what to examine and why. Graphs and scores may summarise complexity, but they rarely explain which relationship matters or what condition would change the outcome.

For example, a configuration record may show that a workload identity has a grant referencing a production resource. The finding should state where that record came from, whether additional conditions affect its use and whether access was actually validated. The business owner can then explain the intended need, while a separately agreed check may establish the effective behaviour. Do not infer that a permission is unnecessary solely because the identity is usually associated with staging.

The language used to express findings shapes how they are acted upon. Describing a finding as a relationship between two identities is more precise than describing it as a vulnerability. It invites the reader to verify the connection rather than assume it is a flaw. This precision matters because the same relationship may be acceptable in one context and problematic in another, and the finding should reflect that nuance rather than flatten it into a single label.

Assign durable ownership for access change and subsequent validation

Ownership for access changes must be durable, meaning it persists beyond the engagement and is not tied to a single person or project. The owner should be a role or team that exists independently of the assessment, with clear authority to modify permissions and to verify that modifications were applied correctly. Without durable ownership, findings become a list of recommendations that no one is accountable for implementing.

Validation of access changes should be treated as a separate activity from the changes themselves. The team that implements a permission adjustment should not be the only team that verifies it worked as intended. This separation does not imply distrust; it reflects the reality that implementation errors and misinterpretations of requirements are common, and independent verification catches them before they become accepted practice.

The engagement should conclude with a record of who owns each finding, what validation is required and when it should be completed. This record is not a contract but a reference point for follow-up. It should be stored where the owner can access it without requesting it, and it should be reviewed at a defined interval rather than assumed to be resolved because no one raised the issue again.