Virtual machine hardening

ISO/IEC 27017 CLD.9.5.2 requires you to harden cloud virtual machines (VMs) to meet your organization’s business needs, which means defining secure configuration baselines, stripping unnecessary components, and keeping VMs patched and controlled throughout their lifecycle. Operationalize it by standardizing hardened images, enforcing configuration drift control, and retaining evidence of build, change, and patch compliance.

Key takeaways:

• Define and approve VM hardening baselines per OS/workload, then make them the default via images and IaC templates.
• Enforce hardening continuously with patching, drift monitoring, and controlled exceptions tied to risk acceptance.
• Keep audit-ready artifacts: baselines, image pipeline logs, configuration scan results, patch reports, and exception records.

“Virtual machine hardening” under ISO/IEC 27017 is a requirement-level expectation: your cloud VMs should not be deployed as generic defaults. They must be configured to reduce attack surface and support your risk and operational objectives (availability, confidentiality, integrity, recovery, and manageability). This is less about one-time “secure build” and more about making secure configuration the path of least resistance across the VM lifecycle: provisioning, configuration, patching, monitoring, and decommissioning.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat VM hardening as a governed standard with technical enforcement. You want a written baseline, an engineered implementation (golden images and infrastructure-as-code), and continuous verification (configuration compliance and patch compliance reporting). Most audit friction comes from gaps between “we have a standard” and “we can prove every VM is built and kept to it,” especially where exceptions, legacy workloads, and third-party managed VMs exist.

This page translates the ISO/IEC 27017 requirement into concrete controls, evidence, audit talking points, and an execution plan you can hand to engineering and track to completion.

Regulatory text

Requirement (verbatim): “Virtual machines in a cloud computing environment shall be hardened to meet the business needs of the organization.” ¹

Operator interpretation: You must (1) define what “hardened” means for your business, (2) implement that standard for cloud VMs, and (3) maintain it over time. A reasonable implementation includes secure configuration baselines, removal/disablement of unnecessary services, and regular patching aligned to your risk and operational requirements. ¹

Plain-English interpretation (what the requirement is really asking)

A hardened VM is one that starts secure and stays secure:

• Starts secure: built from an approved baseline image/template with only required packages, hardened OS settings, secure remote access, and logging enabled.
• Stays secure: patched, monitored for configuration drift, and changed through controlled processes with exceptions documented.

The phrase “to meet the business needs” matters. It means you must pick the baseline settings and patch cadence that match your risk appetite and workload criticality (for example, internet-facing production vs. isolated dev/test), then show that you consistently apply that logic.

Who it applies to (entity and operational context)

Applies to:

• Cloud service customers running workloads on IaaS (and any situation where you manage the guest OS).
• Cloud service providers that provision or manage VMs for customers, including managed hosting offerings.
  ¹

Operational scope you should explicitly define:

• IaaS VMs where you control the OS (primary scope).
• Managed VMs / third-party managed appliances where a third party controls the OS. You still need requirements, due diligence, and evidence of their hardening and patch practices.
• VDI / bastion hosts / jump boxes (often overlooked; high-value targets).
• Ephemeral autoscaling fleets (harden via images/templates; verify via pipeline and runtime checks).
• Legacy workloads that cannot meet baseline without compensating controls and approved exceptions.

What you actually need to do (step-by-step)

1) Define “hardened” as a governed baseline standard

Deliverables:

• VM Hardening Standard (policy-level) stating scope, roles, and required controls.
• Technical baselines per OS and workload class (build standards).

Minimum baseline topics to cover:

• Account and authentication settings (admin access controls, remote access restrictions)
• Network exposure defaults (host firewall posture, allowed inbound management ports)
• Unnecessary services and packages removed/disabled
• Logging and time sync enabled
• Secure configuration for common services (SSH/RDP defaults, TLS config where applicable)
• Endpoint protection/EDR agent requirements (if part of your security stack)
• Patch expectations and ownership (who patches, how, and how you prove it)

Practical tip: keep the “standard” stable, and version the “baselines” so engineering can roll forward without rewriting governance docs.

2) Engineer hardened builds as the default (golden images + IaC)

Hardening that relies on “run this checklist after provisioning” breaks at scale. Make the hardened state the default artifact:

• Golden images (for example, OS images built through a pipeline).
• Infrastructure-as-code templates (with secure defaults baked in: no public IPs by default, restricted security groups, enforced metadata settings where relevant).
• Bootstrap configuration (cloud-init, configuration management) only for environment-specific settings, not basic hardening.

Evidence focus: auditors will accept automation if you can prove the automation is controlled and produces consistent output.

3) Enforce configuration compliance and detect drift

You need a way to answer: “Are all VMs hardened right now?” Implement:

• Configuration scanning against your baseline (CIS-style checks are common in practice, but the key is your approved baseline).
• Drift alerts routed to an owner with a documented remediation workflow.
• Blocking controls where feasible (policy-as-code gates in CI/CD or provisioning guardrails).

Operationalize exceptions:

• Record the VM/workload, which baseline control is not met, compensating controls, approving authority, and review trigger (for example, next rebuild cycle).

4) Run patching as a measurable control, not a promise

ISO/IEC 27017’s summary expectation includes “regular patching.” ¹

Your patch control should include:

• Patch ownership model (platform team, app team, or managed service).
• Patch method (in-place patching vs. immutable rebuild/replace).
• Patch reporting ¹.
• Emergency patch procedure for high-risk vulnerabilities, tied to change management.

A common exam hangup: “We patch via rebuilds” is fine, but you must prove rebuild frequency and fleet coverage.

5) Control admin access and hardening change paths

Hardening is undermined by uncontrolled administrative access. Implement:

• A defined break-glass path with logging and post-event review.
• Privileged access restrictions and auditing (who can log into VMs, from where, and how sessions are captured/logged).
• Change control for baseline updates (versioning, approvals, rollout plan).

6) Decommission securely

Hardening includes lifecycle hygiene:

• Ensure VMs are terminated through standard processes.
• Confirm credentials, keys, and secrets are rotated if embedded anywhere they shouldn’t be.
• Maintain asset inventory linkage so “unknown VMs” do not bypass baselines.

Required evidence and artifacts to retain

Keep evidence that shows (a) the baseline exists, (b) it’s implemented, and (c) it’s continuously enforced.

Governance artifacts

• VM Hardening Standard (approved, versioned)
• Baseline configuration documents per OS/workload class (versioned)
• Exception register with approvals and review notes

Build and deployment artifacts

• Golden image build pipeline records (build logs, tests, approvals)
• Image version inventory (which environments use which image version)
• IaC repositories and change history (PR approvals, policy checks)

Runtime compliance artifacts

• Configuration compliance scan reports (timestamped, scoped to fleet)
• Drift tickets and remediation records
• Patch compliance reports and patch job logs

Access and monitoring artifacts

• Privileged access logs and break-glass records
• Logging/telemetry verification (proof that required logs are enabled and forwarded)

Practical evidence rule: for each environment (prod/stage/dev) you should be able to produce “a list of VMs, their baseline version, last compliance scan, and patch status.”

Common exam/audit questions and hangups

Expect these, and prep the artifacts above to answer them quickly:

1. “Show me your VM hardening baseline.”
   Hangup: baseline exists but is generic, outdated, or not tied to cloud VM realities.

2. “How do you ensure every new VM is hardened?”
   Hangup: manual checklist with no enforcement, or teams can bypass golden images.

3. “How do you detect and remediate drift?”
   Hangup: scanning is ad hoc, results aren’t tracked to closure.

4. “How do you handle patching for legacy and third-party managed VMs?”
   Hangup: unclear ownership; no contractual or operational evidence for third parties.

5. “How do you manage exceptions?”
   Hangup: exceptions granted verbally or in tickets without structured risk acceptance.

Frequent implementation mistakes and how to avoid them

Mistake: Treating hardening as a one-time build task.
Fix: require continuous compliance checks and a drift remediation workflow.

Mistake: One baseline for everything.
Fix: define baseline “tiers” (by OS and workload class) so business needs map to settings without endless exceptions.

Mistake: Golden image sprawl with no lifecycle management.
Fix: version images, set ownership, and retire old images through a controlled process.

Mistake: Relying on in-place patching only, with no rebuild path.
Fix: allow rebuild-based patching for ephemeral fleets and enforce reporting either way.

Mistake: Exceptions become permanent.
Fix: require an expiration condition (next rebuild, system retirement, or compensating control implementation) and periodic review.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so you should treat this requirement as a standards-driven audit expectation rather than anchoring your program to a specific regulator action.

Risk-wise, unhardened VMs create predictable exposure:

• Larger attack surface (unneeded services, default settings)
• Credential and remote access abuse (weak admin controls)
• Vulnerability exposure (patch gaps, unmanaged images)
• Control failures that cascade into incident response, customer commitments, and third-party risk issues (for example, if a managed provider runs your VMs without measurable hardening)

Practical execution plan (30/60/90)

Use this plan as an operating cadence, not a promise of completion time.

First 30 days (Immediate stabilization)

• Assign control owners: security (standard), platform/infra (images/IaC), app owners (workload exceptions).
• Publish VM Hardening Standard and define scope boundaries (what counts as a VM in your cloud).
• Inventory VMs and identify “non-standard builds” and third-party managed VMs.
• Draft baseline v1 for your most common OS and create an exception register template.

By 60 days (Default secure builds + measurable compliance)

• Stand up or formalize golden image pipelines for primary OS types.
• Update IaC templates to enforce secure defaults and require approved images.
• Implement configuration compliance scanning with reporting by environment.
• Start patch reporting and define how patch compliance is measured (including rebuild-based patching).

By 90 days (Continuous enforcement + audit-ready evidence)

• Add drift remediation SLAs aligned to workload criticality (define internally; keep consistent).
• Implement policy gates to prevent provisioning from non-hardened images where feasible.
• Formalize exception approval and review workflow, including third-party attestations where applicable.
• Run an internal audit-style walkthrough: pick sample VMs, trace from build artifact to compliance scan to patch record to access logs.

Where Daydream fits (practical, non-disruptive)

If you struggle to keep evidence consistent across teams, Daydream can help by standardizing the control narrative, mapping required artifacts to the ISO/IEC 27017 requirement, and tracking exceptions and evidence requests across engineering and third parties. The value is faster audit response and fewer “we have it, but can’t prove it” gaps.

Frequently Asked Questions

Do containers or serverless functions fall under “virtual machine hardening”?

This requirement is explicitly about virtual machines in cloud environments. If your platform uses containers or serverless, you still need secure configuration, but you should manage those under separate hardening standards aligned to their technology.

We use managed instance groups and autoscaling. How do we prove hardening?

Prove the hardened state through the golden image pipeline, the IaC template defaults, and runtime compliance scans on a sample of running instances. Auditors usually accept immutable patterns if you can show consistent build controls and drift detection.

Can we meet the requirement with only patching and vulnerability scanning?

Patching and scanning help, but “hardened” implies secure configuration baselines and removal/disablement of unnecessary services, not just vulnerability management. Your evidence should show baseline definitions and enforcement, not only scan outputs.

What’s the minimum acceptable “baseline” artifact for an audit?

A versioned hardening baseline per OS type, approved by the right owner, plus proof it is implemented through images/templates and validated through compliance reporting. A checklist without implementation evidence rarely holds up.

How do we handle third-party managed VMs where we can’t log in?

Treat the third party as part of your control boundary: contractually require hardening and patching practices, request their evidence, and record your review. Where evidence is limited, document compensating controls and risk acceptance.

Do we need separate baselines for dev and prod?

You can keep one baseline with environment-specific parameters, or maintain separate tiers. What matters is that differences are intentional, approved, and reflected in enforcement and exceptions.

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services