Close Menu
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Facebook X (Twitter) LinkedIn
Facebook X (Twitter) LinkedIn
Information Security BuzzInformation Security Buzz
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Subscribe
Information Security BuzzInformation Security Buzz
Home - Articles - How Often Should Companies Conduct Web Penetration Testing?
Articles

How Often Should Companies Conduct Web Penetration Testing?

ISBuzz TeamBy ISBuzz TeamJune 3, 2015Updated:July 4, 20244 Mins Read
Share LinkedIn Twitter Facebook Copy Link Email
web penetration testing
Share
Facebook Twitter LinkedIn Email Copy Link
Quick AI Summary
ChatGPTClaudeGeminiGrokPerplexityDeepSeekCopilot

Following our previous blog post “How long does website penetration testing take” we received a lot of questions from our customers and partners about the recommended frequency of penetration testing for their web applications. In this blog post we will answer that question.

First of all, we would like to highlight that penetration testing is not the only thing that you need to perform in order to keep your website secure. A penetration test is not designed to protect you from all possible risks that your website faces, so you should always combine it with daily vulnerability and malware scanning, data integrity and threat monitoring.

Duration and frequency of various web security services necessary to keep your applications secureA good example of a risk that a penetration test is not designed to prevent, and cannot prevent, is compromised webmaster’s PC with stored credentials that will open the door to hackers. This is especially true in large companies, where many different people and teams, including external parties and consultants, have access to certain parts of their website, and it is almost impossible to build 2Factor authentication (2FA) or One-Time-Passwords (OTP) to minimize those risks. Therefore, a compromise of any privileged third party that has access to the website means a compromise of the website as well. Your hosting or cloud provider can also fall victim of hackers, providing them with access to your website. Companies that rent dedicated servers or even racks are not free from these risks either – quite often data centers have web control panels from which servers, routers, and virtual machines can be re-configured. Remote access, blocked from the outside, is usually authorized for the IPs of the datacenter support, opening one more door in case of its compromise.

As you can see, besides your own web application, with its internal vulnerabilities and weaknesses, there are other risk factors to think about. However, by implementing file integrity, proper event and anomalies monitoring you can significantly minimize those third-parties’ risks. Daily vulnerability scanning is also useful to get notifications about the most recent vulnerabilities in your CMS, framework, web server, or any new SSL weaknesses – something that is not yet discovered at the moment of your last penetration test. Therefore, vulnerability scanning, file integrity and anomalies monitoring, and malware scanning should be conducted daily, especially nowadays, when there are lot of free tools and open source applications to do all these tasks in-house to reduce the operational costs.

Another important component of risk remediation is source code review that shall be conducted before web application launch, or after any significant update of the application functionality. Source code review is an essential part of White Box penetration testing, however in this blog post we speak about more budget-friendly Black Box penetration testing. If you can integrate secure coding and regular code review into your SDLC (System Development Life Cycle) – you can almost avoid your spending on source code review by performing this task by internal resources.

We are arriving at the main question of this article: How often one should conduct web penetration testing in order to keep his or her web application secure? If you have to meet compliance, such as PCI DSS requirement 11.3, then you must conduct a penetration test at least once a year. Here is what PCI DSS 3.1 says about penetration testing frequency (section 11.3.1.a):

“Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:

  • Per the defined methodology
  • At least annually
  • After any significant changes to the environment.”

And here is how PCI SSC defines “significant changes”:

“The determination of what constitutes a significant upgrade or modification is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.”

At High-Tech Bridge, we recommend conducting web penetration tests before launch of your web application, after its update, and at least once per year in order to test it for new vulnerabilities or attacking techniques that appear publicly almost every month. Of course, each web application and its related business needs are unique, however this timing model can be taken as a basic.

ISBuzz Team
  • ISBuzz Team
    Air Canada Data Breach: BianLian Extortion Group Claims A Massive Heist Contrary To Airline’s Earlier Statement
  • ISBuzz Team
    Unprecedented DDoS Attack Rocks The Web: Tech Giants Reveal A Digital Tsunami
  • ISBuzz Team
    CISA Flags High-Severity Adobe Acrobat Reader Flaw Amid Active Exploits
  • ISBuzz Team
    Curl Security Alert: Patching A Critical Bug Averting Potential Cyber Catastrophe

The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.

Share. Facebook Twitter LinkedIn Email Copy Link

Related Posts

The Real Cost of Inconsistent Third-Party Access

December 18, 20255 Mins Read

What Happens When Devices Cross Borders? The Role of Geofencing in Global IT

August 7, 20256 Mins Read

The Evolving Importance of Identity Governance in FinTech

July 10, 20258 Mins Read
ISB-Bora-Side-Bar

No se ha podido establecer conexión. Error 429

 
ISB-Bora-Side-Bar
Black ISB Logo

Information Security Buzz is an independent resource that provides the experts’ comments, analysis, and opinion on the latest Cybersecurity news and topics

X (Twitter) LinkedIn Facebook RSS

Working With Us

  • About Us
  • Advertise With Us
  • Contact Us

Write For Us

  • How To Contribute

The Pages

  • Privacy Policy
  • Cookie Policy
  • AI Policy
  • Terms & Conditions
  • Copyright Notice

Information Security Buzz and all its contents are copyright © 2014-2025. All rights reserved. All third-party trademarks are recognized.

Type above and press Enter to search. Press Esc to cancel.

Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}