SOTI’s Nodir Safarov says cloud security gaps start in architecture, not tools

Cloud Architect Nodir Safarov, who leads migration and infrastructure automation for thousands of global clients at SOTI Inc., argues that many of the most common cloud security gaps begin long before security software is installed. In his view, the problem is architectural: the way systems are designed, migrated, and automated determines what can go wrong in production.

Safarov frames the issue with a reality most enterprises already feel in their bones. Enterprise cloud adoption has accelerated faster than enterprise cloud security. As organizations migrate critical workloads to AWS, Azure, and multi-cloud environments, they often carry forward architectural assumptions from earlier eras of computing. Those assumptions then collide with cloud-specific threats, cloud-native scaling, and the operational speed that cloud companies reward. The result is not just a few misconfigurations. It is entire classes of security holes that appear predictable in hindsight, because they were baked into the architecture from day one.

To understand why architecture matters, it helps to look at how cloud systems actually get built. Modern enterprise cloud stacks are assembled from building blocks: identity and access controls, network segmentation, workload configuration, data storage patterns, automation pipelines, and operational guardrails. Security tools can detect suspicious activity, but they cannot reliably compensate for a foundational design that never enforced boundaries in the first place. If the architecture allows “too much” access by default, or if it makes it easy to deploy workloads without consistent policy, then a security review later will feel like mopping a floor while the leak keeps running.

Safarov’s core message is that security gaps emerge when teams treat cloud adoption as a migration project first and a security design project second. The cloud gives you speed. But speed creates friction in governance, because architecture is where decisions get locked in. When architecture is done under tight timelines, teams tend to optimize for getting systems live, not for how those systems will behave under stress, failure, or adversarial conditions. And when you add multi-cloud, the complexity multiplies: the same workload might be deployed with different settings across environments, or protected unevenly, depending on how each platform was integrated into the broader enterprise architecture.

There is also a board-level incentive to move quickly. Enterprises do not choose AWS or Azure in a vacuum. They choose cloud because competitors moved, because cost structures shifted, and because customers expect faster delivery cycles. That urgency can push security to become a “checklist” activity, performed after the architecture is largely settled. Safarov’s emphasis on architectural failures challenges that approach. It suggests that the security posture that matters most is the one you establish through design principles, not just the one you bolt on through later tooling.

In regulatory and compliance terms, the architectural layer becomes even more important. While specific regulatory obligations vary by industry and jurisdiction, most frameworks converge on the same underlying themes: protect sensitive data, control access, maintain auditability, and demonstrate that security controls are consistent and effective. If architecture makes access control inconsistent or data handling ambiguous, later compensating controls can become hard to evidence, hard to sustain, and expensive to operationalize. In other words, architecture is not just an engineering concern. It is the substrate for compliance credibility.

There are second-order implications for enterprises beyond the immediate risk of breaches. If security gaps are rooted in architecture, then training, patch cycles, and even reconfigurations may help only temporarily. The underlying design patterns keep producing similar problems as the company scales and as new workloads are deployed. That means the operational cost of “fixing security repeatedly” tends to grow faster than the one-time cost of getting the architectural principles right early. For leaders responsible for migration and infrastructure automation, this is a direct message: automation should not just move workloads faster. It should encode the secure architecture that prevents predictable failures.

For other decision-makers wrestling with cloud migration, Safarov’s perspective is a strategic nudge. It is easier to secure a system when you control how it is designed, standardized, and deployed. When security gaps start at the architecture level, the path forward is not only selecting better tools. It is revisiting design principles, tightening the guardrails around automation, and making sure the cloud environments hosting critical workloads adhere to consistent security-by-design patterns across AWS, Azure, and multi-cloud deployments.

Bottom line: when enterprise cloud adoption outruns enterprise cloud security, architecture becomes the battleground. Nodir Safarov’s framing pushes organizations to treat security as a design constraint, not a post-migration patch, because that is where the most common cloud security gaps originate.