If a critical flaw in your website’s software went public this afternoon, who would fix it tonight?
Most leaders can answer part of that question. They know which agency built the site and which company sends the hosting invoice. Fewer can say who would notice the problem first, who would apply each fix, and who would confirm the site is safe afterward.
Website security for small businesses depends heavily on those answers, because a typical site runs on several layers maintained by different parties. That setup handles routine changes well and becomes fragile when something urgent requires every party to act at once.
A business website is built in layers with different owners
At the bottom sits the server and the software it runs, including the programming language the site is written in. That layer belongs to a hosting company, an in-house server, or a cloud account someone set up years ago. On top of it runs the content management system, often WordPress or Drupal. Above that are plugins and themes written by independent developers who release updates on their own schedules. Many sites also include custom code from the agency or freelancer who built them, plus connections to payment processors, online forms, scheduling tools, and the domain registrar.
Each layer tends to have its own owner, and the business is usually the only party connected to all of them. The hosting company has no reason to know who wrote the custom booking feature. The developer may have finished the project three years ago and moved on to other clients. A staff member updates the events page every week with an administrator login that hasn’t been reviewed since launch.
In many organizations, the record of who maintains what lives in old invoices, a former employee’s inbox, and the memory of whoever managed the original launch. That arrangement holds up as long as the site needs nothing more than occasional updates.
Shared ownership stalls under pressure
In a normal week, each owner handles its own piece and the site runs fine. A public vulnerability in the software underneath the site changes that, because the fix often touches several layers at once and each party has a reasonable basis for waiting on another. The host may expect the developer to update the application, the developer may expect the host to patch the server, and a software vendor may publish an update and wait for customers to install it.
Each of those expectations makes sense from where that party sits, and together they can leave a site exposed for days while attackers scan the internet for unpatched systems. The business owner often ends up in the middle, forwarding emails between companies and trying to judge technical answers without the background to evaluate them. For a COO or CFO, that is an uncomfortable position: fully accountable for the outcome, with limited visibility into who is doing what.
PHP2Shell and the coordination problem
The PHP2Shell vulnerabilities, disclosed in October 2026, showed this dynamic clearly. The two critical flaws allowed an attacker with no login to run code on a server by sending a specially crafted web request. PHP runs a large share of business websites, including many built on WordPress and Drupal, and because details leaked ahead of the planned embargo, the PHP security team released fixes within roughly a day of the announcement.
Patching PHP on a server is straightforward once you know where it runs. Finding every copy is harder, and some copies sit outside the server owner’s reach. Security researchers pointed out that some applications ship with their own bundled copy of PHP, so the fix for those depends on the application’s vendor. The same applies to sites built and maintained by outside developers.
Syntech’s response followed that pattern. On the first day, Syntech’s team identified every vulnerable system across its client environments and began patching the systems it manages directly. Several affected sites and applications belonged to outside web developers or software vendors. For those, the team contacted each provider and coordinated the fixes, and clients with affected systems heard from Syntech directly that same day. The developers kept ownership of their code, and the coordination came from the party already watching the rest of the environment.
Coordination belongs with the party already watching
An IT partner already monitors servers, workstations, and network devices, and usually has visibility into hosting accounts and the software running across the environment. It follows security disclosures as part of the job and has the technical background to read one and decide what to check first. That makes it the party best positioned to connect a public vulnerability to a specific client system, even one it didn’t build.
Before an incident
Good coordination starts well before any disclosure, with records the IT partner keeps current as part of managing the environment.. A capable IT partner documents who hosts, builds, and maintains each website and web application, which vendors supply the software underneath them, and which staff members hold administrative access. It keeps contact details current and knows how each provider handles urgent requests. It also knows which sites and applications matter most to daily operations, so the first hours of an incident go to the systems the business depends on.
During an incident
When a critical flaw goes public, the partner checks client environments the same day without waiting for a request. It patches what it manages, then contacts the owners of everything else with specific information: which system is affected, which version it runs, and what needs to change. It tells the client what was found and what is being done, in terms a business owner can act on. And it follows up with each party until every affected system is confirmed fixed, including the ones it doesn’t maintain itself.
Questions to ask your IT provider about website security
A few direct questions will show whether your organization has someone in this role today:
• Do you have a record of who hosts, builds, and maintains each of our websites and web applications?
- Do you have a record of who hosts, builds, and maintains each of our websites and web applications?
- If a critical flaw affected our website software tomorrow, how would we hear about it, and from whom?
- Which fixes would you apply directly, and which would require our developer or a software vendor?
- Do you have current contacts for those parties, and have you worked with them before?
- After the most recent major public vulnerability, what did you check in our environment, and what did you tell us?
If the answers come back vague, the coordination would likely be improvised during the next incident, when time matters most.
Getting ahead of the next disclosure
A business website will keep depending on several owners, and that is a reasonable way to run one. The risk sits in the handoffs between them, and it surfaces when a flaw goes public and every hour of exposure counts. Knowing who owns each layer, and who will pull those owners together, lets a leadership team make decisions with clear information during the next incident.
At Syntech Group, we treat a public vulnerability as a reason to act the same day. Our team keeps track of what runs in each client’s environment and who maintains it, and checks for exposure before clients have to ask. We fix what we manage and bring in the developers and vendors responsible for the rest. Clients hear what we found and what we’ve done, in plain business terms, while the work is underway.
If you’re unsure how your current provider would respond to the next vulnerability affecting your website, contact our team. We’ll walk through how your environment is set up today and how a response would work for your business.
