Security Updates for Company Software: Who Is Responsible When There Is No Developer

A mid-size logistics company in Hamburg found out the hard way. The freelancer who built their booking portal in 2022 moved to a different country in 2024, the invoices stopped, and nobody replaced him. Eighteen months later a customer's procurement team sent a security questionnaire asking when the portal's dependencies were last patched. The answer, pieced together from server logs, was never. The deal stalled for six weeks while the company scrambled to find out what software security updates responsibility even meant once the original developer was gone.

This situation is common and rarely discussed openly. A company commissions custom software, the relationship with the developer or agency ends, and the software keeps running because it still works. Nobody decides to stop patching it. The patching simply never gets reassigned to anyone, and the gap stays invisible until a breach, an audit, or a customer question forces it into the open.

Who is responsible for software security updates when there's no developer

The short answer is the company that owns the software, not the developer who built it. Once a project contract ends, so does any obligation the original developer had, unless the contract explicitly included ongoing maintenance. A one-time build agreement covers exactly that: a build. It does not create a standing duty for the developer to monitor CVE databases for the application five years later.

That leaves the business itself holding the risk, whether or not anyone on staff understands PHP dependency trees or Symfony security advisories. If the software processes customer data, sits on the public internet, or connects to other business systems, somebody inside the company is accountable for keeping it patched even if nobody inside the company can actually do the patching. Ownership and capability are two different things, and companies often discover they have the first without the second only after something has already gone wrong.

This gap tends to open quietly. A developer leaves, a retainer lapses, a freelancer's scope was narrower than anyone remembers. The software itself gives no warning. A PHP application with a security hole looks and behaves exactly like one without, right up until it doesn't.

In practice, the person who ends up accountable is rarely a technical one. It's an operations manager, a finance director, or occasionally the founder, because they're the ones who signed the original contract or who field the question when a customer asks about it. That person doesn't need to understand the code. They need to know who currently has authority to patch it, and right now, in many companies, the honest answer is nobody.

NIS2 and the obligations that don't go away

For companies in the EU, this isn't only a reputational question. The NIS2 directive pulled a much wider range of mid-size companies into formal cybersecurity obligations than its predecessor did, and one of its named measure areas is security in the acquisition, development, and maintenance of software. An organisation in scope cannot point to an absent developer as a reason that patching never happened. The directive expects a documented process, and "we used to have someone for that" is not one.

Even companies outside NIS2's direct scope often inherit the same expectations indirectly. A customer in a regulated industry will ask its vendors to confirm patch cadence as part of its own supply chain due diligence, because that obligation flows downstream from its own compliance requirements. If your company sells to banks, insurers, healthcare providers, or anyone in critical infrastructure, expect a version of that questionnaire eventually, and expect "nobody currently maintains that system" to be treated as a red flag rather than an acceptable answer.

Data protection law adds a second layer. Under GDPR, a known, unpatched vulnerability that leads to a data breach is difficult to defend as an unforeseeable event once the vendor or the security community has published a fix. Regulators generally don't ask whether you had a developer on staff. They ask whether reasonable technical measures were in place, and a two-year-old unpatched dependency with a known exploit rarely counts as reasonable.

What cyber insurance expects now

Cyber insurance has changed significantly over the past few years, and patch management is now a central part of underwriting rather than a footnote. Many insurers now ask applicants directly how quickly critical vulnerabilities are remediated, and some require a documented process before they'll issue a policy at all.

The practical risk shows up at claim time rather than at application time. If a breach traces back to a vulnerability with a patch that had been available for months, insurers increasingly scrutinise whether the policyholder's own stated practices were actually followed. A company that answered "yes, we patch promptly" on its application, then suffered a breach through a dependency nobody had touched in two years, is in a weaker position to collect than one that was honest about a gap and had already started closing it.

This creates an uncomfortable incentive to under-report the problem to avoid raising premiums, which is exactly backwards. Insurers price known gaps. They don't price well for gaps that surface only after a claim.

What a documented update process actually looks like

None of this requires hiring a full-time developer. It requires naming one responsible party and giving that party a repeatable process, whether that's an internal hire, a freelancer on a defined schedule, or an external partner. Three elements make the difference between a real process and good intentions.

The first is an inventory. You can't patch what you haven't listed. That means every application, every major dependency inside it, and the end-of-life date for its language and framework version. PHP 8.2 loses security support on December 31, 2026; Symfony 5.4 reaches end of life even earlier. A company running either without a plan for what comes next is carrying a clock it hasn't looked at.

The second is cadence with a named owner. "We'll get to it" is not a cadence. A monthly or quarterly review for routine dependency updates, plus a separate and faster track specifically for anything flagged as a security advisory, gives you something you can actually point to when a customer or an insurer asks. It doesn't need to be elaborate. It needs to exist on a calendar, with a specific person's name attached, not a department's.

The third is a record. When something is patched, write down what changed and when, even if it's three lines in a shared document. This is the piece that turns "we take security seriously" from a sentence into evidence, and it's the piece most companies skip, because it feels like paperwork rather than security work. During an audit, a procurement review, or a breach investigation, that log is often the only thing that distinguishes a company that had a process from one that got lucky.

Wolf-Tech sets this kind of process up as part of our code quality consulting work, starting with the dependency and version inventory most companies in this position don't yet have. We also cover related maintenance questions, including what a software maintenance retainer should actually include once you decide ongoing coverage makes more sense than an ad hoc fix.

If your company is running production software with no developer currently responsible for it, the honest first step is finding out exactly what's installed and how old it is. Reach out at hello@wolf-tech.io or visit wolf-tech.io, and we'll help you figure out where the gaps actually are before a customer, an auditor, or an insurer finds them first.