When you need it
Your servers were built by hand over several years, and no two are quite the same. A customer or auditor asks for proof that they are hardened, and the only evidence is an old build document. The last hardening attempt broke an application, so nobody wants to touch the settings again.
What sets the quote
- Linux and Windows Server on AWS, Azure or Google Cloud, hardened to CIS Benchmarks Level 1, with Level 2 for server roles that need it.
- Small scope: one cloud, one OS family, up to 2 OS versions and up to 2 server roles, such as web server and database server.
- Medium scope: one cloud, Linux and Windows Server (one version of each) and up to 4 server roles.
- Large scope: up to 8 server roles, and 2 clouds or 3 or more OS versions.
- One image pipeline per OS version and cloud. Hosts reporting compliance are counted with a free read-only inventory query (AWS Resource Explorer, Azure Resource Graph or Google Cloud Asset Inventory), and the count sets the rollout waves.
- Larger estates are quoted after sizing.
What changes
- Every new server starts from a hardened golden image, so no host is built by hand.
- Drift from the baseline is detected and corrected, or flagged, without anyone logging in to a server.
- You can show customers and auditors compliance evidence for every host, not a build document.
- Settings that would break an application are recorded as exceptions with an owner and a review date, not skipped in silence.
What you get
- Golden image pipeline for each OS version and cloud, using EC2 Image Builder, Azure VM Image Builder or Packer
- Hardening settings as code for each server role, mapped to CIS Benchmark IDs
- Enforcement and drift checks with Ansible, AWS Systems Manager State Manager, Azure Machine Configuration or Google Cloud VM Manager OS policies
- Compliance evidence per host, for example from Amazon Inspector CIS scans or OpenSCAP
- Exception register listing each deviation with its reason, owner, compensating control and review date
- Rollout plan in waves, with a rollback step for each wave
- Runbook for updating the baseline when a new benchmark or OS version arrives, and a handover session
What we cover on each cloud
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Golden images | EC2 Image Builder or Packer | Azure VM Image Builder or Packer | Custom images built with Packer |
| Settings and drift | Systems Manager State Manager or Ansible | Azure Machine Configuration or Ansible | VM Manager OS policies or Ansible |
| Compliance evidence | Amazon Inspector CIS scans | Machine Configuration compliance results in Azure Policy | VM Manager OS policy reports |
OpenSCAP can add Linux evidence on any cloud.
Not included
- Application and middleware hardening, such as IIS, NGINX or database settings
- Day-to-day patching, which belongs in a care plan
- Laptop and desktop hardening (see the Microsoft 365 security baseline)
- Hardening of container images and Kubernetes nodes
What we need from you
- AWS: AdministratorAccess in a dedicated image-build account and AmazonInspector2FullAccess where CIS scans run. Changes to workload accounts go through your pipeline or a role you approve.
- Azure: Contributor on the image-build resource group, plus Resource Policy Contributor and Guest Configuration Resource Contributor where settings are assigned.
- Google Cloud: Compute Admin in the image project and OSPolicyAssignment Admin where OS policies apply.
- An application owner for each server role, to test hardened images and agree exceptions.
- A test environment and an agreed change window for each rollout wave.
How it works
Free 30-minute call, then the sizing query and a written fixed quote.
Agree the server roles, the CIS profile for each role and the target OS versions.
Build the image pipelines and settings as code, test them with each application in a test environment and record exceptions.
Roll out in waves, starting with the least critical hosts, and collect compliance evidence after each wave.
Hand over the pipelines, the exception register and the runbook.
At a glance
- Duration
- 2–6 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
Zero Trust assessment
In 1–2 weeks, a review of identity for people, devices and workloads, cloud guardrails and CI/CD, with every control checked as declared, refused and in effect, ending in a maturity rating per area and a roadmap.
Threat modelling workshop
A STRIDE threat model of one system or major feature, built with your team in two half-day sessions over one to two weeks, with a data-flow diagram, trust boundaries and prioritised mitigations in your backlog.
Vulnerability management setup
Scanning for hosts, containers, Kubernetes, serverless functions and code dependencies, with triage rules, fix deadlines by severity, ticket integration and a weekly report, set up in two to five weeks.