How we look after our clients once their system is live

The week a flaw is announced

On 21 October 2026 the PHP project released fixes for two critical flaws that let an attacker take over a web server with a single request. Most of the systems we build and run use PHP somewhere. By the next day we had updated PHP on every server we manage, switched off old PHP versions that will never be fixed, and checked each site afterwards to make sure the update had not broken anything. Then we wrote to our clients. None of them had asked, and none of them needed to, which is the point. A client should hear about a serious flaw from the people who run their system, with the fix already in place, not from a news headline followed by a nervous phone call. We have written up the flaw itself separately for anyone who runs a PHP website.

Patch first, then tell the client

Most of our clients are ministries, agencies, schools, NGOs and companies whose job is not tracking software vulnerabilities. They should not have to be. The company that runs a system is the only party in a position to see a disclosure, judge whether it applies, test the fix and apply it, usually before the client has finished reading their email that morning. So our order of work is fixed: secure the system, confirm it still works, then explain. Explaining first and patching later only adds a worried client to an exposed server. Patching quietly and never saying anything is not good enough either, because a client who is never told what was done has no way to tell an attentive provider from an absent one.

Plain language, not a changelog

When we write to a client about a security update, we write for the person who signs off the budget, not for an engineer. A changelog full of version numbers and vulnerability identifiers tells a director nothing about whether their institution is safe. Our notes follow the same shape every time, so a client learns where to look for the part that concerns them, and the most common answer to the question of what they need to do is a single word: nothing.

• What happened, in one or two sentences.
• Why it matters, in plain terms, without jargon.
• What we have already done about it, and when.
• What the client needs to do, which is usually nothing.
• Anything they run elsewhere that they should check, and what to ask.
• Who to call with questions.

One accountable person on every system

Every system we run has a named person at Information Village who answers for it. Not a ticket queue, not a general mailbox that someone checks on Fridays. When something goes wrong, the client knows who to call, and that person already knows the system: how it is hosted, what changed last, who uses it and when the busy days are. This matters most in government work, where a registry or a reporting system can sit quietly for months and then carry a ministry's entire reporting deadline in one week. We still operate systems we built years ago, including the Government Digital Registry for the Ministry of ICT, and the reason that works is continuity of people as much as code.

When we do not control the server

Not every client system sits on a server we manage. Some run with a hosting company the client chose before we arrived, or one a parent body requires. It would be easy to say the fix is the host's problem and leave it there. We do not, because the client does not care whose server it is, they care whether their system is safe. So we raise the issue with the host, follow it until the fix is installed, and keep the client told where it stands. If a system cannot be patched quickly, we recommend taking it off the public internet until it can be, and we explain why, because a short outage is a better outcome than a breach the client has to report.

Watching, not waiting

Patching is only half of looking after a system. The other half is noticing when something is wrong before the client does. Our servers run SENTINEL, the threat detection we built and operate on our own infrastructure, which watches for attacks and blocks them as they happen. We would rather find a problem at night and fix it before morning than have a client discover it in front of their own users. None of this is unusual in principle. What is unusual, in our experience of the Ugandan market, is a provider still doing it in the third year of a contract, when the launch is long forgotten and the work is unglamorous. That is the part of the job we think matters most.

What to expect from us, and what to ask any provider

If we run your system, this is what you can hold us to. If someone else does, these are fair questions to put to them, and the answers will tell you more about the next three years than the original proposal did.

• Critical security fixes applied as soon as a tested fix exists, without waiting to be asked.
• A plain-language note after every security update telling you what changed and what, if anything, you need to do.
• One named person who knows your system and answers when you call.
• Problems followed through to the end, including on servers we do not control.
• A straight answer about anything we cannot fix quickly, and what we recommend in the meantime.