Penetration Testing Scope Change Addendum Template vary an in-flight engagement without breaking the authorisation chain
A free, copy-ready penetration testing scope change addendum template. Twelve structured sections covering header and addendum references, parties, change trigger, asset delta and depth changes, authentication and credential references, schedule impact, commercial impact, risk and stop-test conditions, retest scope impact, named team and scheme reference changes, third-party permissions for added assets, and a fresh authorisation statement and signatures. Stacks on top of the executed engagement letter, statement of work, and rules of engagement; it does not replace them. Aligned with PTES, NIST SP 800-115, and the CREST Defensible Penetration Test specification.
Run scope changes on the same record as the original authorisation
SecPortal stores every signed addendum alongside the engagement letter, SOW, ROE, findings, draft and final reports, and retest evidence. One audit trail from initial authorisation through every scope change to closure. Free plan available.
The addendum opens with its own reference, the engagement reference it varies, and the documents it inherits from. It does not replace the original engagement letter; it stacks on top of it. PTES Section 1, NIST SP 800-115 planning guidance, and the CREST Defensible Penetration Test specification all assume the authorisation chain remains traceable across in-flight scope changes.
PENETRATION TESTING SCOPE CHANGE ADDENDUM
Addendum reference: {{ADDENDUM_REFERENCE}}
Addendum date: {{ADDENDUM_DATE}}
Addendum sequence: Addendum {{N}} of {{TOTAL_ADDENDA_PLANNED_OR_ESTIMATED}} for this engagement
This addendum varies the penetration testing engagement defined under:
- Engagement letter reference: {{ENGAGEMENT_LETTER_REFERENCE}}, executed {{ENGAGEMENT_LETTER_DATE}}
- Statement of Work reference: {{SOW_REFERENCE}}, executed {{SOW_DATE}}
- Rules of Engagement reference: {{ROE_REFERENCE}}, executed {{ROE_DATE}}
- Master Services Agreement (where applicable): {{MSA_REFERENCE}}, executed {{MSA_DATE}}
Where any term of this addendum conflicts with the underlying executed documents, those documents govern except for the specific deltas captured below, which take effect on the latest signature date of this addendum. All other terms of the engagement letter, SOW, and ROE remain in force unchanged.
2. Parties
Names the same Authorising Party and Testing Party as the original engagement letter, or the substitute representative on either side with the same delegated authority over the affected assets.
Authorising Party (the Client):
- Legal entity: {{CLIENT_LEGAL_NAME}}
- Authorising representative for this addendum: {{CLIENT_AUTHORISING_NAME}}, {{CLIENT_AUTHORISING_TITLE}}
- Email: {{CLIENT_AUTHORISING_EMAIL}}
- Phone: {{CLIENT_AUTHORISING_PHONE}}
- Authority basis: {{SAME_AS_ENGAGEMENT_LETTER_OR_DELEGATION_REFERENCE}}
Testing Party (the Vendor):
- Legal entity: {{TESTING_FIRM_LEGAL_NAME}}
- Engagement lead for this addendum: {{ENGAGEMENT_LEAD_NAME}}, {{ENGAGEMENT_LEAD_TITLE}}
- Email: {{ENGAGEMENT_LEAD_EMAIL}}
- Phone: {{ENGAGEMENT_LEAD_PHONE}}
- Commercial owner sign-off (where addendum changes fees): {{COMMERCIAL_OWNER_NAME}}, {{COMMERCIAL_OWNER_TITLE}}
3. Change trigger
Records what caused the scope change, in one sentence. Triggers that age well include client request with a specific business reason, mid-engagement discovery of an asset that was always in scope but missed during inventory, regulatory or scheme guidance that changed during the engagement, or a stop-test event that requires re-scoping. "We thought we should test more" ages badly.
Trigger for this scope change (select one and complete):
- [ ] Client-initiated request: {{REASON_AND_REQUESTING_INDIVIDUAL}}
- [ ] Mid-engagement discovery during testing: {{ASSET_OR_FINDING_THAT_PROMPTED_THE_CHANGE}}
- [ ] Regulatory or scheme event: {{REGULATOR_OR_SCHEME_AND_REFERENCE}}
- [ ] Stop-test or incident-driven re-scope: {{INCIDENT_REFERENCE_AND_STOP_TEST_LOG}}
- [ ] Other (must be explicit): {{OTHER_TRIGGER_DESCRIPTION}}
Date the change was first raised: {{TRIGGER_DATE}}
Channel the change was first raised on: {{CHANNEL_EMAIL_CALL_WORKSPACE_NOTE}}
Activity log reference (where logged in the engagement workspace): {{ACTIVITY_LOG_REFERENCE}}
4. Asset delta and scope change
The substantive change to the asset list. Captures additions, removals, and depth changes by canonical identifier. Vague descriptions like "marketing infrastructure" do not survive audit; explicit identifiers like "www.example.com and the IP range 192.0.2.0/24" do.
Assets ADDED to scope under this addendum:
1. Asset: {{ADDED_ASSET_1_CANONICAL_IDENTIFIER}}
Asset class: {{WEB_API_NETWORK_CLOUD_MOBILE_SOURCE_CODE}}
Authentication state: {{NONE_ROLE_SCOPED_FULL_ADMIN_WITH_CREDENTIAL_REFERENCE}}
Test depth: {{PASSIVE_POLITE_AGGRESSIVE_OR_LEVEL_1_2_3}}
Methodology references: {{PTES_NIST_OWASP_WSTG_OWASP_MASTG_OWASP_ASVS_CREST}}
2. Asset: {{ADDED_ASSET_2_CANONICAL_IDENTIFIER}}
... (repeat as needed)
Assets REMOVED from scope under this addendum:
1. Asset: {{REMOVED_ASSET_1_CANONICAL_IDENTIFIER}}
Reason for removal: {{REASON}}
Compensating coverage (if any): {{ALTERNATIVE_COVERAGE_OR_RISK_ACCEPTANCE_REFERENCE}}
2. Asset: {{REMOVED_ASSET_2_CANONICAL_IDENTIFIER}}
... (repeat as needed)
Depth or methodology changes on EXISTING in-scope assets:
1. Asset: {{EXISTING_ASSET_CANONICAL_IDENTIFIER}}
Original depth and methodology: {{ORIGINAL_VALUES}}
Revised depth and methodology: {{REVISED_VALUES}}
Reason: {{REASON}}
2. ... (repeat as needed)
Out-of-scope confirmation: all other inclusions and exclusions in the original engagement letter, SOW, and ROE remain unchanged.
5. Authentication state and credential references
Authenticated DAST scope for newly added assets needs explicit named roles, credential references (not the secrets themselves), and the destructive operations that remain prohibited. Lift this section verbatim from the ROE pattern for the affected assets so the addendum stays consistent with the operating manual.
Authentication state for newly added assets requiring authentication:
1. Asset: {{ADDED_ASSET_REQUIRING_AUTH}}
Roles authorised: {{ROLE_LIST}}
Credential references: {{CREDENTIAL_REFERENCE_NOT_SECRETS}}
Destructive operations expressly prohibited: {{LIST_DELETE_TRANSFER_PAYMENT_BULK_ACCOUNT_CREATION_ETC}}
Test account naming: {{NAMED_TEST_ACCOUNTS}}
Cleanup commitments: {{CLEANUP_AT_END_OF_TESTING_WINDOW}}
Where credential rotation is required as a result of this addendum (for example new test accounts provisioned for the new assets), the rotation schedule and responsibility live here:
Rotation owner: {{NAMED_INDIVIDUAL_ON_CLIENT_OR_TESTING_PARTY_SIDE}}
Rotation completion date: {{DATE_BEFORE_OR_AT_END_OF_TESTING_WINDOW}}
Rotation evidence reference: {{ACTIVITY_LOG_OR_TICKET_REFERENCE}}
6. Schedule impact
Captures any change to the testing window, off-hours testing window, or blackout periods. The original engagement letter authorised a specific window; this section records the new window or confirms the original window still applies. Outside the window, this addendum (like the original letter) does not authorise any testing activity.
Schedule impact on the active engagement:
- Original primary testing window: {{ORIGINAL_START}} to {{ORIGINAL_END}} ({{TIMEZONE}})
- Revised primary testing window: {{REVISED_START}} to {{REVISED_END}} ({{TIMEZONE}})
- Original off-hours window for high-impact tests: {{ORIGINAL_OFF_HOURS}}
- Revised off-hours window: {{REVISED_OFF_HOURS}}
- Original blackout periods: {{ORIGINAL_BLACKOUT}}
- Revised blackout periods: {{REVISED_BLACKOUT}}
If the schedule is unchanged, this section reads: "Schedule unchanged. The testing window in the original engagement letter remains in effect for the assets added by this addendum."
Outside the (revised) window, this addendum does not authorise any testing activity. Retests are governed by Section 9 of this addendum or by the retest clause in the SOW.
7. Commercial impact
Records the price change, even when the change is zero-fee. Zero-fee changes get explicit acknowledgement so the buyer cannot later claim they expected a credit and the consultancy cannot later claim they expected a payment. Day-rate, fixed-fee, and time-and-materials models all work; the addendum just needs to make clear which one applies.
Commercial impact of the scope change (select one and complete):
- [ ] Day-rate add-on: {{ADDITIONAL_TESTER_DAYS}} days at the SOW blended day rate of {{DAY_RATE}} {{CURRENCY}} = {{TOTAL_ADDITIONAL_FEE}} {{CURRENCY}}.
- [ ] Fixed-fee add-on: {{FIXED_FEE_AMOUNT}} {{CURRENCY}} for the work described in Section 4.
- [ ] Time-and-materials with not-to-exceed cap: {{HOURLY_RATE}} {{CURRENCY}} per hour, not to exceed {{CAP_AMOUNT}} {{CURRENCY}}.
- [ ] Zero-fee scope change. Both parties acknowledge no fee adjustment despite the scope change. Reason: {{ZERO_FEE_REASON}}.
Invoicing reference: invoice will be raised against {{ENGAGEMENT_REFERENCE}} on the original payment terms unless varied here.
Payment terms variation (if any): {{VARIATION}}
Purchase order reference (if required): {{PO_REFERENCE}}
8. Risk impact and stop-test conditions
New assets bring new attack surface and may introduce new stop-test conditions. This section records any risk profile change, any new stop-test trigger, and any change to the production-impact monitoring agreed in the ROE.
Risk impact assessment of the added assets:
- New attack surface introduced: {{DESCRIPTION_OF_SURFACE_FOR_EACH_ADDED_ASSET}}
- Production-impact monitoring required: {{YES_OR_NO_AND_OWNER}}
- New stop-test triggers introduced (in addition to those in ROE Section 9): {{NEW_TRIGGERS}}
- Existing stop-test triggers that now apply to additional assets: {{LIST}}
Where the addendum changes the risk profile materially (introducing production credentials, regulated data, or critical business processes), the named stop-test contact and the 24/7 verification phone in the engagement letter must be confirmed as still current. Confirmation:
- Stop-test contact still current: {{YES_NO_AND_REVISED_CONTACT_IF_CHANGED}}
- 24/7 verification phone still current: {{YES_NO_AND_REVISED_PHONE_IF_CHANGED}}
9. Retest scope impact
Most missed scope changes show up at retest time, when the client expects retest of newly added assets that were never priced into the retest budget. This section makes the retest delta explicit so the retest engagement does not become a second negotiation.
Retest scope impact of the added assets:
- Original retest window: {{ORIGINAL_RETEST_WINDOW}}
- Revised retest window (if changed): {{REVISED_RETEST_WINDOW}}
- Original retest count per finding: {{ORIGINAL_RETEST_COUNT}}
- Revised retest count for findings on added assets: {{REVISED_COUNT_OR_SAME_AS_ORIGINAL}}
- Retest fee impact: {{ADDITIONAL_RETEST_FEE_OR_ZERO_FEE_ACKNOWLEDGEMENT}}
- Retest acceptance criteria for added assets: {{CRITERIA_OR_DEFAULT_TO_ORIGINAL_ENGAGEMENT_LETTER_TERMS}}
- Retest verification method: {{MANUAL_VERIFICATION_AUTOMATED_RETEST_HYBRID}}
If retest scope is unchanged, this section reads: "Retest scope unchanged. The retest provisions of the original engagement letter and SOW apply equally to findings on the assets added by this addendum, at no additional fee."
10. Named team and scheme reference changes
Where the addendum substitutes or adds testers, or where it brings new scheme requirements into play, the changes must be recorded explicitly so scheme reviewers and auditors can verify the authorisation chain. Substitutions affecting accredited roles always need fresh acknowledgement.
Named engagement team changes under this addendum:
- Tester(s) added: {{NAME_ROLE_ACCREDITATIONS}}
- Tester(s) substituted: {{REPLACED_NAME_REPLACED_BY_NAME_ROLE_ACCREDITATIONS}}
- Tester(s) removed: {{NAME_AND_EFFECTIVE_DATE}}
Scheme reference changes under this addendum:
- Scheme(s) newly applicable to the added assets: {{CHECK_CREST_OVS_STAR_FEDRAMP_DORA_TLPT_OTHER}}
- Scheme(s) newly out of scope as a result of removed assets: {{LIST}}
- Scheme accreditation evidence references for new testers (where required): {{EVIDENCE_REFERENCE}}
Where the addendum substitutes a scheme-accredited tester (CHECK Team Member, CREST Registered Tester, OVS, STAR, FedRAMP penetration tester, DORA TLPT Threat Intelligence Provider or Red Team Provider), the new tester may not operate under the engagement until the Authorising Party has acknowledged this addendum in writing.
11. Third-party permissions for added assets
Where any newly added asset is hosted, processed, or operated by a third party (cloud provider, managed hosting, SaaS dependency, partner-operated infrastructure), the addendum records the permission reference. This is the clause that prevents authorised testing of an added asset the client does not fully own from becoming unauthorised testing of someone else system.
Third-party permissions referenced for newly added assets:
1. Third party: {{THIRD_PARTY_1_NAME}}
Asset(s) covered: {{THIRD_PARTY_1_ASSETS}}
Permission reference: {{THIRD_PARTY_1_PERMISSION_REF}}, dated {{THIRD_PARTY_1_PERMISSION_DATE}}
Permission expiry (where applicable): {{THIRD_PARTY_1_PERMISSION_EXPIRY}}
2. Third party: {{THIRD_PARTY_2_NAME}}
Asset(s) covered: {{THIRD_PARTY_2_ASSETS}}
Permission reference: {{THIRD_PARTY_2_PERMISSION_REF}}, dated {{THIRD_PARTY_2_PERMISSION_DATE}}
Permission expiry (where applicable): {{THIRD_PARTY_2_PERMISSION_EXPIRY}}
If no newly added asset is hosted or operated by a third party, this section reads: "Not applicable. All assets added by this addendum are owned and operated by the Authorising Party."
12. Fresh authorisation statement and signatures
The closing block converts the addendum into an executed variation. The substantive authorisation statement is restated for the new (or varied) scope so an auditor or scheme reviewer can find it without parsing the surrounding text, then both sides sign.
The Authorising Party authorises the Testing Party, through its named engagement lead and the engagement team identified in Section 10 (as varied), to perform the activities defined in the SOW and ROE against the assets in Section 4 (as varied), during the window in Section 6 (as varied).
The Authorising Party warrants that:
1. It owns or has the right to authorise security testing of every asset added under this addendum.
2. Where an added asset is hosted by a third party, written permission has been obtained and is referenced in Section 11.
3. It has notified internal stakeholders (security operations, incident response, change control, business owners) whose detection or response activity may overlap with the varied testing window.
4. The original engagement letter remains in force in respect of all scope not varied by this addendum.
Signed for and on behalf of the Authorising Party:
Name: {{CLIENT_AUTHORISING_NAME}}
Title: {{CLIENT_AUTHORISING_TITLE}}
Signature: ____________________________
Date: ________________________________
Signed for and on behalf of the Testing Party:
Name: {{ENGAGEMENT_LEAD_NAME}}
Title: {{ENGAGEMENT_LEAD_TITLE}}
Signature: ____________________________
Date: ________________________________
Effective on the latest of the two signature dates above. Work under the varied scope may not commence before the effective date.
How to use this template
Confirm that the executed engagement letter, statement of work, and rules of engagement are in place. The addendum varies those documents; it cannot exist without them. If any of the three is unsigned, write the original instrument first and skip the addendum entirely.
Pause any work that depends on the new scope. Touching newly added assets or extending the testing window without a signed addendum is unauthorised testing, regardless of any verbal agreement. Where the change is triggered by a halt event mid-engagement, execute the halt first with the pentest stop-test letter template so the pause and the variation each sit on the engagement record as discrete events rather than collapsing into one ambiguous step.
Validate the asset delta against the underlying inventory and re-cost using the pentest scope calculator. Capture the revised tester-day estimate in Section 7 so the commercial change is defensible.
Replace every {{PLACEHOLDER}} with engagement-specific values. Pay particular attention to Section 4 (asset delta), Section 9 (retest impact), and Section 10 (named team and scheme references), which are the three areas where missed updates cause the most downstream pain.
Route the addendum to the same signing authority that signed the original engagement letter, or to a substitute with documented delegation over the affected assets. A junior engineering contact on the kickoff call cannot authorise a scope change.
Get the document signed by both sides before any work under the varied scope starts. Reconnaissance against newly added assets is testing for the purpose of authorisation; an unsigned addendum does not authorise reconnaissance any more than it authorises exploitation.
Store the signed addendum alongside the engagement record so the authorisation chain (proposal, SOW, ROE, engagement letter, every addendum) lives with the work for audit, scheme review, and retest purposes.
Methodology and scheme references
PTES Section 1 (Pre-engagement interactions) treats authorisation as continuous, not one-shot. A scope change is a fresh authorisation event. See the SecPortal PTES framework page for the operator-first walkthrough.
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, planning phase, expects scope and approach to be documented and re-documented when they change.
CREST Defensible Penetration Test specification and CREST CHECK / OVS / STAR scheme documentation. Where the addendum substitutes scheme-accredited testers, the substitution must be acknowledged before the new tester operates. See the CREST penetration testing framework page for accreditation context that may belong in Section 10.
For TIBER-EU and DORA TLPT scope changes in financial services, see the SecPortal TIBER-EU framework page and the DORA framework page. Both schemes require scope changes to be re-acknowledged by the regulated entity.
For severity-driven communications under Section 8, the vulnerability remediation SLA calculator produces a defensible severity rubric the addendum can inherit.
Where the addendum sits in the engagement
The clean paper trail for a regulated penetration testing engagement runs RFP, proposal, SOW, ROE, engagement letter. When scope changes mid-flight, the addendum becomes the next link in that chain. It is the cheapest structured way to absorb the change without reopening the contract. The accepted vendor proposal flows into the SOW; the SOW carries operational rules into the ROE; the ROE binds testers to conduct; the engagement letter authorises the team to begin; the addendum varies that authorisation when the work legitimately needs to change.
For the day-by-day work plan that needs updating after the addendum is signed, see the pentest test plan template. Re-acknowledge the test plan with the client when scope changes.
This template is provided as a starting point for a penetration testing scope change addendum. It is not legal advice. Have the final addendum reviewed by counsel and aligned with the master services agreement, statement of work, rules of engagement, and engagement letter that govern the broader relationship.