Security services are often scoped around what a provider will do. They should be scoped around what will be different afterwards. An outcome-led service names a baseline, a target, a measure and an owner. Everything else is activity.
Activity is easy to buy. Change is what you need.
A statement of work usually lists things a provider will do: run a monthly scan, deliver an assessment report, monitor alerts, supply advisory hours. These are easy to price, easy to verify and easy to renew. They also say little about whether the organization is safer at the end. A report can arrive on time and change nothing.
Take a hypothetical vulnerability management engagement. The activity version: scan monthly and publish a report. The outcome version: critical vulnerabilities on internet-facing systems are fixed or mitigated within a window the business has agreed, and the number of exceptions is visible to the CISO. The service line is the same. The accountability is not. In the first, the provider succeeds when the report ships. In the second, success depends on whether exposure shrinks.
The frameworks already point this way
NIST Cybersecurity Framework 2.0 is written as outcomes. Its Core describes results to achieve, not tasks to perform. An organization records a Current Profile, chooses a Target Profile and plans to close the gap. Tiers describe how rigorous its governance and risk management practices are. ISO/IEC 27001 requires continual improvement, and ISO/IEC 27004 covers how to monitor, measure, analyze and evaluate security performance. A buyer who cites these in front of an auditor can cite them in a contract.
What outcome-led looks like across common services
| SERVICE | ACTIVITY-LED SCOPE | OUTCOME-LED SCOPE |
|---|---|---|
| Cyber risk assessment | Workshop held, report issued | Top risks ranked, each with an accountable executive and a recorded decision |
| Penetration testing | Findings report delivered | Findings fixed and retested, and the tested attack path no longer works |
| SOC / MDR | Alerts triaged, tickets raised | Agreed incident classes contained within agreed times, with detection coverage verified by testing |
| Compliance | Gap assessment delivered | Controls operating, with evidence an auditor or regulator accepts |
| Remediation | Fixes applied | Recurring finding types removed at source |
| vCISO advisory | Hours delivered | Roadmap decisions made and delivered, and board reporting in place and used |
What an outcome statement needs
Use six elements. If one is missing, the statement is still an activity description.
-
Baseline. Where things stand now, measured the same way you will measure later.
-
Target. The result, in terms the business recognizes.
-
Measure. A figure or a test that someone outside the engagement can check.
-
Owners. A named person on the buyer side and one on the provider side.
-
Dependencies. What the buyer must supply: access, change windows, decisions and staff time.
-
Review date. When the result will be checked.
Where outcome-led breaks
Outcomes often depend on things a provider does not control. Patching speed depends on the buyer’s change windows. Containment time depends on who is allowed to isolate a host at 3 a.m. Contract an outcome the provider cannot influence and you get disputes, not improvement.
Measures also get gamed. Judge a SOC on tickets closed and tickets get closed. Judge it on mean time to resolve and hard cases wait. Prefer measures verified by testing over self-reported ones, such as running detection tests against agreed techniques. Pair every speed measure with a quality measure.
Short contracts fit slow outcomes badly. A twelve-month term cannot be judged on a result that takes eighteen months. Split the commitments instead: milestones the provider controls, indicators both sides share, and outcome measures reviewed over a longer horizon.
A hybrid works best. Keep fixed-scope activity for hygiene work where the activity is the point, such as a patch cycle or a log review. Use outcomes where the business needs a result. Share accountability where an outcome depends on both sides, and write the dependencies into the contract.
What changes for the buyer
Outcome-led buying asks more of the buyer. You need a baseline, which means measuring first. You need to decide what better means before the engagement starts. You may also find that the provider’s work is not the bottleneck. That is useful to know. Without it, money goes on activity while the real constraint stays untouched.
Next step
Take one current engagement and rewrite its scope as a single outcome statement using the six elements. If the statement will not fit, because there is no baseline or no owner, you have found what the engagement needs before it can be judged. Continuous improvement works the same way. Each cycle starts from a measured position and ends with a measured change.
Sources
1. NIST, The NIST Cybersecurity Framework (CSF) 2.0, Cybersecurity White Paper 29.
2. ISO/IEC 27001, Information security management systems, requirements.
3. ISO/IEC 27004, Information security management, monitoring, measurement, analysis and evaluation.
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionBuild & Transform CybersecurityTurn a long list of projects into a lasting program.See how we work →Related service
Continuous Security Improvement
Use this to establish measurable security improvement.