Skip to content

Testing plan · Development agencies

Security testing for development agencies

A client-ready testing workflow for agencies: written scope, isolated test accounts, reproducible findings, remediation ownership and handover evidence.

By BugSnaps · Updated

Start an authorized assessment View an example report

How can a development agency test a client website responsibly?

Obtain explicit authorization for the client's exact targets, create controlled test accounts and agree operational exclusions. Run a scoped baseline, verify actionable findings and deliver fixes with retest evidence. Owning the code or hosting login does not by itself authorize testing every connected system.

Agency projects often combine agency-managed code, client-managed hosting and vendor integrations. A test plan must establish who controls each system before work starts. The handover should let a client see what was checked, what changed and which remaining responsibilities belong to their provider or internal team.

Scope

Define the assets, actors and boundaries.

Use this plan to agree an assessment scope. The exact checks depend on your application, authorization and available test access.

Assets, test roles and priorities for development agencies
Asset or journeyTest contextsPriority
Client website and owned APIsAgency tester and client target ownerDocument exact targets and permitted methods.
CMS, customer and support functionsContent editor, administrator and customerCompare content management permissions and customer access.
Deployment and vendor boundariesAgency engineer and client operations ownerSeparate owned controls from systems requiring another authorization.

Before the assessment

Prepare representative access and a clear scope.

  • Get written approval for hostnames, dates, accounts, data handling and stop conditions.
  • Create client-specific synthetic accounts and keep their evidence separate from other engagements.
  • Agree who fixes application code, hosting configuration, plugins and third-party integration settings.

Only test systems you own or have explicit permission to assess. Agree target boundaries, data handling and stop conditions before active testing.

Workflow

Move from a baseline to verified repairs.

  1. Step 1

    Confirm ownership and scope

    Map client targets and their vendors. Get the proper owner to approve each target; exclude shared hosting infrastructure and vendor services that have not been authorized.

  2. Step 2

    Collect a repeatable baseline

    Assess the verified application with agreed accounts. Preserve the target and coverage details so the client can distinguish tested behavior from missing access.

  3. Step 3

    Verify and assign findings

    Confirm the relevant response and business impact with synthetic data. Route each defect to the party who can repair it, including any manual review needed for custom CMS or commerce workflows.

  4. Step 4

    Retest and hand over

    Retest the repaired deployment and provide the client with evidence, outstanding exclusions and ownership. Revoke test credentials and apply the agreed evidence retention policy.

Report evidence

Keep enough detail to verify and repair the issue.

Use controlled records, remove secrets and keep the result tied to the permission or workflow that failed.

  • The client's approved hostname list, assessment window and permitted account roles.
  • Sanitized reproduction steps linked to the responsible code or configuration owner.
  • Before-and-after control results and a clear inventory of excluded vendor systems.

Use the evidence in the release decision

Give the client a decision record for unresolved issues and exclusions. A report should not say the whole site is secure when only public pages or a staging environment were tested.

Coverage and limits

Know what automation establishes and what needs a reviewer.

Automated baseline

An automated baseline can support repeatable project handovers. The agency must still check authorization, interpret coverage and verify that a finding belongs to the client's application rather than an unrelated shared system.

Review MyPentest's scope

Human review

Use human review for scope decisions, custom CMS permissions, payment workflows and client-specific requirements. Validate any assurance statement against the actual evidence before putting it into a delivery certificate or proposal.

Discuss the assessment scope

Common questions

Questions about testing development agencies.

Can an agency scan every site it built?

Only with current authorization from the appropriate owner for the intended assessment. A past development engagement is not a blanket permission for future testing or connected vendors.

Can we send the report directly to the client?

Review its scope, evidence and redaction first, then share through the agreed delivery channel. Include retest results and remaining limitations so the client can act on it.

Is white-label reporting part of this workflow?

This page describes an agency testing process, not a claim that MyPentest includes a white-label feature. Use the product's available report format and an agreed client handover.

References for this testing plan

These primary references inform the testing approach. They are not endorsements of BugSnaps or claims that a product implements every test in a standard.