# MSSP Security Delivery Benchmark 2027 methodology

Status: methodology only; no 2027 results published  
Version: 0.1.0  
Published: 2026-08-12  
Owner: ContraForce Security Operations

## Purpose

The benchmark is designed to describe how managed providers deliver security incident outcomes. It has two independent inputs: an MSSP operator survey and deidentified events from participating ContraForce deployments. Survey findings and product telemetry are collected, analyzed, and labeled separately.

## Publication units

- **Operator survey:** one eligible response per provider. Recruitment source, respondent role, provider size band, service geography, question wording, response count, exclusions, and weighting must accompany every result.
- **Product telemetry:** one deidentified, pre-aggregated observation per provider cohort and measurement period. No incident payload, customer identity, tenant ID, user ID, IP address, or free-text evidence may be included.
- **Customer-reported outcome:** one provider-supplied calculation with a documented baseline, comparison period, formula, and publication consent. It is not product telemetry.

The public row schema carries `source_type` so results from these units cannot be silently mixed.

## Eligibility

The target operator population is US- and UK-based MSSPs and MSPs that deliver security operations for external customers. Final reporting must describe the achieved sample. ContraForce customers, partners, and noncustomers must be labeled; recruitment cannot be described as representative without a defensible sampling and weighting design.

Telemetry eligibility is metric-specific. Every measure must define supported integrations, active-policy requirements, event completeness, test-record exclusions, duplicate handling, partial-period rules, and any minimum activity threshold before extraction.

## Required reporting

- elapsed time: valid N, contributing-provider count, median, P90, P95, and clock boundaries;
- rate: numerator, denominator, eligibility definition, and confidence interval when appropriate;
- change: baseline and comparison periods, calculation method, valid N, range, and median;
- survey item: exact question and response options, valid N, missing-response handling, and weighting;
- every output: source type, extraction or instrument version, period, cohort definition, owner, reviewer, and limitations.

Means and best-case examples cannot stand alone. Missing values remain null and are never converted to zero.

## Privacy and consent

Public data is aggregated and deidentified before it enters this repository. Suppress or combine small cohorts that could expose a provider or customer. Named case studies remain separate from the benchmark and require written publication consent. Raw operational data, incident payloads, tenant identifiers, and survey contact details are never public benchmark fields.

## Validation gate

Before any row or result is published:

1. Freeze and checksum the deidentified input.
2. Record extraction code or survey-instrument version.
3. Confirm the field dictionary matches the calculation.
4. Reconcile valid, excluded, duplicate, missing, and total counts.
5. Reproduce published aggregates from the frozen input.
6. Complete privacy and disclosure review.
7. Assign a claim owner, review date, expiration date, and approved surfaces.
8. Obtain independent reproducibility review before using “validated.”

## Known limitations

Voluntary participation can create selection bias. Product telemetry represents participating deployments, not the market. Survey answers and customer economic outcomes are self-reported. Provider size, customer mix, licensing, geography, incident mix, staffing, autonomy policies, and accounting methods may materially affect results. Observational differences do not demonstrate causation.

## Versioning

Breaking changes to event boundaries, eligibility, or row structure increment the major schema version. Additive fields increment the minor version. Corrections and editorial clarifications increment the patch version. Every released dataset is immutable; corrections create a new version and a changelog entry.