On this page
What security hardening is
Hardening means reducing the number of ways a system can be attacked: removing what isn’t needed, tightening what is, and making defaults safe. Individual fixes — a patched plugin here, a closed port there — help, but they tend to be inconsistent. One server gets the careful treatment, the next one is set up in a hurry, and six months later nobody remembers which is which.
Our security hardening service is a systematic pass over the whole stack against a written checklist. It covers the application, the server, the network and the way people access all three. Because it follows a checklist rather than intuition, the result is repeatable: new servers can start hardened instead of being fixed later.
A checklist also makes security visible to people who are not engineers. Instead of a vague assurance that the servers are secure, you have a document showing which controls are in place on which system, when they were last checked, and which exceptions were accepted and why. That is useful when you onboard a new developer, change hosting providers, or answer questions from a customer who wants to know how their data is protected.
Who needs it
Hardening is most valuable when you run more than one system, or when systems are rebuilt and added regularly. Examples include a SaaS startup preparing for a customer’s security questionnaire, an e-commerce business moving to its own cloud servers, a manufacturer connecting its ERP to a web portal for dealers, or a real estate company running several sites and a CRM on shared infrastructure.
- Each server was configured by a different person, in a different way.
- A customer or partner has asked what security controls you have, and there is no document to show them.
- You are about to launch something new and want it to start from a known-good baseline.
- Previous fixes keep being undone by updates or new deployments.
The layers we cover
| Layer | Examples of checklist items |
|---|---|
| Application | Framework and dependency versions, debug mode off in production, secure session and cookie settings, security headers, error messages that don’t leak internals |
| Server | Minimal installed packages, automatic security updates, SSH key-only access, fail2ban, file permissions, log retention |
| Network | Default-deny firewall, databases and caches not exposed publicly, admin interfaces restricted, TLS on every public endpoint |
| Access | Individual accounts, least privilege, 2FA on hosting, DNS and code repositories, documented offboarding |
| Data | Encrypted, off-site backups with scheduled restore tests, secrets kept out of code repositories |
What you receive
- A written checklist tailored to your stack, which you keep and can reuse.
- A change record showing each item checked, what was changed, and when.
- A list of accepted exceptions — items deliberately left as they are for business reasons, with the compensating control noted.
- Where useful, configuration as code (for example, scripts or templates) so new servers are built to the same standard automatically.
How we deliver it
- Scope and authorisation — agree in writing which systems are included and confirm you are entitled to have them changed.
- Baseline — record the current state of each system before touching anything, and make sure backups exist.
- Draft the checklist from recognised guidance, such as OWASP recommendations for applications and vendor hardening guides for operating systems, adjusted to how your business actually works.
- Apply in stages, starting with low-risk changes and scheduling anything that could interrupt service.
- Verify each item, re-testing from outside where possible.
- Hand over the checklist and change record, and walk your team through it.
What affects timeline and cost
- The number and variety of systems — ten identical servers are quicker than three very different ones.
- Whether the application code needs changes, or only configuration.
- How much downtime is acceptable and when maintenance windows are available.
- Whether you want configuration automated for future builds or applied by hand this time.
Common mistakes
- Copying a generic hardening script from the internet without understanding what it changes, then breaking an application.
- Hardening the production server but leaving staging, backups or old servers wide open.
- Treating hardening as a one-off project, with no plan to apply the checklist to new systems.
- Skipping access controls because they feel like admin rather than security.
Frequently asked questions
Is this the same as a penetration test?
No. Hardening is a defensive configuration exercise against a checklist. Where authorised testing is also useful, we agree its scope separately and in writing.
Can our own team use the checklist afterwards?
Yes, that is the point. The checklist is written for your stack and handed over, so your team can apply it to every new system.
Will this help with customer security questionnaires?
It often does, because you will have a documented set of controls and a change record to refer to. We don’t fill in questionnaires on your behalf or claim certifications you don’t hold.
Do you harden systems built by another vendor?
Yes. We start by recording the current state, then apply the checklist in stages so nothing the existing applications depend on is changed without being agreed first.
How long does the hardening last?
As long as it is maintained. Updates, new software and new staff can erode it, so we recommend re-running the checklist periodically and whenever something significant changes.
Talk to us about security hardening
A systematic pass over the whole stack against a written, repeatable checklist.