VULNERABILITY REMEDIATION & SECURITY HARDENING

A vulnerability assessment or penetration test ends at a list of vulnerabilities — which is exactly where the problem starts for most organisations. Who fixes them? Your system administrators have Windows, Linux, databases, firewalls, and cloud in their hands at once, and nobody is an expert in every platform. A finding that reads "insecure configuration" does not tell you what the secure value should be in your environment, and the report was never written to answer that question.

This service does two things. It fixes the vulnerabilities you already have, working from a penetration test or vulnerability assessment report — ours or another provider's. And it hardens to a full baseline, configuring your system components to security best practice from the start, so the attack surface shrinks across the whole estate rather than at the points a scanner happened to reach. We reference CIS Benchmarks first. Where no benchmark exists for a component, we use vendor recommendations. Where neither exists, we use CIS Critical Security Controls as a framework, together with our team's experience, to draft a baseline for you. In every case you know where each setting came from — not that it was set out of habit. If you want the background first, our team has written both an introduction to hardening and a beginner's walkthrough.

Remediation and hardening — what is the difference

The two are usually spoken of together, but they answer different questions, and they are scoped and priced differently.

Remediation is reactive. The findings are already in your hands and have to be closed before an audit deadline or the retest window. The scope is clear because it is tied to the finding list, and progress is measured directly: how many are closed.

Hardening is proactive — bringing systems to the security baseline they should have had all along. Standards and compliance frameworks tell organisations to do this, and it still rarely gets done, least of all on production. The result is a smaller attack surface across the whole system, not only at the points a scanner happened to see.

In practice, many findings in a pentest report are not CVEs waiting on a vendor patch. They are loose configurations that a good hardening baseline would have closed at the outset. Organisations that fix finding by finding, round after round, tend to meet the same issues again next time — because they are treating the symptom, not the baseline.

What we harden

Scope is set by the number of hosts and the types of component in play, agreed before any work begins. If you are unsure where to start, we recommend beginning at the OS layer and working upward.

• Operating systems — Windows Server, Windows clients, the major Linux distributions, and Unix. This layer is usually the right starting point because it disturbs the applications running above it less than the layers higher up.
• Server software — web servers, application servers, and middleware.
• Databases — engine configuration, account privileges, and encryption in transit.
• Network devices and firewalls — rule bases, the management plane, and deprecated protocols still left enabled.
• Cloud — account-level and service-level configuration on the major cloud providers. This is hardening specific cloud components to a baseline; if what you need is a review of a whole cloud environment against the shared responsibility model, that is a separate engagement — see cloud security assessment.
• Containers and orchestration — images, runtime, and cluster configuration.
• Active Directory — privilege structure, policies, and the settings that so often become a lateral movement path.

If you run a component that is not on this list, bring us the problem and we will talk it through.

How we work

Hardening that takes the system down is hardening that failed. Our process is built so the work lands.

1. Scoping and asset inventory — We agree what components are in your estate, how many hosts, of which types, against which guideline, and what we will not touch. That is settled here, not discovered at the end.
2. Baseline audit — We check the current state against the chosen benchmark, so the gap is a number before anything is changed. You and we then share a reference point for where this started.
3. Impact assessment and agreed exceptions — Doing every item in the document may not be possible. Risk matters, and so does business operation. Any item that would disrupt live systems or conflict with your existing policy is recorded as an exception with its reasoning rather than forced through — which is the documentation your auditor will ask for anyway.
4. Backup, then work in rounds — The existing configuration is backed up every time. We work group by group, always starting outside production. If something breaks after a change, we restore immediately.
5. Verify — We audit again after the changes, confirming the settings took effect and the system still works.
6. Report and baseline document — You receive the results of this round, plus a baseline document your team can apply to newly built hosts on its own.
7. Periodic re-audit — Optional. Configuration drift happens the moment people start changing systems. We re-check on an agreed cycle so you can see what has slipped away from the baseline.

Automated hardening with Confix

Hardening ten hosts by hand is fine. Hardening three hundred and re-auditing them every quarter by hand is not.

We use Confix, a solution that automates system hardening and auditing across Windows and Unix servers using customisable templates. The template is what turns your organisation's baseline into something concrete, and each new audit round shows immediately which hosts have drifted from the standard.

There are two ways to use it — we come in and do the work as a service using the tool, or you take the licence and your own team runs it, with us setting up the templates and training your people at the start. The second suits organisations with an in-house infrastructure team that want this as routine work.

What you get

• Baseline audit reports, before and after — how many items passed out of how many, at the start of the work and at the end.
• A hardening baseline document for your organisation — every item, what it sets, which source it came from (CIS, vendor, or our team), and why. Your team applies it to newly built hosts directly.
• A record of exceptions and their reasoning — the items not applied and the business or technical reason they were not, written so it answers an auditor directly.
• Your original configuration, backed up — ready to restore if a problem surfaces later.
• Post-remediation verification — a second audit confirming the settings took effect.
• An executive summary — the reduction in risk, at a level management and auditors can read.

Team credentials

The work is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination. That offensive-security background is what makes the hardening decisions sound: we know which settings an attacker actually exploits, so the argument for a change is never simply that a document lists it. See the full list of certifications the team holds.

Standards

1. CIS Benchmarks — always the first choice. Published by the Center for Internet Security, they cover most of what organisations actually run, are updated regularly, and give each item a rationale, an impact, an audit procedure, and a remediation step. That makes the conversation with your auditor a straightforward one.
2. Vendor recommendations — where CIS has no benchmark for a component, we work from the manufacturer's own hardening guide, usually the most accurate source for a specialised product.
3. Our team's experience, on a framework you can point to — where neither exists, we use CIS Critical Security Controls as the structure, map which features and functions of the component correspond to which control, and add guidance from credible community sources. The result is a baseline drafted specifically for you, with the reasoning recorded for every item — not an opinion offered without support.

Hardening closes what an assessment finds, so it sits directly downstream of the work that produces the findings: a vulnerability assessment for breadth across the estate, a penetration test for proof of what an attacker could reach, and infrastructure testing for the network and servers underneath. Where the question is not which settings to change but which controls your organisation needs and how to evidence them for an audit, that is the governance side, and our consulting team works there.