How Effort Is Calculated
The Effort value in your Top Actions list estimates the time to remediate a finding. Mondoo shows two numbers side by side so you can see the work involved manually and the time saved by automation.
The two models
Mondoo Automated Effort
The hands-on time when you use Mondoo's automated remediation. The formula is 10 minutes fixed, plus 5 minutes per 100 affected assets to launch and monitor the rollout.
| Assets | Mondoo Automated Effort |
|---|---|
| 100 assets | 15 minutes |
| 400 assets | 30 minutes |
| 1,000 assets | 60 minutes |
Industry Standard Effort
A benchmark for the full manual remediation lifecycle, modeled on NIST and SANS frameworks. Effort scales with both the number of affected assets and the threat type. A zero-day is significantly more work than a routine patch.
| Assets | Standard CVE | Zero-day |
|---|---|---|
| 1–10 | 7.5 hours | 22.5 hours |
| 11–100 | 10.5 hours | 31.5 hours |
| 101–1,000 | 21 hours | 63 hours |
| 1,001+ | 36 hours | 108 hours |
The X FASTER label
The Top Actions list combines both numbers as 30m 21X FASTER. The multiplier is:
X FASTER = Industry Standard Effort ÷ Mondoo Automated Effort
A higher multiplier means more time saved. Use it to prioritize findings where automation delivers the most value over manual work.
The manual effort estimate reflects the hands-on-keyboard time for a security or IT engineer to remediate a single, prioritized vulnerability in a modern IT environment with standard tools (patch deployment utilities, vulnerability scanners). The model is built on industry frameworks from the National Institute of Standards and Technology (NIST) and the SANS Institute.
The four-phase remediation framework
Our model breaks the manual remediation process into four phases, a practical application of the lifecycle defined in NIST Special Publication 800-40 Rev. 4, "Guide to Enterprise Patch Management Planning" [1]:
-
Research and Planning. Investigate the vulnerability, read vendor advisories, identify affected assets and software versions, and determine the technical steps for remediation. Aligns with the "Identification" and "Assessment" phases of NIST and the "Analyze" focus area of the SANS Vulnerability Management Maturity Model [2].
-
Scripting and Testing. Create or adapt a deployment script (PowerShell, Ansible playbook, etc.), set up a representative lab, apply the patch, and validate the fix doesn't cause instability. Testing is a critical best practice in numerous security frameworks [3].
-
Staged Rollout. Manage and oversee the deployment using an existing patch utility: configure jobs, define target groups, promote the patch from pilot to broader rings, monitor for failures, and troubleshoot the percentage of endpoints where automation fails.
-
Verification. Confirm the patch was successfully deployed and the vulnerability is no longer present. Includes initiating post-remediation scans, reviewing the output, and closing the work ticket. Aligns with the "Verification" phase in NIST SP 800-40.
Detailed Time Estimation Model
Time estimates account for two real-world variables: the threat type of the vulnerability and the scale of the deployment.
Phase 1: Research and Planning
- Activities. An engineer reads the vulnerability disclosure, understands vendor-specific advisories, identifies which assets and software versions are affected, and determines the technical steps for remediation. This aligns with the "Analyze" phase of the SANS Vulnerability Management Maturity Model [2].
- Time. A high-skill, fixed-cost activity. We allocate a baseline of 2 hours, a conservative estimate derived from industry data suggesting an average of 6 hours of total engineering cost to fix a single vulnerability [4]. Time increases slightly at higher asset tiers to account for analyzing impacts in more diverse environments [5].
Phase 2: Scripting and Testing
- Activities. Create or adapt a script to deploy the patch, set up a representative test environment, apply the patch, and run functional tests. A dedicated testing environment is a common time sink [6].
- Time. A front-loaded, fixed-cost activity. We allocate a baseline of 4 hours, the remaining two-thirds of the 6-hour engineering benchmark [4]. Time increases modestly at higher tiers to account for testing against more configurations [5].
Phase 3: Staged Rollout
- Activities. An engineer manages the automated deployment: configures the patch utility, defines deployment rings, monitors progress, and manually intervenes when automation fails.
- Time. The primary phase where effort scales with asset count. Patching the first few assets is relatively quick (1 hour); the effort grows significantly as the rollout covers dozens (4 hours) or hundreds (12 hours) of assets, reflecting the coordination across teams and environments.
Phase 4: Verification
- Activities. Initiate a verification scan with an existing tool, review the report, and close the ticket.
- Time. Scanning is automated, so manual effort is minimal. Baseline: 0.5 hours. Increases slightly at higher tiers to account for larger scan reports, as prescribed by the "Verification" stage in NIST SP 800-40.
Calculation Summary
Threat type modifier
- Non-Zero-Day (1.0x baseline). The vast majority of known vulnerabilities with available patches.
- Zero-Day (3.0x multiplier). A novel, actively exploited vulnerability requiring an emergency response. The chaotic, multi-patch response to the Log4j vulnerability (CVE-2021-44228) is a quintessential example [7][8].
Manual Effort Calculation Table (Non-Zero-Day Baseline)
| Phase | Tier 1 (1–10) | Tier 2 (11–100) | Tier 3 (101–1,000) | Tier 4 (1,001+) | Rationale |
|---|---|---|---|---|---|
| Research & Planning | 2 hours | 2 hours | 3 hours | 4 hours | High fixed cost for initial analysis. Scales modestly with environment complexity (NIST, SANS). |
| Scripting & Testing | 4 hours | 4 hours | 5 hours | 6 hours | High fixed cost for core engineering. Scales modestly to cover a wider variety of configurations [3]. |
| Staged Rollout | 1 hour | 4 hours | 12 hours | 24 hours | Primary driver of scaling. Hands-on time to manage the automated tool across larger, more diverse asset groups [5]. |
| Verification | 0.5 hours | 0.5 hours | 1 hour | 2 hours | Minimal manual effort to initiate automated validation scans and review output, retaining the final manual check required by NIST. |
| Total (Non-Zero-Day) | 7.5 hours | 10.5 hours | 21 hours | 36 hours | Apply Threat Type Multiplier: Zero-Day (3.0x) |
Works Cited
- What Is Vulnerability Management Lifecycle? Picus Security, accessed July 24, 2025.
https://www.picussecurity.com/resource/glossary/what-is-vulnerability-management-lifecycle - Using the SANS Vulnerability Management Maturity Model. RH-ISAC, accessed July 24, 2025.
https://rhisac.org/vulnerability-management/sans-maturity-model-process/ - What is Vulnerability Remediation? Practices & Process. Jamf, accessed July 24, 2025.
https://www.jamf.com/blog/vulnerability-remediation-why-its-security-relies-on-it/ - Security Remediation Budgeting: A Simple Guide. Opus Security, accessed July 24, 2025.
https://www.opus.security/blog/guide-security-remediation-budgeting - Why it Takes so Long to Patch a Vulnerability. JetPatch, accessed July 24, 2025.
https://jetpatch.com/blog/patch-management/why-it-takes-so-long-to-patch-a-vulnerability-and-how-you-can-speed-the-process/ - Vulnerability Remediation: How To Automate Your Process. PurpleSec, accessed July 24, 2025.
https://purplesec.us/learn/vulnerability-remediation/ - Unraveling Log4Shell: Analyzing the Impact and Response to the Log4j Vulnerability. arXiv, accessed July 24, 2025.
https://arxiv.org/html/2501.17760v1 - What is the Log4j Vulnerability? IBM, accessed July 24, 2025.
https://www.ibm.com/think/topics/log4j