PCI Compliance for Dentists: What to Prove and Submit

Proving PCI compliance for a dentist means having the right card-data controls running, writing them down, completing the Self-Assessment Questionnaire that matches how the office takes cards, and submitting a signed Attestation of Compliance plus any required scan or pentest reports to whoever asked: your payment processor, merchant bank, or practice-management payments vendor. That packet is what keeps the monthly non-compliance fee off the statement and keeps the front desk able to collect. This guide is for practice owners and office managers who got the questionnaire and want a plain list of what to do and what to send.

Why the processor is asking, and why the fee shows up

PCI DSS is the security rule set for anyone who stores, processes, or transmits payment card data, maintained by the PCI Security Standards Council. The current version is PCI DSS v4.0.1. You agreed to it when the practice signed up to accept cards. It is a contractual requirement from the card brands, enforced through your bank or processor, not a federal law. HIPAA is the federal rule for patient records. PCI is the card-brand rule for card numbers.

The trigger is almost always the annual attestation from your merchant processor, or a Dentrix, Open Dental, Eaglesoft, or other payments portal that will not mark you current until you finish the questionnaire. Leave it sitting and a non-compliance fee often starts. Dental Intelligence's Xplor Pay documentation, as one example, describes a $29.95 monthly fee if the form is not done within about 30 days of setup. That figure is specific to that processor. Read your own merchant agreement for the number that applies to you.

PCI does not replace HIPAA. For the health-record side in dental terms, start with HIPAA compliance for dental practices.

How a dental office actually takes cards

Map every path card data takes before you fill in a form. Typical dental flows:

• Front-desk terminal for copays, balances, and same-day treatment.
• P2PE-validated terminal, which encrypts the card at the swipe so data never sits on the practice network. This is the shortest in-person path when it qualifies.
• Practice-management payment module in Dentrix, Eaglesoft, Open Dental, or a connected payments product.
• Online deposits, text-to-pay, or emailed links, either a hosted page or fields on a page you control.
• CareCredit or similar financing, counted in the map so you know whether it touches your systems.
• Cards on file for payment plans. Use the processor's tokenized vault. Do not keep numbers in the PMS, a spreadsheet, or email.

The less card data your systems see, the shorter the SAQ. A terminal on the same flat network as imaging and the practice-management server does the opposite. That layout is covered in on-prem server security for medical and dental practices. The Council's scoping and segmentation guidance is the source behind it.

Which SAQ a dentist usually needs

Most dental offices validate with a Self-Assessment Questionnaire. There is not one PCI form. Each SAQ is the subset of the twelve requirements that apply to your card flow. A shorter SAQ means smaller scope, not a weaker standard. Your bank or processor confirms the type. The Council lists them in its Getting Started guide. The general walkthrough lives in how to become PCI compliant.

If the practice takes cards this way	Your SAQ is usually	Proof burden
Standalone terminal only, no electronic card storage	B or B-IP	Short SAQ, usually no pentest
P2PE-validated terminal, no electronic storage	P2PE	Short SAQ, often no scan
Patient pays on a hosted page the practice redirects to	A	Short SAQ, usually no pentest
Payment fields embedded on the practice website	A-EP	Longer SAQ, quarterly ASV scan, external pentest
Virtual terminal on a practice PC, one card at a time, nothing stored	C-VT	Moderate
Payment application on the network, no electronic storage	C	Moderate
Stored cards, custom checkout, or unclear scope	D	Full SAQ, scans, pentest

Two forks matter. SAQ A versus SAQ A-EP: sending the patient to a hosted checkout is usually A; putting card fields on a page you host is usually A-EP, with scans and an external pentest. P2PE-validated terminal versus a generic IP terminal: P2PE, when the device and process qualify, is often the shortest in-person questionnaire. Some dental payment portals walk you onto that P2PE path if you pick the right product code. Dental Intelligence's Xplor Pay guide is one published example. It is not universal. Follow the SAQ your own processor assigns.

The controls that have to be running

In a dental office the twelve requirements mean a firewall with waiting-room Wi-Fi kept off the payment, PMS, and imaging network, no vendor default passwords, no card numbers stored in Dentrix, Eaglesoft, Open Dental, or email, TLS on any payment page, endpoint protection and patching on front-desk PCs, unique logins with MFA on remote access, physical control of the server closet, logging, and written policies staff can follow.

Quarterly ASV scans apply when your SAQ requires them. Some P2PE and fully hosted setups do not. If a portal suddenly asks for a scan, you may have landed on the wrong SAQ path. Confirm the product and processing method before you pay for a scan you do not owe. An annual penetration test is common on SAQ A-EP and D, and unusual for a terminal-only or P2PE office. See which merchants PCI requires a pentest for.

Much of this is the same list your cyber insurance application already wants, and the same work under security and compliance readiness. If those controls are running, the PCI packet is mostly evidence.

The proof package that proves PCI compliance

Processors want a dated folder, kept current so the yearly upload is a copy-and-submit.

Always include:

• The completed Self-Assessment Questionnaire for the SAQ type your bank confirmed.
• A signed Attestation of Compliance (AOC).
• Written security policies covering access, MFA, incident response, acceptable use, and physical security.
• Evidence the controls are operating: patch records, MFA on the accounts that matter, firewall configuration, a recent access review.

Include when your SAQ requires them:

• Passing quarterly ASV vulnerability scan reports.
• A penetration test report dated within twelve months, with critical and high findings closed or on a dated fix list.
• Segmentation evidence if you claim reduced scope: a network diagram and the firewall rules that keep the card environment apart from imaging and the PMS.

Often requested alongside the packet:

• A PCI letter or AOC from the terminal or payments vendor.
• The P2PE device listing, if you use P2PE-validated terminals.

How to submit it to your processor or practice-management vendor

1. Confirm who is asking. The merchant statement names the bank, processor, or ISO. A payments add-on inside Dentrix, Open Dental, or Dental Intelligence may have its own portal.
2. Ask which SAQ they expect. Product-code and processing-method questions decide whether you land on a short P2PE path or a longer one that demands a scan. Answer for the setup you actually have.
3. Complete the SAQ, then sign the AOC. A mismatched short form is worse than a longer one you can support.
4. Upload SAQ plus AOC in the merchant portal. Attach scan and pentest reports if they apply. Download the confirmation the portal generates.
5. If the PMS vendor sent a separate form, copy answers from the completed SAQ.
6. Calendar the annual renewal. The first year is the slow one.

What skipping it costs

The merchant agreement is the source of truth. Many dental processors charge a monthly non-compliance fee until the attestation is in, and some raise rates in the meantime. In a worst case they suspend card acceptance. After a card-data incident, the card brands define penalties and your bank enforces them through that contract. Filing the packet is cheaper than the fee, a rate hike, lost card acceptance, or liability if card data is stolen while you were out of compliance.

Frequently asked questions

Do dental practices need PCI compliance if they take cards?

Yes. PCI DSS applies to any dental office that stores, processes, or transmits payment card data, including front-desk collections, online deposits, and CareCredit. Volume does not exempt you. A small office with a standalone or P2PE terminal usually has a shorter questionnaire, but you still complete it and send it to your processor each year.

Is PCI the same as HIPAA for a dental office?

No. HIPAA protects patient health information. PCI DSS protects payment card data. A dental office often handles both on the same network, so firewalls, access control, and logging do double duty, but the paperwork is separate. A HIPAA risk analysis does not replace the SAQ and attestation your payment processor asks for.

What's the difference between PCI SAQs for a dentist?

Every SAQ is a subset of the same twelve PCI requirements. The difference is how you take cards. A P2PE or standalone terminal, or a fully hosted payment page, is a short form. Payment fields on your own website or stored cards pull in more questions, quarterly scans, and sometimes a pentest. Your processor confirms which SAQ applies.

Do dentists need a PCI penetration test?

Only if your SAQ requires it. Offices that take cards on a standalone or P2PE-validated terminal, or send patients to a fully hosted payment page, usually do not. If payment fields sit on your own website, or you store card data, an annual external penetration test is commonly required. Confirm the SAQ type before you book one.

What documents do we submit to our payment processor?

Most processors want a completed Self-Assessment Questionnaire and a signed Attestation of Compliance. If your SAQ requires them, attach passing quarterly scan reports and a current penetration test report. Keep written security policies and any PCI letters from your terminal or practice-management vendor. Upload the packet through the merchant portal named in your statement.

What happens if a dental office misses the PCI deadline?

Your processor can add a monthly non-compliance fee, raise processing rates, or suspend card acceptance until the attestation is in. Some dental payment platforms start that fee within weeks of setup. After a card-data incident, missing compliance also leaves more liability on the practice. Filing on time is cheaper than any of those outcomes.

Getting PCI compliance for dentists without the scramble

PCI compliance for dentists comes down to mapping how you take cards, picking the SAQ that matches, keeping policies and evidence current, and submitting the AOC before the processor's fee clock starts. Medical offices run the same packet with different software; see PCI compliance for a doctor's office. If you want this mapped for your practice, Desert Lakes Solutions offers a no-pressure discovery call to walk the card flow, confirm the SAQ, and assemble the proof package. We do dental practice IT alongside the compliance work. Book a discovery call and we will give you the straight version.