Services / Care / Security & updates

Patches applied on schedule, not after the incident

Almost every compromise we are called in to clean up started with a known problem that had a published fix available for months. Patching is unglamorous, easy to postpone, and cheap next to the alternative, so we do it on a schedule, in small tested batches, and give you a written record of exactly what changed.

Start the conversation →See the technology

Why it matters

The cost is the wait

Nobody has ever put "apply the updates" at the top of a board agenda, which is precisely why it slips. The trouble is that deferral compounds. Skip a quarter and you have a chore; skip two years and a routine framework upgrade has quietly turned into a rewrite, because every step between where you are and where you need to be has to be taken at once, by people who no longer remember why the code does what it does.

Meanwhile the risk is not theoretical. Vulnerabilities in widely used components are published openly, with working exploits circulating within days, and automated scanners find exposed installations far faster than any attacker could by hand. Your insurer's questionnaire asks about patching cadence. So does the security review your first serious enterprise customer will run before signing. "We update it when something goes wrong" is not an answer that survives either conversation.

So we treat this as scheduled maintenance rather than emergency response. Updates go out in small, tested batches through a copy of your system before they touch the real one. Serious vulnerabilities are assessed against your actual setup, a flaw in code you never call is not the same as one on your login page and patched inside a window agreed in your plan, with out-of-hours handling for anything being actively exploited. Every month you get a plain-language record of what was patched, what was held back, and why.

What you actually get

Built to be trusted

None of this is clever. It is the unglamorous work that prevents the expensive disasters, done on a schedule and written down.

Little and often, never a crisis

Updates applied in small, tested batches on a regular rhythm, rather than saved up into an annual emergency. It is what keeps your next major upgrade a routine task instead of a project you have to raise budget for.

Judged by real risk to you

Automated scanners produce a great deal of noise. Every finding is assessed against how your system is actually built and exposed, then ranked, so you get a short list of things that genuinely matter, not a forwarded alarm feed nobody reads.

Critical patches inside an agreed window

Serious vulnerabilities get a promised timeframe written into your plan, with out-of-hours handling for anything being exploited in the wild. You receive a written note of what was patched and when, the sort of thing an auditor or an insurer will ask for.

Never fixed live on the real system

Every change, including an urgent one, goes through a safe copy first, gets reviewed, and can be undone in a single step. Marginally slower on the smallest fixes; dramatically safer on everything else.

Old keys and ex-staff access removed

A scheduled review of who and what can reach your systems, retiring dormant accounts, unused API keys and over-broad permissions. Former staff and forgotten integrations holding live access is one of the most common ways organisations are actually breached.

Certificates and renewals never left to chance

SSL certificates, domains and third-party service renewals tracked and automated where possible, alerted well ahead where not. An expiry is the most avoidable outage there is, and it always seems to land on a Sunday.

Where it earns its keep

Same pattern, different desks

The technical work barely changes between sectors. What changes is what an unpatched system puts at risk, and who asks you to prove it is patched.

01 · Retail & e-commerce

Every plugin is a door someone else built

The problem: A typical store runs dozens of extensions, themes and integrations from different authors, each updating on its own schedule. One abandoned plugin is all it takes for skimming code to be injected into the checkout, and it can sit there collecting card details for weeks before anyone notices anything at all.
What we build: A tracked inventory of every component with its update status and support state, batched patching through a staging copy so a theme update cannot break the buy button, file-integrity monitoring on the checkout path, and a flag on anything the author has stopped maintaining so you can decide to replace it deliberately.
What changes: The store stays current without a nervous manual update session before every busy weekend, and abandoned components get replaced on your timetable rather than after an incident.

02 · Legal & accountancy practices

The security questionnaire you can answer honestly

The problem: You hold client material that would be genuinely damaging if it leaked. Your professional indemnity renewal now asks detailed questions about patching and access control, corporate clients run their own supplier reviews, and the honest current answer is that updates happen when someone remembers.
What we build: A documented patching cadence with severity-based windows, quarterly access reviews that clear out leavers and dormant logins, encrypted backups proven by restoring them, and a monthly written record that maps directly onto the questions those forms actually ask.
What changes: Renewals and client reviews stop being an exercise in creative writing, and the practice has evidence rather than assurances.

03 · Software & SaaS companies

Dependency drift, before it becomes a rewrite

The problem: The product shipped on a framework version that is now several major releases behind. Nobody wants to be the one to start the upgrade, so each month the gap widens, the security advisories stack up, and enterprise prospects keep asking for a SOC-style summary you cannot produce.
What we build: Automated dependency monitoring with grouped, tested upgrade batches; the major version jump broken into a sequence of small landings rather than one heroic branch; secret scanning across the repository history; and a maintained record of components, licences and known issues.
What changes: The gap closes gradually instead of never, upgrades stop being a project in their own right, and security questionnaires are answered from a document that already exists.

The technology

The tools behind it, named

Most of this runs automatically and reports into one place. The tools matter less than the schedule they run on, but these are the ones we reach for.

6 layers · 29 technologies

Watching what you depend on

Your software is mostly other people's software. These watch every component you have pulled in and tell us the moment one of them has a published problem.

Dependabot
Renovate
Snyk
npm audit
GitHub Advisories

Scanning what you actually ship

Beyond the dependency list: container images, code patterns and credentials accidentally committed. Findings are triaged before they reach you.

Trivy
SonarQube
OWASP ZAP
Semgrep
Gitleaks

Certificates and the edge

Encryption that renews itself, plus a layer in front of your application that blocks the crude attacks before they ever reach it.

Let's Encrypt
Cloudflare
Nginx
Caddy

Keys, passwords and who holds them

Credentials belong in a vault your organisation owns, not in a spreadsheet, a chat thread or a config file. Rotation becomes possible once they live somewhere sensible.

1Password
Bitwarden
HashiCorp Vault
Auth0

Proving a patch is safe before it lands

A staging copy, an automated test run and a one-step rollback. This is the difference between updating confidently and updating nervously.

GitHub Actions
Docker
Vitest
Cypress
Playwright

The platforms underneath

Operating systems, runtimes and databases need patching too, and they are the layer most often forgotten because nothing visible depends on them until it does.

Ubuntu
Debian
Node.js
PHP
WordPress
PostgreSQL

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

The first month is mostly finding out what you are running. After that it settles into a rhythm you stop having to think about.

We inventory what you are actually running

Every dependency, plugin, server, runtime, certificate, domain and third-party account, including the ones nobody has looked at since launch. Almost every engagement turns up at least one service still being paid for, or one account still belonging to someone who left.

We agree what urgent means

Severity levels, the patch window that applies to each, coverage hours, who signs off on a change that carries risk, and how we reach you out of hours. Written down before it matters, so the first real incident is not also a negotiation.

We build the safety net first

A staging copy that resembles production, backups verified by restoring them, and a rollback that takes one step. You cannot patch confidently until you can undo, so this comes before any patching we do.

We switch the watching on

Dependency alerts, vulnerability scanning, secret detection across the repository, and expiry tracking for certificates and renewals. All of it routes to us first and reaches you as a triaged summary rather than raw alerts.

The monthly patch run

Updates batched, applied to staging, tested, deployed, and verified against the journeys that matter. Anything that breaks in staging is held back and reported to you with an explanation and a plan, rather than pushed and hoped for.

The report, and the awkward conversations

A plain-language monthly record of what was patched and what was deferred, plus a quarterly access review. It is also where we raise the things patching cannot fix (a framework reaching end of life, a component with no maintainer) while there is still time to plan rather than react.

Before you commit

The questions worth asking

Can you guarantee we will not get hacked?

No, and you should be wary of anyone who does. What we can do is close the route that is used most often, a known vulnerability with an available fix, keep the window between disclosure and patch short, remove access that should not exist any more, and make sure that if something does happen you have proven backups and a rehearsed plan. That converts a potential catastrophe into a bad week.

Will updates break our site?

Occasionally an update genuinely does break something. That is exactly why they get applied to a staging copy first and tested there. When one breaks, we hold it back, tell you, and either work around it or plan the change properly. The risk of patching is real but small and controlled; the risk of not patching accumulates quietly and arrives all at once.

How quickly do you patch something critical?

That is set in your plan rather than by us unilaterally, because it depends on the coverage hours you are paying for and how exposed the system is. As an illustration only, a plan might commit to same-business-day assessment and patching within twenty-four hours for a critical issue on a public-facing system, with out-of-hours work for anything under active exploitation. We agree the actual numbers with you and then report against them.

Our system has not been updated in years. Can you catch it up?

Usually, yes, but honestly, this is the case where the estimate is least reliable. Long-deferred updates interact with each other, and the true state of a neglected system only becomes clear once you start moving it. We do a health check first, give you a range with the risky unknowns named, and work in stages you can stop at. Sometimes the finding is that catching up costs more than replacing a component, and we would rather tell you that in week one.

Can we just have a one-off security clean-up?

You can, and it is genuinely worth doing. Be aware that its value decays: new vulnerabilities are published continuously, so a system hardened today drifts back towards exposure over the following months. A one-off is a good starting point, not a substitute for a schedule, and we will not pretend otherwise to sell one.

Who holds the credentials and the accounts?

You do, from day one. Cloud accounts, domains, repositories and services are registered in your organisation's name with us added as collaborators, never the other way round. If you ever move to another supplier, removing us is an afternoon's work, not a hostage negotiation.

Not sure when your system was last updated?

That answer is usually the most revealing one. Tell us what you are running and we will do a health check, give you a ranked list of what actually needs attention, and quote a schedule to keep it that way.

Start the conversation →

Explore more

The rest of Ongoing Care & Support

Always-on monitoring A real response promise Continuous improvement Software we didn't build ← All of Care