ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27017 virtual machine hardening is one of the cloud-specific additions that separates this standard from a plain ISO 27001 programme. ISO/IEC 27017:2015 adds seven cloud controls to the ones in ISO/IEC 27002, and three of them deal with virtual environments: segregation between tenants, hardening of virtual machines and alignment between virtual and physical network security. Cloud providers and their customers both have work to do here, and assessors ask for different evidence from each.
This guide explains what the three controls ask, who does what, and how to gather evidence. It builds on our guides to ISO 27017, the shared responsibility matrix and ISO 27017 versus ISO 27018.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
A summary of the standard lists the seven additional controls as follows. The three that relate to virtualization are the focus of this article.
| Control | Title | Focus here |
|---|---|---|
| CLD.6.3.1 | Shared roles and responsibilities in a cloud computing environment | Background |
| CLD.8.1.5 | Removal of cloud service customer assets | Background |
| CLD.9.5.1 | Segregation in virtual computing environments | Yes |
| CLD.9.5.2 | Virtual machine hardening | Yes |
| CLD.12.1.5 | Administrator’s operational security | Related |
| CLD.12.4.5 | Monitoring of cloud services | Related |
| CLD.13.1.4 | Alignment of security management for virtual and physical networks | Yes |
The standard also modifies 37 existing ISO/IEC 27002 controls with implementation guidance for both the cloud service provider and the customer. Control numbers follow the 2015 edition. If you work with newer versions of related standards, map the numbering before you cite it in policy.
Segregation means that one customer’s virtual workloads cannot see or affect another’s. This is mainly a provider responsibility, but customers must check that the provider can show it. As a provider, describe how tenants are isolated at the hypervisor, network and storage layers, how you test the isolation and how you handle a suspected breach of isolation. As a customer, ask for evidence such as independent assurance reports, penetration test summaries and the provider’s description of its architecture.
Hardening means configuring virtual machines to reduce their attack surface. The control expects that whoever configures the machine, provider or customer depending on the service model, does so to meet the requirements for the intended use. In infrastructure-as-a-service, the customer usually configures guest operating systems, while the provider hardens the hypervisor and management plane. In platform and software services the provider takes on more of the work.
Many organizations use published configuration benchmarks as a starting point, and adapt them to their environment. Record which benchmark you used and why you deviate where you do.
Virtual networks should have security that matches the physical ones they connect to. A provider should be able to explain how virtual network configuration is governed and how changes are controlled. A customer should ensure that security groups, firewall rules and network zones in the cloud reflect the same principles as on-premises networks, for example separating production from development and limiting administrative access.
Keep network diagrams current, and review rules regularly. Stale rules that were opened for a test and never closed are one of the most common causes of exposure.
| Area | Cloud service provider | Cloud service customer |
|---|---|---|
| Tenant segregation | Designs, operates and tests | Seeks evidence and segments own workloads |
| Hypervisor and management plane hardening | Responsible | Assesses through supplier review |
| Guest VM hardening | Responsible for managed services | Responsible for IaaS guests |
| Virtual network rules | Governs the platform | Configures own security groups and zones |
Write these splits into your shared responsibility matrix and your contract, so nobody assumes that another party is covering a task.
Assemble this evidence ahead of the audit, and map each item to the relevant control in your Statement of Applicability.
Hardening and segregation duties should appear in the agreement between provider and customer. A good cloud service agreement states who configures each layer, what standards apply, how vulnerabilities are notified, how quickly critical patches are applied and how the customer can obtain assurance. Customers should ask for the right to receive independent reports and to be told about changes that affect isolation. Providers should describe their commitments precisely, since vague language leads to disputes and audit findings.
If personal data is processed in the environment, the same architecture supports the controls in ISO 27018. See our guides to ISO 27018 and the PII processor role for how the two standards fit together.
Manual checks do not scale in cloud environments, where machines appear and disappear in minutes. Use infrastructure as code to define the machine configuration, and keep the definitions in version control with review and approval. Add automated checks that compare running systems to the baseline and raise alerts for drift. Record the rules you enforce, the results of scans and the way you handle exceptions. Automated evidence is easier for assessors to sample, and it shows that ISO 27017 virtual machine hardening is a continuing process, not a one-off exercise before the audit.
Include container and serverless workloads in your thinking. Although the standard speaks of virtual machines, the same principles of minimal images, patching, access control and logging apply to those services, and assessors increasingly ask about them.
Finally, train the people who build and operate the environment. Engineers should know why the baseline exists, how to request an exception and what evidence they must leave behind. Short, practical sessions with real examples of misconfigured machines are more effective than policy readings.
Most of the effort lies in building the baseline and the evidence trail, not in new tooling. If you already follow a recognised benchmark and use configuration management, you may be close to compliant. See our note on ISO 27017 certification cost for a broader view of budget. Plan time for reviewing supplier evidence too, because gathering assurance from large cloud providers can take longer than expected.
A hypothetical software company runs its platform on virtual machines in a public cloud. It builds all servers from a hardened image, scans each week against the baseline, and records exceptions with owners. Its network rules are reviewed quarterly, and a reviewer finds a test rule that allowed remote administration from any address. The rule is removed and the review record is filed. For tenant isolation, the company asks its cloud provider for its latest independent assurance report and notes the relevant sections in its supplier file. At the ISO 27017 audit, the assessor samples three servers and follows them from image to scan to patch record. The example is invented for illustration.
Use a trusted summary such as the 6clicks introduction to ISO/IEC 27017 for orientation, and read the standard itself before writing your policies. For exit and asset removal, see our guide to the cloud exit plan.
To avoid writing hardening standards, responsibility matrices and evidence checklists from scratch, the ISO 27017 and 27018 Toolkit provides documents you can adapt. Have your security lead review them for your cloud platform.
Seven cloud-specific controls, according to summaries of the 2015 edition, plus extra guidance on 37 existing controls.
Usually the customer for guest operating systems, and the provider for the hypervisor and management plane. Confirm this in your contract.
Yes. Ask the provider for assurance reports or test summaries and record them in your supplier file.
The standard does not name one. Pick a recognised configuration benchmark, record it and explain deviations.
Set a frequency based on risk, for example weekly for production servers, and record the results and follow-up.
September 30, 2026
