What is a pentest change order?

A pentest change order is a written amendment to an active engagement that changes scope, schedule, price, or rules of engagement after the SOW is signed. It is the operational mechanism that lets a buyer add a new asset, extend the testing window, swap a target, or accept a higher day count without re-running the whole proposal cycle. Without a change order, mid-engagement requests either get done off the books (which destroys margin) or get refused (which damages the relationship). The change order is the cheap, structured way to say yes without giving the engagement away.

When should a change order be raised, not absorbed?

Raise a change order whenever the change adds work that was not in the signed SOW, materially shifts the risk allocation, or moves the dates outside the agreed window. The two failure modes are equal and opposite: absorbing every small request hollows out margin and trains the buyer to keep asking, while raising a change order for a five-minute clarification damages goodwill. The working line is that anything that adds more than half a tester-day of work, changes the asset list, or moves the testing window by more than two business days needs a change order. Smaller items get logged but absorbed.

How is change order pricing usually calculated?

Three pricing models are common. Day-rate add-on uses the same blended day rate as the original SOW multiplied by the additional tester-days; this is the simplest and the buyer-friendly default. Fixed-fee add-on prices the change as a small standalone scope with its own deliverable; this works when the change is genuinely separable, like adding a mobile app companion. Time-and-materials uses an hourly rate with a not-to-exceed cap; this works when the change has uncertain effort, like investigating a finding that opens up a new attack surface. Whichever model is used, the change order should make the rate, the assumed day count, and the not-to-exceed clear so there is no surprise on the invoice.

What goes inside a pentest change order?

Eight elements as a minimum. The engagement reference (SOW number, project code), the change description in plain language, the original scope being changed, the new scope after the change, the pricing model and amount, the impact on the testing window and final report date, any rules-of-engagement adjustments (new IPs, new credentials, new approvers), and the named approvers on both sides with the date. Anything less and the change is hard to defend at invoicing time. Anything more is usually a sign the change should have been a separate engagement.

Who has authority to approve a change order?

On the buyer side, the original SOW signer or the budget holder named in the SOW. On the provider side, the engagement lead with sign-off from the commercial owner. Sending a change order to the engineering contact who happens to be on the kickoff call almost always backfires; that contact does not own the budget and any verbal yes evaporates at invoicing. The pattern is to capture the operational request from whoever raised it during testing and then route the change order to the named approvers before any extra work starts.

Can the testing team start the new work before the change order is signed?

No. Starting the work before the change order is signed is the single most common way pentest consultancies write off mid-engagement effort. The pattern that fails is: the buyer asks live, the lead tester says yes informally, two days of effort go in, the change order goes to procurement, procurement pushes back on the rate, and the consultancy ends up either eating the days or fighting an awkward invoice. The defensible line is that any work outside the signed SOW waits for a written change order, even if the change order is just an email confirmation from the SOW signer with the price and the schedule impact.

How is a change order different from scope creep?

A change order is the documented, priced, and approved way the engagement formally absorbs new work. Scope creep is the undocumented, unpriced, and sometimes unapproved drift of work the buyer has come to expect at no extra cost. Change orders convert scope creep into scope change. The right metric is not the number of change orders raised; it is the share of mid-engagement requests that landed as priced change orders versus written-off effort. A consultancy with zero change orders on engagements that ran over scope is leaking margin in silence.

How should change orders interact with retest scope?

Retest scope is set at the debrief and locked into the final report. If new findings are added during testing that require a retest beyond the original retest window or asset list, the change order must extend the retest scope as well as the testing scope. The trap is changing only the testing window in the change order, then discovering at retest time that the buyer expects to retest assets that were never priced in the original retest budget. Make retest impact a required field on every change order template.

What records should the engagement carry after a change order?

The signed change order, the original SOW, the change-impact summary, the updated rules-of-engagement document, the updated asset list, the updated schedule, and the updated final-report deliverable list. All of these should sit on the engagement record alongside the kickoff record, the findings, and the debrief outcomes, so the change history is auditable and the invoicing record is defensible. Without this, the change order lives in three different inboxes and the next renewal cycle starts on a different commercial basis from the one signed.

How does SecPortal help manage change orders?

SecPortal stores the engagement record on a tenant-branded portal so the original SOW, the kickoff record, the asset list, the rules of engagement, the findings, the change orders, the debrief, and the final report all live on one record. Change orders attach to the engagement, update the priced day count visible to the team, and feed into invoicing so the invoice reflects the SOW plus the signed change orders rather than a manual reconciliation at month end. The branded client portal serves the same change history to the buyer, which removes the most common source of late-cycle commercial dispute.

← Back to Blog

Business7 May 202615 min read

Pentest Change Order Pricing: A Practical Playbook

Mid-engagement scope changes are the silent margin killer for pentest consultancies. The buyer asks for one more subdomain on day three. The CTO drops a new mobile app into the slack channel on day five. Engineering pushes a new feature into staging the night before the test wraps. Each request, treated informally, becomes either an awkward invoice conversation or unbilled effort that quietly hollows out the project margin. This guide covers the change order discipline that turns those requests from scope creep into priced scope change: the triggers that warrant a change order, the three common pricing models, a practical template, and the operational pattern that keeps the engagement record clean from kickoff to final invoice. For the upstream commercial discipline that prevents many change orders in the first place, see the pentest scope of work template and the pentest pricing guide.

Why Change Order Discipline Decides The Margin

Pentest engagements are sold on a fixed scope that maps to a fixed number of tester-days. The price is the day rate multiplied by the day count plus a small share for engagement management, reporting, and retest. Any work that lands inside the engagement window but outside the signed scope falls into one of two buckets: it is either absorbed silently, in which case the day rate effectively drops, or it is priced and approved as a change order, in which case the engagement remains profitable.

The compounding problem is that consultancies that absorb mid-engagement work train buyers to keep asking. The buyer who got a free subdomain in the last engagement asks for two free subdomains in the next one. The buyer who got a same-week schedule shift for free expects the same the following quarter. Three engagements later, the consultancy is delivering on a SOW that has nothing to do with the signed price.

Change orders solve this with a simple discipline: every scope, schedule, or rules-of-engagement change that exceeds a small written threshold gets priced and signed before any work begins. The threshold is a deliberate operational choice, not a default. Done well, change orders preserve goodwill (the buyer never feels nickel-and-dimed for a five-minute clarification) and preserve margin (real work always carries real price).

What Triggers A Pentest Change Order

The triggers fall into four categories. Setting these out in the SOW removes most of the argument when one of them fires mid-engagement.

Asset additions: new domain, new subdomain outside the wildcard scope, new mobile app, new API surface, new repository for code scanning, new cloud account, additional Active Directory forest, additional ICS zone.
Asset substitutions: the buyer swaps an in-scope asset for one that is materially different in size, complexity, or technology. A one-for-one swap of a similar internal app is usually absorbable; swapping a static brochure site for a SaaS platform with a customer login is not.
Schedule changes: testing window slips by more than two business days, retest window changes, debrief moves outside the original report-delivery deadline, blackout windows added that compress effective tester-days.
Rules-of-engagement changes: additional approvers required, new credential set added, new IP whitelisting workflow, social engineering opt-in or opt-out, additional reporting jurisdiction added.

For consultancies that run engagements under a formal rules of engagement template, every category-four trigger should automatically open a change order, even if the cost impact is zero, because the rules-of-engagement document itself needs to be re-signed.

The Absorb-Or-Raise Threshold

Not every mid-engagement request deserves a change order. The buyer asking for a quick check on a subdomain that was always implicitly in scope, a single extra screenshot in the report, or a fifteen-minute walkthrough on a finding does not need paperwork. The two failure modes are absorbing everything (margin destruction) and raising paperwork for everything (relationship destruction).

The working threshold most consultancies converge on is:

Half a tester-day or more of additional effort: change order.
Any change to the asset list of the SOW: change order.
Schedule shifts greater than two business days in either direction: change order.
Any rules-of-engagement change: change order, even if cost impact is zero.
Anything below half a day, with no asset list or rules-of-engagement impact: log it on the engagement record as absorbed effort.

Logging absorbed effort matters even when nothing is billed. Over a quarter, the absorbed-effort log is the evidence that informs the next SOW: if the same buyer absorbed three days of effort across two engagements, the next SOW either prices in a larger discretionary buffer or tightens the scope language.

Three Pentest Change Order Pricing Models

The pricing model is the part of the change order most likely to get pushed back on by buyer procurement. The three common patterns each work in different situations.

Model	When to use	Calculation
Day-rate add-on	Most asset additions, most schedule extensions, most rules-of-engagement changes that add tester time.	Same blended day rate as the original SOW, multiplied by the additional tester-days, with reporting overhead added.
Fixed-fee add-on	When the change is separable enough to be a small standalone deliverable (mobile app companion, dedicated infrastructure review, additional report appendix).	Standalone fixed price with its own scope, deliverable, and acceptance criteria. Reads like a mini-SOW inside the change order.
Time and materials	When effort is genuinely uncertain (investigating a finding that opens a new attack surface, exploring an undocumented system).	Hourly rate with a not-to-exceed cap. Cap should never exceed the equivalent of two tester-days without a second approval.

The day-rate add-on is the buyer-friendly default. It uses the same rate the buyer already accepted in the original SOW, which removes most of the procurement friction. Fixed-fee add-ons are cleaner from an accounting perspective but tend to attract scope-deflation pressure during negotiation. Time-and-materials needs disciplined tracking; without a time log on the engagement record, the invoice is hard to defend.

Sample Pentest Change Order Template

The template below covers the eight required elements. It fits on one page, which is deliberate: a one-page change order gets signed; a five-page change order goes to legal and gets signed three weeks later (often after the work has already been done).

Change Order # <number> to SOW <reference>

Engagement: <client name, project code, engagement window>

Description: One paragraph in plain language describing what the buyer is asking to change and why.

Original scope (relevant section): Quote the exact clause or asset list from the SOW that is being changed.

Revised scope: The new clause or asset list that supersedes the original. Reference the engagement record where the updated asset list is held.

Pricing: Pricing model (day-rate add-on, fixed-fee add-on, or time and materials), the rate, the assumed tester-days or hours, the not-to-exceed amount, and the total change-order amount.

Schedule impact: Revised testing window, revised draft-report date, revised final-report date, revised retest window, any blackout periods.

Rules-of-engagement impact: Any change to the approvers, IP allowlists, credential set, or out-of-scope assets. Reference the updated rules-of-engagement document.

Retest impact: Whether the new scope is included in the existing retest budget or requires additional retest tester-days, with the additional cost stated separately if applicable.

Approvers: Buyer SOW signer or named budget holder, provider engagement lead and commercial owner, with date.

Keep the change order on the engagement record. The closest parallel is the kickoff record at the start of the engagement: a single, durable artefact that anchors every subsequent decision. For the kickoff bookend, see the pentest kickoff meeting agenda. For the longer-form, twelve-section variant that varies the engagement letter itself (rather than only the commercial scope) and is preferred under regulated schemes like CHECK, CREST OVS, CREST STAR, FedRAMP, and DORA TLPT, see the pentest scope change addendum template.

Five Common Scenarios And How To Price Them

Concrete scenarios make the discipline easier to apply in the moment. The numbers below assume a single tester at a working blended day rate; substitute the actual rate from the engagement.

Scenario 1: Buyer adds two subdomains on day three. The original SOW listed three subdomains. The two additions are similar in size to the originals. Price as a day-rate add-on for one tester-day plus reporting overhead. Schedule impact is one extra business day on the testing window, which usually means the draft report slips by one day. Approve, sign, then test.
Scenario 2: Buyer adds a mobile companion app. The mobile app is genuinely separable from the web scope. Price as a fixed-fee add-on with its own three-day scope, its own reporting deliverable, and its own retest budget. The change order reads like a mini-SOW. The original engagement timeline can continue in parallel.
Scenario 3: Buyer wants to investigate a finding that uncovered an undocumented internal API. The effort is uncertain and depends on what the API exposes. Price as time and materials with a two-day not-to-exceed cap, and require an approval before the cap is increased. Log time daily on the engagement record.
Scenario 4: Buyer slips testing window by a week because of a production freeze. No new scope, no extra tester-days, but the tester reservation needs reslotting. The change order may have zero cost impact if the calendar accommodates, or carry a rebooking fee if the slot resale is at risk. State the rebooking policy in the original SOW so the conversation is short.
Scenario 5: Buyer adds a new compliance reporting requirement (for example, SOC 2 mapping) on day four. The technical testing is unchanged but the reporting deliverable expands. Price as a fixed-fee add-on for the additional reporting effort. Reference the relevant framework page (SOC 2, PCI DSS, or ISO 27001) in the change order so the buyer sees the explicit mapping work being added.

Common Pentest Change Order Mistakes

Starting work on a verbal yes: the lead tester hears the buyer say yes on the slack call and starts testing. Two days later procurement pushes back on the rate. Eat the days or fight an awkward invoice. Always wait for the signed change order, even if the signature is just an email confirmation from the SOW signer.
Routing the change order to the wrong contact: the engineering lead on the kickoff call is rarely the budget holder. A verbal yes from the wrong contact does not survive procurement review. Capture the operational request from whoever raised it, then route the paperwork to the named approvers.
Pricing the change at a different day rate: quoting a higher day rate on the change order than on the original SOW is the fastest way to make procurement reject the document. Use the same blended day rate the buyer already accepted unless the change involves materially different skill sets.
Forgetting the retest impact: the change order extends the testing scope but never the retest scope. Retest day comes, the buyer expects the new assets included, and the consultancy delivers retest work for free. Make retest impact a required field on the template.
Not updating the rules of engagement: the change adds new IPs or new credentials, but the original rules-of-engagement document is never re-signed. If anything goes wrong (an outage, an alert in the buyer SOC, a finding outside the originally approved attack surface), the engagement is exposed. Update and re-sign even when the cost impact is zero.
Treating absorbed effort as invisible: small requests get absorbed silently, never logged, and the consultancy has no record at renewal time of how much free work was given. Log absorbed effort on the engagement record. Roll it up at renewal.
Long change orders: a five-page change order gets routed to legal and signed three weeks later. By that time the work has either been done off the books or the buyer has moved on. Keep change orders to one page; the SOW carries the long-form terms.
No version trail: change orders sit in three different inboxes. By final invoice the engagement has no clean record of which version of the asset list, schedule, or rules of engagement applies. Keep a single source of truth on the engagement record so the invoice can be reconciled directly.

Three SOW Clauses That Reduce Change Order Friction

Most change order disputes come from gaps in the original SOW, not from the change itself. The three clauses below, added upfront, make the change order conversation short.

Change order procedure clause: states explicitly that any change to scope, schedule, or rules of engagement requires a written change order signed by the named approvers before work begins. Names the day-rate add-on as the default pricing model. References the change order template by exhibit number.
Absorb-or-raise threshold clause: states the specific threshold (half a tester-day, no asset list change, no rules-of-engagement change) below which a request is absorbed and logged rather than priced. Removes the implicit expectation that any small ask is free.
Rebooking and schedule-shift clause: states the policy when the buyer requests a window shift, including the notice period that triggers a rebooking fee and the rate at which rebooking is priced. This is the most valuable clause to standardise across all SOWs because schedule shifts are the single most common change order trigger.

For the broader SOW structure these clauses sit inside, see the pentest statement of work template or the long-form SOW guide.

The Operational Pattern That Keeps Change Orders Clean

Change orders fail operationally more often than commercially. The mechanics that keep them working are simple but easy to skip under delivery pressure.

Capture the request the moment it lands. Slack message, email, kickoff call note: log it on the engagement record with a timestamp.
Apply the threshold rule. Above threshold, open a change order. Below threshold, log as absorbed effort.
Draft the change order using the template. One page. Eight required elements.
Route to the named approvers, not the operational contact. Reference the SOW signer.
Confirm receipt and price. If procurement pushes back, hold the testing line. Do not start the new work.
Capture the signature. An email confirmation from the SOW signer is enough if it covers the price, the schedule impact, and the scope.
Update the engagement record: revised asset list, revised rules of engagement, revised schedule, change order document attached.
Update the invoice schedule. The change order amount feeds into the invoicing cadence so the final invoice reflects SOW plus signed change orders.
At engagement closure, audit the change order log against the absorbed-effort log. The ratio informs the next SOW pricing.

Pentest Change Order Quick Checklist

SOW carries change order procedure, threshold, and rebooking clauses
Change order template stored at one page with eight required elements
Named approvers identified on both sides at engagement kickoff
Threshold for absorb-or-raise documented and shared with the testing team
Live request logged on the engagement record with timestamp
Pricing model selected (day-rate add-on, fixed-fee add-on, or time and materials)
Retest impact captured even when zero
Rules-of-engagement impact captured even when zero
Change order routed to the named approvers, not the operational contact
Work paused until written approval received
Engagement record updated with revised asset list, schedule, and rules
Invoice schedule updated to reflect change order amount
Absorbed-effort log maintained alongside change order log

From Mid-Engagement Request To Defended Invoice On A Single Record

The change order is one phase of an engagement record that also covers scope, kickoff, findings, debrief, retest, and final invoicing. Keeping the change orders inside the engagement record (rather than as PDFs in three different inboxes) means the SOW, the change history, the asset list, the rules of engagement, the findings, and the invoice all live on one record and reference one source of truth.

SecPortal links the change order to the live engagement on a tenant-branded portal: engagement management stores scope and dates, findings management stores findings against the latest signed asset list, invoicing reflects SOW plus signed change orders, and the branded client portal serves the change history to the buyer so the commercial picture stays aligned. The operational complement on the delivery side lives in pentest project management and the commercial parent layer is documented in pentest retainer management. For the research view of why these requests appear in the first place, see pentest scope creep.

Frequently Asked Questions About Pentest Change Orders

Run change orders on the same engagement record as the SOW and the invoice

SecPortal stores the SOW, kickoff, asset list, rules of engagement, findings, change orders, debrief, and invoicing on a single engagement record so the change history is auditable and the invoice is defensible. See pricing or start free.

Get Started Free