VAPT work often reveals an undocumented host, API, integration or service path, while product teams may release a new build or request an added workflow. The contract must let the parties respond without testing unauthorised targets, hiding material risk or turning every clarification into a commercial dispute.

Change control should be fast enough for an active assessment and strict enough to preserve authority, safety, price and assurance claims. The discovery itself, the decision to investigate and the final coverage record are separate actions.

Define change categories in the contract

Separate buyer-requested additions, newly discovered assets, changed builds, unavailable dependencies, expanded depth and remediation or retest changes. Each category can have a different consequence.

A clarification that preserves the original boundary should not automatically be a paid change. A new target, identity matrix or specialist technique may be material. Define examples without pretending every case is predictable.

  • Added or removed target.
  • New role, tenant or workflow.
  • Build or architecture replacement.
  • Access, dependency or schedule change.

Set materiality thresholds

Materiality can consider expected effort, risk, authorization, specialist need, environment impact and effect on deliverables. A five-minute hostname correction differs from a newly discovered payment service.

Allow the delivery lead and buyer owner to resolve immaterial changes within a recorded tolerance. Material changes require formal impact and approval.

  • Effort or duration threshold.
  • New legal or third-party boundary.
  • Changed production-safety profile.
  • Effect on assurance or acceptance.

Use a stop-and-notify rule

When a tester encounters a target not clearly authorised, it should record the minimum necessary fact and stop active probing. DNS linkage or a client reference does not prove permission.

Notify the named contact with location, discovery method, potential relevance and any immediate safety concern. Do not collect avoidable data to prove the target is interesting.

  • No active testing before authority.
  • Minimum evidence retained securely.
  • Urgent exposure escalated safely.
  • Discovery time and source recorded.

Verify ownership and permission

The buyer confirms whether the asset is owned, operated by a supplier, shared or completely unrelated. Cloud and platform terms or processor agreements may require separate approval.

If authority cannot be established, keep the item excluded and describe the limitation. A commercial desire to include it cannot replace legal permission.

  • Asset owner and operator.
  • Contract or platform testing rights.
  • Environment and customer-data implications.
  • Named authority granting permission.

Triage relevance without overtesting

Use architecture and available documentation to decide whether the discovery affects critical workflows or shared controls. The aim is to prioritize the change, not perform an unapproved mini-test.

Classify urgent safety exposure separately from broader coverage value. A publicly exposed administration service may need immediate containment even before a full assessment is approved.

  • Connection to in-scope assets.
  • Potential data, authority or operational impact.
  • Likelihood of shared root cause.
  • Urgency and safe interim action.

Prepare a complete impact statement

The provider states added work, people, access, methods, safety controls, deliverables, price and schedule. It also states what happens if the change is declined.

The buyer should see trade-offs. Adding a target without more time may reduce depth elsewhere; that reduction must be explicit and approved, not hidden in delivery.

  • Technical scope and prerequisites.
  • Effort, fee and tax impact.
  • Schedule and milestone impact.
  • Coverage trade-off or residual limitation.

Use named approval authority

Only identified representatives can approve a change. Engineers can clarify facts but should not accidentally commit budget or authorize testing.

Approval should be written in the contract system or agreed channel and reference the impact statement. Emergency authority can be faster but must still be documented.

  • Buyer technical approver.
  • Commercial or procurement approver.
  • Provider delivery owner.
  • Emergency alternate and spending limit.

Update all affected control documents

An approved change updates the target register, rules of engagement, account plan, schedule, price and acceptance baseline as applicable. One email should not contradict the signed scope.

Version and date the update so testers, operations and report reviewers use the same boundary. Communicate new production risks before work resumes.

  • Scope and build baseline.
  • Testing window and safety ceilings.
  • Evidence and deliverable requirements.
  • Commercial order and milestones.

Price foreseeable changes fairly

The contract can pre-price day rates, units or optional modules for likely additions. This accelerates approval without granting an unlimited right to bill.

Require estimates and caps. Fixed-price providers should not charge for ordinary estimation error or work clearly included in the baseline; buyers should not expect genuinely new systems for free.

  • Pre-agreed rate card or units.
  • Minimum and maximum increments.
  • Estimate validity and cap.
  • No work before approval except authorised emergency action.

Handle changed builds and blocked access

A replacement build may invalidate earlier evidence or require regression. Define thresholds for minor correction, partial rerun and full restart.

When access is unavailable, record cause and blocked time. Decide whether the provider shifts to other work, pauses, reschedules or raises a change; do not silently mark the area tested.

  • Build diff and affected coverage.
  • Re-execution decision.
  • Pause and reschedule rules.
  • Limitation if readiness is not restored.

Report declined or deferred discoveries

The final report should identify relevant untested discoveries and why they remained outside scope, without implying vulnerability where none was tested.

Preserve the decision, owner and recommended next action. A deferred separate assessment can be linked without contaminating the original result.

  • Discovery and relevance stated factually.
  • No unsupported security conclusion.
  • Decision and authority recorded.
  • Residual uncertainty visible to relying parties.

Audit the change history at closure

Reconcile every request to approved, declined, withdrawn or superseded status. Ensure final scope, coverage, invoices and retest records match.

Use recurring change patterns to improve future inventories and readiness. This learning should not rewrite the historical record.

  1. Export the change log.
  2. Match approvals to testing and charges.
  3. Reconcile final coverage and limitations.
  4. Carry deferred work into the risk process.

Use NIST SP 800-115 for assessment planning, rules and reporting, and use the OWASP Web Security Testing Guide to evaluate how a scope change affects practical coverage. Contract interpretation and testing authority should be confirmed by the appropriate legal and procurement owners.

Keep change fast, authorised and visible

Good change control prevents two opposite failures: unsafe testing beyond authority and rigid refusal to address a material discovery. It gives the engagement a controlled path between them.

WIMD links discovery, triage, written impact, approval, updated rules and final reconciliation so scope can evolve without losing evidence, safety or commercial trust.