What is ISO 27001 Annex A 8.20 – Network Security?
ISO 27001 Annex A 8.20 requires organizations to secure, manage, and control their networks and network devices.
Networks connect:
- Employees
- Servers
- Applications
- Databases
- Cloud environments
- Customers
- Suppliers
- Remote workers
- Security systems
- Internet services
- Third-party services
If network security is weak, an attacker may be able to move from one compromised system to another, access sensitive information, intercept communications, or disrupt business operations.
Simple explanation:
Control who and what can connect to your network, where they can connect from, what they can access, and how network activity is protected and monitored.
Why is Annex A 8.20 Important?
A modern company’s network is no longer limited to an office LAN.
For a startup, the network may include:
- AWS/Azure/GCP
- Corporate Wi-Fi
- VPN
- Cloud VPC/VNet
- Firewalls
- Load balancers
- Kubernetes networks
- Databases
- Employee laptops
- SaaS platforms
- APIs
- Internet-facing applications
- Remote employees
- Third-party connections
A weakness in one area can create a path to another system.
Common network security risks
| Risk | Example |
|---|---|
| Unauthorized access | Unknown device connects to corporate network |
| Network intrusion | Attacker exploits an exposed service |
| Lateral movement | Compromised laptop reaches production database |
| Data interception | Sensitive traffic is transmitted insecurely |
| Misconfiguration | Firewall allows unnecessary internet access |
| Exposed services | Database is directly accessible from the internet |
| Weak segmentation | Development and production systems share the same network |
| Rogue devices | Unknown equipment connects to the network |
| Denial of service | Network resources become unavailable |
| Unauthorized remote access | VPN or remote service is poorly secured |
Simple principle:
A secure network does not simply connect systems—it controls and limits how systems can communicate.
What Does ISO 27001 Annex A 8.20 Require?
The organization should implement controls to protect its networks and network devices.
The controls should address risks associated with:
- Network architecture
- Network access
- Network devices
- Network services
- Internal communication
- External communication
- Remote access
- Cloud networking
- Wireless networks
- Network administration
- Network monitoring
- Network configuration
- Network availability
The controls should be proportionate to the organization’s risks.
ISO 27001 does not require every organization to purchase a particular firewall, VPN, SIEM, IDS, or network-security product.
The organization should determine appropriate controls based on its:
- Risk assessment
- Architecture
- Business requirements
- Data sensitivity
- System criticality
- Regulatory obligations
- Customer requirements
- Threat environment
What Are Network Controls?
Network controls are technical and administrative measures used to protect communication between systems.
Examples include:
- Firewalls
- Network access control
- Security groups
- Network segmentation
- VPN
- Zero Trust controls
- Secure remote access
- Intrusion detection
- Intrusion prevention
- Network monitoring
- Secure protocols
- DNS security
- Wireless security
- Routing controls
- Access control lists
- Cloud network controls
- Network configuration management
Network Security in a Modern Startup
A traditional office-based company might have:
Internet
↓
Firewall
↓
Corporate Network
↓
Servers
A SaaS startup may instead have:
Internet
↓
Cloud Load Balancer / WAF
↓
Application
↓
Private Services
↓
Database
Alongside:
Employees → Identity Provider → SaaS Applications
and:
Developers → VPN / Zero Trust → Cloud Environment
Therefore, Annex A 8.20 should be applied to the organization’s actual architecture, not just its office network.
Activities Required to Implement Annex A 8.20
Step 1: Identify Your Network Environment
Document important network components.
For example:
| Component | Environment | Purpose | Criticality |
|---|---|---|---|
| Cloud VPC | AWS | Production network | Critical |
| Firewall | Corporate | Network protection | High |
| VPN | Corporate | Remote access | High |
| Corporate Wi-Fi | Office | Employee connectivity | Medium |
| Load Balancer | Cloud | Application access | Critical |
| Security Groups | Cloud | Traffic control | Critical |
The inventory should connect with your asset inventory under Annex A 5.9.
Step 2: Create a Network Architecture
The organization should understand how systems communicate.
A simplified SaaS architecture may look like:
Internet
↓
DNS
↓
WAF / Load Balancer
↓
Web/Application Layer
↓
Internal Services
↓
Database
The database should generally not need to be directly exposed to the public internet.
Step 3: Identify Network Trust Zones
Consider separating systems based on their security requirements.
For example:
Zone 1 – Internet
Public users and external traffic.
Zone 2 – Public Application Layer
Internet-facing application components.
Zone 3 – Internal Services
Internal application services.
Zone 4 – Restricted Data Layer
Databases and sensitive information.
Zone 5 – Administration
Privileged administration systems.
Zone 6 – Corporate User Network
Employee endpoints.
This reduces unnecessary communication between systems.
Step 4: Implement Network Segmentation
Network segmentation limits how systems can communicate.
For example:
Employee Laptop
→ Application
→ Allowed
But:
Employee Laptop
→ Production Database
→ Blocked
Similarly:
Public Internet
→ Web Application
→ Allowed
But:
Public Internet
→ Database
→ Blocked
Segmentation is especially important for:
- Production systems
- Databases
- Payment systems
- Administrative interfaces
- Security infrastructure
- Sensitive information
Step 5: Control Inbound Traffic
Determine what traffic is allowed into your systems.
For example:
| Source | Destination | Port/Service | Decision |
|---|---|---|---|
| Internet | Web application | HTTPS | Allow |
| Internet | Database | Database port | Deny |
| Corporate VPN | Admin server | SSH/RDP | Allow |
| Public Internet | Admin interface | Admin port | Deny |
| Application server | Database | Database port | Allow |
The organization should avoid unnecessarily exposing services to the internet.
Step 6: Control Outbound Traffic
Network security should not focus only on inbound traffic.
Consider controlling outbound communication from:
- Servers
- Endpoints
- Containers
- Cloud workloads
- Production systems
For example, an application server may not need unrestricted access to every internet service.
Outbound restrictions can help reduce:
- Malware communication
- Data exfiltration
- Command-and-control connections
- Unauthorized downloads
- Unnecessary external dependencies
The level of control should be risk-based.
Step 7: Secure Network Administration
Network devices and cloud networking infrastructure should be administered securely.
Examples include:
- Firewalls
- Routers
- Switches
- VPN gateways
- Wireless controllers
- Cloud networking
- Security groups
- Network access-control lists
Administrative access should use:
- Individual accounts
- Strong authentication
- MFA where appropriate
- Least privilege
- Secure management channels
- Logging
- Monitoring
Avoid shared administrator accounts wherever practical.
Step 8: Secure Remote Access
Remote work introduces additional network risks.
Remote access may include:
- VPN
- Zero Trust Network Access
- Remote desktop
- Cloud administration
- SSH
- Vendor access
Remote access should be:
- Authorized
- Authenticated
- Encrypted
- Restricted
- Logged
- Monitored
A production database should not be directly exposed to the internet simply to make remote administration convenient.
Step 9: Secure Wireless Networks
For organizations with office Wi-Fi, consider separating:
- Corporate Wi-Fi
- Guest Wi-Fi
- IoT devices
- Administrative devices
For example:
Corporate Wi-Fi
→ Internal business resources
Guest Wi-Fi
→ Internet only
A visitor should not automatically gain access to internal systems simply by connecting to the office network.
Step 10: Use Secure Network Protocols
Where sensitive information is transmitted, use appropriately secured communication protocols.
Examples include:
- HTTPS/TLS
- SSH
- Secure VPN protocols
- Secure administrative protocols
Avoid unnecessary use of insecure protocols such as:
- Telnet
- Plain FTP
- Unencrypted HTTP for sensitive communications
The organization should consider both encryption in transit and secure endpoint configuration.
Step 11: Protect Network Devices
Network devices themselves should be secured.
Controls may include:
- Secure configuration
- Firmware updates
- Restricted administration
- Strong authentication
- MFA where supported
- Disable unnecessary services
- Disable unused ports/interfaces
- Backup configuration
- Logging
- Monitoring
- Vulnerability management
A firewall with an insecure administrative interface can itself become an attack path.
Step 12: Monitor Network Activity
Important network events should be monitored.
Examples include:
- Repeated connection failures
- Unusual traffic
- Unexpected geographic connections
- New firewall rules
- New public services
- Port scanning
- Suspicious outbound traffic
- Large data transfers
- VPN anomalies
- Unauthorized administrative activity
This works closely with:
- A.8.15 Logging
- A.8.16 Monitoring Activities
Step 13: Review Firewall and Network Rules
Firewall rules should not be created and then forgotten.
Periodically review:
- Unused rules
- Duplicate rules
- Overly broad rules
- Temporary rules
- Internet-facing services
- Administrative access
- Source restrictions
- Destination restrictions
For example:
Weak
Allow traffic from anywhere to a management interface.
Better
Allow management traffic only from authorized administrative networks or access mechanisms.
Startup Example
Imagine a 40-person SaaS startup hosted in AWS.
Weak architecture
The startup has:
- Public EC2 instances
- Public database
- Open security groups
- Shared administrator access
- No network segmentation
- No firewall-rule review
The application works, but the network provides unnecessary exposure.
Improved architecture
The company implements:
Internet
↓
WAF / Load Balancer
↓
Application Layer
↓
Private Services
↓
Private Database
Administrative access is provided through:
Authorized User
↓
MFA
↓
VPN / Zero Trust Access
↓
Restricted Management Interface
The database is not directly exposed to the public internet.
Startup-Focused Quick Summary
A startup can begin with a practical network-security model:
1. Know your network
Document cloud and corporate network architecture.
2. Minimize exposure
Do not expose services unnecessarily.
3. Segment critical systems
Separate public, internal, administrative, and sensitive systems where appropriate.
4. Control access
Use firewalls, security groups, ACLs, VPN/Zero Trust and least privilege.
5. Secure administration
Protect network devices and cloud management interfaces.
6. Encrypt sensitive traffic
Use secure communication protocols.
7. Monitor
Watch important network events and changes.
8. Review
Regularly review firewall rules, exposed services and network configurations.
Startup principle:
Your network should expose only what the business actually needs.
Example Network Security Rules
A startup may define rules such as:
| Rule | Requirement |
|---|---|
| Public applications | HTTPS only where appropriate |
| Production database | No direct public access |
| Administrative interfaces | Restricted access |
| Remote administration | MFA + approved access mechanism |
| Corporate Wi-Fi | Strong authentication |
| Guest Wi-Fi | Segmented from corporate network |
| Firewall changes | Authorized and logged |
| Critical network devices | Security updates maintained |
| Network logs | Protected and retained appropriately |
| Temporary firewall rules | Documented and reviewed |
Network Security Risk Assessment
Example:
| Risk | Likelihood | Impact | Treatment |
|---|---|---|---|
| Public database exposure | Medium | Critical | Remove public access |
| Unrestricted admin interface | Medium | High | Restrict access |
| Flat internal network | Medium | High | Segment critical systems |
| Weak Wi-Fi security | Medium | Medium | Strengthen authentication |
| Unauthorized firewall changes | Low | High | Restrict and log admin access |
| Unmonitored outbound traffic | Medium | Medium | Implement monitoring |
Actual risk ratings should be determined by the organization’s own risk assessment.
Network Security for Cloud Environments
Cloud networking should be included within Annex A 8.20.
Relevant controls may include:
- VPC/VNet design
- Subnets
- Security groups
- Network ACLs
- Cloud firewalls
- Private endpoints
- Internet gateways
- NAT gateways
- Load balancers
- WAF
- VPN
- Zero Trust access
- Routing controls
- Cloud network monitoring
Example
Instead of:
Internet → Database
use:
Internet → WAF → Load Balancer → Application → Private Database
The architecture should reflect the organization’s security and availability requirements.
Network Security and APIs
APIs are also part of the organization’s network exposure.
Organizations should consider:
- HTTPS
- Authentication
- Authorization
- Rate limiting
- API gateways
- Network restrictions
- Monitoring
- Logging
- Abuse detection
An API that is publicly accessible should not automatically be treated as trusted simply because it belongs to the organization.
Network Security and Third Parties
Third-party network connections should be controlled.
Examples:
- Vendor VPN
- Managed service provider access
- Cloud support access
- Customer integrations
- Partner APIs
- Remote support
Consider:
- Business justification
- Scope
- Authentication
- Least privilege
- Duration
- Network restrictions
- Monitoring
- Logging
- Termination
Temporary third-party access should not become permanent by accident.
Network Security and Zero Trust
Zero Trust principles can complement Annex A 8.20.
Instead of assuming:
“The user is inside our network, therefore they are trusted.”
the organization can evaluate:
- Identity
- Device
- Authentication
- Authorization
- Context
- Application
- Resource
This is particularly useful for distributed and cloud-first startups.
However, adopting a product or architecture specifically called “Zero Trust” is not itself required for ISO 27001.
The organization should implement controls appropriate to its risks.
Network Security and Development Environments
Development and production environments should be appropriately separated.
For example:
Developer
→ Development Environment
Tester
→ Test Environment
Authorized Production Engineer
→ Production Environment
A developer’s normal workstation should not automatically have unrestricted access to production databases.
This works closely with:
- A.8.2 Privileged Access Rights
- A.8.4 Access to Source Code
- A.8.18 Privileged Utility Programs
- A.8.25 Secure Development Life Cycle
- A.8.31 Separation of Development, Test and Production Environments
Network Availability
Network security also has an availability dimension.
Consider:
- Redundant internet connections
- Redundant network devices
- Cloud availability zones
- DDoS protection
- Backup connectivity
- Failover
- Network capacity
This connects Annex A 8.20 with:
- A.8.6 Capacity Management
- A.8.14 Redundancy
- A.5.29 Information Security During Disruption
- A.5.30 ICT Readiness for Business Continuity
Audit Evidence for Annex A 8.20
An auditor may review:
Documentation
- Network Security Policy
- Network Architecture Diagram
- Network Configuration Standard
- Remote Access Procedure
- Firewall Management Procedure
- Wireless Security Standard
Technical Evidence
- Firewall configuration
- Cloud security-group configuration
- Network ACLs
- VPN configuration
- WAF configuration
- Network monitoring
- Network-device hardening
- Vulnerability scan results
Records
- Firewall change requests
- Network access approvals
- Firewall-rule reviews
- VPN access records
- Security incidents
- Network monitoring alerts
Annex A 8.20 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is the network architecture documented? | Network diagram |
| Are critical network components identified? | Asset inventory |
| Are network security responsibilities defined? | RACI/policy |
| Are internet-facing services identified? | External exposure inventory |
| Is unnecessary exposure prevented? | Firewall/security groups |
| Is network segmentation implemented where required? | Architecture/configuration |
| Is remote access controlled? | VPN/Zero Trust configuration |
| Is MFA used for privileged remote access where appropriate? | IAM/VPN evidence |
| Are network devices securely configured? | Configuration standard |
| Are insecure protocols restricted? | Network configuration |
| Are firewall rules reviewed? | Review records |
| Are network changes authorized? | Change tickets |
| Are network activities logged? | Logs |
| Are important network events monitored? | Monitoring alerts |
| Are network vulnerabilities managed? | Vulnerability reports |
| Are third-party connections controlled? | Vendor access records |
| Is guest wireless separated where appropriate? | Wi-Fi configuration |
| Are critical network services resilient? | Redundancy/BC evidence |
Common Mistakes
1. Assuming “We Use AWS” Means Network Security Is Covered
Cloud providers secure the underlying cloud infrastructure, but the customer remains responsible for configuring its own environment appropriately.
Security groups, network architecture, access, public exposure and application configuration still matter.
2. Exposing Databases to the Internet
A database usually does not need unrestricted public access.
Use private networking and restricted access wherever practical.
3. Flat Network Architecture
Putting every system in one unrestricted network can increase the impact of a compromise.
Segment systems according to risk.
4. Allowing “Anywhere” Access
Rules such as:
0.0.0.0/0
may be appropriate in some limited circumstances, but broad access should be justified rather than used for convenience.
5. Forgetting Outbound Traffic
Security teams often focus only on incoming connections.
Outbound controls and monitoring can also help detect and prevent:
- Data exfiltration
- Malware communication
- Unauthorized external services
6. No Firewall Rule Review
A temporary access rule can remain in place for years.
Review and remove rules that are no longer required.
7. Shared Network Administrator Accounts
Shared accounts make accountability difficult.
Use individual accounts and appropriate privileged access controls.
8. Ignoring Remote Workers
A modern startup may have very few employees physically connected to the corporate office.
Remote access and cloud access therefore become central parts of network security.
Practical Startup Implementation Model
A startup can implement Annex A 8.20 using this lifecycle:
1. Discover
Identify networks, cloud environments, devices and connections.
2. Map
Document how systems communicate.
3. Classify
Identify critical and sensitive systems.
4. Minimize
Remove unnecessary network exposure.
5. Segment
Separate systems where risk requires it.
6. Restrict
Control inbound, outbound and administrative traffic.
7. Secure
Use secure protocols and hardened network devices.
8. Monitor
Monitor important network activity.
9. Review
Review firewall rules, exposure and configurations.
10. Improve
Address weaknesses identified through monitoring, testing and incidents.
Simple implementation formula:
Discover → Map → Classify → Minimize → Segment → Restrict → Secure → Monitor → Review → Improve
Minimum Viable Network Security for a Startup
A startup should consider establishing at least:
Cloud
- Secure VPC/VNet
- Private database
- Restricted security groups
- Controlled administrative access
- WAF where appropriate
- Network monitoring
Employees
- Secure Wi-Fi
- Endpoint security
- Controlled remote access
- MFA
Administration
- Restricted privileged access
- Individual accounts
- Secure management channels
- Logging
Operations
- Firewall/network-rule review
- Vulnerability management
- Network monitoring
- Change management
Documentation
- Network diagram
- Network security policy
- Firewall rules
- Remote access procedure
- Network review records
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Network access must be controlled and protected |
| Standard | Production databases must not be publicly exposed unless formally justified |
| Process | Firewall changes require authorization |
| Technical Control | Security groups restrict database access |
| Evidence | Firewall/security-group configuration |
| Monitoring | Network events are monitored |
| Review | Firewall rules are periodically reviewed |
Relationship With Other ISO 27001 Controls
Annex A 8.20 has strong relationships with several other controls.
| Control | Relationship |
|---|---|
| A.5.9 | Network assets should be identified |
| A.5.15 | Network access must be controlled |
| A.5.18 | Network privileges must be managed |
| A.5.19–5.22 | Third-party and supplier network connections |
| A.5.29 | Network availability during disruption |
| A.5.30 | ICT continuity and network resilience |
| A.8.2 | Privileged network administration |
| A.8.8 | Network-device vulnerabilities |
| A.8.9 | Secure network configuration |
| A.8.13 | Backup of relevant configurations/information |
| A.8.14 | Network and infrastructure redundancy |
| A.8.15 | Network logging |
| A.8.16 | Network monitoring |
| A.8.17 | Time synchronization for network logs |
| A.8.18 | Privileged network utilities |
| A.8.19 | Controlled software on network systems |
| A.8.21 | Security of network services |
| A.8.22 | Network segregation |
| A.8.24 | Cryptography |
Particularly important relationship
A.8.20 + A.8.21 + A.8.22
These controls should work together:
Network controls → Secure network services → Appropriate segregation
Useful Documents for Annex A 8.20
- Network Security Policy
[Insert Draft Document Link] - Network Architecture Diagram
[Insert Draft Document Link] - Network Security Configuration Standard
[Insert Draft Document Link] - Firewall Rule Management Procedure
[Insert Draft Document Link] - Remote Access Security Procedure
[Insert Draft Document Link] - Network Access Request Form
[Insert Draft Document Link] - Network Firewall Review Checklist
[Insert Draft Document Link] - Cloud Network Security Checklist
[Insert Draft Document Link] - Network Device Hardening Checklist
[Insert Draft Document Link]
Questions an Auditor May Ask
Network Architecture
- Can you show your current network architecture?
- What are your critical network components?
- Which systems are internet-facing?
- Which systems are private?
Access
- Who can administer your firewalls?
- Who can access production?
- How is remote access controlled?
- Is MFA enabled for privileged access?
Segmentation
- How are production and development environments separated?
- Can employee devices directly access production databases?
- How is guest Wi-Fi separated?
Configuration
- How are firewall rules created?
- Who approves network changes?
- How often are rules reviewed?
- How do you remove obsolete rules?
Monitoring
- What network events are logged?
- How are suspicious connections detected?
- Who reviews network alerts?
Third Parties
- Do suppliers have network access?
- How is their access restricted?
- How do you terminate third-party access?
Example Auditor Walkthrough
An auditor may select a critical production application and trace its network path:
Internet
↓
DNS / WAF
↓
Load Balancer
↓
Application
↓
Private Service
↓
Database
The auditor may then verify:
- Public exposure
- Firewall rules
- Security groups
- Network segmentation
- Administrative access
- Logging
- Monitoring
- Change records
The objective is to determine whether the implemented controls match the organization’s documented security requirements.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.20 is not simply about installing a firewall.
It is about controlling and protecting communication between systems, users, devices, applications and external networks.
A startup should be able to answer:
- What networks and network components do we have?
- Which systems are exposed to the internet?
- Why are they exposed?
- Which systems should be private?
- Who can access critical network resources?
- How is remote access controlled?
- How are network changes authorized?
- How do we detect suspicious network activity?
- How often do we review network rules?
- What happens if a critical network component fails?
In one sentence:
Annex A 8.20 ensures that organizational networks and network devices are appropriately controlled, protected, monitored, and managed according to information security risks.
For a modern SaaS startup, the most important mindset is:
Do not build a network where everything can talk to everything. Build controlled paths based on business need, security risk, and system criticality.
That approach makes Annex A 8.20 practical for ISO 27001, SOC 2, cloud security, and customer security reviews without turning network security into unnecessary complexity.