Skip to main content

PA-DSS

logo

Summary

The PCI Payment Application Data Security Standard (PA-DSS) Requirements and Security Assessment Procedures define security requirements and assessment procedures for software vendors of payment applications. The version used in this section is PA-DSS version 3.0, November 2013.

Definitions

DefinitionRequirements
1_1. Do not store sensitive authentication data after authorization360. Remove unnecessary sensitive information
1_1_1. Do not store full contents of any track from the magnetic stripe160. Encode system outputs
335. Define out of band token lifespan
360. Remove unnecessary sensitive information
1_1_2. Do not store the card verification value or code used to verify transactions160. Encode system outputs
335. Define out of band token lifespan
360. Remove unnecessary sensitive information
1_1_3. Do not store personal identification number (PIN) or the encrypted PIN block205. Configure PIN
360. Remove unnecessary sensitive information
1_1_4. Securely delete any track data, card verification values or codes, and PINs or PIN block data stored by application in accordance with industry-accepted standards183. Delete sensitive data securely
335. Define out of band token lifespan
360. Remove unnecessary sensitive information
1_1_5. Do not store sensitive authentication data on vendor systems083. Avoid logging sensitive data
2_1. Provide guidance to customers regarding secure deletion of cardholder data183. Delete sensitive data securely
360. Remove unnecessary sensitive information
2_2. Mask PAN when displayed300. Mask sensitive data
2_3. Render PAN unreadable anywhere it is stored127. Store hashed passwords
185. Encrypt sensitive information
305. Prioritize token usage
2_5. Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data145. Protect system cryptographic keys
252. Configure key encryption
2_5_1. Generation of strong cryptographic keys145. Protect system cryptographic keys
224. Use secure cryptographic mechanisms
2_5_2. Secure cryptographic key distribution-
2_5_3. Secure cryptographic key storage145. Protect system cryptographic keys
146. Remove cryptographic keys from RAM
2_5_4. Cryptographic key changes for keys338. Implement perfect forward secrecy
361. Replace cryptographic keys
2_5_5. Retirement or replacement of keys361. Replace cryptographic keys
2_5_7. Prevention of unauthorized substitution of cryptographic keys145. Protect system cryptographic keys
176. Restrict system objects
3_1. Support and enforce the use of unique user IDs and secure authentication for all administrative access033. Restrict administrative access
229. Request access credentials
3_1_2. Enforce the changing of all default application passwords for all accounts142. Change system default credentials
3_1_4. Application employs methods to authenticate all users228. Authenticate using standard protocols
229. Request access credentials
231. Implement a biometric verification component
305. Prioritize token usage
357. Use stateless session tokens
3_1_5. Payment application does not require or use any group, shared, or generic accounts and passwords143. Unique access credentials
362. Assign MFA mechanisms to a single account
3_1_6. Passwords must meet minimum requirements132. Passphrases with at least 4 words
133. Passwords with at least 20 characters
3_1_7. Payment application requires changes to user passwords at least every 90 days130. Limit password lifespan
3_1_11. Require the user to re-authenticate to re-activate the session (inactive)023. Terminate inactive user sessions
141. Force re-authentication
3_3_1. Use strong cryptography to render all payment application passwords unreadable during transmission181. Transmit data using secure protocols
3_4. Limit access to required functions/resources and enforce least privilege for built-in accounts035. Manage privilege modifications
186. Use the principle of least privilege
4_1. Log all user access and be able to link all activities to individual users085. Allow session history queries
377. Store logs based on valid regulation
4_2_2. Actions taken by any individual with root or administrative privileges046. Manage the integrity of critical files
075. Record exceptional events in logs
4_2_4. Invalid logical access attempts075. Record exceptional events in logs
4_2_5. Changes to the application's identification and authentication mechanisms with root or administrative privileges075. Record exceptional events in logs
4_2_6. Initialization, stopping, or pausing of the application audit logs046. Manage the integrity of critical files
075. Record exceptional events in logs
4_2_7. Creation and deletion of system-level objects075. Record exceptional events in logs
079. Record exact occurrence time of events
4_3. Payment application's audit log settings and audit log output079. Record exact occurrence time of events
4_4. Facilitate centralized logging377. Store logs based on valid regulation
5_1_1. Live PANs are not used for testing or development180. Use mock data
5_1_2. Test data and accounts are removed before release to customer154. Eliminate backdoors
5_1_5. Secure practices are implemented to verify integrity of source code during the development process330. Verify Subresource Integrity
5_2_1. Injection flaws, particularly SQL injection050. Control calls to interpreted code
160. Encode system outputs
169. Use parameterized queries
173. Discard unsafe inputs
321. Avoid deserializing untrusted data
5_2_2. Buffer Overflow157. Use the strict mode
173. Discard unsafe inputs
345. Establish protections against overflows
5_2_3. Insecure cryptographic storage145. Protect system cryptographic keys
185. Encrypt sensitive information
224. Use secure cryptographic mechanisms
5_2_4. Insecure communications181. Transmit data using secure protocols
336. Disable insecure TLS versions
5_2_5. Improper error handling077. Avoid disclosing technical information
078. Disable debugging events
5_2_7. Cross-site scripting (XSS)029. Cookies with security attributes
173. Discard unsafe inputs
340. Use octet stream downloads
344. Avoid dynamic code execution
349. Include HTTP security headers
5_2_8. Improper access controls033. Restrict administrative access
035. Manage privilege modifications
080. Prevent log modification
096. Set user's required privileges
176. Restrict system objects
186. Use the principle of least privilege
265. Restrict access to critical processes
266. Disable insecure functionalities
320. Avoid client-side control enforcement
341. Use the principle of deny by default
5_2_9. Cross-site request forgery (CSRF)029. Cookies with security attributes
174. Transactions without a distinguishable pattern
349. Include HTTP security headers
5_2_10. Broken authentication and session management029. Cookies with security attributes
032. Avoid session ID leakages
369. Set a maximum lifetime in sessions
5_4_6. Process in place to review application updates302. Declare dependencies explicitly
353. Schedule firmware updates
6_1. The wireless technology must be implemented securely084. Allow transaction history queries
142. Change system default credentials
181. Transmit data using secure protocols
248. SSID without dictionary words
250. Manage access points
251. Change access point IP
252. Configure key encryption
253. Restrict network access
257. Access based on user credentials
273. Define a fixed security suite
353. Schedule firmware updates
6_2. For wireless technology, implement strong encryption for authentication and transmission181. Transmit data using secure protocols
249. Locate access points
252. Configure key encryption
253. Restrict network access
255. Allow access only to the necessary ports
257. Access based on user credentials
8_1. Secure network environment-
8_2. Use of necessary and secure services, including those provided by third parties161. Define secure default options
262. Verify third-party components
8_3. Operation of two-factor authentication technologies for secure remote access319. Make authentication options equally secure
362. Assign MFA mechanisms to a single account
9_1. Any web server and any cardholder data storage component are not required to be on the same server261. Avoid exposing sensitive information
339. Avoid storing sensitive files in the web root
10_2_2. Unique authentication credential must be used for each customer environment128. Define unique data source
143. Unique access credentials
10_2_3. Remote access to customer's payment applications must be implemented securely025. Manage concurrent sessions
083. Avoid logging sensitive data
142. Change system default credentials
176. Restrict system objects
11_1. Use of strong cryptography and security protocols to safeguard sensitive cardholder data during transmission176. Restrict system objects
178. Use digital signatures
181. Transmit data using secure protocols
11_2. Render the PAN unreadable185. Encrypt sensitive information
12_1. Encrypt all nonconsole administrative access with strong cryptography033. Restrict administrative access
185. Encrypt sensitive information
336. Disable insecure TLS versions