5 Cloud Architecture Changes That Should Trigger a Cloud Security Assessment

As SaaS companies scale, the infrastructure supporting their applications evolves, sometimes through major transitions that fundamentally change how systems, identities, and data interact. 

These changes can introduce security risks that weren't present in the original environment. New identities and permissions may be created, services may connect in unexpected ways, sensitive data may follow new paths, and security controls previously handled by a platform provider may shift to the engineering team.

For SaaS companies, the impact can be significant. Software Secured's aggregated production assessment data shows improper access control or missing authorization in roughly 65% of assessments. Cross-tenant access control was the leading authorization vulnerability, with Critical vulnerabilities observed in multiple multi-tenant platforms.

When an architecture changes substantially, the security assumptions behind the previous environment may no longer apply. That's why architecture transitions can trigger a new security assessment.

The Cloud Architecture Changes That Warrant a Secure Cloud Review 

1. You Migrated to a New Cloud Provider

Moving from AWS to Azure, Azure to GCP, or between other cloud environments can change more than where your application runs.

Each provider has different identity models, networking services, resource policies, logging capabilities, and security controls. Even if the application architecture stays largely the same, the supporting controls may not translate directly.

During a migration, teams should validate:

• IAM roles and service identities
• Production and non-production separation
• Network segmentation
• Public access to storage and databases
• Encryption and secrets management
• Logging and monitoring
• Administrative access
• Connections between services and environments

This is especially important when you rebuild infrastructure rather than migrate it directly. Recreating an environment can introduce differences that aren't obvious from the application layer.

For example, a storage resource that was private in the previous environment could be deployed with different access controls in the new one. An application service may also receive broader permissions during migration because the team is still determining which resources it needs.

A cloud security assessment after migration provides an independent validation of the deployed environment and its security controls.

2. You Moved From a Managed PaaS to Infrastructure You Control

Moving from a managed PaaS to AWS, Azure, or GCP changes the division of security responsibility.

On a highly managed platform, many infrastructure controls are abstracted away from the development team. Once the application moves onto infrastructure the company manages directly, the team may become responsible for networking, IAM, operating-system configuration, secrets, logging, backups, monitoring, and other controls.

Consider a SaaS company migrating from Scalingo to AWS. The security concern is not simply whether the new AWS environment is configured correctly, but whether the migration transferred responsibility for controls previously managed or abstracted by the PaaS. That makes this type of migration a particularly useful point for a security assessment.

What to review

The assessment should establish whether the controls that were previously provided by the managed platform now exist in an appropriate form within the company's own environment.

That includes checking:

• Who can administer infrastructure
• Which workloads can access which resources
• How secrets and credentials are managed
• Whether production resources are appropriately isolated
• Whether sensitive services are exposed to the internet
• Whether security events are logged and monitored
• Whether backups and recovery mechanisms are adequately protected

The larger the shift in operational responsibility, the more important this validation becomes.

3. You Broke a Monolith Into Microservices

Moving to microservices creates more than additional deployments. It creates additional identities, APIs, service relationships, and authorization decisions. A monolithic application might rely primarily on one application-level authorization model. A microservices architecture can introduce:

• Service-to-service authentication
• Separate service identities
• Internal APIs
• API gateways
• Message queues
• Multiple databases
• Service-specific permissions
• Additional network boundaries

This increases the number of relationships that need to be secured.

The privilege problem

A service may have access to another service because a particular workflow requires it. Over time, those relationships can become broader than necessary. The resulting risk can be a chain:

Compromised service → service identity → additional resource → higher privilege

In our experience, Broken Access Control is the highest-severity vulnerability category, and authorization is especially difficult to remediate because meaningful fixes often require changes to the underlying authorization model. A cloud security assessment can therefore examine service identities and permissions in the context of the architecture rather than evaluating them independently.

Architecture transitions need validation.

Vendelux illustrates why this matters. The company transitioned to a modern microservices architecture, increasing the complexity of its application environment. Software Secured subsequently performed comprehensive penetration testing to help identify and mitigate security risks associated with the more complex architecture.

Architectural modernization should include security validation as part of the transition, rather than treating it as a step to address after the new architecture is established.

4. You Adopted Containers or Kubernetes

Containers introduce another layer of infrastructure between the application and the underlying cloud environment. Kubernetes adds its own identity, authorization, networking, and workload-management controls.

A Kubernetes-based SaaS environment should be assessed for issues such as:

• Kubernetes RBAC
• Service account permissions
• Workload identity
• Secret access
• Network policies
• Namespace isolation
• Metadata service exposure
• Service account token automounting
• Cluster-to-cloud permissions
• Administrative access

The important consideration is what happens when a workload is compromised.

For example, an attacker who gains control of a container may be able to access its service account. If that identity has excessive permissions in the cloud environment, the initial compromise can become a pathway to other resources.

Configuration benchmarks are useful but limited.

Tools such as Prowler and ScoutSuite can provide valuable automated coverage of cloud configuration and benchmark controls. They help identify known configuration weaknesses across large environments. They don't, however, establish whether the architecture prevents a realistic compromise path.

That requires examining the relationships between workloads, identities, network controls, and cloud resources. A cloud security assessment should therefore use automated configuration analysis as one layer of the review, followed by manual validation of the relationships that could enable privilege escalation or lateral movement.

5. You Added a New Region or Went Multi-Cloud

Adding another region or cloud provider increases the number of environments you must secure consistently.

A second region can introduce another set of:

• IAM configurations
• Network controls
• Storage resources
• Encryption settings
• Secrets
• Logging configurations
• Service identities
• Administrative interfaces

Multi-cloud environments add another challenge: providers may implement similar security requirements differently.

Watch for security drift.

A security control that is correctly configured in one environment may be missing or implemented differently in another.

Examples include:

• Different IAM permissions between environments
• Inconsistent firewall rules
• Missing logging
• Publicly accessible resources
• Different encryption configurations
• Credentials shared across environments
• Inconsistent administrative controls

Infrastructure-as-code can reduce configuration drift, but it doesn't eliminate it. Templates can include overly broad permissions or insecure relationships, and manually configured resources can exist outside the deployment pipeline.

For that reason, security validation should ultimately focus on the deployed architecture, not just the infrastructure code.

What Does a Cloud Security Assessment Actually Validate?

The scope of a cloud security assessment should reflect the architecture being reviewed. For a SaaS environment, five areas matter most.

Identity and Access

Review human and machine identities, privileged accounts, service accounts, workload identities, role assignments, and cross-account or cross-project access.

The objective is to determine whether identities have appropriate access and whether a compromised identity could be used to gain additional privileges.

Network Boundaries

Assess public-facing resources, private networks, security groups, firewall rules, database access, administrative interfaces, and service-to-service connectivity.

The goal is to establish whether sensitive resources are appropriately isolated and whether unnecessary paths exist between environments or workloads.

Data and Secrets

Review storage exposure, databases, backups, snapshots, encryption, secrets management, and the movement of sensitive information between services.

For multi-tenant SaaS platforms, this should include the infrastructure supporting tenant isolation.

Detection and Response

Review logging, audit trails, monitoring, alerting, privileged activity visibility, and the organization's ability to detect and contain a compromise.

A secure architecture should provide enough visibility to investigate suspicious activity and respond when preventive controls fail.

Attack Paths

Finally, assess how an attacker could move through the environment after gaining an initial foothold.

For example:

Compromised workload → compromised identity → privilege escalation → access to another environment → sensitive data

This type of analysis connects individual configuration issues to their potential business impact.

Why a Cloud Security Assessment Complements a Pentest

A cloud security assessment and an application penetration test examine different layers of the SaaS environment.

An application penetration test focuses primarily on the application's attack surface, including:

• Authentication
• Authorization
• APIs
• Business logic
• Session management
• Tenant isolation
• Input handling

A cloud security assessment focuses on the infrastructure and identity layer supporting that application, including:

• Cloud IAM
• Accounts and projects
• Network architecture
• Storage
• Workload identities
• Kubernetes
• Cloud databases
• Secrets
• Logging
• Cross-environment access
• Detection and containment

There is some overlap, particularly around authorization and data access, but the assessments answer different questions.

Cross-tenant access control vulnerabilities, application logic bypasses, race conditions, and privilege escalation frequently require multiple sessions, concurrent testing, or an understanding of application workflows rather than straightforward automated scanning.

The same principle applies to cloud infrastructure. Knowing that an identity has access to a resource is useful. Understanding whether that access creates a realistic path to sensitive data or elevated privileges matters more. For SaaS companies undergoing major architectural changes, combining application and cloud security assessments can provide coverage across both layers.

How to Approach a Cloud Security Assessment After an Architecture Change

The timing of the assessment matters.

Ideally, security validation should happen once the new architecture is sufficiently representative of production but early enough that the engineering team can still make meaningful changes without major rework.

For a significant migration or architecture transition, the process can include:

1. Map the new architecture. Identify cloud accounts, projects, workloads, identities, networks, data stores, and external integrations.
2. Review security controls. Assess IAM, segmentation, encryption, secrets, logging, monitoring, and other relevant controls.
3. Identify realistic attack paths. Determine what an attacker could reach from compromised workloads, identities, or exposed services.
4. Manually validate important relationships. Test areas where configuration alone cannot establish whether the architecture is secure.
5. Prioritize remediation. Focus on vulnerabilities based on their potential impact and ease of exploitation.
6. Retest critical changes. Verify that significant vulnerabilities have been properly addressed.

This approach helps turn an architecture review into an actionable security assessment rather than a list of configuration observations.

Frequently Asked Questions

When should a SaaS company get a cloud security assessment?

The strongest triggers are significant architecture changes that affect identity, access, networking, data flows, workload security, tenant isolation, or security ownership.

Common examples include cloud migrations, moving away from managed PaaS, adopting microservices or Kubernetes, and expanding into new regions or cloud providers.

Is a cloud security assessment the same as a CSPM scan?

No. CSPM tools can identify cloud configuration issues against security policies and benchmarks. A cloud security assessment can incorporate those tools while also evaluating identity relationships, network boundaries, privilege escalation paths, and other architectural risks.

Do I need a cloud security assessment if I already perform annual penetration testing?

It depends on what the penetration test covers.

An application pentest does not necessarily assess the underlying cloud environment, IAM configuration, workload identities, cloud networking, or cross-environment relationships. If those areas changed substantially since the last assessment, additional cloud-focused testing may be appropriate.

Does moving to a new cloud provider automatically require a full assessment?

Not always. The scope should reflect the scale and nature of the migration.

A migration that changes only a small isolated component may require targeted validation. A migration that changes IAM, networking, workload architecture, data storage, or security ownership presents a much stronger case for a comprehensive assessment.

Conclusion

Cloud security should evolve alongside the architecture it protects.

A new cloud provider, PaaS migration, microservices deployment, Kubernetes environment, or additional region can introduce new identities, permissions, connections, and responsibilities that weren't present when the previous security assessment was performed.

Software Secured's data shows that some of the most consequential vulnerabilities (particularly authorization and tenant-isolation issues) are closely tied to how applications and their supporting infrastructure are designed. Across approximately 45 SaaS assessments, the average assessment contained roughly 20–30 vulnerabilities, including approximately 2–5 Critical and 4–9 High vulnerabilities.

For SaaS companies, the practical rule is straightforward:

When a major architecture change alters how identities, workloads, networks, or data interact, reassess the security model before those new relationships become permanent.