In the early days of PCI DSS, I recall having many conversations with vendors of payment applications and card-related services in which we spent hours persuading and educating providers about their new obligations.  This was before the Payment Application Data Security Standard (PA DSS), which gave us something more concrete to point to in these situations.

Thankfully, these conversations now are a rarity.  However, as the banks extend their compliance focus to level three and four merchants, who may rely on locally grown applications and services, situations still may arise where a vendor does not know about PCI or PA DSS.  Or the vendor simply may not consider their service subject to the standards.

For that matter, you may wonder if you are a service provider yourself!  Many organizations make use of multiple merchant accounts for a variety of legitimate business reasons.  In such circumstances, organizations may wrestle with this question.*

So, how does service provider compliance relate to merchant compliance?  And how is service provider status determined?

(continue reading…)

A reader recently submitted the following question to Ask PCI DSS Guru:

“A corporate service organization stores, processes, or transmits cardholder data on behalf of different departments. Each department is a merchant and there are thirty merchants . Is the corporate service organization a Service Provider under PCI even [if] it is internal?”

We saw this question arise about three years ago for a large institution (having just over 40 merchant accounts and over a dozen payment systems).  We maintained (and the institution’s acquiring bank agreed) that because the merchant accounts belonged to a single entity the services provided by that entity to its internal constituents did not make that organization a service provider.

Obviously, all of those merchant accounts were still in scope for PCI DSS and each system had to be certified compliant.  Here is another post that elaborates on the definition of a service provider under PCI.

Want a Word document copy of the entire policy template? Sign up for the PCI DSS Guru newsletter and receive a free copy that you can edit and use in your organization!

(12.5) Chief Security Officer (or equivalent) is responsible for overseeing all aspects of information security, including but not limited to:

• (12.5.1) creating and distributing security policies and procedures
• (12.5.2) monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel
• (12.5.3) (12.9) creating and distributing security incident response and escalation procedures that include:
• (12.9.1) roles, responsibilities, and communication
• (12.9.1) coverage and responses for all critical system components
• (12.9.1) notification, at a minimum, of credit card associations and acquirers
• (12.9.1) strategy for business continuity post compromise
• (12.9.1) reference or inclusion of incident response procedures from card associations
• (12.9.1) analysis of legal requirements for reporting compromises (for example, per California bill 1386)
• (12.9.2) annual testing
• (12.9.3, 12.9.5) designation of personnel to monitor for intrusion detection, intrusion prevention, and file integrity monitoring alerts on a 24/7 basis
• (12.9.4) plans for periodic training
• (12.9.6) a process for evolving the incident response plan according to lessons learned and in response to industry developments
• (12.6; 12.6.1.a) maintaining a formal security awareness program for all employees that provides multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings)
• (10.6.a) review security logs at least daily and follow-up on exceptions

(12.2.a) The Information Technology Office (or equivalent) shall maintain daily administrative and technical operational security procedures that are consistent with the PCI-DSS (for example, user account maintenance procedures, and log review procedures).

System and Application Administrators shall:

• (12.5.2) monitor and analyze security alerts and information and distribute to appropriate personnel
• (12.5.4) administer user accounts and manage authentication
• (12.5.5) monitor and control all access to data
• (12.8.1) maintain a list of service providers
• (12.8.3) ensure there is a process for engaging service providers including proper due diligence prior to engagment
• (12.8.4, 12.4) maintain a program to verify service providers’ PCI-DSS compliant status, with supporting documentation
• (10.7.a ) retain audit logs for at least one year

The Human Resources Office (or equivalent) is responsible for tracking employee participation in the security awareness program, including:

• (12.6.1.b) facilitating participation upon hire and at least annually
• (12.6.2) ensuring that employees acknowledge in writing at least annually that they have read and understand the company’s information security policy
• (12.7) screen potential employees prior to hire to minimize the risk of attacks from internal sources

Internal Audit (or equivalent) is responsible for executing an annual (12.1.2) risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment.

General Counsel (or equivalent) will ensure that for service providers with whom cardholder information is shared:

• (12.8.1, 12.4) written contracts require adherence to PCI-DSS by the service provider
• (12.8.2, 12.4) written contracts include acknowledgement or responsibility for the security of cardholder data by the service provider

Want a Word document copy of the entire policy template? Sign up for the PCI DSS Guru newsletter and receive a free copy that you can edit and use in your organization!

(7.1) Procedures for data control must be maintained by each department and must incorporate the following:

• Access rights to privileged User IDs are restricted to least privileges necessary to perform job responsibilities
• Assignment of privileges is based on individual personnel’s job classification and function
• Requirement for an authorization form signed by management that specifies required privileges
• Implementation of an automated access control system