Why A.8.20 matters so much for MSPs
Annex A.8.20 matters to MSPs because it decides whether your network can safely host many customers without one breach spreading into others. Larger customers, auditors and insurers use this control to judge tenant isolation, protection of management tools and firewall governance, reflecting the way the ISO 27001:2022 Annex A network controls are treated as core evidence that networks are being managed in line with risk. When you can explain this clearly and show credible evidence, you reduce incident impact, increase enterprise buyer confidence and strengthen your position with insurers.
Strong networks quietly protect every customer you serve, even when nobody is looking.
If you run a managed service provider, your network has quietly become part of every customer’s attack surface. A single weakly segmented management platform or “flat” core can turn one compromised tenant into twenty compromised tenants.
A majority of organisations in the 2025 ISMS.online survey say they have been impacted by at least one third‑party or vendor‑related security incident in the past year.
ISO 27001:2022 Annex A.8.20, the “Network security” control, is where auditors and large customers now look to see whether your network layer is genuinely under control. In practice, when organisations certify against ISO 27001, reviewers routinely focus on this and related network controls to understand how tenant isolation, firewall governance and monitoring are handled in multi‑tenant estates. It is also where insurers and regulators expect you to have answers on tenant isolation, firewall governance and monitoring, especially in multi‑tenant environments.
For MSPs, treating A.8.20 as a design and operating standard – not just a line in a policy – is what separates “we think we are secure” from “we can explain and prove how each tenant is protected.”
What A.8.20 actually requires (in plain language)
A.8.20 expects you to design and operate networks so they actively protect information rather than simply carry traffic, and to design, segment and manage them so they adequately protect the information flowing through them. The formal ISO wording is copyrighted, but public commentary on the standard – and widely used guidance on network and firewall security – is consistent that networks and network devices should be secured, managed and controlled in line with risk so that the information flowing across them is adequately protected.
In practice, for an MSP that means you are expected to:
- Design network architectures deliberately based on risk and information sensitivity.
- Segment networks so tenants, internal systems and management interfaces are separated.
- Control access between segments using firewalls, VPNs, SD‑WAN and access control lists.
- Operate these controls under clear policies, standards and processes.
- Evidence that the controls work over time, not just on paper.
A.8.20 does not stand alone. It is closely linked to:
- A.8.22 – Segregation of networks: (how segments and zones are separated).
- A.8.31 – Separation of development, test and production: (environment boundaries).
- A.8.15 / A.8.16 – Logging and monitoring: (seeing what is happening on the network).
- A.8.32 – Change management: (controlling changes to firewalls and network devices).
These relationships reflect the way Annex A brings related network, logging and change controls together in one catalogue, so it is natural for auditors and implementers to treat them as one combined “network security programme” rather than a set of isolated controls. If you do the same, you will find Annex A much easier to implement and to explain, and you will give customers and auditors a more convincing storey.
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
A simple 3‑plane model for MSP network security
A.8.20 becomes much easier to design and explain if you break your estate into three logical planes and secure each deliberately. A helpful way to think about network security in an MSP is to split everything into three logical “planes” – corporate, tenant and management – so you can show how traffic flows, where it is constrained and how you prevent a compromise in one area from turning into a multi‑tenant incident.
In this model, you split everything into three logical “planes”:
- Corporate / internal IT.
- Tenant / customer data.
- Management / out‑of‑band control.
Each plane has different goals, risks and audiences, but all three need to be secured, managed and controlled in ways you can evidence.
Corporate / internal IT plane
The corporate plane must protect your own information and avoid becoming a back door into customer environments, because your own business systems sit in this plane: email, file services, HR and finance applications, staff devices, corporate Wi‑Fi and similar services. If you treat this plane as a separate zone with clear boundaries and controlled paths into management tools, you reduce the risk that compromised staff devices or office networks can pivot silently into tenant estates.
Typical examples in this plane include your email, collaboration tools, HR and finance systems, corporate Wi‑Fi and staff endpoints.
Goals:
- Protect your business information.
- Stop compromised endpoints from reaching tenant networks directly.
- Provide secured, audited paths for staff to access management tools.
Tenant / customer data plane
The tenant plane needs strong isolation between customers and sensible segmentation inside each customer. When you give every tenant its own logical space and limit internal movement between zones, you drastically reduce the blast radius of any compromise and make your multi‑tenant storey much more credible to enterprise buyers. Public‑sector and industry guidance aimed at MSPs also emphasises strong customer isolation and tightly controlled administration paths, so treating robust separation as your default stance is aligned with widely accepted expectations.
All the networks, sites and workloads you manage for customers sit here: on‑premises LANs, data centres, cloud VPCs/VNETs and branch offices.
Goals:
- Strong tenant‑to‑tenant isolation.
- Appropriate internal segmentation within each tenant (user, server, DMZ, OT and similar zones).
- Controlled connections back to your management plane and, where necessary, to other tenants.
Management / out‑of‑band plane
The management plane should be treated as your highest‑value network asset and given the strongest isolation you can realistically sustain. If you keep management interfaces on dedicated paths with tight access controls and full monitoring, you dramatically reduce the chance that one compromised tool can quietly change many customer environments at once.
This is the “nervous system” that controls everything: remote monitoring and management tools, hypervisors, storage controllers, switches, firewalls, console access and jump hosts.
Goals:
- Extremely restricted access (only from hardened admin paths).
- No exposure on public networks.
- Full logging, strong authentication and robust monitoring.
A.8.20 expects you to show that each plane is:
- Secured: (hardened, segmented, least privilege).
- Managed: (owned, documented, governed).
- Controlled: (changes authorised, activity logged and reviewed).
Once you have this three‑plane picture, every design decision about VLANs, VRFs, SD‑WAN and firewalls can be anchored in clear objectives instead of ad‑hoc choices, and you can explain that logic to customers, auditors and insurers.
At this point it is worth sketching your own three‑plane diagram and marking where current paths or shared services cut across the boundaries you want to enforce.
Designing segmentation for multi‑tenant environments
Segmentation for multi‑tenant MSPs is about deciding where you draw boundaries and how you control the few paths that cross them. When you deliberately separate tenants, environments and management paths – using the three‑plane model as your guide – segmentation becomes a matter of deciding how you slice and connect each plane so you reduce the chance that a single mistake or compromise will cascade across customers, and you make your network storey easier to explain to enterprise buyers and auditors.
Around 41% of organisations in the 2025 ISMS.online survey named managing third‑party risk and tracking supplier compliance as a top information‑security challenge.
With the three‑plane model in mind, you can decide how each plane should be sliced and connected.
Tenant isolation and per‑tenant segmentation
Per‑tenant isolation is the foundation that keeps one customer’s problem from becoming everyone’s incident. If you give each tenant its own routing domain and carefully controlled links to shared services, you can demonstrate that their traffic stays inside boundaries you defined and can adjust without breaking other customers, and for the tenant plane strong isolation really is the default expectation.
For the tenant plane, strong isolation is the default expectation:
- Use per‑tenant VLANs or VRFs in your core to give each customer a logical routing domain.
- In cloud environments, use separate VPCs/VNETs per customer or major application.
- Treat shared hosting platforms as high‑risk zones with very strict ingress and egress controls.
The principle is simple: one tenant’s traffic should never reach another tenant’s systems unless you have designed and documented a specific, justified connection and can show how it is controlled.
Environment separation (prod / test / dev)
Environment separation stops low‑assurance test and development systems from undermining high‑assurance production systems. When you keep experiments, labs and pilots in clearly separated segments with strictly controlled links into live environments, you reduce the risk that a convenient shortcut accidentally exposes real customer data.
A.8.20, together with A.8.31, expects you to prevent test and development systems from undermining production. Both controls, as set out in ISO 27001:2022, emphasise that lower‑assurance environments should not create unmanaged paths into live systems:
- Maintain separate subnets or VLANs for development, test and production in each tenant or shared environment.
- Ensure connectivity from test and development to production is tightly controlled and justified, not “open for convenience”.
- Block generic lab networks and proof‑of‑concept environments from reaching live customer data.
Management‑plane separation
Management‑plane separation ensures that admin interfaces are not shortcuts between tenants or into your own corporate network. When management interfaces sit on dedicated segments with forced access through hardened paths, you can show that changes to firewalls, hypervisors and other shared components always pass through known gates.
Your management plane is the highest‑value target in your estate, so it deserves its own segmentation pattern:
- Place management interfaces on dedicated management networks.
- Avoid exposing management interfaces on customer LANs or the internet; use jump hosts, VPNs or bastion services.
- Use VRFs or equivalent features to keep management traffic logically separate from tenant and corporate planes.
Shared services enclaves
Shared services enclaves are where many “flat” designs quietly appear, so they deserve extra attention. By grouping shared services into dedicated segments and restricting tenant access to specific, justified ports, you avoid turning these services into a hidden bridge between customers.
Shared services (such as DNS, logging, monitoring, backup repositories and remote management servers) are often where segmentation breaks down. To keep them under control:
- Group shared services into enclaves with their own network segments and firewalls.
- Allow tenants to reach these enclaves only on specific, required ports and protocols.
- Ensure there is no implicit path from one tenant, through a shared service, into another tenant.
Secure remote access paths
Secure remote access paths are the routes your engineers actually use day‑to‑day, so they must reflect your segmentation storey. If you align jump hosts, privileged workstations and VPNs with your three‑plane model, it becomes much easier to justify remote access to customers and answer insurers’ questions about privileged access.
How your engineers get into customer environments is a key A.8.20 concern:
- Favour bastion hosts or privileged access workstations as stepping stones into tenant zones.
- Integrate remote access with strong identity and log all sessions.
- Avoid direct RDP or SSH from general corporate laptops into tenant networks, and avoid “VPN to everything” designs.
Taken together, these patterns meet the core Annex A.8.20 questions:
- How are tenants separated?
- How are internal, tenant and management networks separated?
- Through what controlled paths do they interact?
As you review your current segmentation, it helps to list the crossings between planes and tenants, then check whether each crossing is truly required and correctly controlled.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Firewall baselines that make segmentation real
Firewalls are where your segmentation designs become enforced behaviour, so A.8.20 cares about the rules you run as much as the diagrams you draw. Network diagrams alone cannot protect customers. Enforcement lies in firewalls and gateways, and A.8.20 is interested in how you configure, govern and monitor those devices across all planes so that clear baselines, consistently applied and tightly governed from on‑premises to cloud and SD‑WAN, demonstrate that default‑deny and least‑privilege are lived operating principles rather than slogans in a document.
A.8.20 is interested in how you configure, govern and monitor firewall and gateway devices across all planes. A consistent baseline, applied from on‑premises to cloud and SD‑WAN, makes it much easier to explain your posture to auditors and customers.
A risk‑based firewall baseline
A risk‑based firewall baseline gives your engineers a starting pattern that reflects your security posture, so they do not reinvent policy for every site or tenant. When that baseline is aligned across on‑premises, cloud and SD‑WAN, it becomes much easier to demonstrate to auditors and customers that risk, not convenience, drives your rule sets, and for an A.8.20‑aligned MSP a sensible baseline looks like this.
For an A.8.20‑aligned MSP, a sensible baseline looks like this:
- Default deny on all interfaces with explicit “permit” rules only for required flows.
- Least privilege rules with clear purpose, minimal scope and minimal ports.
- Tight egress control so networks reach only what they genuinely need.
- Hardened management access with dedicated interfaces, controlled sources and strong authentication.
This baseline should apply to:
- Perimeter firewalls.
- Internal segmentation firewalls between key VLANs and zones.
- Cloud security groups, network firewalls and application firewalls used as network controls.
As you compare current firewalls against this baseline, capture a simple list of biggest gaps so you can prioritise remediation where it matters most.
Rule governance and change control
Rule governance and change control determine whether your firewall posture improves over time or drifts slowly into chaos. By giving rules owners, clear justifications and regular reviews, you prove that broad, legacy rules are being driven out rather than creeping back in unnoticed.
A.8.20 is as much about how you manage firewalls as where they sit. Good practice includes:
- A documented network security or firewall standard that sets baseline configuration and rule conventions.
- A formal change process for rule and configuration changes with risk assessment and approval.
- Testing or at least back‑out plans for non‑trivial changes, recorded alongside implementation details.
Logging, monitoring and IDS/IPS
Logging and monitoring show that your network controls are alive rather than static configuration snapshots. When you can demonstrate how firewall and sensor alerts feed into your operations processes, you make it clear that you notice and act on suspicious activity at the boundaries that matter most.
To show that firewalls and segmentation are “managed and controlled”:
- Log security‑relevant events such as key allows, denies and admin logons.
- Send logs to a central platform where they are correlated and retained according to policy.
- Deploy intrusion detection or threat detection at important boundaries, such as internet edges and shared services zones.
- Define how alerts are triaged, escalated and closed, and how findings drive improvements.
This links A.8.20 to the logging and monitoring controls (A.8.15, A.8.16) and helps demonstrate that your network security is an active, not static, control. In the Annex A control set, these areas are deliberately grouped so that network defences and monitoring are understood as parts of one continuous feedback loop rather than isolated activities.
Proving compliance: documentation and evidence that auditors expect
A.8.20 compliance is ultimately judged by how clearly you can show intent, implementation and operation over time. For Annex A.8.20 auditors and larger customers want to see both design intent and evidence of operation, so if you assemble a reusable set of documents and records that connect your network design, firewall standards and monitoring activities to this control, you make audits easier and give customers more confidence in your MSP.
The State of Information Security 2025 report indicates that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 and emerging AI standards.
For Annex A.8.20, auditors and larger customers want to see both design intent and evidence of operation.
Design‑level artefacts
Design‑level artefacts explain why your networks look the way they do and how they are meant to behave. When these documents are current and referenced directly from your A.8.20 control, they become a powerful way to bring engineers, auditors and customers up to speed without walking every device, and typical items that help you tell a credible storey include the following.
Typical items that help you tell a credible storey:
- A network security policy setting out general principles for segmentation and remote access.
- A network segmentation and firewall standard that translates principles into concrete patterns.
- Network diagrams that show three‑plane views and representative tenant or site layouts.
- A Statement of Applicability entry for A.8.20 and related controls that references these documents.
Together, these artefacts show that your network security design is intentional, documented and aligned with Annex A.8.20 rather than an accidental result of growth.
Operation‑level evidence
Operation‑level evidence demonstrates whether your networks actually behave as designed and whether you correct drift when it appears. This is where auditors and larger customers look to confirm that your diagrams and standards hold up under real‑world change and pressure.
To show that controls are in use and maintained, it helps to have:
- Configuration baselines or exports from representative firewalls, routers, switches and SD‑WAN controllers.
- Change records for firewall and core network changes, including approvals and testing notes.
- Review records for periodic firewall rule reviews and segmentation checks.
- Monitoring reports showing alerts, responses and lessons learned from network‑related incidents.
An information security management system (ISMS) makes this much easier to manage in practice. Practitioners discussing continuous compliance often point out that without a structured management system, keeping policies, evidence and risk decisions aligned with specific controls quickly becomes unmanageable. By storing policies, diagrams, firewall baselines, change records and monitoring reports in one place and linking them directly to A.8.20 and relevant risks, a platform such as ISMS.online can help you assemble audit packs and answer customer questionnaires quickly without hunting through scattered files.
In ISMS.online you can, for example, link your A.8.20 firewall standard, network diagrams and change records directly to the control entry and associated risks, so your engineers, auditors and customer account teams can all see how the evidence fits together.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Common weaknesses and how to fix them without breaking services
Most MSPs discover similar weaknesses when they first map themselves against A.8.20, and many of those weaknesses come from earlier growth phases rather than bad intent. Industry articles on network segmentation and firewall hygiene regularly highlight flat networks, shared management paths and broad rules as recurring mistakes, so you are unlikely to be alone in what you find. If you approach these issues in a risk‑based, phased way, you can strengthen your network posture without creating outages or overwhelming your teams.
Two‑thirds of organisations in the 2025 ISMS.online survey say the speed and volume of regulatory change are making compliance harder to sustain.
Many MSPs share similar problems when they first assess themselves against A.8.20:
- A largely flat internal network with only superficial VLAN use.
- Shared management interfaces sitting on production networks or exposed to the internet.
- Broad “any‑any” firewall rules left over from past troubleshooting or rushed deployments.
- Untracked lab, test or legacy networks that bypass current standards.
- Inconsistent logging and monitoring across firewalls and key zones.
These weaknesses increase the risk that a single compromise spreads quickly, that changes go unnoticed and that you cannot convincingly answer customers’ questions about isolation and governance.
A short comparison of typical weaknesses, their risks and first fixes can help you prioritise work.
| Common weakness | Associated risk | First fix |
|---|---|---|
| Flat internal network | Lateral movement across many systems | Introduce core VLANs and simple zones |
| Exposed management interfaces | Direct takeover of admin tools | Move to dedicated management networks |
| “Any‑any” firewall rules | Uncontrolled access between key zones | Log usage, then replace with narrower rules |
| Untracked lab or legacy networks | Hidden paths into production or tenants | Discover, document and bring under standards |
| Patchy logging and monitoring | Attacks or misconfigurations go unseen | Centralise key firewall and VPN logging |
If you fix only two things this quarter, start with flattening internal networks into zones and moving exposed management interfaces onto dedicated, well‑controlled paths.
You do not need to fix all of this overnight, and you should avoid changes that risk widespread outages. A pragmatic approach is to work in stages and keep each change reversible.
Step 1 – Prioritise by risk
Prioritise tenants, shared platforms and gateways where a compromise would cause the greatest harm to customers and your own business.
Start with tenants in regulated or high‑sensitivity sectors, shared management platforms and internet‑facing gateways where a failure would hurt most.
Step 2 – Stabilise before segmenting
Stabilise your current networks by ensuring you have reliable configuration information, basic monitoring on key devices and proven fall‑back plans.
Make sure you have reliable asset and configuration information, basic monitoring on key devices and tested back‑out plans for major changes.
Step 3 – Introduce segmentation in layers
Introduce segmentation in manageable layers, beginning with management networks and then separating user and server zones for a small set of tenants.
Create management VLANs or VRFs first, then separate user and server networks in pilot tenants, and finally refine shared services enclaves and egress rules.
Step 4 – Use pilots and standard patterns
Use pilots and agreed patterns so your NOC and project teams can test new designs with a small set of tenants before wider rollout.
Test patterns with a small set of tenants before rolling them out widely, and adjust designs based on real operational feedback from engineers and customers.
Step 5 – Tackle “any‑any” rules over time
Reduce “any‑any” rules gradually by logging how they are used, replacing them with specific permits and then removing the broad rules once you are confident.
Log how broad rules are used, replace them with specific permits and monitored denies, and review results before removing temporary allowances.
With each improvement, update your diagrams, standards and evidence. A.8.20 is about ongoing management, not a one‑time redesign, and treating fixes as an incremental programme makes it easier to maintain service quality while you harden the estate.
Book a Demo With ISMS.online Today
ISMS.online can help you turn A.8.20 from a technical headache into a structured, evidence‑backed part of your ISO 27001 programme that your engineers, auditors and customers can all understand. By bringing your network policies, standards, diagrams, firewall configurations and change records together in one workspace, and by treating A.8.20 as a repeatable programme rather than a one‑off project, you can follow a simple roadmap that moves from understanding to patterns to operation and evidence so your networks become safer, your audits smoother and your enterprise sales conversations more confident; bringing Annex A.8.20 to life in a multi‑tenant MSP really can be summarised as a straightforward, if multi‑step, journey that your technical leaders and engineers can follow together.
Despite rising pressure, almost all respondents in the State of Information Security 2025 report list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.
Step 1 – See the reality
See the reality of your current networks by mapping where tenants, internal systems and management planes overlap and how traffic flows between them.
Map your existing networks, identify where tenants, internal and management planes overlap, and quantify both security and business risks.
Step 2 – Define what “good” looks like
Define what “good” looks like by translating A.8.20 and related controls into MSP‑specific outcomes and documenting your three‑plane model and firewall baselines.
Interpret A.8.20 and related controls into MSP‑specific outcomes, adopt the three‑plane model and write down your segmentation and firewall baselines.
Step 3 – Design repeatable patterns
Design repeatable patterns so your NOC, project teams and architects can implement the same proven designs across many customers and platforms.
Create reference architectures for per‑tenant segmentation, shared services and admin access, standardise firewall rules and decide how cloud and on‑premises environments fit the same patterns.
Step 4 – Implement and operate
Implement and operate your patterns in phases, starting with the highest‑risk areas and ensuring that monitoring and reviews keep the design honest over time.
Roll out segmentation and firewall baselines in phases based on risk, centralise logging and monitoring at key boundaries and run regular reviews to refine the design.
Step 5 – Evidence and improve
Evidence and improve by assembling a reusable A.8.20 evidence set and reviewing it whenever your business, technology stack or regulatory environment changes.
Assemble a reusable A.8.20 evidence set, link it to risks and the Statement of Applicability, and revisit the design after significant business, technology or regulatory changes.
If you support this journey with a structured ISMS, you make it much easier to keep architecture, operations and documentation in sync. An ISMS platform such as ISMS.online can help you link your A.8.20 policies, network standards, diagrams, change records and monitoring evidence directly to the control, so you can demonstrate security in ways that satisfy customers, auditors and regulators.
For your NOC and project teams, that means less time hunting for documents, clearer patterns to implement and fewer surprises in audits and customer reviews.
Over time, this combination of clear design, disciplined operation and well‑organised evidence can help turn A.8.20 from a checkbox into a commercial strength, supporting fewer cross‑tenant incidents, smoother enterprise sales and a more convincing storey for insurers and partners who depend on your network to protect their own business.
If you want to see how this looks in practice, you can book a demo with ISMS.online and explore how your A.8.20 network security storey can be designed, operated and evidenced in one place.
Book a demoFrequently Asked Questions
How should you treat ISO 27001 A.8.20 when you design or review an MSP network?
You should treat A.8.20 as a design and operating standard for your whole MSP network, not just a “firewall checkbox.” It expects you to show that segmentation is intentional, that boundaries are controlled, and that day‑to‑day operation consistently protects customer and corporate information.
What does “good” look like for A.8.20 in a managed service environment?
A practical way to think about A.8.20 is that it is testing four things:
- You have clearly defined network zones with a purpose (corporate, tenant, management, shared services).
- Those zones are separated by enforced boundaries (firewalls, ACLs, routing, identity‑aware controls).
- You operate, monitor and review those boundaries on a schedule, linked to risk.
- You can explain and evidence all of the above to an auditor or enterprise customer in minutes, not weeks.
A simple litmus test is this: if someone new joined your organisation tomorrow, could you give them one or two diagrams, a short network security standard and a handful of examples (change tickets, reviews, alerts) that allow them to understand how traffic is supposed to flow? If the answer is yes, you are already close to what A.8.20 expects; if the answer is “it’s in people’s heads,” A.8.20 is your prompt to capture that knowledge and run it through your Information Security Management System (ISMS).
How does A.8.20 interact with other ISO 27001 clauses and Annex A controls?
A.8.20 is part of a web of requirements that all reinforce each other:
- Clause 4.3 (scope): defines which network segments, platforms and tenants fall inside your ISMS.
- Clause 6.1 (risk assessment and treatment): explains why you chose particular segmentation patterns, technologies or cloud constructs.
- Annex A.8.21 and A.8.22: deal with how network services and segregation are run in everyday operations.
- Annex A.5.23 (cloud services): covers how public cloud constructs (VPCs, VNets, peering) align with your segmentation model.
- Annex A.5.24–A.5.27 (incident management): become relevant when a network weakness leads to an event or incident.
When your Statement of Applicability, network policy, risk records and diagrams tell the same storey, A.8.20 stops being “the firewall control” and becomes the visible network layer of your wider ISMS. Using a platform such as ISMS.online makes that easier because your policies, risks, diagrams, configurations and reviews can all be linked back to the control in one place.
How can an MSP design a three‑plane network that satisfies A.8.20 and still works under pressure?
Designing a three‑plane network that engineers can live with means isolating corporate, tenant and management environments while keeping workflows practical. A.8.20 doesn’t mandate specific technologies; it asks you to show that those planes are separated on purpose and joined only where the business can justify it.
What are the essential elements of a three‑plane MSP design?
A robust three‑plane design usually includes:
- Corporate plane: – identity services, email, HR and finance systems, collaboration tools and your own line‑of‑business applications.
- Tenant plane: – per‑customer networks and workloads, segmented by VLANs, VRFs, VPCs/VNets or similar constructs, with clear trust boundaries between tenants.
- Management plane: – remote monitoring and management tools, hypervisor consoles, network device admin interfaces, backup and observability platforms.
The crucial point for A.8.20 is that traffic between these planes is forced through well‑defined gateways where you can enforce least‑privilege rules and log activity. For example, engineers might connect from hardened endpoints, into a secured operations VPN, then through a jump host into the management plane, instead of accessing devices directly from office LANs or the internet. When every new tenant uses a repeatable pattern and every engineer follows the same on‑ramp, the architecture becomes easier to secure, explain and audit.
How can you stop segmentation turning into an unusable maze for your engineers?
Segmentation fails when it is so complicated that people feel forced to bypass it. To keep it workable:
- Define a small set of standard tenant blueprints with published diagrams and port matrices, then reuse them.
- Create shared service zones for things like monitoring, backup, authentication and logging, with clear rules on who can talk to them.
- Provide a limited number of “admin on‑ramps” (for example, two regional secure access points) rather than bespoke paths for every engineer.
- Automate routine tasks such as VPN profile deployment, jump host access and privileged session recording so that the secure path is also the easiest one.
Documenting these patterns inside your ISMS, and linking them to Annex A.8.20, gives teams an authoritative reference. In ISMS.online you can attach the diagrams, standards and access procedures to the control and keep them aligned with change management, so engineers see one coherent picture rather than a moving target.
Which firewall and routing standards matter most for A.8.20 in a multi‑tenant MSP?
For A.8.20, your firewall and routing standards are the concrete expression of “network segregation.” The control is less interested in brand names and more interested in whether you apply a consistent baseline everywhere and can demonstrate that it is followed.
What should be in an A.8.20‑aligned firewall and routing baseline?
An effective baseline for a service provider typically covers:
- A default‑deny posture, with only explicitly permitted flows allowed and every rule tied to a documented need.
- North–south controls: (internet and inter‑site traffic): use of stateful inspection, DNS security, DDoS controls, reputation or geography‑based blocking where proportionate.
- East–west segregation: (inside and between tenants, corporate and management): restrictions on lateral movement, separation of user and server networks, and strict isolation of privileged systems.
- Administrative access controls: where from, how and by whom management interfaces may be reached, including multi‑factor authentication and device hygiene requirements.
- Logging and oversight: minimum log sources and retention, correlation into SIEM or log platforms, thresholds for alerting and a defined review cadence.
The same ideas apply in cloud as on‑premises: network security groups or cloud firewalls should follow the same principles as physical devices. Capturing this baseline as a formal standard in your ISMS and mapping it to Annex A.8.20 gives you something concrete to point to when auditors or customers ask how you govern network controls across different platforms.
How do you keep firewall and routing policies under control as you grow?
Without discipline, rule sets will grow to the point where nobody can safely change them. To stay in control:
- Require every rule to have an owner, a business justification and a review or expiry date.
- Use objects, groups and templates for recurring patterns (for example, a standard set of ports to a shared backup service) instead of creating one‑off entries per tenant.
- Schedule regular reviews that highlight risky patterns such as wide source/destination ranges, any‑any rules or long‑unused entries, and tie those reviews to actions in your ISMS.
- Make it easy to see which rules are linked to which risks and services so people can change them confidently when business requirements evolve.
By storing standards, change records and review outputs in a single ISMS platform such as ISMS.online, you can trace a line from risk assessment through to configuration and back again. That traceability is often what reassures auditors that your A.8.20 controls are not just well‑intentioned but actually maintained.
What evidence does an MSP need on hand to satisfy auditors and customers about A.8.20?
For A.8.20, strong evidence is about showing your intent and your practice in a way that is compact but convincing. Most auditors and enterprise security teams want to understand your model quickly, then drill into specific examples.
Which artefacts give the clearest picture of your network segregation?
Evidence packs that land well with auditors and customers usually include:
- A network security policy that sets expectations for segmentation, firewall management and admin access across the estate.
- A segmentation and firewall standard that describes your planes, zones and the kinds of controls at each boundary.
- A small number of core diagrams – for example, one high‑level architecture view and one representative tenant layout, with trust boundaries and traffic flows marked.
- An inventory of key network components, including edge firewalls, core switches, VPN gateways, cloud security controls and remote access infrastructures.
- Recent change records: for material ruleset updates or topology changes, showing approvals and links to risk decisions or customer commitments.
- One or more review records where you have assessed logs or rulesets, found issues, taken action and recorded the outcome.
If you use ISMS.online, each of these artefacts can be linked directly to Annex A.8.20 and related controls, so when someone asks for an explanation you can export or share a curated pack rather than starting from a blank page. That saves time and also reduces the risk of inconsistent answers across different questionnaires and audits.
How can you make A.8.20 evidence reusable instead of rebuilding it every year?
The easiest way to make evidence reusable is to treat it as a library with version control:
- Keep core documents (policies, standards, reference diagrams) as controlled items in your ISMS, with clear owners and review dates.
- Tag technical artefacts (configuration extracts, firewall screenshots, ticket histories) against the controls they support, so you can pull them into different packs without duplication.
- Define a small number of standard evidence bundles – for example, “ISO 27001 network pack,” “enterprise due‑diligence pack” – and refine them after each major audit or assessment.
Working like this means that each surveillance audit or large customer questionnaire becomes an opportunity to improve the library, not an exercise in reinventing it. ISMS.online is built around this idea, allowing you to attach updated artefacts to the same control and keep your A.8.20 storey current without losing previous context.
Which recurring A.8.20 weaknesses do MSPs face, and how can they reduce risk without causing outages?
Most MSPs find that A.8.20 exposes similar patterns of weakness: organically grown internal networks, shared admin paths that cut across tenants, permissive rules that were added “just for testing,” lightly governed lab environments and inconsistent monitoring of core devices. These issues tend to accumulate quietly until a security review or incident makes them visible.
How can you reduce A.8.20 risk in a way that operations teams can accept?
A pragmatic improvement plan respects the fact that you are running a live service:
- Start with visibility: make sure you have current diagrams, accurate device inventories and working configuration backups before you touch anything.
- Rank weaknesses by impact and exposure: prioritise internet‑facing points, shared platforms and high‑value tenants.
- Stabilise admin access: move management interfaces behind controlled access points, strengthen authentication and reduce the number of paths engineers can use.
- Tighten permissive rules gradually: add logging, observe real use, agree narrower rules with service owners and only then remove the broad entries.
- Handle labs and legacy: either bring them under the same standards or isolate them as untrusted zones with limited, well‑documented connectivity.
Each change should be logged as a risk treatment and a formal change in your ISMS, with updated standards and diagrams attached. Managing this in ISMS.online lets you present the whole storey – problem, decision, change and evidence – when someone asks what you have done to strengthen Annex A.8.20 over the last year.
How can you turn A.8.20 improvements into a positive message for customers?
Rather than waiting for customers to discover weaknesses during due‑diligence, you can position your A.8.20 work as part of a continuous improvement storey. Explaining, in customer‑friendly language, that you have identified certain risks, applied new controls and validated the results signals maturity and transparency. Sharing selected artefacts – such as updated diagrams, new admin access procedures or summaries of rule reviews – through a controlled portal reassures buyers that you are not just compliant today but are actively investing in better segregation and network governance.
How can an MSP plan and execute a safe migration from a flat network to an A.8.20‑aligned architecture?
A successful migration from a flat or loosely segmented network to an A.8.20‑aligned architecture is more about sequence and governance than about shiny new hardware. The most resilient programmes favour small, well‑understood steps with clear outcomes, over ambitious redesigns that try to change everything at once.
What phased approach works best for most MSPs?
A sensible sequence often looks like this:
- Document and stabilise the present: confirm configuration backups, ensure monitoring is in place on key devices and validate rollback plans.
- Create or harden the management plane: introduce dedicated networks or VRFs for management traffic, and reduce admin entry points to a small, controlled set.
- Segment priority tenants and shared services: choose a manageable subset of critical customers and shared platforms, apply the three‑plane model, and refine firewall baselines and service enclaves around them.
- Extend the pattern across the estate: roll out the proven design incrementally to the wider tenant base and to internal systems, consolidating rules and decommissioning obsolete connectivity as you go.
- Integrate everything into your ISMS: update standards, diagrams, risk entries and evidence as each wave lands so that Annex A.8.20 reflects the real network, not just a slide deck.
Running the programme this way lets your teams learn from each wave, update playbooks and shorten the time between design and value. It also gives you more chances to validate that new controls behave correctly before larger tenants are moved.
How does an ISMS platform keep a multi‑year A.8.20 uplift on track?
Over several years, people and platforms change; your ISMS is what keeps the intent and the evidence coherent. With a platform such as ISMS.online you can:
- Maintain a target architecture standard and associated blueprints as controlled documents.
- Link each change, project or migration wave directly to Annex A.8.20 and related controls, with references to the risks being treated.
- Attach evidence – such as configuration snapshots, test records, review outputs and incident lessons learned – to the relevant controls and risks.
- Generate consistent reports and evidence packs for auditors, customers and internal governance, using the same underlying data.
When you handle A.8.20 in this way, you are not only meeting a control requirement; you are building a visible, repeatable way of running network security as part of your Information Security Management System. That sends a strong signal to customers and stakeholders that your MSP takes long‑term stewardship of their environments seriously and has the structure in place to keep improving.
