Name Your Incident Owner Before the Outage, Not During It

Today's fix: assign an incident owner and an escalation path

Write down two things. Who is responsible when the firm's website goes down or gets compromised. Who that person calls next, with a phone number, when the problem is bigger than they can solve. That is the entire task. It takes under an hour and it does not require a committee, a budget cycle, or anyone's approval but yours.

Most firms cannot answer either question right now. The site was built by an agency three years ago, the hosting bill is on somebody's card, and the plan for an outage is "text the marketing person and hope." That works until the day it does not, and the day it does not is usually the day you are also in trial.

Why this small task matters more than it looks

Verizon's 2026 Data Breach Investigations Report found that 31% of breaches now begin with exploitation of software vulnerabilities — overtaking stolen credentials as the leading entry point. That is a meaningful shift. For years the story was phishing and password reuse, and the response was training and MFA. The story now is unpatched software: the plugin nobody updated, the CMS version two majors behind, the theme from a developer who stopped shipping updates in 2022.

Here is the connection to the incident owner exercise. You cannot name an escalation path without answering a chain of questions you have been avoiding:

• Where is the site actually hosted, and who holds the credentials?
• Who has the ability to patch it — and when did they last do so?
• What plugins are running, and which of them are abandoned?
• If the site went down at 6pm Friday, who would notice, and how?
• Where do the leads go if the forms stop firing?

The exercise is a flashlight. Naming an owner forces you to inventory what that owner is responsible for, and the inventory is where the stale plugins fall out. Firms in this situation routinely discover they are running components that have not received a security update in years — not because anyone was negligent, but because nobody's job description included checking.

You cannot name an escalation path without first admitting you do not know who has the keys. That admission is the whole value of the exercise.

What an incident owner actually needs

Keep this lightweight. You are not writing a disaster recovery manual. You are writing a one-page document that a panicked person can read in ninety seconds.

The four fields

• Owner. One named human at the firm. Not "IT." Not "the agency." A person with a mobile number who is accountable for the site being up.
• Escalation contact. The host, the developer, or the vendor who can actually touch the server. Include the support number, the account ID, and the login path. If your only route to help is a web form that promises a reply in 48 hours, that is the finding — fix it.
• Trigger thresholds. What counts as an incident. Site down. Forms not delivering. Unexpected redirects. Certificate expired. A page load time that has doubled. Write the list so nobody wastes twenty minutes deciding whether to escalate.
• Communication line. Who tells the intake team that inbound leads may be missing, and how calls get captured while the site is dark.

That last one is where law firms lose the most money and think about it the least. A down website is an advertising spend that lands on a blank page. If you run paid search, every hour of downtime is billed. The incident owner's job is not only to fix the site — it is to pull the plug on paid traffic until it is fixed.

The 30-day follow-up: compare resource headroom

Once the incident plan is live, do one more thing. Over the next 30 days, look at resource headroom on your hosting: CPU, memory, storage, and how close you run to your limits during traffic spikes. Not as a technical exercise — as a business one.

Headroom is what determines whether an incident is a blip or an outage. A site running at 85% of its allocated resources on a normal Tuesday has nothing left when a local news story mentions your firm, when a campaign lands, or when a bot swarm hits. Shared hosting environments make this worse, because your headroom depends on what your neighbors are doing that day.

Track three things across the month:

• Peak versus average utilization. If peaks routinely exceed 70–80% of capacity, you are one event away from a slow site.
• Time to first byte during peaks. Slow server response is the leading indicator that shows up before an outage does — and it feeds directly into Core Web Vitals, which affect what Google is willing to rank.
• Patch latency. How many days pass between a security update being released and it being applied on your site. Given that vulnerability exploitation is now the top breach vector, this number is a risk metric, not an IT metric.

Why this compounds for firms with large page inventories

If your site is a twelve-page brochure, headroom is a rounding error. If you are running real geographic coverage — hundreds or thousands of service-and-city pages designed to capture demand across every market you serve — hosting is no longer a utility line item. It is the substrate the entire asset sits on. Large page inventories mean more crawl activity, more concurrent database queries, and more surface area to keep patched. A hosting environment sized for a brochure site will quietly throttle a coverage strategy, and you will read the symptom as an SEO problem when it is an infrastructure problem.

That is the argument for dedicated hosting: predictable resources, a known patch cadence, and an escalation path that terminates in a human who can actually act. You can see how Bosseo approaches dedicated hosting if you want to compare it against what you are running now.

Your next step

Before the end of this week: open a document, write the four fields, name a person, get the escalation phone number, and send it to everyone who touches the website or the phones. Put a calendar reminder 30 days out to review resource headroom and patch latency.

Do not wait for a full rebuild to fix this. Rebuilds take months and get deprioritized. One clear change removes real friction now — and in the process, it tells you exactly which of the bigger problems you actually have.