If your organization was subject to PA-DSS compliance in years past, you may need to achieve PCI Secure SLC certification as soon as possible. The most efficient path begins with scoping before in-depth implementation and assessment—all of which an advisor can optimize further.
Are you prepared for PCI Secure SLC certification? Schedule a consultation to find out.
Optimizing Your PCI SSLC Compliance
The Payment Card Industry (PCI) Secure Software Lifecycle (Secure SLC or SSLC) regulation aims to protect the environments in which payment software is developed. To become SSLC compliant, organizations need to meet a wide variety of requirements, which can be challenging both for organizations certifying for the first time and those mapping over from other regulations.
Organizations can optimize their journey to compliance by focusing on three critical processes:
- Understanding the scope of your implementation and assessment requirements
- Installing and maintaining controls to meet the specifications of the framework
- Securing an assessment partner, conducting an assessment, and reporting on it
Working with a qualified PCI SSLC compliance advisor or assessor is the best way to minimize costly errors, overlap, adjustments, and other oversights as you carry out all these processes.
Determine Your Implementation Scope
Up until October 2022, payment software security was governed by the Payment Application Data Security Standard (PA-DSS), which applied to most payment app developers and vendors.
But the PCI’s Security Standards Council (SSC) has since replaced the PA-DSS with a new two-part standard called the Software Security Framework (SSF). The SSF comprises two distinct parts, the SSLC and the Secure Software Standard (unofficially SSS or The Standard).
The Secure Software Standard applies directly to payment software itself rather than its vendors or developers. Although these parties are who get the software validated, it is the software that is compliant. Validation assessments measure the extent to which the software’s settings, defaults, and other elements protect payment and consumer data from being compromised.
The SSLC applies to the environment in which payment software is developed. It applies to the developers and vendors themselves rather than the apps or programs. It measures the extent to which they have security governance in place to detect and mitigate risks that could lead to data being compromised during its development or at any point in the software’s entire lifecycle.
Understanding your scope means knowing which frameworks and requirements apply.
Request a FREE Consultation
Who Needs Which Parts of the PCI SSF?
In a nutshell: if you were previously subject to the PA-DSS, there is a strong chance that one or both component parts of the SSF apply to your organization. Whether and which frameworks apply depends on the nature of your organization’s relationship to the software in question.
As noted above, the Secure Software Standard validates pieces of payment software such as apps or programs that process payments and related data. Specifically, it governs such software that is provided in a third-party capacity (product or service) rather than developed for internal use. It applies to payment software being sold or distributed and, by extension, to the parties responsible for selling it. Those vendors are responsible for validating the software’s security.
The SSLC applies directly to vendors and developers of payment software, again specifically those making such applications for third-party use. Rather than assessing individual pieces of software, vendors must validate the security of their development and management processes.
In practice, it is very common for both the Secure Software Standard and SSLC to apply to an organization simultaneously. And, while validating compliance across both may appear to be a hurdle, SSLC compliance allows for swifter and less resource-intensive SSS assessments.
Other Regulatory Compliance Considerations
Just as both parts of the SSF may apply to your organization, one or both frameworks also might coexist alongside other regulations, both from the PCI SSC and otherwise. To begin with, the SSC’s own Data Security Standard (DSS) version 4.0 applies to most organizations that process credit card information. If your organization processes card payments for its payment software in B2B or B2C offerings, there’s a strong chance you’ll need to be DSS compliant. That requires a separate control implementation and distinct audit reports, which may be challenging.
However, one benefit of the overlap between SSF and DSS compliance is that, unlike the PA-DSS, the SSF requirements are directly influenced by the DSS, which facilitates mapping.
And, beyond the PCI’s own regulations, countless others may apply.
If you provide payment software to organizations in or adjacent to healthcare, you may be considered a covered entity under the Health Insurance Portability and Accountability Act (HIPAA). HIPAA also requires business associates of covered entities to comply. If you process the personal data of residents in protected areas, you may be subject to government regulations like the California Consumer Privacy Act (CCPA) or the European Union’s General Data Protection Regulation (GDPR). These frameworks (and others) may all apply simultaneously.
When determining your PCI SSF implementation scope, consider which other frameworks apply and what kind of mapping and optimizations are available to you. Working with an assessor or using an omnibus framework like the HITRUST CSF will help you minimize control overlap.
Implement PCI SSLC Control Objectives
Assuming the Secure SLC framework applies to your organization, you’ll need to implement its various requirements in preparation for an assessment. The PCI SSLC uses an objective-based approach to organizing requirements. There are ten over-arching Control Objectives, which are distributed across four primary categories. Each Control Objective breaks down into one or more parts. For example, Control Objective 1 includes Control Objectives 1.1., 1.2, and 1.3.
In the Test Requirements for each Control Objective, these sub-requirements may then break down further into specific details. For example, Objective 1.2 includes Test Requirements 1.2.a and 1.2.b. All Control Objectives are also accompanied by Guidance, which provides practical tips and best practices for meeting or exceeding the respective requirements efficiently.
Below, we’ll summarize the most critical information across each Control Objective, including points of emphasis in the Test Requirements and Guidance, to facilitate your implementation.
Software Security Governance Requirements
These top-down Control Objectives are designed to measure an organization’s commitment to overall software security across all of its production and vending processes. They include:
- Control Objective 1 – Establishing formal security responsibilities and resources:
- 1.1: Senior leadership teams assign and update overall responsibility and accountability for the security of payment software products and services.
- 1.2: Leadership delegates specific software security responsibilities to individuals and communicates them clearly (1.2.a), as measured by staff interviews (1.2.b).
- 1.3: Leadership ensures that individuals assigned security responsibilities are adequately trained and supported with appropriate resources to uphold them.
- Control Objective 2 – Defining and communicating security policies and strategies:
- 2.1: Leadership clearly identifies and monitors regulatory and other requirements to be maintained across operations and processes related to payment software.
- 2.2: Leadership disseminates policies commensurate to the requirements with specific measurables (2.2.a), clearly understood by staff interviewed (2.2.b).
- 2.3: Leadership establishes and maintains a formal strategy for ensuring that requirements are met and policies are followed throughout the software lifecycle.
- 2.4: Leadership implements and maintains security assurance processes, ensuring the inventory (2.4.a) pertains to all relevant Control Objectives (2.4.b).
- 2.5: Leadership continuously generates and maintains evidence demonstrating processes’ efficacy, subject to inventory tests (2.5.a) and interviews (2.5.b).
- 2.6: Leadership identifies and addresses weaknesses or failures across process inventory with appropriate detection (2.6.a) and mitigation (2.6.b) protocols.
Secure Software Engineering Requirements
These Control Objectives focus on risk detection, identification, and mitigation capacities of software and of the environments and processes used to develop it. They break down into:
- Control Objective 3 – Continuously identifying, assessing, and managing threats:
- 3.1: Developers and related teams identify critical assets and classify them according to applicable confidentiality, integrity, and resiliency requirements.
- 3.2: Developers continuously identify and assess threats of design weaknesses (3.2.a) or related to open source components 3.2.b) across all software (3.2.c).
- 3.3: Developers incorporate software security controls (3.3.a) that are reasonably justifiable relative to residual risk (3.3.b) and mitigate all identified threats (3.3.c).
- 3.4: Developers detect failures and weaknesses in software security controls (3.4.a) and update, augment, or replace controls deemed ineffective (3.4.b).
- Control Objective 4 – Continuously detecting and mitigating vulnerabilities to attacks:
- 4.1: Organizations account for emerging vulnerabilities with regular scans, including appropriate testing processes (4.1.a) and test tools (4.1.b, 4.1.c).
- 4.2: Organizations respond to newly discovered security vulnerabilities in a timely manner, including defined fixes and processes for new and existing weaknesses.
Secure Software and Data Management Requirements
These Control Objectives pertain to integrity across payment software and its development lifecycles, ensuring that changes and other activities are accounted for. They comprise:
- Control Objective 5 – Monitoring and managing changes to payment software:
- 5.1: Organizations identify, assess, and approve all changes to software, including processes for authorization (5.1.a) on a per-change basis (5.1.b).
- 5.2: Organizations identify and track all versions of software throughout its lifecycle, including categorizing changes (5.2.a) and updates (5.2.b) by version.
- Control Objective 6 – Protecting software integrity throughout the lifecycle:
- 6.1: Developers ensure the integrity of code throughout the software lifecycle.
- 6.2: Developers deliver updates in a secure manner, ensuring code integrity.
- Control Objective 7 – Ensuring the protection of sensitive production data
- 7.1: Developers limit the collection and retention of sensitive data related to payment software production to systems with a business or technical need.
- 7.2: Developers protect sensitive production data that is retained across software vendor systems and ensure it is securely deleted when it is no longer needed.
Security Communications Requirements
These Control Objectives ensure that vendors and developers communicate security-relevant information to stakeholders (i.e., users) in a timely manner. They break down as follows:
- Control Objective 8 – Providing software vendor implementation guidance:
- 8.1: Vendors provide stakeholders with clear, comprehensive information on how to implement, configure, and operate (8.1.a) all elements (8.1.b) of software.
- 8.2: Vendors guide stakeholders on all supported components and platforms.
- 8.3: Vendors provide up-to-date and comprehensive information (8.3.a) aligned with available and upcoming updates and provided timely upon update (8.3.b).
- Control Objective 9 – Maintaining stakeholder communications channels:
- 9.1: Vendors make channels available for customers and users of the payment software to communicate bi-directionally about security and mitigation issues.
- 9.2: Vendors notify stakeholders about security updates clearly and timely.
- 9.3: Vendors supply information about mitigating risks associated with known vulnerabilities and exploits, including when complete mitigation is not available.
- Control Objective 10 – Providing comprehensive software update information
- 10.1: Vendors provide summaries of specific changes made to the software upon update, ensuring messaging is clear, accessible (10.1.a), and accurate (10.1.b).
Conduct an SSLC Assessment and Report
Finally, with all your controls in place, you’ll need to conduct an official assessment and report on its findings to validate your compliance. For PCI Secure SLC certification purposes, you’ll need to contract a third-party assessor vetted and listed by the PCI SSC. At present, it is not possible to self-assess for SSF compliance. However, organizations that achieve SSLC certification can perform select elements of Secure Software Standard validation internally.
When you find an assessor, they will test all controls according to the Test Requirements listed in the framework. They’ll confirm whether the requirements are met and, if not, potentially provide advice on remedial steps needed. Once all requirements are met, they’ll produce a Report on Validation (ROV) and an Attestation of Validation (AOV). The AOV confirms the accuracy of the ROV and must be signed by the assessor and a leader at your organization.
Once your reporting is completed, your organization will have attained SSLC compliance. But, critically, compliance is not a finite achievement but rather an ongoing process to be maintained.
Streamline Your PCI SSLC Certification Today
Attaining and maintaining PCI SSLC certification requires understanding the scope of your compliance needs, implementing controls to meet applicable requirements, and assessing and reporting per PCI protocols. Along the way, one of the best ways to ensure that each of these processes is operating as smoothly and efficiently as possible is to work with a PCI advisor.
RSI Security has guided countless organizations along their PCI certification journeys, including DSS, PA-DSS, and now SSF compliance. We understand that the right way is the only way to keep payment software and sensitive financial information safe. We’re committed to helping you do so efficiently without compromising on discipline—which is the key to freedom down the line.
To learn more about our PCI Secure SLC Certification services, contact RSI Security today!
Learn how RSI Security can help your organization. Request a Free Consultation
 |
