Ultimate Guide to PCI Compliance for SaaS Companies

While we talk a lot about governmental cybersecurity here on the Ignyte blog, programs like FedRAMP and CMMC are not the most common kind of security you’re likely to encounter. That honor goes to PCI DSS.

PCI DSS is a security framework we all engage with on a near-daily basis. It’s the security framework used around the world to secure payment card information, and it’s extremely important for trust, safety, and the security of customer information.

As a SaaS company, what do you need to do to implement PCI DSS? We’ve put together this guide to help you out each step of the way.

What is PCI DSS and What Does It Involve?

First, a quick review of the basics for those of you new to the SaaS world.

PCI is the Payment Card Industry set of standards. It’s actually not just one standard, but a whole ecosystem of related standards, different aspects of which apply to different components of the world of commerce.

For example, payment card issuers like credit card companies need to adhere to PCI standards surrounding card production and token management. Vendors and merchants, as well as processors, need to adhere to other standards, like those surrounding PIN security, point-to-point encryption, and contactless payment security.

All of this is created, maintained, and managed by the PCI Security Standards Council. The council is made up of members from the five major credit card networks: Visa, Mastercard, JCB, Amex, and Discover. The aim is to unify security for the protection of everyone using a credit card, so “data security” is not a concern when it comes to picking a provider.

PCI DSS is, specifically, the Payment Card Industry Data Security Standard. Currently, the standard is on version 4.0.1, released mid-2024.

Broadly, PCI DSS is divided into 12 core requirements to secure payment card data. We’ll cover those in detail in a later section.

Unlike frameworks like FedRAMP or ISO 27001, PCI DSS is not a certification. You don’t implement, undergo an audit, and earn a certificate.

Instead, PCI DSS is a continual process of security awareness and improvement. On an ongoing basis, you must maintain an inventory of data handling processes and systems, monitor for vulnerabilities, proactively fix them, and report all of this. The more directly you handle credit card information, the stricter the requirements for reporting will be.

There are, however, still overviews and audits involved in PCI DSS. PCI requires at least annual self-reporting and overviews by Qualified Security Assessors, who validate your results.

Who Needs to Implement PCI DSS?

PCI DSS is required for anyone who handles credit cards. If you accept credit card payments for your SaaS business, you need to comply with PCI DSS standards. It doesn’t matter where in the world you’re headquartered, how much or little information you handle, or what other payment options you offer.

One area where SaaS companies often get in trouble is assuming that using a third-party payment processor offloads the responsibility to that processor. While it’s true that most of the work is out of your hands, you still need to be aware of PCI DSS rules and how you need to comply.

Critically, PCI DSS is not enforced by law. There’s no item in the federal register that mandates using it. Instead, it’s a universal part of the contracts you sign when you create a merchant account with a credit card company. By accepting credit card payments, you agree to comply with PCI DSS.

Failure to comply carries steep penalties. You face significant fines, compensation for data breaches, exposure to legal action, reputational damage, and more.

What Tasks Do You Need to Handle to Implement PCI DSS?

The specific array of tasks you need to complete, either once or on an ongoing basis, will vary depending on how much interaction you have with credit card information. You may be able to implement basic security on a limited scope of systems, file annual self-assessments, and be good to go. Or, you might need to establish and prove ongoing continuous monitoring, undergo quarterly audits, submit to penetration testing, and more.

There’s a lot of ground to cover. SaaS companies need to think about:

• Company network firewalls
• Encrypted transmission of cardholder information
• Access restrictions to systems that handle or store cardholder information
• General information security
• General access control
• Access logging and monitoring
• Ongoing testing, scanning, and evaluation of systems
• Cloud system logging and monitoring
• Data classification and information tagging

Understanding what you need to do is the hardest part of PCI DSS compliance.

In general, the amount of cardholder data you directly handle determines how much you need to do.

SaaS companies that use exclusively tokenization to handle payments need to comply with PCI DSS at a very limited scope. Tokens and networks need to be secured, but much of the burden is relieved.

SaaS companies using third-party checkout systems like Stripe or PayPal likewise need to be secured appropriately. You need to ensure cardholder information doesn’t enter your systems, and you need to self-report with questionnaires annually, but many of the requirements are out of scope.

SaaS companies that store or handle card data directly need to adhere to full compliance with PCI DSS.

The General Process of PCI Compliance

Before getting into the specific domains, we can talk about the overall process you’ll need to follow. This applies to any SaaS company.

1: Scoping. The first thing you’ll need to do is figure out your scope. Map out your entire network and data flow. What payment information touches your systems, and how? Anything that interacts with cardholder data in any way, whether it’s an environment, a pipeline, an analytics tool, a container, or anything else, if cardholder data can touch it, it needs to be in scope.

One of the main goals of scoping is to figure out where you can draw boundaries and how you can change your systems to exclude more, so you only need to secure the barest minimum. The larger your systems and the more you need to secure, the larger a threat surface you present and the more work you need to do.

2: Learning. Before you can get to work, you need to know what work needs to be done. Review the 12 domains and specific controls that are part of PCI DSS, and figure out which ones apply to your scope. For some SaaS businesses, it will be a limited number; for others, it will be all of them.

3: Gap Analysis. You have your target, now you analyze where your current security posture puts you, and what you need to do to reach your target. This is where a firm map of the 12 domains and your scope is critical.

4: Implementation. Your gap analysis gives you the list of tasks you need to complete; now, complete them. Whether it’s adding MFA, deploying encryption, implementing logging, or adding vulnerability scanning, get it done.

5: Document and Validate. As with any security framework, documentation is required. From company policies to audit logs and scan results, you need documentation to prove your security posture.

A huge part of PCI DSS is the ongoing reporting cycle, so get used to maintaining and filing the paperwork as necessary.

6: Scanning and Auditing. Internal scans and audits help you validate your implementation and provide proof of your security posture. This can then be part of your Self-Assessment Questionnaire, along with your Attestation of Compliance and any other supporting information.

There are 8 types of SAQs, and the one you use depends on your type of business. For SaaS, you’re likely to need either:

• SAQ A, which is for ecommerce or mail order/telephone order merchants that outsource payment processing.
• SAQ A-EP, which is for the same kinds of businesses that outsource payment processing, except for an account data page.
• SAQ D, which is the catch-all “needs an SAQ but doesn’t fit in another category” type.

7: External Audits. Your “final” step of the process, for some SaaS businesses, will be an external audit conducted by a QSA. This will be a more thorough and validated review of your security to make sure you didn’t miss anything or have anything implemented incorrectly. If all was done well, you’ll be PCI compliant and can carry on business.

Many, even most, SaaS firms won’t need an external audit. They are generally only necessary for merchants that handle more than 6,000,000 transactions annually, for high-volume service providers, or if you’ve suffered a data breach. Ideally, if you’re handling that many transactions, you already are deeply familiar with PCI DSS compliance.

How Long Does PCI DSS Compliance Take?

Now that you see what is involved in PCI DSS compliance, you might wonder just how long it will take. The answer is: it depends. The larger and more complex your business, the more you’ll need to do, and the longer it will take.

The simplest SaaS small businesses can achieve PCI compliance in just a few weeks of concerted effort. On the other hand, firms with poor buy-in, complex systems, bad scoping, and other issues can struggle for a year or longer.

On average, though, you should expect 4-6 months to cover all of your bases properly.

The 12 Domains of PCI DSS Compliance

PCI DSS has a core document available in their document library, which is a PDF with 400+ pages of information. Fortunately, not all of it applies to every company, but knowing what you need to do is critical. As a SaaS company, you will have specific tasks and concerns to be aware of as you implement security across the 12 domains.

Let’s cover those 12 domains and what you need to do. Be aware that this is fairly generalized, however. If you need more specific information, you can contact us or seek out a PCI DSS expert to work with for your company’s security.

Domain 1: Network Security

The first domain is all about technical security controls that monitor and restrict access to your networks.

You will need to:

• Install and configure firewalls.
• Implement network security controls at network borders.
• Segment environments to limit scope and secure cardholder environments.
• Control both inbound and outbound traffic.
• Document traffic control rules.
• Review, test, and validate configurations and implementations.
• Implement active monitoring of all traffic to watch for unauthorized access.

This is the digital equivalent of having a well-trained bouncer ensuring only verified and trusted individuals can access sensitive areas.

Domain 2: Secure Configurations

The modern digital world is made up of many thousands of off-the-shelf or pre-configured modules, systems, applets, containers, and other elements, put together into cohesive wholes.

The issue PCI identified is that all of these come with base, default configurations, and those configurations may not be appropriate.

Therefore, they made an entire domain specifically around making sure you customize the settings and configurations for all of these modules. Every component needs to be reviewed, defaults removed or changed as necessary, and weaknesses fixed.

• Disable any unnecessary services, protocols, ports, or other modules.
• Remove any default accounts or, if you can’t, secure their credentials.
• Define company-specific baselines for all system configurations.
• Review all configurations when their modules change or are updated.
• Implement active monitoring to watch for drift.

Since any misconfiguration can be an avenue an attacker can use, this is a critical element of security.

Domain 3: Protect Stored Data

A big part of scoping is determining how much data you actually touch, and what kind of data it is. If you touch, handle, store, forward, or otherwise process cardholder data in any way, it must be protected. Store it only for as long as is necessary, do as little as necessary as you can with it, ensure that it’s encrypted, and so on.

For SaaS businesses that outsource their payment processing and don’t handle cardholder data at all, you’ll have very little to do for this domain. If you handle that data at all, even for the briefest moment, you’ll need full compliance.

Domain 4: In-Transit Data Protection

Data isn’t just stored; it moves. When it’s given to you by a customer and when you forward it on, it needs to be secured. TLS encryption is the usual standard for this.

You will also need to make sure you don’t have outdated encryption protocols in place, you have secure key management, and you monitor traffic for unusual use.

Domain 5: Malware Protection

Viruses, worms, cryptolockers, phishing apps, keyloggers; malicious software is everywhere. You need to ensure that your systems are secured against malware, using anti-malware and antivirus software and routine scans, as well as active traffic and file integrity monitoring.

Make sure action is taken swiftly in the event of anything suspicious, and keep your malware libraries and definitions up to date.

Domain 6: Secure Development

If your SaaS business is doing any custom development, anything you produce must be secure. For some businesses, using combinations of off-the-shelf modules and APIs, you won’t have much to do. For others, where your primary offering is custom-developed, you will absolutely need a deep and thorough review of your code base to ensure security.

This is especially important today, as AI systems open up all new realms of exploitation, from hallucinated dependencies that are taken over by attackers, to code with security flaws or bugs that aren’t caught. This must be taken extremely seriously to protect cardholder data.

Domain 7: Access Restriction

Any system that touches cardholder data in any way needs to be heavily restricted using the principle of least access. Only the people who directly need access to those systems for the function of your business should be allowed to have it, their access should be monitored, and as soon as they no longer need access, it should be removed.

The more accounts that have access to a system, the more vectors there are for an attack.

Domain 8: User Access Authentication

The biggest source of data breaches is not card skimming, man-in-the-middle, brute forcing, or malware. It’s phishing. Social engineering that convinces an employee with access to share their credentials allows those credentials to be used against the company. Access control helps minimize this, but someone, somewhere, will need access and thus be a potential target.

User authentication and specific monitoring allow you to check for unauthorized access even on authorized accounts, and prevent compromised accounts from doing any damage before they’re caught.

Domain 9: Physical Access Control

SaaS businesses don’t necessarily have their own physical locations where data is stored, but sooner or later, there will be that physical storage, because that’s how computers work.

If your business operates entirely out of AWS buckets or Azure Blobs, the burden is on Amazon or Microsoft for physical security. If you have your own server room, that room must have physical security and access control.

Domain 10: Access Logging and Monitoring

Any time “access logging” or “activity monitoring” is mentioned in another domain, the definition of what that means specifically is in domain 10. Log system access, log user activity, track access, and so on.

Critically, this domain also includes log integrity. Make sure logs can’t be altered or otherwise damaged or destroyed in the event of a compromise.

Domain 11: Testing

Everything in all of the PCI DSS domains requires testing and validation. Whether that’s automated vulnerability scanning, penetration testing, or QSA auditing, it depends on your business and scope.

Some components need daily review, others need annual testing, but it all needs to be verified at some point.

Domain 12: Policy

The final domain is how everything in the previous 11 domains is institutionalized via company policy. This is the text in your contracts, the information in your employee handbooks, your employee onboarding and training, and everything else.

All of this will be reviewed in any audit you conduct and must be consistent with requirements and implementation.

Ensuring PCI DSS Compliance for SaaS Businesses

SaaS businesses often have a few advantages when it comes to PCI DSS compliance. Several domains are of limited or no relevance, and others may be very easy to implement. Even so, it’s worth using a centralized platform to help you keep track of every one of the hundreds of controls, their documentation, implementation status, and validation.

This is where we can help. The Ignyte Assurance Platform was built for highly reviewed and stringent governmental security frameworks, so we can handle PCI DSS no problem. To see how it can work for you, drop us a line to book a demo and have a chat about your company’s unique needs.