Platform Engineering

Ongoing website security and maintenance

A security assessment is a measurement taken on one day. What keeps a platform out of trouble is what happens on the other three hundred and sixty-four — the patch that was applied before it was exploited, and the component that was replaced before it was abandoned.

The problem

Security work is continuous, but it is bought as a project

An assessment finds the weaknesses that exist when it is run. It cannot find the vulnerability that enters the platform next month through an update, a new integration or a dependency that stops receiving fixes upstream. Those arrive continuously, and an organisation that reviews its security annually has a twelve-month window in which nobody is looking.

An assessment was completed and its findings were addressed, once
Platform and dependency updates happen when something breaks, not before
Nobody can say which installed components are still receiving security fixes
Access has accumulated — former staff, contractors, shared accounts, dormant admins
Backups run and no restore has been tested since the site was built
Security alerts exist and are routed to an address nobody monitors
A compromise was cleaned up but the entry point was never closed
Nobody owns the answer to 'are we currently exposed to anything known'

Who this is for

The people who usually bring us this problem

A business that had an assessment and wants the benefit to persist

The findings were fixed. You need the condition maintained rather than re-measured annually and found to have decayed.

A platform owner without security staff

Nobody in the business is responsible for knowing what is patched, who has access, or whether the backups work.

A CTO under compliance or client pressure

You need to be able to answer questions about patching cadence, access control and recovery testing with evidence rather than intention.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

An annual assessment leaves eleven months uncovered

Most compromises exploit something that became known after the assessment ran. The finding was not missed; it did not exist yet, and no process was in place for the day it did.

Patch deferral compounds

Each version skipped makes the next one less tested against your configuration. A routine update becomes a project, and the project acquires a deadline set by an end-of-support date rather than by you.

Access accumulates silently and permanently

Departures, contractors, agencies and shared credentials leave an attack surface nobody enumerated. Unlike a vulnerability, it never appears in a scan — it has to be reviewed deliberately, and it is the shortest path into most platforms.

An untested backup is discovered to be broken at the worst time

Backups that complete and backups that restore are different claims. The second one is the only one that matters, and it is almost never the one that has been checked.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Defined patch cadence

A schedule rather than a policy statement: what is updated, how it is tested before it reaches production, when it is applied, and what happens if it goes wrong. Frequency is agreed per engagement, because a platform that changes daily and one that changes quarterly need different answers.

Dependency lifecycle tracking

Knowing which installed components are still maintained and which have been abandoned upstream. An abandoned component is a future vulnerability with a known arrival date, and it is invisible in any single scan.

Access review

Enumerating who can reach the platform, through what, with what privilege, and removing what no longer needs to exist. Usually the highest-value recurring work in a security agreement and the least glamorous.

Backup restore testing

Periodically restoring rather than periodically checking that a job ran. This is a recurring deliverable rather than a one-off, because a backup arrangement can break without any visible symptom.

Alert triage

Monitoring output routed to somebody who acts on it. Alerts nobody reads are indistinguishable from no alerts, and they create the impression of coverage while providing none.

Periodic re-assessment

The initial assessment repeated at an agreed interval, so the security position is re-measured against a platform that has changed rather than assumed to hold.

Incident response within the agreement

A defined route for a suspected compromise, and a stated escalation path. What it does not include is an advertised response time, because we will not commit to cover we cannot staff.

Written reporting

A recurring summary of what was patched, what was found, what access was removed and what needs attention. Without this the arrangement is invisible, and an invisible security agreement is the first thing removed in a difficult quarter.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Establish the current position before accepting responsibility
Version currency, dependency lifecycle, access list, backup restore, and whether any existing monitoring produces anything actionable. We do not take on maintaining a position we have not measured, because the first month would otherwise be spent discovering what we had agreed to.
Set cadence against the platform's actual change rate
A platform receiving weekly releases needs a different patching arrangement from one that is architecturally stable. Agreeing a cadence that does not fit how the site actually changes produces either unnecessary work or a standing exception.
Close the exposure before improving the process
Known vulnerabilities and accumulated access are addressed first. Process improvement while a known exposure is open is optimising the wrong thing, and the exposure is the part with a clock on it.
Test the update somewhere that is not production
Where a staging environment exists, updates go through it. Where one does not, a backup restore point and a tested rollback are the minimum — updating production without either is a gamble taken repeatedly.
Remove access on a schedule, not on a resignation
Reviews happen at an agreed interval regardless of whether anyone has left, because access accumulates through paths nobody reports — a contractor finishing quietly, an agency engagement ending, a shared account outliving its purpose.
Report so the work is legible
A recurring written record, because maintenance is invisible when it works. The failure mode of a security agreement is a quiet period in which nobody can see what was prevented.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Onboarding

Version and dependency inventory with maintained status
Access enumeration and first review
Backup configuration review and a tested restore
Monitoring review and alert routing
Agreed cadence, scope and exclusions in writing
Closing of any known exposure before routine work begins

Recurring

Patch and version updates on the agreed cadence
Testing in a non-production environment, or a tested rollback where none exists
Dependency lifecycle review, with replacements for abandoned components
Access review at the agreed interval
Backup restore testing
Alert triage with an owner
Periodic re-assessment

Reporting

Recurring written summary of patches, findings and removals
Change log attributed and dated
Standing register of accepted risk, with the reason
Escalation path for anything outside the agreed scope

Under the hood

Architecture and technology

What a security maintenance agreement covers

Updates applied on a schedule, tested before production
Dependency lifecycle tracked rather than discovered
Access enumerated and reviewed at an interval
Backups restored, not merely observed
Alerts routed to a human with the authority to act
Periodic re-assessment against a changed platform
A written record of all of the above

What it explicitly does not cover

Round-the-clock monitoring unless separately contracted
Guaranteed prevention of compromise — the commitment is detection, cadence and response, not invulnerability
Application code review beyond the agreed scope
Compliance certification or audit sign-off
Content, marketing or editorial work
Recovery from a compromise that predates the agreement, which is an incident engagement

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

The platform is WordPress specifically

The same cadence applied to WordPress's own update and plugin surface.

WordPress maintenance

You need a one-off assessment rather than ongoing work

A risk register, remediation order and verification criteria.

Website security

Something has already happened

Incident response has a different sequence and a different first step.

Hacked website recovery

The server needs an owner rather than the site

Operating-system patching, monitoring and infrastructure operations.

Server management

Questions

Frequently asked

How often do you patch?

It is agreed per engagement against how the platform actually changes, and it is written into the scope rather than stated as a general policy. What matters more than the interval is what surrounds it: whether the update is tested somewhere before production, and whether there is a way back if it goes wrong. An aggressive cadence without a rollback is not more secure, it is more eventful.

Does this include 24/7 monitoring?

No, and we will not imply that it does. What is included is alerting on the signals that matter and triage by somebody who will act on them during the covered hours, which are stated in the agreement. If your requirement is continuous out-of-hours monitoring then that is a different provider relationship, and we would rather tell you now than during an incident.

Can you guarantee we will not be compromised?

No, and no honest answer can. What an ongoing arrangement changes is the exposure window — a vulnerability that becomes known is closed in days rather than at the next assessment, and access that should not exist is removed at the next review rather than never. Those two things account for a large share of real-world compromises, and they are process problems rather than capability ones.

What happens when a vulnerability is announced that affects us?

It is assessed against what you are actually running, and the answer is stated even when it is inconvenient. If the affected component is not installed, that is a non-event and we will say so. If it is installed, the fix is scheduled against the cadence and the interim risk is described. What we will not do is forward vendor bulletins without establishing whether they apply to you, which is how security email becomes something people stop reading.

We already have an assessment. Is this redundant?

It is the opposite of redundant, and the reason is timing. An assessment finds what exists on the day it runs; most compromises exploit something that became known afterwards. The assessment is what establishes your starting position, and this is what stops that position decaying. If you have findings that were never closed, closing those is the first thing the arrangement does.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work