Quarterly Business Review With Your Technology Partner: What a Useful One Covers

TL;DR: A useful quarterly business review with your technology partner ends in written decisions. The partner brings what broke and why, what was fixed, ranked risks, spend and renewals, and a plan for next quarter, all from your own systems. You bring your business plans. Last quarter's decisions get checked first.

A quarterly business review, or QBR, is the one meeting a year that happens four times on purpose. In IT, it is where you and your technology partner look at what changed in your systems, what it risked, and what to do next. Done well, it is the most useful hour you spend with them. Done badly, it is a slideshow.

The difference is rarely the partner's skill. It is whether the meeting was built to produce decisions, and whether anyone checks them three months later.

What is an IT quarterly business review for?

A quarterly business review exists so the people who pay for technology and the people who run it make the next quarter's calls together, with evidence. Status updates can travel by email. A QBR earns its hour when something gets decided: fund this, stop that, accept this risk in writing.

The federal guidance on cybersecurity governance describes this loop plainly. The Govern function of the NIST Cybersecurity Framework 2.0 includes an oversight category in which "results of organization-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy." (NIST, Cybersecurity Framework 2.0, February 2024) Results inform adjustment. That is the whole point of a review.

The same framework treats your technology partner as part of your supply chain. Subcategory GV.SC-07 says the risks posed by a supplier should be "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship." Over the course of the relationship, not once at signing. A quarterly business review is one of the most practical ways a small business can do that monitoring without hiring anyone.

Government auditors have used the same idea for more than twenty years. In its framework for managing IT investments, the U.S. Government Accountability Office defines investment oversight as reviewing the progress of IT projects and systems "using pre-defined criteria and checkpoints, in meeting cost, schedule, risk, and benefit expectations and to take corrective action when these expectations are not being met." (GAO-04-822, August 2004, applying GAO's ITIM framework, GAO-04-394G) A small firm in Westborough needs no investment board, but it does need the checkpoints and the corrective action.

Why does a quarterly business review so often feel like a waste of time?

Because many meetings do. When researchers writing in Harvard Business Review surveyed 182 senior managers across industries, 71% said meetings are unproductive and inefficient, and 65% said meetings keep them from completing their own work. (Perlow, Hadley and Eun, Harvard Business Review, 2017)

A quarterly business review has its own way of going wrong. The partner controls the data and the slides, every chart is green, the last fifteen minutes are a pitch, and you leave with a PDF and no decisions.

The research on meetings points to what works instead. A peer-reviewed study videotaped 92 regular team meetings and coded the interactions in them. Teams that showed more problem-solving and action planning were more satisfied with their meetings, "better meetings were associated with higher team productivity," and constructive meeting behavior was related to organizational success 2.5 years later. Complaining and criticizing showed negative effects that were even stronger than the positive ones. (Kauffeld and Lehmann-Willenbrock, Small Group Research, 2012)

A review of the meeting science adds the design side: circulating a written agenda before the meeting, going over it at the start, and starting and ending on time all improve how effective people judge a meeting to be. (Mroz, Allen, Verhoeven and Shuffler, Current Directions in Psychological Science, 2018, summarizing Leach, Rogelberg, Warr and Burnfield, 2009)

The recipe for a quarterly business review follows: an agenda sent ahead, action planning instead of venting, decisions written down. Brian wrote about the same instinct from the other side of the table: the client who wanted a dashboard actually wanted a decision (opens in a new tab).

What should your technology partner bring to a quarterly business review?

Everything below should come from your own systems. If the numbers would look the same for any client, they are not about you.

• Last quarter's decisions, and what happened to each. Done, not done, or changed, with a reason for anything that slipped. This comes first because it tells you whether the last quarterly business review mattered.
• What broke, and why. Every incident or outage that touched your staff or customers, with the cause in plain language. "The backup job failed for nine days because a password expired" is useful. "Two P2 incidents, resolved" is not.
• What was fixed, and what is still open. Patches, replacements, configuration changes, and the items that are waiting on a part, a vendor or a decision from you.
• Risks, ranked. A short list, most important first: what could go wrong, how likely, what it would cost you, and what it would take to reduce it. The partner should say which risks you can reasonably accept.
• Spend and renewals. What you paid for technology this quarter, what renews in the next two quarters, and any license or subscription nobody is using. Brian wrote up an afternoon audit of software spend per employee (opens in a new tab) that turns up tools paid for twice.
• A proposed roadmap for next quarter. Three to five priorities with a reason for each, sized so they can actually get done.

NIST's guidance on reporting security measures backs up the "plain language, with context" part. It warns that "if a measure is reported to stakeholders without proper context, there can be unintended consequences or indecision," and suggests a report include what risk a measure indicates, whether it fits your risk appetite, and "what prioritization, action, or decision might need to be taken." (NIST SP 800-55 Volume 1, December 2024)

On "what broke," NIST's current incident response guidance notes that improvements are often identified by holding lessons-learned meetings, which give an "opportunity to review what happened, what actions were taken, and how effective those actions were." (NIST SP 800-61 Revision 3, April 2025) For a small business, the QBR can be where that review finally happens with the owner in the room.

What should you bring to the quarterly business review?

The partner knows your systems. You know where the business is going.

• Plans for the next two quarters. New hires, a second location, a new service line, a big customer, a move. Each of these has a technology consequence that is cheaper to plan than to rush.
• What annoyed your team. The login that keeps timing out, the report someone builds by hand every Friday. Small complaints often point at real problems.
• Requests from outside. Customer security questionnaires, insurance renewal forms, an auditor's questions. These usually need your partner's input, on a deadline.
• Last quarter's written record. If you only bring one thing, bring this.

If the ownership lines between you and your partner were drawn well at the start, this list is easy. If not, I wrote about why client onboarding is where scope creep starts (opens in a new tab), and the quarterly business review is a good place to redraw those lines.

Which metrics matter in an IT QBR, and which are vanity numbers?

A vanity number is one that always looks good and never changes a decision. A useful number tells you whether something is working, and it can go the wrong way.

NIST draws a helpful line here. Implementation measures "demonstrate the progress of specific controls," such as which systems have up-to-date patches. Effectiveness measures "evaluate how well implementation processes and controls are working and whether they are meeting desired outcomes." (NIST SP 800-55 Volume 1) Both have a place, but a quarterly business review made only of activity counts tells you how busy your partner was, not whether you are safer.

Some swaps I would ask for:

• Instead of tickets closed, ask how many problems came back. A partner who closes the same issue six times looks productive on the first chart.
• Instead of uptime averaged across everything, ask for minutes that your staff or customers could not work, by system. An average can hide one painful afternoon on the system that takes bookings.
• Instead of patches deployed, ask what share of your important systems were patched within the target window, and which were not.
• Instead of response time alone, ask how long it took to actually restore service. I wrote a longer piece on why an SLA response time is not resolution time (opens in a new tab).
• Instead of "backups successful," ask when a restore was last tested, and how long it took.

Any metric that becomes a target will drift toward looking good, so keep the list short and change it when a number stops being useful. Why your team games every metric you set (opens in a new tab) covers that dynamic, and the same thinking applies to your website numbers in five website metrics that actually connect to revenue (opens in a new tab).

What are the red flags in a technology partner's QBR?

One alone proves little. Three or more in the same meeting deserve a direct conversation.

• Every number is green, every quarter, and nothing ever broke.
• The deck looks the same as last quarter's with new dates.
• The numbers come from a tool you cannot see, and the partner cannot show you the source.
• Last quarter's action items are never mentioned.
• Risks are described as industry trends instead of things in your systems.
• A large share of the hour goes to a new product or a bigger plan.
• Nobody writes down what was decided, or the summary arrives weeks later.

A healthy run of QBRs will include a quarter where the partner says nothing needs to change, and the meeting ends early. Saying so plainly is a sign the review is honest.

What does a one-page quarterly business review agenda look like?

Here is a version you can send to your partner a week ahead. The times assume a 60-minute meeting and are a suggestion, not a rule.

1. Last quarter's decisions (5 minutes). Each one: done, not done, or changed, and why.
2. What changed and what broke (15 minutes). Incidents and outages with causes, what was fixed, what is still open.
3. Risks, ranked (10 minutes). The top three to five, with what it would take to reduce each and which ones to accept.
4. Spend and renewals (10 minutes). This quarter's technology spend, renewals in the next two quarters, unused licenses.
5. Your plans (10 minutes). Business changes coming up and what they need from technology.
6. Decisions and owners (10 minutes). Three to five priorities for next quarter, each with one owner and a date, read back before anyone leaves.

The written record afterward should fit on one page: what changed, what was found, what was decided, and who owns each next step. That page becomes item one of the next agenda.

How does a QBR fit for a Central Massachusetts small business?

In a small business, the owner or office manager is usually the technology decision maker. For those owners, the quarterly business review can be the only scheduled time to think about technology on purpose instead of in an emergency.

Massachusetts adds a reason to keep good records. The state's data security regulation, 201 CMR 17.00, applies to businesses that own or license personal information about Massachusetts residents. It calls for "regular monitoring" of the information security program, for "reviewing the scope of the security measures at least annually or whenever there is a material change in business practices," and for overseeing service providers by "taking reasonable steps to select and retain third-party service providers that are capable of maintaining appropriate security measures." (201 CMR 17.03, via Cornell Law School's Legal Information Institute)

A quarterly business review does not satisfy those requirements on its own, and what your program needs is a question for your own counsel. But four dated, written records a year, each covering risks, changes and your provider's work, are a natural home for the evidence that the reviews happened. My guide to Massachusetts WISP requirements under 201 CMR 17.00 (opens in a new tab) covers the rule itself, and the MyRHC reference page for NIST CSF 2.0 (opens in a new tab) collects the framework's official sources in one place.

NIST's own small business guide to the framework asks a question worth putting at the top of any quarterly business review agenda: "As our business grows, how often are we reviewing our cybersecurity strategy?" (NIST SP 1300, CSF 2.0 Small Business Quick-Start Guide) Its supply chain guide goes further and suggests defining security requirements in service level agreements "for monitoring suppliers for acceptable security performance throughout the supplier relationship lifecycle." (NIST SP 1305, Quick-Start Guide for Cybersecurity Supply Chain Risk Management) Your SLA says what your partner promised. The quarterly business review is where you check it.

This article is general information, not legal advice. Kief Studio is not a law firm, and reading it does not create an attorney-client relationship. Laws and regulations change, so check the current text and talk with a licensed Massachusetts attorney about your situation.