Which PCI DSS SAQ do I need for my payment setup?
Your customer, acquirer or contract is asking for a PCI DSS self-assessment, and the first decision is which Self-Assessment Questionnaire fits how you take cards. You choose an SAQ by matching your payment channel to that SAQ's eligibility criteria, and every criterion must be met before you can use it. A single unmet condition, such as a second payment channel on the same device or a system that stores card data, moves you to a different SAQ or to a Report on Compliance. The answer depends on three things: how cardholder data is captured (typed in, read by a terminal, or handled by a payment page you host), where it is stored and whether any copy of it persists electronically, and how the payment systems connect to the rest of your network. Encrypted storage counts as storage, so a merchant that keeps encrypted card data is usually pointed to SAQ D rather than a lighter questionnaire.
Start by describing your environment on paper before you open any questionnaire. List every place a card number enters your business, including e-commerce pages, standalone terminals, point-of-sale software, virtual terminals and any call center or back-office process, and note whether any of them keeps card data after authorization. Then read the SAQ Instructions and Guidelines for the PCI DSS version you are validating against, which describes each SAQ's intent and eligibility criteria. If you run more than one payment channel, decide early whether you will complete one SAQ per channel or one SAQ for everything, because separate SAQs require each channel to meet its own criteria and to be adequately segmented from the others.
Confirm the choice before you start. Your acquiring bank or payment brand has the final say on which SAQ applies to your business and on the validation deadlines it expects, so ask for their written confirmation of the SAQ type and the environments it covers. Ask your acquirer whether they accept a self-assessment at all, since some require an independent assessor for certain merchant levels. If your payment setup changes after you submit, such as a new terminal model, a switch to a hosted payment page or a new sales channel, treat the earlier SAQ as out of date and recheck eligibility with your acquirer. A quick conversation at the start costs far less than rewriting an attestation that was filed under the wrong questionnaire.
What each SAQ covers and who it fits
SAQ A and SAQ A-EP cover merchants that take card payments online but do not store, process or transmit cardholder data on their own systems. SAQ A suits a merchant that fully outsources the payment page to a provider, typically through a redirect or an iframe the provider hosts. SAQ A-EP applies when the merchant's website can affect the security of the payment page, for example when it serves the page itself or relies on scripts that run within it, even though the merchant never receives card numbers.
- SAQ A: the payment page and all card data handling sit with a third-party provider, and the merchant's website does not receive or store cardholder data.
- SAQ A-EP: the merchant hosts or controls the page that collects card data, usually with a direct post or merchant-hosted script, so its web server and scripts remain in scope.
- Common confusion: a redirect or fully provider-hosted iframe usually points to SAQ A, while a merchant-controlled page element usually points to SAQ A-EP.
- Eligibility: every criterion of the chosen SAQ must hold at all times, so a single change to the checkout design can move a merchant to a different SAQ.
- Ask your acquirer: which SAQ applies to your checkout design, based on the SAQ Instructions and Guidelines.
Before you choose, describe your checkout flow step by step and confirm with your acquirer which SAQ applies.
SAQ B and SAQ B-IP cover in-store merchants that accept cards on standalone terminals and never store cardholder data electronically. SAQ B covers imprint machines and standalone dial-out terminals that connect to the payment processor through a phone line rather than the merchant's network. SAQ B-IP covers standalone PTS-approved point-of-interaction devices that connect to the internet over IP, and it carries additional requirements for the device and its network.
- SAQ B: imprint-only or dial-out terminals with no connection to other merchant systems.
- SAQ B-IP: IP-connected PTS terminals that process cards directly, with no other system type in the payment path.
- Excluded devices: secure card readers and wireless terminals fall outside the eligibility criteria of these SAQs, so merchants using them need a different questionnaire.
- Administration: administering a terminal from a same-type device on the same network can remain eligible, but using a back-office server to administer it does not.
- Check: whether any other system on the network touches the terminal, because that can break eligibility.
List each terminal by make, model and connection type before you confirm the SAQ with your acquirer.
SAQ C and SAQ C-VT cover merchants that enter or process card data through a payment application, either on an internet-connected point-of-sale system or in a web-based virtual terminal from a provider. SAQ C fits a single device or a single-store local network running a payment application with an internet connection. SAQ C-VT fits merchants that key card numbers into a provider's browser-based virtual terminal on an isolated computer, with no card readers and no software that stores card data.
- SAQ C: one payment application on one device or a single-store LAN, isolated from other business systems.
- SAQ C-VT: manual keying into a provider's web virtual terminal, on a computer dedicated to that purpose.
- System type: each SAQ allows only one permitted system type, so a second kind of payment device in the same environment can change the answer.
- Multiple stores or storage: a multi-store environment or any electronic storage of card data generally moves the merchant toward SAQ D.
- Ask your provider: whether your virtual terminal is hosted in a way that matches SAQ C-VT.
Confirm the isolation design and any other electronic channels in writing before you select the questionnaire.
SAQ D for Merchants is the broadest merchant questionnaire. It covers merchants whose environments do not fit the narrower SAQs, including e-commerce sites that accept card data directly and merchants that store cardholder data electronically, even when that data is encrypted. SAQ P2PE covers merchants that use a validated point-to-point encryption solution in which the card data is encrypted at the device and not accessible in clear text on the merchant's systems. SAQ SPoC covers merchants using a validated SPoC solution, in which a mobile device accepts card data through a secure card reader and a secure payment application.
- SAQ D for Merchants: the default when no narrower SAQ's criteria are fully met.
- Encrypted storage: encrypted cardholder data still counts, so storing it electronically points to SAQ D.
- SAQ P2PE: requires an approved P2PE solution used as validated, with no clear-text card data in the merchant environment.
- SAQ SPoC: requires a validated SPoC solution used as validated, on the solution's mobile device and reader.
- Requirements: some SAQ D requirements can be marked not applicable only when the reason is documented.
Confirm with your acquirer whether a validated solution is in use and whether it is deployed as the vendor's listing requires.
SAQ D for Service Providers is the only self-assessment questionnaire a service provider can use. Every other SAQ is written for merchants. Service providers are organizations that store, process or transmit cardholder data for others, or that manage components that could affect the security of another entity's cardholder data environment, such as hosting providers and managed service providers. Their questionnaire covers the requirements that apply to running services for customers, in addition to the merchant-style controls that apply to their own environment.
- Only option: service providers cannot use a merchant SAQ, even when their own payment flow looks simple.
- Scope: the questionnaire covers the provider's own systems and the services it delivers to customers.
- Evidence for customers: a merchant SAQ or its AOC does not satisfy a customer who needs a service provider's validation.
- Brand requirements: the payment brands set the level and validation route, so confirm the expected form with each brand or acquirer.
- Assessor decision: some providers must validate through a Report on Compliance rather than a self-assessment, depending on brand rules.
Confirm the validation route with each payment brand or acquirer that your customers rely on before you start the questionnaire.
Why every eligibility criterion has to hold
An SAQ is either valid for your environment or it is not. Eligibility is a precondition, not a score. The PCI SSC's rule is that all of an SAQ's eligibility criteria must be met before you can use it, so failing one criterion does not leave you with a slightly weaker SAQ. It moves you to a different SAQ, most often SAQ D for Merchants, which covers the full standard. A merchant that answers nine of ten criteria correctly and fails the tenth cannot submit the shorter form with a note explaining the gap.
The criteria are written to cover three areas: how the payment system is isolated from the rest of your network, which types of system are involved in accepting card data, and whether any cardholder data is stored electronically, including in encrypted form. A criterion about isolation might require that a payment page or terminal has no connection to back-office systems. A criterion about system types limits which devices can sit in the payment flow. A criterion about data handling is where encrypted storage often breaks eligibility, because encrypted cardholder data still counts as cardholder data for SAQ purposes. Read each criterion in the current SAQ Instructions and Guidelines and check it against your network diagram, device inventory and data flows.
Do not decide based on the channel label. A team that says it runs an "e-commerce channel" or a "POS channel" may have a shared admin network, a reporting database that holds card numbers, or a store server that also runs email. Walk each criterion through your actual environment, record the evidence for each answer, and ask your acquirer or payment brand to confirm the result before you start the questionnaire. If a criterion is hard to verify, treat it as failed until you can show otherwise, because an assessor or acquirer will apply the same test.
How encrypted storage pushes you to SAQ D
Most merchants start by assuming that encryption keeps them in a lighter questionnaire. The PCI SSC treats encrypted cardholder data as cardholder data, so the triggers below decide whether SAQ D applies even when no plain card numbers are kept. Check each one against your actual environment before choosing an SAQ.
Any electronic storage, even encrypted
Every SAQ except SAQ D includes an attestation that you do not store cardholder data electronically. Encrypted card data still counts as cardholder data, so a database, log, spreadsheet, backup or ticketing attachment that holds encrypted PANs can rule out the lighter SAQs. Confirm where any card number exists in encrypted form, including backups, exports, support tools and developer test copies, and list each location before you choose the SAQ.
Direct e-commerce card capture
If your website collects card numbers on your own pages or servers and then passes them on, you are outside the scope of the redirect and iframe models. Card data enters your environment before it leaves, which sets your merchant environment apart from SAQ A-EP. Confirm whether card fields are served from your own domain or server by reviewing the payment flow with your developers and your acquirer.
Environments that break other SAQ criteria
Each SAQ has eligibility criteria, such as a single permitted system type for SAQ B-IP, C or C-VT, or isolation of the payment device from other systems. A single failed criterion moves you to a different SAQ. For example, a back-office server that administers a payment terminal breaks SAQ B-IP eligibility. Walk through each criterion of your candidate SAQ and document which system fails it.
Multiple connected payment channels
A merchant with several channels may complete one SAQ per channel, but each channel must meet its own SAQ criteria and be segmented from the others. If one channel stores data, or two channels share systems without adequate segmentation, the combined environment can fall under SAQ D. Map every channel and every shared system before deciding between separate SAQs and one combined SAQ.
Confirmation with your acquirer
The SAQ Instructions and Guidelines describe each SAQ's environments, and the PCI SSC encourages you to contact your acquiring bank or payment brand before starting. Acquirers can require a specific SAQ or set validation expectations of their own. Ask your acquirer in writing which SAQ applies and record the answer alongside your scope diagram.
One SAQ for all channels or one SAQ per channel?
This table compares the two approaches a merchant with several payment channels can take, and what each requires in eligibility, segmentation and reporting. Read it as a decision aid: the right choice depends on whether channels share an environment, and the acquirer should confirm the approach before the questionnaire is started.
| Question | Separate SAQ per channel | Single SAQ covering all channels |
|---|---|---|
| What it covers | Each payment channel is assessed on its own SAQ, matched to that channel's payment method | One SAQ describes every channel, so it must fit the most demanding environment in use |
| Eligibility | Each channel must meet the eligibility criteria of its own SAQ | All channels must meet the criteria of the single SAQ chosen, which is often a stricter type |
| Segmentation | Adequate segmentation between channels is required and must be demonstrated | Shared environments are included in one assessment, so no segmentation split is needed |
| Reporting | Covered environments are recorded in the AOC executive summary for each SAQ | One AOC covers all environments, with the executive summary listing what is in scope |
| Typical fit (illustrative) | A store with a standalone terminal and a separate e-commerce site with a redirect page | Channels that share a POS network, payment application or card data storage |
| Main risk | A weak boundary between channels can disqualify the separate SAQs | Including a stricter channel can push every channel into a larger questionnaire |
| What to confirm | Ask the acquirer whether separate SAQs are accepted for your channel structure | Ask whether a single SAQ is acceptable and which SAQ type the acquirer expects |
How to confirm the SAQ with your acquirer before you start
This sequence turns a vague sense of how you take cards into a written, channel-by-channel eligibility check that your acquiring bank or payment brand has agreed to before you spend time on the questionnaire. It prevents the common failure of completing an SAQ that the acquirer later rejects as the wrong type.
Map every payment channel you operate
The merchant lists each way card data enters the business: e-commerce pages, standalone terminals, internet-connected point of sale, virtual terminals, mail or phone orders, and any mobile or subscription flow. For each channel, record the devices, the software, where card data is received, and whether it is stored electronically, including in encrypted form. Finance or operations owns this list, and technical staff verify the device and network details. The step is done when every channel has a one-line description and an owner.
Read the matching SAQ instructions and guidelines
Download the SAQ Instructions and Guidelines document for PCI DSS v4.0.1 from the PCI SSC Document Library, then read the section for each SAQ type that could fit your channels. The document explains each SAQ's intent, its environment and its eligibility criteria. Read the full criteria for each candidate rather than the summary, because a single unmet criterion removes that SAQ from consideration. The step is done when you can name the candidate SAQ for each channel and the criteria it depends on.
Draft the eligibility check for each channel
For each channel, write a table that marks every eligibility criterion of the candidate SAQ as met, not met or unclear, with the evidence behind each mark, such as a network diagram, a device inventory or a vendor configuration. Note where the answer depends on how a device is administered or how a network is segmented. Where one channel fails a criterion, record which SAQ that channel falls to instead. Qualified staff should review the draft, and a QSA or ISA can help if the boundaries are unclear. The step is done when every channel has a documented answer and every unclear point has an owner.
Decide on one SAQ or one per channel
If you have several payment channels, decide whether to complete one SAQ covering all of them or a separate SAQ for each. Separate SAQs require each channel to meet its own eligibility criteria and adequate segmentation between channels, and the covered environments are recorded in the executive summary of the Attestation of Compliance. Choose the approach that your acquirer accepts and that your network can support. The step is done when the decision and its reasons are written down and the covered environments are listed.
Contact your acquirer or payment brand to confirm
Send the channel map and the draft eligibility check to your acquiring bank or the payment brand that manages your program, and ask them to confirm which SAQ applies to each channel and whether they accept the segmentation you describe. The PCI SSC encourages entities to contact the organization they submit to before starting, so do this early. The acquirer or brand decides who must validate and which validation type they accept, not the PCI SSC. The step is done when you hold written confirmation of the SAQ type for each channel, with the date and the contact's name.
Record the confirmed scope and any open questions
Update the channel map and eligibility check with the acquirer's answers, and note any points the acquirer asked you to resolve before submission, such as a change to device administration or an unsupported channel. Store the confirmation with the scope documentation so that the same answer is available to your assessor and to future reviewers. If the acquirer's answer differs from your draft, revisit the affected channel before going further. The step is done when the scope record, the confirmation and the open items are filed together.
Begin the questionnaire only after confirmation
Start completing the confirmed SAQ, or the set of SAQs, only after the acquirer's confirmation is on file. Work through the questions in the order of the document, perform the expected testing that each requirement calls for, and keep the evidence for each response. If the scope changes during the work, stop, repeat the eligibility check and confirm the change with the acquirer before continuing. The step is done when the questionnaire starts from a scope that has already been agreed with the party that accepts it.
Questions buyers ask before choosing an SAQ
Is a self-assessment questionnaire always enough for PCI DSS?
No. A self-assessment questionnaire is only available if you meet the eligibility criteria of a specific SAQ. Entities that do not qualify for any SAQ, or that their acquirer or payment brand requires to validate through a Report on Compliance, must use a Qualified Security Assessor. The Self-Assessment Questionnaire is the validation tool for SAQ-eligible merchants and service providers, and every criterion of the chosen SAQ must be met before you use it. Confirm your validation level and required method with your acquiring bank or payment brand, since the PCI SSC does not set those requirements itself. Your cardholder data flows and the systems that touch them decide the answer more than your business size does.
Does SAQ A apply when we use a hosted payment page?
Sometimes, but the hosting method matters more than the fact that a provider is used. SAQ A covers merchants that fully outsource all cardholder data functions to PCI DSS validated third parties, with no electronic storage, processing or transmission of card data on their own systems. A payment page that is served by your own website and posts card data to the provider can move you to SAQ A-EP instead, because your web server can affect the security of the payment page. Read the eligibility criteria for each hosting model against your actual page flow, and confirm the result with your acquirer before you start.
What happens if an SAQ eligibility criterion fails in the middle of the year?
You can no longer use that SAQ until you again meet all of its criteria, and you should contact your acquirer promptly to agree on the next step. Eligibility is judged against the current environment, so a change such as adding a second payment channel, storing data electronically, or connecting a payment device to a new network can invalidate an earlier choice. The change may move you to a different SAQ, to a full Report on Compliance, or to a multi-SAQ approach if the channels are separately segmented. Keep a change log for payment systems so that you can detect these events and document the new scope when they happen.
Must a QSA complete the SAQ for us?
No. The merchant or service provider completes the SAQ and signs its Attestation of Compliance, so the organization is responsible for the answers. A Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA) can help you interpret the requirements and gather evidence, but they do not issue the SAQ as an independent assessor, and they do not replace the acquirer's requirements for validation. Whether you need outside help depends on your team's experience with PCI DSS, the number of systems in scope and how your acquirer views the submission. Ask any firm you hire to explain exactly which parts of the work they will perform and which remain yours.
How long does choosing the right SAQ take?
The time depends on how many payment channels you run, how many systems touch card data, and how well your data flows are documented. A single channel with a clearly isolated terminal can be settled quickly once the eligibility criteria are read against your environment. Multiple channels, shared networks, or unclear data flows take longer, because each channel needs its own review and the segmentation between channels needs evidence. Ask your acquirer which SAQ they expect before you begin, so that the discovery work is focused on the right criteria.
Can an implementation partner confirm our SAQ eligibility without issuing the AOC?
Yes, a partner can help you check eligibility and prepare the evidence, but only you can decide which SAQ to use and only you can sign the Attestation of Compliance. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Any eligibility review should be documented in the written scope, and the final determination should be confirmed with your acquiring bank or payment brand.
What to have ready before the SAQ choice is final
The SAQ you can use depends on facts about how cards move through your business, not on how you hope they move. Gather these five artifacts before you choose, because each one either confirms an eligibility criterion or exposes a gap that pushes you toward a larger questionnaire.
Current payment channel inventory
List every way your organization accepts card payments: e-commerce pages, standalone terminals, IP-connected POS, a web-based virtual terminal, mail or phone orders, and any mobile acceptance. For each channel, record the device or page, the owner, and whether card data is typed, swiped, dipped, tapped or redirected. Each channel may need its own SAQ, so an incomplete list can produce the wrong answer. Owner: payments or finance operations, reviewed by the security lead.
Card data flow description
Write down how card data enters, moves through and leaves each channel, including the systems that receive it, transform it, log it or forward it. Note every point where the merchant's own systems touch the PAN, even briefly. This document shows whether the merchant ever receives card data, which decides between SAQ A, A-EP and the SAQs that require the merchant to handle it. Owner: the architecture or application owner, with sign-off from the payments lead.
Network diagram showing segmentation
Draw the network that carries each payment channel, marking the boundary between the channel and the rest of the business network. Show where terminals, POS devices, administrative workstations and any internet connection sit. Segmentation claims must be visible here, because multiple channels may use separate SAQs only when adequate segmentation between them exists. Owner: network or infrastructure engineering, verified by a test of the boundary.
Storage location register, including encrypted stores
List every place cardholder data or sensitive authentication data is kept, including databases, logs, backups, spreadsheets, email, ticketing systems and removable media. Mark which locations hold encrypted data, because encrypted cardholder data still counts for eligibility. Any electronic storage, even encrypted, can move you to SAQ D, so this register is the item most likely to change the answer. Owner: data owner for each system, consolidated by the compliance lead.
Acquirer's written SAQ confirmation
Ask your acquiring bank or payment brand, in writing, which SAQ applies to each channel you described, and keep the reply with the artifacts above. The PCI SSC encourages entities to contact the party they submit to before starting, and the SAQ Instructions and Guidelines document explains each questionnaire's intent. Ask whether they accept a separate SAQ per channel or require one combined SAQ. Owner: the finance or merchant services contact who manages the acquiring relationship.
Who owns the SAQ decision and who prepares the evidence
The merchant owns the outcome. Its leadership, finance or operations function and its security or IT owner choose which SAQ fits how the business accepts cards, confirm that every eligibility criterion is met, answer each requirement and sign the Attestation of Compliance (AOC). Nobody else can make those statements on the merchant's behalf.
- Eligibility decision: The merchant documents each payment channel, the systems that touch card data and the reasoning for the SAQ selected.
- Control ownership: Each requirement that applies needs a named internal owner who can explain how the control works day to day.
- Responses and AOC: The merchant completes the questionnaire, records responses honestly and signs the AOC with an officer who accepts the accuracy of the attestation.
- Ongoing conditions: Eligibility can change when a new channel, device or hosting arrangement appears, so the merchant must re-check the choice when the environment changes.
- Evidence retention: The merchant keeps the records that support each answer for review.
Check that your internal owners can explain each answer without reading it from a document.
An implementation partner such as DeployOpen can help the merchant or service provider prepare its environment and evidence. Typical work includes scoping the systems in each payment channel, designing or checking network segmentation between channels, configuring hardened systems and collecting the records that show controls operate. The partner works inside the client's own infrastructure under a written scope.
- Scoping support: Mapping which systems store, process or transmit card data, and which can affect them, so the SAQ choice rests on facts.
- Segmentation work: Preparing isolation between payment and non-payment systems where the chosen SAQ requires it.
- Evidence preparation: Gathering configuration baselines, access lists, logs and inventories the merchant can present.
- Gap support: Remediating gaps the merchant has identified, so the answers it gives are accurate when it signs.
- Limits: The partner does not issue the AOC, does not decide eligibility on the merchant's behalf and does not stand in for an independent assessor.
Ask any partner to state in writing which tasks it performs and which remain the merchant's.
The acquiring bank or payment brand confirms which SAQ applies and where the AOC must be sent. The PCI Security Standards Council (PCI SSC) does not enforce compliance or set reporting requirements for individual merchants; the payment brands decide who must validate and run their own programs. Merchants should confirm the SAQ with their acquirer before starting, because the acquirer's answer determines what evidence is accepted.
- Confirming the SAQ: Ask the acquirer which SAQ it expects for each channel and whether multiple SAQs are acceptable.
- Submission rules: Confirm the recipient, format and deadline for the AOC and any supporting documents.
- Validation level: Ask whether the merchant's transaction volume or risk profile requires a different validation route, such as a ROC by a Qualified Security Assessor.
- Written confirmation: Keep the acquirer's response with the scoping file so the choice is traceable.
- Program rules: Payment brand programs can change, so re-confirm when the acquirer contract, channels or volumes change.
Before starting, confirm in writing which SAQ your acquirer expects and whether an independent assessor must be involved.
When outside help changes the SAQ answer
Outside help matters most when you cannot yet state, with evidence, which systems touch card data. The SAQ you choose depends on facts about your environment: whether a point-of-sale device shares a network with the office, whether a back-office server can reach a payment terminal, and whether any stored file holds a primary account number. A consultant or implementation partner can map these facts, document the network and data flows, and test whether the boundaries you believe exist actually hold. That work often shows that an SAQ you assumed was available, such as SAQ C or SAQ B-IP, no longer fits, or that a store you thought was out of scope needs SAQ D. Ask any provider to name the systems it examined, the segmentation tests it ran and the evidence it handed over, so you can see exactly what changed your answer.
Several situations are common enough to check first. Segmentation between a payment device and other systems may be assumed rather than tested, and an isolation that exists on paper can fail once a shared printer, remote support tool or administrator laptop is added. Encrypted data stores are hard to find when they sit in logs, exports, backups, spreadsheets or developer test databases, and any electronic storage of encrypted cardholder data changes the SAQ answer. Multi-channel merchants face a separate question: whether each channel can be validated on its own SAQ with adequate segmentation between channels, or whether one SAQ covering everything is simpler. Each of these is a place where an adviser can prepare the evidence that your acquirer will later ask to see.
Help changes what you prepare, not who signs. An implementation partner can clarify scope, harden systems, and assemble diagrams, configurations and test results, but the merchant still owns its controls and completes the SAQ and its Attestation of Compliance. Only an independent QSA or other recognized assessor issues a ROC or validates the environment where required. Before you start, confirm the SAQ choice with your acquiring bank or payment brand, as the PCI SSC SAQ guidance advises, and agree in writing what the adviser will deliver and what remains your responsibility.
How DeployOpen scopes systems ahead of the SAQ
Choosing an SAQ depends on how card data flows through your systems, so the work starts with scope, not the questionnaire. DeployOpen maps your payment channels, the systems that touch them and the boundaries between them, then prepares the environment so the SAQ you select matches what is actually in place. Your organization owns the eligibility decision, and your acquirer or payment brand confirms it.
How we scope
- Map each payment channel and the systems that send, receive or store account data
- Identify any electronic storage, including encrypted data, that could move you toward SAQ D
- Document the written scope of which SAQ criteria we will help you test before work starts
- Agree deliverables, scope and timeline in writing as a fixed-scope engagement
How we build
- Prepare segmentation between payment channels so each SAQ's criteria can be met
- Configure isolated systems, such as a dedicated terminal or virtual terminal computer, where the chosen SAQ requires it
- Implement and harden open-source platforms inside your own cloud accounts, data centers or networks
- Record configuration, network boundaries and data flows as evidence for the SAQ
How we hand over
- Deliver a scope summary listing each channel, its SAQ type and the systems it covers
- Provide documentation that supports each eligibility criterion, ready for your internal review
- Ask your acquirer or payment brand to confirm the chosen SAQ before you begin the questionnaire
- Transfer administration and evidence ownership so your team can maintain the environment
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Revisit scope when a payment channel, system or storage location changes
- Coordinate with your independent QSA or ISA where an assessor is involved, without issuing any attestation ourselves
- Confirm with you which SAQ version and instructions apply at each renewal cycle
