New APIs, roles and applications are common discoveries during penetration testing. They can reveal an incomplete inventory, an alternate route into the tested service or an entirely separate system. Discovery does not automatically expand the tester’s authority.
The provider should record the item, avoid active testing beyond existing permission and give the buyer enough evidence to classify ownership, exposure and risk. The buyer then decides whether to include it now, defer it, replace lower-priority work or commission a separate assessment.
A good change-control process protects legal authority and production safety while preserving the value of the discovery. It also prevents the final report from implying coverage of assets that appeared in reconnaissance but were never approved or tested.
Treat discovery and authorisation as separate facts
A route appearing in JavaScript, DNS, API documentation or traffic proves discoverability, not permission to test it. The provider should limit interaction to what the current rules explicitly allow.
Record the source, timestamp, identifier and relationship to the known service. Do not include secrets or customer data in a broad status message; use the protected engagement channel.
- Observed host, route, role or application.
- Discovery method and test context.
- Current authority status.
- Potential relationship to approved scope.
Check whether the item is already covered
Compare the discovery with the signed target inventory, wildcard language, API definitions, role matrix and rules. Some cases are naming clarifications rather than changes.
The buyer and provider should document the interpretation. Ambiguous wording is not a safe substitute for explicit authority when ownership or production effect differs.
- Target and environment identity.
- Existing scope wording.
- Same owner and business service.
- Applicable technique and data restrictions.
Classify the proposed change
Use a small set of categories: clarification, in-scope baseline update, replacement, expansion, reduction or deferral. Classification makes commercial and assurance consequences visible.
A new API version may be a baseline update; a newly acquired application may require a separate engagement. A role can expand effort even when the host does not change.
- Clarification with no effort change.
- Substitution of an unavailable target.
- Added scope or testing depth.
- Removed or deferred coverage.
Triage immediate security and operational risk
Assess internet exposure, privilege, sensitive data, money movement, tenant reach and whether the item suggests uncontrolled shadow or legacy technology. Use minimum interaction until approved.
If passive evidence indicates an urgent exposed secret or active compromise, activate the critical or incident path. Change control must not delay immediate risk notification.
- Reachability and authentication.
- Data and authority involved.
- Production criticality.
- Urgent escalation threshold.
Confirm ownership and third-party rights
Identify the system owner, cloud account, vendor, customer environment and contractual testing rights. A technically related endpoint may belong to a payment, identity or messaging provider.
Obtain additional authorisation where required. Never infer permission to test a third party from the buyer’s use of its service.
- Asset and business owner.
- Hosting and account ownership.
- Supplier or partner boundary.
- Required legal or operational approval.
Assess readiness for the added work
Determine whether representative accounts, roles, test data, documentation, monitoring and contacts exist. An added target without readiness can consume time and still produce weak coverage.
State what can be completed within the remaining window and what would remain sampled. Avoid an optimistic yes that later becomes an undocumented limitation.
- Accounts and identity states.
- Stable environment and release.
- Test data and authoritative outcomes.
- Operations and escalation contacts.
Estimate coverage and method impact
Describe which existing coverage would be displaced or diluted if time is fixed. Added APIs may require operation discovery, authorization matrices and workflow tests rather than a quick scanner pass.
Explain whether the change affects specialists, devices, network locations or production controls. Estimate effort as a range with assumptions when discovery is incomplete.
- New control surfaces and workflows.
- Depth required for meaningful evidence.
- Specialist or tooling needs.
- Trade-off with planned coverage.
Estimate schedule and commercial impact
Identify changes to testing completion, draft review, final report and retest dates. Apply contractual rate or change-order terms transparently.
The buyer should see options: add time and fee, swap equivalent work, accept limited sampling, defer to a new engagement or keep the original plan.
- Incremental effort and cost basis.
- Milestone movement.
- Resource availability.
- Available scope trade-offs.
Obtain written decision from authorised owners
The change request should name the item, classification, rationale, permission, constraints, effort, price, schedule and displaced coverage. Both technical and commercial authority may be required.
An informal chat message can alert the team but should not be the sole record when it changes legal targets, production techniques or fees. Link the approved decision to the engagement record.
- Technical scope approval.
- Commercial approval where needed.
- Updated authority and rules.
- Decision date and approvers.
Update the baseline and coverage plan
Revise target lists, API or role matrices, accounts, prohibited actions, monitoring and evidence requirements. Version the update so the final report can identify the tested baseline.
Notify testers, operations and buyer contacts before work begins. Confirm allowlisting or production controls with a recognisable readiness check.
- Versioned scope and target inventory.
- Coverage and priority updates.
- Readiness and safety controls.
- Secure team communication.
Control reductions and substitutions
When work is removed to make room, name the exact roles, APIs, applications or techniques no longer covered. The buyer should approve the resulting assurance gap.
A substituted target is not equivalent merely because effort is similar. Record the business and risk rationale and keep the original item visible as deferred or unavailable.
- Removed coverage.
- Replacement coverage.
- Risk owner acceptance.
- Residual uncertainty.
Reflect the change in status and reporting
Routine status should state the approved change, revised forecast and buyer actions without broadcasting sensitive discovery. The final report should reconcile original and final scope.
List unapproved, deferred and partially tested discoveries with enough context for follow-up. Do not describe them as tested assets or confirmed vulnerabilities without supporting work.
- Change-log reference.
- Updated milestone forecast.
- Final scope and limitation statement.
- Deferred-discovery register.
Close change control with traceable evidence
At the end of testing, compare approved changes with completed coverage and invoices. Resolve discrepancies before final assurance is issued.
Feed inventory gaps into asset management, architecture and future assessment planning. A discovery can improve governance even when it is not added to the current test.
- Reconcile every discovery with a recorded decision.
- Confirm final authorised targets and completed coverage.
- Carry deferred items into accountable follow-up.
- Preserve approvals with the report and retest evidence.
Use NIST SP 800-115 for assessment planning and rules-of-engagement context and the OWASP Web Security Testing Guide for application coverage context. Apply the organisation’s legal, procurement and change-control requirements.
Make discovery improve assurance rather than weaken control
A disciplined team welcomes new attack-surface information while keeping authority, safety and coverage honest. It does not hide discoveries or chase them without permission.
WIMD records discoveries as controlled decisions, updates the testing baseline and carries every deferred area into explicit residual risk so assurance readers know exactly what changed.