Managed vs. Self-Service Cyber Risk Quantification

TL;DR

‍

• Self-service and managed describe who operates the cyber risk quantification program, with the models, the data, and the outputs identical across both.
• Self-service suits organizations with a risk analyst who can own scoping, asset mapping, and the quarterly reporting cycle, and it puts a first quantification in reach inside a day.
• A managed program hands configuration, data integration, report building, and model tuning to the vendor, leaving internal teams with stakeholder alignment and the decisions themselves.
• The deciding question is internal hours rather than budget, since the operational load of running quantification well lands on roles that already have full calendars.
• Managed delivery costs more and gives up some internal fluency with the model, which matters for organizations building a long-term risk function.
• Organizations move between the two models in both directions, and the migration is a matter of handover rather than reimplementation.

‍

Two Ways to Run the Same Program

‍

Organizations evaluating cyber risk quantification usually arrive at a second decision once they have picked a platform, which is whether their own team will operate it or whether the vendor will. The two models produce the same quantified outputs from the same models and the same external data. What separates them is who does the work of scoping entities, mapping assets, running the integrations, building the reports, and keeping the whole thing current as the organization changes.

‍

The honest answer for most buyers comes down to internal hours. Security and risk teams rarely have a spare analyst, and quantification done properly asks for sustained attention from someone who understands both the organization's technology estate and how executives read financial exposure. Organizations with that person in place tend to be better served running the program themselves, since internal fluency with the model compounds over years. Organizations without one get more out of a managed program than they would from a platform login nobody has time to open.

‍

What Running Cyber Risk Quantification In-House Asks For

‍

Running cyber risk quantification internally gets undersold in both directions. Vendors describe it as a login, and skeptics describe it as a research project. The first month is the useful thing to look at, because the work splits into three stretches that demand different people and different amounts of time.

‍

The First Quantification Lands Inside a Day

‍

A first run needs firmographic details, a picture of the technology estate, data holdings by type and volume, and a controls assessment. Organizations that already hold a cybersecurity maturity assessment against NIST CSF, CIS, ISO 27001, or SOC 2 have most of that on hand. The output arrives the same day, covering modeled loss scenarios across the entity portfolio, average annual loss, loss exceedance curves, 1:100 tail risk, and the event types and attack vectors sitting behind the numbers.

‍

Weeks Two Through Four Are Where the Hours Go

‍

The second stretch turns a first result into something an executive will act on, which means working through control-level recommendations, simulating the effect of planned investments, and folding incident intelligence into the cyber risk register. None of it is technically difficult. All of it requires someone who can get answers from asset owners, from the people who run the GRC platform, and from whoever can say what counts as a business unit.

‍

The Program Only Pays Off When It Keeps Running

‍

By the end of the first month an organization running the program itself should have board-ready reporting, modeled losses compared against insurance coverage, and continuous control monitoring showing how exposure responds to control changes. Holding that position is the part teams underestimate, since each quarter brings new scope, model updates to interpret, and a report that someone has to rebuild and explain. Quantification stops earning its keep the moment that cycle lapses.

‍

One Person Usually Carries the Whole Program

‍

Self-service programs concentrate in a single analyst more often than anyone plans for, and the concentration is invisible while that person is in the seat. They hold the scoping decisions, the reasoning behind each asset valuation, and the ability to explain why a number moved. A resignation takes all of it, leaving a successor to rebuild context from configuration screens and old reports. Organizations choosing self-service should decide early who the second person is, even if that person only shadows the quarterly cycle.

‍

What a Managed Program Takes Off the Internal Team

‍

A managed CRQ program moves the operational side of that cycle to the vendor while the organization keeps the decisions. Six stages of the lifecycle change hands, and reading them as a list of tasks someone would otherwise be doing internally makes the comparison concrete.

‍

Program Build and Migration Happen Before Anyone Logs In

‍

Programs get built from the ground up or migrated across from existing risk data, methodologies, and workflows, including work done manually or with a previous vendor. Organizations arriving with years of assessments behind them keep that material instead of restarting, and the transition runs without pausing the reporting their stakeholders already expect.

‍

Configuration and Data Integration Stay Tuned Over Time

‍

Entity structures, risk scenarios, and control mappings get configured against how the enterprise is actually organized, then tuned as that changes. Data integrations run continuously rather than being set up once and quietly decaying, which is the usual fate of an integration nobody owns.

‍

Reports Get Built for the Stakeholder Rather Than the Archive

‍

The Reports Hub is configured and maintained as a library covering board summaries, materiality analyses, insurance optimization views, and return on security investment analyses, with custom reports built for specific presentations. Stakeholder enablement sits alongside it, meaning CISOs and GRC leaders get the context and the narrative to present outputs themselves instead of forwarding a PDF and hoping.

‍

Where the Operational Difference Shows Up

‍

The lifecycle stages above describe scope. What a buyer feels day to day is narrower, and it concentrates in four places where quantification programs either hold together or quietly stop producing anything.

‍

Asset Mapping Decides What the Numbers Mean

‍

Mapping infrastructure, data, and third-party dependencies, then establishing what each is worth to the business, sets the ceiling on how useful every later output will be. Automated discovery handles the inventory. Agreeing on relative value takes conversations with people outside the security team, and whoever runs the program ends up chasing those conversations.

‍

Integrations Need an Owner After Go-Live

‍

SIEM platforms, endpoint tooling, asset and vulnerability management systems, and the GRC stack all feed quantification through API integrations, and the connections degrade as those systems change. An integration that silently stops delivering produces a result that still looks fine, which is the failure worth worrying about.

‍

Scenario Modeling Reflects the Enterprise Only With Effort

‍

Simulations tailored to industry, infrastructure, past incidents, and current control posture beat generic modeling by a wide margin, and the tailoring draws on both top-down and bottom-up analysis. Getting there means feeding the model specifics it cannot discover on its own, including the revenue processes that matter and the dependencies the architecture diagram leaves out.

‍

Benchmarking and Executive Reporting Are Recurring Work

‍

Comparing exposure against peers, tracking average annual loss against the industry, and translating all of it into a document a board reads without a presenter are quarterly tasks rather than one-time builds. The recurring nature is the real cost, since quantification only changes decisions when the numbers arrive in time for them.

‍

When Self-Service Is the Better Call

‍

Managed delivery is not the right answer for everyone, and the cases where it fits badly are predictable enough to name.

‍

Teams Building a Permanent Risk Function Should Own the Model

‍

Organizations standing up quantitative risk as a discipline, with a hired analyst and a mandate that outlasts any single vendor relationship, benefit from doing the work themselves. Fluency with how the model responds to changes in posture takes months to build and transfers poorly through a quarterly handover. Outsourcing operations early can leave a team auditing a model it did not build and dependent on a vendor to explain its own exposure figures, which is a weak position when a board asks a question nobody internally can answer.

‍

Small Scope Does Not Need a Managed Wrapper

‍

A single entity with a straightforward technology estate and one annual board report does not generate enough operational load to justify the service. The platform's own onboarding and the assigned customer success manager cover that situation, and every pricing tier includes both. Paying for managed delivery against that scope buys convenience rather than capability.

‍

Managed Programs Still Require Internal Time

‍

The word managed oversells the reduction. Scoping decisions, asset valuation, and stakeholder alignment stay internal in both models, because no vendor can decide what a business unit is or what an outage would cost in lost revenue. Buyers expecting to hand over the program entirely tend to be the ones who end up disappointed, and the honest framing is a reduction in operational hours rather than their elimination.

‍

How the Two Models Differ Commercially

‍

Managed delivery is a distinct program rather than a pricing tier, which means it sits beside the platform subscription instead of replacing it. Understanding that structure matters during budgeting, since the two lines get approved by different logic and sometimes by different people.

‍

Support and Onboarding Come With Every Tier

‍

Dedicated onboarding, ongoing platform guidance, and an assigned customer success manager are included regardless of subscription level. Self-service in this market does not mean unsupported, and buyers comparing vendors should check that distinction carefully, since some treat basic onboarding as a paid add-on.

‍

Pricing Tracks Requirements Instead of Company Size

‍

Kovrr's CRQ pricing depends on what the program needs to do, covering the granularity of insights, the loss scenario analyses, the reports, and the features in scope. Revenue and headcount do not set the figure. Plans scale as requirements grow, whether that means more users, more frequent quantifications, or capabilities that were out of scope at the start.

‍

The Comparison Is a Service Fee Against a Salary Line

‍

Staffing is the largest recurring cost in most quantitative risk programs, which makes the managed fee a substitute for a position instead of an addition to the software budget. Organizations weighing the two should price a risk analyst with quantification experience in their own market, including recruitment time and the months before that hire is productive, then set that against the managed program fee and the wider total cost of ownership. Finance teams tend to find that comparison more persuasive than any argument about platform features, and it reframes the decision as one about where a capability lives instead of what a tool costs.

‍

Moving Between the Models Is a Handover, Not a Rebuild

‍

Organizations switch in both directions. Existing platform customers can hand operational maintenance to the managed program once scope outgrows the team, and the program scope gets tailored to wherever the organization is starting from. Teams moving the other way, usually after hiring an analyst, keep the configuration, the integrations, and the historical results, which preserves the baseline every later quantification is measured against.

‍

What the Quantified Outputs Get Used to Decide

‍

Both models produce the same metrics, and the metrics only matter because specific decisions hang on them. Knowing which decisions are in play helps size how much operational support the program needs, since a company quantifying once a year for a board deck has different requirements from one feeding insurance renewals and quarterly budget cycles.

‍

Average Annual Loss Sets a Risk Appetite Anyone Can Hold

‍

Average annual loss gives executives a figure to place alongside the other operational risks the business already carries, which turns risk appetite from a sentence in a policy document into a number leadership can accept or refuse. A company looking at nine million dollars of expected annual cyber loss can decide to absorb it, or fund initiatives that bring it down to something it can absorb. Appetite statements written without that figure tend to go unexamined until an incident tests them.

‍

Tail Figures Drive Insurance and Worst-Case Planning

‍

The 1:100 annual loss describes the amount with a one percent chance of being met or exceeded in a year, which is the figure that decides limits, retentions, and whether existing coverage leaves an uncovered exposure. Boards use it differently, as the worst plausible year to prepare against. Reading the full loss curve against a policy is what turns a renewal conversation from a negotiation over price into one about whether the structure matches the risk.

‍

Exposure Reduction Per Dollar Beats Spreading Budget Evenly

‍

Security budgets distributed evenly across open findings reliably overfund low-impact work. Quantified output ranks control upgrades by the exposure each removes, which supports budget justification with an argument a CFO can follow. Both delivery models produce this analysis, and both depend on quantifications being rerun often enough to reflect the current estate, which annual subscriptions allow without a per-run charge.

‍

Deciding Between Them

‍

The decision comes down to a small number of questions with honest answers available before any contract gets signed. Count the hours a named person can give the program each month, not the hours the role nominally has. Look at how many entities or business units need quantifying in year two instead of year one, since operational load scales with scope rather than with the first assessment. Check who in the organization will stand in front of the board and answer follow-up questions, because that person needs fluency with the model whichever delivery model is chosen. Hold the whole decision against one test, which is whether the program will change a decision within its first year. Quantification that produces credibility and awareness while leaving budget allocation, insurance limits, and mitigation sequencing exactly where they were has not earned its cost under either model.

‍

Organizations that answer those questions and still land somewhere ambiguous tend to do well starting self-service and moving to managed when scope forces the issue. The reverse works too, and neither direction wastes the configuration work already done. What fails is picking managed delivery to avoid a staffing conversation, then discovering that scoping and valuation decisions still need an internal owner who was never appointed.

‍

Kovrr's CRQ experts walk buyers through this comparison, including the cases where self-service is the stronger answer. Talk to a CRQ expert about which model fits the team actually available.