The comparison is only as useful as its basis. Pick a consistent unit — normally tester-days — and decide whether reporting, retest and coordination are included in both the quoted and actual figure. A mixture of “test time only” on one engagement and “all delivery time” on another will create a pattern that is not really there.
Minimum closeout record
- Assessment type and a generalized complexity category.
- Quoted tester-days and actual tester-days on the same basis.
- Reporting and retest days, when they are tracked separately.
- Whether scope changed after approval and how that change was handled commercially.
- Price, loaded day cost and explicitly unbilled days only when the firm is comfortable recording them.
Use anonymous engagement references. You do not need client names, vulnerability details, credentials, targets or raw security artifacts to learn from estimation history.
Keep four quantities separate
Teams often use “overrun” as shorthand for several different things. Separating them keeps a delivery review fair to both the estimator and the delivery team.
1. Estimation variance
Actual tester-days minus the approved tester-days. It describes the delivery difference; it does not tell you why.
2. Scope change
Work added, removed or materially changed after approval. Keep it visible even when it is commercialized, because it should not silently rewrite the original estimate.
3. Unbilled effort
Extra delivery work the firm confirms it did not recover through an approved change, separate retest agreement or another charge. It is a commercial classification, not an automatic result of variance.
4. Margin impact
A financial calculation that needs a reliable price and cost basis. When either is missing, report the effort pattern and label the financial impact unknown.
A review method that avoids false precision
- Group comparable work. Start with one assessment type and a small number of complexity variables you can actually observe, such as authenticated roles, tenant boundaries, API surface, reporting or retest terms.
- Set a tolerance before reading the results. Small differences can be normal recording variation. State the tolerance your firm treats as material; do not adjust it after seeing a favorite result.
- Inspect every outlier. Ask whether the scope changed, data was incomplete, actuals were recorded on a different basis, or the original assumption was genuinely too low.
- Show sample size beside every pattern. “Three of four multi-role SaaS applications exceeded estimate” is useful but not equivalent to a stable firm-wide rule.
- Change one assumption at a time. Update a reporting allowance, retest allowance or a named scope trigger; then watch the next comparable work. Do not claim machine learning from a small history.
Worked example
This fictional engagement has an approved quote for 10 tester-days at $16,000. The firm records a loaded tester-day cost of $800. Delivery took 12 days and no approved scope change or separately billed retest explains the extra two days.
Fictional arithmetic
The calculation is clear; the conclusion stays qualified.
Estimation variance = 12 actual days − 10 quoted days = +2 days
Percentage estimation error = +2 ÷ 10 = +20%
Quoted delivery cost = 10 × $800 = $8,000
Actual delivery cost = 12 × $800 = $9,600
Cost overrun = $1,600
Quoted gross margin = ($16,000 − $8,000) ÷ $16,000 = 50%
Actual gross margin = ($16,000 − $9,600) ÷ $16,000 = 40%The $1,600 is a cost overrun under the stated assumptions. It is not automatically lost revenue and it does not prove the quote was wrong: confirm the approved scope, billing treatment and cost basis first. A single engagement should trigger a review, not a coefficient change.
Turn patterns into better quotes
Look for an adjustment you can describe in a sentence. Good changes are observable and reviewable: “Reserve a named retest allowance when retest is included,” or “Require an explicit authorization review for multi-role tenant administration.”
Before changing your estimate model
Preserve the original recommendation, the approved quote, actual-effort basis and reason for any manual adjustment. Then test a proposed change against subsequent, comparable work. If the history is sparse or contradictory, retain a wider range and a senior-review prompt instead of inventing precision.
If you want a quick first pass, ScopeMargin's free browser audit calculates the descriptive comparisons locally from a sanitized CSV. Its report distinguishes confirmed unbilled days from assumptions and displays sample-size limitations.
Sources and limits
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment frames assessment planning around scope, assumptions, limitations, resources and deliverables. Accessed 27 September 2026.
- OWASP Web Security Testing Guide is a source for web-application test domains; it does not prescribe commercial tester-day estimates. Accessed 27 September 2026.
This guide provides a method for internal learning, not a market-rate benchmark or a promise of margin improvement. A small or inconsistent sample can reveal questions to investigate, but cannot establish a statistically stable rule.