Why a network security policy matters more than founders think
Most SaaS founders write off network security as “we’re on AWS, security groups handle it.” That’s a misunderstanding of what auditors and frameworks actually require. ISO 27001 A.8.20–A.8.23 are not optional opinions — they are required controls. SOC 2 CC6.6 (logical access from outside boundaries) is tested in every audit. PCI DSS v4.0 Req 1 mandates a documented firewall policy with formal change management. NIS2 Art. 21(2)(b) lists network security as a mandatory cybersecurity risk management measure.
Security groups exist. That doesn’t mean you have a network security policy. The policy is the document that says: what your firewall stance is, how rules are reviewed, who approves changes, how segmentation works, what counts as remote access, and how you detect anomalies. Auditors want to see the policy and the evidence it’s followed.
Compliance requirements for network security
| Framework | Requirement | What you need to document | Audit evidence |
|---|---|---|---|
| ISO 27001 | A.8.20 — Networks Security | Documented network security controls including perimeter, segmentation, and monitoring | Network security policy + firewall rule export |
| ISO 27001 | A.8.21 — Security of Network Services | Security mechanisms and SLAs for third-party network services | Vendor contracts, service descriptions |
| ISO 27001 | A.8.22 — Segregation of Networks | Networks segregated by sensitivity, function, and user groups | Architecture diagram + VPC/subnet configuration |
| ISO 27001 | A.8.23 — Web Filtering | Outbound web access restricted to reduce malware risk | DNS filtering logs, WAF dashboard |
| SOC 2 | CC6.6 — Logical Access from External Boundaries | Access from outside the network protected by firewall, VPN/ZTNA, and MFA | Remote access policy, VPN/ZTNA config, MFA enforcement |
| SOC 2 | CC6.7 — Transmission of Confidential Information | Transmission restricted and encrypted on untrusted networks | TLS configuration, encryption-in-transit standard |
| PCI DSS v4.0 | Req 1 — Network Security Controls | Formal firewall configuration standards; quarterly rule review | Firewall standards doc + rule review records |
| NIS2 | Art. 21(2)(b) | Network security as risk management measure | Documented policy, board-approved |
“We’re cloud-native” is not an exemption
Some founders argue that because they don’t run physical firewalls, the firewall policy doesn’t apply. Auditors disagree. AWS Security Groups, GCP Firewall Rules, and Azure NSGs are firewalls. They need the same rigour: documented standards, default-deny inbound, change management, quarterly review, and IaC-managed.
The cloud-native checklist:
- Default-deny inbound everywhere. If a port isn’t explicitly allowed, it’s denied. No “temporary” 0.0.0.0/0 SSH access that nobody removed.
- Rules in version control (Terraform / CDK / Pulumi). Click-ops in production is prohibited. Every change is a PR with reviewer approval.
- Separation per environment. Production security groups are not shared with staging. Cross-environment rules are explicitly justified.
- Quarterly rule review. A list of all rules, who owns each, when it was added, and whether it’s still needed. Stale rules are removed.
- No direct internet ingress to backend systems. Databases, internal services, admin planes — private subnet only.
Network segmentation for SaaS
Segmentation is the difference between “we had a breach” and “we had a breach and they got everything.” If your production database is on the same subnet as your build server, you’re one CI compromise away from a data exfiltration headline.
The minimum SaaS segmentation pattern:
| Zone | Examples | Inbound | Outbound |
|---|---|---|---|
| Public / DMZ | Load balancers, CDN edge, public APIs | Internet → LB on 443 | App tier only |
| Application tier | API servers, web servers, workers | DMZ + admin plane only | Data tier + internet egress (allowlisted) |
| Data tier | Databases, caches, object stores | App tier only | Deny all (or strict allowlist) |
| Management plane | CI/CD, monitoring, SIEM | Privileged users via bastion / ZTNA | Strict allowlist |
| Dev / Staging | Pre-production environments | Isolated from prod entirely | No prod data, no prod connections |
PCI DSS CDE isolation: if you process cardholder data, the cardholder data environment must be physically or logically isolated from out-of-scope networks. Annual (or more frequent if PCI DSS v4.0 Req 11.4.5 applies to you) segmentation penetration testing is required.
Remote access: VPN vs ZTNA
Remote access has moved from “VPN into the corporate network” to “verify identity and device, then grant least-privilege access to a specific resource.” Both are legitimate; what auditors want is documentation of which method is used for which access.
| Capability | VPN | ZTNA |
|---|---|---|
| Trust model | Authenticated user trusted on internal network | Continuous per-request verification |
| Lateral movement risk | High once on network | Low — access limited to authorised resources only |
| User experience | Client install, connection drops | Browser or lightweight agent, transparent |
| Implementation complexity | Moderate | Low for cloud-native (Cloudflare Access, Tailscale, AWS Verified Access) |
| Auditor evidence | VPN logs, MFA enforcement | Access logs per resource + device posture |
SOC 2 CC6.6 expectation: remote access requires MFA. PCI DSS v4.0 Req 8.4.3: MFA is required for all remote access into the CDE, regardless of origin. Device posture checks (encryption on, EDR running, OS patched) before granting access are increasingly expected by enterprise customers in security questionnaires.
Zero Trust isn’t a product — it’s a posture
Vendors will sell you “Zero Trust” as a SKU. It isn’t. Zero Trust is the principle that network location no longer determines trust. Practical implementations for small SaaS:
- Identity as the perimeter. Every request authenticated; IdP (Okta, Google Workspace, Entra ID) is the source of truth.
- Device posture matters. MDM-enrolled, encrypted, patched, EDR-installed devices only.
- Application-level access controls. Even if someone is on the corporate network, they don’t implicitly access production.
- Service-to-service authentication. mTLS via service mesh or signed JWTs — not “it’s on the same VPC, must be safe.”
- Continuous verification. Sessions revoked when device posture drops; conditional access policies enforce this.
You don’t need to be “fully Zero Trust” to claim progress. A maturity model with documented next steps is what auditors and enterprise procurement teams accept.
Network monitoring: what auditors actually look for
SOC 2 CC7.1 and ISO 27001 A.8.15/A.8.16 require monitoring. For network security, that means:
- Flow logging enabled in all VPCs. VPC Flow Logs (AWS), VPC Flow Logs (GCP), NSG Flow Logs (Azure). Ingested into a SIEM, log management tool, or at minimum stored in S3 / GCS with lifecycle policy.
- Cloud-native threat detection. AWS GuardDuty, GCP Security Command Center, Azure Defender. These catch known indicators (Tor exits, cryptominer C2, brute-force patterns) without you writing rules.
- Alerts on unexpected open ports. Continuous external scan of public IP ranges — if a new service goes live on port 8080 unexpectedly, alert.
- Egress monitoring. Outbound connections to known-bad destinations are a stronger signal than inbound noise.
- Firewall change events. Every security group / NSG change is logged and reviewed. Unauthorised changes trigger an incident.
DDoS protection: not optional under NIS2
NIS2 Art. 21(2)(b) requires measures to ensure the availability of network and information systems. Translation: you need a documented DDoS protection strategy. For most SaaS:
- Cloud provider native DDoS protection (AWS Shield Standard, GCP Cloud Armor, Azure DDoS Basic) is free and on by default. Document it.
- Add CloudFront / CloudFlare / Fastly in front for application-layer (L7) protection and rate limiting.
- API gateway rate limiting per IP, per API key, per route. This catches most credential-stuffing, scraping, and small DDoS attempts.
- DDoS response playbook: who decides to escalate to Shield Advanced / CloudFlare Magic Transit; who notifies customers; what status-page communication looks like.
The minimum viable network security policy (10 items)
- Documented firewall configuration standards (default-deny, IaC-managed, change-managed).
- Network segmentation: prod isolated from dev/staging, data tier private, management plane separated.
- Remote access: VPN or ZTNA with MFA; no direct SSH/RDP to production from the internet.
- WAF on all public-facing applications with OWASP Top 10 rules.
- TLS 1.2 minimum (1.3 preferred) for all inbound and outbound; HSTS on customer-facing endpoints.
- DNS filtering for outbound queries; DNSSEC for authoritative zones.
- Cloud-native threat detection enabled (GuardDuty / Defender / SCC).
- Quarterly firewall rule review with documented justification.
- External vulnerability scanning at least quarterly; critical findings remediated within 24–48 hours.
- Documented DDoS protection posture and response plan.
What good looks like at audit
A clean SOC 2 or ISO 27001 audit on network security typically involves:
- The network security policy itself, board-approved with a current version date.
- An architecture diagram showing zones, segmentation, and trust boundaries.
- A current firewall rule export with owner and last-review date per rule.
- Evidence of the most recent quarterly rule review (signed off).
- Remote access logs showing MFA enforcement.
- Sample VPC flow log queries demonstrating detection capability.
- The last external vulnerability scan report and remediation tracker.
Generate your network security stack: Network Security Policy Generator, Remote Work Security Policy, Password & Authentication Policy, Access Control Policy, Information Security Policy, Log Management Policy.
Related reading: Zero Trust Network Access for SaaS, Remote Work Security Policy Guide, Access Control Policy Guide, Vulnerability Management Policy Guide, ISO 27001 Annex A Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Network architecture and applicable controls depend on your specific environment, risk profile, and regulatory scope. Engage a qualified security professional for implementation guidance tailored to your organisation.