What is ISO 27001 Annex A 8.22 – Segregation of Networks?
ISO 27001 Annex A 8.22 focuses on segregating groups of information services, users, and information systems within networks according to the organization’s security and business requirements.
The purpose is to prevent unnecessary communication between systems, users, and environments and to limit the impact of a security incident.
Simple explanation
Network segregation means separating systems, users, or services into different network zones and controlling communication between those zones.
Instead of allowing everything to communicate with everything else:
User Network → Controlled Access → Application Network → Controlled Access → Database Network
This creates additional security boundaries.
Why is Network Segregation Important?
If an attacker compromises one system, unrestricted network access can allow the attacker to move to other systems.
For example:
Employee Laptop
↓
Compromised
↓
Application Server
↓
Database
↓
Sensitive Customer Data
Network segregation can reduce this type of lateral movement.
A properly designed network can restrict communication so that compromise of one environment does not automatically provide access to every other environment.
What does A.8.22 require?
The organization should consider whether different groups of:
- Information services
- Users
- Information systems
need to be segregated.
The level of segregation should be based on:
- Information-security risk
- Business requirements
- System criticality
- Information sensitivity
- Regulatory requirements
- Customer requirements
- Architecture
- Threat environment
Segregation can be physical, logical, virtual, or implemented through access-control mechanisms.
Examples of Network Segregation
Common examples include:
1. Production vs. Development
Separate production systems from development and testing environments.
Development → Test → Production
Access to production should be appropriately restricted.
2. Corporate vs. Guest Wi-Fi
Employees and guests should not necessarily use the same network.
Corporate Wi-Fi
→ Internal resources
Guest Wi-Fi
→ Internet only
3. Application vs. Database
Applications may communicate with databases, but users do not need direct access to the database.
Users → Application → Database
rather than:
Users → Database
4. Internet-facing vs. Internal Systems
Public-facing systems can be placed in a controlled network zone, while internal systems remain protected.
5. Security Management Network
Administrative interfaces can be separated from ordinary user networks.
6. High-Sensitivity Systems
Systems containing particularly sensitive information may require stronger network isolation.
Activities Required to Implement A.8.22
1. Identify network zones
Start by identifying the organization’s major network environments.
For example:
| Network Zone | Purpose | Risk |
|---|---|---|
| Internet | Public connectivity | High |
| DMZ | Public-facing services | High |
| Corporate | Employee systems | Medium |
| Production | Business applications | High |
| Database | Sensitive data | Critical |
| Development | Software development | Medium |
| Guest | Visitor access | High |
| Management | Administrative systems | Critical |
The exact zones will depend on the organization’s architecture.
2. Identify what should communicate
For each zone, determine:
- Who needs access?
- Which systems need communication?
- Which ports are required?
- Which protocols are required?
- Which communication should be prohibited?
A simple rule is:
Allow only the communication that is required for business operations.
3. Implement network boundaries
Network segregation can be implemented using technologies such as:
- VLANs
- Firewalls
- Security groups
- Network ACLs
- Subnets
- Virtual networks
- Private networks
- VPNs
- Zero Trust controls
- Micro-segmentation
- Routing controls
- Access-control lists
Cloud environments commonly use virtual networks, subnets, security groups and network access controls rather than traditional physical network segmentation.
4. Define access rules
Network access rules should specify:
- Source
- Destination
- Port
- Protocol
- Purpose
- Owner
- Approval
- Expiration, where applicable
Example:
| Source | Destination | Port | Purpose |
|---|---|---|---|
| Web Server | Application Server | 443 | Application traffic |
| Application Server | Database | 5432 | PostgreSQL |
| Employee Network | Internet | 443 | Web access |
| Guest Network | Internal Network | Denied | Prevent internal access |
5. Restrict unnecessary traffic
Network segregation should not become a collection of permanent exceptions.
Review whether:
- Unused ports are open
- Unnecessary routes exist
- Development can access production
- Guest users can reach internal resources
- Employees can directly access databases
- Administrative interfaces are exposed
- Internet-facing systems can reach sensitive internal systems unnecessarily
6. Monitor network boundaries
Relevant network traffic and security events should be monitored according to risk.
Monitoring may identify:
- Unauthorized connection attempts
- Blocked traffic
- Unexpected communication
- Port scanning
- Lateral movement
- Firewall-rule violations
- Unusual traffic patterns
- Changes to network controls
7. Periodically review segregation
Network segregation should be reviewed when:
- Network architecture changes
- New applications are introduced
- New cloud environments are created
- New users or locations are added
- Firewall rules change
- Major security incidents occur
- New regulatory/customer requirements arise
- Systems are retired
Example – SaaS Startup
Consider a SaaS startup operating a cloud-based application.
Its architecture contains:
- Public web application
- Application servers
- Database
- Development environment
- Corporate employee network
- Guest Wi-Fi
- Management interfaces
A simplified architecture could be:
Internet
↓
WAF / Firewall
↓
Public/Application Zone
↓
Application Zone
↓
Database Zone
At the same time:
Corporate Network → Internet / Approved Internal Services
Guest Network → Internet Only
Development → Development Resources
Management Network → Restricted Administrative Interfaces
The database does not need to be directly accessible from employee laptops or the public Internet.
This limits the number of possible paths to sensitive systems.
What Events Should Trigger Review?
| Trigger | Action |
|---|---|
| New application | Determine required network zone |
| New production environment | Review segmentation |
| Cloud migration | Reassess network architecture |
| New office | Review network zones |
| New remote-access solution | Review access paths |
| Major firewall change | Review affected segmentation |
| Security incident | Reassess network boundaries |
| New sensitive data | Review isolation requirements |
| New customer requirement | Review network controls |
| Major infrastructure change | Update architecture |
| System retirement | Remove unnecessary network rules |
Startup-Focused Quick Summary
Does a startup need complicated network segmentation?
No.
A startup does not need an enterprise-grade network with dozens of VLANs just to implement A.8.22.
The objective is to create appropriate separation based on risk.
A small SaaS startup might only need:
- Production
- Development
- Corporate
- Guest
- Database
- Management
Depending on its architecture.
Minimum startup implementation
A startup can begin with:
- Create a basic network architecture diagram.
- Identify production, development and corporate environments.
- Separate guest access from internal systems.
- Restrict direct access to databases.
- Protect management interfaces.
- Define required communication paths.
- Block unnecessary traffic.
- Review firewall/security-group rules periodically.
- Monitor important network activity.
- Document significant changes.
Simple rule
If two systems do not need to communicate, don’t allow them to communicate by default.
And:
If a system contains sensitive information, consider whether it needs stronger network isolation.
Small team ≠ flat network.
A startup can have a simple architecture while still maintaining meaningful network segregation.
Example Network Segmentation Matrix
| Source Zone | Destination Zone | Access | Purpose | Approval |
|---|---|---|---|---|
| Internet | Web/WAF | Allowed | Public application | Security |
| Internet | Database | Denied | Not required | N/A |
| Corporate | Production | Restricted | Administration/support | Authorized Owner |
| Development | Production | Restricted/Denied | Minimize risk | Management/Security |
| Application | Database | Allowed | Application data access | Application Owner |
| Guest | Corporate | Denied | Prevent internal access | Security |
| Guest | Internet | Allowed | Internet access | IT |
| Admin | Production | Restricted | Administrative activities | Authorized Admin |
The exact rules should be based on the organization’s architecture and risk assessment.
Network Segregation Design Questions
For each network zone, ask:
Users
- Who can access this zone?
- Are privileged users separated?
- Is guest access isolated?
Systems
- Which systems are located here?
- Are production and development separated?
- Are critical systems isolated?
Communication
- Which systems need to communicate?
- Which ports are required?
- Which protocols are required?
- What traffic should be blocked?
Administration
- How is administrative access performed?
- Are management interfaces isolated?
- Is MFA required?
Monitoring
- Is network traffic logged?
- Are suspicious connections detected?
- Are important firewall events monitored?
A.8.22 Audit Evidence
An auditor may request evidence such as:
Architecture
- Network architecture diagram
- Network topology
- Cloud network diagram
- Data-flow diagram
- Network zone documentation
Configuration
- VLAN configuration
- Firewall configuration
- Security groups
- Network ACLs
- Routing tables
- Subnet configuration
- VPN configuration
- Micro-segmentation rules
Access-control evidence
- Firewall-rule review
- Network access requests
- Rule approvals
- Access-control matrix
- Administrative access records
Monitoring
- Firewall logs
- Network monitoring
- Security alerts
- Intrusion detection/prevention records
- Network traffic analysis
Testing
- Vulnerability assessment
- Penetration testing
- Network security testing
- Segmentation testing
Change management
- Network change tickets
- Firewall-rule changes
- Architecture changes
- Approval records
A.8.22 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Has the network architecture been documented? | Network Diagram |
| Are important network zones identified? | Network Architecture |
| Are sensitive systems appropriately segregated? | Architecture/Configuration |
| Are production and development separated where required? | Network Configuration |
| Is guest access isolated from internal resources? | Wi-Fi/Firewall Configuration |
| Is database access restricted? | Firewall/Security Groups |
| Are network communication requirements documented? | Segmentation Matrix |
| Are unnecessary connections restricted? | Firewall Rules |
| Are network boundaries monitored? | Logs/Monitoring |
| Are firewall/security-group rules reviewed? | Review Records |
| Are network changes controlled? | Change Tickets |
| Is segregation tested where appropriate? | VAPT/Penetration Test |
| Are network zones reviewed after major changes? | Review Evidence |
Common Mistakes
1. Flat network
Everything can communicate with everything else.
This can make lateral movement easier following a compromise.
2. Production and development are connected unnecessarily
Developers may have excessive access to production systems.
Access should be restricted according to business and security requirements.
3. Guest Wi-Fi can access internal resources
Guest networks should generally be isolated from internal networks unless there is a specific justified requirement.
4. Database exposed directly
Users and Internet-facing systems should not have unnecessary direct access to sensitive databases.
5. Too many firewall exceptions
Over time, temporary access rules can become permanent.
Review rules periodically.
6. No documentation
The technical configuration may exist, but nobody can explain why the network is segmented the way it is.
Maintain an architecture diagram and appropriate documentation.
7. Assuming cloud means segmentation is automatic
Cloud platforms provide segmentation capabilities, but the organization still needs to configure and manage them appropriately.
Practical Implementation Model
A practical A.8.22 implementation model is:
Identify Systems & Users
↓
Classify Information & Risk
↓
Define Network Zones
↓
Define Required Communication
↓
Implement Segmentation
↓
Restrict Unnecessary Traffic
↓
Monitor
↓
Review Rules
↓
Test
↓
Update After Changes
Policy vs. Architecture vs. Evidence
| Element | Example |
|---|---|
| Policy | Network access shall be appropriately segregated based on security and business requirements. |
| Architecture | Production, development, guest and database environments are separated. |
| Configuration | Firewall/security groups restrict communication between zones. |
| Evidence | Network diagrams, firewall rules, review records and security testing. |
A network diagram alone does not prove effective segregation.
Likewise, a firewall configuration alone may not demonstrate that the segregation requirements were properly defined.
The auditor should be able to see the connection between:
Risk → Requirement → Architecture → Configuration → Monitoring → Review
Useful Resources
Recommended documents
- Draft Network Segregation Standard – [Insert Draft Document Link]
- Network Architecture Diagram Template – [Insert Draft Document Link]
- Network Segmentation Matrix – [Insert Draft Document Link]
- Firewall Rule Review Checklist – [Insert Draft Document Link]
- Cloud Network Security Checklist – [Insert Draft Document Link]
- Network Security Policy – [Insert Draft Document Link]
- Network Change Management Procedure – [Insert Draft Document Link]
Related ISO 27001 controls
A.8.22 works closely with:
- A.5.15 – Access control
- A.5.18 – Access rights
- A.8.2 – Privileged access rights
- A.8.3 – Information access restriction
- A.8.5 – Secure authentication
- A.8.9 – Configuration management
- A.8.15 – Logging
- A.8.16 – Monitoring activities
- A.8.20 – Network security
- A.8.21 – Security of network services
- A.8.24 – Use of cryptography
Final Takeaway
ISO 27001 Annex A 8.22 is about separating network environments and controlling communication between them according to security and business requirements.
A practical organization should be able to answer:
What are our network zones?
Why are they separated?
Who can communicate with each zone?
Which connections are allowed?
Which connections are blocked?
How do we monitor and review the segregation?
For a startup, network segregation does not have to be complicated.
Start with the basics:
Production ≠ Development
Guest ≠ Corporate
Database ≠ Public Internet
Management Interfaces ≠ General User Access
Then strengthen segmentation as the organization’s systems, risks, customers and regulatory requirements grow.
A.8.22 = Identify → Separate → Restrict → Monitor → Review → Test → Improve.