The Swiss federal cybersecurity office’s recommendations for SMEs translate, for a company website, into six points: keep software current, secure access (strong passwords, two-factor authentication, limited login attempts), create backups and test restoring them, reduce attack surface, log access, prepare for incidents. Five of them cost no money, only discipline. The most effective lever is the fourth: a statically served site has no server, no database, no login and no plugins, so four of the six points are settled structurally rather than maintained permanently. Switzerland has no general incident reporting duty for all companies, but one for operators of critical infrastructure; independently, the revised data protection act requires notifying the Federal Data Protection Commissioner where a breach of data security entails a high risk.
The federal recommendations to SMEs are technically sound and deliberately general. They have to apply to the baker with five employees as much as to the machine builder with a hundred and fifty.
The price of that generality is that they are hard to act on. “Keep your systems up to date” is indisputable and does not answer what to do on Monday morning.
Here is what the six central points concretely mean for a company website. And which of them largely takes care of the rest.
1. Keep software current
What is meant: known vulnerabilities are probed automatically within hours of disclosure. An update left for a week is a week of open door.
Concretely on a CMS site: enable automatic updates for the core and the plugins, and actually enable them rather than intending to. Then check monthly that they ran, because a failed automatic update rarely announces itself.
The honest addition: this is a task without an end. It never disappears, it is only done regularly or not.
2. Secure access
What is meant: most successful attacks use no exotic vulnerability, they use a login.
Concretely:
- Two-factor authentication on every account with write permissions. This is the single most effective measure there is, because a guessed password becomes worthless.
- Limit login attempts, in a plugin or at the host.
- Do not give away the login name. On WordPress the interface at
/wp-json/wp/v2/usersreveals, without authentication, which account publishes, including the name it logs in with. That is default behaviour and can be switched off. Otherwise one of the two required pieces of information is public. - Remove accounts nobody needs anymore. The 2023 intern is a door.
3. Back up, and test the restore
What is meant: a backup that has never been restored is an assumption.
Concretely: the backup belongs off the server it protects. Sitting on the same system, it is affected by the same compromise. And once a year, run a restore on a test environment, with a stopwatch. The question is not whether a backup exists, but how long it takes until the site is back.
One detail surprises many: after a break-in, last week’s backup is often already infected, because the attack started days earlier. So keep several generations.
4. Reduce the attack surface
This is the lever that changes the other points.
What is meant: every component that runs can be attacked. What is not there cannot be attacked.
Concretely on an existing CMS site:
- Delete unused plugins and themes rather than deactivating them. A deactivated plugin still sits on the server and in some cases is still reachable.
- Remove default files such as
readme.html, which confirm the system and version. - Block
xmlrpc.phpif it is not needed. - Set security headers. HSTS, Content-Security-Policy, X-Content-Type-Options and the rest cost nothing and are simply absent on many sites.
And the structural variant: a company website very rarely needs a running server. Served statically, there is no server to patch, no database that can leak, no login to brute-force and no plugin that goes stale.
Points 1, 2 and parts of 3 and 5 are then settled not through better maintenance, but because the object of maintenance no longer exists. That is the difference between locking a door and having no door.
5. Log access
What is meant: after an incident you will be asked what happened. Without logs the answer is “we do not know”, and that is the most expensive answer of all.
Concretely: retain access logs, with a defined period, and know where they are. On a CDN those are the access logs; at a host they are usually available on request.
A side effect that is often underrated: the same logs also answer who actually reads the site, including the AI systems that appear in no analytics interface. How to read them without fooling yourself is in the post on AI crawlers in server logs.
Note that IP addresses are personal data. So a retention period and an entry in the privacy notice are needed.
6. Prepare for the incident
What is meant: decisions in an emergency are badly made during the emergency.
Concretely, on one page of paper: who notices it, whom do they call, who may take the site offline, where are the credentials, who informs clients, and when is a notification made.
On notification duties, because much gets confused here: Switzerland has no general reporting duty for all companies. Operators of critical infrastructure are subject to a reporting duty towards the federal cybersecurity office. Independently of that, the revised data protection act requires notifying the Federal Data Protection Commissioner where a breach of data security is likely to entail a high risk for the individuals concerned. Whether that applies in a given case is an assessment, not a formality, and it should not be made for the first time on the day of the incident.
This is not legal advice, it is a prompt to settle the question beforehand.
The honest summary
Five of the six points cost no money. They cost attention, every month, permanently, and that is exactly where they fail in practice. Not because anyone is careless, but because a website rightly is not a priority in the daily life of an SME.
That is what makes point 4 the interesting one. It is the only one that does not do the task better but abolishes it. Everything else stays a permanent task, and permanent tasks are rarely won.
Whether the rebuild is worth it depends on what runs through the site. If it only shows who you are, the five cheap points are the right answer and a rebuild is overkill. If customer data, bookings or a login run through it, the arithmetic looks different.
Frequently asked questions
What does the Swiss government recommend to SMEs for securing their website?
For a website, the federal cybersecurity office’s recommendations come down to six points: keep software current, protect access with strong passwords and two-factor authentication, create backups and test restoring them, remove unnecessary services and attack surface, log access, and prepare for an incident. Five of them cost no money, only discipline.
How do I apply these recommendations to a WordPress site?
Automate updates, secure the login with two-factor authentication and limit login attempts, switch off the REST interface’s user listing, delete unused plugins and themes rather than merely deactivating them, store backups off the server and restore one once a year, retain access logs, and write down who does what in an incident.
Does a Swiss SME have to report a cyber incident?
There is no general reporting duty for all companies. Operators of critical infrastructure are subject to a reporting duty towards the federal cybersecurity office. Independently of that, the revised data protection act requires notifying the Federal Data Protection Commissioner when a breach of data security entails a high risk for the individuals concerned. Whether that applies is a case-by-case assessment.
Which measure helps most on a company website?
Removing the attack surface instead of defending it. A statically served site has no server to patch, no database that can leak, no login to brute-force and no plugin that goes stale. Four of the six recommendations then take care of themselves structurally rather than needing permanent maintenance.