SEC-8 Tech Due Diligence

Tech Due Diligence SEC-8: Cloud Security and Network Architecture

What This Control Requires

The assessor evaluates cloud infrastructure security, including VPC/network configuration, security group rules, IAM policies, cloud service configuration hardening, and the overall network architecture security posture.

In Plain Language

Cloud misconfigurations are one of the leading causes of data breaches, and they are alarmingly common. Publicly accessible databases, overly permissive IAM policies, open storage buckets - these get created during rapid development and never cleaned up.

In a DD review, we examine how your cloud environment is actually configured rather than how you think it is configured. We look at VPC and network segmentation, security group and firewall rules, IAM policies and least privilege enforcement, cloud service hardening (storage buckets, databases, APIs), audit logging of cloud API calls (CloudTrail, Activity Log), and alignment with cloud provider security best practices like the AWS Well-Architected Framework or Azure Security Benchmark.

We are looking for evidence of deliberate, intentional cloud security practices. Default configurations and rules that accumulated over time without review are red flags that suggest security is not part of the infrastructure conversation.

How to Implement

Build a secure network architecture from the start. Use VPCs with public and private subnets. Databases, application servers, and internal services belong in private subnets. Only load balancers and bastion hosts should sit in public subnets. Apply network ACLs and security groups following least privilege.

Keep security group and firewall rules tight. Each group should allow only the specific ports and source IP ranges required for its function. Document the purpose of every rule. Audit regularly and remove anything no longer needed. Never allow 0.0.0.0/0 access to anything except public-facing load balancers on ports 80 and 443.

Get IAM right: use individual IAM users (no shared accounts), require MFA for all console access, enforce least privilege on all policies, use IAM roles rather than long-lived access keys for service-to-service authentication, implement permission boundaries, and regularly audit for unused permissions.

Lock down cloud storage. Make sure no buckets are publicly accessible unless they are intentionally serving public content. Enable server-side encryption, turn on access logging, block public access at the account level, and version important data for recovery.

Centralise cloud audit logging. Configure CloudTrail (AWS), Activity Log (Azure), or Audit Logs (GCP) to capture all API calls and store them in a tamper-resistant location. Set up alerts for high-risk activities like root account usage, IAM policy changes, and security group modifications.

Run cloud security posture management (CSPM) tools on a regular schedule. AWS Security Hub, Azure Defender for Cloud, or third-party tools like Prowler and ScoutSuite automatically assess your configuration against security benchmarks and surface misconfigurations.

Separate your environments into different accounts. Use distinct AWS accounts or Azure subscriptions for production, staging, and development. This limits blast radius and provides clean access control boundaries.

Evidence Your Auditor Will Request

Network architecture diagram showing VPC, subnets, and security groups
Security group and firewall rule audit results
IAM policy review showing least privilege implementation
Cloud security posture assessment report (CSPM tool output)
Cloud audit logging configuration and monitoring evidence

Common Mistakes

Databases or internal services accessible from the public internet
Overly permissive IAM policies (admin access, wildcard permissions)
Cloud storage buckets publicly accessible with sensitive data
Cloud API logging not enabled or not monitored
All environments (dev, staging, prod) in the same account with shared credentials

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.20	Related
SOC 2	CC6.6	Related

Frequently Asked Questions

Should we use a multi-cloud strategy?

For most companies, multi-cloud adds significant complexity without a proportionate benefit. A single cloud provider with solid architecture is typically viewed more favourably than a poorly executed multi-cloud setup. Multi-cloud makes sense for specific requirements like regulatory compliance, vendor risk management, or geographic coverage, but do not adopt it without a clear justification.

What cloud security benchmark should we follow?

Start with your cloud provider's own framework: AWS Well-Architected Security Pillar, Azure Security Benchmark, or GCP Security Best Practices. Layer on CIS Benchmarks for detailed configuration guidelines specific to your provider. These are well recognised in the industry and give comprehensive coverage that DD reviewers expect to see.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment