Who Actually Takes Care of Your Website's Security?

A question few people ask

If you run an SME, you have a website. Probably for years. At some point it was set up by an agency, a freelancer, or someone you know, and it has been running ever since. Most of the time you do not think about it, and that is actually a good sign.

Until the day you read in the news that a critical security vulnerability affects “millions of websites.” Suddenly a question comes up that nobody had ever asked before: who actually takes care of your website's security?

If the honest answer is “nobody, really,” you are not alone. For small and medium-sized businesses, it is the norm.

An example: the PHP vulnerability of October 2026

In October 2026, two critical security vulnerabilities became public in PHP, the programming language that runs around 70 percent of all websites. The vulnerabilities allowed attackers to execute their own code on vulnerable servers, in other words to take control of the website.

In Switzerland, the canton of Basel-Stadt took its websites offline. The University of Geneva and EPFL Lausanne were unreachable overnight. A major Swiss hosting provider preemptively shut down more than 100,000 customer sites. The Swiss National Cyber Security Centre (NCSC) rated the situation as critical.

That day, several inquiries from clients came in, all with the same question: “Is our website affected?” The answer was no, every single time. For my clients it was a relaxed day; for me, a quiet one. I will get to why in a moment.

This vulnerability was neither the first nor will it be the last. Log4j, Heartbleed in OpenSSL, countless WordPress plugin vulnerabilities: the list is long, and it keeps getting longer. October 2026 is just a particularly vivid example of what happens when the question of responsibility was never settled beforehand.

Why it so often hits WordPress

WordPress is not insecure. Let me say that up front, because it is often claimed. A properly maintained WordPress on an up-to-date server is a solid system. The problem is not the software but the way it is operated by SMEs in practice:

• The website was built years ago, and the agency from back then no longer exists.
• Updates get postponed because something broke the last time.
• There are 20 to 40 plugins running, each from a different developer, each with its own update rhythm.
• The server version is outdated because one plugin no longer works with the new one.
• Nobody in the company knows who is responsible.

This does not only apply to WordPress. Joomla, Typo3, Drupal, and many other systems work on the same principle: you get a piece of software, and from then on you are responsible for running it. Whether you know it or not.

A security expert summed it up in the NZZ after the PHP vulnerability: the biggest risk lies with small companies whose website nobody explicitly takes care of.

What has fundamentally changed

In the past, a vulnerability like this came with a certain lead time. It became known, experts analyzed it, and it took days or weeks before it turned into a working attack. During that time, you could patch.

That time no longer exists. The head of IT security at the University of Basel put it this way in the NZZ:

“Before the AI era, you might have had one to two weeks before someone built a working attack on a vulnerability. Today it is ten or fifteen minutes.”

The PHP vulnerability in October 2026 was itself discovered with the help of AI. The first attacks were underway before the patches were even available. Cloudflare, one of the largest operators of internet infrastructure, counted millions of automated attack attempts within hours.

This changes the math completely. Anyone who wants to keep up needs someone who is reachable around the clock, can assess the situation within minutes, and acts immediately. For a company with its own IT department, that is feasible. For an SME with ten employees, it is not. That is not a question of skill but of resources.

Nobody is completely independent

An objection I often hear: “Then I will just switch to a different technology.” It is not that simple, and I say this as someone who relies on a specific platform.

Almost every website stands on a foundation maintained by surprisingly few people. PHP depends on the PHP Foundation, a small, donation-funded organization. Node.js, which Webflow also runs on, depends on the OpenJS Foundation. OpenSSL, which the encryption of half the internet relies on, was maintained for years by a handful of volunteers. There is no technology without security vulnerabilities.

So the real question is not “which technology is secure,” but: who responds in an emergency, and how fast?

It is about risk distribution

Every company with a website carries a security risk. The only question is who carries it. There are two clean answers:

• You carry it yourself. Your own hosting, your own CMS, your own plugins, your own updates. Full control, full responsibility. This makes sense if you have the resources for it or pay someone who takes it on with a binding commitment.
• You deliberately hand it off. You rely on a managed platform where a team operates, monitors, and patches the infrastructure. You have less influence over the technology, but no late-night updates and no crisis meetings.

Both are legitimate. The only problematic option is the third one, which is the most common in practice: carrying the risk yourself without knowing it.

Why we at KOMUNIQUE rely on Webflow

I want to be honest: Webflow is not the right choice for every project. Anyone who needs a complex online store with ERP integration, custom server logic, or specific requirements for data location is better served elsewhere. And when it comes to multilingual sites, Webflow is not cheap.

For the vast majority of Swiss SMEs I work with, however, the math works out. Their website is a business card, a source of information, and a point of contact. Nobody in the company wants to deal with servers. Text and images should be editable in-house. And the site should grow with the business without needing a rebuild every few years.

What Webflow does differently when it comes to security:

• No application server. Webflow delivers your website as static HTML, CSS, and JavaScript over a global network. There is no server on which attackers could inject code. That is why our clients were not affected by the PHP vulnerability.
• No plugin model. Design, CMS, SEO settings, and forms are part of the platform. There are no dozens of third-party extensions that each need to be maintained individually.
• Infrastructure included in the base price. DDoS protection, SSL certificates, encryption, automatic patching, and version history with restore are included in every plan.
• Externally audited. Webflow is SOC 2 Type 2 and ISO/IEC 27001 certified and is tested annually by independent parties. The reports are available to customers.
• A team that does nothing else. In October 2026, Webflow's security team reviewed its own systems, patched where necessary, and documented the process publicly. Without me or my clients having to do anything.

That is why, as an agency, I can focus on what truly adds value for my clients instead of installing security updates. The risk is not gone. It is simply carried by people who are equipped for it.

A word on dependency, because it comes up often: yes, with Webflow you tie yourself to one provider. With WordPress you can switch hosting providers; with Webflow you cannot. But hard lock-in is not a law of nature; it is a question of implementation. Content can be exported, and on every project we make sure that switching remains possible. The flip side of having no influence over the infrastructure is having no work to do on it.

What you can do now

Regardless of which system your website runs on, here are the questions you should be able to answer:

1. Who is responsible? Is there a person or company with a binding responsibility for updates and security on your website? With a contract, not with “he will take care of it”?
2. How up to date is your system? Ask your hosting provider or your agency which versions of CMS, plugins, and server are running. If the answer takes a long time, that is already an answer.
3. What happens in an emergency? Who gets informed, who acts, how fast? If you do not know, probably nobody does.
4. Is there a backup? And has anyone ever tested whether it can be restored?
5. Do you know your obligations? The revised Swiss FADP requires that a data breach with a high risk for affected persons be reported to the FDPIC “as soon as possible.” For the legal assessment of your specific case, I recommend consulting a specialist.

If you stumble on two or more of these questions, you are carrying the risk yourself without knowing it. That is not an accusation; it is the case for most SMEs. But it is the moment when you should decide whether you want to keep carrying it yourself or deliberately hand it off.

An offer

If you want to move your website to a managed platform: we handle the 1:1 transfer from WordPress to Webflow at fixed flat rates. Design and content are preserved, redirects are set up cleanly, and afterwards you can edit your text yourself, right in the browser.

Write to me at philipp@komunique.com, and I will take a look at your website with no obligation.

Sources

• NZZ: “Millionen von Hackerangriffen: So kam es zum Fiasko” (in German, October 2026)
• Webflow Blog: “How Webflow builds security into your site” (Ty Sbano, Josephine Cahill, updated October 26, 2026)
• BBC: “PHP is the cyber equivalent of an unexploded bomb” (Zoe Kleinman, October 2026)
• W3Techs: Usage of server-side programming languages, as of August 2026
• FDPIC: Duty to report data security breaches under the revised Swiss FADP