Your inventory is in order, production is up to scale, and your marketing strategy has been mapped out. All that's left to do is for payments to be set up — whether you're opening a brick-and-mortar store, or launching online.
On Google, you search for terms like "how to accept payments online" or "how to accept card payments". Everything seems straightforward until you hit a major stumbling block: payment compliance. You encounter unfamiliar acronyms like "PCI DSS", or terms like "PCI DSS checklist" and you're not sure where to start.
The topic of payment compliance is a complicated landscape of regulations, standards, and technical requirements, which can be daunting for anyone to navigate, especially for those navigating the process independently. Read on for the full run-down on payment compliance, and use our PCI DSS checklist to help you achieve a secure, compliant payment environment.
What is PCI-DSS?
PCI-DSS (Payment Card Industry Data Security Standard) refers to the set of rules, regulations, and security standards established in 2004 by MasterCard, American Express, Visa, JCB International and Discover Financial Services to:
- Achieve consistent security controls across the different card networks.
- Reduce card payment fraud.
- December 2004 marked the initial release of version 1.0 of PCI DSS. Since then, the guidelines have been continuously reviewed and revised to reflect the ever-changing landscape of the payments industry.
Under the latest version, PCI DSS (4.0.1)*, the standard applies to any entity that accepts, processes, stores, or transmits sensitive cardholder data — including credit card numbers, CVV codes, and personal account details. This encompasses all stakeholders involved in payment card processing, including merchants, processors, acquirers, issuers, and other service providers.
Does PCI-DSS apply to me?
According to the PCI DSS (4.0.1), the requirements outlined apply to the following entities that:
1. Store, process, or transmit account data (cardholder data and/or sensitive authentication data)
This covers any business whose own systems directly handle raw payment data during a transaction. For example, this applies to:
- Online stores with a custom-built checkout page, such as an online form at checkout that collects the customer's card number directly on the merchant's own website before forwarding it to a payment gateway.
- Businesses that manually key in customer card details for phone or mail orders into their own POS system or spreadsheet. In Hong Kong, this business practice is mainly adopted by hotels.
- Businesses that store customer card details internally. For example, service providers that keep card numbers on file for recurring billing or subscriptions, rather than using a tokenised system provided by a certified provider
2. Operate or maintain systems that can impact the security of cardholder data and/or sensitive authentication data
This applies to parties who don't handle card data directly, but own or manage systems or infrastructure that could affect payment data security. For example,
- IT providers managing the Wi-Fi network your card terminal connects to instore.
- Developers maintaining the website that your checkout page sits on.
While both parties never see the card data itself, a flaw in their respective security systems could still put payment data at risk.
3. Outsource payment operations or cardholder data environment (CDE) management to a third party
This applies to businesses that don't store, process, or transmit card data themselves because they've outsourced that responsibility to a payment provider — for example, a cafe using KPay Terminal Pro. The business itself never touches the card data directly, but remains responsible for ensuring that their chosen provider is PCI DSS compliant.
Assess your payment compliance with the PCI DSS checklist
In order to achieve full compliance, the PCI DSS requires merchants and payment providers to satisfy the following 12 requirements as outlined in PCI DSS version 4.0.1 in order to meet the security standards required by card networks and payment service providers to accept digital payments.
Before committing to a payment provider, use the checklist below to verify that your provider meets all 12 PCI DSS requirements on your behalf. Any requirement not covered by your provider becomes your business's responsibility to implement and maintain.
| Requirement |
Action needed for compliance |
Does your potential payment provider cover this? |
| 1 |
Install and Maintain Network Security Controls (NSCs)
NSCs such as firewalls, typically control network traffic based on custom rules set by a developer or IT service provider.
If you have outsourced the payment operations to a certified payment provider, this requirement is largely handled on your behalf — their infrastructure has these controls built in and maintained. However, it's worth confirming that these controls are properly configured and reviewed regularly.
|
Yes |
No |
| 2 |
Apply Secure Configurations to All System Components
Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce opportunities for an attacker to compromise your systems |
Yes |
No |
| 3 |
Protect Stored Account Data
Payment account data should not be stored unless it is necessary to meet business needs, while sensitive authentication data must never be stored after authorization. If your organization stores PAN (Primary Account Number), it is crucial to render it unreadable. If sensitive authentication data is stored prior to authorisation, that data must also be protected. |
Yes |
No |
| 4 |
Protect Cardholder Data with Strong Cryptography During Transmission PANs must be encrypted during transmission over networks that are easily accessed by malicious individuals, including untrusted and public networks.
PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both.
|
Yes |
No |
| 5 |
Protect All Systems and Networks from Malicious Software
Malicious software (malware) is software or firmware designed to secretly infiltrate systems to steal or damage data. Common examples include viruses, spyware, ransomware, and keyloggers (software that secretly records everything typed on a keyboard, including passwords and card details).
Malware can enter the network during business-approved activities, including employee e-mail (e.g. phishing) and use of the internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.
|
No |
Yes |
| 6 |
Develop and Maintain Secure Systems and Software
Security vulnerabilities may allow criminals to access payment data. However, this can be prevented by performing regular system updates to patch security vulnerabilities.
Applications must be developed according to secure development and coding practices, and changes to systems in the cardholder data environment must follow change control procedures
|
No |
Yes |
| 7 |
Restrict Access to System Components and Cardholder Data by Business Need to Know
Unauthorized individuals may access critical data or systems due to poorly managed user access controls. As such, access to sensitive data and systems must be limited to authorised personnel only, based on each user's specific role requirement.
Access should be limited based on two guiding principles:
-
"Need to know" - access should be provided to only the least amount of data needed for a job.
-
"Least privileges" - access should be provided to only the minimum level of privileges needed for a job.
|
No |
Yes |
| 8 |
Identify Users and Authenticate Access to System Components
Assigning unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, identifiable and authorised users.
These requirements, unless otherwise stated, apply to all accounts types, including:
- Point-of-sale accounts
- Accounts with administrative capabilities
- Accounts used to view or access payment account data or systems that contain such data
Note: These requirements are not applicable to accounts used by consumers (cardholders).
|
No |
Yes |
| 9 |
Restrict Physical Access to Cardholder Data
Physical access to cardholder data, and any systems that store, process, or transmit it, should be restricted. Otherwise, unauthorised individuals could access or remove sensitive systems or hardcopies containing this data.
|
No |
Yes |
| 10 |
Log and Monitor All Access to System Components and Cardholder Data
In order to prevent exploitation, business entities need to monitor and test networks regularly, to detect and fix:
- Unexpected access and activities
-
Security system failures
-
System vulnerabilities
Audit and system logs should also be kept to track user activities for detection of anomalies and suspicious activities, and effective forensic analysis.
|
No |
Yes |
| 11 |
Test Security of Systems and Networks Regularly
System components, processes, and bespoke and custom software should undergo frequent review and testing, as malicious parties may uncover system vulnerabilities, and software updates could introduce new bugs or system flaws that can compromise data security.
This ensures that existing security controls continue to keep pace as the business's systems and operating environments continue to change.
|
No |
Yes |
| 12 |
Support information security with organisational policies and programs
Business entities that implement strong security policies set expectations for the company's stance on data security, and inform employees of their responsibilities related to it.
All employees should be made aware of the sensitivity of payment account data, responsibilities for protecting it.
|
No |
Yes |
Note: the requirements above are taken from the PCI-DSS Prioritised Approach Tool created by the PCI Security Standards Council, and reference the PCI DSS Quick Reference Guide. Please refer to the official documents for a comprehensive breakdown of each requirement and the specific controls your business needs to implement to achieve full PCI DSS compliance.
What do the results of my PCI DSS compliance checklist mean?
If you are not able to confidently answer 'Yes' to any of the requirements above, your chosen payment method may not yet be fully PCI DSS compliant. This means that you could risk being fined or penalised by your acquiring bank that is acting on behalf of card networks like Visa and Mastercard. These obligations would ultimately fall on your business.
However, you don't have to manage all 12 requirements yourself. By choosing a PCI DSS-compliant payment service provider, you can pass much of this compliance responsibility on to them instead.
Protect your customer's data with KPay's payment solutions
Keeping your customers' payment data secure is one of the most important, and often most overwhelming parts of accepting digital payments. KPay's payment solutions are PCI DSS compliant and ISO 27001 certified.
Rather than managing payment security on your own, choosing a certified payment provider like KPay grants you access to payment infrastructure that's already built, tested, and certified to industry security standards. You reduce your own compliance burden while giving your customers confidence that their payment data is being handled securely.
%20(4).png)
.png)
