What to Expect from a Cloud Security Architecture Engagement

The engagement begins with a discovery session, typically a 60- to 90-minute call with your engineering leads, cloud architects, and security team (if you have one). The assessors need to understand your cloud footprint: which providers and accounts you use, how environments are structured (production, staging, development), what workloads run where, and what compliance requirements apply. This is not an interrogation. It is a collaborative conversation to ensure the assessment focuses on the areas that matter most to your organization.

After discovery, the team defines the scope: which accounts, subscriptions, or projects are in scope, and which security domains will be assessed. A typical engagement covers all eight domains (identity, network, data protection, compute, logging, incident response, governance, and CI/CD), but the depth of coverage may vary based on your priorities. If you are preparing for SOC 2, the governance and logging domains may receive extra attention. If you recently experienced an incident, incident response readiness and network architecture may be emphasized.

The final step in Phase 1 is provisioning read-only access. The assessment team needs read-only access to your cloud environments to run automated scanning tools and manually inspect configurations. In AWS, this typically means creating a cross-account IAM role with the SecurityAudit and ViewOnlyAccess managed policies. In Azure, it means assigning the Reader role at the subscription level. In GCP, it means granting the Viewer role at the project or organization level. This access is time-limited and revoked at the end of the engagement.

Phase 2 is the core of the engagement. The assessment team runs automated scanning tools against your environment to establish a configuration baseline. These tools evaluate your configurations against CIS Benchmarks, cloud provider best practices, and the team's proprietary rule sets. Automated scanning is fast and comprehensive but produces raw data that requires human interpretation. A typical scan of a moderately complex AWS environment produces hundreds of findings, many of which are false positives, informational, or low-severity items that do not warrant immediate attention.

The manual analysis component is where the value of an architecture review becomes apparent. Assessors review your VPC architecture diagrams, IAM policies, trust relationships, logging pipelines, and deployment processes. They look for design patterns that automated tools cannot evaluate: Does your account structure isolate blast radius effectively? Can an attacker who compromises one service account escalate to administrative access? Does your network architecture allow lateral movement between environments? Are your security controls resilient to the failure or compromise of a single component?

During this phase, the assessment team may schedule follow-up calls to clarify design decisions, understand operational processes, or discuss specific findings. These conversations are essential: a configuration that appears insecure might be intentionally configured that way with compensating controls, or it might be a known gap that is already on the remediation roadmap. The assessors need this context to produce findings that are accurate and actionable.

In the final phase, the assessment team synthesizes automated scanning results, manual analysis findings, and contextual information from discussions with your team into a coherent set of findings and recommendations. Each finding is documented with a description, risk rating (Critical, High, Medium, Low, Informational), evidence, affected resources, and specific remediation guidance. Findings are not just configuration issues. They include architectural weaknesses, missing capabilities, and operational gaps.

The team then develops a remediation roadmap that organizes findings into actionable phases. Phase 1 of the roadmap addresses critical and high-severity findings that can be remediated quickly, typically within 30 days. These are your quick wins: enabling MFA for privileged accounts, restricting overly permissive security groups, or enabling audit logging in accounts where it is missing. Phase 2 addresses medium-severity findings and more complex changes over 60 to 90 days. Phase 3 covers architectural changes that require planning, design, and potentially budget approval, such as redesigning your account structure or implementing a centralized logging architecture.

The engagement concludes with a readout session where the assessment team presents findings to both technical and executive stakeholders. The technical readout covers detailed findings and remediation guidance. The executive readout focuses on overall risk posture, the most critical gaps, and the investment needed to address them. After the readout, you receive all deliverables: the findings report, findings workbook, executive summary, and remediation roadmap. Most teams also schedule a follow-up call 30 to 60 days after delivery to answer questions that arise during remediation.

To maximize the value of the engagement, your team should prepare several things before kickoff. First, identify the stakeholders: who owns cloud architecture decisions, who manages IAM, who handles incident response, and who is the executive sponsor. The assessment team needs to talk to the right people, and chasing down the right contacts mid-engagement wastes time.

Second, prepare access. Create the read-only IAM roles or service principals before the engagement starts. Provision access to your CSPM tool dashboards, architecture documentation (even if it is outdated), and any existing security assessment reports. The more context the assessment team has, the faster they can focus on the issues that matter rather than spending time discovering what your environment looks like.

Third, be honest about what you already know is broken. Every organization has known security gaps that have not been addressed due to competing priorities, budget constraints, or technical debt. Sharing these upfront allows the assessment team to validate whether those gaps are as serious as you think, identify related issues you may not be aware of, and calibrate their findings to focus on issues that are genuinely new and actionable. An architecture review is not a test you pass or fail. It is a diagnostic tool that is most valuable when the patient is forthcoming about symptoms.