Payment Card Assessments

PCI levels are categories that the PCI Security Standards Council (SCC) and card brands (VISA, MasterCard, American Express, Discover, and JCB) use to determine PCI compliance validation and reporting requirements for both merchants and service providers. The levels are numbered 1 through 4, with 1 at the highest level.

At level 1, merchants and service providers are required to engage an independent Qualified Security Assessor (QSA) to validate compliance with the PCI Data Security Standard (DSS).

Level 2 through level 4 merchants and service providers are permitted, but not required, to self-validate compliance with the DSS. They may also have a QSA validate compliance.

Ultimately, all entities that store, process, or transmit cardholder data are required to comply with all relevant PCI DSS requirements, regardless of transaction volume. Having a QSA validate compliance with the DSS provides confidence and assurance that the cardholder data environment (CDE) is securely controlled and that relevant requirements have been met.

Policies and procedures help create an internal control framework within an organization. Management uses this internal control framework to rely upon and ensure that the organization's objectives are being met.

The main objective of having formally documented policies and procedures is to help guide the organization’s operation and the procedures needed to fulfill the policy.

Having well written policies and procedures helps auditors when assessing risk and performing any type of compliance work. It also helps an organization stay consistent when management needs to make decisions. When documenting formal policies and procedures, it is important to keep them as simple as possible and involve all staff members for their development. It is also important to keep them easily accessible and promote them throughout the organization.

Q: We are a SaaS provider that follows a Scrum methodology, generally with two-week sprints. We do not handle cardholder data, but several clients are requiring vulnerability scans to show compliance to the PCI DSS standard.

A: Many software providers are being required to be PCI compliant due to contractual requirements and/or because their application may be on the same network as PCI in scope systems, even though it may not store, process, or transmit cardholder data.

The 11.2 requirement of the PCI DSS requires vulnerability scans at least quarterly and after any significant change in the network and includes examples such as new system component installations and product upgrades. The Product Owner can likely determine whether changes to the product are a minor update, which likely wouldn’t mandate a vulnerability scan, or a major update, which likely would. A major update may include the migration to a new version of the development framework (e.g. moving from Rails 3.x to 4.x), or a critical piece of the application such as the authentication components. The 11.2 requirement focuses on detecting flaws at the application and network layers, but isn’t meant to be code scanning, which is covered more in Requirement 6: Develop and maintain secure systems and applications.

That being said, the higher the frequency of vulnerability scanning, the timelier the results will be and it is often easier to incorporate the results of the scan into the development life cycle.

Some organizations, particularly larger organizations, will continuously conduct vulnerability scans, often unannounced. There are benefits to aligning scan schedules with the two-week sprints, or perform monthly, which is generally more in-line with vendor patch updates. Either way, organizations that scan on a more frequent basis than quarterly tend to have an easier time achieving clean scan results. Additionally, limiting your scans to run on a quarterly basis increases the risk that a fix doesn’t get into the backlog in time.

The result of a compliant PCI DSS assessment is the generation of an Attestation of Compliance (AOC) as well as a Report on Compliance (RoC). The AOC is attesting to the organization’s compliance with the PCI DSS standards, different than an audit attestation report, which may be governed by the AICPA.

Data Retention is not just about being able to evidence controls and processes for an audit.

Data should be retained according to client directives, contractual obligations, legal and regulatory requirements, and internal reporting standards. Certain certifications and compliance standards require various retention requirements, for example PCI requires logs and recordings to be available for a minimum of 90 days for certain controls; whereas, other requirements and compliance efforts may require 12 months or greater, or may not specify a retention requirement at all. For data retention requirements related to your compliance initiatives, please contact your BrightLine engagement representative.