PCI DSS SAQ C-VT for virtual terminals: who qualifies

Does keying card payments into a virtual terminal qualify for PCI DSS SAQ C-VT?

SAQ C-VT applies only when every condition holds at once. The merchant manually keys one transaction at a time into a virtual payment terminal hosted by a PCI DSS compliant third-party service provider (TPSP), from a computer that is isolated, has no card reader attached and runs no software that stores account data, and the merchant receives no account data electronically through any other channel. Each condition is a yes or no test, and failing one moves the merchant to a different SAQ. Start by listing every way card data reaches your business: the browser session, email, fax, phone-to-web tools, a point-of-sale application, a shared spreadsheet or a payment link. If any channel other than the keyed entry exists, the answer is no until that channel is removed or validated under its own SAQ.

The isolated computer condition is where most ineligible setups fail. The workstation used for the virtual terminal should not share a network segment with systems that handle cardholder data, should not be used for general browsing or email, and should have no card reader, PIN pad or card-swipe device attached. Ask your provider to confirm in writing that its virtual terminal is hosted and validated for PCI DSS, then check the provider's current status on the official PCI SSC listings. The PCI SSC's FAQ on SAQ C-VT and SAQ C explains the boundary between the two, and the PCI SSC FAQ 1063 is the natural next read before you decide.

Your acquirer, not the PCI SSC, decides which SAQ you must complete. The payment brands and acquirers set validation requirements for each merchant, so confirm the SAQ type with your acquirer before you start. Eligibility also depends on the configuration you actually run, not the one you intended, so repeat the check after any change to the workstation, network or provider. Using a compliant provider does not transfer your obligations: you still need a written agreement with the TPSP, a yearly review of its PCI DSS status under Requirement 12.8, and your own Attestation of Compliance (AOC). A partner can help map your channels, test the isolation and prepare evidence, and an independent QSA or the acquirer's process confirms the outcome. Only you can sign the AOC for your organization.

Which conditions must all hold for SAQ C-VT eligibility?

SAQ C-VT is only available when every condition holds at once. Each card below is a condition that can fail on its own, so the merchant should check each one against its own payment setup and keep evidence for it. A single exception, such as a card reader on the same computer or a second channel that receives account data, moves the merchant to a different SAQ.

Keyed single transactions only

The merchant must enter one card payment at a time by typing the account data into the virtual terminal, with the cardholder present or on a call. Batch uploads, file imports and automated feeds into the terminal fall outside this SAQ. Check staff procedures and the terminal's transaction screens to confirm that keying is the only input method used. Keep written procedures that describe the keying process.

Hosted terminal from a compliant provider

The virtual terminal must be hosted by a third-party service provider that is PCI DSS compliant, and the merchant must not host it. Ask the provider for its current Attestation of Compliance and confirm the service covers the terminal you use. Do not accept a marketing statement or a certificate as proof. Record the provider's compliance status and review it at least once a year under Requirement 12.8.

Isolated computer with no card readers

The computer used to key transactions must have no card readers attached, such as swipe, chip or contactless devices. The merchant should confirm this by walking the workstation setup and checking the device list. A computer that also runs a point-of-sale application or connects a PIN pad does not qualify. Keep a current inventory of the workstation and its attached hardware.

No software that stores account data

The computer must not run any software that stores cardholder data, including spreadsheets, document editors that save card numbers, screen recording tools or local logs that capture account data. Review the installed applications and browser extensions, and check where the browser caches or downloads files. Confirm that no paper or electronic copies of card numbers are kept on the workstation. Document the review and repeat it when software changes.

No account data through other channels

The merchant must receive no account data electronically through any other channel, such as email, fax-to-email, a website form, a messaging app or a phone line connected to a system. Any such channel means the merchant needs a different SAQ. Check email inboxes, shared drives and integrations with other business systems. Write down the approved channels and confirm staff know that card numbers must not arrive by email.

Standalone computers only under v4

Under v4 eligibility, the PCI SSC states that SAQ C-VT applies only to standalone computers. A workstation that connects to a shared network segment with other payment or business systems should be assessed with that in mind and confirmed with the acquirer before the merchant files. Map the network connections of the workstation and record any shared resources such as printers or file servers. Confirm the interpretation with the acquirer rather than assuming it.

SAQ C-VT or SAQ C: which fits keyed payments?

This table compares SAQ C-VT with SAQ C and, for contrast, SAQ D for merchants, across how card data enters the business, where the payment application runs and whether electronic storage is allowed. Read each row against your own payment flow, and treat any move to a different SAQ as a question to confirm with your acquirer.

Factor	SAQ C-VT	SAQ C
Payment channel	Single transactions keyed one at a time into an Internet-based virtual terminal	Internet-connected payment application used to process transactions
Where card data is entered	Typed into a web-based virtual terminal hosted by a validated third-party provider	Entered into the merchant's own payment application on a device
Payment application on the merchant's system	No payment application or card-storing software on the merchant's computer	Yes, a payment application runs on the merchant's own system
Connection to other systems	Isolated computer with no card readers attached and no other electronic card data channels	Application not connected to other systems, which the SAQ C eligibility criteria define
Electronic storage of cardholder data	Not allowed	Not allowed
Provider dependency	Requires a PCI DSS compliant third-party service provider hosting the virtual terminal	Does not depend on a hosted virtual terminal, though merchant responsibilities remain
When to move to SAQ D	If card data arrives through any other electronic channel or is stored electronically	If the environment becomes multi-store, stores data, or exceeds SAQ C eligibility

How administering devices affects SAQ C-VT eligibility

SAQ C-VT allows only one permitted system type, and that limit controls which devices may administer the isolated computer. PCI SSC FAQ 1442 explains that a merchant can administer a device from a same-type device on the same network, through non-console administrative access, and remain eligible. Using a different system type, such as a back-office server, to administer the device breaks eligibility. The FAQ answers this question for SAQ B-IP, C and C-VT, and the position should be applied only to the questionnaire it addresses. Do not assume the same reasoning holds for other SAQs, which have their own eligibility criteria and may treat administrative paths differently.

In practice, the isolated computer is the system you must protect, so start by listing every device and account that can reach it for administration. For each one, record its system type, its network path, and whether the access is console or non-console. A helpdesk laptop of the same type on the same segment is a different case from a file server, a domain controller or a general-purpose workstation used for email and back-office tasks. Keep this inventory with your other eligibility evidence and update it whenever remote support tools, jump hosts or management accounts change.

Confirm the approach before you rely on it. Ask your acquirer whether they accept the administrative pattern you describe, and ask your QSA or the reviewer of your self-assessment to check the documented device list against the network as it actually runs. Because eligibility depends on details of your environment, treat any administrative access that you cannot clearly classify as a question to resolve first, not an assumption to carry into the Attestation of Compliance.

Who does what when a merchant uses a virtual terminal

The merchant remains responsible for the environment where card data is keyed, even though the payment platform is hosted by someone else. Under SAQ C-VT, the merchant's own team controls the isolated computer, the people who use it, the paper records that hold card data, and the written answers that go into the self-assessment. Using a compliant provider does not transfer those duties, so the merchant has to be able to show how each one is met.

Isolated computer: Keep the workstation standalone, with no card reader attached and no software that stores account data, and document its configuration against a secure configuration policy.
Staff training: Train everyone who keys transactions on phishing recognition and on the handling of card data, and keep records of completion.
Written policies: Maintain the security policies, paper record retention rules and removable media controls that the SAQ asks about, and review them on a schedule.
Paper records: Define how long paper receipts and order forms are kept, where they are stored and how they are destroyed.
Self-assessment and AOC: Complete the SAQ, answer each requirement with accurate evidence, and sign the Attestation of Compliance as the merchant.

Confirm that a named owner can produce the configuration records, training logs and policy versions on request.

What PCI DSS v4.0.1 changed for SAQ C-VT

PCI DSS v4.0.1 is the only active version of the standard, and the SAQ C-VT you complete must match it. The PCI Security Standards Council published v4.0.1 on 11 June 2024 as a limited revision of v4.0, with no requirements added or deleted. The SAQs for v4.0.1 followed on 15 October 2024. Those SAQs aligned their content with v4.0.1 and clarified the eligibility criteria in SAQ C-VT, so the questions you answer now are more precise about what a qualifying virtual terminal environment looks like. v4.0 was retired on 31 December 2024, so any SAQ C-VT still based on v4.0 should be replaced with the v4.0.1 form before you sign a new Attestation of Compliance.

The v4 additions named by the PCI SSC for SAQ C-VT are the ones your team must evidence, not just tick. They are secure configuration policies for the isolated computer, data retention rules for paper records that carry card details, protection against malware from removable media, phishing protection, and passwords and phishing training for staff who key transactions. Start by confirming that the computer used for keying has a written configuration standard, that paper receipts and order forms have a defined retention period and secure disposal, that USB and other removable media are blocked or scanned, and that staff have completed training that covers phishing and password practices. Ask your virtual terminal provider which of these controls they operate and which fall to you.

How a merchant moves from eligibility check to a signed SAQ C-VT

The sequence below takes a merchant from confirming that keyed virtual terminal payments fit SAQ C-VT to a signed Attestation of Compliance ready for the acquirer. Each step produces a record that the next step depends on.

Confirm the payment channel and provider status
Confirm that every card transaction is keyed one at a time into a web-based virtual terminal hosted by a PCI DSS compliant third-party service provider, and that no card data arrives through any other channel such as email, fax, phone recordings, paper forwarded electronically or a card reader. Ask the provider for its current Attestation of Compliance and confirm it covers the virtual terminal service you use. The output is a written channel description and a dated copy of the provider's AOC on file. If any other channel exists, stop here, because SAQ C-VT is not the right questionnaire.
Map the isolated computer and its administration path
Identify the standalone computer used to access the virtual terminal, record its make, model, operating system and location, and confirm that no card reader is attached and no software on it stores account data. Document who administers the machine and how, and confirm that any administration uses only a device of the same permitted type on the same network. The output is a system inventory entry and a short administration diagram that an assessor can follow without asking questions.
Document policies and paper record handling
Write or update the security policy, secure configuration standard for the computer, acceptable use rules, and procedures for handling paper records that carry card data, including retention limits and secure disposal. Add the v4 items that SAQ C-VT now expects, such as removable media malware protection and phishing training. Assign an owner to each document and record the date of approval. The output is a signed policy set that matches what the workstation and staff actually do.
Answer each requirement against its Expected Testing
Work through each SAQ C-VT requirement using the official questionnaire, reading the Expected Testing column for what the assessor will check. For each requirement, choose one of the response options the questionnaire allows, such as in place, not applicable with a reason, or not in place with a remediation plan, and do not mark a response until you have tested it yourself. The output is a completed draft of the questionnaire in which every row has a response and a note describing how it was tested.
Gather evidence for each answer
For every response, collect the artifact that proves it: configuration exports, screenshots of settings, training completion records, patch and malware protection reports, access lists, and the provider's AOC. Store each item with a file name that matches the requirement it supports. Confirm that dates on the evidence fall inside the period the attestation covers. The output is an evidence index mapped line by line to the questionnaire, so any answer can be traced to a document.
Review gaps and confirm eligibility again
Have someone other than the person who completed the questionnaire check each answer against the evidence and the channel description. Confirm the eligibility criteria still hold, including the isolated computer condition and the absence of other electronic channels. If any answer is not in place, decide with the acquirer whether a remediation plan is acceptable or whether another SAQ applies. The output is a reviewed questionnaire with recorded reviewer sign-off and no unresolved eligibility question.
Sign the Attestation of Compliance
Complete the SAQ C-VT Attestation of Compliance with an officer or authorized signatory who can accept responsibility for the answers. The AOC states which SAQ was used and the merchant's compliance status, and must match the questionnaire exactly. Keep a signed copy with the evidence index and the provider's AOC. The output is a signed AOC and a retained file set ready for submission.
Submit to the acquirer or requesting entity
Send the signed AOC to the acquirer or the entity that requested it, using the method and format they specify, and ask for written confirmation of receipt. Ask whether they require any additional documentation or a different validation type. Record the submission date and the contact who confirmed it. The output is a confirmed submission record, and the same file set becomes the basis for the next annual cycle and for any change to the virtual terminal or the computer.

Which mistakes move a virtual terminal merchant out of SAQ C-VT?

SAQ C-VT is only available while the keying environment stays isolated, single-purpose and free of other electronic card data channels. The cards below describe the failures that most often push a merchant out of eligibility, and the checks that keep the environment inside the SAQ.

Card reader on the keying computer

SAQ C-VT requires the computer used to key transactions to have no card readers attached. A reader connected to that machine, even one used occasionally for swiping, means card data is entering through a second channel and the merchant no longer fits C-VT. Check the machine's physical connections and USB ports during the annual eligibility review, and record that no reader is attached. If a reader is needed for card-present sales, the merchant likely needs a different SAQ.

POS or payment software on the keying machine

Installing point-of-sale, payment application or any software that stores account data on the keying computer breaks the isolation the SAQ assumes. Even a utility that caches transaction records can count as storage. Confirm with the provider and your own inventory that the machine runs only a browser session to the hosted virtual terminal and the operating system tools it needs. Document the approved software list and review it when anything changes.

Card data received by email

Accepting card numbers by email, whether a customer replies to a message or a staff member forwards an order, means account data arrives through an electronic channel other than keying a single transaction. SAQ C-VT requires that the merchant receive no account data electronically through any other channel. Set a written rule that card details are never sent by email or chat, tell customers how to pay instead, and check the shared mailboxes used for orders.

Fax-to-system and file feeds

Faxes that land in a document system, or batch files uploaded from order software, are electronic card data channels that SAQ C-VT does not allow. Staff sometimes forget these paths exist because they feel like back-office tasks. Map every inbound route for orders and payments, including fax servers, SFTP drops and scanned forms, and confirm that none carries account data into a system. Paper forms can be destroyed under the retention rules in your written policy.

Provider PCI DSS status not checked

SAQ C-VT depends on a hosted virtual terminal run by a PCI DSS compliant third-party service provider. Using a provider without checking its validation status, or without keeping evidence of it, leaves the merchant unable to show the premise of its eligibility. Obtain the provider's current Attestation of Compliance, confirm it covers the service you use, and keep a written agreement. Using a provider does not remove your own responsibilities, including yearly monitoring of the provider under Requirement 12.8.

General browsing on the keying machine

Using the virtual terminal computer for email, web browsing, social media or access to other business systems exposes it to malware and phishing that the SAQ is designed to keep out. It also allows other systems to connect to the same machine. Limit the device to the hosted terminal and the tools needed to reach it, separate staff accounts for administration, and confirm that no other system type is administered from it. Review this use at each annual assessment.

Questions merchants ask about SAQ C-VT

Can a merchant key card payments on a shared office computer and still use SAQ C-VT?

Usually not. SAQ C-VT is built around an isolated computer that is used only for keying single transactions into the provider's virtual terminal, with no card readers attached and no software that stores account data. A shared computer used for email, browsing, or other business tasks adds systems and risks that the questionnaire does not cover, so the merchant would normally need a dedicated machine. Standalone status matters too: the PCI SSC states that v4 eligibility for C-VT applies only to standalone computers. Confirm the exact eligibility criteria in the official SAQ C-VT before deciding, and check the setup with your acquirer.

Does SAQ C-VT require an outside assessor or QSA?

No. A merchant completes SAQ C-VT itself and signs its own Attestation of Compliance, so no Qualified Security Assessor is required for this questionnaire. An outside party can still help with interpreting requirements, testing configurations, or reviewing the completed answers, and some merchants find that useful the first time. The decision is about capacity and confidence, not a formal requirement. Ask your acquirer which validation process it expects, since acquirers set reporting requirements for their merchants.

What must a merchant do about its virtual terminal provider beyond checking its PCI DSS status?

Confirming that the provider is PCI DSS compliant is only the start. The merchant must have written agreements that describe the provider's responsibilities, monitor the provider's compliance at least once a year, and track which requirements the provider covers and which remain with the merchant. Requirement 12.8 covers this third-party oversight. Using a compliant provider does not transfer the merchant's own duties, such as protecting the keying computer, managing its accounts and passwords, and handling any paper records. Ask the provider for its current attestation and a responsibility matrix, and record when you reviewed them.

Can a phone-order team use the same virtual terminal setup under SAQ C-VT?

Only if the phone channel fits the same pattern. SAQ C-VT covers keying one transaction at a time into the virtual terminal and receiving no account data electronically through any other channel. A team that takes card numbers by phone and keys them in still fits this model, but any other way cardholder data arrives, such as email, fax-to-email, call recording, voicemail, or a telephone system that transmits data electronically, changes the picture. Paper records of card numbers also bring data retention and storage duties under the v4 additions. Map every route card data takes before assuming the phone team qualifies.

When must a merchant move from SAQ C-VT to SAQ C or SAQ D instead?

A merchant moves when its setup no longer matches SAQ C-VT. SAQ C fits Internet-connected payment applications on a device or single-store network that is isolated from other systems, and it does not allow electronic storage of cardholder data. SAQ D applies to environments that exceed other SAQs, including any electronic storage of card data, even if encrypted, and most multi-system or service-provider setups. Common triggers include installing payment software on the keying computer, connecting the computer to other business systems, storing card data electronically, or adding a card reader. Review the SAQ selection criteria whenever the workflow changes.

How much effort does SAQ C-VT need from the team?

The effort depends on what drives the scope, not on a fixed figure. The main drivers are the number of keying computers, since each one must be isolated and configured, the number of staff who key or handle transactions, and how paper records of card data are created, stored and destroyed. Provider documentation also matters: the more the provider supplies current attestations and responsibility details, the less the merchant must gather itself. Recurring work includes annual self-assessment, staff training on phishing and passwords, and yearly provider monitoring. Ask any consultant for a quote built from these drivers, with the one-time setup and recurring tasks listed separately.

How DeployOpen prepares an isolated keying environment and its evidence

DeployOpen works on the isolated computer, the self-hosted supporting systems and the evidence around SAQ C-VT for merchants who key card payments into a provider's virtual terminal. We prepare the environment and documentation so your team can answer each SAQ C-VT question with evidence. The organization owns its eligibility decision and attestation, and only your acquirer and the assessment process confirm them.

How we scope

Confirm that each payment is keyed one at a time into a virtual terminal hosted by a PCI DSS compliant provider.
Inventory the isolated computer, confirm no card reader is attached and no software stores account data.
Record every other electronic channel so the written scope shows none receives account data.

How we build

Harden the standalone keying computer against the SAQ C-VT configuration and secure configuration policy expectations.
Set up removable media malware protection, phishing protection and browser controls on the keying computer.
Deploy self-hosted, open-source tooling in your own infrastructure for logging, patching and access control where needed.

How we hand over

Deliver written scope, system inventory and network diagrams that match the SAQ C-VT eligibility criteria.
Provide configuration records, procedure documents and paper record retention rules for your assessor or acquirer.
Walk your staff through the evidence so they can answer each SAQ C-VT question and sign the Attestation of Compliance themselves.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and reviews of the keying environment are available as a retainer.
Ask any provider or assessor to confirm the scope and the eligibility outcome before you rely on the SAQ.

PCI DSS SAQ C-VT for virtual terminals