PCI DSS Training for Agencies That Take Card Payments at the Counter

A municipal utility billing office has 2 payment windows. Residents come in to pay a water bill, hand over a debit card, and a clerk runs it through a countertop terminal. The office takes a few hundred card payments a month, employs 4 people, has no security team, and has never been asked for a self-assessment questionnaire by anybody.

That office is inside PCI DSS all the same. Its finance director usually discovers it during a bank review. That review is usually where the first reaction arrives, which is that the standard was written for retailers and processors.

The standard draws no such line anywhere in its text. What such a line would change with size is the volume of technical work. The part that covers people does not change at all.

Those people are the subject of 5 questions, and they arrive in a predictable order. The office has to work out whether PCI DSS applies to a government agency at all, and whether the terminal at the window changes the answer. It then has to work out what Requirement 12.6 asks for and how often it has to happen. The last question is what applies to an agency that would not apply to a shop across the street.

Only the first of those questions decides whether the rest matter.

Does PCI DSS Apply to a Government Agency?

The first question has an answer in 2 parts, because PCI DSS gets to a public agency by 2 different routes. One of them is contractual and the other is statutory, and your own answer may involve both at once.

The contractual route is the one every agency travels. PCI DSS is published by the PCI Security Standards Council and imposed through the agreements an organization signs with its acquiring bank and the card brands. It is not a federal statute, and calling it one is the most common error in agency policy documents. An agency that accepts cards has agreed to it the same way a hardware shop has, and the consequence of falling short is contractual.

The second route is statutory and applies in a small number of states. Of those states, Nevada is the one that matters most for public bodies. Under NRS 603A.215(1), a data collector doing business in Nevada that accepts a payment card must comply with the current version of the PCI Data Security Standard. The duty runs to the transactions connected with a sale of goods or services.

Everything in Nevada turns on the term data collector. That term is defined in NRS 603A.030 as any governmental agency, institution of higher education, corporation, financial institution or retail operator, alongside other business entities. A city, a county, and a state department are each inside that definition.

Being named there is what puts PCI DSS public agencies inside a statute as well as a contract. NRS 603A.215(4) then limits the exemptions to telecommunication providers conveying the communications of other persons and to data transmission over a secure, private communication channel. Public bodies are given no exemption from either of them.

The 3 States Are Not Doing the Same Thing

Those 3 states are frequently listed together as the ones that legislated PCI DSS. Listed that way, Nevada, Minnesota and Washington each do something quite different. Reading them as one rule is where agency policy usually goes wrong.

Only the Nevada row in that table is a duty to comply with PCI DSS. The Minnesota statute codifies one specific practice without naming the standard. The Washington provision is a shield for organizations that already comply, which makes it useful only to an agency that has done the work and can show it.

An agency in government and public sector working from a policy that groups the 3 will overstate what Minnesota asks of it. It will also underuse the safe harbour Washington offers it. That distinction matters more when several bodies share one policy, which is a difficulty multi-agency training rollouts meet for other reasons as well.

Either route puts the same terminal at the window inside the standard. The counter is where both of them arrive, and it is where the next question starts. Which route applies to you changes the consequence of falling short, and changes nothing at all about what the clerk at that counter has to be taught.

Does a P2PE Terminal or a Short Self-Assessment Remove the Duty?

The terminal at the window is usually the next thing raised. A validated point-to-point encryption device encrypts card data at the moment of capture, so the agency's own network never holds readable cardholder data at any point in the transaction. The self-assessment that follows is far shorter than the full one.

Common but wrong

A P2PE terminal takes our counter staff out of PCI DSS.

Scope reduction of that kind lowers technical scope. It reduces the systems in the cardholder data environment and shortens the assessment. The Requirement 12.6 awareness obligations continue to apply to the people who handle cards.

What Scope Reduction Does and Does Not Move

That outcome surprises people because scope reduction is usually explained as a way of getting a smaller PCI footprint, and it is. Technical controls contract because there is less technology in scope. What the device cannot do is take a person out of the path the card travels, and the awareness requirements are written about that person.

Staff numbers stay where they were before the device arrived. A clerk who takes a card at a counter can still be phished and can still write a number on a notepad. That same clerk can still be talked into reading one aloud over the phone. Awareness requirements exist for those handling risks, and no terminal covers any of them.

For a 4 person office, that split is the useful half of the news. The technical burden is small once a validated device is in place. Most of what remains is what Requirement 12.6 asks for.

What Does Requirement 12.6 Ask For?

Requirement 12.6 asks for a program, a review of that program, and training for the people who do the work. None of the 3 depends on how many cards the office takes. All 3 produce a document somebody can hand over.

What a Small Counter Operation Has to Produce

For your utility billing office those 3 come to a short set of artifacts. Each one is a single document somebody writes once. None of them takes longer than an afternoon to assemble once the decision about frequency has been made:

• A written policy the counter staff can read.
• A completion record for each of the 4 employees.
• Course content that covers phishing and acceptable use specifically.
• A note of when the program was last reviewed.

Nothing on that list requires a security team, a consultant, or a platform the office cannot afford. It requires content that already exists and a record that survives someone leaving. What the list does require is a decision about how often.

Which 12 Months Is Being Counted?

Frequency is 2 questions, because 12.6.2 and 12.6.3 both use 12 months and count different things. Reading them as one 12-month cycle is the error that produces a training record nobody can defend at the next bank review.

1. The program review. 12.6.2 puts the awareness program itself on a 12 month cycle, so the material is looked at and updated where updating is needed. The subject being counted is the program.
2. The person's training. 12.6.3 puts each individual on a 12 month cycle and adds a second trigger, because training is also required upon hire. The subject being counted is the employee.

Why the 2 Cycles Come Apart

Those 2 cycles come apart the first time somebody is hired mid-year. A billing office that reviews its program every January and trains all 4 staff at the same time keeps both aligned until it hires someone in June. The new employee needs training upon hire, which starts an individual clock in June, while the program review stays in January where it has always been. The office now runs 2 schedules whether or not anyone has written the second one down.

Recording a single annual date for PCI training loses that June hire's clock, and loses it again with every subsequent hire. The fix costs one extra column. A per-person completion record and a separate program review date solve it, which makes this a records problem before it is a training problem.

That distinction belongs entirely inside PCI DSS, and an office that gets it right has still answered only the questions the card brands ask of it. The next duty comes from beyond PCI DSS entirely.

What Applies to an Agency That Does Not Apply to a Shop?

Beyond PCI DSS, Nevada adds a duty that exists only because the counter belongs to a public body. The duty covers a far wider set of records than any card transaction, and it reaches offices in the same building that never touch a terminal.

NRS 603A.210(2) applies where a data collector is a governmental agency and maintains records containing personal information of a Nevada resident. That agency must, to the extent practicable, comply with the current version of the CIS Controls published by the Center for Internet Security. Corresponding standards adopted by the National Institute of Standards and Technology satisfy it as well.

2 Duties Over 2 Different Sets of Records

The hardware shop across the street carries no equivalent obligation. Its duty stops at the cardholder data it handles, and nothing in Nevada law widens that to the customer records it keeps alongside. Nothing in NRS 603A.210(2) touches a private retailer at all. The billing office has a second duty covering a much wider set of records, and the 2 overlap without matching:

• The PCI duty covers the cardholder data the counter handles.
• The CIS Controls duty covers the personal information the agency maintains, including utility accounts, service addresses, and payment histories that never involve a card.
• The PCI duty is fixed in its terms. The CIS duty is qualified by "to the extent practicable", which is a position an agency has to be able to explain and defend.

For the billing office this means the awareness training has 2 audiences in one room, and frequently the same person in both. The clerk who takes a card also opens the account record. That is why training built for public sector work tends to look different from the retail version of the same course.

Every one of these duties is met or missed by the clerk at the window. No policy document changes that.

The Counter Is Where the Standard Is Met or Missed

The clerk at the window is where each of these obligations either holds or fails. A policy document does not stop a phishing email. A P2PE terminal does not stop a card number being read aloud over the phone. An annual review date does not stop a June hire from going 7 months without training.

Neither the standard nor Nevada law tells an agency which course to buy, and neither creates a legal duty to train outside the states that have legislated it. What they create is an expectation that the people handling cards have been taught the specific material, and a record that proves it.

KC Library carries the security awareness and cardholder data courses that satisfy the content side of Requirement 12.6. A completion record is held against each person. Those records are the half a 4 person office has no practical way to build itself.

So the question worth putting to a finance director is a small one. Could the person at the second window describe what to do with a card number that arrives by email? Whatever the policy file says, that answer is the agency's position.

Frequently Asked Questions

1. Does PCI DSS apply to government agencies?

Yes, by 2 routes. The ordinary route is contractual: any organization accepting payment cards agrees to the standard through its acquiring bank and card brand agreements, and a public body is no different. The second route is statutory in a small number of states. Under NRS 603A.215(1) a data collector doing business in Nevada that accepts a payment card must comply with the current version of the standard, and NRS 603A.030 defines a data collector to include any governmental agency.

2. Does a P2PE terminal remove PCI training requirements?

No. A validated point-to-point encryption device reduces technical scope by keeping readable cardholder data off the agency's network, and it shortens the self-assessment considerably. The Requirement 12.6 awareness obligations continue to apply to the people who handle cards, because the risks they address are phishing, social engineering, and handling practices that no terminal covers.

3. How often must security awareness training be repeated?

Requirement 12.6.3 calls for training upon hire and at least once every 12 months for each person. A separate 12 month cycle in Requirement 12.6.2 applies to reviewing the awareness program itself. The 2 are counted on different subjects, so an office that records only one annual date will lose track of anyone hired between review dates.

4. What does NRS 603A.215 require?

It requires a data collector doing business in Nevada that accepts a payment card in connection with a sale of goods or services to comply with the current version of the PCI Data Security Standard for those transactions. NRS 603A.215(4) limits exemptions to telecommunication providers conveying the communications of other persons and to transmissions over a secure, private communication channel, so governmental agencies are covered.

5. Do Minnesota and Washington require PCI DSS compliance?

Neither works the way Nevada does. Minn. Stat. 325E.64 prohibits retaining card security code data, the PIN verification code number, or the full contents of any magnetic stripe track after authorization, and it never names PCI DSS. RCW 19.255.020(2) removes liability under that section for an entity certified compliant with the standard, or where the account information was encrypted at the time of the breach, which is a safe harbor and not a duty to comply.

References

1. PCI Security Standards Council. "PCI DSS v4.0.1, Requirement 12.6."
2. Nevada Legislature. "NRS 603A.215, security measures for a data collector that accepts a payment card."
3. Nevada Legislature. "NRS 603A.030, data collector defined."
4. Nevada Legislature. "NRS 603A.210, security measures, including the CIS Controls duty for a governmental agency."
5. Office of the Revisor of Statutes. "Minn. Stat. 325E.64, access devices, breach of security."
6. Washington State Legislature. "RCW 19.255.020, liability for a breach of a system containing account information."