Note from the Editor: This blog is the final installment of an 8-part blog series entitled, “The Complete Web Application Penetration Test Guide.” To read the series from the beginning, please go to the blog, What is a Web Application Penetration Test?
One of the first questions we hear often is, “How long does it take?” And, yes, “it depends” is part of the answer. However, we wanted to at least give you a rough idea of how long a web application penetration test takes for planning purposes. This blog also covers factors that go into the timeline, and how that time is spent.
Typical Web Application Penetration Test Timeline
First, let’s break down the typical pieces of a web application penetration test timeline:
Contracts/Planning/Kick-Off Call
This is the bundle of everything that leads up to the actual testing for an application. It includes scoping calls, proposals, formal contracts, etc. These all need to be in place and signed before a project can even begin. This can take some time depending on your organization’s size and efficiency. You should plan for this part of the process to take 2-3 weeks, conservatively. But we can always move more quickly if you can, if there’s a more urgent need.
Execution
Testing starts as soon as the schedule is agreed upon and the scope/ROE has been confirmed during the Kick-Off Call. A small application will probably require a week of time allocated for execution. Larger applications can take up to 2-3 weeks of testing time. This timeline is going to be based on:
- application size
- scoping information gathered
- any restrictions placed on testing (e.g., testing required to be after business hours, etc.)
Documentation and Quality Assurance
Documentation and quality assurance begin after we complete all the active testing and write the reports. The QA process has a couple different layers to it. If the web application penetration test is the only service being performed, it will probably take a week. The report set will be delivered at the end of it, prior to the deliverable presentation.
Deliverable Presentation
The last milestone for the initial assessment is the presentation where we review the delivered report set with your team. This will usually fall right after the QA period, depending on all the stakeholders schedules, etc.
Retesting
Any retesting required for reported vulnerabilities that you want to fix is usually done within a 90 day window of the deliverable presentation. This helps us maintain the integrity of the report set. So that new revisions aren’t being released too long after the initial delivery.
What Can Affect The Execution Time
There are some important factors that contribute to the time allocated to a web application penetration test. Let’s touch on those in a little more detail:
Application Size
Web application size can be one of the most nebulous and subjective scoping parameters across all of penetration testing. But the rough size of an application directly correlates to the amount of time an engineer needs to spend on it to give you a thorough and holistic test. Given that solid web application penetration testing should be a roughly 25% automated and 75% manual process, major applications can be a significant undertaking. So if you’ve got an app with thousands of screens, dynamic pages, form submissions, etc., you should plan on multiple weeks of testing.
Number of User Roles
Similar to application size, the number of user roles that need to be tested as part of a web application penetration test can exponentially increase the scope. Depending on a particular application, each user role could have their own set of unique screens and functionality to be evaluated. Even if the users just have subsets of functionality drawn down from an administrative role, each role needs to be tested for opportunities for privilege escalation and lateral movement that may be unique to that user. This takes time and can move testing from one week to multiple weeks.
Testing Restrictions
This is probably common sense, but I’ll include it here just to be thorough. Any time restrictions placed on your test team is going to result in a longer testing timeline. For example, if you can only test during certain hours in a day. This generally results in the same amount of testing being spread over a longer period of time.
So ultimately, there are several factors that impact the length of a web penetration test. You should probably give yourself at least a month from engaging a security partner to expecting to have a report in your hands. We can accelerate timelines by using multiple engineers simultaneously on a project. However, this will increase your overall cost.
Once contracts are signed, the execution phase is the longest period of time that needs to be scheduled. And, the amount of time will be based on several factors, the most important of which is application size.
If you still have questions or want to start planning for a web application penetration test please reach out. We’d be happy to help.
About the Author:
JR Johnson is the Director of Penetration Testing at SIG. He holds a BS in Computer Science Engineering from the University of Florida. And a MS in Information Assurance and Cybersecurity from the Florida Institute of Technology. JR is an avid collector of security-related certifications, including OSCP, OSWE, GWAPT, CISSP, C|EH, CISA, and PCI QSA. You can find him on Twitter @InfoSecJR.
