Payment software vendors and developers need to ensure that their apps and programs protect sensitive data. The PCI SSF provides security assurance across a broader range of software than its predecessor. Understanding its full scope helps all industry stakeholders stay compliant.
Is your organization fully compliant with the PCI SSF? Schedule a consultation to find out!
Understanding the PCI SSF’s Broad Software Coverage
The Payment Card Industry (PCI) Software Security Framework (SSF) is a regulation for payment software developed and governed by the Security Standards Council (SSC). Sometimes called the Secure Software Framework, PCI SSF ensures security across a variety of industries and use cases.
Understanding the full scope of PCI SSF coverage and its implications requires asking:
- What specific software is covered by the SSF, including via secure development?
- How does the SSF protect this software—what controls are required for each kind?
- Who needs to comply with SSF protections, and how can they achieve compliance?
Ultimately, the best way to comply with the SSF and other PCI regulations is to work with a quality PCI compliance advisor who facilitates implementation, monitoring, and assessment.
What Software and Processes Are Covered by the SSF?
The SSF applies to all components of all payment software. That is, it covers all software used to process payments or related data. Covered functions include payment processing, inputs and outputs, error handling, data flows, and security controls.
That last part is critical, as it provides greater coverage for software that includes or connects to payment functionalities. To the extent that an unrelated piece of software is connected to an app or program used for payments, everything in their shared infrastructure needs to be secured.
Another critical element of SSF protection is the way it branches out to its development process beyond the programs themselves. This is a critical way in which it differs from its predecessor.
How the PCI SSF Built on the Foundation of the PA-DSS
Before the PCI SSF was released in 2022, the primary regulation on payment software was the Payment Application Data Security Standard (PA-DSS). It provided coverage for payment apps and other software by adapting and extending PCI Data Security Standard (DSS) controls to software and its developers/vendors rather than the organizations that implemented it. But stakeholders in the SSC felt that the complexity of newer software environments warranted more comprehensive coverage for both software and its development—hence the PCI SSF.
The SSF consists of two main components: the Secure Software Standard and the Secure Software Development Lifecycle Standard (Secure SLC). The former applies to the software itself and is primarily applicable to its vendors. The latter applies to the methods and environment in which payment software is created; it applies primarily to software developers.
How the PCI SSF Protects Payment Software Holistically
The SSF protects payment software by requiring a series of Control Objectives to be met. The SSF outlines 12 core controls that apply to all payment software, with additional rules for specific types.
The 12 Core Requirements are organized under four primary categories:
- Minimizing the Attack Surface
-
- Control Objective 1 – Identify critical assets
-
- Control Objective 2 – Install secure defaults
-
- Control Objective 3 – Minimize data retention
- Software Protection Mechanisms
-
- Control Objective 4 – Protect critical assets
-
- Control Objective 5 – Control authentication and access
-
- Control Objective 6 – Protect sensitive data
-
- Control Objective 7 – Encrypt data securely
- Secure Software Operations
-
- Control Objective 8 – Track activity
-
- Control Objective 9 – Detect attacks
- Secure Software Lifecycle Management
-
- Control Objective 10 – Manage threats and vulnerabilities
-
- Control Objective 11 – Provide secure software updates
-
- Control Objective 12 – Provide implementation guidance
Each of these controls breaks down further into one or more specifications. For more detailed information on the specific controls required, see our guide to the SSF’s Core Requirements.
PCI SSF Modules for Specific Kinds of Payment Software
One of the ways that the PCI SSF offers broader protection for more kinds of payment software is in specifying additional controls for specific kinds of programs and apps. To that effect, it has three modules of controls that can apply in addition to the 12 Core Requirements listed above.
The three modules are outlined as follows:
- Module A: Account Data Protection Requirements
-
- Control Objective A.1 – Protect sensitive authentication data
-
- Control Objective A.2 – Protect cardholder data
- Module B: Terminal Software Requirements
-
- Control Objective B.1 – Document terminal software specifications
-
- Control Objective B.2 – Design terminal software securely
-
- Control Objective B.3 – Mitigate attacks on terminal software
-
- Control Objective B.4 – Test terminal software security regularly
-
- Control Objective B.5 – Provide terminal software implementation guidance
- Module C: Web Software Requirements
-
- Control Objective C.1 – Secure web components and services
-
- Control Objective C.2 – Provide web software access controls
-
- Control Objective C.3 – Mitigate attacks on web software
-
- Control Objective C.4 – Secure web software communications
Beyond these protections applicable to the software itself (and its vendors, by extension), the SSF stipulates protections for the development lifecycle, which may apply irrespective of these.
PCI Secure SLC Protections for Software Development
The Secure SLC framework is the other part of the SSF. Rather than applying to the software itself, it governs the conditions under which it’s created. While there is some overlap with the Secure Software controls, these standards do not always apply simultaneously.
The following requirements apply across all payment software development environments—
- Software Security Governance
-
- Control Objective 1 – Establish security responsibilities and resources
-
- Control Objective 2 – Disseminate security policies and strategies
- Secure Software Engineering
-
- Control Objective 3 – Identify and address security threats
-
- Control Objective 4 – Detect and mitigate security vulnerabilities
- Secure Software and Data Management
-
- Control Objective 5 – Manage changes securely
-
- Control Objective 6 – Protect software integrity
-
- Control Objective 7 – Protect sensitive data
- Security Communications
-
- Control Objective 8 – Provide implementation guidance
-
- Control Objective 9 – Secure stakeholder communications
-
- Control Objective 10 – Provide security update information
If an organization acts as both developer and vendor, they may need to implement both sets of controls. But if their primary function is one or the other, then only one may apply. Working with a dedicated PCI advisor is the best way to determine which you need to follow (and how).
Who Needs to Comply with the PCI SSF—and How
The PCI SSF applies primarily to software vendors and developers who need to ensure that the products they’re pushing out to clients will secure payments adequately. SaaS providers offering payment processing must also ensure their software complies with PCI SSF.
In terms of how to comply, vendors and developers need to implement applicable controls from the lists above. Then, they’ll need to prepare for an audit from a PCI-vetted SSF Assessor.
One complication to consider is whether other PCI regulations apply in addition to the SSF. If your organization directly processes credit card transactions or cardholder data in addition to developing or vending payment software, you may also need to comply with the PCI DSS. That would necessitate working with an Approved Scanning Vendor (ASV) for certain controls, along with a Qualified Security Assessor (QSA) to verify your overall compliance, depending on your PCI level. The best compliance partners hold certifications as QSA, ASV, and SSF Assessor.
Secure Your Payment Software with RSI Security
The PCI SSF is changing the way payment software is protected, empowering developers and vendors to assure security to their clients with uniform controls and standards. However, compliance with the applicable SSF requirements demands careful implementation.
RSI Security is a comprehensive PCI compliance partner recognized by the PCI as a QSA, ASV, and SSF Assessor. We’ve helped countless organizations comply with PCI regulations and ensure seamless, secure payments for their clients, partners, and other stakeholders. We believe that the right way is the only way to protect your data, and we’ll help you do it efficiently.
To learn more about how we support PCI compliance, contact RSI Security today!
Contact Us Now!
