Cloud IAM & Permissions Audit

No. We use a read-only IAM Role (AWS), App Registration (Azure), or Service Account (GCP) scoped strictly to IAM, Organizations, AWS Identity Center, AWS RAM, CloudTrail, Entra ID, and GCP IAM APIs. The role explicitly cannot read S3 / Blob / GCS object contents, database rows, Secrets Manager / Key Vault / Secret Manager values, or any other data-plane resource - and it has zero write permissions across every API. We provide the policy JSON in advance so your security team can review it before deployment.

Graph-based, not rule-based. We model every principal, role, policy, trust relationship, and group as a graph and run path-finding analysis (PMapper, Cartography) to find every chain that leads from a low-privilege identity to admin or to a sensitive resource - including multi-step chains that no rule-based scanner catches. Every path is mapped to MITRE ATT&CK Cloud Matrix techniques (T1078 Valid Accounts, T1098 Account Manipulation, T1548 Abuse Elevation Control) so your detection engineers can build coverage in parallel with remediation.

Those tools produce raw findings; this audit interprets them. AWS IAM Access Analyzer is excellent at unused-access detection but does not map full escalation chains, distinguish legitimate cross-account roles from confused-deputy exposure, or prioritise based on actual blast radius. CSPM platforms like Wiz, Orca, Prisma Cloud, Lacework, and CrowdStrike Falcon Cloud Security generate thousands of IAM findings - most are noise. A senior cloud-security engineer triages every finding, removes false positives, combines signals across IAM Access Analyzer, Access Advisor, IAM Recommender, PMapper, Cartography, Prowler, and ScoutSuite, and produces a prioritised, copy-pasteable remediation backlog rather than a 5,000-line raw report. If you already use a CSPM, we sanity-check its IAM module too.

Yes. Every finding is mapped to specific controls in the CIS AWS, Azure, and GCP Foundations Benchmarks (the IAM sections), NIST 800-53 Access Control (AC) family, the AWS Well-Architected Security pillar, and MITRE ATT&CK Cloud Matrix techniques. The output is designed to drop directly into SOC 2, ISO 27001, HIPAA, or PCI-DSS evidence packs as well as detection-engineering backlogs.

Yes - and most teams find this is the highest-ROI part of the audit. The report includes a secretless-workload migration plan covering OIDC federation from GitHub Actions, GitLab CI, CircleCI, Buildkite, Kubernetes (IRSA on AWS, Workload Identity on GCP), Terraform Cloud, and Jenkins to AWS, Azure, and GCP - with the trust-policy templates, conditions, and audience claims you actually need so long-lived keys can be deleted entirely.

No. The audit is fully read-only, runs against IAM and identity APIs at a controlled rate, and never assumes other roles, never modifies anything, and never connects to data-plane services. We can pre-coordinate with your detection team if your CloudTrail / Defender / SCC alarms might flag the read activity - but in practice the API calls look identical to a normal admin running aws iam list-* commands.

For AWS we work via the management account and read child accounts through AWS Organizations, AWS RAM, and the IAM-related APIs (no cross-account assume needed beyond the read-only audit role). For Azure we read across subscriptions via Management Group scope. For GCP we read across folders and projects via the organisation node. Findings are deduplicated across accounts (e.g. the same SCP gap shared across 30 accounts becomes one finding with affected-account list) and prioritised by environment criticality.

Typical turnaround is 1-2 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your security and platform leads. Larger multi-account / multi-cloud estates with thousands of identities can take a little longer; we confirm the timeline as soon as we see the scope.