PCI Compliance: A Guide to Meeting Today’s Requirements

Achieving PCI Compliance in 2026

In the ecommerce world, businesses face countless unique challenges and unknowns. But, there’s one journey every online business has to take the moment they decide to accept credit card data online: Compliance with the Payment Card Industry Data Security Standard (PCI DSS).

PCI compliance isn’t something most businesses look forward to, but it’s also one of the most important elements of running an online business. Without up-to-date PCI compliance in place, you’re leaving every piece of data that runs through a payment processor at the mercy of bad actors. (No, not like Steven Seagal. The other kind of bad actors.)

No company is too big to be exempt from risk, either:

• In 2025, Under Armour saw 343 gigabytes of sensitive data get exposed via ransomware, and is now facing a class action lawsuit.

• Warby Parker was hit with a $1.5M penalty in 2025 for a breach that also violated HIPAA regulations.

• ManoMano, a major home improvement ecommerce business, was impacted by a breach that compromised the records of 38M customers.

The above cases could have been even worse, had the companies in question not followed PCI-compliant practices with payment gateways and handling of customer data. Keep in mind each of the above companies is also sizable, with the in-house resources to react quickly.

No matter the size of your company, it’s critical you do what you can to protect your customers. And fortunately, you can.

Before covering the 12 primary requirements of PCI compliance, let’s take a closer look at PCI compliance, who needs to follow it, and most importantly: how you can keep your customers safe.

What is PCI compliance?

PCI Compliance consists of numerous standards set forth by the PCI Security Standards Council (PCI SSC), all of which work toward ensuring customer data is kept safe by businesses accepting credit card payments.

The guidelines that make up PCI Compliance are known as the Payment Card Industry Data Security Standard (PCI DSS). Within the PCI DSS are different subsets of rules that apply to different businesses, determined via various PCI compliance self-assessment questionnaires (SAQ), like SAQ A or SAQ D. (More on this later.)

Who created and enforces the PCI DSS?

PCI DSS was established by the PCI SSC in 2004 as a way to protect consumer information. Over time, the PCI DSS has evolved, taking into consideration the rise of ecommerce, digital payments, and hybrid models.

While PCI SSC created the PCI DSS, enforcement is up to the actual card brands, like Visa, Mastercard, JCB, American Express, and so on. These major cards then have an agreement with a financial institution, who will then ensure PCI DSS is followed by your ecommerce business.

What counts as cardholder data?

Cardholder data is one of the primary reasons for PCI DSS, as it contains sensitive information and it’s commonly stored. (As long as the retailer is compliant.)

Cardholder data includes either the Primary Account Number (PAN), or the PAN along with any of the following:

• Cardholder’s name: The holder’s entire name as it appears on the card.

• Card expiration date: The month and year in which the card expires.

• Service code: A 3 - 4 digit number within the magnetic strip.

There’s also Sensitive Authentication Data (SAD), which is another set of data for transaction authorization. Where cardholder data may be safely stored, SAD may never be stored.

Who needs to be PCI compliant?

PCI Compliance requirements are fairly straightforward: If you process, store, or transmit credit cards and related cardholder data, you need to follow the PCI DSS.

Going deeper, there are four levels of compliance, each one requiring different amounts of validation, applying to different businesses. Your level depends primarily on your transaction volume across every channel, and determines if you need to have a qualified security assessor complete your validation or if you can use a SAQ.

Do SaaS merchants still need to comply?

Simply put: Yes, SaaS merchants need to follow PCI DSS if they handle cardholder data. (Which is most SaaS organizations, unless you take payment only by check.)

Compliance is still in play if you’re an ecommerce business using a SaaS platform as well, but with a caveat. For instance, if you’re using an ecommerce platform, like BigCommerce, or a payment provider like PayPal, the burden is lessened as these platforms are compliant.

BUT, you still need to complete an SAQ and receive an attestation of compliance, it will simply be easier than if you’re running your own open-source payment gateway and trying to do it all on your own.

Why transaction volume is aggregated across channels.

It’s worth calling out that transaction volume is aggregated across all your channels. And, for good reason: The bigger your footprint, the bigger your risk.

For example, say you run a brick-and-mortar that gets a handful of sales each day. But, you also have an online store that drives thousands of sales every month. While your brick-and-mortar poses a smaller security risk, your business as a whole still processes thousands of cards each month and should be held to PCI DSS requirements that match.

PCI compliance levels explained

There are four levels to PCI compliance, with varying requirements that depend on the scale of your business.

Also worth noting that level definitions can change depending on the card brand. For example, Visa doesn’t recognize a level 4, but instead has a level 3 distinction for businesses with more than one-million transactions.

What happens to your level after a breach.

Regardless of your current level, a breach can result in your being escalated to level 1. This will then entail a costly on-site audit and your brand having to stick to level 1 standards until you’re reassessed.

Note: Non-compliance with your current level can also result in your company getting moved up a level, or to level 1.

The 12 PCI DSS requirements (compliance checklist)

If you’re going with a SaaS solution that follows PCI Compliance, you’ll have to handle all 12 PCI DSS requirements yourself. But, even if you go with a compliant platform or payment gateway, it’s still a good idea to be aware of these requirements regardless.

The 6 PCI DSS goals at a glance.

When viewed as a whole, PCI DSS and PCI Compliance seem complicated. (He said, to the shock of nobody.)

Before diving into the 12 PCI DSS requirements, it’s helpful to understand the core six goals of these standards:

• Build a secure network (and keep it going)

• Protect account data

• Manage vulnerabilities

• Establish strong access control

• Monitor and test networks

• Create and maintain an information security policy

In other words, every requirement of PCI DSS plays a role in properly handling cardholder data, and securing it for the long term.

Now, what do these requirements look like?

1. Safeguard cardholder data by implementing and maintaining a firewall.

First up is the task of establishing a strong defense by way of firewall.

You can do this by:

1. Positioning firewalls to only allow necessary traffic to enter your CDE.

2. Having a “deny all” rule for all other inbound and outbound traffic.

3. Dynamic packet filtering.

4. Creating a secure zone for any card data storage.

5. Ensuring all outbound connections from your CDE are explicitly authorized.

6. Installing a firewall between wireless networks and your CDE.

7. Documenting all firewall policies and procedures, including business justifications for each port or protocol allowed through firewalls.

2. Create custom passwords and other unique security measures rather than using the default setting from your vendor-supplied systems.

“Password” or “1234” aren’t clever or unique, they’re just plain bad. For step two, we’re ensuring your passwords and security measures are unique and strong, like a signature beverage.

Establish the right security measures by:

1. Maintaining an inventory of all hardware and software used in the CDE.

2. Assigning a system administrator to be responsible for configuring system components.

3. Implementing a system configuration and hardening guide that covers all components of the CDE.

4. Disabling or uninstalling any unnecessary services, programs, accounts, drivers, scripts, features, systems, and web servers, and documenting which ones are allowed.

5. Changing vendor-supplied default usernames and passwords.

6. Documenting security policies and operating procedures for managing vendor defaults and other security settings.

7. Using technologies such as VPN for web-based management and ensuring all traffic is encrypted following current standards. There are both paid and free VPNs available.

8. Enabling only one primary function per server.

3. Safeguard stored cardholder data.

Depending on your business and the type of purchase, some cardholder data is stored (subscriptions or recurring orders), while some isn’t. If you have cardholder data stored, step three ensures you’re keeping it stored responsibly.

You can safeguard stored cardholder data by:

1. Documenting a data retention policy.

2. Having employees acknowledge their training and understanding of the policy.

3. Eliminating storage of sensitive authentication data after card authorization.

4. Masking the primary account number on customer receipts.

5. Understanding guidelines for handling and storing cardholder data.

6. Making sure primary account number storage is accessible by as few employees as possible, including limiting access to cryptographic keys, removable media, or hard copies of data.

7. Utilize multifactor authentication (MFA) for any access to cardholder data, whether digital or in-person via a system.

4. Encrypt cardholder data that is transmitted across open, public networks.

Storage is only part of the equation. What about all that cardholder data that’s in motion?

The next requirement is all about encrypting this data as it’s transmitted across open, public networks, accomplished by:

1. Reviewing all locations, systems, and devices where cardholder data is transmitted to ensure you’re using appropriate encryption to safeguard data over open, public networks.

2. Verifying that encryption keys/certificates are valid and trusted.

3. Continually checking the latest encryption vulnerabilities and updating as needed.

4. Having a policy to ensure you don’t send unprotected cardholder data via end-user messaging technologies.

5. Checking with vendors to ensure supplied POS devices are appropriately encrypting data.

6. Reviewing and implementing best practices, policies and procedures for sending and receiving payment card data.

7. Ensuring TLS is enabled whenever cardholder data is transmitted or received through web-based services.

8. Prohibiting the use of WEP, an unsecured wireless encryption standard.

5. Anti-malware/anti-virus software needs to be implemented and actively updated.

Just as your home computer should have anti-malware and anti-virus software, so too should your business networks.

The following is how you make sure the right defenses are in place:

1. Deploying anti-virus and anti-malware programs on commonly affected systems.

2. Setting anti-virus/malware to scan automatically to detect and remove malicious software.

3. Maintaining audit logs for review.

4. Ensuring the anti-virus/malware system is updated automatically.

5. Setting up administrative access to ensure anti-virus/malware can’t be disabled or altered by users.

6. Documenting malware procedures and reviewing with necessary staff.

7. Examining system configurations and periodically evaluating malware threats to your system.

6. Create and sustain secure systems and applications.

You thought we were done with security? Think again! The next requirement adds another layer of security via the right systems and applications.

Make sure you have the right systems and applications in process by:

1. Having a change management process.

2. Having an update server.

3. Having a process in place to keep up-to-date with the latest identified security vulnerabilities and their threat level.

4. Installing vendor-supplied security patches on all system components.

5. Ensuring all security updates are installed within one month of release.

6. Setting up a manual or automatic schedule to install the latest security patches for all system Components.

7. Keep cardholder access limited by need-to-know.

Some things in life are on a need-to-know basis, like how that itchy spot is something to show your doctor and not your neighbor. The same is true for cardholder access. Whether your company has 50 or 5,000 people, some people don’t need access to cardholder data.

Keeping this sensitive data as need-to-know can be done by:

1. Implementing access controls on any systems where cardholder data is stored and handled.

2. Having a written policy that details access to cardholder data based on defined job roles and privilege levels.

3. Training employees on their specific access level.

4. Configuring access controls to only allow authorized parties and denying all others without prior approval or access.

8. Users with digital access to cardholder data need unique identifiers.

Even if you have access limited to those in the need-to-know circle, it’s important you know just who’s poking around in all that cardholder data and when. This is where unique identifiers come into play.

Keep tabs on access by doing the following:

1. Requiring users use their own unique ID to log in and access data. (NO sharing accounts.)

2. Monitoring all remote access accounts used by vendors, business partners, IT support personnel, etc. when the account is in use.

3. Disabling all remote access accounts when not in use.

4. Enabling accounts used for remote access only when they are needed.

5. Implementing a multi-factor authentication solution for all remote access sessions.

9. Physical access to cardholder data needs to be restricted.

Just as you restrict digital access, you need to similarly limit physical access as well. If you’re fully online, you may not have any physical cardholder data to protect. But, if you’re keeping receipts or order information, and it contains any of the aforementioned cardholder data, you need to follow PCI DSS.

In the event you have physical cardholder data, protect it by:

1. Restricting access to any publicly accessible network jacks in the business.

2. Keeping physical media secure and maintaining strict control over any media being moved within the building and outside of it.

3. Keeping media in a secure area with limited access and requiring management approval before the media is moved from its secure location.

4. Using a secure courier when sending media through the mail so the location of the media can be tracked.

5. Destroying media in a way that it cannot be reconstructed.

6. Maintaining a list of all devices used for processing and training all employees to inspect devices for evidence of tampering.

7. Having training processes for verifying the identity of outside vendors wanting access to devices and processes for reporting suspicious behavior around devices.

10. Network resources and cardholder data access needs to be logged and reported.

Unique IDs and identifiers help you keep tabs on who is accessing data, while logging and reporting acts as your digital paper trail. (In the event of any mishandling or a breach, these are your receipts.)

Logging and reporting are crucial to PCI DSS and protecting your organization, and fortunately you can implement it by:

1. Having audit logs that track every action taken by someone with administrative privileges, failed login attempts and changes to accounts.

2. The ability to identify a user, the date and time of the event, the type of event, whether the event was a success or failure, where the event originated from and the name of the impacted data or system component.

3. Having processes and procedures to review logs and security events daily, as well as review system components defined by your risk management strategy.

4. Having a process to respond to anomalies or exceptions in logs.

5. Keeping all audit log records for at least one year and maintaining logs for the most recent three months readily available for analysis.

11. Run frequent security systems and processes tests.

How can you be sure your door’s locked if you don’t wiggle the handle? The same’s true for your PCI security components. With the right systems and tools in place, it’s time to test them out.

Vet your security systems and processes by:

1. Running quarterly internal vulnerability scans using a qualified internal resource or external third party.

2. Running quarterly external vulnerability scans using a PCI-approved scanning vendor (ASV).

3. Using a qualified resource to run internal and external scans after any major change to your network .

4. Configuring the change-detection tools to alert you to unauthorized modification of critical content files, system files or configuration files, and to configure the tools to perform critical file comparisons at least once a week.

5. Having a process to respond to alerts generated by the change-detection tool.

6. Running a quarterly scan on wireless access points and developing a plan to respond to the detection of unauthorized wireless access points.

7. Performing penetration tests to confirm segmentation is operational and isolates systems in the CDE from all other systems.

12. Address information security throughout your business by creating a policy.

It’s time to spread the gospel of your PCI DSS systems and processes.

Do the following to ensure your company is knowledgeable on their role in PCI compliance:

1. Developing written compliance and security policies.

2. Ensuring every employee working in the CDE completes annual security awareness training.

3. Creating a company policy documenting all critical devices and services within the CDE, including laptops, tablets, remote access, wireless access, and email/Internet usage.

4. Developing a comprehensive description of each employee’s role in the CDE and documenting acceptable uses and storage of all technologies.

5. Creating an incident response plan in the event cardholder data is compromised.

6. Creating and updating a current list of third-party service providers.

7. Annually documenting a policy for engaging with third-party providers, obtaining a written agreement acknowledging responsibility for the cardholder data they possess and having a process for engaging new providers.

How to achieve PCI compliance: assess, remediate, report

Okay, the actual requirements for PCI DSS look like a lot when they’re all laid out. So, how are you supposed to actually go about making PCI compliance happen? A tried-and-true approach to security: assess, remediate, report.

This three-step approach is used for matters outside security, but is largely applicable to building a vulnerability management program specifically because it emphasizes continuous, diligent effort.

Best of all, this approach makes compliance feasible for organizations with a robust IT department and their own internal security assessor, and those who are just getting their footing.

1. Assess.

First, you need to assess your current systems and workflows to find vulnerabilities that risk PCI compliance. Take the following steps to ensure no stone goes unturned:

• Document every instance where cardholder data is processed, transmitted, or stored. (Don’t forget integrations and third-party apps!)

• Review your internal policies and workflows for vulnerabilities, taking note to add documentation around any policies that’s currently lacking or highlighting areas where access control measures are needed.

• Assign risk scores to every vulnerability uncovered to help with prioritization in the next step.

Take your time with this step, as it’s easily the most important. Anything missed here won’t get addressed further down the line. (No pressure.)

2. Remediate.

Next, it’s time to fix any vulnerabilities discovered in the previous step. There are a things you can do here to help:

• Simply put: Don’t store cardholder data if you don’t have to.

• Make sure you’re not storing guest checkout cardholder data. (Some homegrown ecommerce platforms will do this, and it’s an unnecessary risk.)

• Ideally, choose a payment provider that utilizes tokenization or point-to-point encryption, making cardholder data processing more secure and PCI compliance easier to obtain.

Once you’ve taken any steps to resolve security issues, test and retest everything. Credit card information is sensitive, valuable stuff, and it’s on you to keep it safe the moment a customer entrusts you with it. (Again, no pressure.)

3. Report.

Whether this is your first time going for PCI compliance or you’re fixing loopholes after a violation, reporting is the moment your hard work (hopefully) pays off.

Carefully document your findings and any measures taken, as well as your completed self-assessment questionnaire, and then submit them to the acquiring bank and any card brands you work with.

Note: Both acquiring banks and card brands require reporting annual, so no matter what, reporting is in your future.

Completing your SAQ and meeting the technical requirements

Unless you’re a level 1 merchant, it’s essential you know how to complete the SAQ that’s appropriate for your business. Like everything else in the world of PCI compliance, this is a task best tackled in methodical fashion.

How to find the right SAQ.

First, you need to know which SAQ applies to you. Review the following SAQ types to find the one that best matches your business:

• SAQ A: For merchants using a fully hosted, redirected payment page where card data never touches their server.

• SAQ A-EP: For ecommerce merchants that outsource payment processing but whose website (JS or server-side code) can still impact transaction security.

• SAQ B: For merchants using only imprint machines or standalone dial-out terminals with no electronic cardholder data storage.

• SAQ B-IP: For merchants using only standalone IP-connected payment terminals with no electronic data storage.

• SAQ C: For merchants running internet-connected payment applications with no electronic cardholder data storage.

• SAQ C-VT: For merchants manually keying single transactions into a web-based virtual terminal on an isolated, dedicated computer.

• SAQ D: The only SAQ available to service providers that process, store, transmit, or secure cardholder data on behalf of others.

• SAQ P2PE: For merchants and service providers using a validated point-to-point encryption solution that encrypts card data at the point of interaction.

• SAQ SPoC: For card-present merchants using a secure card reader on a validated mobile device, not applicable to ecommerce.

If you’re unsure, or feel two SAQs are close to applying to your business, choose that which is more thorough than you need.

Technical controls for the cardholder data environment.

Next, you need to handle the technical controls, or access, elements that pertain to your cardholder data environment (CDE).

• Make sure default passwords aren’t used anywhere for anyone.

• Go through your list of personnel and ensure only those who absolutely need access to cardholder data have it.

• Set up MFA for any users that will have access to cardholder data.

• Train employees on your data handling and security best practices.

• Ensure proper firewalls are in place within your network and that all systems are up to date.

• Encrypt cardholder data if you’re processing it on your end, or partner with a compliant processor who handles encryption or tokenization.

The above is far less of a burden when you’re utilizing a trusted ecommerce platform with compliant payment gateways in place. Again, you’ll still have to do your due diligence on your end, but your partner can ensure safe storage and transmission of cardholder data.

Time and cost to reach compliance.

There’s no concrete timeline or cost for PCI compliance. The larger your business and the tighter the requirements for your merchant level, cost and timelines can increase. Your current infrastructure and security challenges can further increase cost and timelines as well.

Despite this, there are general estimates depending on the size of your business.

• Small businesses: Costs can range from $1,000 to $10,000 every year, with initial compliance taking 2 - 6 weeks.

• Medium businesses: Typically level 2 or 3, businesses in this range can expect to spend $10,000 to $50,000 each year. The process typically takes two to 2-5 months.

• Enterprise: Large businesses and those at level 1 should plan on costs of $50,000 and beyond each year, with initial compliance taking 6 - 12 months.

Just keep in mind these estimates can shift wildly, especially if you have major security needs you’ve yet to fill.

How your ecommerce platform affects PCI compliance

• Use a comparison table: platform type → who owns most PCI scope → relative cost/effort → key risk.

There’s no magic fix for PCI compliance, but your choice of ecommerce platform can certainly lessen or increase your burden.

Open-source, self-hosted software.

As open source platforms continue to grow in popularity, it is no surprise that open source security has begun to question. The software industry has failed to protect the public from data theft and breaches, which is why the PCI DSS has become so critical for organizations. 

Open source issues have become so prevalent that PCI addressed it directly. In section 3.2b of the PCI Secure SLC document, the guidelines state: 

“Where open-source software components are utilized as part of the software, the assessor shall examine vendor evidence, including process documentation and assessment results to confirm these components are managed as follows:

• An inventory of open-source components used in the vendor’s software is maintained.

• A mature process exists to analyze and mitigate the use of open-source components with known vulnerabilities.

• The software vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.

• An appropriate patching strategy for open-source components is defined.”

Commercial (on-premise) software.

Using commercial, on-premise software comes with similar PCI hurdles as open-source, in that your organization is responsible for all of compliance.

While commercial software may come with certain guardrails that make compliance easier or improve overall safety/security, it’s still on you to:

• Maintain access control of the software.

• Update the software.

• Properly secure your network, maintain firewall, network security controls, and so on.

• Secure any physical copies of cardholder data or orders containing cardholder data.

• Have a plan in place in the event of a breach.

• Train employees on proper access and use of the software, cardholder data, etc.

Again, depending on the commercial solution you choose, you could have an easier time than with an open-source platform. But, your role in PCI compliance is still larger than using, say, a SaaS platform.

SaaS platforms.

Many Software as a Service (SaaS) platforms and providers are now involved in transmitting and storing credit or debit card data. 

While they may not be processing the actual data themselves, the fact that it passes through their system is more than enough to fall under the careful eye of PCI DSS compliance.

To ensure PCI compliance, Saas platforms should look to prioritize the following:

1. Information Security Policies

SaaS platforms must take care to have direct and explicit information security policies and procedures in place. Organization is key here — you want to be able to point to the processes in place in the event of a data breach or security issue.

2. Documentation

Similarly, documentation is critical for SaaS. PCI compliance demands in-depth policies and procedures. Organizations need to be able to log all of the information they have related to payment data, and it needs to be readily available for review. 

The more documentation a business has, the fewer potential gray areas it will have to deal with.

3. Risk Assessment

Lastly, a significant part of PCI compliance for SaaS platforms is the assessment of risk for cloud computing providers. PCI DSS requires that SaaS providers perform an annual risk assessment to review for any potential threats. 

Knowing what to watch out for is half of the battle. Every business faces a different set of challenges and threats, depending on industry, size, or location. By setting yourself up for success, you can prevent broader security issues.

Headless and composable setups.

Headless platforms work primarily by separating the frontend storefront from the backend commerce services. 

PCI compliance comes into play in the connection of the frontend with the backend, particularly in regards to card payment. If a customer enters the wrong credit card information at the frontend, then the backend should reject the transaction. 

What the PCI regulations ask in an instance like this is, instead of triggering a specific message on why the transaction failed, the frontend should create a general message about invalid information. 

Why is that? If the goal is to prevent fraud ultimately, businesses should do their best to lessen the chance of fraud whenever possible. Instead of giving fraudulent customers an area in which to make an educated guess, you're simply making sure they're aware of an issue. 

Data breaches and credit card fraud can ruin a business' bottom line and reputation. Businesses can set themselves up for success and prevent potential risk by ensuring the front-end and backend are as harmonious as possible.

Risks and penalties of PCI non-compliance

Keep in mind that PCI compliance isn’t a law, but a set of guiding standards. Failing to comply isn’t going to result in the same kind of punishment as breaking a law, but credit card companies can levy a number of fines for failing to comply. (A number that increases in the event of a breach.)

Fines and non-compliance fees.

When you fail to comply, the card company associated with your platform or payment gateway imposes a fine on the bank who then passes it along to you. This fine can vary, depending on the card company, your merchant level, and how long non-compliance has gone on.

To get a better sense of the costs associated with non-compliance, take a look at the following:

• Mastercard: For level 1 or 2 merchants, fines increase from $25,000 to $200,000 after your fourth violation.

• Visa: Visa doesn’t publish official violation fines, but does share that violations result in an assessment, which costs anywhere from $5,000 to $100,000 depending on level.

Again, the above is only what these cards choose to publish. Fines can vary significantly, and there can be numerous related costs. (Not to mention, the hit to your brand’s reputation.)

Losing the ability to process cards.

Failing to meet PCI DSS can hit your pocketbook pretty hard. More than that, it can result in something no ecommerce business wants: losing the ability to process credit cards.

This loss can be temporary in some cases, getting lifted after you meet compliance again. But, an ongoing failure to comply can ultimately lead to the bank closing your account to minimize risk.

Imagine being a pizza shop that no longer has the right to own a pizza oven.

Breach liability and forensic costs.

Card companies can require mandatory forensic investigations after a breach, which can carry additional costs. On top of this, there can be liability costs as well, which often increase with the severity of the breach or violation.

Overlap with GDPR and other privacy laws.

The General Data Protection Regulation (GDPR) is a series of EU-based regulations that protect the information of consumers online. Unlike PCI, which focuses on cardholder data, GDPR is focused on privacy. But, there’s still overlap between the two, and a breach can impact both.

A PCI breach exposes cardholder data, which contains sensitive, personal information. This information falls under GDPR, meaning an issue with PCI compliance can quickly become an issue with GDPR. This can result in penalties from both ends, snowballing quickly.

Worth noting: Even if you aren’t selling to anyone in the EU, you should still be GDPR compliant, as it covers anyone in the EU who has their information collected by a site.

The final word

PCI compliance is a long, detailed process. But, when done well from the beginning, it’s easier to keep up with any changes.

If you’re feeling overwhelmed, that’s okay. Take a deep breath, and:

1. Confirm your merchant level and SAQ with your acquiring bank.

2. Run inventory on the scripts powering your checkout page and ensure it’s safe.

3. If your business is growing more than 20% YoY, reach out to a QSA before you’re forced up a level.

Unless you’re a true security nerd, PCI compliance isn’t the most riveting thing in the world. But, it’s important to the long-term success of your ecommerce business and the safety of your customers.

Take your time, do it right the first time, stay vigilant, and you’ll be compliant in no time. (Okay, longer than “no time.”)

For more information on how BigCommerce fits into the PCI compliance puzzle, be sure to explore our in-depth platform guide.

FAQs about PCI compliance