Many retail businesses, whether a single small shop or a nationwide big-box chain, tend to process credit card payments in one consistent manner. In contrast, higher education institutions, hospitals, and state and local government (SLED) environments operate more like a collection of many small businesses, each with unique needs reporting under one organizational umbrella.
When you’re dealing with hundreds of Merchant IDs (MIDs), figuring out whether you comply with PCI standards can feel overwhelming. In fact, the hardest part is getting organized before you even examine your first PCI DSS control. Start by asking yourself a few key questions:
- How many different acquiring banks have issued our Merchant IDs?
- How many MIDs do we have from each acquirer?
- How many different payment acceptance methods do we use?
- How many of our merchants don’t have their own MID?
An Attestation of Compliance (AOC) helps acquiring/merchant services banks assess the risk they incur by supporting you in accepting/processing payment cards. The questions above help you group your merchants correctly. If you work with multiple acquiring banks, you will generally want to report via SAQ(s) only on MIDs from a given bank, rather than mixing activities tied to multiple banks.
Here are some practical steps to creating a structured, repeatable process:
Step 1: List Each Merchant by Acquiring Bank
Start by cataloging every merchant under its respective acquiring bank. If a merchant area processes payments without its own MID, review the contract with the payment processor. Often, the merchant area is using a third-party MID (a MID owned by the payment service provider or platform provider, e.g., ticketing, event registration, etc.) through fully outsourced payment solutions.
Vendors such as Square, PayPal, and Stripe use different technical approaches (tokenization, proprietary encryption, P2PE (Point-to-Point Encryption), or SPoC—Software-based PIN entry on COTS). Even if a third-party vendor implements a validated solution like P2PE or SPoC, you will want to manage them using controls similar to a formal PCI DSS service provider, because you still have reputational risk.
The situation becomes complicated if your personnel are involved in processing transactions that settle against an external vendor’s MID(s). A full discussion is beyond the scope of this article, but, in brief, if your personnel process transactions “for” a different entity, which is the MID owner, you are acting as a formal PCI DSS service provider, even if that external vendor does not require you to attest.
Whether or not to conduct and document the results of a service provider assessment is a risk-based decision. The contract may also specify security obligations you must meet, like checking terminals for skimming devices or completing security awareness training.
Step 2: Group by Payment Processor or Acceptance Method
Once your MIDs are organized by acquiring bank, break them into groups based on how payments are accepted. Different business units often use entirely different hardware, software, payment providers, and workflows. For example:
- Admissions and the bookstore may use different terminals.
- Parking services, tutoring centers, cafeterias, and athletics may all rely on different systems.
- Seasonal operations, such as summer camps, conferences, sporting events, theatre, and fundraising, often have unique requirements.
Grouping merchants by their acceptance channels helps you determine which systems are in scope and how cardholder data is captured, processed, stored, and deleted. This, in turn, keeps your focus on the correct environment(s) and required security controls while performing assessments.
Step 3: Flag Issues that will Expand PCI DSS Scope (Complications)
For each merchant area or department, assess whether their payment process would be compliant in principle by answering questions such as:
- Is cardholder data logically and/or physically segmented from other systems (so that only systems that need card data can access it), or does cardholder data flow across a flat, unsegmented network, or have other access to non-payment programs and resources, like network file shares, non-payment websites, ERP systems, etc.?
- Do the written policies and operational procedures used by the area align with PCI DSS requirements (access controls, logging, patching, change control, etc.)?
- Are departmental personnel familiar with those policies and procedures, and do their actions in the field align with documented workflow?
- What specific technical, procedural, or training gaps exist that would prevent compliance?
Document the expected scope (which systems and flows touch card data) and the gaps for remediation planning.
Step 4: Validate in Person
We strongly recommend visiting every location during the first year and reviewing their processes end-to-end to avoid surprises. Ask open-ended questions such as:
- “Walk me through how you take payments.”
- “Do you accept payments face-to-face? Over the phone? By mail? Online? By email?”
- “Do you ever write down card information or receive it on paper?”
- “After processing, how do you handle any cardholder data?”
- “What information do you store, and for how long? Where? Who has access?”
Accepting card data through email, text messaging, network fax, or VoIP (Voice over IP) telephone is a red flag, as is any electronic retention of payment card data. Writing card information down can be acceptable temporarily if it is promptly shredded after processing.
Storing data longer term for legitimate business reasons can be compliant (at the cost of added risk and compliance burden), but storing the security code (CVV/CVC) after authorization is strictly prohibited. Sometimes, well-intentioned actions motivated by customer service can greatly complicate your PCI DSS compliance.
Moving into the Assessment
Once you’ve defined the scope for each merchant, you’re ready to assign and start completing the correct SAQs. Depending on how a merchant area processes cards, a SAQ can range from a relatively short questionnaire (a few dozen questions) to several hundred questions if card data travels across many systems in your network.
Consider bringing in a QSA (Qualified Security Assessor) to help define the scope, clarify requirements, and ensure that the correct SAQ(s) are assigned to each processing department. Though most acquirers only request a single SAQ D (that we call a “roll-up”) covering your entire operation, we have found that the annual assessment process flows more quickly, and is more accurate, when it is broken down by processing department and payment channel.
Effectively, each area + payment channel is treated as a small “mom and pop” merchant, where the appropriate SAQ for that type of operation is completed and later contributes to the overall roll-up. This often does require a merchant area manager to complete two or more reduced SAQs, like SAQ A for fully-outsourced e-commerce and SAQ P2PE for validated P2PE solutions. This is still much more focused than asking the same manager to complete SAQ D, which is the “correct” SAQ once two or more payment acceptance methods are in play.
Having each merchant complete their own SAQ is an effective way to ensure accountability. Someone at a senior level will ultimately sign the AOC (attestation), and banks use this document to determine your risk level, which can influence rates, fines, or even the ability to continue processing transactions.
After the First Year
Each SAQ and AOC is only valid for one year. We recommend having each merchant complete their own SAQ annually, with support as necessary from IT and your PCI team. In addition, have your audit team or a third-party assessor visit a reasonable sample of merchant areas each year. This sampling approach helps:
- Reinforce proper PCI practices
- Ensure policies are being followed
- Detect any “creative” approaches to payment acceptance
- Provide leadership with confidence that cardholder data is being protected
Bringing order to PCI compliance in a SLED environment is about building a repeatable, structured program more than solving a single technical problem. By organizing merchant areas, defining clear scopes, validating practices in person, and involving appropriate expertise, you create a framework that can be maintained year after year.
Most importantly, you help each department understand its responsibilities, which moves PCI compliance from an annual scramble to an ongoing culture of protecting cardholder data.
As payment technologies evolve and expectations around security increase, maintaining compliance becomes more than meeting a standard; it becomes a commitment to safeguarding the trust placed in your organization.
With the right processes, regular validation, and a collaborative approach, SLED organizations can confidently reduce risk, support secure payment operations, and ensure that every department plays its part in protecting cardholder data.
This comprehensive, culture-driven approach also has the benefit of allowing you to align your PCI DSS compliance burden with risk tolerance and overall strategy, so that you utilize budgetary and personnel resources properly and efficiently.
CampusGuard Central®, our robust customer portal, helps you assess, track, and document PCI DSS compliance across all your locations and departments. Request a demo or contact us to get started.
Definitions:
- Acquirer: Acquiring or Merchant Services bank
- AOC: Attestation of Compliance (included within SAQs); demonstrates compliance status or result of assessment
- CVV/CVC: Card Verification Value/Card Verification Code; card security code on credit and debit cards used to help prevent fraud.
- MID: Merchant ID/Merchant account
- P2PE: Point-to-Point Encryption
- PCI DSS: Payment Card Industry Data Security Standard
- QSA: Qualified Security Assessor
- SAQ: Self-Assessment Questionnaire
- SPoC: Software-based PIN entry on COTS (consumer off the shelf)
- SLED: State/Local Government, and Education
