Why a cloud IAM review is often the first cloud engagement
A cloud IAM review answers a narrow question that frameworks, customer questionnaires, launch reviews and insurers increasingly ask: is access to our cloud accounts controlled, and can anyone reach more than they should? It examines the identities, roles, policies and keys that govern what people, workloads and automation can do in AWS, Azure, Google Cloud or across several of them. In scope are human users and federated sessions, *roles* and role trust relationships, attached and inline policies, groups or role assignments, service identities and the long-lived access keys that still sit in code, CI pipelines or user profiles. The review looks for three weakness categories: privilege escalation paths, where a permitted action lets an identity grant itself more; unused or over-broad permissions; and long-lived keys that outlive their purpose.
It is lighter than a full cloud assessment because it does not test network exposure, storage configuration, logging coverage or workload hardening in depth. Those belong to the provider-specific assessments. The boundary is the shared responsibility model: the cloud provider secures the infrastructure that runs its services, while the customer is responsible for security in the cloud, including how identities and permissions are configured. The provider will not correct an over-broad policy you wrote, so the review concentrates on the part of the environment that is almost always the customer's to fix. Before commissioning, confirm with the provider's published testing rules which activities need approval. Reviewing configuration and reading policies generally does not, but any active testing of listed services must stay within those rules.
Decide early which accounts, subscriptions or projects are in scope, which identity providers feed them, and whether you want a point-in-time snapshot or a baseline you can repeat. Ask the provider to walk through how it will read identity configuration, what evidence it will keep, and how it will handle findings that touch production. Ask whether the output maps to a benchmark your auditor recognises, such as the relevant CIS Foundations Benchmark, so the findings can be traced to controls. Expect the most valuable output to be a ranked list of concrete escalation paths and permissions to remove, with owners, rather than a generic score.
What a cloud IAM review can cover and how scope is agreed
Scope for a cloud IAM review is decided before any identity is examined. The decisions below determine which accounts, identity paths and access levels the review touches, and which provider rules apply to each.
Accounts, subscriptions and projects
Agree the exact list of AWS accounts, Azure subscriptions and Google Cloud projects in scope, along with any organization-level or management-level constructs that govern them. Shared services accounts and sandbox accounts often hold trust relationships that affect production, so confirm whether they are in or out. Record the account identifiers in the statement of work so later findings can be traced to a named boundary.
Identity providers and federation paths
List every path that issues cloud access, including the corporate directory, SSO federation, OIDC trust for CI/CD runners and any cross-account or cross-tenant trust. Each federation path is a route to privilege, so a weak trust condition can matter more than a weak individual role. Ask the client for a current diagram of these trusts before the test starts.
Human and workload identities
Define whether the review covers people, service accounts, managed identities, instance roles, function execution roles and pipeline identities, or only a subset. Workload identities often carry the longest-lived access and the least owner attention, so they usually need explicit inclusion. Confirm which identity types the client wants reported separately.
Roles, policies and key material
Decide which policy sets are reviewed, including attached and inline policies, resource policies, permission boundaries and service control policies where they exist. Key material such as access keys, service account keys, client secrets and certificates is in scope for age, rotation and storage. Ask for an inventory export, not only a console walk-through, so the review covers the full population.
Provider testing rules
AWS allows assessments without prior approval for a listed set of services, but any testing that includes command and control needs prior approval. Microsoft's rules prohibit testing tenants the tester does not own, so every subscription and tenant must be confirmed as the client's. Google Cloud requires that tests affect only the customer's own projects, so project lists must be exact.
Read-only or elevated access
Most IAM reviews run on read-only auditing roles, with enumeration limited to configuration and identity metadata. Any step that needs elevated rights, such as assuming a privileged role to confirm an escalation path, must be named in the written scope and approved by the client in writing before it happens. Record who holds the access, for how long and where the session logs are kept.
How the review runs from scoping to retest
The sequence moves from agreed rules and scope to an evidence-based inventory, control analysis, validated escalation paths and a prioritized report, and ends with confirmation that fixes work. Each phase produces a document the client can check before the next one starts.
Agree scope and rules of engagement
DeployOpen and the client agree in writing which cloud accounts, subscriptions or projects, identity providers and workloads are in scope, and which are excluded. The written scope also records the provider rules that apply, such as whether the review touches only the client's own tenant and whether any activity needs prior approval from the provider. Confirm in the scope document which named contacts can authorize testing and how stop conditions are raised. The step is complete when the client signs the scope and the rules of engagement, and both sides hold the same copy.
Collect the identity inventory and configuration evidence
The reviewer gathers read-only exports of the identity estate: users, groups, roles, service accounts, workload identities, trust relationships, attached and inline policies, permission boundaries, and key or credential metadata such as age and last-use data where the provider records it. The client supplies or grants read access, and the collection is logged. The output is a dated inventory per account or project that the client can compare against its own records. The step closes when every in-scope account has an inventory and any gaps in access are listed.
Analyze IAM controls against the CIS Foundations Benchmarks
The reviewer maps the collected configuration to the IAM-related recommendations in the CIS Amazon Web Services Foundations Benchmark at version 7.1.0, the CIS Microsoft Azure Foundations Benchmark at 6.0.0 and the CIS Google Cloud Platform Foundation Benchmark at 5.0.0, using the versions that match each platform in scope. Each recommendation is marked as passed, failed, not applicable or needing client confirmation, with the evidence attached. Where a benchmark recommendation does not fit the client's architecture, the reviewer records the reason. The step is complete when every in-scope account has a control-by-control result table.
Validate escalation paths and over-broad grants
Benchmark checks do not show how permissions combine, so the reviewer traces which identities can reach which roles, which policies allow actions on wildcard resources, and which chains of role assumption or service account impersonation could lead to higher privilege. Each path is confirmed by reviewing the policy logic and, where the scope allows, a controlled check that does not change production state. Unused permissions and long-lived keys are compared against last-use data. The output is a list of validated paths, each with the identities involved and the conditions required. Confirm in scope whether any active validation is permitted in production.
Prioritize findings and write the report
The reviewer groups findings by the access they expose and the effort needed to close them, then writes a report that states each finding, its evidence, the affected identities, the validated path where one exists, and a specific remediation step. Benchmark references and control mappings are included so the client can show progress to an auditor or customer. Findings that were not validated are labelled as such. The report is complete when the client has reviewed a draft and the reviewer has resolved factual corrections. The client should ask for the report format and the level of detail for each finding during scoping.
Retest fixed items and close the review
After the client has applied fixes, the reviewer re-runs the relevant evidence collection and checks only the findings that were addressed, plus any paths that depended on them. Each finding is marked as resolved, partly resolved or still open, with the new evidence attached. Retest scope, whether it is included in the original quote and how long after the report it can be requested are items to confirm in the written scope. The review closes when the retest report is issued and open items have named owners.
Weakness categories we look for in cloud identities
This table lists the identity weakness categories a Cloud IAM review examines, what each looks like in a cloud account, and why it matters. Read each row as a detection target: the category is the finding, and the right-hand columns show where it usually appears and what evidence confirms it.
| Weakness category | What it looks like in the target | Why it matters |
|---|---|---|
| Privilege escalation through role assumption or policy modification | Principals allowed to assume more privileged roles, create or attach policies, or update their own permission sets, often through chains that only appear when policies are read together | A low-privilege identity can gain administrator-level control without any single permission looking dangerous on its own |
| Over-broad wildcard policies | Actions or resources set to wildcards on sensitive services, or broad permissions granted at account or organization scope where a narrow resource scope was intended | Compromise of one identity exposes far more data and control than the workload needs, and reviewers struggle to justify the grant |
| Unused roles and dormant users | Roles, users and service principals with no recent sign-in or API activity in the logs reviewed, including accounts left from past projects or vendors | Idle identities are rarely monitored, so a stolen credential for one can go unnoticed for long periods |
| Long-lived access keys without rotation | Static access keys or client secrets older than the organization's rotation policy, or keys held in code, tickets or shared files | Long-lived secrets remain valid after staff changes and leaks, and they are a common route into cloud accounts |
| Excessive administrator rights on service accounts | Automation identities, CI/CD runners or service accounts holding administrative roles that their tasks do not require | Pipelines and integrations are high-value targets, so their rights define the blast radius of a single compromise |
| Weak federation or trust conditions | Identity provider trust policies without conditions on audience, subject or repository, or federated roles that any user in the directory can assume | External or broad trust lets identities outside the intended population obtain cloud access without a password |
| Missing MFA on privileged identities | Administrator or root-equivalent users, or console roles, without multi-factor authentication enforced, or with exceptions not documented | Privileged accounts without a second factor are the most rewarding targets for password-based attacks |
| Excess execution rights on serverless or Kubernetes workloads | Function execution roles or pod service accounts with permissions beyond what the code calls, including access to secrets, storage or metadata credentials | If a workload is exposed to untrusted input, its role becomes the attacker's reachable scope, so unneeded rights widen impact |
Where IAM review fits in compliance and customer reviews
Frameworks and customers rarely ask whether access control exists. They ask for evidence that access is reviewed, that the review happened on a schedule, and that someone acted on the findings. For financial entities in the EU, DORA sets a concrete cadence: Article 21 of Delegated Regulation (EU) 2024/1774 requires access rights to systems supporting critical or important functions to be reviewed at least every 6 months. A cloud IAM review gives you a dated, scoped snapshot of who holds which roles, service accounts and long-lived keys in those environments, which is the raw material for that review cycle. Confirm with your compliance lead which systems count as supporting critical or important functions, because that decision defines the cloud accounts, subscriptions or projects in scope.
The same regulation's Article 10 asks for automated vulnerability scanning of those assets at least weekly. An IAM review does not replace that scanning, but it covers a gap scanners miss: an over-broad role or an unused access key is a configuration fact, not a missing patch. Before the engagement, ask the provider to map each finding to the access review record your organization keeps, so that remediation tickets, owners and closure dates can be pulled into one evidence set for the next review.
DeployOpen prepares controls, configurations and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. In practice, the deliverable from a cloud IAM review should be written so your auditor can trace each access decision to a finding, a remediation and a retest result, and so a customer's security review team can read it without a translator. Ask the provider which of those artifacts it will produce, in what format and with what dating, and confirm with your auditor what form of access evidence they will accept before the test is scoped.
Frameworks and programs that expect identity and access testing
This table maps four assurance contexts to what each expects for cloud access, from DORA access reviews to insurer and customer questionnaires. Use it to see which evidence you need before scoping a review, and confirm the exact wording of any requirement with your auditor or the framework text.
| Context | What it expects for cloud access | Evidence a reviewer usually asks for |
|---|---|---|
| DORA Article 21 (Delegated Regulation (EU) 2024/1774) | Access rights reviewed at least every 6 months for systems supporting critical or important functions | Dated access review records, removal of stale accounts, and proof that reviews cover cloud roles and service identities |
| CIS Foundations Benchmarks (AWS 7.1.0, Azure 6.0.0, GCP 5.0.0) | Used as a configuration baseline for identity settings such as root or owner account protection, MFA, and key management | Benchmark-mapped findings, configuration output, and a remediation record for each failed recommendation |
| Customer security questionnaires | Assurance that cloud privileges are least privilege, reviewed, and not reliant on long-lived keys | Written access policy, a recent review summary, and an independent test report or statement of scope |
| Insurer requirements | Evidence that privileged cloud access is controlled and that known identity weaknesses are being fixed | Scope of the test, findings status, and proof of retest for high-impact identity issues |
| Provider testing rules (AWS, Microsoft, Google Cloud) | Testing of IAM must stay within each provider's published rules, with no attacks on other tenants | Written scope naming the accounts or projects, and confirmation that no prohibited activity is included |
What the client receives and whether it serves an auditor
A Cloud IAM review ends in a written report, and its value depends on whether an auditor or customer can trace each finding to evidence and a retest. The cards below cover what the report contains and where it stops, since it records what was tested and found, not whether the environment is compliant.
Executive summary and scope record
The opening section states which accounts, subscriptions or projects, identity providers and time window were in scope, and which were excluded. It also gives the overall risk picture in plain language for a board or risk committee. Check that the scope statement matches the written agreement signed before testing, because an auditor will compare the two first.
Identity inventory with owners
The inventory lists human users, roles, service accounts and access keys reviewed, with their owners, last-used dates where the platform exposes them, and the policies attached. It is the baseline for access review evidence. Ask whether the inventory is a point-in-time export or can be regenerated, since recurring reviews need the same method each cycle.
Findings with severity and affected identities
Each finding names the identity or role affected, the permission or trust relationship involved, the weakness category, and a severity with its rationale. Over-broad permissions, unused access, long-lived keys and cross-account trust are reported as separate items. Every finding should name the specific identities it affects, so the owner can act without re-running the review.
Escalation path diagrams
Where a chain of permissions allows one identity to gain control of another, the report shows the path as a diagram with each hop explained. These diagrams help architects see why a low-severity permission matters in combination. They describe the path at the level needed for remediation, without exploit steps, and should be checked for accuracy against the platform's documented policy evaluation logic.
Remediation mapped to CIS recommendations
Remediation guidance links each finding to the relevant recommendation in the CIS Benchmark for the provider in scope, identified by its control ID and title. The guidance states the owner, the change, and how to verify it. Ask the provider to confirm which benchmark version was used, since recommendation numbering changes between versions.
Retest results and closure status
After the client fixes findings, a retest confirms each closed item and records anything still open or accepted as a risk. Retest results should reference the original finding IDs and state the date and configuration checked. An auditor will look for this closure trail, so ask for it to be included in the fixed-price scope or scheduled as a separate step.
How IAM review differs across AWS, Azure, Google Cloud and Kubernetes
AWS identity is built from IAM users, roles, policies and trust relationships. A review starts by mapping which principals can assume which roles, which policies grant those roles effective permissions, and where long-lived access keys still exist. Permissions are the sum of identity policies, resource policies, permission boundaries and service control policies at the organization level, so a reviewer has to read them together rather than one file at a time. The points that most often need attention are:
- Trust relationships: role trust policies that allow broad principals, cross-account trust without an external ID, or a chain of roles that lets a low-privilege principal reach an administrative one.
- Access keys: long-lived keys for human and machine users, keys that have not been rotated, and keys that belong to users who no longer need them.
- Policy scope: wildcard actions or resources, inline policies attached directly to users, and managed policies that grant far more than the workload uses.
- Organization guardrails: whether service control policies limit what member accounts can do, and whether those limits apply to the accounts in scope.
- Unused permissions: access that has not been exercised in a long period, which the review can compare against last-used data.
Confirm with your team which accounts are in scope, whether any testing requires prior AWS approval under the AWS penetration testing policy, and whether the review also covers the configuration described in the AWS shared responsibility model.
Azure access is controlled through role assignments, which bind a principal to a role at a scope such as a management group, subscription, resource group or individual resource. Entra ID supplies the identities, groups and application registrations that receive those assignments, so a review has to cover both the directory and the subscription. Inherited assignments from higher scopes are often the hardest part to see and the easiest to overlook. The points that most often need attention are:
- Scope inheritance: role assignments made at a management group or subscription that reach many resources, including ones the owning team does not manage.
- Privileged roles: owner and user access administrator assignments held by users, groups or service principals that do not need them day to day.
- Entra ID-connected identities: service principals and managed identities with credentials, app registrations with client secrets, and group membership rules that grant access automatically.
- Guest and external access: directory guests with assignments in subscriptions that hold production workloads.
- Logging of changes: whether role assignment changes are captured in the activity and directory logs so that drift can be traced.
Confirm the subscriptions and tenant boundaries in writing before the review starts, and check the testing limits in the Microsoft Cloud penetration testing rules of engagement if any active testing is planned.
Google Cloud grants access through IAM policy bindings, which attach roles to members at the organization, folder, project or resource level. Service accounts are both identities and resources, so a review covers who can act as a service account, which keys exist for it, and what roles it holds. Organization policies add a separate layer that can restrict behavior across many projects at once. The points that most often need attention are:
- Bindings at higher levels: roles granted at the organization or folder level that propagate to every project beneath them.
- Service account keys: user-managed keys that are long-lived, unrotated or unused, which the review should compare against the keys that are actually needed.
- Impersonation rights: principals that can impersonate a service account, since this can grant more access than the principal holds directly.
- Organization policies: whether constraints on key creation, external identities and resource sharing are enforced across the projects in scope.
- Default and broad roles: primitive roles such as owner or editor, and default service accounts that carry broader permissions than their workloads need.
Google states that customers do not need to notify Google before testing their own infrastructure, but the work must follow the Acceptable Use Policy and Terms of Service and affect only the customer's own projects, so confirm project boundaries before any active step.
Kubernetes authorization uses RBAC, which binds subjects such as users, groups and service accounts to roles at namespace or cluster scope. The cloud identity layer adds a second question: how pods obtain cloud credentials and what those credentials can do. A review therefore has to read the cluster bindings together with the cloud IAM configuration that the workloads inherit. The points that most often need attention are:
- Cluster-wide bindings: cluster role bindings that grant broad rights, including rights to read secrets or create workloads in every namespace.
- Default service accounts: pods running under default service accounts with token mounts or permissions they do not use.
- Workload identity links: the mapping between Kubernetes service accounts and cloud identities, and whether that mapping gives a pod more cloud access than its function requires.
- Pod security settings: whether namespaces enforce the Pod Security Standards at a level that matches the workload's risk.
- Node-level credentials: instance profiles or node identities that pods can reach if isolation is weak.
Confirm with the platform team which cluster and cloud accounts are linked, and use the CIS Kubernetes Benchmark and the Kubernetes Pod Security Standards as the reference points for the cluster side of the review. Serverless execution roles are covered in the serverless testing topic.
What the client prepares before the review starts
Before the review starts, the client names one accountable contact for the cloud platform, one for the identity provider and one for the business owner of each account in scope. These people answer questions about why a role exists, which workloads depend on a key, and which change tickets explain a recent policy edit. The client also confirms in writing which accounts, subscriptions or projects are in scope, including any organization-level management account, shared services account or sandbox that can still reach production identities. Scope agreed on paper is what the reviewer uses to decide which trust relationships and roles to examine, so an account left off the list is an account nobody reviews.
Access comes next. The reviewer usually needs a read-only or dedicated reviewer role that can read identity and policy configuration, access advisor or last-used data, and audit logs, without the ability to change anything. The client should agree the exact role, the session method and who provisions it, and record that agreement in the statement of work. If an identity inventory export is available, such as a credential report, a list of IAM users with last-used dates, or a directory export of groups and memberships, provide it early, since it shortens the first days of analysis. Ask the reviewer to confirm which exports they can use and which the client should produce. Also list the federated identity providers that issue sessions into the cloud, because trust policies that accept external identities are a common source of unexpected paths.
Plan the calendar as well. Identify any change freeze windows, release periods or audit blackout dates so the review does not coincide with a policy migration that would make findings stale. Confirm whether any planned test activity needs approval from the provider in advance. Under the AWS penetration testing policy, most listed services can be assessed without prior approval, but any testing that includes command and control needs prior approval, and certain simulated events need a request at least 2 weeks ahead. IAM configuration review is usually read-only, but the client should check the current provider rules and confirm with the reviewer whether any activity falls outside them. Write those decisions down before the kickoff.
What to check before choosing an IAM review provider
An IAM review is only as good as the person doing it, so the checks below focus on the reviewer's experience, their grasp of the testing rules, and the paperwork you receive before work starts. Each card covers one item you can verify in writing before you sign.
Experience with each cloud's identity model
Ask whether the reviewers have worked through AWS IAM policies, Azure role assignments with Entra ID, and Google Cloud IAM bindings and service accounts, not only one of them. Each provider evaluates identity differently, including how inherited permissions, resource policies and trust relationships combine. Ask for examples of the kinds of privilege escalation paths they have checked in each environment, described at a category level.
Knowledge of provider testing rules
Confirm the provider knows which activities each cloud permits without prior approval and which require a request. For example, AWS has a listed set of services customers may test without approval, and it requires advance notice for simulated events. Microsoft and Google publish their own rules, and the provider should explain how those rules shape the review scope.
Written fixed scope
Expect a written scope that names the accounts, subscriptions or projects, the identity providers in scope, the review period, and the exclusions. A fixed scope lets you compare quotes on equal terms. Ask what happens if the review finds a cross-account trust or a federated identity source that was not in the original list.
Access and data handling terms
A reviewer usually needs read access to IAM configuration, and sometimes to logs. Confirm which roles they will request, how credentials are issued and revoked, where evidence is stored, and how long it is kept. Ask whether any review requires the reviewer to see secrets or key material, and what the provider will do to avoid copying it.
A sample report
Request a redacted sample report before signing. Check whether each finding names the affected identity or policy, the evidence used, the risk, and a concrete remediation step. A useful report separates confirmed issues from items that need your team's context, such as a service account whose purpose only your engineers know.
Retest terms and independence
Confirm whether one retest of fixed findings is included, how long it stays open, and whether it is priced separately. Also ask whether the reviewers had any role in building or changing the IAM design under review. A reviewer who helped design the roles is poorly placed to judge whether those roles are over-broad.
Cloud IAM review questions buyers ask before commissioning
How much effort does a cloud IAM review take?
Effort depends mainly on the number of accounts, subscriptions or projects in scope, how many identity providers and federation paths feed them, and how many roles and policies exist. A single account with a small, well-documented role set is far quicker to review than an organization with dozens of accounts, inherited policies and many CI/CD integrations. Effort is also driven by how much evidence your team can export in advance, such as role inventories, policy documents and access logs. DeployOpen does not publish prices. A quote follows from the written scope, so ask the provider to itemize the environments, the identity sources and the reporting depth they have assumed.
How long does a cloud IAM review take?
Duration follows the same drivers as effort: the number of environments, the identity sources, the size of the permission set and how quickly your team answers questions about intended access. Reviews that include analysis of cross-account trust, federated access and automated credentials take longer than reviews limited to human users. Time also depends on whether findings need validation in a live environment, which requires agreed access windows. No standard duration applies. Ask the provider for a timeline tied to the written scope, and confirm which steps depend on your own staff being available.
What must our team provide before a cloud IAM review starts?
Most reviews need the following before work begins:
- A list of accounts, subscriptions or projects in scope, with owners and environment types
- Exports or read-only access to identity and policy configuration, including role and policy definitions and trust relationships
- Identity provider and federation design documents, plus a list of CI/CD and workload integrations
- Access logs or audit trail retention settings, so usage can be compared with granted permissions
- A named contact who can explain why specific roles exist
Read-only access is usually sufficient for the review itself. Confirm the exact access model in the written scope, and agree how credentials and exports will be handled.
Can our internal staff run a cloud IAM review themselves?
Internal staff can review their own identities against the CIS Foundations Benchmark for their provider, and many teams do this continuously. Where they struggle is independence and attack-path thinking: staff who maintain the roles often accept inherited permissions as necessary, and they rarely chain several small permissions into a privilege escalation route. An external review adds a second set of eyes, a method for tracing escalation paths across accounts and federation, and a written record that a third party can compare against the framework. The trade-off is cost and the time needed for your staff to answer questions. Many organizations use internal checks for routine hygiene and an external review for the periodic, scoped assessment.
Does a cloud IAM review satisfy an auditor on its own?
No. A review produced by a security testing provider is evidence that you checked access controls. It is not an audit report, attestation or certification. Independent auditors and certification bodies decide whether your controls meet a framework, and they will ask for evidence such as access review records, approval history and remediation tracking. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports. Ask your auditor early which artifacts they will accept, and agree the report format and mapping to controls with them before the review begins.
How does retesting work after a cloud IAM review?
Retesting checks whether the agreed findings were fixed. It is usually scoped as a separate, smaller piece of work, so confirm in the written scope whether retesting is included, how many rounds are covered and how fixes are verified. Verification typically means re-running the relevant checks against the changed roles, policies and trust relationships, then recording the outcome against each finding. Some findings, such as long-lived keys, need evidence that old credentials were revoked and that workloads moved to short-lived alternatives, not just a changed setting. Ongoing checks can be handled through a retainer if your environment changes frequently.
Does a cloud IAM review need approval from the cloud provider?
It depends on the provider and the activity. Review of identities, roles and policies is a configuration review, not a penetration test of the provider's infrastructure, so it generally does not require provider approval. AWS allows customers to run security assessments or penetration tests of listed services without prior approval, but any testing that includes command and control needs prior approval, and certain simulated events require a request at least 2 weeks ahead. Microsoft's rules of engagement and Google Cloud's guidance also set limits on what testers may do. Confirm the testing rules for each provider in the written scope before any active validation begins.
How DeployOpen scopes, tests, reports and retests IAM reviews
DeployOpen is a Chainscore Labs company that runs security testing and configuration review inside your own cloud accounts, so the IAM review happens in the environment you operate, under the access you grant. Engagements are fixed-scope. Before work starts, the written scope names the cloud accounts, subscriptions or projects, the identity providers and federation paths in play, the sample of roles and service accounts to examine, and whether the work stays read-only or includes validation of specific escalation paths. DeployOpen does not publish a price list. A quote follows from that written scope, so the decisions that move cost (number of accounts, number of identity sources, whether validation is included, and how many findings need a retest) should be settled before you sign. Ask the provider to state what is one-time and what recurs, and who supplies the read-only access and the audit trail for it.
The deliverable should answer the questions your auditor and your risk owners will ask: which principals hold administrative rights, which long-lived access keys exist and who owns them, which policies grant wildcard actions or cross-account trust, and which findings were validated versus inferred from configuration. Confirm the report format, severity definitions and evidence handling in the scope document, and check which benchmark control IDs the findings map to, for example against the CIS AWS Foundations Benchmark, the CIS Microsoft Azure Foundations Benchmark or the CIS Google Cloud Platform Foundation Benchmark, depending on your provider. Retesting is part of the agreed scope: after you fix the findings, the provider re-checks the specific roles, policies and keys in question and records whether each finding is closed. Confirm in writing how many retest rounds are included and what happens to findings you accept as risk. Where you need ongoing access reviews, for example to meet a six-monthly review cadence that a regulator sets, DeployOpen offers retainers for continuing review and retesting rather than a one-off report.
