Third-Party Risk as a Service: The MSP Pricing and Margin Playbook

Third-party risk management looks like a natural adjacency for an MSP, MSSP, or cybersecurity consultancy. Clients already ask for help with security reviews, assurance evidence, supplier questionnaires, and compliance obligations. The work repeats. The risk persists. A recurring service should follow.

Yet many providers turn that opportunity into a low-margin administration desk. They quote a flat fee for every vendor, promise to manage whatever questionnaires arrive, and discover that one critical cloud provider takes more analyst time than fifty low-risk suppliers. Senior consultants become evidence chasers. Clients delay risk decisions. Sales keeps adding custom reviews because the service boundary was never written down.

The problem is not demand. It is product design.

A profitable third-party risk service sells an operating rhythm for making vendor decisions. It does not sell questionnaire volume. The provider maintains a reliable inventory, assigns effort according to risk, reviews evidence, identifies gaps, routes decisions to accountable owners, and keeps the portfolio current. Pricing must reflect that work and make unusual demand visible before it erodes delivery capacity.

For operators, the central rule is simple: price the decision system, not the paperwork.

Build the offer around a managed decision loop

A client does not become safer merely because 200 questionnaires were sent. It becomes better governed when the important vendors are known, the right evidence is reviewed, material gaps reach an accountable person, and renewal or risk-acceptance decisions happen on time.

That sequence is the product. Write it as a closed loop:

1. Discover and maintain the vendor inventory.
2. Tier each vendor according to business impact, access, data, and substitutability.
3. Apply due diligence that matches the tier.
4. Review evidence and record findings with a confidence level.
5. Assign actions, escalation, or risk acceptance to named owners.
6. Reassess on a schedule or when a meaningful event occurs.
7. Report portfolio changes and unresolved decisions.

This framing changes both sales and delivery. Sales can describe a managed outcome instead of a software feature list. Operations can standardise the work across clients. The client understands that its own leaders still own commercial and risk decisions, while the provider runs the system that makes those decisions possible.

A multi-tenant TPRM platform should support the loop, but it is not the offer by itself. If the service promise is simply access to a portal, buyers can compare it with a licence. If the promise is a current, decision-ready vendor risk portfolio, the provider’s process and judgement remain central.

Draw the service boundary before setting a price

TPRM touches procurement, privacy, legal, security architecture, incident response, compliance, and business continuity. Without a boundary, every adjacent request lands in the delivery queue.

Define the base service in operational terms. It might include inventory maintenance, tiering, standard intake, questionnaire administration, assurance-document review, finding management, reassessment scheduling, and a monthly portfolio meeting. State the number or class of reports, meetings, and active reviews included. Define what counts as complete at each stage.

Then name what is outside the recurring fee. Common exclusions include:

• drafting or negotiating contract language
• giving legal or regulatory opinions
• performing penetration tests or technical validation inside a vendor environment
• remediating a supplier’s controls
• completing unlimited bespoke customer questionnaires
• running procurement selections
• providing unrestricted event-driven or emergency reassessments

Exclusion does not mean refusal. It means the work follows a separate statement of work, rate card, or service tier. A consultancy may be well placed to provide contract review or technical testing, but bundling those variable activities into the standard fee makes the base service impossible to forecast.

Document client responsibilities as carefully as provider responsibilities. The client must identify vendors, disclose business context, appoint decision owners, respond to escalations, and approve risk acceptance. An MSP cannot promise a current register when new suppliers appear only after they have signed contracts.

Weight vendors by effort instead of counting logos

Per-vendor pricing is attractive because it is easy to quote. It is also a poor proxy for delivery cost. A payroll platform holding sensitive data, supporting a critical process, and relying on several subcontractors is not equivalent to a supplier of office furniture.

Create a small number of tiers and attach an effort weight to each one. The exact labels matter less than consistent admission criteria. A practical starting model might look like this:

Vendor tier	Typical characteristics	Illustrative effort weight
Critical	Business stoppage, privileged access, sensitive data, or difficult replacement	5 units
Material	Important process or meaningful data access with workable alternatives	2 units
Standard	Limited access and impact, assessed through a lighter workflow	0.5 units
Inactive or out of scope	No current service dependency or no relevant access	0 units

The weights are not universal truths. They are a capacity-planning device. Start with assumptions, record actual analyst time for 60 to 90 days, and recalibrate. If a critical-vendor review takes eight times as long as a standard review, a five-to-one weight is understating the difference.

Use clear triggers for changing tiers. A vendor may move up when it receives privileged access, begins processing a new data class, becomes operationally critical, or adds a high-impact subcontractor. It may move down when access ends or the service is replaced. Tier changes should affect the portfolio allowance at the next agreed billing point rather than becoming invisible free work.

This approach also improves client conversations. Instead of arguing about why 100 vendors cost more than 80, the provider can explain how the risk and workload mix changed.

Use a three-part pricing architecture

A durable price separates the work of establishing the programme from the work of operating it. Use three components.

First, charge a one-time onboarding fee. It covers inventory cleanup, stakeholder interviews, tiering workshops, workflow configuration, data migration, baseline reviews, report design, and the initial operating calendar. More on this work in a moment.

Second, charge a recurring governance base fee. This pays for the service infrastructure that exists even with a small portfolio: programme ownership, queue management, quality assurance, client meetings, platform administration, reporting, and service management.

Third, add a portfolio fee or band based on weighted vendor units. The client buys an allowance that fits its current mix, with published bands or rates for growth. This protects the provider when the client adds critical vendors without making every small inventory change a billing dispute.

The commercial model can be expressed as:

Monthly service fee = governance base + weighted portfolio band + contracted exceptions

Consider an illustrative portfolio with six critical vendors, eighteen material vendors, and forty standard vendors. Using the sample weights above, it carries 86 units: 30 plus 36 plus 20. If the selected service tier includes 75 units, the proposal should price the next band or the additional eleven units. The number of logos is 64, but the weighted workload is what informs capacity.

Avoid charging primarily by questionnaire count. That model rewards activity rather than risk reduction and invites clients to send every available template. Avoid unlimited reviews too. An unlimited promise is merely an unknown liability with friendly wording.

Model gross margin from minutes and roles

The software price is usually the easiest cost to see. Labour is where the service wins or loses margin.

Map every recurring workflow and record the role, touches, and active minutes required. Include intake validation, client clarification, questionnaire chasing, evidence review, quality assurance, escalation preparation, meeting time, and report production. Waiting time is not direct labour, but the follow-up it creates is.

Calculate delivery cost with loaded rates rather than salary alone:

Delivery cost = role-based labour + platform and data costs + allocated QA + service management + exception cost

Then measure gross margin by client cohort, not only across the entire practice. Averages can hide a bespoke account whose custom workflow consumes senior time while standard clients subsidise it.

Use both median and upper-percentile effort. The median shows the normal run rate. The upper percentile shows whether difficult vendors are overwhelming the service. If most critical reviews take three hours but a recurring group takes twelve, decide whether that group needs a specialist workflow, a higher weight, or explicit exception pricing.

Do not turn a target margin into a delivery shortcut. Evidence still needs a defensible review. The operator’s job is to remove avoidable work: duplicate data entry, manual reminders, inconsistent templates, unnecessary senior approvals, and reports rebuilt from scratch. Margin earned by a repeatable system is durable. Margin earned by superficial assessment becomes a quality and liability problem.

Treat onboarding as a paid project

Onboarding is not a free prelude to recurring revenue. It is often the most uncertain and senior-heavy phase of the engagement.

Client inventories arrive with duplicate supplier names, inactive contracts, missing owners, subsidiaries recorded as separate vendors, and software purchases hidden on expense cards. Business context has to be reconstructed. A provider may also need to import old questionnaires, validate certificates, identify expired evidence, agree tier definitions, configure platform integrations, and train decision owners.

Price onboarding against assumptions written into the proposal: number of records supplied, expected data quality, number of stakeholder groups, historical documents to migrate, and number of baseline assessments. Define change control if those assumptions are wrong.

Use milestone acceptance rather than an open-ended promise. Sensible milestones include a normalised inventory, an approved tiering model, assigned owners, configured workflows, an initial portfolio view, and a signed operating calendar. The recurring service begins when those conditions are met.

If a client needs commercial flexibility, the provider can spread the onboarding charge over an initial term, but it should remain visible as implementation work. Hiding it inside the monthly fee makes early termination painful and prevents the practice from learning whether its setup process is profitable.

Standardise the recurring delivery rhythm

The recurring service needs a calendar that clients and analysts can predict. Otherwise every account becomes a different collection of reminders and meetings.

A standard rhythm could include weekly queue triage, monthly portfolio review, quarterly tier validation, and annual service-design review. Critical vendors may have more frequent reassessment or event triggers. Standard vendors may use a lighter annual or biennial workflow, depending on the client’s risk model.

Create playbooks for evidence sufficiency, stale information, non-responsive vendors, conflicting answers, inherited risk, compensating controls, and escalation. Define which decisions a junior analyst can make, which require quality review, and which belong to the client. This lets the practice use a blended team without pretending that all judgement can be reduced to a score.

Map evidence to the client’s relevant compliance frameworks, such as ISO 27001, SOC 2, NIST CSF, PCI DSS, or CIS Controls, after the core risk workflow is stable. One piece of assurance evidence may support several frameworks. The provider should reuse that evidence without promising that a vendor’s certificate proves every control in the client’s environment.

Keep the service global by designing around common risk concepts: access, data sensitivity, operational dependency, concentration, resilience, and assurance. Region-specific obligations can be configured when a client actually needs them; they should not dictate the default delivery model.

Automate administration, preserve judgement

The best automation removes work that never needed an analyst. Intake forms can populate a vendor record. Rules can suggest an initial tier. The platform can distribute standard questionnaires, chase responses, flag expiring evidence, schedule reassessments, reuse approved answers, map controls, and assemble recurring portfolio reports.

Human review remains necessary where context changes the conclusion. A valid SOC 2 report may omit the service the client uses. An ISO 27001 certificate may cover only one location. A questionnaire answer may describe a planned control rather than an operating one. A low external risk score may say little about privileged access or business continuity.

Build explicit confidence states into the workflow: verified, supported with limitations, self-attested, unavailable, and stale. That is more useful than forcing every vendor into a precise score that implies certainty the evidence cannot support.

Use a shared MSSP and vCISO operating platform so analysts can work across tenants with consistent objects, queues, permissions, and reports. Multi-tenancy should reduce duplicated administration while preserving client separation. Test role-based access, audit trails, exports, and offboarding before trusting the platform with the service.

Automation should also expose failures. A broken integration, bounced questionnaire, or expired token must create an owned exception. Silent gaps are dangerous because an empty dashboard can be mistaken for a clean portfolio.

Put scope, response times, and liability into the contract

A TPRM service depends on parties the MSP does not control. Vendors may ignore requests. Evidence may be incomplete. The client may defer a risk decision. Contract language and service levels must reflect that reality.

Promise response and process commitments that the provider can own: time to validate a new request, time to review complete evidence, escalation cadence after non-response, and report delivery dates. Do not promise that every vendor will respond or that every assessment will finish within a fixed period regardless of dependency.

Define volume boundaries for new-vendor intake, concurrent critical reviews, custom questionnaires, rush requests, mergers, and event-driven reassessments. State how excess demand is queued or priced. Include a process for re-baselining the portfolio when vendor counts or tier mix moves beyond the contracted band.

The agreement should also explain that the provider assesses available information and supports decisions; it does not guarantee a third party is secure or predict every incident. Set rules for reliance on client and vendor representations, retention of evidence, confidentiality, conflicts, subcontractors, and limits of responsibility. Have qualified counsel adapt the terms to the provider’s services and jurisdictions.

This is not paperwork added after the offer is designed. It is part of the operating model. A vague contract invites sales, clients, and delivery teams to hold three different definitions of the same service.

Sell the service when a decision trigger appears

Generic fear is a weak sales motion. Strong opportunities appear when a client has a decision it cannot support with its current vendor process.

Common triggers include an enterprise customer asking for supply-chain assurance, an insurer probing dependencies, a board questioning concentration risk, an audit exposing missing evidence, a major contract renewal, rapid software adoption, or a formal assurance programme. These events create urgency without tying the offer to a single country’s rules.

Discovery should quantify the operating problem:

• How many vendors can access sensitive data or production systems?
• Which suppliers could stop an important service?
• Who decides whether a vendor’s residual risk is acceptable?
• How long does a critical review take from request to decision?
• How many reviews are waiting on evidence, internal context, or approval?
• Which renewals will occur before the next assessment cycle?
• How much senior time is spent chasing rather than deciding?

Do not give away a full inventory cleanup as a sales assessment. A short diagnostic can estimate portfolio size, tier mix, backlog, stakeholders, and desired cadence. The paid onboarding project turns those estimates into a controlled system.

Proposals should show the decision loop, service calendar, client responsibilities, weighted allowance, exception schedule, and sample reporting. That makes the offer harder to compare with a portal licence or a low-cost questionnaire bureau.

Attach advisory services without making the bundle vague

TPRM creates legitimate paths into broader advisory work. Vendor findings may expose weak access governance, incomplete continuity planning, missing policies, or unmanaged concentration. Those issues can feed a vCISO service, compliance programme, security roadmap, or targeted remediation project.

Keep the products distinct. The TPRM service manages vendor-related evidence, findings, decisions, and cadence. The vCISO service owns broader security leadership and programme priorities. Technical teams implement changes. Clear handoffs let the provider expand revenue without turning every discovery into unpriced work.

Bundle only when the delivery model supports it. A higher service tier might include a quarterly executive risk session led by a senior adviser, while the standard tier provides an operational portfolio review. Both should specify preparation time, participants, outputs, and decision rights.

The cross-sell works in both directions. Existing advisory clients often have vendor risk obligations but no operating capacity. Existing managed-security clients may already hold telemetry that improves vendor access context. Existing compliance clients need third-party evidence across multiple controls. The provider can connect these services through shared data and governance while keeping each service’s unit economics visible.

Run the practice with capacity and quality metrics

Revenue growth is not proof that the service scales. The operator needs a small scorecard that connects workload, quality, client decisions, and margin.

Track at least:

• weighted vendor units per delivery full-time equivalent
• active reviews and work in progress by analyst
• median and upper-percentile hours by vendor tier
• percentage of analyst time spent chasing evidence
• review rework and quality-assurance failure rate
• days from complete evidence to decision-ready finding
• overdue client risk acceptances and actions
• off-catalog requests by client and salesperson
• onboarding effort against estimate
• gross margin by client cohort and service tier

Review exceptions monthly. If one client repeatedly exceeds concurrent review limits, reprice or move it to another tier. If evidence chasing dominates analyst time, fix the workflow, escalation rules, or client expectations. If senior reviewers reopen the same issue, improve the playbook and training before hiring around the defect.

Use work-in-progress limits. Starting every requested review immediately makes the queue look responsive while increasing cycle time and context switching. Prioritise by criticality, renewal date, evidence readiness, and client decision deadline. Publish that logic so sales cannot silently promote every request to urgent.

Capacity should be forecast from the weighted portfolio plus expected onboarding, not raw client count. Ten small clients with clean inventories may be easier than one acquisitive client with dozens of critical suppliers and constant change.

Launch the service in 90 days without overbuilding it

In the first 30 days, define the catalogue, exclusions, tier criteria, effort weights, roles, playbooks, pricing bands, contract assumptions, and standard reports. Select a delivery platform and test one complete vendor journey, including evidence export and an integration failure. Build the economics from estimated minutes by role.

In days 31 to 60, pilot the offer with a small number of existing clients whose portfolios are representative, not unusually simple. Charge for onboarding. Record actual effort at every stage. Hold weekly delivery reviews and note every request that falls outside the catalogue. Do not automate a workflow until the team can run it consistently by hand.

In days 61 to 90, adjust weights and prices, tighten acceptance criteria, finalise sales enablement, and train a second delivery pod. Compare actual onboarding cost and recurring effort with the original model. Fix high-frequency exceptions in the service design; price low-frequency exceptions separately.

Set a gate before wider launch. The service should have repeatable onboarding, stable evidence-quality checks, a measured delivery cost, visible client decisions, and a contract that matches the work. If it depends on one senior consultant remembering how every account operates, the offer is not productised yet.

Third-party risk management can become dependable recurring revenue, but only when the provider refuses to price it as clerical volume. Define the decision loop, weight the portfolio by effort, charge separately for implementation, protect the contract boundary, and use automation to remove administration rather than judgement. That is how an MSP, MSSP, or consultancy builds a service clients can rely on and operators can scale.

GetCybr helps security providers run multi-tenant vendor inventories, assessments, evidence, risks, controls, and reporting in one operating layer. Book a GetCybr demo to see how a productised TPRM service can work across your client portfolio.