PCI Compliance

PCI Compliance

Post COVID e-commerce businesses are thriving more than ever, however with this growth comes the increased responsibility to secure card transactions. Payment Card Industry Data Security Standard (PCI DSS) compliance is a requirement for any e-commerce business handling card payments. Achieving PCI compliance ensures that your transactions are secure and meet industry standards.

PCI Compliance Overview

Who needs to be PCI compliant?

PCI compliance is mandatory for all organisations that accept card payments, irrespective of the transaction volumes, value or location globally. Extending to financial institutions, payment gateways, service providers, including any organisations involved in processing, storing, or transmitting credit card information. It's important to note that even if you rely on third-party service providers to handle your card payments,  you still have to maintain PCI compliance.

Here are the organisations that need to be PCI compliant:-

• Merchants: Any business that accepts card payments, whether processing transactions electronically or manually.
• Third Party Service Providers: Companies that process card payments on behalf of merchants.
• Service Providers: Entities that provide services that control or could impact the security of cardholder data, such as hosting providers, payment gateways, and others.

What does PCI stand for?

PCI stands for "Payment Card Industry." Within the context of PCI DSS "Payment Card Industry Data Security Standard", it refers to the global standards and guidelines established to secure card transactions and protect cardholder data across the various payment channels. PCI standards are managed by the PCI Security Standards Council "PCI SCC", an organisation founded by major credit card companies like Visa, MasterCard, American Express, Discover, and JCB.

What is PCI Compliance?

PCI compliance refers to the set of standards developed by the PCI Security Standards Council, designed to protect cardholder data from theft and fraud. These standards apply to all entities involved in payment processing, including merchants, processors, acquirers, issuers, and service providers.

The Importance of PCI Compliance

• Trust: Compliance builds trust between merchants and customers.
• Security: Enhances your cyber-security posture against breaches.
• Regulatory Requirement: Avoid fines and penalties for non-compliance.

How Do I Become PCI Compliant?

This highly detailed guide will walk you through the process of achieving and maintaining PCI DSS v4.0 compliance, utilising the Prioritised Approach for PCI DSS v4.0 as our roadmap.

Step 1 - Determine Your PCI Level and Scope

Achieving PCI compliance starts with understanding your business's specific requirements under the Payment Card Industry Data Security Standard (PCI DSS). The first step in this journey is to determine your PCI level and scope, which are crucial for defining the extent of the efforts you'll need to undertake to become PCI compliant.

Determining your PCI level

Your acquirer will normally Identify your merchant level based on the volume of card transactions per year. Here's a detailed breakdown of how this is normally done:-

What are the 4 levels of PCI Compliance?

PCI merchant levels are categorised into four levels that are determined by the number of card transactions your business processes annually. These levels help categorise businesses based on card transaction volume, which then affects the rigor and method of compliance validation required. The main goal here is to ensure that the larger the volume of transactions, the more stringent the security measures that are in place. 

The Visa merchant levels are typically defined as follows:

One of the key differences between merchants and service providers is how they submit completed reports. Merchants submit their completed reports to their acquirer, whereas service providers must submit reports to the individual card brands (Visa, MasterCard, American Express, JCB, and Discover).

Defining the Scope of Your Assessment

Once you've identified your merchant level, the next step is to accurately define the scope of your assessment.Understanding your scope is critical because it directly impacts the complexity and cost of achieving PCI compliance. This involves identifying all system components, networks, people and processes that are included in or connected to the cardholder data environment. The cardholder data environment is comprised of people, processes, and technology that store, process or transmit cardholder data (CHD) or Sensitive Authentication Data (SAD).

The scope of PCI compliance, however, is not limited to just the CardHolder Data Environment (CDE). Systems that have a connection to the CDE are also in scope, even if the system itself does not store, process or transmit cardholder data. Systems with a connection to the CDE must be included in scope to ensure that appropriate security controls are in place to prevent an attacker using the connected system to gain access to the CDE, and thus to cardholder data.

There are also other types of systems that need to be included in scope, such as; systems providing security services to the CDE, systems that provide or facilitate segmentation between the CDE and any out-of-scope networks, and, generally, any other system that has the ability to directly impact the security of the CDE or of cardholder data.

Some examples of the systems providing security services may include: 

• Authentication services
• Time management services
• Patching deployment and management
• Audit logging
• Anti-virus updates
• Network devices used to control and filter traffic
• Cryptographic services, and
• Physical access controls

You are responsible for annually determining the scope of PCI Compliance and confirming its accuracy, the assessor (if any) performing the PCI DSS validation is responsible to confirm that the scope has been defined and documented properly.

Network Segmentation

Consider network segmentation as a method to reduce your PCI compliance scope. By isolating the CDE from the rest of your network, you can limit the systems and processes that fall within the scope of PCI DSS requirements. Network segmentation is strongly recommended as a method that may reduce:

• The PCI compliance scope.
• The PCI compliance cost.
• The cost and difficulty of implementing and maintaining PCI DSS controls.
• The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations).

Without adequate network segmentation (Sometimes called a "flat network") the entire network is in the scope of the PCI assessment. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists or other technologies that restrict access to a particular segment or network.

If network segmentation is in place and is being used to reduce the scope of the PCI DSS assessment, it  must be verified that the segmentation is adequate to reduce the scope of the assessment. With all segmentation controls being penetration tested at least annually or after changes to segmentation controls per PCI DSS Requirement 11.4.5 (PCI 4.0), to ensure that controls in place continue to provide effective segmentation. 

a) Cardholder Data Environment (CDE)

The first step when scoping your assessment is to identify all the locations where cardholder data exists, from each initial point of collection to the point of destruction or disposal. Begin by mapping your Cardholder Data Environment (CDE). This includes all systems that interact with or could impact the security of CHD and SAD.Identifying all the locations where cardholder data exists, from each initial point of CHD collection to the point of destruction or disposal. 

Data Flow Diagrams

Create detailed data flow diagrams to visualise the flow of CHD and SAD through your systems. This helps in identifying all points where card data is handled, ensuring none are overlooked in your compliance efforts.

Practical Steps:

• Identify Transaction Volume: Review your processing statements or consult with your payment processor to determine your annual transaction volume and identify your PCI level.
• Map Your Data Flow: Document how and where CHD and SAD enter your environment, the systems they interact with, and where they exit. This includes both digital and physical forms of data.
• Segment Your Network: If feasible, implement network segmentation to isolate the CDE from other parts of your network, reducing the scope and complexity of your PCI DSS compliance efforts.
• Consult With Stakeholders: Engage with your IT, security, and payment processing teams to ensure all potential scope elements are considered.

b) People

The second step when scoping your assessment is to identify the people that have the ability to interact with the cardholder data. When identifying the people for inclusion in the assessment, it’s important to include the individuals who actually interact with cardholder data as well as their responsible  managers. Here are just some examples of the types of roles that might be included in a PCI compliance assessment. The following is not intended to be a complete list, but may help as a starting point when determining which people (roles) may be included in the scope of an assessment:-

• Cashiers and sales clerks
• Back-office clerks
• Call center operators
• Systems and network administrators
• IT support personnel
• Application developers
• Key custodians
• Human resources
• Information security officers
• Customer support
• Accounting/finance personnel
• Supervisors/managers for each area
• Senior management and executives

Role assignments will vary from one organization to the next. In some cases, a single person may be responsible for multiple roles, while in others there may be several individuals performing each role. You will need to identify the right people to interview in order to obtain the information needed for the assessment.
 
When validating the scope of the assessment, it is often worth talking to individuals from the accounting and finance department, as these departments can, in many cases, provide details about their company’s payment channels and acquirer relationships. Personnel in these departments may also manage dispute and charge-back processes, making them a great source of information about how these processes are managed.

When identifying personnel for inclusion in the assessment, be sure to consider all the levels of seniority within the organisation.For example, it’s important to include the individuals who actually interact with cardholder data as well as the responsible managers. As in many cases, the managers will explain the documented processes and how they are intended to be followed; however,  the people actually working directly with cardholder data are able to confirm whether the documented processes are in fact being followed.

c) Process

The third step when scoping your assessment involves identifying the processes capable of interacting with cardholder data. This step is crucial for determining which processes should be included in the PCI compliance assessment. Below is a guide to help start this process, noting that this list is not exhaustive but serves as an initial reference for identifying relevant processes.

Examples of processes related to payment processing:

• Regular payment processing channels
• Payment cancellations and chargebacks
• Back-up and fail-over processes
• Reconciliation, periodic reporting
• Distribution and storage of paper reports and other physical media
• Legacy processes and data stores
• Onboarding processes for new personnel

Examples of supporting processes:

• Authorisations and approvals for system access
• Firewall review processes
• Change management
• Scheduling of security patch deployments
• System building and configuration
• Identifying and escorting visitors
• Performing log reviews
• Processes for reporting potential security incidents
• Security policy updates

For each payment channel, it is essential to consider how charge-backs and disputes are managed. Often, charge-backs are recorded both in physical reports and in spreadsheets on one or more computers. Additionally, it's critical to identify any alternate payment methods that might be employed should the primary processes fail—for instance, whether cashiers switch to manual data collection when a point-of-sale system goes offline, or if there are backup systems used under specific conditions.

Paper documentation also requires attention. For example, certain payment terminals may execute daily reconciliation processes, potentially printing transaction records that include card numbers in summary reports. If full Primary Account Numbers (PAN) are present in these documents, the procedures for printing, collecting, transporting, storing, and destroying these reports must be carefully reviewed. While data-flow diagrams are typically focused on the electronic movement of cardholder data, they often overlook the handling of physical documents containing such data, like paper printouts, receipts, and internal reports. However, these diagrams can still be a valuable tool for identifying systems that might produce cardholder data in printed form, as well as highlighting where alternative processes kick in if the standard system or method fails.

It's equally important to consider the entity's data retention policy. An entity might not currently have processes for collecting or storing cardholder data in certain locations, but there may be legacy data stores from previous processes that have been archived and potentially forgotten. These legacy data stores might predate the organisation's current data retention policy. Besides the payment channels themselves, a range of general organizational processes also requires examination during the assessment..

d) Technology

The fourth step in scoping an assessment is pinpointing the technology that interacts with cardholder data. Identifying the right technology for a PCI Compliance assessment is crucial, as the scope can vary significantly between entities. It's essential to focus on technology that directly deals with cardholder data. Below, we provide an overview of common technological areas within the payment industry that often require scrutiny during the assessment process.

Examples of types of technologies:

• Servers, Applications, Networks, Devices: The backbone of most IT infrastructures, these components are critical points of interaction with cardholder data.
• Physical Security Systems: Systems that control access to physical locations where cardholder data may be processed or stored.
• Logical Security Systems: Digital safeguards that protect against unauthorised data access or manipulation.
• Payment Terminals and Point of Sale Systems: Direct interfaces for cardholder data entry and transaction processing.
• Electronic Communications: Includes email, electronic fax, and other digital messaging systems.
  Backups and Disaster Recovery "Hot" Sites: Essential for ensuring data integrity and availability in case of system failure.
• Telecommunications: Differences between traditional phone systems (POTS) and VoIP systems have distinct implications for PCI compliance scope.
• Management Systems: Administrative tools for overseeing IT components and security measures.
• Remote Access Systems: Solutions that enable off-site access to networks, often increasing the risk landscape.

If your organisation receives cardholder data by telephone, it’s important for you to understand the type of phone system and where cardholder data is transmitted and stored by the system. Regular telephone lines (often called POTS lines) are separate to an organization’s network, and voice communications over these lines are generally not in scope. Voice over IP, or VoIP, is a different type of communication method and generally requires the same type of security as other IP networks. Additionally, many organisations have a call recording system so they can retain information about the transaction in the event of a dispute. If cardholder data is included in the voice recording, then the applicable PCI DSS requirements apply.
 
If cardholder data is sent or received via an electronic communication technology, such as e-mail or electronic fax, it’s important to identify the individual workstations as well as the messaging servers that may be part of the communication process. Each of these systems has the potential to retain a copy of the message, including any cardholder data it may contain, and it’s important to ensure it is properly protected.
 
It is important not to overlook backups and disaster recovery facilities. Many organisations will have automated backups that store data at a separate location, to support the quick recovery of business operations. If cardholder data or supporting components, such as cryptographic keys, are stored in these locations, then the applicable PCI DSS controls need to be applied.
 
To summarise, it’s important to identify all the technologies that an entity is using that interact with or can impact how cardholder data is stored, processed, and transmitted.

Sampling

Sampling is an option used to optimise the assessment process, particularly in scenarios involving extensive numbers of business locations or system components within the assessment's scope.

It's crucial to understand that sampling is strictly a mechanism for assessment and not a strategy to apply PCI DSS requirements to a sample of targeted systems. Entities are expected to enforce PCI DSS mandates across all applicable systems and facilities without exception. It is not permissible for an entity to limit the application of PCI DSS standards to a subset of their systems, nor is it acceptable to implement only selected requirements.

When incorporating sampling into an assessment, it's imperative that the chosen samples accurately reflect all types of business facilities and all types of system components. This entails including a broad variety of system components, ensuring that every type and combination currently employed is adequately represented within the sample. This approach ensures a comprehensive and effective assessment, aligning with the overarching goal of maintaining robust security standards across all entities subject to PCI DSS.

As well as ensuring that samples are representative of the overall population, the number of items in the samples must be large enough to provide assurance that the observed controls are implemented across all systems and all facilities. If a chosen sample does not provide this assurance, it will need to be expanded.

Remember, sampling is not a PCI DSS requirement; however if sampling is used, the assessor’s methodology should include consideration for people and processes, and not just technologies.

Conclusion and Timing

By clearly defining your PCI level and scope, you're laying a solid foundation for your compliance journey. This not only ensures that you focus your efforts appropriately but also aids in efficient resource allocation for addressing PCI DSS requirements.

Timing

It is important that an appropriate amount of time is allocated to collect the information that is needed to perform an accurate assessment. The duration of an assessment will vary according to the size and complexity of the environment, as well as the number of people performing the assessment activities.
 
Another factor to consider is whether any “not in place” items are to be remediated and re-assessed as part of the current assessment, or whether the remediation and re-assessment will be performed as a separate activity after the assessment is complete. This should be agreed in advance to avoid unexpected time delays once the assessment has commenced.
 
You will need to allow an appropriate amount of time to complete the report on compliance, perform a quality assurance review, and finalise any steps needed to submit the report.

Step 2 - Assess Your Current Compliance Posture

After determining your PCI level and scope, the next crucial step in achieving PCI compliance is to assess your current compliance posture. This step involves conducting a thorough review of your existing security controls, processes, and infrastructure to identify any gaps against the PCI DSS requirements. Here's how you can effectively assess your current compliance posture:

1. Understand the PCI DSS Requirements

The PCI DSS is based on six primary goals. These goals are:

• Build and maintain a secure network and systems
• Protect Account Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

The PCI DSS is comprised of 12 requirements that cover various aspects of security, including network security, data protection, vulnerability management, access control, monitoring, and information security policies. Begin by familiarising yourself with these requirements and understanding how they apply to your environment.

2. Select the Appropriate Self-Assessment Questionnaire (SAQ)

Depending on your business's PCI level and the scope of cardholder data you handle, you may be eligible to use a Self-Assessment Questionnaire (SAQ) to assess your compliance. The SAQ is a tool provided by the PCI Security Standards Council that simplifies the compliance process for businesses not required to undergo a full Report on Compliance (ROC) by a Qualified Security Assessor (QSA).

Selecting the Right SAQ
Based on the information outlined in "Step 1: Determine Your PCI Level and Scope," choose the SAQ that best matches your business model and payment processing methods. There are several versions of the SAQ designed to cater to different types of merchants.
Review the eligibility criteria for the chosen SAQ carefully to ensure it aligns with your business operations and payment processing environment.

Download the chosen SAQ from the PCI-SCC document llbrary

Completing your SAQ
Answer each question in the SAQ honestly,. the questions in the SAQ correspond directly to the PCI DSS requirements.If you identify any "No" responses, these areas require remediation to meet PCI DSS standards.

3. Conduct a Gap Analysis

With the relevant SAQ in hand, conduct a gap analysis to compare your current practices against each of the PCI DSS requirements outlined in your SAQ. This involves:

• Documenting Current Controls: Identify and document all the security controls and processes you currently have in place that align with PCI DSS requirements.
• Identifying Gaps: Note where your practices fall short of the requirements. This could be areas where controls are partially implemented, not implemented at all, or where existing controls do not fully meet the PCI DSS standards.

4. Prioritise Findings (See below Step 3 - Prioritise Compliance Efforts)

Once you have identified gaps in compliance, prioritise them based on risk. Consider factors such as the potential impact on cardholder data security, the complexity of implementing necessary controls, and any regulatory or contractual deadlines you may be facing.

5. Document Your Findings

• Create a detailed report of your assessment findings, including:
  A list of all controls and processes currently in place that align with PCI DSS requirements.
  A list of gaps identified during the gap analysis, along with a risk assessment for each.
• A prioritised action plan for addressing each gap. 
  This report will serve as a roadmap for your PCI compliance journey, guiding your efforts to address deficiencies and enhance your security posture.

Practical Tips:

• Engage Stakeholders: Involve relevant stakeholders from across your organisation in the assessment process. This includes representatives from IT, security, operations, and any other departments involved in processing, storing, or transmitting cardholder data.
• Use Tools and Resources: Consider using automated tools to help identify vulnerabilities and assess compliance with technical requirements, such as encryption and firewall configurations.
• Seek Expertise: If you're unsure about any aspect of the PCI DSS or how it applies to your environment, don't hesitate to seek advice from a Qualified Security Assessor (QSA) or other PCI compliance experts.

Step 3 - Prioritise Compliance Efforts

Once you've assessed your current compliance posture and identified gaps in your PCI DSS compliance, the next step is to prioritise your compliance efforts. The PCI Security Standards Council (PCI SSC) recommends a prioritised approach to help organisations address their compliance tasks in a structured and efficient manner based on the highest risks. Following the "Prioritised Approach for PCI DSS v4.0," you can ensure that you're focusing on the most critical vulnerabilities first, optimising the allocation of your resources towards compliance. Here's how to prioritise your compliance efforts effectively:

Download the Prioritized Approach For PCI DSS v4.0 from the PCI-SCC document library.

Understand the Prioritised Approach

The Prioritised Approach breaks down the PCI DSS requirements into six milestones designed to help merchants and service providers progress through compliance efforts in phases, starting with the most critical/high risk security vulnerabilities and control objectives.

The prioritised approach maps the above milestones to each PCI DSS v4.0 requirement and sub-requirements (The below image is a snapshot of the prioritized approach). It's important to note that the PCI DSS v4.0 requirements outlined in the prioritised approach sections are presented without the accompanying Applicability Notes and other critical details typically found in the full PCI DSS documentation. These Applicability Notes provide essential context that can influence the interpretation of a requirement and are deemed an essential component of PCI DSS, necessitating thorough consideration throughout the assessment process.

Develop a Prioritised Implementation Plan

Based on the above milestones, create a detailed implementation plan that:

• Lists each gap identified in your assessment.
• Assigns each gap to the relevant milestone.
• Prioritises actions within each milestone based on your specific risk assessment.
• Assigns responsibilities and deadlines for each action item.

Practical Tips:

• Engage Cross-Functional Teams: Security is a shared responsibility. Involve stakeholers from across your organisation in prioritising and addressing compliance efforts.
• Leverage Expertise: Consider consulting with a Qualified Security Assessor (QSA) or other PCI compliance experts to validate your prioritisation and ensure that your plan aligns with PCI DSS requirements.
• Monitor Progress Regularly: Set regular checkpoints to review progress against your plan. Adjust priorities as needed based on emerging risks, business changes, or lessons learned during implementation.

Step 4: Implement Required Controls

After prioritising your compliance efforts, the next step is to implement the required controls to meet PCI DSS requirements. This process involves deploying a combination of technical measures, administrative policies, and procedural safeguards to protect cardholder data effectively. Implementing these controls is a critical step in achieving and maintaining PCI compliance. Here’s a structured approach to implementing the necessary security controls:

Technical Controls 

• Install and Maintain Network Security Controls : Firewalls are your first line of defense. Ensure that firewalls are correctly configured to protect the cardholder data environment (CDE) from unauthorised access. Often, seemingly insignificant paths to and from un-trusted networks can provide unprotected pathways into sensitive systems. 
• Apply Secure Configurations to All System Components: Remove unnecessary software, services, and functions from systems in the CDE. Use secure configurations to protect against vulnerabilities. Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings are well known and are easily determined via public information.Applying secure configurations to system components reduces the means available to an attacker to compromise the system. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface. 
• Protect Stored Account Data: Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection. If an intruder circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys and is unusable to that intruder. Other effective methods of protecting stored data should also be considered as potential risk-mitigation opportunities. For example, methods for minimizing risk include not storing account data unless necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies such as e-mail and instant messaging.If account data is present in non-persistent memory (for example, RAM, volatile memory), encryption of account data is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. . Data should be removed from volatile memory once the business purpose (for example, the associated transaction) is complete.
• Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks. The use of strong cryptography provides greater assurance in preserving data confidentiality, integrity, and non-repudiation. To protect against compromise, PAN must be encrypted during transmission over networks that are easily accessed by malicious individuals, including untrusted and public networks. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targeted by malicious individuals aiming to exploit these vulnerabilities to gain privileged access to cardholder data environments (CDE). Any transmissions of cardholder data over an entity’s internal network(s) will naturally bring that network into scope for PCI DSS since that network stores, processes, or transmits cardholder data. Any such networks must be evaluated and assessed against applicable PCI DSS requirements. 
  Requirement 4 applies to transmissions of PAN unless specifically called out in an individual requirement. 
  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. While it is not required that strong cryptography be applied at both the data level and the session level, it is recommended.
• Protect All Systems and Networks from Malicious Software: Deploy anti-virus software on all systems commonly affected by malware. Keep the anti-virus software up to date to protect against the latest threats.Malicious software (malware) is software or firmware designed to infiltrate or damage a computer system without the owner's knowledge or consent, with the intent of compromising the confidentiality, integrity, or availability of the owner’s data, applications, or operating system. 
  Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, and rootkits, malicious code, scripts, and links. 
  Malware can enter the network during many business-approved activities, including employee e-mail (for example, via phishing) and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.Using anti-malware solutions that address all types of malware helps to protect systems from current and evolving malware threats.
• Develop and Maintain Secure Systems and Software: Actors with bad intentions can use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor 
  provided security patches, which must be installed by the entities that manage the systems. All system components must have all appropriate software patches to protect against the exploitation and compromise of account data by malicious individuals and malicious software. Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For bespoke and custom software, numerous vulnerabilities can be avoided by applying software lifecycle (SLC) processes and secure coding techniques. Code repositories that store application code, system configurations, or other configuration data that can impact the security of account data or the CDE are in scope for the PCI DSS assessment.
• Restrict Access to System Components and Cardholder Data by Business Need to Know: Implement access control measures to ensure that only authorised personnel have access to cardholder data, based on their job role. Unauthorised individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Access” or “access rights” are created by rules that provide users access to systems, applications, and data, while “privileges” allow a user to perform a specific action or function in relation to that system, application, or data. For example, a user may have access rights to specific data, but whether they can only read that data, or can also change or delete the data is determined by the user’s assigned privileges. 
  “Need to know” refers to providing access to only the least amount of data needed to perform a job. “Least privileges” refers to providing only the minimum level of privileges needed to perform a job.These requirements apply to user accounts and access for employees, contractors, consultants, and internal and external vendors and other third parties (for example, for providing support or maintenance services). Certain requirements also apply to application and system accounts used by the entity (also called “service accounts”)
• Identify Users and Authenticate Access to System Components: Assign a unique ID to each person with computer access to the CDE, ensuring accountability and traceability for actions on critical systems.Two fundamental principles of identifying and authenticating users are to 1) establish the identity of an individual or process on a computer system, and 2) prove or verify the user associated with the identity is who the user claims to be. Identification of an individual or process on a computer system is conducted by associating an identity with a person or process through an identifier, such as a user, system, or application ID. These IDs (also referred to as “accounts”) fundamentally establish the identity of an individual or process by assigning unique identification to each person or process to distinguish one user or process from another. When each user or process can be uniquely identified, it ensures there is accountability for actions performed by that identity. When such accountability is in place, actions taken can be traced to known and authorized users and processes.
  The element used to prove or verify the identity is known as the authentication factor. Authentication factors are 1) something you know, such as a password or passphrase, 2) something you have, such as a token device or smart card, or 3) something you are, such as a biometric element. The ID and the authentication factor together are considered authentication credentials and are used to gain access to the rights and privileges associated with a user, application, system, or service accounts.
  These requirements for identity and authentication are based on industry-accepted security principles and best practices to support the payment ecosystem. NIST Special Publication 800-63, Digital Identity Guidelines provides additional information on acceptable frameworks for digital identity and authentication factors. It is important to note that the NIST Digital Identity Guidelines is intended for US Federal Agencies and should be viewed in its entirety. Many of the concepts and approaches defined in these guidelines are expected to work with each other and not as standalone parameters.
• Restrict Physical Access to Cardholder Data: Any physical access to cardholder data or systems that store, process, or transmit cardholder data provides the opportunity for individuals to access and/or remove systems or hardcopies containing cardholder data; therefore, physical access should be appropriately restricted. 
  There are three different areas mentioned in Requirement 9:
  1. Requirements that specifically refer to sensitive areas are intended to apply to those areas only.
  2. Requirements that specifically refer to the cardholder data environment (CDE) are intended to apply to the entire CDE, including any sensitive areas residing within the CDE.
  3. Requirements that specifically refer to the facility are referencing the types of controls that may be managed more broadly at the physical boundary of a business premise (such as a building) within which CDEs and sensitive areas reside. These controls often exist outside a CDE or sensitive area, for example a guard desk that identifies, badges, and logs visitors. The term “facility” is used to recognize that these controls may exist at different places within a facility, for instance, at building entry or at an internal entrance to a data center or office space.
• Logging and Monitoring: Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs on all system components and in the cardholder data environment (CDE) allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is difficult, if not impossible, without system activity logs.This requirement applies to user activities, including those by employees, contractors, consultants, and internal and external vendors, and other third parties (for example, those providing support or maintenance services). These requirements do not apply to user activity of consumers (cardholders)

Administrative Policies and Procedures

• Test Security of Systems and Networks Regularly: Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System 
  components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
• Support Information Security with Organizational Policies and Programs: Create and maintain a comprehensive information security policy that addresses all PCI DSS requirements and is communicated to all relevant personnel. The organization’s overall information security policy sets the tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of cardholder data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors, and consultants with security responsibilities for protecting account data or that can impact the security of account data.
• Risk Assessment: Conduct regular risk assessments to identify vulnerabilities in your systems and processes that could impact the security of cardholder data.
• Employee Training Program: Develop and implement a security awareness program to educate employees about the importance of PCI compliance and their role in maintaining it.
• Vendor Management: Ensure that third-party service providers adhere to PCI DSS requirements. Include security requirements in contracts and regularly monitor service providers’ compliance.

Procedural Safeguards

• Change Management: Implement a formal change management process to ensure that changes to the system and network configurations are documented, tested, and approved.
• Incident Response Plan: Develop and maintain an incident response plan to respond to any security breach or incident effectively. Regularly test and update the plan.
• Data Retention and Disposal Policies: Establish policies for retaining cardholder data only as long as necessary for business, legal, or regulatory reasons. Securely dispose of data when no longer needed.

Implementation Tips

• Start with High-Priority Areas: Focus first on implementing controls in areas identified as high-priority during your risk assessment and the prioritised approach process.
• Document Everything: Keep detailed records of the controls implemented, including configuration settings, justifications for use, and any exceptions.
• Test Controls: After implementing security controls, test them to ensure they are working as intended. This may involve vulnerability scanning, penetration testing, and reviewing access controls.
• Iterate and Improve: Security is an ongoing process. Continuously monitor the effectiveness of your controls and make improvements as needed.

Step 5 - Validate Compliance

After diligently working through the implementation of required security controls to meet PCI DSS requirements, the next critical phase in your compliance journey is validation. This step is about formally verifying that your environment meets all the standards set forth by the PCI DSS. The validation process can differ based on your merchant level, the complexity of your cardholder data environment, and the specific requirements applicable to your business model. Here’s a guide on how to validate your PCI compliance.

Choose the Right Validation Method

• Self-Assessment Questionnaire (SAQ): Smaller businesses often qualify to self-assess their compliance by completing the appropriate SAQ, which varies based on how you handle cardholder data. Select the SAQ that aligns with your specific business scenario, as determined in earlier steps.
• Qualified Security Assessor (QSA): Larger merchants and all service providers are typically required to have their PCI DSS compliance validated by a QSA. QSAs are organisations certified by the PCI SSC to conduct on-site PCI DSS assessments.
• Internal Auditor: For some larger organisations, an internal auditor trained in PCI DSS assessments (and formally recognised as an Internal Security Assessor or ISA) may conduct the assessment if allowed by the merchant's acquirer or payment brands.

Conduct the Validation

• Completing the SAQ: If you are eligible for an SAQ, carefully complete each question, ensuring that your answers accurately reflect the security controls and processes you have implemented. Supporting documentation, such as policies, procedures, and network diagrams, should be readily available.
• On-Site Assessment: If engaging with a QSA, prepare for their visit by ensuring all necessary documentation is in order and any previously identified issues have been addressed. The QSA will review your documentation, interview personnel, and physically inspect your systems and processes to validate compliance.
• Penetration Testing and Vulnerability Scans: Both SAQ completion and QSA assessments may require passing a penetration test and/or quarterly vulnerability scans performed by an Approved Scanning Vendor (ASV). These tests are designed to identify and remediate vulnerabilities in your network.

Address Findings

Whether you’re completing an SAQ or undergoing a QSA audit, you may identify areas where your environment does not fully comply with PCI DSS requirements. Address these findings promptly by:

• Creating a Remediation Plan: For any gaps in compliance, develop a detailed remediation plan outlining the actions needed to achieve compliance, who is responsible, and the expected timeline for resolution.
• Implementing Changes: Execute the remediation plan, making necessary adjustments to your security controls and processes.
• Re-Assessment: After remediation, re-assess the affected areas to ensure that they now comply with PCI DSS requirements.

 Finalise Compliance Documentation

• Complete the Attestation of Compliance (AOC): The AOC is a formal declaration of your compliance status. Whether through an SAQ or a QSA assessment, complete the AOC accurately, indicating your compliance with all applicable requirements.
• Submit Documentation: Submit your completed SAQ and/or AOC, along with any required vulnerability scan reports, to your acquirer or payment brands as directed.

Maintain Ongoing Compliance

Remember, PCI DSS compliance is not a one-time event but an ongoing process. Continuous monitoring, regular testing, and staying abreast of changes to the PCI DSS are crucial to maintaining compliance over time.

Step 6 - Maintain and Monitor Compliance

Achieving PCI DSS compliance is a significant milestone for any organisation handling cardholder data. However, maintaining this compliance is an ongoing process that requires continuous vigilance and adaptation. Regular monitoring, testing of security controls, and keeping abreast of updates to the PCI DSS are essential to ensure your environment remains secure and compliant. Here are key strategies to maintain and monitor your PCI DSS compliance effectively:

Continuous Monitoring of Security Controls

• Implement Automated Tools: Utilise security information and event management (SIEM) systems, intrusion detection systems (IDS), and intrusion prevention systems (IPS) to continuously monitor your network for suspicious activities and potential breaches.
• Regular Reviews: Conduct regular reviews of system configurations, access controls, and logs to ensure that only authorised access is occurring and that any anomalies are quickly identified and addressed.
• Change Management: Maintain a robust change management process to ensure that any changes to the cardholder data environment are documented, reviewed, and tested before implementation.

Regular Testing of Security Systems and Processes

• Vulnerability Scanning: Conduct quarterly vulnerability scans with an Approved Scanning Vendor (ASV) to identify and remediate vulnerabilities within your systems.
• Penetration Testing: Perform annual penetration testing to simulate an attack on your systems from both outside and inside your network. This helps to identify weaknesses that could be exploited by an attacker.
• Internal and External Audits: Schedule regular internal audits to review compliance with PCI DSS requirements and prepare for external audits by Qualified Security Assessors (QSAs) or Internal Security Assessors (ISAs).

Stay Updated with PCI DSS Revisions

• PCI DSS Updates: The PCI Security Standards Council (PCI SSC) periodically updates the PCI DSS to address emerging threats and technologies. Stay informed of these updates and understand how they may affect your compliance posture.
• Training and Awareness: Keep your team informed about the latest PCI DSS requirements and security best practices through ongoing training programs. Security awareness among staff is crucial to maintaining a secure environment.
• Participate in Security Communities: Engage with online forums, attend conferences, and participate in workshops related to PCI DSS and cybersecurity. Networking with peers can provide insights into compliance challenges and solutions.

Ensure Continuous Compliance through Daily Operations

• Integrate Compliance into Business Processes: Make PCI DSS compliance a part of your daily business operations. Incorporate compliance checks into routine activities to ensure continuous adherence to security policies and procedures.
• Document Policies and Procedures: Maintain up-to-date documentation of all policies, procedures, and technical configurations related to PCI DSS compliance. This documentation is vital for both maintaining compliance and facilitating future audits.
• Respond to Incidents Swiftly: Have an incident response plan in place and ensure all staff are familiar with their roles in the event of a security breach. Quick response to incidents is critical to minimising impact and maintaining trust.

Reassess and Adapt

• Annual Review: Conduct an annual reassessment of your PCI DSS compliance to identify any changes in your environment or operations that might affect your compliance status.
• Continuous Improvement: Use the insights gained from monitoring, testing, and audits to continuously improve your security posture. Compliance is a baseline, not the ceiling, for security. 

Maintaining PCI DSS compliance requires a commitment to security best practices and a proactive approach to monitoring, testing, and updating security controls and processes. By embedding these practices into your organisation's culture, you can ensure that protecting cardholder data becomes a natural part of your business operations, keeping your data secure and your customers confident in your commitment to their privacy and security.

Conclusion

Achieving and maintaining PCI compliance is crucial for the security of your e-commerce transactions and the protection of sensitive cardholder information. By following this step-by-step guide, businesses can ensure they meet industry standards and protect their customers' data effectively.

ProCheckUp's PCI DSS Solution's

• PCI-ASV (Approved Scanning Vendor) Services: ProCheckup, a globally recognized ASV, conducts meticulous external vulnerability scans to ensure the integrity of systems handling credit card data, in compliance with PCI-DSS requirement 11.3.2. Our ASV scan solution leverages cutting-edge security tools to rigorously test and confirm your network's defenses against known threats, helping to secure your data transactions. (Learn More)
• PCI QSA (Qualified Security Assessor) Services: As an independent QSA firm accredited by the PCI Security Standards Council, ProCheckup embodies excellence in ensuring entities meet the stringent standards of PCI DSS. Our longstanding expertise, since the establishment of the QSA program, provides reliable validation of your compliance posture. (Learn More)
• Penetration Testing: ProCheckup's penetration testing services are an embodiment of our commitment to security excellence, meeting PCI-DSS requirement 11.4.1. Our team of Crest, Cyberscheme, and NCSC-qualified penetration testers, with a proven 24-year track record since 1999, employs a comprehensive approach to identify and remediate exploitable security vulnerabilities. (Learn More)
• Data Discovery for Primary Account Number (PAN): Our specialized services extend to the detection of PAN within your network, particularly identifying unauthorized storage locations outside the Cardholder Data Environment (CDE), adhering to PCI-DSS requirement 12.5.2. ProCheckup ensures that sensitive payment data is contained and managed securely. (Learn More)
• Segmentation Testing: With precise technical testing, ProCheckUp validates the efficacy of network segmentation, ensuring that the CDE is isolated from all systems not pertinent to card processing , in compliance with PCI-DSS requirement 11.4.5 This critical service supports PCI-DSS compliance by verifying the robustness of segmentation controls, maintaining the security of your cardholder data environment. (Learn More)