How to Choose a Website Security Assessment Provider

Start with the assessment objective, not the service label

A business may need a pre-launch baseline, validation after a major change, review of a payment journey or evidence for customers and partners. These objectives create different scope, depth and outputs. If the request says only “test our website security”, each provider will estimate a different engagement and the prices will not be comparable.

Before the conversation, list domains, environments, APIs, user roles, data types, high-consequence flows and recent changes. Record third-party assets, operating constraints and the decision the report must support. A capable provider asks about architecture, authorisation and business logic before confirming testing days.

• ✓Which production, staging, API and third-party assets are in scope?
• ✓How many roles, account types and important business flows exist?
• ✓Which data is sensitive and which impacts must be avoided?
• ✓Will the result support launch, a remediation backlog or third-party assurance?

A long report does not automatically create better security. Value comes from the right scope, evidence engineers can act on and confirmation that fixes genuinely close the issue.

Compare proposals against one equivalent scope

A proposal should name assets, test accounts, methodology, schedule, exclusions, assumptions, outputs and retest responsibility. Automated scanning, configuration review, manual web-app testing, code review and penetration testing are different activities. Do not accept one broad label without understanding what the team will actually do.

OWASP ASVS provides technical requirements that can support contracts and procurement, while OWASP WSTG provides web application and web-service testing scenarios. Ask the provider to state the referenced version, relevant control groups and excluded coverage. A phrase such as “OWASP aligned” should not be interpreted as complete coverage of every standard.

• ✓A list of in-scope, out-of-scope and third-party dependencies.
• ✓The balance of scanners, manual testing, configuration or source review.
• ✓Referenced standards, versions and system-specific tailoring.
• ✓Dates for access, testing, clarification, reporting and retesting.

Review safety rules before granting access

NIST SP 800-115 covers planning, conducting assessments, analysing findings and developing mitigation. For a live system, both parties need written rules of engagement covering test accounts and data, rate limits, operating windows, emergency contacts, prohibited actions and stop conditions.

Do not send production passwords through casual chat. Use named accounts with least privilege, expiry and post-engagement revocation. Agree how evidence is stored, transferred and deleted because screenshots and sample requests can contain tokens or sensitive data. Actions that might alter data, send real messages or affect service need an appropriate environment and explicit authorisation or should remain excluded.

• ✓Rules of engagement and a contact authorised to stop testing.
• ✓Named accounts, MFA, expiry and access revocation.
• ✓Handling rules for tokens, logs, screenshots and sensitive data.
• ✓An urgent channel for findings with immediate impact.

Require evidence that engineers can use

A useful finding includes context, asset, preconditions, minimal reproduction, a negative control, impact, sanitised evidence and remediation direction. Severity should not be only a scanner label; it should reflect exploitability, required access, data type, impact scale and current controls.

Ask for a sanitised report sample before signing. Check for an executive summary, engineering detail, a prioritised action list and status after retesting. The provider also needs a way to handle uncertain observations instead of reporting every scanner signal as a confirmed vulnerability.

• ✓Minimal reproducible evidence without unnecessary sensitive data.
• ✓Impact connected to business and technical context.
• ✓Remediation focused on the control to improve, not only a product to buy.
• ✓A clarification channel between assessors and the remediation team.

Agree retesting, handover and limitations

Retesting terms should state the number of rounds, time window, covered findings and confirmation output. If remediation changes the related architecture or flow, that may require new scope rather than a simple retest. The final record should distinguish fixed, partly mitigated, accepted and open findings.

No provider can demonstrate that a system is “absolutely secure”. An assessment is a time- and scope-bound view. Ask what was excluded, how the test environment differs from production and when to reassess. The business still owns patching, dependencies, logs, backups, access and incident response after the engagement.

• ✓Retest scope and timing written into the proposal.
• ✓A final report showing the status of each remediated finding.
• ✓Handover of limitations, assumptions and residual risk.
• ✓Revocation or agreed deletion of accounts, test data and evidence.

Twelve questions for a website security assessment provider

Score every candidate on the same matrix: system understanding, scope, methodology, safety constraints, evidence, reporting, retesting and engineering collaboration. Certifications can be a signal, but they do not replace a report sample, the assessor's questions or experience with a comparable architecture.

Friday Works provides scoped website, web app and API security assessments focused on reproducible evidence, prioritised remediation and agreed retesting. The current service is not described as a full penetration-testing or Red Team programme. Businesses should use the same questions below to evaluate Friday Works as any other provider.

• ✓1–3. Which objective, assets, roles and flows are in scope?
• ✓4–6. What methodology, references and exclusions apply?
• ✓7–9. How are rules of engagement, test data and evidence handled?
• ✓10–12. What do reporting, remediation support and retesting include?