Open Mobile Menu

Blog

Am I Prepared for a PCI Assessment? Part 2: Organization and Scope

Views: 508

Written By: Chip Ross March 21, 2019

This is Part 2 in a 4-part series exploring how to ensure readiness for a Payment Card Industry (PCI) assessment, and how to avoid issues that can cause delays and additional costs. In Part 1, we discussed:

  • The need for upper-management commitment
  • Definitions of Merchants and Service Providers
  • Who might be asking for proof of PCI compliance
  • Determination of Merchant or Service Provider level
  • Available PCI compliance validation options

Once we understand the basics of how PCI compliance validation works from the outside, we need to ensure we need to identify all situations in our business that may have PCI compliance implications.  

Do I Understand My Organization?

From a PCI perspective, it’s all or nothing. Either an entity is compliant, or they aren’t. That means it’s very important to ensure that all portions of an entity’s business are considered. If one part of a business is compliant, but another part that is not compliant is discovered during the course of the assessment, it can lead to added delays and costs. There are two types of entities to be considered, and different approaches may be used.

Wholly-owned subsidiaries

In the ROC reporting template (see Part 1[CR2] ), there is a specific section for listing all business entities that require compliance with PCI DSS. It specifically mentions wholly-owned entities, and allows the assessor to list whether each entity is included as part of the assessment, or will be assessed separately. The PCI DSS Glossary doesn’t specifically address what wholly-owned entities are, but includes this definition:

Entity

Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.

Lacking any other direction, we follow the Merchant IDs (MIDs) (sound familiar? If not, see Part 1). Any entity that is using a particular MID, must be included in the same assessment. Conversely, if there is some sort of organizational unit that is somehow legally defined, it may be possible to conduct a separate assessment for that particular entity.

This is especially important for any assessment involving an Self-Assessment Questionnaire (SAQ). The SAQ templates don’t have the same section specifically calling out wholly-owned entities. However, there is a spot for ‘Company Name’, and ‘DBA (doing business as)’. That means that if the company has legally defined organizational units, and are using different MIDs, it may be possible to conduct separate assessments for each.

Remember, for most Merchants, the acquirer is the one that sets the reporting requirements. That being the case, if there are any questions regarding which organizational units should be included in any particular assessment, consult the acquirer for direction. For Service Providers, consult each of the card brands. 

Business units

Once the entities which require reporting have been determined, it’s important to ensure that all business units of the entity are considered. It’s entirely possible for a business unit to accept cardholder data without consulting IT or Compliance personnel (That never happens, right?). This unexpected increase in Scope (discussed further in this article) can lead to delays and added cost.

Additionally, it’s important to obtain input from all business units. In fact, if it’s possible, we recommend that representatives from all business units meet together to explore how each may handle cardholder data. We’ve found that this sort of meeting allows the representatives to ‘bounce’ things off of each other, often revealing previously unknown or unconsidered cardholder data handling.

How Are My Organizations Handling Cardholder Data (CHD)?

In Part 1, we established that entities handling a large amount of transactions must complete a Report on Compliance (ROC), which addresses all ways CHD is handled.

Entities without large transaction counts may opt to use one of the available SAQs. The SAQs also take into consideration how an entity handles CHD. Is it all e-commerce? Are there face-to-face transactions? Is CHD stored?

The SAQs are labeled A, A-EP, B, B-IP, C-VT, C, P2PE, and D. There are separate SAQ-D documents for Merchants and Service Providers.

Why is this important? Well, each of the different SAQs has a different number of requirements. For example, and SAQ-A has 22 requirements, and an SAQ-D for Merchants has 330. It is important to note that SAQ-D is the only option for Service Providers that aren’t required to complete a ROC, and contains 369 requirements.

More information regarding how the way CHD is handled affects which SAQ can be used is also available in the blog article: https://www.appsecconsulting.com/blog/pci-101-transaction-volumes-and-validation-requirements

AppSec Consulting has seen it happen numerous times; we discover unknown information about the environment during the assessment that ends up changing the nature of the engagement. It is not much fun when we discover an unknown process or system, which requires more validation tasks to complete a ROC, or requires the entity to complete a much more complicated SAQ. How do we avoid this? We carefully examine the Scope.

What is My Scope?

Consult the PCI Data Security Standard (PCI DSS) for a detailed discussion regarding the scope of a PCI assessment. We will not restate it here, but at a high level, the Cardholder Data Environment (CDE) which includes all people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data, and all systems connected to or supporting the security of the CDE are in-scope for the assessment. It is extremely important that each entity understand exactly how they handle CHD, or in the case of some Service Providers, how they are affecting the security of another entity’s CHD.

Some of the items that are important to know before any engagement are:

  • Data flows; determine where is CHD:
    • Entering
    • Leaving
    • Traversing systems
  • Payment Acceptance Channels; is CHD obtained through:
    • Websites
    • Mobile applications
    • Telecommunications
      • Phone
      • Fax
      • Voice Over IP (VOIP)
    • Postal Mail
    • Email
    • In person via Point of Sale/Interaction devices (POS/POI; registers, card swipes)
    • Chat
  • CHD storage; where is CHD:
    • Stored on my systems (databases, file storage, call recordings)
    • Stored by another entity (hosting providers, off-site storage)
    • Backup systems (both online and backup tapes)
    • Hard-copy documents
  • How is stored CHD protected:
    • Encryption at rest, and in transit
    • Data destruction once no longer needed
  • Infrastructure; do I understand which system components are used to store, process, transmit, or protect CHD, including:
    • Network devices
    • Servers
    • Appliances
    • Other systems providing security controls (VPN servers, logging systems, etc.)
    • Inventories of all system components
  • Service Providers/Outsourcing; are outside entities:
    • Storing, processing, or transmitting my CHD
    • Providing other managed services affecting the security of my CHD
    • PCI compliant
    • Not PCI compliant
    • Providing documentation regarding which requirements are being addressed by them
    • Covered by contracts which require them to protect any CHD they may posses
    • Personnel; do I understand those who:
    • Receive CHD or enter CHD into any systems
    • Can view clear-text CHD
    • Have access to the CDE (cardholder data environment)
    • Manage the system components
    • Are roles defined and documented?
  • Scope reduction; to reduce scope, have I implemented
    • Network Segmentation
    • Payment Tokenization
    • Data-loss prevention (DLP)
    • PCI SSC validated Point-to-Point Encryptions solutions (P2PE)
    • Other third-party solutions

Do I have a documented Scoping statement?

One of the easiest ways to ensure preparedness is to assemble all of the above information about the environment into a consolidated Scoping statement. It is basically a narrative describing the results of the efforts of your scope determination. It should describe the people, processes, and technologies regarding how your organization handles CHD, or impacts the security of another entity’s CDE.

This is a valuable tool, as it helps assessors see how the entity examined their environment, to ensure they know where CHD is present, and where it should not be present. It can also contain evidence, or references to evidence, showing the accuracy of the scoping exercise. Finally, this sort of effort is usually done collaboratively, and provides a forum where personnel can share information, which may lead to discovery of previously unknown or unconsidered possible locations of CHD.

How Can AppSec Consulting Help?

Our Qualified Security Assessors (QSAs) leverage AppSec Consulting’s proven PCI Assessment methodologies. Their many years of security, IT, development, and PCI auditing experience ensures that whatever your goals, the outcome is exactly what you need and makes strategic sense for your business. Whether you’ve been asked by your bank “to comply with PCI”, or preparing for your first validation with a Report on Compliance (ROC), gearing up for annual re-validation, or would just like to know what the PCI DSS mean to your business, our team of experts are there to help.

More information can be found at www.appsecconsulting.com, or call us at 408-224-1110

Chip Ross

Chip came up through the ranks of Information Technology, beginning as a contract Desktop Field Engineer in 1997. His career evolution included leading the Desktop Operations team at Northwest Airlines, including day-to-day work direction for a team of 14 packagers and maintaining communication with upper management regarding desktop operations. In 2006, he transitioned to Information Security and delivered compliant merchant RoCs for 2007 – 2010, including the year of the Northwest/Delta merger.

Chip moved to Carlson in 2010 and continued delivering compliant Service Provider and Merchant RoCs from 2010 – 2012 as a Carlson-sponsored ISA. During that time, Chip also conducted many assessments at Carlson hotel and restaurant franchisees, providing on-the-ground guidance to the smaller merchants that make up a large portion of Carlson’s organization. Chip joined United Health Group as a sponsored ISA in early 2013, to provide guidance, tracking and reporting on the PCI efforts for the various teams and business units there.

Drawing on his experience, leading, participating, tracking and reporting on many remediation projects, Chip helps clients achieve their compliance goals through scope reduction, process improvement, and strategic technology integration. Chip’s broad background and extensive PCI experience with large corporations enables him to be comfortable working with client personnel anywhere from the data center to the board room, ensuring that AppSec Consulting’s clients receive thorough, top-quality consultation and assistance.

read more articles by Chip Ross