PCI DSS Requirements

Table of Contents show

What are the requirements of the PCI DSS?

PCI DSS requirements apply to all system components, including people, processes and technologies included in the cardholder data or cardholder data environment, and to the storage, processing or transmission of card data linked to that environment.

All organizations are required to meet a total of 12 PCI DSS requirements. Compliance requirements vary depending on the type and volume of transactions carried out by the company and are determined by the acquiring bank.

Compliance with PCI DSS Requirements may seem challenging and time-consuming. Still, the requirements will allow you to build a robust data security foundation to protect your company and sensitive card data.

The PCI DSS requirements and descriptions can be found below. You can visit the related requirement page for detailed explanations.

12 PCI DSS Requirement

pci dss requirements
12 pci dss requirements

Build and maintain a Secure Network and System

PCI DSS Requirement 1: Configure and use firewalls to protect cardholder data

pci dss requirement 1
pci dss requirement 1

See Also: PCI DSS Requirement 1 Explained

Firewalls control the transmission of data between trusted internal networks and untrusted external networks within a company and traffic in sensitive areas of internal networks.

PCI DSS Requirement 1 requires firewalls to prevent unauthorized system access. If other system components provide the capabilities of the firewall, those systems should also be included in the scope of the requirement.

PCI DSS Requirement 1.1: Create and implement standards for configuration of firewalls and routers

Configuration standards for all firewalls and routers covered by the PCI should be established, reviewed regularly and ensured that the standards are enforced.

Changes to firewalls and routers must be checked and approved.

Network diagrams indicating the scope of the PCI should be created, analyzed, and connections to the cardholder data verified.

Card data flow diagrams should also be created to ensure that they represent all cardholder data on the network and are updated regularly.

A firewall should be used between all Internet connections and demilitarized zones (DMZ) and the local network with access and exit to the network.

The groups, roles and responsibilities used to manage the network components should be defined.

The security measures applied to protocols considered to be unsafe should be documented. Business rationale and approval documents shall be drawn up for the use of all services, protocols, and ports permitted.

Router and firewall configuration rules should be checked and reviewed every six months to identify and remove old, irrelevant or unsafe rules.

PCI DSS Requirement 1.2: Create a firewall and router configuration that restricts connections between untrusted networks and all system components in the cardholder data environment.

Firewalls must be used between a trusted internal network and an untrusted external network.

Limit inbound and outbound network traffic only to the connections required for the data medium of the cardholder and specifically reject all other traffic.

Secure and save the configuration files of the router and synchronize them with all relevant devices.

Install firewalls between all wireless networks and the data environment of the cardholder and configure them to block traffic. If this traffic is required for business purposes, it will only allow traffic between the wireless medium and the data medium of the cardholder.

PCI DSS Requirement 1.3: Restrict direct global access to any system component of the cardholder data medium over the internet.

Create a demilitarized zone (DMZ) to limit incoming traffic to system components that provide only publicly accessible authorized services, protocols and ports.

Limit incoming Internet traffic to only IP addresses located within the demilitarized zone ( DMZ).

Apply anti-spoofing measures to the IP anti-counterfeit firewall to detect and block the entry of counterfeit IP addresses to the network. For example, block internet traffic with a local IP address.

Prevent and prevent unauthorized traffic from the cardholder data environment to the Internet environment.

Allow connections to pre-established connections to the network only.

Position system components that store cardholder data in a network zone that differs from the demilitarized zone (DMZ) and other unreliable networks.

Do not disclose private IP addresses and route information to unauthorized parties. Avoid the identification and viewing of local network information over an external network using methods such as NAT or proxy servers.

PCI DSS Requirement 1.4: Install personal firewall software on all mobile devices that are connected to the internet and used to access the network when they are out of the network.

It is necessary to set up a personal firewall on all portable computing devices that connect to the internet outside the local network and also to access cardholder data and ensure that it works actively.

Unique configuration settings must be defined for a firewall that satisfies installation requirements and must be configured in such a way that the device user cannot change the settings of the firewall software.

PCI DSS Requirement 1.5: Make sure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

Relevant employees should be fully aware of the organization’s security policies and operational procedures to ensure continuous and desired management of firewall and router configurations.

PCI DSS PCI DSS Requirement 2: Do not use the vendor’s default settings for system passwords and other security parameters

pci dss requirement 2
pci dss requirement 2

See Also: PCI DSS Requirement 2 Explained

Default configuration settings and values are well known to attackers for many typical applications and devices, and attackers can easily use these default values.

The default settings and values provided by the manufacturer must therefore be changed, and unnecessary default accounts disabled or deleted before any system is installed on the network. This requirement applies to all of the default passwords without exception.

PCI DSS Requirement 2.1: Always change the default settings and values ​​provided by the manufacturer and remove or disable unnecessary default accounts before installing any system on the network.

This rule applies to all devices, applications and systems within the scope of PCI. The default accounts and settings of all devices, applications, and systems covered under the PCI should be removed or disabled.

Also, change the default settings and values for all wireless systems, including default wireless encryption keys, passwords, and SNMP community strings, for wireless environments that connect or transmit cardholder data.

PCI DSS Requirement 2.2: Create configuration standards for all components of the system.

Make sure that the configuration standards address all known vulnerabilities and are consistent with industry-accepted hardening system standards.

Functions requiring different levels of security should not be run on the same server. The system configuration should be checked to ensure that only one primary function is running on a single server. For example, web servers and database servers need to be installed and run on separate servers.

In the case of using virtualization technologies, it is necessary to run a server that performs only one primary function per virtual system component.

Enable only the functions, protocols and services needed for the system to work. Remove unnecessary functions, protocols, and services from the system. Implement additional security measures for functions, protocols or services that are considered unsafe but required for the system to operate.

PCI DSS Requirement 2.3: Encrypt all non-console administrative access to devices using strong encryption.

Use technologies such as SSH, VPN or SSL / TLS for all web-based and non-console other administrative access. You should also verify that unsafe remote login commands are not used by reviewing parameter and configuration files for non-console access.

PCI DSS PCI DSS Requirement 2.4: Keep an inventory of all PCI DSS in-scope system components.

The list of software and hardware components should be kept up-to-date by checking to ensure compliance. Some system components may be forgotten when inventory is not maintained or updated and may result in under-definition of PCI coverage.

PCI DSS Requirement 2.5: Make sure that security policies and operational procedures are documented, in use, and known to all affected parties to manage the manufacturer’s default values ​​and other safety parameters.

Employees need to be aware of and know about their organization’s information security policies and daily business procedures. To this end, the implementation of the policy should be reviewed. Also, all stakeholders should be made aware of the documentation.

PCI DSS Requirement 2.6: Shared hosting service providers must protect the environment and cardholder data hosted by each organization.

This requirement is designed for hosting service providers that offer hosting on a single server and share the system for multiple customers. Compliance with these requirements aims to protect the cardholder data of shared hosting service providers in shared environments by providing a secure environment.

Shared hosting service providers must meet the specific PCI DSS requirements in the annex created for PCI DSS Appendix A1: Shared Hosting Providers.

Protect cardholder data

PCI DSS Requirement 3: Protect stored cardholder data

pci dss requirement 3
pci dss requirement 3

See Also: PCI DSS Requirement 3 Explained

Cardholder data storage should be kept to a minimum, and appropriate policies, protocols and mechanisms for data protection and destruction should be put in place. Data such as card chip or magnetic strip content, CVN (card verification number) or PIN (personal identification number) should never be stored.

When data needs to be stored, the data must be stored securely. The critical components of cardholder data protection are encryption, trimming, masking and hashing. Even if attackers bypass other security checks, encrypted data will not be able to be read and used without accessing appropriate cryptographic keys.

For this reason, the cryptographic keys must be stored securely and limited to the minimum number of custodians that need access.

PCI DSS Requirement 3.1: Keep cardholder data storage to a minimum by developing and implementing policies, procedures and processes for data retention and destruction of cardholder data (CHD)

Compliance with this requirement can be achieved through the establishment of an official policy on data retention. The policy will determine what kind of data should be protected and what data should be destroyed if it is no longer needed.

Limit the amount and duration of data storage and retention to the time required for regulatory or business requirements.

Create custom retention requirements for cardholder data.

Create processes to securely delete and destroy data when it is no longer needed.

Scan cardholder data every three months that exceeds the retention period specified in the procedures and, if found, securely delete it.

PCI DSS Requirement 3.2: Do not store sensitive authentication data after authorization, even if it is encrypted.

When sensitive authentication data arrives, delete all data irreversibly after the authorization has been completed.

If there is a business reason for storing sensitive data, and the data is stored securely, it is permitted for organizations that provide services to store sensitive authentication data.

Do not store the content of the magnetic stripe on the back of the card or data on the chip after authorization. As an alternative to these data, full track, track, track 1, track 2, and magnetic stripe data is also called.

In everyday business processes, data items such as the cardholder’s name, primary account number (PAN), expiration date, and service code may be stored in the magnetic stripe. To minimize the risk, keep only the data items needed for the job.

After authorization, do not store the verification code or value of the card. (CVV – three-digit or four-digit number printed on the front or back of the payment card used to verify transactions not done with the physical card)

Do not store your personal identification number (PIN) or encrypted PIN block after authorization.

PCI DSS Requirement 3.3: If the primary account number (PAN) has to be displayed, mask it to view it.

The maximum number of digits that can be displayed is the first six and last four digits of the primary account number. Only staff with legitimate business needs can see more than the first six and the last four digits of the card number.

PCI DSS Requirement 3.4: Make the primary account number unreadable wherever it is stored.

The primary account number (PAN), including portable digital media, backup media and logs, should be meaningfully unreadable at all locations where it is stored.

After an operation, the primary account number (PAN) can be stored, but it must be rendered unintelligible using methods such as encryption, Truncation or hashing (Hashing).

If the disk encryption method is used, logical access should be managed separately and independently from the local operating system authentication and access control mechanisms. Also, decryption keys should not be associated with user accounts.

PCI DSS Requirement 3.5: Create and implement procedures to protect the keys used to protect stored cardholder data from disclosure and misuse.

The protection of cryptographic keys is vital because unauthorized access to the key means that the data can be decrypted and used for malicious purposes.

The keys should be stored at the least possible location, and the fewest people should be able to access them. Key encryption and data encryption keys should also be stored separately.

Service providers should create an explanatory document about cryptographic processes. The cryptographic process document should include details of all algorithms, protocols and keys used to protect cardholder data, including key strength and expiration date.

PCI DSS Requirement 3.6: Document and implement all key management processes and encryption key procedures used to encrypt cardholder data.

Key management documents should include key management components such as the creation of strong encryption keys, the secure distribution of cryptographic keys and the secure storage of encryption keys.

For keys which have reached the end of their encryption life, encryption key changes must be made per industry standards.

The keys must be removed or replaced if the integrity of the key is weakened or exposed.

If manual clear-text encryption key management operations are used, these operations should be managed using methods such as split information and dual control.

Unauthorized replacement of cryptographic keys should be prevented, and cryptographic key officials must formally acknowledge that they understand and accept their responsibilities.

PCI DSS Requirement 3.7: Security policies and operational procedures must be documented, used and known to all affected parties to protect stored cardholder data.

Staff should be regularly informed about security policies and procedures to manage the secure storage of cardholder data to meet this requirement.

PCI DSS PCI DSS Requirement 4: Encrypt cardholder data when transmitting over open, public networks

pci dss requirement 4
pci dss requirement 4

See Also: PCI DSS Requirement 4 Explained

Strong cryptographic encryption and security protocols should be used to protect confidential cardholder data during transmission over open, public networks that malicious attackers can easily access. Examples of public networks are technologies such as the internet, wireless technologies, GPRS, and communications via satellite.

Implementing authentication and robust encryption procedures must follow industry best practices. Also, security policies and procedures for encrypting cardholder data transmission should be documented and communicated to all interested parties.

PCI DSS Requirement 4.1: Use strong encryption and security protocols to protect sensitive cardholder data during transmission over open, public networks.

Only trusted encrypted keys and certificates should be accepted and used in encryption. Only secure versions and configurations of the protocols used should be supported. Encryption strength should be appropriate for the encryption methodology used.

Wireless networks that transmit cardholder data or are connected to the cardholder data environment should use an authentication mechanism, and robust methods of encryption should be used.

PCI DSS Requirement 4.2: Never send Primary Account Number (PAN) information without password over end-user messaging technologies.

This requirement ensures that personal account numbers are never transmitted in encrypted or plain text format via communication channels such as e-mail, chat, or instant messaging.

Besides, a written policy should be applied to ensure that the transmission of unprotected or unencrypted primary account number information (PAN) over end-user messaging platforms is prohibited.

PCI DSS Requirement 4.3: To encrypt the transmission of cardholder data, ensure that security policies and operational procedures are documented, in use, and known to all affected parties.

Strict policies and procedures are required to secure the cardholder data transmitted over the network. Certificate usage with robust encryption procedures, encrypted protocols and a secure key will ensure sensitive data transmission security.

These policies and procedures should be explained to each person, and it should be ensured that they are accepted and followed by everyone.

PCI DSS PCI DSS Requirement 5: Protect all systems against malware and update anti-virus software regularly.

pci dss requirement 5
pci dss requirement 5

See Also: PCI DSS Requirement 5 Explained

Anti-virus applications that can identify malware and protect systems by neutralizing it should be installed on all systems that are frequently affected by malware.

Evolving software threats should be analyzed regularly to determine whether antivirus software is required. Antivirus systems must be actively working and effective. Anti-virus systems should be disabled if approved by the authorized person.

PCI DSS Requirement 5.1: Install anti-virus software on all systems that are commonly affected by malware.

Install anti-virus software on all frequently affected systems, especially personal computers and servers, to protect against malware.

Make sure that anti-virus software can detect all known types of malware and quarantine to protect the systems.

Identify constantly evolving malware threats and make regular assessments for systems that are not considered to be widely affected by malware.

PCI DSS Requirement 5.2: Make sure all anti-virus mechanisms are working properly

A regular update of the anti-virus software is essential. Even beneficial anti-virus software that does not have new virus information and is not updated periodically will not be sufficient.

Virus definitions of anti-virus software should be updated regularly, periodically scanned and logged.

PCI DSS Requirement 5.3: Anti-virus software should work effectively and cannot be disabled by users.

Anti-virus software should work effectively and should not be disabled by users at any time, except when the administrator disables it for a limited time.

Anti-virus software can only be temporarily disabled by the administrator if there is a technical need. Where anti-virus protection has to be disabled for a particular purpose, the necessary records must be created for this process. Additional security measures may be required during the period when anti-virus protection is inactive.

PCI DSS Requirement 5.4: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to protect systems against malware.

To ensure that every employee is aware of the organization’s security policies and operational procedures, and to provide the maximum protection of the network from malware, institutional policies and procedures for anti-malware should be established and communicated to staff.

PCI DSS Requirement 6: Develop secure systems and applications

pci dss requirement 6
pci dss requirement 6

See Also: PCI DSS Requirement 6 Explained

Organizations should develop a mechanism to identify and rank vulnerabilities by risk levels. Critical security patches must be applied within one month of being released to ensure the security of cardholder data is not compromised.

All software applications developed internally or externally must be developed safely and securely following the PCI DSS guidelines. Software applications should also be based on industry standards and best practices, and information security should be included in all software development processes.

PCI DSS Requirement 6.1: Identify vulnerabilities using reputable external sources and create a risk ranking for newly discovered vulnerabilities.

You should develop a system that regularly monitors advancements for possible vulnerabilities. This monitoring can be done through some sources that can be accessed by signing up for newsgroups, mailing lists, RSS feeds or trusted websites.

Risk ranking should be established, taking into account industry best practices and the potential impact of the deficit. Among the criteria for ranking vulnerabilities, the CVSS base score or the classifications made by the manufacturer can be used.

Methods for assessing vulnerabilities and assigning risk ratings vary depending on an organization’s environment and risk assessment strategy. Risk ranking should at least identify all vulnerabilities that are considered “high risk” for the environment.

PCI DSS Requirement 6.2: Install valid security patches provided by the vendor to ensure that all system components and software are protected from known vulnerabilities.

Install critical level patches within one month of release. Critical security patches should be identified according to the risk rating process. Low-grade vulnerabilities patches can be installed within 2 to 3 months.

PCI DSS Requirement 6.3: Securely develop all software applications

Follow basic PCI DSS guidelines such as secure authentication and creating audit trails on software developments. Use industry standards and best practices in software development. Include information security throughout the software development lifecycle. These rules apply to all software developed internally, as well as special software developed by a third party.

Remove development, test, or custom app accounts, user IDs, and passwords before bringing apps to life.

Perform source code review using manual or automated methods before bringing applications to live environment.

Code changes should be reviewed by people familiar with code review techniques and secure coding practices, except the source code developer.

Source code reviews should check that the code has been developed in accordance with secure coding guidelines. Vulnerabilities found as a result of the inspection must be corrected and approved by the manager before the code is put live.

Source code reviews are valid for all custom code as part of the system development lifecycle. An experienced staff or third parties can do code reviews.

PCI DSS Requirement 6.4: Create change control processes and follow procedures for all changes in system components.

Separate development/test environments from production environments and restrict access with access control mechanisms. Development/test environments and production environments should be managed by considering the separation of duties.

Actual card data should not be used in test or development environments. Test data and accounts must be removed from system components before the system goes live.

Change control procedures should include impact analysis, change confirmation approved by authorized parties, functionality testing to verify that the change does not adversely affect the security of the system, and procedures for withdrawing changes.

In the event of a significant change in the PCI environment, all relevant PCI DSS requirements should be applied to modified systems and networks, and documents should be updated accordingly.

PCI DSS Requirement 6.5: Identify and fix common vulnerabilities in software development processes.

Software developers should receive secure code development training at least once a year. Develop applications based on secure coding practices and update training and procedures when industry best practices for vulnerability management are updated. You can monitor security vulnerabilities from reliable sources such as OWASP, SANS CWE Top 25 and CERT Secure Coding.

PCI DSS Requirement 6.6: Continuously monitor new threats and vulnerabilities for open web applications and ensure that these applications are protected against known attacks.

Scan web applications at least once a year and after any changes, either manually or by automated vulnerability scanning tools.

Install an automated technical solution, such as a web application firewall that can detect and block web-based attacks in front of web-enabled applications.

PCI DSS Requirement 6.7: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to develop secure systems and applications.

Secure software development processes and procedures should be established in detail, and relevant employees should be provided with code development activities according to these documents. It is recommended that the review process be conducted and reported annually to keep all appropriate documentation up to date.

Implement strong access control measures

PCI DSS Requirement 7: Restrict access to cardholder data based on business requirements

pci dss requirement 7
pci dss requirement 7

See Also: PCI DSS Requirement 7 Explained

Misuse of authorized accounts and user privileges is one of the easiest ways for attackers to access a system. This type of attack is, at the same time, one of the most challenging types of attack to detect. Therefore, documented processes should be created to limit access rights to critical data.

Access control mechanisms should deny all access by default. Access should be given according to the “need to know” principle and the defined job responsibilities of authorized personnel.

The “need to know” principle is that access rights are granted for the least amount of data and privileges required to perform a job.

PCI DSS Requirement 7.1: Limit access to system components and cardholder data only to those who need it for their job functions.

Define the access needs of each role. Identify the system components and data sources that each role must have access to for business functions.

Determine the levels of privilege required to access resources. Restrict access to privileged user IDs to the minimum necessary privileges to fulfill job responsibilities.

Assign access to employees based on job classification and function. Approval of authorized persons is required for authorization and privilege definitions.

PCI DSS Requirement 7.2: Create secure access control systems.

An access control system must be set up for system components which restrict access based on the “need to know” principle and which are set to “deny all” unless specifically allowed.

When more people are allowed to access the data, it is more likely that the data will be misused. Only persons with a real reason should therefore be allowed access.

Access control should cover all components of the system. Privileges should be granted to employees based on job classification and function.

PCI DSS Requirement 7.3: Ensure that security policies and operational procedures to restrict access to cardholder data are documented, in use, and known to all affected parties.

All security policies and procedures regarding limited access to cardholder data should be documented, implemented and communicated to all interested parties.

PCI DSS Requirement 8: Identify and authenticate access to system components

pci dss requirement 8
pci dss requirement 8

See Also: PCI DSS Requirement 8 Explained

In addition to ensuring that network access is limited to those with appropriate authority, the identification of individual users provides an audit trail that can be reviewed after any violation. Therefore, documented policies and procedures should be implemented to ensure proper monitoring of user identity across all aspects of the system for administrator accounts.

All users should be assigned a unique identity, and identity identification should be managed according to specific guidelines. Controlled user-authentication management should be implemented, and MFA (multi-factor authentication) mechanism should be used for remote access connections.

PCI DSS Requirement 8.1: Define and implement policies and procedures to ensure correct user identity management for users and administrators across all system components.

Identify a unique identity to all users before allowing them to access system components or cardholder data.

Control the addition, deletion, and modification of user IDs, credentials, and other identifying objects.

Immediately revoke access for user accounts that are not used for any reason. Inactive user accounts should be removed or disabled within 90 days.

Enable accounts that are used by third parties for remote access, support or maintenance of system components only for the time required and disable them when not in use. Monitor these accounts during use as well.

Limit repeated access attempts by locking the user ID after six attempts. Set the lockout time to at least 30 minutes or to enable an administrator user account.

If the session has been idle for more than 15 minutes, force the user to re-authenticate to re-activate the terminal or session.

PCI DSS Requirement 8.2: Provide appropriate user authentication management for users and administrators in all system components.

To verify all user identities, use something you know, such as a password, something you have like a smart card, and at least one of the methods you have, such as biometrics.

Make all authentication information unreadable using strong encryption during transmission and storage in all system components.

Verify user identity before changing any authentication information.

Passwords must be at least seven characters long, both numerical and alphabetic. Alternatively, the complexity and strength of the passwords should at least be equivalent to the specified parameters.

Change user passwords at least every 90 days. Do not allow replacing the last four passwords used with a new password that is the same as anyone.

Generate first-time passwords for each user to have a unique value and force them to be changed immediately after the first use.

PCI DSS Requirement 8.3: Secure all individual administrative access to the CDE and all remote access to the CDE using multi-factor authentication.

Multi-factor authentication requires at least two of the three authentication methods to be used for authentication purposes. Using a factor twice is not considered to be multi-factor authentication; it is called a multi-step authentication.

Set up a multi-factor authentication mechanism for all remote network accesses, including both user and administrator, and third-party access for support or maintenance.

PCI DSS Requirement 8.4: Document and communicate authentication policies and procedures to all users

Choosing strong authentication information means using a strong password that no one else can guess.

Procedures should include selecting strong authentication information, how to protect users’ authentication information, instructions not to reuse previously used passwords, and password change instructions if passwords are exposed.

PCI DSS Requirement 8.5: Do not use group, shared or public IDs, passwords or other authentication methods.

When multiple users use the same passwords or user account, it is not possible to track the responsible person in the event of a security breach. Each user should have different credential and passwords to prevent this from happening.

Public user IDs should be disabled or removed. User IDs for system management and other critical functions should not be shared. Shared and public user IDs should not be used to manage any components of the system.

Service providers with remote access to customer facilities (e.g. to support POS systems or servers) must use unique authentication information for each customer. This requirement does not apply to shared hosting providers where multiple client environments are hosted.

PCI DSS Requirement 8.6: Where other authentication mechanisms are used, the use of these mechanisms should be assigned as follows.

Other authentication mechanisms may include physical or logical security tokens, smart cards or certificates.

If multiple accounts are allowed to use user authentication methods such as smart cards, tokens, and certificates, it is not possible to track a single user for a specified time.

Physical or logical controls, such as passwords, PINs or biometric data, should be implemented to ensure that each user is uniquely identified and unauthorized users cannot access it through a shared authentication process.

Authentication mechanisms should be assigned to a separate account and should not be shared. Physical or logical controls must be in place to ensure that only the account created to gain access can use this mechanism.

PCI DSS Requirement 8.7: Limit all access to any database containing cardholder data.

The configuration settings for the database and application should be reviewed to ensure that each user is authenticated before access is granted.

All user access to databases, user queries and user actions must be done through programs. Only database administrators should be able to access the databases directly or to query them. Application IDs for applications in the database can be used only by applications, not users or other non-applications.

PCI DSS Requirement 8.8: Ensure that security policies and operational procedures for authentication and identification are documented, in use, and known to all affected parties.

Ensure security policies and operational procedures for processes of authentication and identification are documented, in use, and known to all concerned parties. Employees should be routinely informed about security policies and authentication and identification procedures.

PCI DSS Requirement 9: Restrict physical access to cardholder data

pci dss requirement 9
pci dss requirement 9

See Also: PCI DSS Requirement 9 Explained

Electronic data breaches are not the only reason for data loss. The use of adequate controls should also restrict and monitor physical access to systems. Procedures to distinguish between employees and visitors should be followed, and physical access to sensitive areas should be limited accordingly.

All environments must be securely protected and monitored for use, access and distribution. When it is not necessary, media containing sensitive data should be destroyed safely. Devices that receive payment card data through direct physical interaction with the card must be protected from replacement and periodically inspected. Besides, an updated list of these devices should be kept.

PCI DSS Requirement 9.1: Create and use appropriate facility access controls to limit and monitor physical access to systems in the cardholder data environment.

Physical security measures should be implemented in data centers, server rooms and all other facilities where confidential data is stored, thus preventing unauthorized access.

Video cameras or access control mechanisms should be used to monitor physical access in sensitive areas. The data collected needs to be reviewed and compared with other entries. Recorded data should be kept for at least three months unless otherwise required by law.

Sensitive areas refer to any data center, server room, or any place that hosts systems that store, process, or transmit cardholder data.

Perform physical or logical controls to restrict access to public network connectors. Restrict physical access to gateways, wireless access points, handsets, network equipment and telecommunications lines.

PCI DSS Requirement 9.2: Develop procedures to distinguish between staff and visitors easily.

Each visitor entering the facility should be checked for authorization, and the mechanisms for distinguishing visitors from employees should be available.

Use distinctive badges to distinguish between employees and visitors. Revoke expired visitor IDs or reset their privileges.

PCI DSS Requirement 9.3: Restrict physical access to sensitive areas for employees as follows.

Access to sensitive areas should only be granted to employees who have business needs and the authority to visit sensitive areas.

Access should be canceled immediately after termination and all physical access mechanisms, such as keys or access cards originally issued for entry, must be returned.

When the authorized person’s visit to a sensitive area has ended, all access permissions must be withdrawn from them, and they will not be able to reaccess the CDE without authorized permission.

PCI DSS Requirement 9.4: Follow procedures to identify and empower visitors.

Robust procedures should be implemented to check whether visitors are authorized to enter sensitive areas of the facility. Such measures and controls will help reduce unauthorized access to the cardholder data environment by malicious individuals.

Before entering areas where cardholder data is processed or maintained, visitors must be authorized and must be received in sensitive areas by the accompaniment.

A badge or other identity should be provided that visually separates visitors from the staff. Visitors must deliver the badge or ID before leaving the facility or when it expires.

The visitor log should be used to keep a physical audit trail of visitor activity, as well as computer rooms and data centers where cardholder data is stored or transmitted.

The name of the visitor, the company, represented, and the person who gives physical access should be documented and recorded in the diary. Visitor logs and records should be kept for at least three months unless otherwise required by law.

PCI DSS Requirement 9.5: Protect all media that contains physically sensitive data

Cardholder data is at risk if it is kept unprotected in the system if it is written on a piece of paper on a table or stored unsafely in portable media. Sensitive data backup should also be stored securely and in a secure environment.

Sensitive data backups should be stored in a secure location, preferably in an alternative or backup data center. The safety of the area where sensitive data are stored should be reviewed at least once a year.

PCI DSS Requirement 9.6: Have strict control over the internal or external distribution and transmission of any media.

Cardholder data should not be distributed in electronic or paper format unless it is deemed necessary. For compliance, a strict media distribution policy is required.

All media devices must be classified to identify which of them contains sensitive data. Records should be kept for all media sent outside the company and ensure that they are sent and tracked by a reliable courier.

PCI DSS Requirement 9.7: Have strict control over media storage and accessibility.

If a secure media inventory is not maintained, the lost or stolen media may not be detected for a long and indefinite time. There should be a documented media storage policy, and an inventory should be maintained periodically.

Store all media inventory logs appropriately, and review and edit media inventory at least once a year.

PCI DSS Requirement 9.8: Destroy media when it is no longer needed for business or legal reasons.

Printed materials must be crushed, burned or pulped in such a way that they cannot be regenerated. Safe storage containers or warehouses should be used for the destruction of the media.

Cardholder data must be rendered unrecoverable in an electronic environment so that cardholder data cannot be re-created.

PCI DSS Requirement 9.9: Protect devices that receive payment card data through physical interaction from tampering and replacement.

This requirement applies to card-reading devices used in physical card transactions at the point of sale.

All personnel should be conscious of detecting any suspicious activity and promptly notify any tampering or replacement on the device. Therefore, employees should be given regular training on tampering or replacing devices.

An updated device list should be maintained, and the list should include the brand, model of the device, location of the device, serial number of the device, or other unique identification information. All devices should be checked periodically to check for any replacements or tampering.

The device surface should be inspected regularly to detect tampering or replacement. Examples of signs that a device may be tampered with or replaced include unexpected attachments or cables attached to the device, missing or altered security labels, changes to the broken or differently colored body or serial numbers, or other external signs.

Verify the identity of third-party parties claiming to be repair or maintenance personnel before giving them access to replacement or troubleshooting. Do not install, replace or return devices without verification.

Be aware of suspicious behavior around devices. When suspicious behavior is observed, it should be reported immediately to authorized persons for examination.

PCI DSS Requirement 9.10: Ensure that security policies and operational procedures to restrict physical access to cardholder data are documented, in use, and known to all affected parties.

All security policies and operational procedures to restrict physical access to cardholder data should be formally documented, implemented within the organization, and communicated directly or indirectly to all parties involved in the storage, processing and transmission of cardholder data.

Monitor and test networks regularly.

PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data

PCI DSS Requirement 10
PCI DSS Requirement 10

See Also: PCI DSS Requirement 10 Explained

The use of log mechanisms is critical to preventing, detecting and minimizing data security threats. When activities related to system users are not logged, a possible violation cannot be identified. For this reason, it is necessary to implement safe and controlled control ways that connect all access to system components with individual users and record their actions.

These audit paths include access to cardholder data, access to audit mechanisms, actions performed by administrator rights, use and modification of identification and authentication systems, invalid access attempts, stopping or pausing audit logs, and creating and deleting the system.

At least quarterly audit logs should be kept ready for immediate analysis. All log files should be kept for a minimum of one year. Records and security events should be reviewed regularly to identify abnormal or suspicious activity.

PCI DSS Requirement 10.1: Create a process that connects access to system components to each user.

It is essential to keep track of all access to the system components, making it easier to check which user is responsible for the change in the event of an unwanted change to the network.

Each user, in particular the administrators, should be monitored over the network and checked for their activities. A regular report should be created, giving a list of users accessing specific system objects.

PCI DSS Requirement 10.2: Set up an automatic log review mechanism to reproduce events.

When access to system components is tracked manually, the more components there are, the more likely important events are to be missed. For this reason, it is recommended that the access monitoring, control and reconstruction procedures be automated.

Events to be followed are as follows:

  • All individual user access to cardholder data
  • All operations performed by any person with root or administrator privileges
  • Access to all audit mechanisms
  • Invalid physical access attempts
  • Creating new accounts and elevating privileges
  • All changes, additions or deletions on accounts with root or administrator privileges
  • Starting, stopping, or pausing audit logs
  • Creating and deleting system-level objects

PCI DSS Requirement 10.3: Record at least the following information for events occurring in all system components:

  • User ID
  • Event type
  • Date and time
  • Success or Failure Indicator
  • The Origin of the Event
  • Identity or name of the affected data, resource, system component

It is essential to record events logged with this information to quickly and easily identify any data breach, who, when, where, what and how to do it.

PCI DSS Requirement 10.4: Synchronize all critical system clocks and times using time synchronization technology.

Time synchronization technology helps to synchronize the clocks of system components. If these clocks are not synchronized correctly, it won’t be easy to compare different log files on other systems to create appropriate system events and event schedules.

With time synchronization, critical systems are expected to have accurate and consistent time. Time data should be maintained, and time settings should be obtained from time sources accepted by the industry.

PCI DSS Requirement 10.5: Keep the logs in a way that cannot be altered.

Changing logs can pose a serious security threat because, in the event of a breach of the information, no real log data will be found and it will not be possible to identify the person responsible for the actual reason. For this reason, log files must be stored in such a way that they cannot be changed.

Limit log viewing to those with business needs, protect log files from unauthorized changes.

Forward and back up log files to a central log server that is difficult to modify and access.

Use file integrity monitoring or change-detection software in log files to ensure that existing log data cannot be changed without generating any warning.

PCI DSS Requirement 10.6: Regularly review logs and security events for all system components to identify abnormalities or suspicious activity.

All system components that store, process, transmit or indirectly affect cardholder data should be examined and reviewed in the logs. Automated log collection, separation, inspection and warning tools can be used to meet this requirement.

The following log events should be reviewed and reviewed:

  • All security incidents
  • Logs of all components of the system that store, process or convey cardholder data
  • Logs of all crucial components of the system
  • Logs of servers and system components that perform security functions

The logs of all other system components should be reviewed according to organization policies and risk management strategy as determined by the organization’s annual risk assessment.

Necessary actions should be taken regarding exceptions and abnormalities detected during the review process.

PCI DSS Requirement 10.7: Retain the log history for at least one year and have at least three months of data ready for analysis.

Audit logs should be kept for at least one year and log records of at least three months should be kept ready for review.

Requirement 10.8: Create and implement processes for timely detection and reporting of failures of critical security control systems for service providers.

This requirement only applies to service providers. Examples of critical security control systems include firewalls, IDS / IPS systems, file integrity monitoring software (FIM), antivirus software, physical access controls, logical access controls, audit logging mechanisms and segmentation controls if used.

Failures or warnings of critical security systems should be responded to promptly. Processes to respond to errors or warnings in security audits should include the following items:

  • Restoring security functions
  • Determining and documenting the duration of the security failure
  • Identifying and documenting the causes of the error
  • Necessary analysis to eliminate the root cause of the error
  • Identify and resolve security issues that arise during a malfunction.
  • Carry out a risk assessment to ascertain if other actions are required due to a security failure.
  • Applying necessary controls to prevent recurrence of the cause of failure
  • Ensuring the continuation of log production of security controls

PCI DSS Requirement 10.9: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to monitor all access to network resources and cardholder data.

Employees should be informed of all security policies and procedures and ensure that the procedures created are in use.

PCI DSS Requirement 11: Test security systems and processes regularly

PCI DSS Requirement 11
PCI DSS Requirement 11

See Also: PCI DSS Requirement 11 Explained

New vulnerabilities are continually spreading and being exploited. For this reason, it is crucial to test system components, systems and special applications regularly and to close security vulnerabilities.

Necessary wireless network tests and related procedures are required to detect and identify all unauthorized wireless network access points quarterly.

Internal and external vulnerability scans should be performed by qualified personnel at least once a year, or after any significant change in the network.

Intrusion detection/prevention systems should be used to identify or prevent unauthorized network activity, and unauthorized operations on critical file integrity software and necessary files should be followed.

PCI DSS Requirement 11.1: Create processes to test the presence of wireless access points (802.11), and identify all authorized and unauthorized wireless access points quarterly.

When an unauthorized wireless router is connected to a system or network without installation information, it can be easily used by a malicious person to access all information on the network, especially cardholder data.

Necessary wireless network tests and related procedures are required to detect and identify all unauthorized wireless network access points quarterly.

If an inventory of authorized wireless access points is maintained and unauthorized wireless access points are detected, it is necessary to disable unauthorized wireless access points by applying incident response procedures.

PCI DSS Requirement 11.2: Perform internal and external network vulnerability scans at least every three months and after a significant change in the network.

External and internal network vulnerability scans are required every three months or after significant system and network changes. Vulnerability scans are an automated scanning method that tests the potential vulnerabilities of all internal and external network systems.

A significant change in the network; examples include adding new system components, changes in network topology, firewall rule changes, product upgrades. Tests must be repeated after such changes.

Multiple scan reports can be combined to demonstrate that all systems are scanned for quarterly scanning, and all applicable vulnerabilities are fixed. Additional documentation may be required to verify that uncorrected vulnerabilities are in the process of being resolved.

For the first PCI DSS compliance;

  • The most recent scan result should be a “passing” scan
  • An entity’s documentation of policies and procedures that require quarterly scanning
  • Vulnerabilities identified in the scan results; must be corrected with the rescans.

Rescan should be performed to verify that all “high-risk” vulnerabilities are closed based on a business vulnerability ranking. The scans should be done by qualified personnel.

An Approved Scanning Vendor requires quarterly external network vulnerability scans (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). If the scan report contains “failed” findings, the scans should be repeated until the relevant findings have been closed and confirmed.

Quarterly external network vulnerability scans should be carried out by an Approved Scanning Vendor (ASV) certified by the Payment Card Industry Security Standards Council (PCI SSC).

PCI DSS Requirement 11.3: Apply a methodology for penetration testing.

Penetration testing is the assessment of how far malicious attackers can penetrate the network by simulating an attack. Penetration testing is one step ahead of the vulnerability scanning and performed manually, as it attempts to exploit the vulnerabilities detected in a vulnerability scan with automated software.

For penetration testing, a methodology should be applied that includes:

  • It should be based on the penetration testing methodologies accepted by the industry. (For example, NIST SP800-115)
  • All CDE environment and critical systems should be included in the scope of testing.
  • The network must be tested internally and externally.
  • Must include tests to verify segmentation and scope reduction controls.
  • Application layer should be included in the scope of the test.
  • Tests must be performed to include operating systems as well as components that support network functions.
  • Threats and vulnerabilities that have been experienced in the last 12 months should be reviewed and assessed.
  • Penetration test results and improvement methods should be specified.

Internal and external network penetration tests must be repeated at least once a year and after significant infrastructure and application changes.

After the vulnerabilities found during the penetration test have been corrected, the test must be repeated for the verification work.

Suppose segmentation is used to isolate CDE from other networks. In that case, penetration tests should be performed at least once a year and to verify that the segmentation methods are functional and effective.

If service providers use segmentation, they must verify the scope of PCI DSS at least once every six months and after any changes to their segmentation controls/methods.

PCI DSS Requirement 11.4: Use intrusion detection or intrusion prevention techniques to detect or prevent network intrusion.

Using network and host-based intrusion detection and intrusion prevention systems (IDS / IPS) to monitor network traffic through the cardholder data environment can help to compensate for possible data breaches.

Intrusion detection or intrusion prevention techniques should be used to detect or prevent intrusion in the network. Monitor all traffic around the cardholder data environment and critical points in the cardholder data environment and alert staff about suspicious traffic. Measured values and signatures of all intrusion detection and prevention software or devices should be kept up to date.

PCI DSS Requirement 11.5: Set up a change detection mechanism to detect unauthorized modification of critical system files, configuration files or content files.

Change detection or file integrity monitoring tools are essential for detecting changes in critical files and reporting management in case of changes.

Change detection or file integrity monitoring tools should be configured to perform critical file comparisons at least once a week.

Critical files are files that do not change regularly but may expose the risks that could compromise the security of the system if they are changed. Change detection mechanisms, such as file integrity monitoring products, usually come pre-configured with critical files for the respective operating system. Necessary files for special applications should be evaluated and identified.

When an unauthorized change is detected, a defined process must be implemented to respond to the generated alerts.

PCI DSS Requirement 11.6: Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.

To ensure compliance, all security policies and practices related to this requirement should be reviewed in a standard way, implemented throughout the organization and communicated to all interested parties.

Maintaining the information security policy.

PCI DSS Requirement 12: Create a policy that addresses information security for all staff.

PCI DSS Requirement 12
PCI DSS Requirement 12

See Also: PCI DSS Requirement 12 Explained

Organizations should establish and publish a security policy that should be reviewed at least once a year and updated to reflect the changing risk environment.

You must implement a risk assessment process to identify threats and vulnerabilities. Usage policies for critical technologies should be developed, and security responsibilities for all personnel should be clearly defined. Besides, a formal information security awareness program should be implemented.

Organizations also need to implement an incident response plan to respond immediately to any system and network violations.

PCI DSS Requirement 12.1: Create and publish an information security policy.

The information security policy should be consistent with the PCI DSS. Still, it is also essential to develop a comprehensive policy that is consistent with the applicable regulations and covers corporate requirements.

A policy covering all other corporate issues should be implemented, and the policy should be updated at least once a year or if there are any changes in the business process.

PCI DSS Requirement 12.2: Create and implement a risk assessment process.

The risk assessment process is critical to identify potential threats and vulnerabilities that could affect your company. Organizations should continuously monitor their environment, develop a risk assessment process, and implement controls that address threats and vulnerabilities discovered during the process.

The risk assessment process should include the following items:

  • It should be renewed at least once a year and in case of significant changes in the environment.
  • Identify critical assets, threats, and vulnerabilities.

Examples of risk assessment methodologies are OCTAVE, ISO 27005 and NIST SP 800-30.

PCI DSS Requirement 12.3: Acceptable usage policies for critical technologies should be developed, and the appropriate use of these technologies should be defined.

Official policies for the use of critical devices and technologies must be established. These policies should prohibit the use of related technologies by staff or guide how to use them correctly.

Examples of critical technologies include remote access and wireless technologies, laptops, tablets, portable electronic devices, e-mail usage, and Internet usage.

  • Acceptable usage policies should cover the following items:
  • Authorized parties must approve it.
  • There must be authentication mechanisms for the use of technology.
  • List of such devices and authorized personnel
  • An appropriate method should be used to accurately and efficiently determine the owner, contact information and purpose—for example, tagging, coding or keeping inventory of devices.
  • Acceptable uses of technology
  • Proper network locations for technologies
  • List of company approved products and devices
  • Automatic discontinuation of sessions for remote access technologies after a period of inactivity or inactivity
  • Enabling remote access technologies for manufacturers and partners only when needed and disabled immediately after use
  • Personnel accessing cardholder data through remote access technologies should not be able to copy, move and store their data on local hard drives or removable electronic media unless expressly permitted for a particular business requirement.

PCI DSS Requirement 12.4: Ensure that security policy and procedures clearly define information security responsibilities for all personnel.

The real strength of information security policy lies in its ability to define the roles and responsibilities of staff clearly and to communicate policy requirements effectively. It is, therefore, necessary to ensure that security policies and procedures clearly explain information security responsibilities for all staff.

For service providers, senior management should establish responsibility for the protection of cardholder data and the PCI DSS compliance program, including:

  • General statement of responsibility to maintain PCI DSS compliance
  • Define a specification for the PCI DSS compliance program and communicate with senior management.

PCI DSS Requirement 12.5: Assign information security management responsibilities to a person or team.

Each individual or team should be aware of their responsibilities concerning information security management by an appropriate policy.

Information security management responsibilities should be as follows:

  • Creating, documenting and publishing security policies and procedures.
  • Monitor, analyze and forward safety warnings to relevant personnel.
  • Establishing, documenting and publishing security incident response procedures to ensure that events are handled in a timely and effective manner.
  • Manage user accounts, including adding, deleting and modifying operations.
  • Monitor and control access to sensitive data.

PCI DSS Requirement 12.6: Implement a formal information security awareness program to inform all staff about the importance of cardholder data security.

A comprehensive information security awareness program is needed to ensure that all employees are fully aware of their obligations to protect cardholder data. The awareness program also helps to create a sense of security within the company, so that staff begins to view information security as a top priority.

Employees should receive information security awareness training when they are first recruited and at least once a year.

Employees must acknowledge that they have read and understood the security policy and procedures at least once a year.

PCI DSS Requirement 12.7: To minimize the risk of attack from local sources, run a history scan of candidates before hiring.

The recruitment of the wrong person for an important position regarding cardholder data can have severe organizational consequences. A newly hired employee can access and manipulate card data for their malicious purpose.

It is therefore essential to carry out a comprehensive history check to eliminate the possibility of hiring a person with a criminal history.

Examples of past checks include the previous history of employment, criminal record, credit history, and reference checks.

PCI DSS Requirement 12.8: Create and implement policies and procedures to manage service providers where cardholder data is shared, or that may affect the security of cardholder data.

Official policies and procedures should be established for service providers with access to cardholder information, and these documents should be shared with interested parties.

The policies and procedures should include:

  • A list of service providers should be kept, including a description of the service provided.
  • A written contract is required, which acknowledges that service providers are responsible for the security of cardholder data to the extent that they have or otherwise store, process, transmit or affect the protection of the customer.
  • A program must be created to monitor and evaluate the status of service providers comply with PCI DSS at least once a year.
  • An inventory is required about which PCI DSS requirements are managed by which service provider.

PCI DSS Requirement 12.9: Service providers must notify their customers in writing that they are responsible for the security of the cardholder data they store, process or transmit on behalf of the customer.

Service providers must agree that, under a written contract, the customer will protect the cardholder data in all possible ways and comply with all the features of the PCI DSS that apply to it.

PCI DSS Requirement 12.10: Create and implement an incident response plan. Be prepared to respond immediately to violations.

Emergency response and recovery plan are necessary to minimize the impact in the event of a violation. Suppose a defined response plan for the events is not developed. In that case, there will be differences of opinion and methodology, and the people involved will spend more time building a single strategy.

Authorized personnel to respond to the incident should be routinely trained and accessible 24/7.

Make sure the following are addressed in the incident response plan to be implemented in case of system breach:

  • Roles, responsibilities, contact information and communication methods
  • Event-specific incident response procedures
  • Business recovery and continuity procedures
  • Data backup processes
  • Analysis of legal requirements
  • Scope of all critical system components
  • Reference to incident response procedures of payment brands

Review the incident response plan and test it at least once a year. To respond to alerts, identify specific staff to serve 24/7. Provide appropriate training to personnel with breach response responsibilities.

Add alerts from security monitoring systems such as intrusion detection, intrusion prevention, firewalls, and file integrity monitoring systems.

Develop the incident response plan based on previous events and industry developments.

PCI DSS Requirement 12.11: Service providers should evaluate at least quarterly to verify that personnel are following security policies and operational procedures.

  • Reviews should cover the following actions:
  • Daily log reviews
  • Firewall rule set analysis and reviews.
  • Application of configuration standards to new systems
  • Responding to security alerts
  • Change management processes

Service providers should keep the documentation of the quarterly review process and the results of the reviews.

For detailed information, you can refer to the PCI DSS Quick Reference Guide or the PCI DSS Standard from the PCI SSC Documentation library.

Surkay Baykara
Surkay Baykarahttps://www.pcidssguide.com
A passionate Senior Information Security Consultant working at Cyberwise. Over the past 15+ years my professional career has included several positions beginning as a developer and IT administrator, working my way up to a senior Technical Performance Consultant before joining Biznet back in 2015. I had several different roles at Cyberwise, including Penetration Tester and PCI DSS QSA. In my job as a QSA, I found my passion and worked closely with the Audit and Compliance team. I've been working inside InfoSec for over 15 years, coming from a highly technical background. I have earned several certifications during my professional career including; CEH, CISA, CISSP, and PCI QSA.

More from author

Common Cyber Threats in Ecommerce and How to Mitigate Them

In this article, we will delve into the issue of cybersecurity in ecommerce, describing the types of cyber threats that ecommerce businesses are confronted with and what can be done to avoid these threats.

Managing Cyber Risk in the Age of Cloud Computing

The cloud delivers game-changing capabilities but also surfaces new cyber risks requiring an evolved security perspective. However, as more sensitive data and critical systems move to the cloud, businesses must adapt their cybersecurity strategies to effectively manage emerging risks.

The Controversy and Importance of Ethical Hacking

Ethical hackers are essentially people who can use the same techniques as cyber criminals, but they do not use them to steal information.

2 COMMENTS

Comments are closed.

Related posts

Latest posts

Common Cyber Threats in Ecommerce and How to Mitigate Them

In this article, we will delve into the issue of cybersecurity in ecommerce, describing the types of cyber threats that ecommerce businesses are confronted with and what can be done to avoid these threats.

Managing Cyber Risk in the Age of Cloud Computing

The cloud delivers game-changing capabilities but also surfaces new cyber risks requiring an evolved security perspective. However, as more sensitive data and critical systems move to the cloud, businesses must adapt their cybersecurity strategies to effectively manage emerging risks.

The Controversy and Importance of Ethical Hacking

Ethical hackers are essentially people who can use the same techniques as cyber criminals, but they do not use them to steal information.

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!