PCI SSF

The payment software must implement strong authentication and access control mechanisms for all users, processes, and services accessing sensitive functions or data within the software.

• Authentication architecture documentation
• Authorization model with role definitions
• Session management implementation evidence
• Test results for authentication controls

• Default credentials shipped with software
• Authorization checks bypassed in error paths
• Sessions not invalidated on logout or timeout

Sensitive authentication data must not be stored after authorization. If retained temporarily during authorization, it must be protected with strong cryptography and securely deleted immediately after use.

• Design documentation prohibiting SAD storage post-authorization
• Code review evidence verifying SAD deletion
• Test results confirming SAD is not retained
• Memory scrubbing implementation evidence

• SAD found in process memory after authorization completion
• Debug builds retain SAD for troubleshooting
• Memory scrubbing not implemented for SAD buffers

When the payment software stores, processes, or transmits account data, additional controls must protect the data including encryption, tokenization, masking, and minimization across all software components.

• Account data inventory across software components
• Encryption and tokenization design documentation
• Masking implementation in user interfaces
• Validation testing for protection controls

• PAN exposed in error messages or logs
• Encryption applied at storage but missing in inter-component communication
• Masking inconsistent across UI screens

The software vendor must identify and document all critical assets within the payment software, including sensitive data, cryptographic keys, authentication mechanisms, and the components that protect them.

• Critical asset inventory mapped to software components
• Data flow diagrams identifying sensitive data paths
• Classification scheme defining sensitivity levels
• Records of asset updates triggered by software changes

• Asset inventory missing newer components after refactoring
• Sensitive authentication data classification incomplete
• No process to update inventory on each release

Critical assets identified within the payment software must be protected by appropriate technical and procedural controls commensurate with the impact of compromise.

• Documented protection controls per asset
• Risk treatment plan
• Validation testing demonstrating control effectiveness
• Mapping between assets, threats, and controls

• Protection controls described abstractly without implementation evidence
• Risk treatment not linked to specific asset
• Validation testing missing for newer protections

All changes to payment software must follow documented change management procedures including risk assessment, security review, testing, and approval before deployment.

• Change management policy and procedures
• Change records with risk assessments
• Security review records for changes
• Approval workflows in change tooling

• Emergency changes bypass security review
• Risk assessments not differentiated by change type
• Approvals captured informally outside tooling

The vendor must maintain effective communication with stakeholders including customers, partners, and PCI SSC regarding security-relevant matters, software releases, and vulnerability information.

• Customer security communication templates
• Release notes including security content
• Records of PCI SSC notifications
• Stakeholder communication policy

• Release notes omitting security fixes
• Customer security advisories sent inconsistently
• PCI SSC notification timelines not tracked

Critical assets requiring cryptographic protection must use industry-accepted algorithms, sufficient key lengths, and robust key management practices throughout the software lifecycle.

• Approved algorithm list and rationale
• Key management procedures
• Cryptographic library version inventory
• Validation test results for cryptographic operations

• Outdated cryptographic libraries with known weaknesses
• Algorithm selection rationale missing
• Key management procedures not specific to software environment

Sensitive data including cardholder data, sensitive authentication data, and cryptographic material must be inventoried, minimized, protected at rest and in transit, and securely deleted when no longer required.

• Sensitive data inventory across all software components
• Encryption design documentation
• Secure deletion procedures and validation
• Data minimization decisions documented

• Sensitive data found in logs and debug output
• Encryption boundary not aligned with data flows
• Secure deletion not validated by testing

The software vendor must provide clear security guidance to implementers and users covering secure deployment, configuration, operation, and decommissioning of the payment software.

• Implementation guide for secure deployment
• Configuration hardening documentation
• User security awareness materials
• Decommissioning procedures

• Implementation guide does not reflect latest software version
• Hardening guidance generic and not version-specific
• Decommissioning procedures missing key destruction steps

Executive management must assign clear responsibility for the secure software lifecycle program, provide sufficient resources, and ensure security objectives are integrated into business goals.

• Security organization chart with named roles
• Budget allocations for security activities
• Executive sponsorship records (charter, meeting minutes)
• Job descriptions with security responsibilities

• Security responsibility distributed without clear accountability
• Budget cuts during fiscal pressure removing security activities
• Executive sponsorship limited to compliance audit window

Developers must follow defined secure coding practices and use approved development tools, libraries, and frameworks. Code must be reviewed for security defects before integration.

• Documented secure coding standards
• Code review records with security findings
• SAST tool configuration and results
• Approved tools and libraries list

• Coding standards not enforced through automation
• Code review records lack evidence of security focus
• SAST findings ignored or marked false positive without justification

The vendor must maintain integrity of software throughout development, build, and distribution including version control, code signing, and protection of build environments.

• Version control configuration and access logs
• Build environment hardening documentation
• Code signing procedures and key management
• Distribution channel security controls

• Build environment shared with development causing tamper risk
• Code signing keys stored without HSM protection
• Distribution channels lack integrity verification

Network security and segmentation. Control from PCI SSF framework, domain: PCI SSF: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Endpoint protection and detection. Control from PCI SSF framework, domain: PCI SSF: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Application security controls. Control from PCI SSF framework, domain: PCI SSF: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Encryption and key management. Control from PCI SSF framework, domain: PCI SSF: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Secure configuration standards. Control from PCI SSF framework, domain: PCI SSF: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Incident detection and classification. Control from PCI SSF framework, domain: PCI SSF: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Incident response and containment. Control from PCI SSF framework, domain: PCI SSF: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Regulatory reporting requirements. Control from PCI SSF framework, domain: PCI SSF: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Customer notification procedures. Control from PCI SSF framework, domain: PCI SSF: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Post-incident review and improvement. Control from PCI SSF framework, domain: PCI SSF: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Information security program management. Control from PCI SSF framework, domain: PCI SSF: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Board and management oversight. Control from PCI SSF framework, domain: PCI SSF: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Risk appetite and tolerance for IT risk. Control from PCI SSF framework, domain: PCI SSF: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Security policy framework. Control from PCI SSF framework, domain: PCI SSF: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Roles and responsibilities definition. Control from PCI SSF framework, domain: PCI SSF: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Business continuity planning and testing. Control from PCI SSF framework, domain: PCI SSF: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Disaster recovery procedures. Control from PCI SSF framework, domain: PCI SSF: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Third-party dependency management. Control from PCI SSF framework, domain: PCI SSF: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Critical service identification. Control from PCI SSF framework, domain: PCI SSF: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Communication and escalation procedures. Control from PCI SSF framework, domain: PCI SSF: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Due diligence and onboarding. Control from PCI SSF framework, domain: PCI SSF: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Contractual security requirements. Control from PCI SSF framework, domain: PCI SSF: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Ongoing monitoring and assessment. Control from PCI SSF framework, domain: PCI SSF: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Concentration risk management. Control from PCI SSF framework, domain: PCI SSF: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Exit strategy and transition planning. Control from PCI SSF framework, domain: PCI SSF: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

The vendor must establish, document, and maintain software security policies and procedures that define security expectations across the entire software lifecycle.

• Approved software security policies
• Procedure documentation for each lifecycle phase
• Annual policy review records
• Policy training records for development teams

• Policies not updated after process changes
• Procedure documentation inconsistent across teams
• Training not refreshed for new joiners

The vendor must establish processes to identify threats to the software, assess associated risks, and mitigate or accept those risks through documented decisions.

• Threat modeling methodology and outputs
• Risk register specific to software products
• Mitigation decisions with executive sign-off
• Periodic risk review records

• Threat models created at launch but not maintained
• Risk register lacks asset and threat traceability
• Mitigation decisions not signed off at appropriate level

Software designs must incorporate security requirements derived from threats, risks, and policy. Designs must be reviewed for security implications before implementation begins.

• Security requirements catalog
• Design documentation with security annotations
• Design review records with security sign-off
• Architectural decision records (ADRs)

• Security requirements added late in design
• Design reviews lack security expertise
• ADRs not capturing security rationale

Payment software installed on PCI PTS approved POI terminals must follow additional requirements that protect the software, prevent unauthorized modification, and maintain the integrity of the terminal's secure boundary.

• Terminal software architecture documentation
• Evidence that terminal software does not interfere with SRED
• Coordination with terminal vendor for security verification
• Test results validating terminal software behavior

• Terminal software accessing memory regions outside intended boundary
• Updates not coordinated with terminal vendor
• Test results not refreshed for newer terminal firmware

The vendor must perform security testing throughout development including static analysis, dynamic analysis, fuzz testing, and penetration testing aligned with the software's risk profile.

• Security testing methodology documentation
• Test execution records (SAST, DAST, IAST, pen test)
• Remediation tracking for identified issues
• Test coverage metrics

• Testing limited to SAST without dynamic analysis
• Pen testing performed too late in cycle for meaningful remediation
• Test coverage metrics absent

The payment software must include capabilities to detect attacks against critical assets, generate appropriate alerts, and support investigation of potential security incidents.

• Threat model documenting expected attack scenarios
• Detection mechanism design documentation
• Alert configuration and routing
• Audit logs covering detection events

• Threat model not refreshed for newer attack patterns
• Alerts disabled or routed to unmonitored channels
• Logs lack sufficient context for investigation

The vendor must ensure software updates maintain integrity from development through delivery, including signing, verification, and protection against rollback to vulnerable versions.

• Update signing procedures
• Client verification logic documentation
• Rollback protection mechanism evidence
• Update integrity test results

• Clients accept unsigned updates
• Verification logic bypassable
• Rollback to vulnerable versions not prevented

The software vendor must provide secure mechanisms for delivering software updates to deployed instances, including authenticity verification, integrity protection, and rollback capabilities.

• Update delivery architecture documentation
• Code signing procedures and key management
• Update verification logic in client software
• Rollback procedures and testing

• Update signatures not verified by client
• Update delivery channels not authenticated
• Rollback not tested for newer update mechanisms

The vendor must operate a vulnerability disclosure program that allows external researchers to report vulnerabilities, and must respond to reported vulnerabilities within defined timeframes.

• Documented vulnerability disclosure policy
• Disclosure intake process and contact channels
• Response timeline targets and tracking
• Communication records with reporters and customers

• No public disclosure channel documented
• Response timelines undefined
• Customer notifications inconsistent across vulnerabilities

The software vendor must establish a threat and vulnerability management process that identifies, assesses, prioritizes, and remediates threats and vulnerabilities across the software lifecycle.

• Threat modeling records
• Vulnerability scanning and SAST/DAST results
• Risk assessment methodology
• Remediation tracking and timelines

• Threat models not updated for new features
• Vulnerability scans not integrated into CI/CD
• Remediation timelines not aligned to severity

Personnel involved in software development and security must have the knowledge, skills, and training necessary to fulfill their security responsibilities effectively.

• Training plan for security and development personnel
• Annual training completion records
• Skills matrix mapping personnel to required competencies
• Conference and certification records

• Training records not tracked centrally
• Skills matrix outdated relative to current technology stack
• New joiners onboarded without security training