Security & Uptime
Keeping services available and defensible: monitoring that catches problems first, patching that actually happens, and an incident process rehearsed before it is needed.
Overview
Most security incidents in small and mid-sized organisations are unglamorous: a dependency with a known vulnerability that was never updated, a credential in a repository, an admin account with no second factor. The sophisticated attack is rare; the unpatched library is routine.
Uptime follows the same pattern. Outages are usually caused by an expired certificate, a disk filling, or a dependency change nobody was watching. Both problems are largely solved by monitoring the right things and having a process that runs whether or not anyone remembers.
Who this is for
- Companies who learn about outages from customers
- Businesses with dependencies that have not been updated in years
- Teams with no agreed process for a security incident
How we approach security & uptime
The specific pieces of work a typical engagement covers. Scope is agreed up front — nothing here is a surprise line item later.
Uptime and synthetic monitoring
Checks from multiple locations against the journeys that matter, not just whether the homepage returns a response.
Vulnerability management
Dependency scanning with a defined timescale for acting on severity levels, so advisories are handled rather than accumulated.
Access and secrets
Least privilege, second factor everywhere, and secrets in a manager with rotation rather than in configuration files.
Backup and recovery testing
Restores actually performed on a schedule, with a measured recovery time rather than an estimated one.
Incident response
A written process with roles, communication templates and escalation, rehearsed before it is needed.
Security review
Configuration review and coordination of penetration testing where the risk profile justifies it.
From first call to measured result
The same sequence every time, so you always know what happens next.
Assess
Current monitoring, dependency status, access controls and what would happen in an incident today.
Close the obvious gaps
Patching, second factor, secrets and monitoring, which is where most real risk sits.
Prepare
Write the incident process, test a restore, and run through a scenario with the people who would be involved.
Operate
Ongoing monitoring, patching cycle and periodic review, so the position does not decay.
Outcomes, not deliverables
A pile of artefacts isn't progress. These are the changes the work is meant to produce — and what we report against.
You find out first
Monitoring the right journeys means problems are detected before a customer reports them.
The common risks closed
Patching, second factor and secrets management address the large majority of realistic incidents.
Recovery that has been tried
A tested restore with a measured recovery time is the difference between a plan and a hope.
An incident that is handled
A rehearsed process means the first hour is executed rather than improvised.
Common questions about Security & Uptime
The things people ask before they get in touch. If yours is not here, ask us directly.
What are the most common security problems you find?
Outdated dependencies with known vulnerabilities, credentials committed to repositories, admin accounts without a second factor, and over-broad access that was granted temporarily and never revoked. Sophisticated attacks are rare; these are near universal.
How quickly should we patch?
Critical vulnerabilities within days, high within a couple of weeks, and everything else on a regular cycle. The specific timescale matters less than having one that is followed rather than decided case by case.
Do we need penetration testing?
Once the basics are in place, yes, and it is worth doing properly rather than as an automated scan. Commissioning a penetration test before patching known vulnerabilities produces an expensive report listing them.
What uptime should we expect?
For most business applications, three nines is achievable without heroic architecture. Each additional nine costs considerably more, so it is worth deciding what the availability is actually worth before designing for it.
Thinking about Security & Uptime?
Tell us what you are trying to change. If we are not the right fit we will say so, and point you somewhere better.
Looking at the wider picture?
Security & Uptime usually sits alongside other work in DevOps, Infrastructure & Technical Operations. Browse the full area to see what it connects to.