1. Define what the review covers
Inventory the public website, administration area, APIs, forms and integrations that support your operations. Identify who maintains each part and what data it processes. An online shop with payments, a client portal and an information site need different scopes; page count alone does not describe that difference.
Before work starts, agree domains, environments, test accounts, dates and boundaries in writing. Specify who authorises the checks, how incidents will be reported and when testing must stop. Third-party services require a check of their terms and permissions; appearing on your website does not place them within the authorised scope.
2. Ask for a method that can be explained
OWASP WSTG provides a testing methodology for web applications. ASVS provides requirements for verifying security controls. These references help define the work; they do not certify that a business or website is invulnerable. [1] [2]
Ask the proposal to state which areas will be reviewed and which are excluded: configuration, authentication, permissions, session management, input handling and relevant business functions. The combination of tools and manual review should match the agreed scope. An isolated automated check does not establish that every application workflow has been reviewed.
3. Review access and changes in context
Prepare a list of roles: visitor, customer, employee and administrator, where relevant. The audit team needs to understand what each role is allowed to do. An apparently ordinary feature can be a problem if a role that does not need it can access it. Provide dedicated accounts, avoid sharing personal credentials and agree to remove access when the work is finished.
The review should also consider how the CMS, extensions and dependencies are maintained. Ask who approves updates, where they are tested and how to restore a previous version. Recording an outdated version is useful; deciding its priority requires understanding exposure, actual use and existing safeguards.
4. Require findings that support action
Each finding should describe the affected component, the minimum evidence needed, the potential impact, the conditions under which it could occur and a specific recommendation. The report itself must protect sensitive information: limit screenshots and test data to what is necessary and agree who can access the document and for how long.
Hypothetical example: if a basic account can view a restricted document, the report should explain the expected permission boundary, what was observed and the proposed fix. It need not copy real documents to demonstrate the issue. The management summary should turn technical priority into an understandable decision without overstating the impact.
5. Separate remediation from verification
Clarify whether the quote covers the audit alone, remediation as well, or a follow-up check. Give each action an owner and an agreed deadline. If a hosting provider and development agency are involved, define who coordinates the changes and who confirms that essential functions still work.
Closing a task does not prove that the problem has disappeared. Keep evidence of the follow-up verification and record outstanding limitations. Significant changes to access, payments or integrations may require the scope to be reviewed again. An audit describes a state at a point in time; it does not replace continuing maintenance.
6. Prepare a useful first conversation
Bring a description of the business, the main URLs, known technology, involved suppliers and dates to avoid. Do not send passwords or databases at the first contact. Explain your concern: service continuity, customer permissions, a recent change or a lack of visibility into maintenance.
When working from Barcelona with teams in other countries, agree the report language, time zones and an operational contact. Proximity helps coordination, but quality depends on precise scope, clear evidence and follow-through. Those are useful criteria for comparing proposals and turning a review into a verifiable improvement.