Software assurance · Practical guide
Funding digital trust with your own evidence
Build a decision around operating costs, required capabilities, and testable risk reduction. Make every assumption visible.
At a glance
- Use your organization’s workload, incident, and recovery records as the baseline.
- Show operating savings separately from uncertain risk reduction and non-optional obligations.
- Fund a bounded improvement with measurable acceptance criteria, then revisit the case with observed results.
Name the decision the funding will change
A business case should let a leader make a specific decision: automate a certificate population, establish a product signing service, replace an unsupported device dependency, or constrain an agent’s access. “Improve digital trust” is too broad to budget or verify. Name the service, the owner, the affected users, and the failure you are trying to reduce.
Begin with the required outcome and realistic alternatives. Compare the current operating model, a focused internal improvement, a managed service, and a combination where appropriate. Include the cost of sustaining each option after implementation. An attractive acquisition price tells little about a capability that depends on unavailable staff or an integration nobody owns.
The framework below is my suggested way to structure that decision. It does not predict a return for your organization. Published vendor studies and composite companies can suggest questions, but their percentages are not measurements of your environment.
Collect a baseline people can challenge
Use an explicit observation period. Record ordinary work and exceptions, not just a memorable outage. If the record is incomplete, label the gap and give the estimate a range. Ask finance and service owners to agree on how labor, outage impact, and implementation time will be valued before comparing products.
| Input | Evidence to collect | Common error |
|---|---|---|
| Routine work | Volume of renewals, releases, reviews, or access requests; hands-on time by role. | Counting elapsed waiting time as labor. |
| Exceptions | Failed renewals, emergency releases, orphaned identities, and manual recovery work. | Counting the same incident in several cost categories. |
| Service impact | Duration, affected services, customer consequences, and documented business impact. | Applying an industry-average outage cost without a local basis. |
| Delivery cost | Integration, migration, testing, training, parallel operation, and exit work. | Treating implementation as only the license or cloud charge. |
| Ongoing cost | Operations, support, monitoring, retention, and vendor management. | Assuming automation eliminates accountability or staffing. |
| Required capability | Legal, contractual, safety, support, or customer requirements and their deadlines. | Treating an obligation as optional because estimated ROI is low. |
Keep three kinds of value distinct
First, estimate measurable operating improvement. Routine task volume multiplied by observed hands-on time gives a labor baseline. Apply a pilot-measured time reduction where available. Freed capacity is not automatically cash savings: say whether the benefit is redeployment, avoided hiring, or an actual budget reduction.
Second, describe uncertain risk reduction using a concrete scenario. An expired certificate that interrupts a customer service has a different loss pattern from a stolen signing key or an agent exporting private data. Document the assumed frequency and impact range, the controls that change them, and the residual exposure. Keep low, central, and high scenarios visible.
Third, list capabilities that must exist to meet an applicable requirement or maintain an essential service. The decision may be which compliant option to fund, not whether compliance produces a positive return. Keep these requirements visible even when their benefit cannot be responsibly converted to dollars.
NIST CSF 2.0 offers a common language for cybersecurity outcomes. NIST IR 8286 Revision 1 connects cybersecurity risk information with enterprise risk management. Use that structure to connect the decision to business objectives and the organization’s risk process.
Show the arithmetic and the assumptions
For a first comparison, use a common time horizon and one set of assumptions across the options. Show implementation costs in the period they occur and recurring costs in the periods they recur. Ask finance to supply the discount rate if a present-value comparison is needed.
- Operating benefit = baseline operating cost minus forecast operating cost for the same scope and period.
- Estimated risk-reduction benefit = baseline expected loss minus residual expected loss over the same period, using explicit frequency and impact assumptions. Keep this separate and label the uncertainty.
- Net benefit = included benefits minus implementation and recurring costs. Do not subtract a cost twice if it already appears in the operating baseline.
- ROI = net benefit divided by total investment cost, using consistent scope and timing. A zero or ambiguous denominator makes the ratio unhelpful.
- Payback occurs when cumulative supported benefits exceed cumulative costs. A model that never reaches that point should say so.
Buy evidence before buying the whole forecast
Choose a representative slice with enough difficulty to test the operating claim. Certificate renewal should include deployment and application verification. Signing should include authorization and emergency key replacement. Device identity should include a disconnected device and revocation. An agent-control pilot should include a denied action and containment.
Define success before the pilot. Record the time, failure modes, recovery results, integration work, and support effort. Ask the people who will operate the capability to sign off on the evidence. A successful demonstration by a supplier is useful, but it does not establish that your team can run the service.
Include provider independence in the decision: exportable inventories and evidence, documented interfaces, retrievable configuration, key-custody boundaries, and an executable transition plan. Estimate exit effort as part of the lifecycle cost, including contract terms and operational dependencies.
Make the approval a reviewable commitment
- Write a one-page decision record naming the outcome, scope, accountable owner, alternatives, cost range, and assumptions.
- Attach the baseline and pilot evidence. Mark the estimates that remain unproven and what would invalidate the case.
- Agree on the first funded increment, acceptance criteria, and a decision date for expansion.
- Review observed costs and outcomes after implementation. Explain differences from the forecast and adjust the next increment.
- Keep risk ownership and operating responsibility visible after the project team moves on.
Questions to take back to your team
- Which operating decision does this funding enable?
- What local records support the largest benefit?
- Are freed hours cash savings, capacity, or avoided future cost?
- What happens to the case if the largest uncertain benefit disappears?
- Who will verify the result and own the service after implementation?
Sources & further reading
- NIST Cybersecurity FrameworkA common structure for cybersecurity outcomes, governance, and organizational profiles.
- NIST IR 8286 Revision 1 — Cybersecurity and Enterprise Risk ManagementDecember 2025 revision. Connects cybersecurity risk information, risk registers, and enterprise objectives. The calculations and pilot suggestions above are an editorial decision framework.
A personal field guide. The checklists and operating frameworks are my recommendations; the linked authorities define their own requirements and scope. Review product and jurisdiction-specific obligations against the current source material.