Vulnerability scanning vs. penetration testing: What’s the difference?

Vulnerability scanning vs. penetration testing: What’s the difference?

Your company’s security program is only as strong as its weakest link. At some point, you’ll have to ensure that the security protocols and tools you’ve established actually do their job. This is where vulnerability scanning and penetration testing come into play. 

Although they sound similar, their applications and purposes aren’t the same. Since you’ll likely need both to hit compliance goals, it’s important to understand the differences between vulnerability scanning vs. penetration testing. 

What is vulnerability scanning?

As your company continues to grow, your applications and tools are sure to evolve. This can leave your company exposed to a number of risks. Vulnerability scanning is a continuous security measure that safeguards your company’s infrastructure from internal and external threats. 

Vulnerability scans help you locate specific gaps in your security system, such as missing patches, outdated applications, or faulty firewalls. If a scan reports anything suspicious, you’ll be able to mitigate any issues before they become too serious. 

How does vulnerability scanning work? 

Vulnerability scanning is an automated process that is specifically configured to monitor certain aspects of your system. Companies can outsource scans to a third-party or purchase certain scanning tools—such as AWS Inspector—based on their cloud environment. Scanning tools run internal or external high-level diagnostics that produce a summary or report of any gaps in your system. 

When should you use vulnerability scanning?

Vulnerability scanning is known as an essential component of any strong infosec program, however; auditors can request vulnerability reports to use as evidence when considering compliance certifications. 

This evidence is commonly used to satisfy compliance requirements within frameworks such as ISO 27001, PCI DSS,  and SOC 2. For instance, the evaluation of vulnerabilities is specifically cited in ISO 27001 requirements.

A.12.6.1 – Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.

Vulnerability scans should be conducted as frequently as possibly, leaving few gaps for bad actors to maliciously intervene. 

What is penetration testing?

Vulnerability scans identify weaknesses in your security program, but penetration tests purposefully exploit them. Penetration tests are typically executed by a third-party organization that specializes in security and compliance.  Your company’s network, applications, APIs, and cloud environments can all be tested. 

Once weaknesses have been exposed with a vulnerability scan, a penetration test is used to simulate how your system responds as if a real malicious incident were to occur. The professional conducting a penetration test will subject your infrastructure to the same kinds of attacks as a hacker. This intentional pressure test enables you to evaluate your security system, strengthen weaknesses, and fortify defenses. 

How does penetration testing work?

One significant difference between vulnerability scanning vs. penetration testing is how they're each performed. Penetration tests are usually not automated, but instead conducted by a real IT professional. Sometimes known as “ethical hackers,” penetration testers will go through a lengthy process when evaluating your company’s infrastructure. 

There are automated tools available, but this method defeats the purpose of simulating an authentic assault on your company’s defenses. After the test, you’ll receive an in-depth analysis of any exploitable weaknesses in your system and how you can patch them. 

When should you use penetration testing? 

Organizations typically seek penetration tests as part of the compliance process. For instance, a penetration test is specifically mentioned as a control to fulfill the necessary SOC 2 requirements. According to the State of Startup Security Report, 60% of small organizations do penetration testing at least annually.

CC4.1 – Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certifications made against established specifications (for example, ISO certifications), and internal audit assessments.

Penetration tests are usually conducted less frequently than vulnerability scans. Many security experts recommend an annual penetration test which also coincides with some compliance requirements. 

Learn more about how to protect your company

Five Principles For Building a Secure Product

The security for SaaS CTO checklist

Security Reviews for Startups

Written by
No items found.
Access Review Stage Content / Functionality
Across all stages
  • Easily create and save a new access review at a point in time
  • View detailed audit evidence of historical access reviews
Setup access review procedures
  • Define a global access review procedure that stakeholders can follow, ensuring consistency and mitigation of human error in reviews
  • Set your access review frequency (monthly, quarterly, etc.) and working period/deadlines
Consolidate account access data from systems
  • Integrate systems using dozens of pre-built integrations, or “connectors”. System account and HRIS data is pulled into Vanta.
  • Upcoming integrations include Zoom and Intercom (account access), and Personio (HRIS)
  • Upload access files from non-integrated systems
  • View and select systems in-scope for the review
Review, approve, and deny user access
  • Select the appropriate systems reviewer and due date
  • Get automatic notifications and reminders to systems reviewer of deadlines
  • Automatic flagging of “risky” employee accounts that have been terminated or switched departments
  • Intuitive interface to see all accounts with access, account accept/deny buttons, and notes section
  • Track progress of individual systems access reviews and see accounts that need to be removed or have access modified
  • Bulk sort, filter, and alter accounts based on account roles and employee title
Assign remediation tasks to system owners
  • Built-in remediation workflow for reviewers to request access changes and for admin to view and manage requests
  • Optional task tracker integration to create tickets for any access changes and provide visibility to the status of tickets and remediation
Verify changes to access
  • Focused view of accounts flagged for access changes for easy tracking and management
  • Automated evidence of remediation completion displayed for integrated systems
  • Manual evidence of remediation can be uploaded for non-integrated systems
Report and re-evaluate results
  • Auditor can log into Vanta to see history of all completed access reviews
  • Internals can see status of reviews in progress and also historical review detail

The ultimate guide to scaling your compliance program

Learn how to scale, manage, and optimize alongside your business goals.

PCI Compliance Selection Guide

Determine Your PCI Compliance Level

If your organization processes, stores, or transmits cardholder data, you must comply with the Payment Card Industry Data Security Standard (PCI DSS), a global mandate created by major credit card companies. Compliance is mandatory for any business that accepts credit card payments.

When establishing strategies for implementing and maintaining PCI compliance, your organization needs to understand what constitutes a Merchant or Service Provider, and whether a Self Assessment Questionnaire (SAQ) or Report on Compliance (ROC) is most applicable to your business.

Answer a few short questions and we’ll help identify your compliance level.


Does your business offer services to customers who are interested in your level of PCI compliance?


Identify your PCI SAQ or ROC level

The PCI Security Standards Council has established the below criteria for Merchant and Service Provider validation. Use these descriptions to help determine the SAQ or ROC that best applies to your organization.

Good news! Vanta supports all of the following compliance levels:


A SAQ A is required for Merchants that do not require the physical presence of a credit card (like an eCommerce, mail, or telephone purchase). This means that the Merchant’s business has fully outsourced all cardholder data processing to PCI DSS compliant third party Service Providers, with no electronic storage, processing, or transmission of any cardholder data on the Merchant’s system or premises.

Get PCI DSS certified


A SAQ A-EP is similar to a SAQ A, but is a requirement for Merchants that don't receive cardholder data, but control how cardholder data is redirected to a PCI DSS validated third-party payment processor.

Learn more about eCommerce PCI

for service providers

A SAQ D includes over 200 requirements and covers the entirety of PCI DSS compliance. If you are a Service Provider, a SAQ D is the only SAQ you’re eligible to complete.

Use our PCI checklist

Level 1 for service providers

A Report on Compliance (ROC) is an annual assessment that determines your organization’s ability to protect cardholder data. If you’re a Merchant that processes over six million transactions annually or a Service Provider that processes more than 300,000 transactions annually, your organization is responsible for both a ROC and an Attestation of Compliance (AOC).

Automate your ROC and AOC

Download this checklist for easy reference


Learn more about how Vanta can help. You can also find information on PCI compliance levels at the PCI Security Standards Council website or by contacting your payment processing partner.

The compliance news you need. Delivered securely to your inbox.

Subject to Vanta's Privacy Policy, you agree to allow Vanta to contact you via the email provided for marketing and other purposes