What the Cloud audit should help you decide
The audit checks whether the security actually configured in AWS or Azure matches the protection level expected by the organization. We look for overly powerful accounts, public resources, shared secrets, overly accessible data, backups dependent on production, and pipelines able to change the Cloud.
The debrief distinguishes what must be fixed immediately, what requires an architecture change, which access paths or resources are actually exposed, which fixes can be automated, and which investments can reduce risk the most.
What do we review in AWS and Azure?
Cloud accounts, subscriptions, and organization
We check whether the Cloud organization actually reflects the company’s boundaries: AWS accounts, Organizations, root accounts, Azure tenants, subscriptions, management groups, resource groups, environments, and administration ownership.
Production, development, administration, and sensitive projects should be separated enough to prevent an incident in one scope from automatically opening access to the others.
Identity, IAM, and privileges
We identify administrator accounts, roles, groups, MFA, SSO, root or Global Admin accounts, temporary rights, dormant accounts, providers, application identities, persistent keys, and inherited permissions.
We look for identities able to change production, read data, or increase their own privileges. The goal is to reduce permanent rights and make sensitive access explicit, attributable, and revocable without duplicating the IAM remediation page.
Cloud networking and Internet exposure
We review VPCs, VNets, subnets, Security Groups, NSGs, NACLs, gateways, load balancers, private endpoints, administration interfaces, public IPs, cross-environment access, VPNs, and on-premise connectivity.
We map paths that can reach critical resources from the Internet, another workload, or the internal network. A resource is not secure merely because it does not appear directly on a public page.
Data, storage, and encryption
We examine buckets, object storage, databases, snapshots, volumes, files, public data, access policies, encryption at rest and in transit, keys, cross-account sharing, and replication.
We identify which data is sensitive, who can actually read it, and through which paths it could be copied or exposed. We also check whether production data has reached test environments.
Secrets, keys, and technical identities
We review application secrets, API keys, Cloud credentials, CI/CD variables, Kubernetes secrets, SSH keys, certificates, tokens, rotation, vault access, and secrets present in repositories.
A secret should not become a permanent password shared across teams or environments. We check where it is stored, who can read it, how it is used, and whether it can be renewed without interrupting production.
Cloud workloads and services
Depending on scope, we review virtual machines, containers, Kubernetes, serverless, managed databases, API gateways, application services, images, registries, functions, and exposed services.
We do not attempt to audit the code of every application. We mainly check whether a compromised workload could reach more Cloud resources than necessary. For code or the application itself, see the application security audit.
Logging, monitoring, and detection
For AWS, we review CloudTrail, IAM logs, events, network logs, and available alerts. For Azure, we review Activity Logs, Entra, diagnostics, network logs, and available detection tools.
The organization should know who created, deleted, or changed a critical resource. We check that important events are recorded, centralized, and actually usable during an investigation.
Backups, recovery, and compromise resistance
We review snapshots, backups, retention, accounts used, production / backup separation, immutability where relevant, deletion access, restoration, replication, and restore tests.
An account that compromised production should not necessarily be able to delete the backups in the same operation. The existence of a backup is not enough if nobody has validated its restoration or isolation.
Who can change production?
The deployment pipeline is part of the security scope when it can create, change, or delete production resources. We review GitHub Actions, GitLab CI, Azure DevOps, Terraform, Bicep, CloudFormation, runners, deployment roles, approvals, and protected branches.
We check whether a compromised repository, exposed token, or poorly isolated runner could become indirect administrator access to the Cloud. Manual changes outside code are also identified because they make fixes difficult to review and reproduce.
The scenarios we aim to prevent
A developer account becomes a production administrator
An account is compromised. Overly broad permissions then let it reach production environments, secrets, or critical data. The audit checks whether roles and environment boundaries prevent this scenario.
A Cloud resource is exposed without the team knowing
A public IP, network rule, storage resource, or administration interface was added for a temporary need and left in place. The audit compares actual exposure with the intended architecture.
A provider retains critical access
A provider took part in a migration or project. Their account, role, or key can still change resources months later. We identify rights to remove, limit, or make temporary.
A compromised secret opens several environments
The same key or secret is reused across services or environments. A local leak can then become a much broader compromise.
Production and backups fail together
The same accounts have the rights needed to delete production data and its backups. The audit checks whether recovery remains viable when privileged access is compromised.
Cloud audit or global IT security audit?
A Cloud audit focuses on AWS and Azure environments: accounts, identities, networking, resources, data, workloads, secrets, logging, backups, and deployments. An IT security audit is broader and can also cover endpoints, internal networks, Active Directory, internal applications, providers, and technical organization.
When Cloud is only one part of a large hybrid environment, the two scopes can be combined. The global IT security audit remains the transverse entry point.
How does a Cloud security audit run?
01 — Environment scoping
A 45-to-60-minute discussion with the CTO, CIO, CISO, Cloud lead, DevOps, and where needed a provider identifies providers, AWS accounts, Azure subscriptions, environments, critical applications, data, teams, and production constraints.
02 — Inventory and read-only access
We gather architecture, accounts, resources, IAM policies, networking, configurations, logs, infrastructure repositories, pipelines, and backups. Read-only access or audit-specific roles are preferred.
03 — Analysis of the actual configuration
We compare the expected architecture with what is actually deployed and review permissions, exposure, segmentation, secrets, data, logs, workloads, backups, and pipelines. Conclusions do not rely only on an automated scanner.
04 — Compromise-path analysis
We connect findings: an old provider account, a permissive role, access to secrets, and production deployment can form a critical scenario. An individually moderate configuration can become critical when combined with other permissions.
05 — Debrief and roadmap
A 60-to-90-minute meeting presents priority risks, affected resources, scenarios, quick wins, structural workstreams, dependencies, and delivery order.
How long does an AWS or Azure audit take?
A Cloud security audit of a mid-sized environment usually represents around 8 to 12 business days of work, spread across two to three calendar weeks.
The workload depends on the number of AWS accounts, Azure subscriptions, environments, workloads, regions, interconnections, pipelines, Kubernetes clusters, providers, and documentation quality. A very broad scope can be split by account, domain, or criticality.
What do you receive after the audit?
Leadership summary
The main exposures, critical scenarios, potential impacts, decisions required, and priorities, without reducing the summary to AWS or Azure terminology.
Map of critical resources
Environments, accounts or subscriptions, data, critical workloads, privileged access, and main connections, at a level of detail useful for decisions.
Risk matrix
For each finding: environment, resource, risk, scenario, exposure, impact, priority, and proposed fix.
IAM and sensitive access review
We identify privileged accounts and overly broad roles, persistent keys, provider or cross-environment access, and permissions able to change production or access data.
Remediation roadmap
Immediate: close critical exposure, remove obsolete access, and protect administrator accounts. Within 30 days: address permissions, segmentation, storage, pipelines, and logs. Within 60 days: structure IAM, environment separation, Infrastructure as Code, and centralized logging. Within 90 days and beyond: implement the target architecture and automate structural controls.
Actionable backlog
Each action can become a task with priority, owner, indicative effort, dependencies, and expected validation.
What does the analysis rely on?
The analysis relies in particular on AWS and Microsoft best practices applicable to the audited environment. For AWS, we can use the AWS Well-Architected Framework Security Pillar areas: identity management, detection, infrastructure protection, data protection, incident response, and application security.
For Azure, we can use the Azure Well-Architected Framework Security recommendations: segmentation, identity, network controls, data protection, monitoring, detection, and workload security. CIS Benchmarks or CIS Controls can complement the review where relevant.
These are working references, not an AWS, Microsoft, CIS, or ANSSI certified audit.
What you should know after the audit
After the audit, the organization should know which accounts can administer the Cloud, which resources are reachable from the Internet, and which providers still have access. It should also be able to verify whether production and development are separated enough.
The debrief should finally answer three questions: could a compromise reach sensitive data, would backups survive an administrative compromise, and is the pipeline itself a privileged access path? Immediate fixes can then be tied clearly to these risks.
How can the environment be secured after the audit?
Koragence can then take on remediation under a separate scope: IAM, MFA, SSO, roles, service accounts, persistent keys, environment separation, private networking, Security Groups / NSGs, secrets, storage, encryption, pipelines, Terraform, backups, logs, alerts, and workload hardening.
Access and Cloud infrastructure hardening covers remediation. Operating and maintaining Cloud infrastructure then belongs to the DevOps and infrastructure scope.
When should AWS or Azure be audited?
The engagement is aimed at structured SMEs, mid-sized companies, B2B scale-ups, groups, critical SaaS products, and business platforms with several accounts, subscriptions, teams, providers, or environments. It is not aimed at a WordPress site on one isolated VM.
The audit is particularly relevant when the infrastructure grew quickly or through several providers, when several AWS accounts, Azure subscriptions, or Cloud teams coexist, or when a new CTO, CIO, or CISO joins.
It is also useful before due diligence, fundraising, a new customer, or a critical service launch, as well as during a Cloud migration, environment merger, infrastructure takeover, unclear secret ownership, or a mix of automated and manual changes.
