HECVAT Category

Payment Card Industry Data Security Standard (PCI DSS)

Payment Card Industry Data Security Standard (PCI DSS) covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.

Assessment Questions

PCID-01

Do you have a current, executed within the past year, Attestation of Compliance (AoC) or Report on Compliance (RoC)?

Current PCI DSS attestation is the requirement here: whether you hold an Attestation of Compliance (AoC) or Report on Compliance (RoC) executed within the past year.

PCID-02

Is the application listed as an approved Payment Application Data Security Standard (PA-DSS) application?

PA-DSS validation is the point of this question: it asks whether your application is officially listed as an approved Payment Application Data Security Standard solution.

PCID-03

Does the system or solutions use a third party to collect, store, process, or transmit cardholder (payment/credit/debt card) data?

Third-party involvement in payment flows is the concern: this item asks whether any outside provider collects, stores, processes, or transmits cardholder data within your solution. Payment card data includes credit card numbers, expiration dates, CVV codes, and other sensitive cardholder information.

PCID-04

Do your systems or solutions store, process, or transmit cardholder (payment/credit/debt card) data?

Payment card data handling is what's being established here, covering whether your systems store, process, or transmit credit, debit, or other cardholder data in any form. Specifically, it's asking about three key activities:

PCID-05

Are you compliant with the Payment Card Industry Data Security Standard (PCI DSS)?

Payment security is the matter at hand: reviewers want to know whether you comply with the Payment Card Industry Data Security Standard (PCI DSS) for handling cardholder data.

PCID-06

Are you classified as a service provider?

Your PCI DSS standing is what's being established, namely whether you qualify as a 'service provider' under the Payment Card Industry Data Security Standard.

PCID-07

Are you on the list of Visa approved service providers?

Visa's Global Registry of Service Providers is the reference point here, the public list of providers that have demonstrated PCI DSS compliance, and whether your organization appears on it.

PCID-08

Are you classified as a merchant? If so, what level (1, 2, 3, 4)?

Your standing under PCI DSS is at issue: whether you are classified as a merchant and, if so, which merchant level (1, 2, 3, or 4) applies to you.

PCID-09

Describe the architecture employed by the system to verify and authorize credit card transactions.

Here you're asked to lay out the technical architecture your system uses to verify and authorize credit card transactions securely.

PCID-10

What payment processors/gateways does the system support?

List every payment processor or gateway your system integrates with to handle payment card transactions. Payment processors are companies that handle credit card transaction processing between merchants, banks, and customers (like Stripe, PayPal, Square). Payment gateways are the technology that captures and transfers payment data from the customer to the acquirer (like Authorize.net, Braintree).

PCID-11

Can the application be installed in a PCI DSS–compliant manner?

Deployment under PCI DSS is what's at stake, asking whether your application can be installed and configured in a manner that meets the standard's requirements. PCI DSS is a set of security standards designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment.

PCID-12

Include documentation describing the system's abilities to comply with the PCI DSS and any features or capabilities of the system that must be added or changed in order to operate in compliance with the standards.

Documentation is what's requested here, describing how your system complies with the PCI DSS and any features or changes needed to operate within those card-data security standards. The question also asks you to identify any features or capabilities that need to be added or modified to ensure PCI DSS compliance.

OPEM-01

Do you support role-based access control (RBAC) for system administrators?

Role-based control over privileged users is the focus, namely whether your system supports RBAC specifically for system administrators. RBAC is a method of regulating access to computer or network resources based on the roles of individual users within your organization.

OPEM-02

Can your employees access customer systems remotely?

At issue is whether your own employees have the ability to remotely access customer systems or environments. In the context of PCI DSS (Payment Card Industry Data Security Standard), this is important because remote access creates additional security risks, especially when dealing with systems that process, store, or transmit payment card data.

OPEM-03

Can you provide overall system and/or application architecture diagrams including a full description of the data communications architecture for all components of the system?

Architecture transparency is what's being requested here, namely diagrams and a full description of the data communications architecture connecting all components of your system.

OPEM-04

Do you require remote management of the system?

Remote administration is the subject: whether running your system depends on managing, configuring, or maintaining it from somewhere other than where the hardware physically sits.

OPEM-05

If you answered "yes" to OPEM-04, are your remote actions and changes logged or otherwise visible to the campus?

Building on your confirmed use of remote actions, reviewers want to know whether those remote changes are logged or otherwise made visible to the campus.

OPEM-06

If you maintain remote access to the system, will you handle data in a FERPA-compliant manner?

FERPA-compliant handling of remote data is the concern, specifically whether you protect education records in line with the Family Educational Rights and Privacy Act when accessing systems remotely. FERPA is a federal law that protects the privacy of student education records. It applies to all schools that receive funds from the U.S. Department of Education.

OPEM-07

Do you support campus status monitoring through SNMPv3 or other means?

Operational monitoring is the subject: assessors want to know whether your system supports campus status monitoring through SNMPv3 or comparable means.

OPEM-08

Describe or provide a reference to any other safeguards used to monitor for malicious activity.

Beyond baseline PCI DSS controls, this asks what additional safeguards your organization relies on to monitor for malicious activity.

OPEM-09

Describe how long your organization has conducted business in this area.

Track record is what reviewers want to gauge: how long your organization has operated in handling payment card data and the related security compliance. The PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements for organizations that handle credit card information.

OPEM-10

Do you have existing higher education customers?

Track record in higher education is the concern, and whether your company already serves customers in that sector. While it appears in the PCI DSS category, it's primarily about understanding your experience serving educational institutions rather than a direct PCI compliance question.

ResponseHub is the product I wish I had when I was a CTO

Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.

As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!

I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.

Signature
Neil Cameron
Founder, ResponseHub
Neil Cameron