2.2.2 Vendor default accounts are managed as follows:

• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.

This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and middleware vendors, payments applications, and Simple Network Management Protocol (SNMP) defaults.

This requirement also applies where a system component is not in the CDE but is indirectly used to process, store, or transmit account data (for example, software and applications that are part of the CDE are accessed via a cloud subscription service).

3.1.1 All security policies and operational procedures that are identified in Requirement 3 are:

• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.

3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:

• Coverage for all locations of stored account data.
• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization, even where there is no need to store SAD.
• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
• A process for verifying, at least once every three months, that stored account data has not exceeded its specified retention period and has been securely deleted or rendered unrecoverable.

Where account data is stored by a TPSP (for example, in a cloud solution) a Data Retention and Disposal Policy that applies to that stored data is provided by the TPSP. For non-TPSP cloud services this is provided in written agreement and formally accepted by the entity. The entity’s inventory includes all data- storage locations, including on-site and off-site back- up repositories, and the legal, regulatory, and business requirements for data retention apply to those repositories. At a minimum, if a backup environment is used, the same data retention policies apply to the backup environment as the production environment. If a data retention period applies, the entity implements a documented process to ensure the data is securely deleted or rendered unrecoverable when the retention period is met. Note: For use of SAD, see also Applicability Notes Section A: Use of SAD after Transaction Authorization. The use of SAD when it is isolated and retained solely to support a legitimate business purpose that cannot be achieved otherwise is a best practice until its effective date.

6.3.1 Security vulnerabilities are identified and managed as follows:

• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information (for example, vendor websites, industry news groups, mailing lists, or through subscriptions / memberships to alert services) including alerts blogs and mailings from national and international and national computer emergency response teams (CERTs).
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
• Risk rankings, at a minimum, identify all vulnerabilities considered to be a high-risk or critical to the environment.
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

This requirement is not achieved by, nor is it the same as, vulnerability scanning alone. A risk-ranking process should be defined and include the potential impact to the environment.

6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

• Critical or high-security patches/updates (identified according to the entity’s vulnerability risk ranking process defined in Requirement 6.3.1) are installed within one month of release.
• All other applicable security patches/updates are installed within three months of release.

8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.

Where external cloud service providers are used to host system component(s) within the cardholder data environment (CDE) authentication to access the cloud service provider account as well as authentication used to access the system component is managed in a manner consistent with this requirement. When web-based workloads outside of the CDE and are accessed via a cloud subscription service.

8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:

• Use is limited to a small number of users.
• Access is limited to specific business, operational or regulatory needs.
• All actions are attributable to an individual.
• Approvals are required and are specifically documented when shared authentication credentials are used.
• Authenticated user identity is confirmed in accordance with Requirement 8.4.2, when a user reports that they have no knowledge of initiating an event.
• Alternatives are in place, and put into practice as soon as feasible and according to time lines, to migrate to individual authentication, where shared authentication credentials are necessary.

Implementing individual authentication for any incident of shared authentication credentials used after 30-April-2025, is a best practice until 31-March-2025; after this date, it is intended to be a requirement. For incidents of shared authentication used before the effective date; refer to Applicability Notes below for details.

8.2.5 Access for terminated users is immediately revoked

8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following approaches:

• Multi-factor authentication (MFA) for all access into the CDE.
• Multi-factor authentication (MFA) for all access into the CDE.
• Multi-factor authentication (MFA) for all access into the CDE.

8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:

• Passwords/passphrases must be set to an individual user account.
• First-time passwords/passphrases must be set to a unique value for each user and changed immediately after the first use.
• Provisioning of financial and business approval roles must be performed in accordance with Requirement 8.2.3.

8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:

• A minimum length of 12 characters (or IF the system does not support 12 characters, then a minimum length of eight characters).
• Contain both numeric and alphabetic characters.

This requirement is not intended to apply to:

• User accounts on point-of-sale terminals that have access to only one cardholder’s account at a time, with no ability to extract, reuse, or otherwise employ the account data (such as IDs used by cashiers on point-of-sale terminals).
• Application or system accounts, which are governed by requirements in section 8.6.

8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases they have used.

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation), then either:

• The passwords/passphrases are changed at least once every 90 days, or
• The system automatically terminates the user’s access after a maximum of 90 days of inactivity or when the user’s access is no longer required, whichever is sooner.

9.4.1 All media with cardholder data is physically secured.

9.4.1.1 Offline media backups with cardholder data are stored in a secure location.

9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months to ensure it remains secure.

9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.

9.4.3 Media with cardholder data sent outside the facility is secured as follows:

• Media sent outside the facility is logged.
• Media is sent only via secured courier or other delivery method that can be accurately tracked.
• Management approves any and all media that is moved from a secured area.

9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals), and a documented approval process is in place.

9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:

• Shred, incinerate, or pulp hard-copy materials so that cardholder data cannot be reconstructed.
• Render cardholder data on electronic media unrecoverable so that data cannot be reconstructed.

11.3.2 External vulnerability scans are performed as follows:

• At least once every three months.
• By a PCI SSC Approved Scanning Vendor (ASV).
• After any significant change.

11.3.2.1 External vulnerability scans are performed after any significant change as follows:

• Vulnerabilities that are scored 4.0 or higher by the CVSS (see Glossary of Terms, Abbreviations, and Acronyms) are resolved.
• Scans are repeated as needed to confirm that vulnerabilities have been corrected until a passing scan result is achieved.

12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of the cardholder data environment is maintained.

12.8.2 Written agreements with TPSPs are maintained as follows:

• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the cardholder data environment.
• The written agreement acknowledges that the TPSPs are responsible for security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customers CDE.

12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.

12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.

If a TPSP does not have the most recent PCI DSS version turn a bad phrase this requirement is not achieved by individual or unqualified service providers engaging in reviews. The focus is to maintain compliance agency documentation and reporting needs

12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

Where a service provider is used and the particular entity is that service provider using card-user information; the particular responsibilities and components that are a part of the PCI process are used for the provider or providers. To the extent that a particular service provider is using information that is entered in and out of the system regarding the safety and security of card-user data and particulars during the transaction; the particular company entering the information on the final card data.

12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security are as follows:

• Clearly and thoroughly contains the written tasks for each team member the particular steps that are taken along with the persons responsible for specific steps.
• Event is isolated and perpetrators identified and isolated from the environment after a compromise.
• Particulars for incident response are given to and to the specific persons responsible