A development agency should obtain an independent penetration test before client handover when the delivered web, API or mobile product creates material customer, data, contractual or launch risk. The assessment should be timed after critical workflows and integrations stabilize but early enough to remediate and retest before acceptance. Independence adds credible adversarial evidence without replacing the agency’s own secure-development and QA obligations.

Define the architecture question before testing

Define what the handover must prove. A client may need confidence that the release resists common attack paths, evidence for an enterprise onboarding review, closure of contractual security requirements, or a clear record of known residual risk. The answer sets scope, timing and deliverables.

Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.

Build the minimum evidence pack

  • A current component and trust-boundary diagram for the environment under test.
  • Identity, credential, network and data-flow details relevant to the decision.
  • Representative accounts, workloads and synthetic records with known ownership.
  • Logs or traces that follow the action through every material control point.
  • Explicit safety limits, stop conditions, owners and restoration steps.

Provide the release candidate, architecture and data-flow summary, web and mobile clients, API specifications, roles and tenant model, authentication paths, third-party integrations, test accounts, synthetic data, known limitations, delivery date and client evidence requirement. Identify what the agency owns versus customer-managed infrastructure.

Choose the right point in the delivery lifecycle

Testing too early creates noise from unfinished functionality; testing after acceptance leaves no room for safe remediation. Use a feature-complete, deployable candidate with security-relevant configuration close to the handover environment.

  • Freeze or record the tested build and configuration.
  • Complete authentication, authorization and critical workflows first.
  • Leave time for triage, remediation and independent retesting.
  • Plan a narrow delta review for changes made after testing.
  • Align the report date with customer or audit freshness expectations.

The final assurance pack should name the build, environment, test dates and post-test changes. “Recently tested” is weak when nobody can identify what was assessed.

Scope the product as the client will operate it

A handover test must include trust paths the customer will actually inherit: public and internal APIs, administrative roles, tenant boundaries, file flows, cloud integrations and mobile backends.

  • Map web, mobile and machine clients to shared APIs.
  • Include ordinary, privileged and cross-tenant identity pairs.
  • Test high-value business workflows and state transitions.
  • Cover documented, versioned and observed API routes.
  • Identify customer-managed controls that require separate validation.

Tie every included component to an owner and business workflow. List exclusions and their consequence rather than hiding them behind an asset count.

Prepare safe, representative access

Independent testers need enough context to spend time on adversarial reasoning rather than rediscovery, but credentials and client data must remain controlled.

  • Create dedicated accounts for each role and at least two tenants.
  • Use synthetic records with clear ownership and cleanup.
  • Share API collections and architecture under agreed confidentiality.
  • Provide safe callback, payment and file-processing sandboxes.
  • Agree rates, destructive exclusions, contacts and stop conditions.

Maintain an access register and revoke test credentials after closure. Do not copy production customer data into staging merely to make it look realistic.

Keep the assessment independent and collaborative

Independence means the tester reaches and validates conclusions without being the author of the product or fix. It does not require withholding architecture or preventing engineering collaboration.

  • Let testers choose hypotheses and validate evidence independently.
  • Allow developers to clarify intended behaviour and data ownership.
  • Separate finding validation from pressure to preserve the release date.
  • Record conflicts, accepted limitations and risk owners.
  • Use remediation calls to resolve root cause, not negotiate away evidence.

The report should state provider, method, scope and limitations, while the agency retains its own remediation decisions and client communication.

Demand handover-ready technical deliverables

A vulnerability list is not enough. Developers need reproducible evidence, and the client needs a concise assurance view with sensitive detail controlled.

  • Require exact preconditions, requests, responses and authoritative effects.
  • Map severity to business impact and affected identity or tenant pairs.
  • Include root-cause and pattern-level remediation guidance.
  • Provide coverage and limitation statements even when no issue is found.
  • Create a closure record that distinguishes fixed, accepted and open risk.

Prepare a confidential technical report and a controlled summary rather than sharing exploitable detail broadly. The summary must not overstate the underlying scope.

Remediate without losing release traceability

Fixes made during or after testing can change the assessed build. Manage them as controlled release changes with regression evidence.

  • Link each finding to code, configuration and owner.
  • Prioritize exploitable and high-blast-radius paths.
  • Fix shared authorization or platform patterns, not only reported endpoints.
  • Run functional and security regression before retest.
  • Record all post-test changes outside the finding set.

A retest candidate should be identifiable and deployable. If substantial features change, reassess the affected surface instead of treating the original report as current.

Close through independent retesting

A developer screenshot or new status code does not prove remediation. The tester should repeat the original exploit and examine nearby paths using the same failed control.

  • Reproduce the original precondition and payload.
  • Confirm the prohibited business effect no longer occurs.
  • Test legitimate use to detect broken functionality.
  • Sample sibling endpoints, roles or tenants sharing the fix.
  • Document residual limitations and the exact retested build.

Issue a retest record that preserves original finding identity, outcome, date, environment and evidence. Keep open or accepted findings visible to the client decision maker.

Execute as controlled hypotheses

  1. Establish the legitimate baseline and capture authoritative state.
  2. Change one trust variable—identity, route, scope, object, time or environment.
  3. Observe the decision at each layer rather than relying only on the response.
  4. Stop at the minimum proof that demonstrates or rejects the hypothesis.
  5. Restore test state and record residual uncertainty or blocked coverage.

Authorize the provider in writing and coordinate with the agency, hosting owner and client. Keep test data synthetic, define production exclusions and use a monitored environment representative of security decisions. If production confirmation is essential, restrict it to pre-approved, low-impact hypotheses.

Report the architectural consequence

Deliver three connected views: engineering evidence for fixes, an accountable risk register for the handover decision, and a controlled assurance summary for customer stakeholders. State explicitly what remains untested, changed or accepted.

Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.

Required closure evidence

  • The original proof no longer succeeds.
  • A legitimate workflow still succeeds under the intended identity and route.
  • Alternate consumers of the same pattern enforce the same invariant.
  • Telemetry records both allowed and denied decisions with useful context.
  • The architecture record and threat assumptions reflect the new control.

Remediate at the durable control point

Fix defects at the component or architecture layer that owns the invariant, add automated negative tests, upgrade insecure defaults and document operational dependencies the client must maintain. Avoid temporary handover-only controls that disappear after acceptance.

Retest the invariant, not just the payload

Have the independent tester validate the release candidate intended for handover, repeat each exploit, sample the shared pattern and confirm normal workflows. Run a delta assessment if security-relevant code or configuration changes afterward.

Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.

The architecture decision

Use independent pre-delivery penetration testing when the handover transfers meaningful security risk or requires credible customer assurance. Schedule it against a stable candidate, give testers representative access, preserve independence through evidence, and do not call the engagement closed until fixes are retested or residual risk is explicitly accepted.

Ask WIMD to plan independent pre-delivery testing that fits the build, handover date, client evidence need and remediation window.