How should organisations decide which PCI SAQ applies to their payment environment?

Why This Matters for Security Teams

Choosing the wrong PCI SAQ is not a paperwork error. It can mean certifying against controls the environment does not actually meet, or missing controls that still apply because the payment flow was not fully outsourced. PCI scope is determined by how cardholder data moves, where it is stored, and which systems can influence security. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the broader principle: scope must follow real risk and system impact, not organisational convenience.

That same scoping discipline is critical when secrets, tokens, or admin credentials touch payment systems. NHIMG research shows that NHI Mgmt Group has found 96% of organisations store secrets outside secrets managers in vulnerable locations, which is exactly how a supposedly constrained payment environment quietly becomes broader than intended. In practice, teams often discover SAQ scope drift only after an assessor traces a shared service, plugin, or API path that was never included in the original diagram.

How It Works in Practice

Start with merchant versus service provider, then map the full payment data path: acceptance, transmission, processing, and storage. The right SAQ depends on whether card data touches the organisation’s systems directly, whether a validated third party fully handles the payment function, and whether internal systems can affect the security of the cardholder data environment. For example, a hosted payment page with no electronic card data touchpoints may fit a shorter SAQ than an environment that still transmits or stores data, but only if the implementation truly removes the organisation from scope.

Security teams should validate the architecture, not just the business description. Review network diagrams, endpoint inventories, browser redirects, payment iframe behaviour, API callbacks, logging paths, and any admin consoles that can influence payment controls. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to identify assets, dependencies, and trust boundaries before making control decisions. For payment scope, the same logic applies to payment gateways, middleware, support tooling, and identity systems.

NHIMG research on JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions shows how developer tooling can leak secrets into systems that teams did not intend to include in scope. That matters for SAQ selection because any system that can alter payment security, even indirectly, can pull the environment toward a more demanding validation path. These controls tend to break down when payment functions are split across SaaS, scripts, plugins, and shared identity providers because the real data flow becomes harder to prove than the assumed one.

• Confirm whether card data is outsourced end to end or still touches internal assets.
• Identify every system that stores, transmits, or can affect payment security.
• Validate whether the environment fits a simplified SAQ category before assuming it does.
• Default to the broader SAQ D path when scope is unclear or shared control exists.

Common Variations and Edge Cases

Tighter SAQ selection often increases assessment effort, requiring organisations to balance reduced compliance burden against the risk of understating scope. That tradeoff is real in hybrid payment environments where hosted fields, redirect flows, tokenisation, and call centres overlap. Current guidance suggests that if a control point remains inside the organisation’s environment, the environment may still be in scope even when card data itself is not stored there.

Edge cases usually appear in shared services. A content management system, customer portal, analytics tag, support desk workflow, or SSO platform may not process card data directly but can still affect how payment pages render or how access is governed. That is where SAQ assumptions fail and where assessor review often becomes more conservative. NHIMG’s Ultimate Guide to Non-Human Identities notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which is relevant because service accounts and API keys frequently extend payment scope beyond what teams model on paper.

There is no universal standard for every edge case, so the best practice is to document the payment architecture, validate outsourcing claims with evidence, and re-check scope after any change to code, redirect logic, secrets handling, or third-party integrations. When those details are uncertain, SAQ D is usually the safer interpretation than an optimistic shortcut.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?