A cybersecurity risk assessment is a structured review that identifies what an organisation depends on, what could go wrong, and what should be fixed first. That definition is well covered for buyers; this post is written for the people on the other side of the table — MSP technical leads and MSSP partners running cybersecurity risk assessment for MSPs as a service line for SMB and mid-market clients.
If you came here looking for the foundational answer for a client of your own, see our earlier piece on what a cybersecurity risk assessment is and why every client needs one. That post is written for the buyer; this one is written for the deliverer — the partner who has to scope it, run it, price it, and present the findings to a business owner who has never read a NIST document.
According to IBM Security, “the global average cost of a data breach reached $4.88 million in 2024,” and 70% of breached organisations reported significant or very significant disruption. For SMB clients, those numbers feel abstract until you map them to their own systems — and that is what a risk assessment delivers.
What a Risk Assessment Actually Produces for Your Client
Most explainers describe risk assessment as a process. From a delivery angle, framing is incomplete: the client receives a deliverable, and the deliverable is what gets paid for.
A well-run engagement should produce three artefacts:
- An asset and dependency map. Short inventory of the systems, data, and third parties that matter to the business — usually 20 to 60 line items for an SMB.
- A risk register. Prioritised list of risks with likelihood, impact, recommended action, and a named owner. This is the document the client lives with for the next year.
- An executive summary. A two-to-four-page narrative the owner or CFO can read in ten minutes, written in business language, with a clear “fix first” list.
Describe the process in the methodology section of the statement of work; describe the three deliverables in the pricing line item. Clients buy outputs, not processes.
Choosing the Right Framework: NIST 800-30, CSF 2.0, or ISO 27005
The most common question from MSP technical leads is which framework to anchor on. All three below are usable; the right pick depends on the client’s regulatory exposure, maturity, and what the partner can deliver.
The NIST Risk Management Framework is explicit that its methodology applies “within any type of organization regardless of size or sector” — the line to quote when a client objects that enterprise frameworks are overkill for a 60-person SMB.
| Framework | Best fit | Output shape | Effort for a 50–250 user SMB |
|---|---|---|---|
| NIST SP 800-30 | Clients needing a formal, auditable risk register — typically for cyber-insurance underwriting, regulator scrutiny, or post-incident review | Quantitative or semi-quantitative risk register with explicit threat-source / vulnerability pairing | 4–8 weeks |
| NIST CSF 2.0 (ID.RA) | First-time SMB clients with no prior security baseline; lightweight entry point | Maturity scoring across the six functions, plus a prioritised gap list | 2–4 weeks |
| ISO/IEC 27005 | Clients pursuing ISO 27001 certification or with EU regulatory exposure (NIS2, DORA) | Risk register aligned to the ISMS scope, ready to feed into the Statement of Applicability | 4–6 weeks |
For NIST CSF risk assessment work, anchor on the Cybersecurity Framework and use the ID.RA subcategory as the backbone. CSF gives a methodology a client can read in a single sitting; SP 800-30 gives the rigour an insurer or auditor will accept; ISO 27005 gives continuity into a longer compliance roadmap.
Pick one as the partner default and train the team on it. Offering all three and inheriting the operational overhead of supporting all three is the most expensive mistake at this stage.
Scoping an SMB Assessment: Four Questions Before You Start
Most MSP risk-assessment engagements drift over budget at the scoping stage. SMB security risk assessment work is rarely complicated; it is almost always under-scoped. Four questions handled before the SOW is signed prevent most of the rework.
- What is the trigger? A cyber-insurance application, a failed audit, a board request, a peer breach, a planned acquisition. The trigger sets the report’s audience and depth. An underwriter-driven assessment needs a quantitative register; a board-driven assessment needs a one-page heat map.
- What is in scope and what is out? Define the asset boundary in plain terms, for example, “the client’s Microsoft 365 tenant, two on-premise servers, the CRM, the website, and the manufacturing OT segment, but not the corporate parent’s shared HR system.” Anything ambiguous becomes a scope dispute later.
- Who is the recipient? The owner, the CFO, the in-house IT lead, an external auditor, and an insurer. Write the executive summary for the most senior recipient, the technical detail for the most operational one.
- What does “done” look like? Three deliverables, one workshop, signed acceptance, and defined upfront.
ConnectWise’s SMB cybersecurity research found that 58% of SMBs view improved security as a key benefit of working with an MSP, but 73% are not fully confident in their MSP’s ability to defend them. A scoping conversation that answers those four questions is where that confidence is built.
Three Delivery Failure Modes That Kill MSP Engagements
Three patterns recur across MSP risk-assessment engagements that go sideways, none technical.
The interview-only assessment. The team books five calls and produces a register based on what people said. No tooling output, no configuration review, no log sampling. The first time an insurer or auditor asks how a finding was discovered, the engagement loses credibility. Every finding should cite at least one evidence source — interview, configuration review, log sample, scan output, or document review.
The vulnerability-scan-as-risk-assessment. A scanner is run, the output reformatted, and CVSS scores presented as risk ratings. CVSS measures technical severity, not business risk: a critical CVE on an isolated test server is not the same risk as a medium CVE on the financial reporting system. Every finding should carry a separate business-impact rating alongside the technical severity.
The 80-page report no one reads. The team produces a long document, the workshop walks through 80 pages of detail, and the client goes quiet. Six months later, nothing has been remediated. Lead the readout with the executive summary and the “fix first” list; treat the long report as the appendix.
The common thread: the assessment is delivered to the team that ran it, not to the client who paid for it.
Translating Findings for a Client Without a CISO
Cynomi’s research on MSP statistics notes that “64% of SMBs operate without any CISO.” For most clients, the most senior security reader of the report is the MSP itself. The risk register has to work in a room where the most senior person is a CFO or the founder.
A risk register for small business clients should fit in a single spreadsheet view and have three columns the client cares about, not seven:
- The finding – described in one sentence, no jargon. Not “MFA enforcement gap on Conditional Access policy”; instead, “an attacker who steals an employee’s password can sign in to email without a second check.”
- The business impact – the realistic worst case in money, downtime, or regulatory consequence. Not “high”; instead, “an email compromise of the finance team could redirect a supplier payment, with median recoverable loss in this industry around $80k.”
- The recommended action is the next step, an owner, and a rough effort estimate. Not “implement Zero Trust”; instead, “switch on number-matching MFA across all admin accounts, IT lead, two days.”
Severity scores belong in the appendix, not on the front page. Lead the readout with the three-to-five findings that would change the client’s tomorrow.
This shape also answers a common follow-up: how often should an SMB get a cybersecurity risk assessment? Annually, as a baseline, with a lighter gap review after any significant change: a new cloud workload, an acquisition, a regulatory shift, or a post-incident review.
Pricing and Positioning Assessments as a Recurring Service
A risk assessment delivered once is a project; one delivered annually with quarterly check-ins against the action list is a service. The economics and the client retention sit in the second model.
Three positioning principles hold across MSP partner networks:
- Price the deliverables, not the days. Clients understand “an asset map, a risk register, and an executive readout for £X.” They do not understand “five days of a senior consultant at £Y.”
- Sell the next year, not the engagement. The assessment is the entry point; the value is the partner working through the action list with the client over the following twelve months. A managed security service provider risk assessment that ends at the readout leaves most of its value on the table.
- Anchor pricing to the client’s risk surface, not their headcount. A 40-person fintech with regulated data is a different engagement to a 200-person manufacturer with three servers. A short scoping questionnaire sets the band.
For partners working the build-versus-buy trade-off, the broader question of how MSPs position security services against in-house alternatives and how MSP cybersecurity partnerships are typically structured and priced covers the pricing mechanics in more depth.
How CyberGlobal Partner Network Backing Strengthens Your Practice
Risk assessment as a recurring SMB service line has two operational constraints: methodology depth, the partner needs senior framework experience to defend findings to insurers, regulators, and counsel, and delivery capacity, running engagements without pulling the technical lead off everything else for three weeks at a time.
CyberGlobal’s governance, risk and compliance services are built to support partners on both fronts. Senior delivery teams provide the framework backing, risk-register templates, and executive readout shape, so partners can offer enterprise-grade methodology at SMB economics without rebuilding the wheel for each engagement.
For MSPs and MSSPs running security as a partner-delivered service line, the practical next step is a scoping conversation about the first three engagements rather than a generic capability call. Similar partners across EMEA and the US are running this service line today.
