Back to blogs

Nothing broke this year. Now defend your web budget.

Open iron gates leading to the arched wooden front door of a university building
Submitted on: November 6 2026

By Fredric, Principal of Bright Plum

Your site didn't go down this year. Nobody got breached. The accessibility audit didn't turn into a lawsuit. By every measure that matters, the year went well.

Then budget season starts. Last February, a marketing director at one of our college clients emailed to plan her next fiscal year. She opened by saying she'd been happy with how the website performed, and everything she asked us to scope after that was something people could see: a fresh look, consistent templates, CRM integrations, an AI chatbot. Nothing in her email protected the work that had made the year quiet.

I don't blame her. Visible work fits in a budget request. An absence doesn't.

Leadership sees it the same way. A few years ago, a longtime client hired a new CIO, and while reviewing budgets he cut our support on one of their two sites. When we followed up, the analyst and the director gave us the honest reason they'd kept us: peace of mind. The CIO's answer was fair. How do I measure that?

This is the answer I wish they'd had. Six scores, each tied to a written description anyone can check. The full rubric is free to download at the end.

Why the usual evidence falls flat

When directors build next year's web budget, most start with last year's. Did we go over? Did we use it all? What's still sitting in the backlog?

That tells you what you spent. It doesn't tell leadership what they got. A backlog reads as a to-do list, and a to-do list invites the question of why it isn't done.

Hours don't help either. Partners charge different rates, so a bigger budget doesn't always mean more work, and "we used 200 hours" means nothing to a VP. Leadership wants to know something simpler: is the website an asset or a liability?

Visible work fits in a budget request. An absence doesn't.

Your website is where trust starts

Most institutions run security awareness training. It teaches everyone the same habit: before you trust an email or a link, check the domain it came from.

Now think about a prospective student, or a parent, who has never heard of you. When they check your domain and type it into a browser, your website is what they find. It's the front door, and it's where they decide whether to trust you.

So the real question behind your web budget is whether the site, and the work it takes to run it, keeps that trust or puts it at risk. That's the line between an asset and a liability.

Six dimensions of trust

We score web operations across six dimensions. We picked them because together they cover everything that has to hold for a visitor to trust what they find.

  • Security. AI tools now find vulnerabilities faster than most teams patch them. A vandalized or offline site breaks trust the moment someone lands on it.
  • Accessibility. It opens the site to people who need accommodations, and it's the law. A site that keeps getting sued for noncompliance has a trust problem before anyone reads a word.
  • Performance. Whether someone arrives on a phone or a laptop, they expect the page to load fast and make sense. A slow, clumsy page tells them something about you.
  • Platform health. The software, hosting and providers underneath the site. Are they supported? Will they be around? Are they worth what they cost?
  • Documentation and institutional knowledge. If the one person who knows how something works goes on vacation, gets sick or takes another job, the next change to the site is a guess.
  • Communication and reporting. Whether your team, leadership and the board understand how the parts fit together, well enough to answer a compliance question and stand up for the team that keeps the front door open.

How a site earns its score

Each dimension gets a score from 1 to 5. A 1 is ad hoc: things happen when someone remembers. A 2 is reactive: work happens when something breaks. A 3 is defined: a process exists and runs. A 4 is proactive: the process is tested and enforced. A 5 is managed: it's built into how the institution operates.

Most of the evidence comes from scans. We check the code against published vulnerabilities, crawl the site for accessibility failures, measure page speed, and confirm the platform is still in vendor support. Communication has nothing to scan, so we ask questions instead, the kind leadership should be able to answer today.

A few rules keep the scores honest.

You can't skip a level. A dimension earns the highest level where everything at that level and below is true. This year a client finished a long run of accessibility fixes and the score didn't move, because the follow-up scan that confirms the work hadn't been approved yet. The work was real. The evidence wasn't there, and the score showed the director exactly what her next approval would buy.

Some gaps hold a dimension at 2. Six requirements cover risks nothing else does, like security updates applied in the last quarter and a full accessibility scan in the last year. Miss one and that dimension can't reach 3. Performance has none on purpose. A slow site is bad, but it isn't dangerous.

Progress shows even when the score doesn't. Every score carries a count, like "one of four requirements met toward level 4." A good month shouldn't look like a flat one.

If it doesn't fit, say why. A requirement that doesn't apply to your site drops out of the count, but only with a written reason. A blank reason looks the same as a hidden gap.

Aim for 4. Level 5 depends on things only your institution controls, like its incident-response plan and whether leadership shows up to planning. Nobody gets to 5 alone.

Why documentation tends to score lowest

Across the sites we score, documentation usually comes in last. The cause is workload. Higher-ed web teams are small, and they spend their days on what the institution can see: campaign pages, content requests from every department, email, and meetings where the registrar's office or a faculty member needs help telling their story on the site.

Writing down how the tools behind that story work is the task that always waits until next week. Then someone leaves, and next week arrives.

We're part of this pattern too. Our records of a client's site are often better than what their own team keeps, which means the knowledge still lives in one place. It's our place instead of theirs. We're working to change that.

Four questions you can ask without a developer

You don't need a scan to find out where you stand. Ask your team these and listen for one thing: is the answer a document, or a name?

  1. If the person who runs our site went on vacation and something broke, would we know what to do? Where is that written down?
  2. If legal or leadership got notice that we're being sued over accessibility, what's our process? What evidence shows the work we've done?
  3. If a serious security issue were announced tomorrow, how would we confirm whether it affects us, and who would fix it?
  4. If the site went down, how would we restore it? Is that written down, and has anyone tested it?

If the answer is a person's name, that dimension is probably a 1 or a 2. You don't need to know the technical answers yourself. You need to know there's a process for each way the site could break the trust you've built.

Bring it to your budget conversation

Most higher-ed budget conversations start in January and February, with decisions due by March or April. Score your site before then.

That CIO asked how to measure peace of mind. Here's how: six scores your team can check against a written description, the distance between each one and level 4, and what it would take to close the gap.

The full rubric is free: The Web Operations Maturity Model (PDF). It has every level of every dimension, the scoring rules, and these four questions. Use it, share it, and change it to fit your team.

Rather talk than read?

If any of this sounds like your site, a 30-minute call is the fastest way to find out where you actually stand.

Book a discovery call