#CyberWeekly

If the names in your documents have drifted, the fastest fix is upstream of the documents: who has access, and who is supposed to.

August is the season of lists. The trouble starts when somebody else reads yours out loud.

Is this you? If you keep a file of customer names, addresses or e-mail addresses, yes. That is every shop, installer, practice, garage and agency in the country. You do not need to be in NIS2 scope for this one. You need a customer list, and you have one.

Belgian furniture chain WEBA was hit on 10 August. It shut its four stores and its webshop as a precaution and had everything running again by 12 August. On 16 August, ransomware leak-site trackers recorded the crew known as Qilin adding WEBA to its victim list. Two days of downtime, handled well. Six days from "customer data may be involved" to a name on an extortion page.

• WEBA said early what an honest company says. Names, addresses, e-mail addresses and phone numbers may be involved, and the exact scope was not yet clear. The stores in Gent, Deinze, Mons and Tongeren were taken offline on purpose, examined, re-secured with IT partners, and reopened. That part worked.
• Listed is not the same as published. A leak-site entry is the pressure step: pay, or the files go up. At the time of writing the data has not been posted. The listing is recorded by leak-site trackers (ransomware.live logs the victim page at 16 August, 15:58 UTC). It is the crew's claim, not a WEBA statement.
• Getting the shop open is the easy half. Restoring systems is a job with a finish line. Working out exactly which records left the building is slow forensic work, and it is the half that decides what you have to tell your customers, and when.

Forward this, do not do it yourself. Send your IT partner these three questions and ask for the answers in writing. One: if a copy of our customer file left the building today, who writes the notice to customers, by name? Two: where is the list of what is actually in that file? Three: do our logs tell us what went out, or only that something did? Whatever comes back vague is the gap, and you found it on a quiet Thursday instead of during an incident. Our incident-response guide has the rest of the checklist.

The other kind of list: the official one, with a line on it that cannot be ticked.

Is this you? If you sell to a hospital, an energy or water company, a transport operator or a government body, then yes, by the back door. The letter below lands on them. What reaches you is the proof they now have to produce, and they will get part of it by asking their suppliers. If you are one of those organisations yourself, it is yours directly and today.

On 18 August the cyber inspectors at the CCB published a letter telling those organisations what to do if they cannot reach the top CyFun level by 18 April 2027: file a catch-up plan instead. The plan is proof that you meet the Important level, plus a written description of how you get to Essential by 18 April 2028. It applies whichever of the three routes you are on. The letter is dated 11 August and carries the reference NCCA/JK/INS/2026-002.

• If you are a supplier, this arrives as paperwork. An organisation that has to evidence Important-level compliance by next April evidences part of it through the companies it buys from. The questionnaire is the delivery mechanism, and it does not care how small you are.
• Here is the part nobody is saying out loud. The CCB's own list of authorised bodies, in its current version, names four organisations allowed to verify CyFun. All four are approved for Basic through Important. None is approved for Essential. The certificate meant to be held next April cannot be bought today, from anyone, at any price.
• So read April 2027 as an Important-level deadline with paperwork attached, and April 2028 as the real Essential one. No legal deadline moved: this is a request for information under Article 48 of the NIS2 law, not a change to it. What is new is the 2028 date.
• A risk analysis can justify aiming lower. Then you owe nobody a catch-up plan, you simply demonstrate the level you chose. That escape hatch is in Article 7 of the royal decree and it is unchanged.

Forward this paragraph to whoever handles compliance, or to your IT partner: "Belgium's inspectors published on 18 August what happens if we cannot reach the top CyFun level by 18 April 2027. We would file a catch-up plan instead: proof at the Important level, plus a dated route to Essential by 18 April 2028. Which of the three routes are we on, and who here knows?" Nothing else can be planned until that answer exists, because the plan is written differently for each of the three. The NIS2 dates that actually bind.

The line on the supply list that turns out to be for the other class.

Is this you? Only if you run SharePoint on a server of your own, or your hosting provider's. If your documents live in Microsoft 365, this one is not yours and you can stop reading here. We would rather tell you that than pad the paragraph.

On 11 August, security firm Rapid7 published its analysis of CVE-2026-55040 together with a working proof-of-concept. By 12 August, honeypots were logging attempts using it. On 18 August, CISA added it to its catalogue of flaws known to be under attack. It is rated 9.1 out of 10, and it lets an attacker with no account forge a login token and act as any user of the site.

• Microsoft fixed it in the July updates. Anyone current was never exposed. The whole window belonged to servers that had not applied a month-old patch, which is the ordinary case, not the unlucky one.
• Affected: SharePoint Server Subscription Edition, 2019, and Enterprise Server 2016. SharePoint Online is not affected.
• The gap between a published write-up and mass attacks is now a day. That is the part worth carrying away, more than the number. "We patch monthly" was a sound policy when that gap was measured in weeks.

One message, and most of you are done in a minute. Ask your IT partner: "Do we run SharePoint on any server of our own, including one nobody has logged into in a year, and is it on the July update?" A forgotten server is still a server, and the honest answer is usually a one-liner. Our notes on patch management cover keeping it boring.

A folder with tabs and your name on it, instead of one envelope with everything shaken into it.

If you sync NinjaOne, the patch and antivirus evidence we collect no longer lands as a single unreadable blob. It lands as a folder: a summary, operating-system patches, software patches, antivirus status, antivirus threats, and alerts. Each file carries a description and a plain-language dictionary of its columns, so an auditor can read a row without going off to look up NinjaOne's documentation first.

• Failures are sampled first, deliberately. Big fleets overflow the row cap on patch tables. Failed patches rank ahead of pending, pending ahead of merely high-severity, and degraded antivirus endpoints ahead of healthy ones. A fleet with 1,500 clean patches and one failure used to be able to produce a file showing nothing wrong. Evidence that hides the one bad row is worse than none, because it reads like proof.
• This is the whole point of collecting it. Evidence exists to be handed to someone who did not build your systems and does not trust you yet. If they cannot navigate it, you have a backup, not evidence.
• Nothing to switch on. The next sync writes the new shape.

Try it this week: open the folder from your most recent sync and read the first ten rows of the patch file as if you were the customer asking. If a row needs explaining, tell us which one. What patch evidence should contain.