PCI DSS is a set of requirements for anyone who stores, processes or transmits cardholder data. Government agencies are not exempt. The practical question is not whether PCI applies but how much of your environment it applies to — and that is a design decision.
Scope is the whole game
Every system that touches cardholder data falls in scope, along with everything connected to it. A single workstation where staff key in a card number can pull a network segment into scope with it.
The goal of a well-designed payment architecture is to keep cardholder data out of agency systems entirely, so scope stays as small as it can be.
What a payment provider can carry
- Capture and transmission of card data in a compliant environment
- Tokenization, so stored payment methods never exist as card numbers in your systems
- Compliant hosting, monitoring and vulnerability management for the payment application
- Attestation for the components the provider operates
What stays with the agency
- Physical security of counter terminals and inspection for tampering
- Staff practices — never writing card numbers on paper forms, never accepting them by email
- Access management for staff accounts in the payment dashboard
- Your own attestation for the parts of the environment you operate
- Policy, training and incident response
Questions worth asking your provider
- Do agency systems ever receive full card numbers?
- How are stored payment methods protected?
- What is the hosting environment, and how is it monitored?
- How are staff privileges controlled and audited?
- What documentation is available to support our own compliance work?
This explainer is general guidance, not a compliance assessment. Your qualified security assessor and legal counsel are the authorities for your jurisdiction.