Are you looking to learn about compliance risk and the importance of having effective compliance management systems? Are you unsure about what regulations apply to payment processing and need to review the regulatory landscape? Are you looking to learn about enforcement actions brought against banks and payment processors and what it could mean for you and your organization? This webinar educates listeners with an overview of third-party payment processors (TPPP), risk and regulations of TPPPs, and how they can impact your organization.

What is a Third-Party Payment Processor?

A third-party payment processor is a depository customer of a bank that uses their banking relationship to process payments on behalf of other companies through its bank. They are typically referred to as processors that process ACH and/or remotely created checks (RCC), although it is typically much broader than that because banks to do not have a contractual relationship with the TPPP’s merchant clients, so you can have credit cards, checks that are not remotely created, and return products that fall under this umbrella term. It is also important to note that TPPP is also synonymous with TSP, or third-party senders, by NACHA if they are processing ACH payments and must adhere to the third-party vendor requirements under the rules.

What Regulations Apply to Third-Party Payment Processors?

The following regulations that have been implemented for electronic payment processors are:

  • Electronic Funds Transfer Act (EFTA)
  • Truth-in-Lending Act (TILA)
  • Consumer Financial Protection Act (CFPA)
  • Federal Trade Commission Act (FTC Act)
  • Bank Secrecy Act
  • USA PATRIOT Act
  • NACHA Operating Rules

Watch the full webinar to learn more about third-party payment processors, the risks and regulations associated with them, and how you it could impact your organization. For more information, contact us today.

How Can You Prepare Your Organization for Phase 2 HIPAA Audits?

This webinar covers an overview of what to expect as we shift to a new phase of proactive supervision and how to prepare for an onsite audit from the OCR. 

First, let’s look at the background of the OCR Period Audit Process and Enforcement Action:

  • 2009: HITECH requires periodic audits of covered entities and business associates
  • 2011/2012: Phase 1 Audits began
  • 2013: Evaluation period, where they reviewed the results of Phase 1 Audits
  • 2014: Phase 2 Audits originally scheduled to begin, but because of delays, that date was not met

From the Phase 1 Audits, we learned:

  • 65% of findings were from the Security Rule
  • 7% Administrative Safeguards
  • 54% Technical Safeguards
  • 76% Physical Safeguards
  • 81% of findings were from Healthcare Providers
  • 66% of findings were from Level 4 entities
  • Trends moving forward into 2015/2016
  • Emphasis on risk analysis
  • Theft of electronic media
  • Attorneys General actions

A few examples that we cover in this webinar are from Anchorage Community Mental Health Services, which was fined $150,000 to settle findings, and Cignet, on which the HHS imposed a $4.3 million Civil Money Penalty. As your organization prepares for Phase 2 Audits, we recommend learning about the updated audit protocol, online portal for data collections, desk audits, and the HSS. Listen to the full webinar to learn details on these topics.

How can KirkpatrickPrice help? We are here to provide a roadmap to your organization. If you’re unsure of where to start, we recommend beginning with a risk assessment. We have very experienced risk assessment practices and can help you walk through that process. We can assist you in policy and procedure review, identify any gaps, and make recommendations. We have an audit approach that is modeled on the HIPAA Audit Protocol, which is published by the DHHS. We have expert personnel; when you work with KirkpatrickPrice, you’re working with someone who is certified in data security, IT governance, and information security. We also have a web-based portal experience; it could be beneficial for your organization to go through an audit with an audit partner before going through the audit with some type of supervisory organization, like the OCR. Contact us today to speak to an expert.

This session in our PCI Readiness Series highlights PCI Requirements 5 and 6, which work together to help organizations build and maintain a vulnerability management program. PCI Requirement 5 states, “Protect all systems against malware and regularly update anti-virus software or programs.” PCI Requirement 6 states, “Develop and maintain secure systems and applications.”

What is Requirement 5?

There are more people than you think looking to harm your environment. PCI Requirement 5 specifically calls out that your organization should protect against malware and use anti-virus software. Malware constantly shows up in today’s headlines. Malware could be viruses, worms, ransomware, Trojans, etc. Your organization should take every precaution possible to prevent a potential attack. This webinar discusses the following sub-requirements:

Requirement 5.1 – Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and servers.

Requirement 5.2 – Ensure that all anti-virus mechanisms are maintained.

Requirement 5.3 – Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Requirement 5.4 – Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.

What is Requirement 6?

Complying with PCI Requirement 6 will help your organization build a vulnerability management program that develops and maintains secure systems and applications. Attackers often use common security vulnerabilities to gain entry to systems in the targeted environment. Many common security vulnerabilities could be fixed with vendor-supplied security patches, but the issue arises when those patches are installed too late or not at all. The PCI DSS calls for all systems and applications to have all appropriate security patches implemented within an appropriate period of time in order to protect the cardholder data environment. This requirement is directed towards all applications in your environment, not just applications you’ve bought commercially or ones that you’ve developed. This webinar discusses the following sub-requirements:

Requirement 6.1 – Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.

Requirement 6.2 – Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Requirement 6.3 – Develop internal and external software applications in accordance with PCI DSS, based on industry standards or best practices, and incorporate information security throughout the software-development life cycle.

Requirement 6.4 – Follow change control processes and procedures for all changes to system components.

Requirement 6.5 – Address common coding vulnerabilities in software-development processes.

Requirement 6.6 – For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.

Requirement 6.7 – Ensure that security policies and operational procedures for developing and maintain secure systems and applications are documented, in use, and known to all affected parties.

To learn more about PCI compliance, check out our PCI Demystified video resources or contact us today.

This session in our PCI Readiness Series focuses on PCI DSS Requirements 3 and 4, which focus on encryption and protecting cardholder data. PCI Requirement 3 states, “Protect stored cardholder data.” PCI Requirement 4 states, “Encrypt transmission of cardholder data across open, public networks.”

What is Requirement 3?

PCI Requirement 3 gives organizations an opportunity to consider which retained data is required and which is becoming a liability for your organization. So how do you protect the stored cardholder data that is vital to your business? In this webinar, we will discuss the following sub-requirements:

Requirement 3.1 – Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes.

Requirement 3.2 – Do no store sensitive authentication data after authorization (even in encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

Requirement 3.3 – Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

Requirement 3.4 – Render PAN unreadable anywhere it is stored (including on portable, digital media, backup media, and in logs).

Requirement 3.5 – Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

Requirement 3.6 – Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.

Requirement 3.7 – Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

What is Requirement 4?

The culture we live in revolves around satellite technology, cell phones/GSM, Bluetooth, laptops, wireless Internet, and more. We may consider these things private, but the PCI DSS deems them to be public. PCI Requirement 4 helps prevent organizations from being a target of malicious individuals who exploit vulnerabilities in misconfigured or weakened wireless networks. To comply with PCI Requirement 4, sensitive data that your organization transmits over open, public networks must be encrypted. In this webinar, we will discuss the follow sub-requirements:

Requirement 4.1 – Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

Requirement 4.2 – Never send unprotected PANs by end-user messaging technologies.

Requirement 4.3 – Ensure that security policies and operational procedures for encrypting transmission of cardholder data are documented, in use, and known to all affected parties.

To learn more about PCI compliance, check out our PCI Demystified video resources or contact us today.

Are you a merchant, service provider, or sub-service provider who stores, processes, or transmits cardholder data? If so, this is a great place to be introduced to the PCI DSS.

The PCI Security Standards Council is a third-party organization that was developed for the sole purpose of managing the security of cardholder data. Prior to the PCI Security Standards Council, each payment card brand managed their own security standards. Eventually, the payment card brands realized that it was counterproductive to have five different sets of standards that their clients had to audit against, thus, the PCI Security Standards Council and the PCI Data Security Standards were created. The PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The founding payment brands for the PCI Security Standards Council include Visa, Inc., MasterCard, Discover Financial, American Express, or JCB International.

If you store, process, or transmit cardholder data, interact with payment card data in any way, or have the ability to impact someone else’s cardholder information or the security of that information, you are subject to comply with the PCI DSS. The PCI Security Standards Council and payment card brands are major participants in the PCI environment and are responsible for tracking and enforcing PCI DSS compliance, penalties, fees, compliance deadlines, and the monitoring and facilitating of investigations. The other entities that are impacted by the PCI DSS compliance lifecycle are acquiring banks, issuing banks, merchants, service providers, and sub-service providers.

What is Requirement 1?

PCI Requirement 1 states, “Install and maintain a firewall configuration to protect cardholder data.” To comply with PCI Requirement 1, you’ll need to understand several aspects of firewall configuration. We will discuss the follow sub-requirements of PCI Requirement 1:

Requirement 1.3 – Prohibit direct public access between the Internet and any system component in the cardholder data environment.

Requirement 1.4 – Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network, and which are also used to access the network.

Requirement 1.5 – Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

What is Requirement 2?

PCI Requirement 2 states, “Do no use vendor-supplied defaults for system passwords and other security parameters.” Did you know that vendor-supplied default information, such as account names and passwords, pose a serious threat to your organization’s security? Yes, vendor-supplied defaults might make installation or even support easier, but they also make it pretty simple for hackers to find the information needed to attack and exploit your system. How can we prevent this?Let’s learn together from PCI Requirement 2. This webinar will discuss sub-requirements such as:

Requirement 2.1 – Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

Requirement 2.2 – Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Requirement 2.3 – Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Requirement 2.4 – Maintain an inventory of system components that are in scope for PCI DSS.

Requirement 2.5 – Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.

Requirement 2.6 – Sharing hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

To learn more about PCI compliance, check out our PCI Demystified video resources or contact us today.