PCI DSS | What It Is and How to Comply

Network security controls – such as firewalls, Cloud-based systems and software-defined solutions – enforce traffic policies between network segments to protect sensitive areas like the cardholder data environment.

They determine whether to allow or block incoming and outgoing traffic based on predefined rules and are used to prevent unauthorised access from untrusted sources such as the Internet, wireless networks, third-party systems or internal networks that fall outside the PCI DSS assessment scope.

Default passwords and vendor settings are widely known and often exploited by attackers – both internal and external – to compromise systems. Applying secure configurations reduces this risk by limiting potential entry points.

This includes changing default credentials, removing unnecessary software and user accounts, and disabling services that are not required. Together, these measures help reduce the system’s attack surface and improve overall security.

Encryption, truncation, masking and hashing are effective ways of protecting stored account data, rendering it unreadable by an attacker who bypasses other security controls but doesn’t have the correct cryptographic keys.

Additional risk-mitigation strategies include storing account data only when necessary, truncating cardholder data when the full PAN is not required, and avoiding the transmission of unprotected PANs via user messaging tools such as email or instant messaging.

While encryption is not required for account data held temporarily in non-persistent memory, controls must ensure that the data is cleared once the business process is complete. If data becomes persistent, all relevant PCI DSS Requirements – including encryption – must be applied.

Strong cryptography helps ensure the confidentiality, integrity and non-repudiation of data. To prevent compromise, PANs (primary account numbers) must be encrypted when transmitted over networks that may be accessible to malicious individuals – including public and untrusted networks.

Misconfigured wireless setups and outdated encryption protocols are common targets, making secure configuration essential. Any internal network transmitting, storing or processing PANs falls within the PCI DSS’s scope and must meet its requirements. PANs can be protected by encrypting the data itself, the transmission session, or both – and while using both methods is not mandatory, it is strongly recommended.

Malware is designed to infiltrate or damage a system without the owner's consent, aiming to compromise the confidentiality, integrity or availability of data, applications or operating systems. Common examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits and other malicious code.

Malware can enter a network through various business-approved activities, such as employee email (phishing), Internet use and mobile devices, and exploits system vulnerabilities. Using comprehensive anti-malware solutions helps protect systems from both current and emerging malware threats.

Bad actors can exploit security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are addressed by vendor-provided security patches, which must be installed by the organisations managing the systems.

All system components must be kept up to date with the appropriate software patches to prevent the exploitation of account data by malicious individuals or malware. Appropriate patches are those that have been tested to ensure they do not conflict with existing security configurations.

For bespoke or custom software, applying secure coding techniques and following software lifecycle processes can help avoid many vulnerabilities.

Code repositories storing application code, system configurations, or other security-sensitive data must also be assessed under PCI DSS requirements.

Unauthorised individuals can access critical data or systems because of weak access control rules. To prevent this, systems and processes must be put in place to limit access based on job roles and a need-to-know basis.

• Access refers to the ability to view systems, applications or data;
• Privileges determine the actions a user can perform on that data, such as reading, changing or deleting it; and
• Need to know ensures users access only the minimum data required for their job.

These requirements apply to employees, contractors, consultants, vendors and third parties, as well as to application and system accounts (service accounts).

Two fundamental principles of identifying and authenticating users are:

1. Establishing the identity of an individual or process on a computer system; and
2. Verifying that the user associated with the identity is who they claim to be.

Identification is achieved 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,” uniquely identify each person or process, ensuring accountability for actions performed. This accountability allows actions to be traced to authorised users or processes.

Any physical access to cardholder data or systems that store, process, or transmit cardholder data presents the opportunity for unauthorised individuals to access or remove such data. Therefore, physical access must be properly restricted. Requirement 9 covers three areas:

1. Sensitive areas, which require physical controls to limit access, should be identified and protected appropriately.
2. The CDE (cardholder data environment) requires broader physical protections across the entire environment, including sensitive areas within it.
3. Facility-level controls apply to the overall premises, such as the management of access at building entry points, including guard desks that log visitors or verify identities. These facility controls may exist outside the CDE or sensitive areas, but still provide essential protection.

Logging mechanisms and the ability to track user activities are essential for preventing, detecting or minimising the impact of a data breach.

Logs across all system components, especially within the CDE (cardholder data environment), enable comprehensive tracking, alerting and analysis if an issue arises. Without system activity logs, determining the cause of a compromise is challenging, if not impossible.

Vulnerabilities are constantly being discovered by both malicious individuals and security researchers, and new software can introduce additional risks.

To ensure ongoing security, system components, processes and bespoke or custom software should be regularly tested to confirm that security controls remain effective in a constantly evolving environment.

The organisation’s overall information security policy sets the tone for the entire entity and outlines the expectations for personnel. All personnel should be aware of the sensitivity of cardholder data and their responsibilities for protecting it.

For the purposes of Requirement 12, “personnel” includes full-time and part-time employees, temporary employees, contractors and consultants who have security responsibilities for protecting account data or whose actions can impact the security of cardholder data or sensitive authentication data.