PCI DSS Instructions

PCI DSS Self-Assessment Questionnaire

Any group who accepts credit cards on behalf of the university is expected to abide by the industry security requirements known as PCI-DSS. Once a year, all Texas A&M University System members are required to complete an official PCI Self-Assessment Questionnaire (SAQ).

This year, all merchants should complete their SAQ online, using the CampusGuard portal. If you did not receive an email with your login credentials and instructions, email pci-dss@tamu.edu and we will have them re-sent.

Each year your SAQ is reviewed for inaccuracies before submission to our card processor. At the recommendation of Texas A&M System Internal Audit, some SAQs will be selected for more thorough review. This will include a review of required documentation as well as an on-site visit. Merchants with missing, late, incomplete, or erroneous SAQs have a greater chance of being selected for more thorough review. To that end, we strive to provide guidance on how to complete your SAQ correctly and completely.

Merchants have already been assigned the SAQ type (A, B, etc.) identified as appropriate for the way they accept cards, so you won’t have to guess which SAQ type applies to you. If the way you do business has changed or you think you’ve been assigned the wrong SAQ, contact us at the email address above.

If your group has more than one merchant account (for instance e-commerce and swipe) then you will see a drop-down for both accounts. Keep track of which SAQ type you are completing, so as to not put down e-commerce answers for your swipe terminal or vice versa.

When you reach the end of the questionnaire, hit the final Save button at the bottom of the page and you’re done. There’s no cover sheet to sign as in years past.

General SAQ Advice



General SAQ Advice

The sections that generate the most questions aren’t the security questions themselves, but the questions about your organization and how you do business, which are found in Parts 1-4. These questions are largely the same regardless of the SAQ.

“Don’t know” is an available answer in the online SAQ, but it’s not a valid response for final submission. It’s intended as a placeholder response, a reminder that you need to research the question and return to give a final answer. If your pie chart summary shows “don’t know” answers then you’re not done.

Part 1a, use the institution name for Company Name (“Texas A&M University”) and the merchant name as the DBA name. The merchant name is the name that appears on a customer’s credit card statement and the name listed for the account when you first log into the portal. The Contact Name should be you, the name of the person completing the questionnaire.

Part 1b just enter CampusGuard for the company name and leave the rest blank.

Part 2a note that you can check multiple business types. Always check “other” and specify “Higher Education”, as well as any other business type. 2b has another section with two questions divided into columns. The question on the left is the ONLY question in any SAQ that extends the context beyond the SAQ you’re completing. The question on the right pertains only in the context of the current SAQ.

Part 2b, be descriptive enough that a stranger can understand how you do business.

Part 2c, if you are completing an e-commerce SAQ then just enter the business office location. Otherwise, list the locations of your swipe terminals and your business office.

Part 2d, list any applicable software involved in accepting payment. For ecommerce it’s probably uCommerce by TouchNet or for your Verifone swipe terminal it’s Softpay 4.0. You can look up payment applications and their expiration dates on the PCI Council website.

Part 2e, again, be descriptive enough that a stranger can understand how you accept cards, who has access to those cards, and how those cards are transmitted to our card processor. You can click and drag the bottom right corner to make the box bigger.

Part 2f, 99% of our merchants don’t have a QIR. If you are on an SAQ A or B the answer is definitely NO, and if you have a Verifone Vx520 or 680 the answer is still NO. If you don’t fall into those categories and you’re not sure, email pci-dss@tamu.edu to discuss.

The question five rows down applies to every one of us though. Chase Paymentech (our processor) is a service provider, and your ecommerce payment gateway is a service provider (TouchNet, Payflow, or whomever else you use). American Express is also a service provider. List all that apply to you for this SAQ (don’t just copy the list above!)

Part 2g, if each statement doesn’t apply to your environment then you’re using the wrong SAQ. Stop can email pci-dss@tamu.edu.

[we’re purposefully skipping the PCI requirements here]

Part 3 as long as you don’t have any No or Don’t Know answers under any page named Requirement [number] then you can check the “compliant” box. Pat yourself on the back. It’s all downhill from here.

Part 3a, this is the one that confuses people the most. Not every box has to be checked. The very bottom requirement applies to e-commerce sites hosted by us rather than by a vendor. Even e-commerce sites that are hosted on campus redirect customers to a secure payment page hosted by a vendor (such as TouchNet), we don’t require scanning. In other words, it doesn’t apply.

The second to last question has to do with the card data found on the magnetic stripe of a card. If you’re strictly e-commerce, obviously this doesn’t apply to you. Chase’s position is that this also doesn’t apply to countertop devices since we have no way of testing, so it doesn’t apply to our Verifone devices either. It’s intended for big point of sale systems like you find in Target or Walmart.

All the other statements do apply.

Part 3b

Remember, we aren’t requiring signatures. You can enter your director (or equivalent) name if you’d like.

Part 3c -3d

Leave ‘em blank.

Part 4

Remember when you marked that “compliant” box earlier because you didn’t have any No or Don’t Know answers? This is sort of like that but more granular. It’s a summary of your previous answers by requirement number. Answer, hit Save/Submit, and rejoice.


SAQ B-IP is new to us this year because of the spread of Voice over IP (VOIP) on campus. Technically since there’s an IP address involved, terminals qualify for the same SAQ as if you were plugging your terminal into the campus network. If you’ve looked at the requirements you know it’s far more demanding—firewalls, quarterly scans, and so on. This is why we instruct you to only use your terminal on a phone line.

To keep our VOIP phone network out of scope for PCI, the university has elected to add an additional layer security to terminals on VOIP. This system, provided by our card processor Chase Paymentech, encrypts the card the moment it is swiped and it can only be decrypted by Chase themselves. In PCI this is known as a “compensating control” for a security requirement. Chase has approved Safetech as a compensating control for some of the more difficult to implement requirements found in SAQ B-IP.

We try hard to draw the line at only explaining a security requirement’s intent rather than tell you want to answer, but we are making an exception for the security requirements covered by Safetech.

If you haven’t started your SAQ yet, your very first step should be to call the Chase Paymentech help desk and ask them to examine the last transaction for each Vx520 you use. In particular, you want them to verify that the transaction was encrypted with Safetech as expected. You can’t claim Safetech as a compensating control if it isn’t actually working. The number is 888-886-8869. In the menu tree press 3, then 4 to talk to someone.

If you call first thing in the morning the wait isn’t as long. You’ll need to provide them your merchant ID and address, found at the very top of a receipt from your terminal. (Note the address on record is FMO’s address, not your own!) The merchant ID is the number that starts with 6 and is seven digits long. The receipt also lists your terminal ID number. Near the top-left, it reads “Term ID: 00X.”

After you’ve verified Safetech is operational on each terminal, these are the questions you can mark as “Compensating Control Used.” An “X” as part of a number means that number and all its sub-requirements. Safetech is a compensating control for requirements 1.x, 6.x, 9.1.2, and 11.x.

Additionally, because your devices are on a VOIP system instead of a traditional network and because your terminal cannot be accessed remotely, the following requirements are Not Applicable (N/A): 2.x, 4.1.x, and 8.x.

That leaves 3.x, 4.2, 7.1.x, 9.5 through 9.9.3, and 12.x for you to consider and answer.

After completing the Requirements pages, you must complete both Appendix B and C.

Appendix B seeks a description for why a compensating control was necessary and how it is stronger than the original control. You can use the following answers or a variation thereof.

1.    The device in question transmits over a private VOIP network, precluding using some of the standard controls.

2.    The objective of the original control is to prevent remote intrusion of a card reading device or prevent interception of cardholder data in transit; the same objective is being met by encryption of cardholder data upon swipe.

3.    If Safetech is not actually enabled on the device then it can transmit cardholder data “in the clear” through the VOIP network, which if compromised would lead to theft of data.

4.    The compensating control is an encryption system provided by Chase Paymentech called Safetech. This system uses a unique key injected in the device to encrypt cardholder data upon swipe. The decryption key is not in the device or held by the university, but only Chase Paymentech. This renders intercepted data unreadable and useless.

5.    The compensating control has been validated by having Chase Paymentech examine a payment record and verify it was encrypted using Safetech.

6.    Perform validation procedure described in number 5 above any time the terminal is updated.

Appendix C is the explanation of non-applicability.

2.1, 2.3, 8.x: Vx520 terminals in dial mode have no remote access function.

2.1.x, 4.1.x: The network environment is a private VOIP network with no wireless connectivity. Cardholder data is transmitted over the VOIP network or common telecarriers, not public networks.

Depending on your answers for the other security requirements, you may have other “N/A” to explain (such as requirement 9).

Frequently Asked Questions

How do we get a signature in Part 3b or the remaining sections?
The portal doesn’t support electronic signatures yet, so we are not requiring them. Just know that the SAQ is no less official just because there’s no signature.
What about the cover page?
We are no longer requiring cover pages. We already know your merchant account number, name, and SAQ version. We’re working out a new process for you to submit employees for PCI training in TrainTraq, but it is being separated from the SAQ process so it will be easier to use throughout the year as employees come and go. There will be a listserv announcement when the new process is ready.
How does my boss or IT sign off?
If your boss or IT professional need to review your SAQ, request they be given access to the portal. They can review it online and give their stamp of approval. Sadly, there is no portal workflow which passes an SAQ from one user to another with multiple approvals.
How do I know if my service provider is compliant?
If it’s Chase, American Express, TouchNet, or Payflow, then FMO already has that documentation. No need to reinvent the wheel. If you’re working with a third party shopping cart, then you should be asking for their PCI Report on Compliance. This is an official document validating the service provider’s current PCI compliance. A Trustwave certificate from 2015 doesn’t count.


You can look up registered Service Providers on Visa’s website, but not all service providers register themselves here. http://www.visa.com/splisting/searchGrsp.do.

How do I know if my Payment Application is compliant? And what is or isn’t a payment application?
Per the PCI website, a payment application is “a software application that stores, processes, or transmits cardholder data as part of authorization or settlement, where the payment application is sold, distributed, or licensed to third parties.” You can look up the list of PCI validated payment applications right on the PCI council’s website.

Last Revised June 13, 2017