<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1977396509252409&amp;ev=PageView&amp;noscript=1">
Contact a Specialist
Industry Solutions
Industry Solutions
Cloud Computing & Data Centers
Cloud Computing & Data Centers
Financial Services & Fintech
Financial Services & Fintech
Healthcare
Healthcare
Payment Card Processing
Payment Card Processing
US Government
US Government
Learning Center
Learning Center
Articles
Articles
Whitepapers
Whitepapers
Case Studies
Case Studies
Events & Live Webinars
Events & Live Webinars
On-Demand Webinars
On-Demand Webinars
Compliance Reliance
Compliance Reliance
About Us
About Us
Leadership Team
Leadership Team
Careers
Careers
Corporate Social Responsibility
Corporate Social Responsibility
MATT WILGUS

By: MATT WILGUS on May 18th, 2015

Print/Save as PDF

Frequency of Vulnerability Scans for PCI DSS

BrightLine Responds


Q: We are a SaaS provider that follows a Scrum methodology, generally with two-week sprints. We do not handle cardholder data, but several clients are requiring vulnerability scans to show compliance to the PCI DSS standard.

 

How often do we need to run vulnerability scans against our product?

 

A: Many software providers are being required to be PCI compliant due to contractual requirements and/or because their application may be on the same network as PCI in scope systems, even though it may not store, process, or transmit cardholder data.

The 11.2 requirement of the PCI DSS requires vulnerability scans at least quarterly and after any significant change in the network and includes examples such as new system component installations and product upgrades. The Product Owner can likely determine whether changes to the product are a minor update, which likely wouldn’t mandate a vulnerability scan, or a major update, which likely would. A major update may include the migration to a new version of the development framework (e.g. moving from Rails 3.x to 4.x), or a critical piece of the application such as the authentication components. The 11.2 requirement focuses on detecting flaws at the application and network layers, but isn’t meant to be code scanning, which is covered more in Requirement 6: Develop and maintain secure systems and applications.

That being said, the higher the frequency of vulnerability scanning, the timelier the results will be and it is often easier to incorporate the results of the scan into the development life cycle.

Some organizations, particularly larger organizations, will continuously conduct vulnerability scans, often unannounced. There are benefits to aligning scan schedules with the two-week sprints, or perform monthly, which is generally more in-line with vendor patch updates. Either way, organizations that scan on a more frequent basis than quarterly tend to have an easier time achieving clean scan results. Additionally, limiting your scans to run on a quarterly basis increases the risk that a fix doesn’t get into the backlog in time.

About MATT WILGUS

Matt Wilgus is a Principal at Schellman, where he heads the delivery of Schellman’s penetration testing services related to FedRAMP and PCI assessments, as well as other regulatory and compliance programs. Matt has over 20 years’ experience in information security, with a focus on identifying, exploiting and remediating vulnerabilities. In addition, he has vast experience enhancing client security programs while effectively meeting compliance requirements. Matt has a strong background in network and application penetration testing, although over the past 10 years most of his focus has been on the application side, with extensive experience testing some of the most well-known IaaS, PaaS and SaaS providers.