PCI Compliance Facts

The Payment Card Industry Data Security Standard (PCI DSS) has been in effect since the early 2000s. PCI compliance is essential to protect sensitive cardholder data and reduce the risk of security breaches that could harm customers and your business. It also helps you meet legal, financial, and contractual obligations required by credit card brands and processors.

However, many business overlook some key aspects of PCI compliance that increase their vulnerability. Here are six things to keep in mind as you move toward or evaluate your own PCI DSS compliance. Even though you don’t process cards directly, you could still fail the approved scanning vendor (ASV) scan because your public-facing systems are vulnerable.

PCI DSS is about protecting the whole environment around card activities, not just the direct flow of cardholder data.

6 Quick Tips to Keep Cardholder Data Safer

1. Secure the Entire Environment
   • Secure everything in the Cardholder Data Environment (CDE)
   • Use HTTPS everywhere
   • Update and maintain SSL/TLS certificates
2. Patch and Update Regularly
   • Patch servers, applications, and plugins, apply security patches within 30 days of release wherever possible
   • Monitor and update CMS platforms (e.g., WordPress, Joomla, etc.) regularly.
   • Remove outdated software
   • Eliminate old plugins, themes, or test apps not actively used
3. Secure Cardholder Data and Authentication
   • Enforce two-factor authentication (2FA) for all remote access to CDE systems
   • Test two-factor authentication periodically to ensure it’s functioning properly
   • Use tokenization for sensitive card data
4. Harden Public-Facing Systems (Websites, Servers)
   • Remove unused public-facing test pages or admin panels
   • Disable directory browsing
5. Manage Third-Party Access Carefully
   • Limit third-party vendor access
   • Audit third-party connections
6. Know and Control Your Data Storage
   • Identify where cardholder data is stored
   • Ensure no unnecessary storage of Sensitive Authentication Data (SAD) like CVV codes or full magnetic stripe data

PCI DSS 4.0 Changes

While redirecting customers to a payment processor may exempt you from certain PCI security measures, under new guidance you may now be required to comply with quarterly security scans. It’s important to note that even if you’re not handling payments on your website, your website might be a target. Attackers may inject malicious scripts (e.g., Magecart attacks) into your site or intercept the redirection process—allowing them to steal payment data before it reaches the processor. PCI DSS version 4.0 introduced these new security measures to protect consumers from malicious redirects.

What is a Redirect?

Here’s how PCI Security Standards Council explains it (and how PCI DSS treats it):

• A true redirect (under PCI DSS) means your website actively sends the customer’s browser to another page automatically — without the customer needing to click anything.
  • Example: An HTTP 30x server-side redirect, or JavaScript that forces the browser to jump to another URL.
  • User doesn’t have a choice.
• A plain hyperlink (a normal <a href="https://paymentprocessor.com">Pay Here</a>) just offers a link is not generally considered a redirect. The customer has to click it.
  • That means your site isn’t controlling the redirection — the user is.
  • This is treated much more like simply “navigating away” — not an automatic redirect.

Do I need a Scan?

Even if you only link to a payment processor, an approved scanning vendor (ASV) may still scan your public website because:

• It’s on the internet (public-facing = “reachable by IP or domain from the outside world”).
• Hackers could attack your site and use it as a stepping stone (e.g., to inject skimmers, redirect customers, or hijack traffic).
• PCI DSS cares about the entire security posture of systems that interact with payment activities — even indirectly.

The onus ultimately falls on the customer. Therefore, it may behoove you to be overly cautious and get the scans rather than assume that everything is kosher. For more information, you can check out the Scan Scope in the ASV guide, section 5.5.

Hiring a Security Firm for PCI ASV Vulnerability Scans

To ensure that your website / server are safe and secure for customer transaction, you must hire a PCI-certified security firm to scan for malicious code. An approved scanning vendor, or ASV, is a company with PCI-approved security tools used to perform external scans required by PCI DSS Requirement 11.3.2. Their scanning solution must be tested and approved by the PCI Security Standards Council before they are officially recognized. These scans must identify vulnerabilities from outside the organization’s network (like over the internet) to ensure that systems exposed to the public (e.g., websites, firewalls) are secure.

In simpler terms:

• Scans occur every 90 days, plus after major changes (like server moves or firewall rule updates).
• You must have an outside PCI-approved company scan your internet-facing systems.
• ASV scans exist to check for security holes that hackers could exploit.

Important:

• The scans must pass (no high vulnerabilities allowed).
• The scans must be performed by an official ASV (not just any IT company).
• You cannot perform your own scans.
• If you fail, you have to fix the issues and rescan until you pass.

They are scanning for vulnerabilities that could:

• Allow hackers to inject malicious scripts (like Magecart attacks)
• Redirect customers to fake payment pages
• Take over your domain to impersonate you
• Harvest information that would weaken the security of your payment process indirectly

What does the ASV Scan Entail?

When you hire an ASV to scan your website / server for PCI vulnerabilities, here’s what to expect.

1. Scoping

• Objective: Define the scope of the external vulnerability scan.

You will give the ASV a list of public-facing IP addresses, domains, and websites that belong to you.
(Even if you only link to a payment processor, your website itself is still Internet-facing and must be scanned.) The scope is then verified by the ASV.

2. Scanning

• Objective: Conduct the external vulnerability scan.

The scan usually starts a few days after scope approval. It identifies vulnerabilities and misconfigurations in the Internet-facing systems. The ASV should Ensure that the scan does not disrupt normal operations or compromise system integrity.​ Here are a few of the items they look for:

• Open ports you don’t need (like FTP, telnet, older web ports).
• Outdated software (WordPress plugins, server versions, etc.).
• SSL/TLS vulnerabilities (like weak ciphers, expired certificates).
• Known vulnerabilities (e.g., vulnerabilities in Apache, nginx, WordPress core, etc.).

3. Reporting

• Objective: Rectify any vulnerabilities found during the scan.

Once the scan is complete, you’ll get a report with vulnerabilities listed by severity:

• High (must be fixed to pass)
• Medium
• Low
• Informational (do not impact compliance)

To pass, you must have no High vulnerabilities and usually no severe Mediums either. Once you pass, you’ll receive a passing Scan Report and an Attestation of Scan Compliance (AOSC) (official PCI paperwork). You submit this paperwork to your acquiring bank, processor, or PCI program manager — not directly to PCI SSC.

If you fail, they will give you a chance to fix the issues and request a free rescan (typically 1–2 rescans included). “With a few exceptions, any vulnerability with a CVSS base score of 4.0 or higher will result in a non-compliant scan report, and all such vulnerabilities must be remediated by the scan customer.”

What if I Disagree with My ASV?

The ASV you hire is the only one who can issue your “Pass” or “Fail” result for PCI DSS Requirement 11.3.2. If they say you failed, you failed, even if you believe they made a mistake — unless you successfully dispute it through their formal process. You can’t just get a second opinion from a different ASV for the same scan window. You must fix the findings they reported or formally appeal their decision.

PCI DSS relies on the idea of independent validation — meaning you can’t “shop around” for a better result once an official ASV has performed a scan. The ASV must follow very strict PCI SSC scanning procedures — they are audited themselves. Allowing merchants to argue or hop between ASVs easily would undermine the integrity of the system. Common causes of failure even for redirecting merchants might include weak TLS settings (SSL issues) or outdated plugins on CMSs like WordPress. This is where it helps if you have a security-minded hosting partner for your website. While this doesn’t guarantee the server is PCI compliant, it should provide assurance that your site is up-to-date on security features and you have someone who knows what they are talking about in your corner should you need to dispute a failure on an ASV report.

How to Dispute a Finding

Request a False Positive Review:

• Most ASVs have a documented “false positive dispute” process.
• You provide evidence (like vendor documentation, CVE clarifications, or patch info) proving their finding is invalid.
• They review and, if they agree, they may reclassify the vulnerability (so you can pass).

Fix it anyway:

• Even if you disagree, sometimes it’s faster to apply a patch, reconfigure, or mitigate and then ask for a rescan.

Change ASVs — later:

• After your scan period is complete (and no pending disputes), you can change vendors for the next quarter.
• You cannot switch mid-scan just because you disagree with the findings.

In Conclusion

Many of our clients don’t use redirects and don’t store/process card data. Therefore, their risk surface is small, meaning scans are usually fast. Vulnerabilities, if any, will likely be web server configurations (not payment-related) or forgotten test pages. It is important to remember at the end of the day it is up to the judgment of the ASV as to whether the client passes or fails the quarterly scan.

CourseVector does offer PCI compliant servers. If you’ve hired an ASV or otherwise need a PCI compliant server, please contact us.

Remember that if you want extra help with PCI compliance (like someone guiding you through the SAQ or explaining vulnerabilities),

• Hire a separate PCI consultant, or
• Use an ASV vendor that offers optional (separate) advisory services through a different division.