Boards are exposed to far more information technology data than they used to be. That has, however, not necessarily improved their ability to manage risk. A monthly support pack can be full of charts and service language yet leave the board with no real feel for how near the organization came to a crisis: a trading problem, a payment failure, or a breakdown in member service. The report can be full of noise, not insights.
This is an international issue. In the United Kingdom, the Financial Conduct Authority has made it clear that boards and senior management remain accountable for operational resilience, including where third parties sit inside delivery while, in the United States, the Federal Reserve defines operational resilience as the ability to deliver critical operations and core business lines through disruption. The US Office of the Comptroller of the Currency places similar weight on governance, scenario testing, and third-party oversight as part of sound practice. In all of those regimes, boards are expected to know which services matter, how much disruption they can survive, and whether their support arrangements will hold under stress.
That logic applies no matter what business you’re running. Whether you are a mid-market hospitality group, a membership organization, a charity, or a multi-site services business you have to deal with payments, bookings, renewals, events, access to records, and connectivity between sites.
Once you list the services that genuinely matter, the role of the managed service provider stops being abstract. The provider is part of the operating spine.
Why the usual reporting leaves boards guessing
Most support reports are written to prove effort rather than results. They lean on familiar numbers:
- Tickets opened and closed.
- Average response time.
- Average resolution time.
- Device status, patching, and broad uptime figures.
Those measures belong in the operational view. They do not tell a board how close the organization came to a serious outage on a service that actually matters.
A service level agreement result of 96 percent appears comforting until you realize that one of the remaining incidents almost took out your payment flow at peak trading, or left your membership portal limping through renewal season. A neat uptime graph looks impressive until you overlay it with the handful of hours that would genuinely damage income or reputation and realize you have never seen those lines in the same place.
The Financial Conduct Authority’s 2026 operational resilience observations are useful because they emphasize discipline rather than rhetoric. They identify important business services, set impact tolerances, map the people, processes, technology, information, and third-party dependencies underneath them.
It is up to the board to then test severe but plausible disruption.
Boards outside financial services do not need the full regulated machinery, but they need that discipline if they want their reporting to mean anything.
Start with important business services
Boards do not lose sleep over servers in isolation. Consequences are what counts.
A hospitality operator cares about guests booking, paying, and being served without chaos at the tills. A membership organization cares about renewals landing, events running, and members getting friction-free access to what they have paid for. A charity may care most about donor systems, safeguarding records, and the ability of a dispersed workforce to reach core systems when it matters.
Reporting should begin there. For many mid-market organizations, the list of important business services is short:
- Customer payments and settlement.
- Booking or reservation flows.
- Member renewal and member access.
- Event delivery.
- Access to the records that underpin safe, compliant operations.
Once those services are named, the board can set an impact tolerance. The term sounds like regulation. In practice it is a simple threshold: the outer limit of disruption the organization can live with before harm becomes unacceptable.
Time is usually the primary measure. Volume sometimes matters alongside it. In some cases, trust is the deciding factor. A payment outage on a quiet afternoon may be irritating. The same issue across a Friday evening is a headline problem. A renewal system stuttering for a day during a slow period is survivable; the same behavior during your main renewal window may put your income plan at risk.
Cardonet’s article on why cyber security is a product of operational excellence covers this from another angle: outcomes depend on how the organization runs around the tools, not which tools it buys. The same is true of operational resilience.
What I expect from an MSP report that goes upstairs
If a report is going to the board, it needs to move beyond activity counts. It should give directors a clear view of exposure, movement, and unresolved risk.
A useful section would answer five direct questions:
- Which important business services rely on the managed service provider.
- Which incidents came closest to breaching an impact tolerance.
- Which workarounds were used and how they performed under pressure.
- Where supplier, platform, or local fixes have become hidden fragilities.
- What remediation is underway, with dates and named owners.
I would expect a short narrative as well. Not a generic summary. Actual judgement.
If a key service only stayed inside tolerance because a single experienced manager held a weak process together, that belongs in the report. Ditto an IT support team preventing a larger incident through rapid diagnosis and escalation and a supplier dependency turning a minor issue into a long one.
Directors need the details not the footnotes to decide whether resilience is improving, stuck, or fraying.
Four measures that tell the truth faster
A forest of metrics is not needed, but a few that expose reality are.
Four are worth elevating:
- Distance to impact tolerance – how close an important business service came to unacceptable disruption.
- Dependency concentration – where too much rests on one supplier, one operating path, one workaround, or one individual.
- Recovery realism – whether fallback arrangements have been exercised, rather than left on paper.
- Remediation pace – how quickly known weaknesses move from acknowledgement to funded action.
These are board measures. Ticket counts still matter but they belong in the operational layer.
They also change the tone of discussion. Directors stop asking, “How busy was IT?” and start asking, “Where are we most exposed, and is that exposure shrinking?” That is a healthier conversation on both sides of the Atlantic.
Where the supplier chain gets messy
On paper, an organization may have an MSP, a cloud platform, a telecoms provider, a specialist software vendor, a payments partner, and a few other supporting players. During a live incident, those boundaries blur and accountability can drift.
A booking issue may start in the application, run through connectivity, collide with identity access, and then stall because nobody is certain which provider owns the next move. A payment problem may involve the local network, terminals, gateway, and escalation path, with each supplier insisting the fault sits elsewhere.
Boards do not need detailed diagrams. They do need a clear sense of where accountability could evaporate.
I would want reporting to show:
- Where the organization is over reliant on a single provider or operating path.
- Where contracts and escalation routes are weaker than leadership assumes.
- Where local workarounds have become routine, masking structural risk.
The National Cyber Security Centre Board Toolkit is valuable here because it encourages boards to ask direct questions and demand evidence, rather than accept reassurances. The same habit serves boards well when they are assessing managed services.
Questions worth putting on the agenda include:
- Which important services are most exposed to third-party failure?
- Where would half a day of supplier underperformance cause real commercial damage?
- When did we last test a realistic disruption with the people who would actually manage it?
- What did we learn from the last near miss, and where is that learning visible?
Major incidents usually get attention. Near misses often reveal where the organization relied on luck. Those are the places where resilience needs to be strengthened.
What better looks like in the board pack
A good resilience section is compact and direct.
I would expect:
- A simple table of important business services and their impact tolerances.
- A note on any incident or supplier issue that came close to those limits.
- A short update on open remediation work and whether it is on track.
- A dependency highlight for any concentration risk that deserves board time.
- A clear view on whether resilience is improving, flat, or slipping.
That structure works as well for a restaurant group or membership body as it does for a regulated firm because it is anchored in operating reality, not in specific rulebooks.
It is also a sharper way to judge the MSP relationship. A provider that can translate support activity into a usable board-level resilience view is delivering more value than one that sends a neat monthly report full of busywork and very little judgement.
If your board pack can tell you how busy information technology support was, but cannot tell you how resilient your core services are, the reporting is unfinished. If it still treats IT support as a technical appendix, it may be time to demand better reporting. Start with a focused resilience review of your MSP relationship.
Talk to Cardonet about turning support data into a board‑level view of important services, impact tolerances, and supplier risk.
Frequently Asked Questions
Why should boards care about MSP reporting for operational resilience?
Boards are accountable for whether the organisation can keep delivering important services through disruption, including where third parties are involved. Managed service providers sit inside those service chains, so their reporting is one of the few lenses boards have into exposure, impact tolerances, and unresolved weaknesses.
What are important business services in a mid-market organisation?
Important business services are the specific activities whose failure would cause real harm to customers, members, donors, or the organisation itself. In a mid-market context that might include payments, bookings, renewals, events, and access to core records rather than every technology component in the estate.
How does an impact tolerance differ from a traditional uptime target?
An impact tolerance is the maximum amount of disruption a service can take before the harm becomes intolerable, usually expressed as a time limit agreed by the business. Uptime targets describe average availability over longer periods and can hide short, high-impact outages that matter far more to boards and regulators.
Which MSP metrics are most useful for board-level resilience oversight?
Metrics that help boards see resilience include distance to impact tolerances for important services, areas of dependency concentration, whether fallbacks have been exercised, and the pace of remediation on known weaknesses. Ticket counts, response times, and resolution averages still matter but belong in the operational layer rather than at the centre of board packs.
How can boards challenge MSPs without getting lost in technical detail?
Boards can use plain-English questions adapted from resources such as the National Cyber Security Centre Cyber Security Board Toolkit to probe resilience without needing deep technical knowledge. Asking where important services are exposed to third-party failure, when realistic scenarios were last tested, and what was learned from near misses keeps the conversation focused on outcomes and evidence.
You must be logged in to post a comment.