Why Cross‑Tenant Exposure Is the New Flat Network Problem
Cross‑tenant exposure is the modern version of a flat network because it lets one breach spread across customers and environments. When networks are not properly segregated, an attacker who compromises one tenant can pivot into others, turning a contained incident into a platform‑level crisis. Strong, risk‑based segregation reduces this blast radius so that one tenant’s problem stays one tenant’s problem, even under regulatory scrutiny and customer pressure.
Strong tenant boundaries turn one incident into one contained incident, even when defences are not perfect.
Cross‑tenant exposure now often means moving from one customer, business unit or partner space into another across shared cloud and SaaS infrastructure. If you treat Annex A.8.22 as a strategic way to contain blast radius, not just a VLAN housekeeping rule, you dramatically cut the impact of the breaches you cannot fully prevent and give auditors a clearer storey about how you protect each tenant. Plain‑language ISO 27001 guides for A.8.22 describe this control in exactly these terms: grouping systems and users into zones based on risk and tightly managing the flows between them, rather than relying on a single flat network.
From Flat Networks to Shared Fabrics
Flat networks gave attackers a simple advantage because compromise of one host often meant easy access to everything else. Segregation reduced that advantage by carving the network into separate zones with controlled paths between them, but modern shared fabrics have reintroduced many of the same lateral‑movement opportunities in more complex forms.
You may have broken that model up with VLANs and firewalls, but your architecture has also shifted into shared Kubernetes clusters, multi‑tenant SaaS, cross‑connected VPCs and managed services that blur the old inside/outside line.
You now have to answer a tougher question than “can an attacker move from user LAN to domain controller?”. You must show how you stop them pivoting from tenant A’s workloads to tenant B’s, or from development environments into production, across shared fabrics.
Every peering link, security group, shared logging service or admin VPN is a potential path. When you look at Annex A.8.22 through that lens, it becomes the control that demands you design those fabrics so that each “neighbourhood” is safely fenced off from the rest and that you can demonstrate those fences to auditors and customers.
Why This Matters to CISOs, Consultants and Operators
Senior security leaders care about cross‑tenant exposure because it dictates how far any compromise can spread across tenants and environments and how serious the regulatory, contractual and reputational impact will be. For CISOs, it is about more than individual vulnerabilities; it defines how a single incident could turn into a systemic platform failure that undermines your entire trust storey.
Cross‑tenant incidents are particularly painful because they undermine your core value proposition: if one customer’s issue affects another customer’s data or availability, your platform’s trust storey collapses and breach notifications may span several jurisdictions.
Only about one in five organisations in the 2025 ISMS.online survey reported that they had experienced no data loss.
Consultants and internal auditors see the same gap from another angle. They often find organisations with good policies and some decent firewalls, but no coherent storey for how tenant isolation is enforced end‑to‑end. That is where A.8.22 bites: it links high‑level risk analysis to a concrete question auditors will ask you directly: “If an attacker compromises this tenant, how exactly are they prevented from reaching another?”
For your network and platform teams, this translates into day‑to‑day design and change decisions: which networks and clusters tenants can share, how shared services are fenced off, and which connectivity requests you must push back on because they weaken isolation.
What ISO 27001:2022 Annex A.8.22 Really Asks For
Annex A.8.22 expects you to separate systems and users into network zones based on risk, and to tightly control the traffic that crosses those zones. In practice, this is the ISO 27001 control that turns your Clause 6 risk assessment and Statement of Applicability into specific choices about which tenants, environments and services share networks, which must be separated, and how you justify and monitor every permitted flow between them so that auditors can trace decisions back to documented risks. Independent ISO 27001 implementation guides on A.8.22 explain the same idea: you design zoning based on risk and then use controls to constrain and monitor flows between those zones.
Plain‑English Wording and Intent
At heart, A.8.22 says that systems, services and users with different security needs must not sit in one big flat network. Instead, you divide your environment into zones aligned to sensitivity and business function and allow only justified, documented traffic across those boundaries. This is how your network design shows auditors and regulators that you have implemented the risk‑based separation implied by your ISO 27001 risk assessment and Statement of Applicability.
In plain terms, A.8.22 expects you to:
- Group by sensitivity: – keep highly confidential or critical systems away from low‑risk ones.
- Group by business function: – separate functions such as finance, HR and engineering where appropriate.
- Respect tenant boundaries: – isolate customer, partner and internal “tenants” that expect separation.
- Justify flows: – allow only well‑defined, documented traffic between zones.
This model gives you a simple checklist for testing whether your segregation design really reflects your risk picture.
This is why treating A.8.22 as “we have some VLANs” falls short. Segregation is not about drawing arbitrary lines; it is about deliberately grouping by sensitivity, business function and tenant so a failure in one group cannot easily impact another. That design work should flow directly from your risk assessment and be reflected in your Statement of Applicability.
As a simple example, production payment‑processing systems should never share a network segment with low‑value test workloads or general office endpoints; the risk and obligations are too different.
How A.8.22 Connects to Other Controls
A.8.22 does not stand alone; it interacts with other Annex A controls and core ISO 27001 clauses. Understanding those connections helps you avoid gaps and duplication and gives you stronger answers in audits.
A.8.20 on network security expects you to protect traffic between networked services, such as enforcing strong encryption and integrity for admin connections across zones. Analyses of the 2022 updates from security vendors highlight that A.8.20 is specifically about securing data in transit and controlling network paths between services, not just putting a firewall at the edge.
A.5.23 on cloud services expects you to manage risks from external providers, including how your segregation model relies on provider constructs such as accounts, VPCs or projects. Shared‑responsibility models from major cloud platforms underline that customers remain responsible for many of these isolation decisions, even when the underlying infrastructure is run by the provider.
If you use cloud or SaaS, network segregation is often implemented partly by the provider and partly by your organisation. A.8.22 is where you show how those responsibilities join up: which isolation features you rely on from the platform, and which you add yourself with routing, firewalls, security groups or service meshes.
It also intersects with access control and change management. Role‑based access control is easier to operate safely when users are grouped into zones that mirror roles. Change management is more effective when any new route, VPN, peering or firewall rule is assessed for its impact on existing separation. When you talk about A.8.22 with engineers, position it as the piece that ensures new connectivity does not quietly undermine all the other good work.
Scope Decisions That Change Your Obligations
In a modern environment, the practical meaning of “network” extends far beyond classic on‑premises links. You have to decide whether your scope includes cloud VPCs, SD‑WAN, service meshes, management planes, inter‑site links and VPNs, and you must be explicit about who counts as a “tenant”: external customers, internal business units, partner teams and suppliers who share infrastructure. Those decisions directly affect your obligations and the audit questions you will face.
Defining these terms up front is not just a documentation exercise. The way you set boundaries affects contracts, customer expectations and audit scope. A shared platform used by several business units may not be called “multi‑tenant” in marketing, but it behaves like one from a risk perspective. If those units are subject to different regulations or levels of scrutiny, your segregation storey has to reflect that.
Two-thirds of organisations in the State of Information Security 2025 survey said that the speed and volume of regulatory change are making compliance harder to sustain.
Auditors will typically ask you to show which parts of your estate are in scope for A.8.22, how these zones are defined, and how you ensure that new connectivity does not extend the blast radius beyond what you intended. ISO 27001 consulting material on A.8.22 and related audits consistently stresses the need to define which networks, sites and fabrics are included in scope and to be ready to walk assessors through those zone boundaries.
Designing With Evidence in Mind
You can make A.8.22 much easier to defend at audit if you design your segregation model with evidence in mind from the beginning. That means thinking about what you will show to an assessor while you design the zones and flows.
Auditors usually look for three things: a policy or standard that describes your zoning approach, diagrams that make the zones and flows visible, and configuration or test evidence that shows those flows are actually enforced in practice. Major cloud providers follow the same pattern in their own ISO 27001 attestations, publishing policies and standards, architectural diagrams and representative configuration or test results to demonstrate how segregation is implemented and verified.
You do not need to drown everyone in low‑level firewall dumps. Instead, aim for a clear chain: risk rationale → zoning standard → high‑level diagrams → representative rule sets and tests. An auditor will often say, “Show me how tenants are separated here,” and expect you to move smoothly from a diagram to concrete examples of enforced rules or test results that prove the separation works.
A platform such as ISMS.online can help by linking your A.8.22 policy, risk entries, diagrams and technical evidence in one place, so you are not scrambling across wikis, ticket systems and screenshots every time someone asks about tenant separation. That connected storey is particularly valuable when regulators or large customers ask how your control implementation supports your risk assessment and legal obligations.
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.
Multi‑Tenancy 101 and What Cross‑Tenant Exposure Means
Multi‑tenancy means a single platform serves multiple customers or groups, and cross‑tenant exposure is when one of them can see, affect or infer another tenant’s data or services. Because modern platforms share so much underlying infrastructure, you cannot assume tenants are isolated just because your application logic says they should be; A.8.22 forces you to look beyond application‑level isolation and examine whether your networks and shared infrastructure really enforce those tenant boundaries in ways you can explain to auditors and customers.
What Multi‑Tenancy Looks Like in Practice
In practice, multi‑tenancy shows up wherever different customers, business units or partner teams share underlying infrastructure, from shared data centres to cloud accounts and Kubernetes clusters. To assess A.8.22 properly, you first need to recognise where that co‑location happens today.
On‑premises, several business units may share switches, hypervisors and management networks. In cloud and SaaS, different customers’ workloads run on the same physical hosts, within the same accounts, clusters or virtual networks.
Kubernetes namespaces, serverless functions, shared API gateways and message buses all introduce tenancy at additional layers. Common patterns you might recognise include:
- Multiple internal units sharing one data centre or private cloud.
- Several customers hosted in a single cloud account or subscription.
- Many tenants running as namespaces or services in shared clusters.
This simple list helps you spot where tenants are already co‑located before you look at the controls.
The key point is that each tenant expects logical isolation, whether or not you call them “tenants” in your documentation. Finance and HR might share a platform but need strict separation; two external customers using your SaaS absolutely must not see each other’s records. When you map multi‑tenancy, you are really answering “who believes they are separate from whom?” and then checking whether your networks respect that belief in ways that would stand up in an audit or regulatory investigation.
How Cross‑Tenant Exposure Actually Happens
Cross‑tenant exposure is rarely caused by a single dramatic firewall rule; it usually emerges from a series of small, individually reasonable decisions that together create an unexpected path. Understanding these patterns is essential if you want to reduce real risk rather than just redraw network diagrams.
A shared logging or monitoring system might sit in a network reachable from several tenants. A hastily created peering connection may allow routes to overlap. A security group might be broadened to “fix” an incident, then never tightened again.
Identity and control‑plane flaws play a big part too. Over‑permissive admin roles and automation accounts can reconfigure network components across tenants. Misuse of tags or labels in policy engines can cause rules intended for one tenant to apply to another. Even when application code correctly checks tenant IDs, the infrastructure below may still allow one tenant to send traffic into another’s network segment.
A simple illustrative scenario is a shared logging stack that lives in a flat “monitoring” subnet. If one tenant’s compromised host can talk to that subnet, and the logging service is not strict about tenant identity, an attacker may be able to request or infer log data from other tenants. That sort of quiet cross‑tenant leak is exactly what A.8.22 is meant to prevent and that regulators and large customers increasingly question during due‑diligence reviews. European cloud‑security guidance, such as material published by ENISA, specifically calls out tenant isolation and cross‑tenant paths as topics for assessment when evaluating shared‑infrastructure risks.
Thinking through these scenarios in calm times is the only way to prevent them. Ask, for each shared component or connection, “If tenant A is compromised, what stops an attacker using this to reach tenant B?” If the honest answer is “nothing very strong”, you have just uncovered an A.8.22 design gap-and a risk that could directly undermine customer trust in your promise of separation.
The Main Cross‑Tenant Risk Categories You’re Up Against
Cross‑tenant risk is not just “data could leak”; it includes several distinct categories that affect confidentiality, integrity, availability and shared‑technology exposure. When you understand these categories, you can design segmentation that addresses real failure modes rather than generic “network security”, and you can show regulators and customers that you have thought about tenant isolation in a structured, risk‑based way.
Four Core Risk Categories
You can treat cross‑tenant risk as four broad categories that you can systematically check and design for. These categories are: data leakage, abuse of shared services, shared‑technology weaknesses and blast‑radius or availability issues.
- Data leakage: – one tenant gains access to another tenant’s data.
- Abuse of shared services: – misuse of shared identity, logging or admin planes.
- Shared‑technology weakness: – flaws in hypervisors, containers or hardware.
- Blast‑radius and availability risk: – one tenant’s behaviour degrades others.
This model gives you a simple checklist for testing whether your isolation storey is complete.
Data leakage covers cases where one tenant gains direct or indirect access to another tenant’s information through misrouted traffic, shared databases, caches or storage. Abuse of shared services arises when a tenant can manipulate a shared identity provider, logging system or API gateway in ways that affect others.
Shared‑technology risk is where vulnerabilities in the hypervisor, container runtime or hardware break isolation even when the network looks correct. This is partly addressed by choosing reputable providers and keeping underlying platforms patched. Blast‑radius risk is where one tenant’s behaviour-accidental or malicious-overwhelms shared components and degrades service for others. Distributed denial‑of‑service attacks, resource exhaustion and misconfigured control planes sit here.
Network segregation primarily targets the first two categories, with some effect on the fourth. It makes it much harder for traffic intended for one tenant to reach another, and it encourages careful treatment of shared services. It also helps contain some consequences of shared‑technology failures by adding additional boundaries an attacker must cross to exploit them. Practitioner explainers on ISO 27001 control 8.22 make the same point, positioning segregation as a way to prevent data paths between tenants and to harden shared services, with secondary benefits for availability and blast‑radius control.
Legal, Regulatory and Customer Impact
The consequences of cross‑tenant exposure are often severe because they affect many parties at once and draw regulator and customer attention to your technical and organisational measures. That scrutiny frequently includes direct questions about tenant separation and network segregation.
The 2025 State of Information Security survey found that a majority of organisations had been impacted by at least one third-party or vendor security incident in the past year.
If data from one customer is exposed to another, you may face breach‑notification obligations in multiple jurisdictions at once, along with contractual penalties and intense scrutiny of your tenant isolation design. Overviews of cloud‑security and privacy standards note that providers frequently have to navigate overlapping notification regimes when incidents involve data stored or processed across borders, which is exactly the situation you want to avoid with strong segregation.
Regulators increasingly expect platform providers to demonstrate robust tenant isolation, not just general security hygiene. When you can point to a risk‑based A.8.22 implementation, backed by clear zones and well‑described flows, you provide a stronger answer when regulators and auditors ask, “What technical and organisational measures prevent cross‑tenant access?” Guidance from European cloud‑security bodies such as ENISA explicitly highlights isolation and shared‑infrastructure risks as topics that should be covered in cloud‑service risk assessments.
Customers care deeply about this too. Large buyers routinely ask questions such as “How are our environments separated from other customers?” and “What prevents another tenant’s compromise from reaching our data?” Clear, risk‑based answers, backed by diagrams and documented controls, differentiate you from competitors who simply say “we use VLANs and firewalls.” Cloud‑security explainers from major vendors describe these tenant‑separation questions as a standard part of due‑diligence on multitenant platforms, reflecting what your own customers are likely to ask.
Mapping Risks to Controls
It is useful to explicitly map these risk categories to mitigation techniques so you can see where A.8.22 fits and where you must rely on other controls. This is also a helpful way to structure conversations with auditors and internal risk committees.
The table below maps each risk to typical causes and example mitigations.
| Risk category | Typical cause | Example controls |
|---|---|---|
| Data leakage | Misrouted traffic, shared storage, broad security groups | Tenant‑aligned zones, strict routing, encryption in transit |
| Abuse of shared services | Shared logging, identity, admin planes with weak scoping | Dedicated service networks, mTLS, per‑tenant authorisation rules |
| Shared‑technology weakness | Hypervisor or container vulnerabilities, hardware flaws | Provider due diligence, patching, layered segmentation |
| Blast‑radius and availability | Noisy neighbours, shared control‑plane overload | Rate limiting, resource quotas, separate management zones |
Building this map forces you to say, in plain terms, “For each way tenants can hurt each other, what do we actually rely on?” That gives you a clear starting point for designing segmentation patterns and prioritising remediation, and it shows where network segregation must be supported by identity, platform and governance controls. Commentary on A.8.22 from security practitioners tends to group mitigations in similar ways, emphasising that segmentation alone cannot remove shared‑technology risks but is essential for restricting data paths and access to shared services.
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.
Designing Network Segregation for Multi‑Tenant Environments
Designing segregation for a multi‑tenant environment means agreeing how you want to carve up the world, then expressing that model consistently across data centres, clouds and orchestration platforms. You rarely get one perfect design; instead, you pick a small set of patterns that fit your risk picture and regulatory context and keep them simple enough that engineers do not accidentally break isolation when they make changes, while still being able to explain them clearly to auditors. A.8.22 is satisfied when this design is deliberate, risk‑based and demonstrable. ISO/IEC 27002 commentary for this control reinforces that message by describing segregation as a risk‑driven activity where you must be able to show how zoning decisions are implemented and verified in practice.
Define Tenant‑Aligned Zones First
Strong segregation designs start with zones and responsibilities, not with products or rule sets. You first identify the major “neighbourhoods” in your estate, decide which must never directly touch each other and which can connect through tightly controlled paths, then map those decisions into concrete constructs. This makes it easier to show auditors why each connection exists and how it was justified against your risk assessment.
You can structure this as a simple sequence:
Step 1 – Identify key zones
List tenant networks, shared services, management paths and environment layers such as development, test and production, so you can see where different risk profiles already sit together.
Step 2 – Describe purpose and data
For each zone, capture its role, data sensitivity, typical users and regulatory obligations in a short, consistent description that supports risk decisions.
Step 3 – Define allowed relationships
Document which zones may talk to which others and why, including protocols, directions and authentication expectations, so reviewers can assess new connections quickly.
Step 4 – Map to concrete constructs
Tie each zone to specific VLANs, VRFs, virtual networks, subnets or namespaces in your platforms, making it clear which technical objects implement each boundary.
These steps keep the design grounded in risk rather than in whatever configuration is easiest to implement at the time and give you a clear narrative for auditors and internal stakeholders.
That exercise may sound simple, but it flushes out hidden complexities. You might discover that your “logging” zone is accessed from every other zone without clear restrictions, or that management interfaces for several tenants live in a shared, poorly controlled network. Once zones are defined, you can map them to concrete constructs-VLANs and VRFs on‑prem, virtual networks and subnets in cloud, namespaces and network policies in Kubernetes-while preserving the same mental model.
Choose Segmentation Patterns That Fit Your Context
There is no single right answer to “How many VPCs should we have?” or “Should we use a VPC per tenant?”. What matters is that your choices are deliberate, documented and tied to risk so you can explain them to auditors, customers and your own teams.
In many environments, you end up choosing between patterns such as:
- Per‑tenant network accounts: – strong isolation, higher operational overhead.
- Grouped tenants per region or risk band: – efficient for many tenants, requires stronger micro‑segmentation.
This comparison gives you a way to discuss patterns without arguing about specific product names.
When comparing patterns, ask questions like: how easily can we prove to a sceptical customer that their tenant is isolated? What happens if a given network account is compromised? How painful is it to add a new tenant or region under each pattern? Explicitly tie those answers back to your risk categories. If a pattern makes it difficult to stop data leakage or to contain blast radius, no amount of local tweaking will fix it.
Design Shared Services Without Breaking Isolation
Shared services such as identity, logging, monitoring and backups are where many segregation schemes quietly fall apart. These components often sit between many zones and, if they are not designed carefully, become convenient bridges for attackers or faulty configuration and frequent sources of cross‑tenant exposure.
The goal is to design paths to these services so that every tenant can use them, but can never see or interfere with other tenants’ data or control planes. That usually means placing shared services in their own zones, with tightly defined ingress and egress rules, and enforcing strong authentication and authorisation on every call. For example, tenants might send logs to a central service over encrypted, mutually authenticated channels that include tenant identifiers, with separate storage or robust multi‑tenant access controls underneath.
At the network level, you ensure that tenants cannot talk to each other directly, only to the shared service, and that the shared service cannot initiate arbitrary connections back into tenant zones. Throughout this design work, keep A.8.22 in mind as your north star: you are not merely trying to make the network “work”, you are trying to ensure groups of services and users are properly separated, and that only justified traffic crosses the boundaries between them.
Misconfigurations That Quietly Break A.8.22
Many organisations have a reasonable high‑level design but still fail A.8.22 in practice because everyday changes undermine segregation over time. Misconfigurations and process gaps slowly re‑flatten networks until a penetration test, audit or real incident reveals that tenant boundaries are not as strong as the diagrams suggest. Understanding these patterns gives you practical checks you can run long before regulators or customers raise questions.
Cloud and Virtualisation Mistakes
Cloud environments make it very easy to create and change security groups, network ACLs, route tables and peering connections, which can quietly weaken isolation if they are not reviewed carefully. Under time pressure, engineers may broaden a rule to restore service, peer two networks to fix a connectivity issue, or reuse an existing subnet rather than create a new one.
The most common patterns include:
- Over‑broad security groups and ACLs: that span multiple tenants or environments.
- Ad‑hoc peering or VPNs: that quietly link previously separated networks.
- VLAN or subnet reuse: that overlaps test and production or multiple tenants.
These examples show how small, local fixes can gradually undo your original zoning model.
Virtualised data centres have similar problems. Trunk ports may carry more VLANs than originally intended. An admin might reuse a VLAN ID for a test environment that overlaps with a production tenant. Private connectivity for a new service might be created inside a management network rather than a separate zone. None of these changes are malicious, but they all weaken segregation in ways that are hard to spot from a static diagram.
A couple of quick checks you can run this week are: search for security groups or firewall objects that reference “0.0.0.0/0” and are attached to more than one tenant or environment, and look for peering or VPN connections where the permitted routes overlap tenant address ranges more than you expected.
Identifying these issues requires both technical checks and process discipline. Network path analysis tools, configuration comparison scripts and infrastructure‑as‑code scanning can reveal where actual paths differ from intended ones. Change‑management policies that require risk assessment for new routes, peering and shared services help ensure those paths are considered before they are implemented.
Process Failures That Undo Good Designs
Even the best technical design cannot survive without supporting process. Configuration drift is a natural outcome of fast‑moving teams, incidents and manual changes. If your organisation does not review network changes against zoning rules, or if exceptions are granted informally, A.8.22 will be eroded even if you passed your last audit.
Typical process gaps to watch for are:
- Uncontrolled configuration drift: from manual, undocumented changes.
- Weaker segregation in non‑production: that leaks patterns into production.
- Unmapped management paths: such as admin VPNs or remote support tunnels.
This list gives you a starting agenda for hardening the change process around A.8.22.
One common gap is environment parity. Development and staging may be much less segmented than production for convenience, so engineers test patterns that would not be allowed in live systems. Over time, those habits leak into production changes, often under the banner of “we did it in test and it worked.” Treating segregation requirements as non‑functional requirements in lower environments helps prevent this.
Another gap is the treatment of management paths. Admin VPNs, bastion hosts, remote support tunnels and orphaned test interfaces can often reach many tenants or zones, sometimes with powerful privileges. If they are not documented as part of your A.8.22 implementation, they will not be reviewed for cross‑tenant impact. Including these paths in your network diagrams, risk assessments and changes is essential.
Ultimately, A.8.22 is not a one‑time design exercise. It is an ongoing commitment to keep your real network in line with your intended segregation. Internal auditors and external assessors can often spot when your diagrams and documents describe one model and your actual configurations have drifted into something much flatter, especially when they compare configuration samples and change records against your stated zoning standards.
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.
Controls That Stop Lateral Movement Between Tenants
Preventing lateral movement between tenants is not about a single magic control; it is about combining several layers so an attacker has a hard time crossing each boundary. A.8.22 provides the network‑segregation layer, but you also need identity, endpoint and governance measures that support it, so cross‑tenant attacks become noisy, slow and easier to detect and contain, which is exactly what auditors and large customers look for in multi‑tenant platforms.
Layered Technical Controls
You can think about the technical side in four layers that work together rather than in isolation. Each layer reduces the attacker’s options and gives you more chances to spot and stop lateral movement before another tenant is affected.
At the base, you have coarse segmentation: per‑tenant or per‑group virtual networks, subnets, VLANs and VRFs with limited routes between them. On top of that you add micro‑segmentation using security groups, SDN policies, Kubernetes network policies or host firewalls to restrict which workloads can talk to which, even within a segment.
Zero‑trust principles add further strength. Rather than trusting traffic because it comes from a “trusted” network, you require strong authentication, authorisation and encryption between services. Identity‑aware proxies, service meshes with mutual TLS and fine‑grained access policies ensure that even if an attacker reaches a network where another tenant’s services live, they still struggle to do anything useful. Endpoint controls such as EDR, host firewalls and strict configuration baselines act as a backstop.
You can think of the technical stack in four layers:
- Coarse segmentation: – separate tenants and environments into distinct networks.
- Micro‑segmentation: – control which services can talk, even within a segment.
- Zero‑trust service access: – require identity and encryption for every connection.
- Endpoint hardening: – detect and block unexpected lateral‑movement attempts.
Taken together, these layers align with A.8.22’s intent by ensuring separation is maintained at multiple points, so a single misconfiguration is less likely to cause cross‑tenant exposure.
Governance, Testing and Monitoring
Technical controls only work as intended when they are embedded in everyday processes and verified regularly. Your aim is to make tenant isolation something you consciously design, test and monitor, not a one‑off diagram produced for certification.
Change management for networks should explicitly ask, “Does this change create a new path between tenants or zones?” and require justification and risk assessment when the answer is yes. Architecture review boards should include tenant isolation and A.8.22 impacts as standard questions whenever new services, shared components or connectivity patterns are proposed.
Testing is equally important. Periodic red teaming or targeted attack‑path simulations focused on cross‑tenant movement can reveal surprising paths and validate the effectiveness of your segmentation. Automated testing tools can attempt to reach one tenant’s resources from another’s and raise alerts when they succeed. Including these tests in continuous integration or regular operational checks makes tenant isolation a measured property, not an assumption.
Monitoring completes the picture. Logs and metrics from key choke points-inter‑zone firewalls, shared services, control planes-should be configured to highlight unusual connections between tenants or zones. For example, attempts by one tenant’s management accounts to access another tenant’s networks, or unexpected protocols flowing between supposedly isolated groups, should be easy to spot.
You can think of the governance loop as three ongoing steps:
Step 1 – Govern changes for isolation
Build tenant‑isolation questions into change and architecture reviews so new paths are assessed before implementation and recorded for audit.
Step 2 – Test isolation regularly
Use red teaming, automated attack‑path tests and scheduled checks to verify that A.8.22 segregation still holds and that diagrams match reality.
Step 3 – Monitor and respond
Instrument key choke points to detect suspicious cross‑tenant flows and respond quickly when they appear, feeding lessons back into design and policy.
For internal teams, a practical quick check is to pick one “flagship” tenant and deliberately try to reach another tenant’s environment in a controlled test. If that is easy to achieve, you have strong evidence that your A.8.22 implementation needs work.
Finally, someone needs to own all this. Assign clear responsibility for the health of A.8.22 within your ISMS, define metrics (such as the number of approved exceptions, results of isolation tests and frequency of segregation‑related incidents) and report them alongside other security indicators. Together, these controls make cross‑tenant movement both difficult and noisy, which is exactly the reduction in blast radius your customers and regulators expect.
Book a Demo With ISMS.online Today
A.8.22 delivers real value when your segregation design, risk decisions and technical evidence form a coherent storey that auditors, engineers and customers can all follow. ISMS.online helps you turn your Annex A.8.22 network‑segregation decisions into clear, connected evidence that auditors, engineers and customers can all trust. Instead of scattering zoning standards, diagrams, firewall exports and risk assessments across different tools, you can maintain them as a coherent storey in one environment that reflects how your organisation actually operates and how tenant isolation evolves over time.
Turn Segregation Design Into Evidence
A good segregation design loses value if nobody can see how it connects to risks, policies and live controls. In ISMS.online you can link zoning standards, risk entries, network diagrams, change records and test results directly to Annex A.8.22 and related controls like A.8.20 and A.5.23.
That lets you show, in one view, why certain tenants and services are separated, how that is implemented, and how you know it is still working. Because everything lives in a single ISMS, you can also keep it current. When a new VPC is added, a shared service changes, or a cloud provider introduces a new feature, you update the related risks and controls in the same place.
Over time, you build a living record of how tenant isolation has evolved, rather than a stack of spreadsheets that go stale after each audit. That record is exactly what auditors, customers and internal stakeholders want to see when they ask about A.8.22 and cross‑tenant exposure.
Plan Your Next Steps With ISMS.online
Planning how to improve A.8.22 in your own environment is easier when you can see how others structure their storey from risk assessment through to evidence. A guided view helps you decide what to do first instead of trying to fix everything at once.
In the 2025 ISMS.online survey, almost all respondents listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.
If you are preparing for ISO 27001:2022 certification, planning a transition from the 2013 version, or responding to customer pressure to prove tenant isolation, seeing a working example is often the fastest way to move forward.
A demo of ISMS.online can show you how other organisations structure their A.8.22 storey-from initial risk assessment through to diagrams, controls and monitoring-so you can adapt that pattern to your own context.
You can also use a trial workspace to map your current segregation posture: define zones, attach existing diagrams and evidence, and quickly see where links are missing. That exercise alone often reveals both gaps and strengths that were hard to articulate before. From there, you decide which issues to address first, which controls to standardise, and which stakeholders need to be involved.
If you want your network‑segregation work to reduce real cross‑tenant risk and stand up under audit, it helps to have an ISMS that makes those connections visible. ISMS.online gives you a practical way to show that Annex A.8.22 is more than a diagram-it is a living control that protects your tenants and your reputation, and if you would like to see that in action you can arrange a walkthrough when the timing is right for your team.
Book a demoFrequently Asked Questions
How can we tighten this FAQ set so it works harder for ISO 27001 and GTM at the same time?
Tighten each answer to a single clear job: reassure buyers and satisfy auditors in 300–450 words.
Where is this draught already strong enough to keep?
You don’t need to throw this work away. There’s a solid backbone you can keep almost intact:
- You explain A.8.22, tenant separation and lateral movement accurately.
- You use realistic examples (VPCs, security groups, CI/CD, bastions) that a practitioner will trust.
- You naturally follow the risk → design → operation → evidence line auditors expect.
- You’ve already made space to mention ISMS.online as the place that keeps that storey joined up.
From an ISO 27001 lens, an auditor could read this and believe you understand what A.8.22 is trying to achieve and how to evidence it.
Where is it missing the mark against your brief?
Measured against your own brief and personas, three gaps stand out:
- Persona targeting is implicit, not explicit
The voice is “good security architect”, but it doesn’t feel written to:
- Kickstarters: who want “step‑by‑step, help us pass first time”.
- CISOs: who care about resilience, board trust and cross‑framework reuse.
- Privacy/Legal: who care about defensibility and regulator‑ready artefacts.
- Practitioners: who just want fewer spreadsheets and less audit scramble.
Each answer should open with a line that makes one of those personas think, “This is for me.”
- ISMS.online is present, but under‑leveraged
You nod to the platform, but the copy doesn’t fully land the platform job:
- “One live place” where zoning standards, diagrams, rules, tests and reviews sit together.
- Linked risks ↔ controls ↔ changes ↔ tests ↔ audits, so A.8.22 is visibly “alive”, not a document.
A single, matter‑of‑fact line in each answer would make that much clearer without sliding into hype.
- Length and repetition blunt landing‑page performance
Several paragraphs loop the same idea (“A.8.22 runs from risk to design to operation”) from different angles. For a landing page, this risks skim‑and‑bounce, especially for Kickstarters scanning for “what do I say to my auditor?” or a practitioner looking for “how do I segment tenants quickly?”
You’ll get more engagement by cutting repetition and using that space to:
- anchor clearly to one persona per question; and
- move into new angles (cloud vs SaaS, per‑tenant vs shared, design vs drift).
You can keep all six questions, but give each a tighter, more specific job.
1. “How does ISO 27001 A.8.22 apply when we’re using shared cloud and SaaS platforms?”
Primary job: Reassure Kickstarters and CISOs that “shared platform ≠ shared blast radius” and give them a sentence an auditor will like.
- Lead with:
“A.8.22 expects you to show that shared cloud and SaaS never turn into a shared blast radius for tenants or teams.”
- Then split briefly for each persona:
- For Kickstarters: “This is what you say at audit in plain language.”
- For CISOs: “This is how you explain cross‑tenant risk and resilience to the board.”
- Add one ISMS.online line: where the zoning standard, diagrams and sample rules live so everyone can tell the same storey.
2. “How should we segment our network and identity layers to satisfy A.8.22 in a multi‑tenant setup?”
Primary job: Give practitioners a zone taxonomy they can copy without over‑explaining theory.
- Open with a one‑line answer:
“Use a handful of clear zones (edge, tenant, shared platform, management, corporate users) and keep admin identities separate.”
- Then:
- List the zones once.
- Show how you combine network and identity controls so “one mistake in one zone doesn’t spill into others.”
- One ISMS.online sentence: zoning standard, diagrams and example rules as an approved reference, so new engineers and suppliers can self‑serve.
3. “What misconfigurations most often break tenant separation, even when the design looks right on paper?”
Primary job: Make CISOs and practitioners nervous enough to care about drift, then show how to tame it.
- Open with:
“Designs usually fail quietly, through small misconfigurations that erode separation over time.”
- Pick 3–5 named patterns only (shared admin accounts, copied security groups, staging wired into production data, emergency firewall changes never closed, mis‑scoped identity roles).
- Then pivot quickly into process fixes:
- linked change records,
- lateral movement testing,
- periodic reviews.
- One ISMS.online line: A.8.22 as a living control with linked change records, tests and internal audit findings.
4. “Which supporting controls best reinforce A.8.22 for multi‑tenant environments?”
Primary job: Reframe A.8.22 for CISOs as a lateral‑movement strategy tied into the rest of Annex A, not a lone checkbox.
- Start with the idea:
“A.8.22 is strongest when it’s woven into identity, incident, continuity and privacy controls.”
- Use a short, narrative table or bullets mapping A.8.22 to a few key groups:
- A.5–A.6 (people/roles),
- A.8.1–A.8.5, A.8.20–A.8.22 (tech segmentation),
- A.5.24–A.5.28 (incident),
- A.5.29–A.5.30, A.8.13–A.8.14 (continuity),
- A.5.31–A.5.34 (legal/privacy).
- One ISMS.online line: show A.8.22 as one node in a control cluster with explicit links to those supporting controls and evidence.
Primary job: Give auditors and Privacy/Legal a neat list of artefacts and show how to keep them “just enough, always current.”
- Answer first:
“You don’t pass on diagrams; you pass because you can walk a simple trail from risk to reality.”
- Then outline the four evidence buckets (risk statement, design artefacts, operational controls, oversight).
- Emphasise “ten‑minute trail, not 40‑page pack”.
- One ISMS.online line: A.8.22 as a control record with those links and attachments, so you’re selecting, not scrambling, at audit time.
6. “How does A.8.22 fit into our overall ISMS and Annex L integrated management system?”
Primary job: Show all personas that A.8.22 is an IMS tile: it touches security, privacy, continuity and quality.
- Open with:
“A.8.22 is where tenant separation meets risk management, operations, privacy and continuity.”
- Map briefly to:
- ISO 27001 Clauses 4–8 (context, risk, planning, operation),
- Annex A clusters it belongs to,
- other Annex L standards it influences (e.g. ISO 9001, 22301, 27701).
- One ISMS.online line: A.8.22 registered once, then linked into risks, audits and actions across multiple standards and departments.
What specific edits will give you the most impact with the least change?
You can make this set “landing‑page tight” with a few targeted moves.
1. Trim to one clear job per answer
- Target 300–450 words per FAQ.
- Keep this shape:
- 1 sentence answer, under 20 words.
- 2–3 short paragraphs focused on:
- what the reader must understand,
- what the auditor will look for,
- how your organisation and ISMS.online make that easier.
Anything that doesn’t serve that job goes.
2. Rewrite openers to name the reader
Change generic openers like “A.8.22 expects you…” into persona‑aware lines:
- “As a Kickstarter, you need a plain way to say…”
- “As a CISO, you’ll care less about topology and more about…”
- “If you’re responsible for SARs or regulatory response, you’ll want to see…”
That single tweak makes each FAQ feel like it belongs on a GTM landing page, not just in a control manual.
3. Standardise the ISMS.online bridge
To avoid repetition but still land value, pick one pattern per question:
- “Store the standard, diagrams and examples against A.8.22 in ISMS.online…”
- “Link change requests, pen‑test findings and reviews to A.8.22 in ISMS.online…”
- “Model A.8.22 as one control node linked to identity, incident, continuity and privacy…”
- “Treat A.8.22 as a living control in ISMS.online, so evidence grows quietly between audits…”
You get consistent value signalling without feeling salesy.
4. Compress repeated explanations into a single phrase
Anywhere you currently restate the full chain “risk → design → operation → evidence”, compress it into a short phrase such as:
- “walk a simple trail from risk to reality”
- “show that the design still holds in day‑to‑day operation”
Use the saved space to introduce fresh angles:
- cloud vs on‑prem nuance;
- per‑tenant vs per‑environment separation;
- how A.8.22 interacts with privacy and records of processing.
Would you like a fully refactored set next?
If you confirm you’re happy for me to rewrite, not just critique, I can return:
- a complete six‑question FAQ set, each 300–450 words, structured for Kickstarters, CISOs, Privacy/Legal and Practitioners;
- strengthened, but calm, ISMS.online value lines in each answer;
- tighter phrasing that keeps all the technical truth on A.8.22 while reading like landing‑page copy, not an internal design document.
You can then paste it straight into your A.8.22 / multi‑tenant landing page and know it speaks equally well to auditors and buyers.
