On Friday 23 October 2026, the South African Presidency took thepresidency.gov.za offline. Its statement called this "a precautionary measure in response to a global cybersecurity event", as reported by Citizen Digital. Spokesperson Vincent Magwenya told Reuters there was no indication of a breach. TechCentral reported that PHP had released fixes two days earlier, on 21 October, and that an Internet Archive copy from 18 October shows the site runs on Drupal, a content management system built on PHP.
The Presidency has not said the site was compromised, and nothing reported so far suggests it was. The more useful question is what the episode shows about how South Africa is set up to handle a vulnerability scare, and what the law does and does not do about it.
The case for taking the site down
The Presidency's caution deserves a fair hearing. When critical remote-code-execution flaws are being actively scanned for, a brochure-style government site carries little operational risk if it is dark for a few days. The same site compromised would be a serious embarrassment, and a defaced head-of-state domain is a propaganda win for any attacker. Switching the site off is a defensible, low-cost choice, and a team that does it quickly is arguably behaving better than one that waits and hopes. Our complaint is not that the Presidency acted. It is what the action implies about the alternatives.
What the action implies
If the quickest safe response to a patch release is to remove the site, then applying the patch within the same window was probably not a routine option. That is an inference, not an established fact. The Presidency did not name the event or say when the site would return. The reported timeline is still instructive: fixes were out on 21 October and the site went dark on 23 October. For public-facing systems, that gap is the period in which exploitation tends to start.
The broader point is that patching is a capability, not a legal duty. The best-known provisions of South Africa's cyber legislation address crime, not hygiene.
What the Cybercrimes Act actually provides
The Cybercrimes Act 19 of 2020 creates offences and investigative powers. On coordination, section 52 requires the National Commissioner to establish or designate an office within the South African Police Service as the "designated Point of Contact for the Republic". That office must provide immediate assistance for investigations and proceedings, including technical advice, assistance with identifying and locating suspects, and cooperation with foreign authorities. It is a law-enforcement liaison. It is not a national incident-response centre, a vulnerability-disclosure body or a patch-advisory service.
The reporting duty is narrower still. Section 54 obliges electronic communications service providers and financial institutions that become aware their service or network is involved in a prescribed category of offence to report to SAPS "without undue delay and, where feasible, not later than 72 hours". It also requires them to preserve relevant information. Failure is punishable by a fine of up to R50 000. Subsection (4) states that the section does not require monitoring of data or active searching for unlawful activity.
Two features matter here. First, the duty applies to providers and financial institutions, not to government departments running their own websites. Second, it only operates for offence categories that the policing minister prescribes by regulation under section 59(2). When most of Chapter 8 commenced on 1 December 2021, ITWeb reported that section 54 was excluded. I could not confirm from the sources reviewed whether it has since come into force.
The policy gap
The law therefore leaves three questions unanswered in a PHP-style event:
- Who must patch, and how fast? Nothing in the provisions reviewed sets a patching standard for government systems.
- Who coordinates a response across departments? SAPS can help investigate a crime once one is suspected. A precautionary shutdown with no breach is not a crime.
- How do outside researchers report a flaw in a government system? The Act does not create a vulnerability-disclosure framework. Researchers who probe systems without authorisation risk the Act's unlawful-access offences. A published safe-harbour disclosure policy would reduce that risk.
We cannot say from public sources how the Presidency handles any of these internally. That is partly the point. Citizens and researchers cannot see the arrangements.
A proportionate response
The wrong lesson would be a heavier statute. Broad mandatory-reporting rules, licensing of security researchers or powers to compel takedowns would add compliance cost and chill the good-faith disclosure that makes systems safer. Proportionate steps are modest and mostly administrative:
- Publish government patching targets. A binding internal standard for public-facing systems, such as critical fixes within a set number of days, can be adopted by directive without new legislation.
- Adopt a disclosure policy with safe harbour for good-faith researchers, along with a published security contact for government domains.
- Finish what the Act started. If section 54 is not yet operative, publishing the section 59(2) regulations would clarify what private operators must report and in what form. Fine, narrowly drawn reporting rules are better than vague ones.
- Explain precautionary shutdowns. A short note on when a site will return and whether data was affected costs little and builds trust.
South Africa has the legal scaffolding for cybercrime investigation. What the PHP scramble suggests is missing is the routine, visible discipline of patching and disclosure. That discipline is best built through standards and practice, not through new criminal penalties.