When it comes to eCommerce dealing with online transactions, it’s better to be safe than sorry. With an annual growth rate of 20.8% globally, the online payment market is expected to exceed USD 17,643.35 billion by 2027. Thanks to the adoption of smartphones, online shopping is the new normal. That also means consumers are constantly subjected to financial fraud. The only trust they can fall back on is the PCI DSS certification.

You might have already heard of PCI DSS, but what is it, and why is PCI DSS important for eCommerce? Without further ado, let’s jump right into it.

PCI DSS Certification – the definition

The PCI DSS, which stands for Payment Card Industry Data Security Standard, is an industry certification that secures in-person and digital payment transactions. For this blog’s sanity, we’ll focus only on the digital sector for PCI DSS certification, established by the Payment Card Industry Security Standards Council, to protect cardholder data and any sensitive authentication data from being unauthorized.

To get PCI DSS certified, you have to meet the following 12 predefined requirements:

1. Having a secured network means installing and maintaining an effective firewall that is not overly excessive.
2. No default settings from 3rd party vendors.
3. Protect your stored cardholder data at all times.
4. Transactional data has to be encrypted.
5. Regular use of effective antivirus software and keeping them up-to-date.
6. Implement and uphold secure systems and applications.
7. Confine access to cardholder data to any unauthorized personnel.
8. Assign unique login credentials to each user for monitoring purposes.
9. Restrict physical access to cardholder data.
10. Log and keep track of all network access.
11. Carry out regular testing on systems and processes security.
12. Create and maintain a security policy.

More on these details can be read in the official PCI DSS documentation here. On the 31st March 2024, the old version of the payment industry standard PCI DSS v3.2.1 officially retired, transitioning to the new PCI DSS v4.0. To get certified for PCI DSS v4.0, there are 50 more requirements to check off compared to the old version. If you have been going strong with your compliance testing and putting hard work into building a secured payment infrastructure, passing the new regulatory requirements is not a breeze but would not be a roller coaster ride of emotions.

What is your merchant level?

The PCI DSS categorizes merchants into four levels:

• Level 1: Over 6 million online transactions per year
• Level 2: In between 1 million to 6 million online transactions per year
• Level 3: In between 20,000 to 1 million online transactions per year
• Level 4: With fewer than 20 online transactions per year

Once you have defined your merchant level based on the prior 52 weeks of transaction volumes recorded by the bank, you’ll have the exact levels of compliance, the number of assessments, and the security validation you must meet to get PCI DSS certified. If your business is level 2 to 4 compliance, you can do the self-assessment questionnaires (SAQs) internally instead of undergoing an external audit by a Qualified Security Assessor (QSA).

How often do you need your PCI DSS certification validated?

You are required to complete the self-assessment questionnaire form (SAQ) and pay the PCI compliance fee annually; otherwise, you are subjected to fines or account termination.

PCI DSS Compliance testing approach

Building a Software Development Lifecycle based on security fundamentals

To stay secure, it should be built with security from the ground up. Have your PDI CSS requirements analyzed early on to align with your project scope, such as encryption, access control, logging mechanism, etc. From there, specify user roles, define roles, and set out the access levels and privileges to restrict access to sensitive information as needed. Design and build a profound security-focused system architecture to isolate cardholder data from the general system properly, have an efficient encryption strategy with different methods applied to different processes, and visually draw out data flow diagrams to understand further and eliminate potential risks often skipped or bypassed.

Having an extensive testing strategy

To get PDI CSS compliance, your software application must go beyond the traditional functional and non-functional testing route while covering security testing. The application has to handle cardholder-sensitive data simultaneously, maintaining its performance and usability, including the following mandatory testing types:

Penetration testing

Simulating real-world attacks involves ethical hacking to pinpoint vulnerabilities both internally and externally or even from third-party vendors.

Static and Dynamic Application Security Testing (SAST/DAST)

The SAST and DAST testing methods aim to identify vulnerabilities at different stages of software testing. During the development phase, SAST strives to analyze source code, binaries, etc. DAST evaluates applications while running in real-time to detect unsecured sessions, exposed APIs, potential injection flaws, etc.

Data Protection aka. Security Testing

To preserve cardholder data properly compliance with the PCD DSS standards, testers have to carry out:

1. Encryption standards: All sensitive data must be encrypted at rest and while in transit using strong algorithms, such as AES-256 for encryption and TLS 1.2 or higher for data transmission.
2. Data masking: Cardholder data must remain masked in all non-production environments, such as development, testing, and staging environments.
3. Data retention and deletion: Sensitive data is only retained for a certain period of time and must be deleted when it is no longer necessary. Verify whether the automated deletion process was applied using secure overwriting methods, such as NIST 800.88 standards.
4. Access control testing: this particular testing method is used to validate that only authorized users have access to encrypted sensitive data. All these accesses must be logged in detail, including user ID, access timestamp, and the accessed data involved. Stick to the principle of least privilege, which means users only gain access to the minimum data needed for their roles.

Patch testing and vulnerability management

Carry out quarterly internal and external vulnerability scanning to detect possible security weaknesses in underlying operating systems, databases, or network infrastructure. Don’t neglect third-party libraries, frameworks, or other existing dependencies. Utilize automated tools to increase testing performance sustainably.

Patch testing for software updates should be done in a controlled environment, ideally in an isolated testing environment like staging or a sandbox that can replicate the production setup but does not handle sensitive data. The test should confirm that neither new vulnerabilities nor updates break the existing functionality.

Always ready for the auditing process and reporting system

Be prepared for scheduled and out-of-schedule audits with all the required documentation proving your PCI DSS compliance practices. Perform internal audits regularly to uncover any vulnerabilities, having everything logged in as much detail as possible and retained for at least a year as required by PCI DSS standards. Reports generated from these logs must adhere to PCI DSS compliance.

Scalability and Performance Testing

These testing approaches determine whether software applications can successfully handle cardholder data during peak load conditions without compromising security or performance. Load testing, stress testing, horizontal and vertical scaling, and cloud scaling are often used in this scenario. Look for metric indicators such as throughput, response time, error rate, uptime, availability, etc., to evaluate the effectiveness of your software application.

The Challenges in PCI DSS Compliance for Testing Teams

The PCI DSS compliance knowledge gap

Let’s face it! The long list of requirements of PCI DSS compliance can be ambiguous and challenging to analyze, let alone follow to the tee. Overlooking critical compliance criteria can happen. You may involve a QSA (Qualified Security Assessors) expert to bridge the knowledge gap and provide training for testing teams to thoroughly understand the PCI DSS compliance and convert them into actionable testing benchmarks.

Secured testing environment

The test environment has always been taken lightly when it comes to security since all the spotlights have been on the production environment. That’s why, in the testing environment, actual cardholder data should not be used. However, keeping access restricted to the involved personnel only encrypting all test data in compliance with PCI DSS standards.

Third-party integrations complications

PCI DSS standards have their own standards regarding 3rd party vendor integrations. If your third-party vendors already have their PCI DSS compliance certifications, seek their Attestation of Compliance (AOC), which you can include in your SAQs application. Otherwise, vigorously testing to ensure there won’t be any compromise to the overall compliance obligations toward PCI DSS application status.

Performance vs. Security

Getting your system solidly secured can be a trade-off for performance, ultimately leading to poor user experiences. The best way to prevent such a problem is to collaborate between testers and developers with a primary focus on the security itself and the high performance when the system is confronted with a sudden peak. Optimize the encryption and logging mechanism to maintain stable system speed.

Limited Resources

Compliance testing can be exhausted without the right tools and resources. Adequate specialized testing tools come with a heavy price tag that not all businesses can afford. Therefore, choosing which competent testing tools to invest in should be carefully considered. Otherwise, outsourcing is a great option to look at.

Your Best Practices for PCI DSS Compliance

The process of getting PCI DSS compliance is lengthy. Roughly around 2 to 3 months-ish, which does not include the preparation timeframe you must contribute to get the assessment done, or can double/triple the time length from 8 months to a year or more, depending on your organization’s size. It’s best to stay alert and continuously be compliant with the PCI DSS principles by adhering to the following best practices:

Putting on the Security First Mindset throughout the SDLC

Analyze and identify the potential threats to software applications very early on to eliminate such risks before they become much harder to handle. Performing peer reviews to stay up-to-date with the coding standards sand ecurity. Training should be given to testers and developers to embrace testing practices relevant to PCI DSS.

Start automation testings

Automation testing reduces human errors tremendously and is extremely consistent. If you have a hard time leveraging which testing process and what not, refer to our previous blog on automation testing for preferences for a good read. Remember to log these results and improve their efficiency as well as accuracy.

Collaborate with the Expert

If you are a bit short in PCI DSS expertise, work closely with someone to understand the compliance requirements and actively in bridging the gap. Otherwise, outsource it to a professional vendor who can help.

Summing up

Getting a PCI DSS-compliant certification means more than just solely showing the badges. It indicates your commitment to protecting the customers from absolute threats in this digital ecosystem with constant security and vulnerability testing; you value your customer benefits as your own. Hence, if you ever feel like giving up on this seemingly never-ending process of PCI DSS, reach out to SHIFT ASIA for help. Our experienced talents and experts shall help you shorten the PCI DSS compliance timeline with none of the hurdles and the pains of preparations if you wish to get it done yourself.