GRSee cybersecurity and compliance

In this article

Avoid These 6 Mistakes When Submitting a PCI DSS SAQ

Common SAQ submission mistakes include misjudging scope, incomplete documentation, overlooking third-party risks, and using the wrong SAQ type. These errors can lead to non-compliance, audit failures, or security gaps.

a man in a white shirt sitting in front of a painting
By Besther Nwosu
Photo of Danell Theron
Edited by Danéll Theron

Updated March 18, 2026

a group of people standing around a table

Submitting your PCI DSS Self-Assessment Questionnaire (SAQ) might look like a straightforward compliance task, but it’s often where organizations make avoidable mistakes. Choosing the wrong SAQ type, overlooking documentation, or underestimating third-party risks can leave serious security gaps. Even small errors in an SAQ form can result in delays, fines, or exposure to breaches.

In this blog, we’ll break down who must submit an SAQ, how submission works, and the most common mistakes organizations make—plus how to avoid or fix them.

» Take the first step towards PCI DSS compliance: Reach out to our experts



Who Must Submit an SAQ and How It Works

Merchants processing fewer than six million card transactions a year may qualify to complete a SAQ rather than a full Report on Compliance (RoC). Which SAQ applies depends on how cardholder data is handled:

  • SAQ A: Fully outsourced e-commerce with no cardholder data touching merchant systems.
  • SAQ A-EP: Merchant-managed websites that redirect or frame to a third-party processor.
  • SAQ B, B-IP, C, C-VT, P2PE, D: Cover various scenarios such as point-of-sale terminals, virtual terminals, or environments where cardholder data is stored.

» Learn more: Here are the benefits of PCI DSS compliance

Merchant Level Also Determines Eligibility:

  • Level 1: Over six million transactions annually or a history of breaches, must complete a RoC.
  • Levels 2–4: Lower transaction volumes generally qualify for an SAQ.
  • Service providers: Thresholds are lower (under 300,000 transactions annually).

Submission and Deadlines

Once the right SAQ is completed, it must be submitted with a current Attestation of Compliance (AOC), signed by an authorized officer. In most cases, both documents are sent to the acquiring bank.

Deadlines are usually annual, but not all businesses have the same timeline. Acquirers may set different dates depending on industry, merchant level, or risk profile. High-risk merchants, or those that change how they process card data, may be asked to submit earlier or more than once a year.

Verifying Acceptance

After submission, confirmation should come from your acquirer or the compliance portal in use. This might be an email, a portal status update, or a formal acceptance letter.

Pro tip: Always make sure the AOC is fully completed and signed, as missing information is one of the most common causes of rejection.

If you don’t receive acknowledgment within a reasonable timeframe, request written confirmation and keep it on record as part of your compliance audit trail.

» Discover how to succeed with PCI DSS compliance

Need Help Identifying Your PCI DSS Level?

Use our expert guide to avoid compliance challenges by targeting the appropriate PCI DSS level for your business.

a person in a hoodie using a laptop


Preventing and Correcting Common PCI DSS SAQ Submission Mistakes

Common and impactful mistakes when submitting a PCI DSS SAQ—particularly SAQ A or SAQ A-EP—often result from treating compliance as an annual box-checking exercise rather than a continuous security process.

Addressing these errors promptly is essential to avoid severe consequences like data breaches and regulatory penalties.

Mistake 1: Not Defining Proper Scope

The main cause is a lack of understanding of PCI DSS scoping rules, specifically the concept that any system capable of affecting the security of the CDE is in scope. This error is often driven by a desire to minimize compliance workload. Other causes include poor training, outdated network diagrams, and unverified assumptions about network segmentation controls.

Inaccurate scoping results in undetected security gaps and a high risk of breach.

How to avoid
  • Assume everything is in scope until segmentation and controls prove otherwise.
  • Create and regularly update detailed network and data flow diagrams, asset inventories, and firewall rulesets.
  • Engage a Qualified Security Assessor (QSA) early to validate scope assumptions and review segmentation effectiveness.
  • Perform regular internal audits and penetration tests to verify that segmentation works and isolates the CDE.
  • Integrate PCI scoping checks into your change management process when deploying new infrastructure.
  • Train all relevant staff on PCI scope principles and the true boundaries of the CDE.

» Learn more: What is good compliance, and how to get started?

Mistake 2: Ignoring Documentation and Policy Requirements

This mistake often arises from assuming PCI compliance is solely an IT task, leading to poor interdepartmental communication and excluding business units. Documentation efforts are frequently deprioritized due to time constraints, lack of clear accountability, or underestimation of policy importance, leaving materials fragmented, outdated, or missing.

Failure to identify processes and maintain documentation leads to critical compliance gaps. Undocumented payment channels may process card data insecurely, vastly increasing breach risk.

How to avoid
  • Map all payment channels and involve stakeholders from both IT and business units through regular workshops.
  • Create a centralized documentation repository and assign a dedicated owner for consistency and version control.
  • Formalize policy updates as part of normal business and operational workflows.
  • Set recurring reminders to review and update key policies like access control and incident response.
  • Use a detailed checklist to align all business processes with explicit PCI DSS requirements.
  • Provide training to staff on their specific roles in maintaining compliance documentation.

» Explore the standards you should meet when building a security culture

Mistake 3: Overlooking Third-Party Risks

Outsourcing payment services does not remove PCI DSS responsibility. If third-party vendors access, process, or store cardholder data, you remain accountable. Failing to track vendors or clarify shared responsibilities can result in major compliance gaps.

Causes include a lack of awareness of PCI DSS Requirement 12.8, incomplete contracts, poor communication between legal and IT, and failing to periodically review the vendor’s PCI Attestation of Compliance (AOC).

If a vendor mishandles card data, the merchant remains accountable under PCI DSS. Breaches at third-party vendors are a major attack vector, resulting in severe reputational damage and regulatory penalties.

How to avoid
  • Maintain a current inventory of all third-party service providers that interact with the CDE.
  • Request and review their PCI AOC annually.
  • Document shared responsibilities using a formal PCI DSS Responsibility Matrix, specifying ownership for each requirement.
  • Integrate the responsibility mapping into all contracts and service-level agreements.
  • Perform regular due diligence to evaluate the vendor’s compliance status and risk level.
  • Ensure proper access controls and segmentation are in place for all vendor connections.

Third-Party Risk Support

GRSee helps you track vendors, map responsibilities, and keep your PCI DSS compliance secure.

Mistake 4: Control Breakdowns During Turnover

When key personnel leave or change roles, critical, ongoing controls (like access reviews or vulnerability management) are often not formally transferred, leading to compliance lapses.

The departure of key staff leads to a failure in security controls, such as logging or access reviews. If unnoticed, the organization quickly falls out of compliance, increasing exposure to data breaches, audit failures, and reputational harm.

How to avoid
  • Implement knowledge transfer protocols for transitions, ensuring successors are trained and responsibilities are reassigned before staff exits.
  • Automate recurring compliance tasks to reduce reliance on manual execution.
  • Establish "trigger events" (e.g., user termination) that automatically alert compliance teams to review related PCI responsibilities.
  • Incorporate compliance ownership into onboarding programs for new hires.

» Make sure you understand these PCI DSS myths

Mistake 5: Misunderstanding SAQ Eligibility Criteria

Selecting an SAQ type that does not accurately match the merchant's payment environment (e.g., using SAQ A when the complexity of the e-commerce model requires SAQ A-EP).

Using the wrong SAQ results in an invalid or incomplete PCI DSS assessment, leaving mandatory controls unaddressed. This can trigger fines and increase breach likelihood.

How to avoid
  • Review the official PCI DSS SAQ eligibility criteria provided by the PCI Security Standards Council.
  • Conduct a detailed assessment of how card data is handled, paying close attention to e-commerce flows for any signs of redirection (A-EP).
  • Consult with your QSA or PCI specialist to validate your SAQ type selection.
  • Build out data flow diagrams to visually confirm which components are in scope.
  • Document the rationale for your SAQ choice and maintain it for audit defense.

Mistake 6: Falling Behind on Recurring Tasks

Missing recurring requirements such as quarterly vulnerability scans, annual risk assessments, access reviews, or staff training can quickly lead to non-compliance. This often happens when PCI is treated as a yearly checkbox instead of a continuous process. Poor scheduling, unclear ownership, or lack of automation make these time-bound tasks easy to overlook.

Failing to complete recurring tasks jeopardizes compliance because they are time-bound—a missed quarterly scan cannot be retroactively fixed. This lapse creates non-compliance, which leads to failed audits, reputational harm, and potentially costly compensating controls.

» Here are 6 things you should know before hiring a risk assessment provider

How to avoid
  • Implement a centralized PCI compliance calendar for all periodic requirements (quarterly, biannual, annual).
  • Assign task owners with clear accountability, and use automated reminders or ticketing systems to track status.
  • Document each recurring task with associated evidence (e.g., scan reports, access control logs) in an organized repository.
  • Perform regular internal reviews to verify that scheduled tasks were completed on time.
  • Conduct mock audits to simulate real-world validation pressures.
  • Ensure all recurring obligations are included in onboarding materials and departmental SOPs.

» Know which PCI DSS path fits your business—so you can avoid these PCI DSS pitfalls



Mid-Cycle SAQ Resubmission: When Environment Changes

A business is generally required to re-evaluate and resubmit its SAQ mid-year if it experiences a significant change in its payment environment. This includes:

  • Launching a new e-commerce channel.
  • Changing payment processors.
  • Altering how cardholder data is handled.

To maintain compliance, organizations must consult their acquiring bank or QSA immediately to confirm the correct SAQ, update all documentation, and submit a revised assessment. Proactive mid-cycle updates are critical for avoiding security gaps.

» Get started with GRSee’s PCI DSS solutions to simplify your security strategy



SAQ Scrutiny: Triggers for a Deeper Review

The likelihood that a submitted SAQ will trigger a deeper review or audit by an acquiring bank or card brand depends on several key factors.

Common Triggers for a Deeper Review

  • Inconsistencies or incomplete responses: Any contradictions within the SAQ, or missing fields or documentation (like required vulnerability scans or the Attestation of Compliance).
  • Incorrect SAQ type: Choosing an SAQ that does not align with the merchant's actual card processing method (e.g., using SAQ A when the complexity requires SAQ A-EP).
  • Payment changes: Recent changes in payment processors or the use of custom payment solutions may prompt a review.
  • History: A documented history of non-compliance or previous data breaches will increase the likelihood of an audit.

Acquiring banks have the authority to require additional validation or request a full RoC if concerns regarding the merchant's accuracy or risk exposure arise.

» Learn how to build a robust PCI DSS security strategy beyond compliance

Prevent SAQ Mistakes

GRSee helps you manage your SAQ submission and avoid mistakes that could expose your business to penalties.



How GRSee Consulting Can Help

At GRSee, we know how confusing PCI compliance can feel—especially when even a small oversight can put you at risk. We work directly with you to determine the correct SAQ type, validate the scope, and ensure documentation meets PCI expectations.

Our consultants help you build repeatable processes, manage third-party risks, and stay on top of recurring compliance tasks. If you’ve already submitted and discovered errors, we guide you through remediation and resubmission.

» Ready to avoid costly mistakes and simplify the process? Let’s get started together

FAQs

What is a PCI DSS SAQ Form and why is it required?

A Self-Assessment Questionnaire (SAQ Form) is a compliance document that allows eligible merchants to confirm they meet PCI DSS requirements without undergoing a full audit.

Who decides which SAQ a business must complete?

Eligibility is based on transaction volume and how the business processes cardholder data. Acquiring banks and payment brands provide the final guidance.

How often should I submit an SAQ and AOC?

Most merchants must submit these once per year, but higher-risk businesses or those that change processing methods may be required to do so more often.

How can I confirm my SAQ has been accepted?

You should receive confirmation from your acquiring bank or compliance portal, either via email, letter, or portal update. If not, request written acknowledgment and keep records.