What to Expect from a Security Assessment: A Client Guide

Before the Assessment: What to Prepare

The preparation phase is where the success of a security assessment is largely determined. A well-prepared client enables testers to focus their time on finding real vulnerabilities rather than troubleshooting access issues or clarifying scope. Start by gathering your scoping documentation well in advance of the engagement start date. This includes a complete list of IP addresses, URLs, and application environments that are in scope, along with any systems or areas that should be explicitly excluded from testing.

The key items to have ready before testing begins:

Preparation may seem like overhead, but every hour invested here saves multiple hours during the assessment itself. A consultancy that receives complete scoping documentation and working credentials on day one can immediately begin productive testing. Without this preparation, the first one to two days of an engagement are often spent on logistics rather than security work.

During the Assessment: What Testers Actually Do

Once testing begins, the assessment follows a structured methodology even though the specific techniques vary based on the type of engagement. Understanding what the testers are doing during each phase helps you set expectations and respond to requests more effectively.

The assessment typically begins with reconnaissance and information gathering. Testers map the attack surface by identifying all accessible services, endpoints, and technologies in use. For web applications, this means crawling the application, identifying all forms and input fields, mapping authentication flows, and understanding the application's business logic. For infrastructure assessments, this involves port scanning, service enumeration, and identifying the software versions running on each system. This phase is methodical and thorough because it forms the foundation for all subsequent testing.

Next comes vulnerability identification, where testers combine automated scanning with manual analysis to identify potential weaknesses. Automated tools catch common issues quickly, but the real value of a professional assessment comes from manual testing. Experienced testers probe business logic flaws, authentication bypasses, privilege escalation paths, and chained vulnerabilities that automated tools consistently miss. This is the phase where the tester's skill and experience make the difference between a basic scan report and a genuine security assessment.

Exploitation follows, where testers attempt to demonstrate the real-world impact of identified vulnerabilities. This does not mean breaking things. It means carefully proving that a vulnerability can be exploited in a controlled manner, documenting the steps required, and capturing evidence such as screenshots, request and response pairs, and proof of access. The goal is to provide irrefutable evidence that the vulnerability is real and to demonstrate its potential impact in business terms.

Throughout the assessment, professional testers document their findings as they go rather than leaving documentation until the end. Each finding is recorded with a description, severity score, evidence, and remediation guidance. This concurrent documentation approach ensures that no findings are lost and that the report can be assembled quickly after testing concludes.

A typical assessment timeline ranges from one to three weeks depending on the scope. A focused web application assessment might take five to ten days, while a comprehensive infrastructure and application assessment for a large environment could extend to three weeks or more. During this time, expect communication from the testing team, particularly if they discover critical vulnerabilities that warrant immediate attention. Many consultancies provide daily standups or interim notifications for any critical or high severity findings that the client should begin addressing immediately rather than waiting for the final report.

After the Assessment: Understanding Your Report

The assessment report is the primary deliverable and the document your organisation will reference for months after the engagement. A professional report is structured for multiple audiences: executives who need the high-level picture, and technical teams who need the details to actually fix the issues.

The executive summary is written for non-technical stakeholders. It should clearly communicate the overall security posture, the number and severity of findings, and the key risks in business language. A good executive summary avoids jargon and focuses on what the findings mean for the organisation rather than the technical details of how they work. This is the section that gets shared with the board, so it needs to be concise, clear, and impactful.

The technical findings section is where the detail lives. Each finding should include a clear title, a severity rating with a CVSS score and vector string, a description of the vulnerability, steps to reproduce it, evidence such as screenshots and request/response data, the potential impact if exploited, and specific remediation guidance. The quality of this section directly determines how effectively your engineering team can address the issues. Vague findings with generic remediation guidance create confusion and delay. Specific findings with clear reproduction steps and targeted remediation accelerate the fix process.

For a detailed breakdown of what makes a high-quality report, see our guide on how to write a security assessment report. Understanding report structure helps you evaluate the quality of what you receive and ask informed questions during the debrief call.

Modern Delivery: Portal vs PDF

Traditionally, security assessment reports were delivered as PDF documents attached to encrypted emails. The consultancy would finish the report, send a password-protected PDF, and the engagement would effectively end. This approach has significant drawbacks that modern delivery methods solve.

PDF reports are static. Once delivered, they cannot be updated with remediation progress, new context, or retest results without generating a completely new document. They also create security risks of their own. Emailing a document that contains detailed vulnerability information about your organisation, complete with exploitation steps and evidence, is inherently risky. Even with encryption, the document is often decrypted and stored on local machines, shared via internal email, or saved to shared drives with broad access. The very document that describes your security weaknesses can itself become a security liability.

Modern delivery through a client portal addresses all of these issues. A portal provides secure, role-based access to findings, so only authorised personnel can view the results. Findings can be updated in real time as remediation progresses, creating a living document rather than a static snapshot. Clients can filter findings by severity, status, or category, making it easier to plan and track remediation work. Sensitive data never needs to be emailed, and access can be revoked instantly if someone leaves the organisation.

Portal delivery also enables collaboration between the consultancy and the client. Clients can ask questions about specific findings, update remediation status, and request retests directly through the platform. This ongoing dialogue improves the quality of remediation and strengthens the client-consultancy relationship. For an in-depth look at the benefits of portal-based delivery from the provider perspective, see our guide on why pentest firms need a client portal.

If your current provider still delivers via email PDF, it is worth asking them about portal-based delivery options. The difference in experience is substantial, particularly for organisations that run multiple assessments per year and need to track remediation progress across engagements.

What to Do with Your Findings

Receiving a report is only the beginning. The real value of a security assessment is realised through effective remediation. Too many organisations file the report away and never act on the findings, or they address only the most critical issues and ignore everything else. A structured approach to remediation ensures you get the maximum return on your security investment.

Start by prioritising findings based on both severity and business context. A critical finding on a public-facing application that processes payment data should be addressed before a critical finding on an internal development server with no sensitive data. CVSS scores provide a useful starting point for prioritisation, but they measure technical severity, not business risk. Your team's knowledge of which systems are most important to the business is essential for effective prioritisation.

Create dedicated remediation sprints rather than trying to fold security fixes into regular development cycles. Security findings compete with feature work for developer attention, and without dedicated time they often get deprioritised indefinitely. A focused remediation sprint after each assessment ensures findings are addressed while the context is fresh. Assign specific owners to each finding, as unassigned findings are rarely resolved.

Track progress systematically. Whether you use a portal, a project management tool, or a dedicated spreadsheet, maintain visibility into which findings have been addressed, which are in progress, and which are blocked. Regular status reviews with the remediation team keep the work on track and surface blockers early. Share progress updates with leadership to demonstrate that the organisation is actively managing its security risk.

For critical and high severity findings, request a retest from your provider once remediation is complete. A retest verifies that the fix is effective and that no new issues were introduced during the remediation. Some providers include a limited retest window in the original engagement price, while others charge separately. Either way, verification is important. Building a remediation culture where findings are consistently tracked, assigned, fixed, and verified transforms security assessments from a compliance checkbox into a genuine improvement tool.

How to Choose a Provider

The quality of your security assessment depends heavily on the provider you choose. Not all security consultancies deliver the same level of service, and the cheapest option rarely provides the best value. Here are the key factors to evaluate when selecting a provider.

• Certifications and qualifications. Look for industry-recognised certifications such as CREST, OSCP, CHECK, OSCE, or GPEN. These certifications demonstrate that the testers have passed rigorous practical examinations and maintain their skills through continuing education. A consultancy should be able to tell you exactly who will be testing your systems and what their qualifications are.
• Methodology transparency. Ask about the testing methodology. A professional consultancy will follow a recognised framework such as OWASP Testing Guide, PTES, or NIST SP 800-115, and they should be able to explain their approach clearly. Be wary of providers who are vague about their methodology or who rely exclusively on automated scanning tools.
• Report quality. Request a sample report (redacted, of course) before signing an engagement. The quality of the report tells you a lot about the consultancy. Look for clear writing, specific remediation guidance, proper evidence documentation, and a structure that serves both technical and non-technical audiences. If the sample report is poorly written or lacks detail, the report you receive will likely be similar.
• Delivery model. Ask how results are delivered. Portal-based delivery with real-time finding access and remediation tracking provides significantly more value than a static PDF sent via email. The delivery model also affects how easily you can collaborate with the consultancy on remediation.
• Ongoing support. The best providers offer support beyond the initial report delivery. This includes debrief calls to walk through findings, availability to answer technical questions during remediation, and retest services to verify fixes. A provider who disappears after delivering the report leaves you to interpret and act on findings alone.

Choosing the right provider is a significant decision that affects your organisation's security posture. For a more comprehensive guide to evaluating and selecting a security testing provider, see our detailed guide on choosing a security testing provider.