Who is responsible for updating your business software?

What changed this week?

On 21 October, PHP published security updates and OpenAI described the research and coordination behind them. We reviewed the announcements on 22 October. There are two useful parts to the story: the immediate update guidance and the longer-term work of maintaining software.

What does the public discussion add?

Direct access to OpenAI's X profile returned an access error, and a targeted search did not surface an accessible relevant post. We could not assess the discussion there.

What does this mean for your small business?

Consider an illustrative guesthouse with a public website, an enquiry form and an externally hosted booking service. The owner can edit room descriptions but has never had to think about the software underneath. An update notice arrives, and each supplier assumes another supplier is handling it.

We would start by listing those services separately. For each one, record who supplies it, who can change it and who receives maintenance notices. The web developer might maintain the website application while the host manages the underlying runtime. The booking provider might operate its own system. Those responsibilities need confirmation from the suppliers, rather than inference from the invoices.

For this PHP advisory, the owner could ask: does any service you maintain for us use affected PHP software, what fix applies, and has it been deployed? A useful reply identifies the service, the relevant release or vendor patch, and when it was checked. 'We have automatic updates' leaves the completion question unanswered.

After the technical update, the guesthouse should check the tasks customers rely on. Can a guest view rooms on a phone, submit an enquiry and reach the booking service? Does a test enquiry arrive where staff expect it? Use a test or sandbox process for transactions so the check does not create an unwanted paid booking.

These checks answer different questions. The maintainer confirms the software fix; the owner confirms that the customer journey still works. A working homepage does not establish that a security fix is installed, and a successful update does not establish that every form or integration works.

This is a proposed approach, not a client case study. The PHP advisory applies to PHP installations; it does not establish that every small-business website is affected. The broader ownership question is useful across different platforms.

How could your strategy evolve over time?

Treat maintenance as part of choosing and running a service. When commissioning a website or an internal tool, ask what the ongoing arrangement covers: application changes, hosting updates, third-party connections, backups and urgent support. Write down any gaps before deciding whether the arrangement suits the business.

Keep a short service register in a place more than one authorised person can access. It can include the business task, supplier, maintenance contact, renewal date and where the relevant account is managed. Keep credentials in the appropriate password manager rather than in the register itself.

Agree how urgent notices reach someone who can act. A shared mailbox is useful only if somebody reviews it. Name a primary contact and a backup, and establish who can approve an urgent change when the owner is unavailable. The process should also cover what to do when a supplier cannot provide a timely fix.

Ask the maintainer to plan testing and recovery alongside changes. For an important booking flow, that could mean a recent recoverable backup, a safe test environment where available, and a short list of checks after deployment. Recovery needs to account for security too: simply restoring vulnerable software can reintroduce the problem.

Review the arrangement when a supplier changes or a new integration is added. A website handover should include access and maintenance responsibilities, not just design files. A useful record of completed work states what changed, who checked it and any remaining issue.

Our interpretation of this week's news is that better discovery tools make the handover to maintenance more important. They do not remove the need for a person to make decisions about a particular business system. For a small team, a clear support arrangement may be more useful than buying another tool to monitor alerts nobody owns.

What can you do this week?

Start with the website or service that handles an important customer task. For affected PHP systems, act on the current advisory immediately rather than waiting for a weekly review.

• List the website, forms, booking tools and other services involved in that task. Name the supplier and maintenance contact for each.
• Send the PHP advisory to the relevant maintainer if applicability is unknown. Ask for confirmation of the applicable fix and that it is running in production.
• Agree who approves urgent updates and who covers that responsibility when the usual contact is unavailable.
• Write a short check of the customer journey using test details. Include the notification or record staff receive, not just the screen the customer sees.
• Record the outcome and any unresolved issue. Arrange a follow-up with a named person and date instead of leaving an open support email unanswered.

How Context Aware can help

We can help map the services behind your website, identify unclear maintenance responsibilities and document the customer journeys that need checking after a change. That gives you a practical brief to discuss with your existing suppliers.

For websites and applications we build or maintain, we can agree the scope of ongoing updates, testing and support, including what needs another provider. Where a specialist security assessment is needed, we can help organise the relevant information and handover.

Bring us the system that feels difficult to keep track of, along with the support arrangements you already have. We can work through who owns each part and what would make the next update easier to manage.