Cloud App and Config Profile Certification for AWS, Azure, and Google Cloud

• Cloud App and Config Profile is an App Defense Alliance (ADA) assessment profile that validates the security configuration and architecture of cloud-hosted applications running on AWS, Azure, and Google Cloud.
• The profile evaluates identity and access management (IAM), logging and monitoring, network segmentation, compute hardening, storage and database configuration, encryption (at rest and in transit), patching cadence, and configuration baselines against provider-native and industry benchmarks (primarily CIS Benchmarks, supplemented by OWASP ASVS for application-layer controls and OWASP MASVS where mobile clients consume the cloud backend).
• Assessment is performed by an ADA Authorized Lab; ValueMentor’s current authorization scope for this profile should be verified against the ADA Authorized Labs directory before you scope work with any assessor, including us.
• A single assessment engagement scopes specific in-scope services, accounts/subscriptions/projects, and environments — it does not extend automatically to future releases, unscoped accounts, or services added after the assessment window closes.
• Engineering teams should expect evidence-pack submission, control-by-control review, and validation testing, not a one-time document upload.

If you’re staring down an ADA Cloud App and Config Profile requirement and need to know exactly what your AWS, Azure, or GCP environment will be tested against, this breaks down the control surface, the evidence you’ll be asked to produce, and where teams typically lose time during review.
Not sure what’s actually in scope for your environment? Request a cloud assessment scoping call — you’ll get a preliminary breakdown of which accounts, services, and control domains apply to your architecture before any formal engagement starts.

Cloud security failures are rarely caused by sophisticated zero-day exploits—they’re far more likely to result from misconfigured identities, excessive permissions, exposed resources, or overlooked configuration changes. As cloud environments grow across AWS, Azure, and Google Cloud, maintaining a secure and consistent security posture becomes increasingly complex.

The App Defense Alliance’s (ADA) Cloud App and Config Profile helps organizations validate that their cloud infrastructure is configured according to recognized security best practices. This blog explains what the assessment covers, how AL1 and AL2 differ, the critical control domains evaluated, and how teams can prepare their cloud environments for a successful assessment.

What the Cloud App and Config Profile Actually Evaluates

The Cloud App and Config Profile sits within ADA’s broader certification structure alongside the Mobile Application Security Assessment (MASA) and other app-focused profiles, but its scope is the cloud infrastructure and configuration layer an application runs on — not just the application code itself. Per the ADA Cloud App and Config Specification, this includes the provider account/project structure, the identity model, network topology, and the configuration state of the services the application depends on.
This is a provider-agnostic control set mapped onto three different provider consoles and APIs — AWS, Azure, and Google Cloud — each with different default postures, different IAM primitives (IAM policies vs. Azure RBAC vs. GCP IAM roles/conditions), and different native logging services (CloudTrail vs. Azure Monitor/Activity Log vs. Cloud Audit Logs). A control that reads as one line in the ADA specification often maps to a materially different technical implementation depending on which provider is in scope.

Assurance Level 1 (AL1) vs. Assurance Level 2 (AL2)

• AL1 is a verified self-assessment. The development team completes a structured questionnaire and submits required automated scan artifacts — configuration scanner output, IAM policy exports, logging configuration exports — which the assessor reviews for completeness, internal consistency, and alignment with the claimed architecture. AL1 is not “documentation only”; the scan artifacts have to actually reflect the live environment, and inconsistencies between the questionnaire and the artifacts are a common source of rework.
• AL2 adds in-depth, hands-on lab verification. The assessor independently queries the cloud environment (read-only, scoped credentials), runs configuration audits directly against live resources, and validates that the control implementation matches what was claimed at AL1 — including spot-checking IAM policy attachments, network ACLs/security groups/NSGs, and encryption configuration on the actual resources rather than relying solely on submitted exports.

Across cloud configuration assessments generally, one of the more frequent gaps assessors flag at the IAM layer is **overly broad managed policies or built-in roles attached at the account/subscription/project level** rather than scoped custom policies — for example, AdministratorAccess-equivalent grants issued to CI/CD service principals that only need write access to a single storage bucket or resource group. This pattern tends to surface during AL2 hands-on review even when AL1 questionnaire responses describe least-privilege intent, because the questionnaire reflects design intent while the live IAM state reflects what was actually deployed.

Control Domains and What Assessors Actually Test

The specification groups controls into functional domains. Below is a mapping of the domains most commonly scoped for AWS/Azure/GCP application backends, what the assessor is actually checking, and the evidence that should be prepared before the engagement starts.

Assessment area	Relevant requirement or control	What the assessor tests or reviews	Evidence the development team should provide	Common failure pattern	Recommended pre-assessment action
Identity & Access Management	Least-privilege access, no standing root/global-admin use, MFA on privileged accounts	IAM policy/role exports, privileged account inventory, MFA enforcement config, service-account/service-principal scoping	AWS IAM policy JSON exports, Azure RBAC role assignments, GCP IAM bindings, MFA policy screenshots or API exports	Wildcard (`\\\*:\\\*`) or built-in Owner/Contributor roles attached broadly instead of scoped custom roles	Run an IAM policy audit (e.g., AWS IAM Access Analyzer, Azure AD Access Reviews, GCP Policy Analyzer) and remediate wildcard grants before submission
Logging & Monitoring	Centralized, tamper-evident audit logging covering control-plane and data-plane events	Logging service configuration, log retention settings, alerting rules tied to security-relevant events	CloudTrail/Config configuration export, Azure Monitor/Activity Log + diagnostic settings, GCP Cloud Audit Logs config, SIEM/alert routing evidence	Logging enabled for management events only, with data-plane events (e.g., S3 object access, Blob access, GCS access logs) disabled or unrouted	Confirm data-plane logging is enabled for all in-scope storage and database services, not just control-plane API calls
Network Segmentation	Restricted ingress/egress, no unnecessary public exposure of management interfaces or data stores	Security group/NSG/firewall rule exports, VPC/VNet topology, public IP inventory	Network diagrams, security group/NSG rule sets, results of internet-facing asset discovery (e.g., via port scan against known ranges)	Databases or admin interfaces (SSH/RDP/DB ports) reachable from `0.0.0.0/0` or equivalent broad CIDR ranges	Run an external attack-surface scan against in-scope CIDR ranges and close unnecessary public ingress before scoping
Compute Hardening	Patched OS/runtime images, disabled unused services, CIS Benchmark alignment on instance/container configuration	Golden image or base image manifests, patch management records, CIS Benchmark scan output for the relevant OS/container base	Image build pipeline evidence, patch cadence SLAs, CIS-CAT or equivalent benchmark scan reports	Long-lived, manually patched instances outside the golden-image pipeline that drift from the hardened baseline over time	Run a CIS Benchmark scan (CIS-CAT Pro, or cloud-native equivalents like AWS Inspector, Azure Defender, GCP Security Command Center) against representative in-scope compute
Storage & Database Configuration	No public read/write on data stores, encryption enabled, access logging on	Bucket/container/database ACL and policy exports, encryption-at-rest settings, public access block configuration	S3 bucket policy + public access block config, Azure Storage account network rules, GCS bucket IAM + public access prevention settings	Storage buckets or database snapshots left publicly accessible for cross-team convenience during development, never re-locked down	Run a public-exposure scan across all in-scope storage and database resources (e.g., AWS S3 Public Access, Azure Storage public network access, GCP Bucket public IAM)
Encryption (In Transit & At Rest)	TLS enforced for data in transit, provider-managed or customer-managed keys for data at rest	TLS configuration/cipher suite audit, KMS/Key Vault/Cloud KMS key policy review	TLS scan results (e.g., via `testssl.sh` or provider load balancer TLS policy config), KMS key policy exports	TLS termination at the load balancer with unencrypted traffic between internal services or nodes	Confirm end-to-end encryption for any in-scope service handling sensitive data, not just edge/ingress TLS
Patch & Vulnerability Management	Defined patch SLAs, vulnerability scanning coverage across in-scope assets	Vulnerability scan coverage reports, patch SLA documentation, remediation tracking records	Scan coverage reports (e.g., AWS Inspector, Azure Defender for Cloud, GCP Security Command Center), ticketing evidence of remediation timelines	Vulnerability scanning covers production compute but excludes ephemeral or auto-scaled resources, creating blind spots	Confirm scan coverage includes auto-scaling groups, ephemeral containers, and serverless functions, not just static instance inventories
Configuration Baseline Drift	Ongoing conformance to declared baseline, not just point-in-time compliance	Infrastructure-as-code (IaC) source, drift detection tooling output, change management records	Terraform/CloudFormation/Bicep/ARM templates, drift detection reports (e.g., AWS Config rules, Azure Policy compliance state, GCP Config Validator)	Manual console changes made outside the IaC pipeline that silently drift the live environment away from the declared baseline	Enable and review drift detection (AWS Config, Azure Policy, GCP Config Validator/Forseti) for at least 30 days prior to assessment

Technical Testing Vectors Referenced During Review

Assessors evaluating a Cloud App and Config Profile scope typically pull from a combination of:

• Configuration audits run directly against cloud provider APIs (read-only, scoped credentials) — the primary mechanism for both AL1 artifact verification and AL2 hands-on testing.
• Static analysis (SAST) where application code interacts directly with cloud SDKs (e.g., hardcoded credentials, insecure deserialization in Lambda/Function code, IAM policy generation logic embedded in application code).
• Dynamic analysis (DAST) against any application-layer endpoints exposed through the cloud environment, scoped under OWASP ASVS for web application controls.
• Mobile-specific testing under OWASP MASVS, only where a mobile client consumes the cloud backend being assessed — this is a common overlap point when a Cloud App and Config Profile assessment runs alongside a separate mobile app assessment.
• CIS Benchmark conformance scanning for the specific OS, container runtime, and managed service configurations in scope.

Multi-provider environments (an application with primary infrastructure on AWS but a data warehouse or analytics workload on GCP, for example) are one of the more common sources of scoping ambiguity. Assessors need explicit confirmation of which provider-specific services are in scope, because control implementation details — and often the evidence format itself — differ meaningfully across CloudTrail exports, Azure Activity Logs, and GCP Audit Logs, even when the underlying control requirement (centralized audit logging) is identical.

Already have IaC and provider exports ready but unsure how they map to ADA’s control language? Request an evidence-pack review — this walks through what you already have against the profile’s control set and flags gaps before formal submission, so you’re not discovering mapping issues mid-assessment.

Multi-Cloud Scoping: Addressing the Common Objections

Three objections come up consistently when teams first look at this profile:

Our environment is multi-provider and complex

The profile’s control language is provider-agnostic by design, but scoping has to be provider-specific in practice. A defensible scoping exercise identifies every account, subscription, or project touching the in-scope application, and maps each one to the relevant provider-native evidence sources before testing begins — not during it.

We don’t know what’s actually in scope

Scope is defined by what the application depends on operationally: the compute running it, the data stores it reads/writes, the IAM principals with access to those resources, and the network path between them. Shadow infrastructure — forgotten dev/test accounts, orphaned service accounts, unmanaged S3 buckets from earlier project phases — is a frequent source of scope creep discovered mid-assessment rather than before it.

We can’t disrupt production

Configuration audits and evidence review are non-invasive by nature; they query configuration state and logs rather than executing exploit attempts against production systems. Any dynamic testing component (DAST) against live application endpoints should be scoped and scheduled explicitly, with rate limits and testing windows agreed upon in advance — this is a standard scoping conversation, not something that should surprise engineering teams once testing starts.

Conclusion

Strong cloud security isn’t achieved through one-time configuration reviews it’s built on continuous visibility, governance, and validation. The Cloud App and Config Profile provides organizations with a structured way to demonstrate that their cloud environments are configured securely and managed consistently across providers.

Whether your workloads run on AWS, Azure, Google Cloud, or a combination of all three, preparing for the assessment starts with understanding your architecture, validating critical controls, and eliminating configuration gaps before they become security risks. ValueMentor helps organizations navigate this process through cloud security assessments, evidence validation, and expert guidance that accelerates assessment readiness while strengthening long-term cloud resilience.

Frequently Asked Questions

Getting Your Environment Assessment-Ready

Passing review on the Cloud App and Config Profile isn’t primarily a documentation exercise — it’s a question of whether your live AWS, Azure, or GCP configuration actually matches what your team believes it looks like. The gap between declared architecture and deployed reality is where most engagements lose time, particularly at the IAM and network segmentation layers.

If you’re heading into a scoping conversation and need architecture-aware coverage across a multi-provider environment — IAM, logging, network, compute, storage, database, encryption, patching, and baseline drift, mapped consistently across AWS, Azure, and Google Cloud without guessing at provider-specific evidence formats — request a cloud assessment scoping call. You’ll walk away with a preliminary scope breakdown covering which accounts and control domains apply to your architecture, and a tailored quote for the readiness assessment, evidence-pack review, and certification workflow support relevant to your environment.