PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ C)

Why does it matter?

SAQ C marks the point at which a merchant's own network and software come into PCI DSS scope. A POS system on a local area network with an Internet connection has to defend itself with network security controls, secure configurations, anti-malware, patching, individual authentication, audit logging and periodic testing, which is why all twelve requirements appear. What keeps the work proportionate is the eligibility rule that the LAN serves a single store and that the payment application is isolated from every other system, so the controls apply to one location rather than an enterprise network.

Key benefits include:

• Twelve requirements, one store

The criteria require that the physical POS location is not connected to other premises and that any LAN is for a single store only, so the full set of requirements is applied to a bounded environment.

• Segmentation defines the edge

The payment application system must be isolated from all other merchant systems, which the criteria say can be achieved by network segmentation; Requirement 11.4.5 then requires that segmentation to be penetration-tested at least every 12 months.

• Logging sized to the merchant

Requirement 10 is included, with log retention of at least 12 months and the most recent three months immediately available (10.5.1), but the central log server backup requirement 10.3.3 was removed in October 2024.

• Risk analysis only where the standard asks for it

Requirement 12.3.1 requires a documented targeted risk analysis for each requirement that calls for one, reviewed at least once every 12 months, rather than a general enterprise risk assessment.

• Scan evidence is specified

Requirement 11.3.1 internal scans and 11.3.2 external scans by an Approved Scanning Vendor are both quarterly, and the Expected Testing column names the scan reports as the evidence to examine.

How does it work?

The five completion steps are the same as in the other SAQs but carry more weight here because of the scope involved: establish from the eligibility criteria and the Self-Assessment Questionnaire Instructions and Guidelines that SAQ C fits; confirm the scope, which Part 2c asks the merchant to describe together with whether segmentation is used; assess the environment against the requirements; complete Sections 1 to 3; and submit the SAQ, the AOC and any requested material, including ASV scan reports, to the brand or acquirer.

Responses are In Place, In Place with CCW, Not Applicable and Not in Place, one per requirement. A compensating control needs a Compensating Controls Worksheet in Appendix B, and every Not Applicable answer needs the explanation form in Appendix C; Appendix D, for Not Tested, is unused because that option is not available in SAQ C. Part 2g of the AOC then summarizes which responses were used for each of the twelve requirements, and a Not in Place answer can lead to Part 4 if the recipient requests an action plan.

The front matter sets out three further rules. Future-dated requirements were best practice until 31 March 2025 and could be marked Not Applicable before then with an Appendix C explanation. A requirement that a local or regional law prevents the merchant from meeting is marked Not in Place and attested as a legal exception in Part 3, and contractual obligations do not qualify. The customized approach is not available in any SAQ, so the questionnaire omits the customized approach objectives and a merchant wanting that route must discuss a Report on Compliance with its acquirer.

Key Elements

• Merchant Eligibility Criteria

The payment application system and the Internet connection are on the same device and/or the same LAN; the payment application system is not connected to any other merchant system (segmentation permitted); the POS location is not connected to other premises and any LAN serves a single store; no account data is stored electronically; any retained account data is on paper and not received electronically.

• Requirements 1 and 2: Network and Configuration

1.3.1 to 1.3.3 inbound and outbound traffic restricted and controls between wireless networks and the CDE; 2.1.1 configuration policies; 2.2.1 configuration standards; 2.2.2 vendor defaults; 2.2.3 to 2.2.6 separation of functions, necessary services only, insecure services justified, security parameters set; 2.2.7 encrypted non-console administration; 2.3.1 and 2.3.2 wireless defaults and key changes.

• Requirements 3 and 4: Account Data

3.1.1 policies; 3.3.1 sensitive authentication data not stored after authorization; 3.4.1 PAN masked on display; 4.2.1 strong cryptography and trusted certificates for PAN over open, public networks; 4.2.2 PAN protected with strong cryptography whenever sent by end-user messaging technologies.

• Requirements 5 and 6: Malware and Software

5.1.1 policies; 5.2.1 to 5.2.3 anti-malware deployed, kept effective and reviewed for exempt systems; 5.3.1 to 5.3.5 current, scanning, removable media, logging and tamper-resistant; 5.4.1 anti-phishing mechanisms; 6.2.1 to 6.2.4 bespoke and custom software developed securely by trained personnel; 6.3.1 and 6.3.3 vulnerability ranking and patches; 6.5.1 and 6.5.2 change control with documented approval and post-change confirmation.

• Requirements 7 and 8: Access and Authentication

7.2.2 to 7.2.5 least privilege, approved privileges, access reviews at least every six months and managed application accounts; 8.2.1 to 8.2.8 unique IDs, no shared accounts, managed changes, immediate revocation, inactive accounts, third-party accounts and re-authentication after 15 minutes idle; 8.3.1 to 8.3.9 authentication factors and password rules; 8.4.1 to 8.4.3 multi-factor authentication; 8.5.1 MFA configuration; 8.6.1 to 8.6.3 application and system accounts.

• Requirement 9: Physical Access

9.1.1 policies; 9.2.1 facility entry controls for systems in the CDE; 9.2.2 publicly accessible network jacks; 9.4.1 to 9.4.6 media security, classification, transport, approval and destruction; 9.5.1 protection of point-of-interaction devices against tampering and substitution.

• Requirements 10 and 11: Logging and Testing

10.2.1.2, 10.2.1.4 and 10.2.1.5 logs of administrative actions, invalid access attempts and credential changes; 10.2.2 log detail; 10.3.1, 10.3.2 and 10.3.4 log protection and file integrity monitoring; 10.4.1 to 10.4.3 log review and exception handling; 10.5.1 retention; 10.6.1 to 10.6.3 time synchronization; 11.2.1 and 11.2.2 wireless access point detection and inventory; 11.3.1 and 11.3.2 quarterly internal and ASV scans; 11.4.5 segmentation tests; 11.5.2 change detection on critical files.

• Requirement 12 and the Attestation

12.1.1 to 12.1.3 the security policy; 12.2.1 acceptable use policies; 12.3.1 targeted risk analysis; 12.6.1 awareness; 12.8.1 to 12.8.5 third-party service providers; 12.10.1 incident response plan and 12.10.3 personnel available around the clock. Section 1 holds AOC Parts 1 and 2 (with 2g summarizing twelve requirements and 2h the eligibility certification) and Section 3 holds Part 3 (Compliant, Non-Compliant or Compliant but with Legal exception, signed in 3a to 3d) and Part 4.

What does it cover?

The questionnaire is for brick-and-mortar or mail and telephone order merchants that process account data through a POS or other payment application system connected to the Internet, store no account data on any computer system, and run that system in a single store isolated from other systems and premises (Merchant Eligibility Criteria). Everything on the same device or LAN as the payment application is within the assessment, together with wireless networks, administrators, logs, the paper records the merchant may keep and the third-party service providers it uses. Merchants with e-commerce channels, multi-site networks, electronic storage or service provider roles need another SAQ or a Report on Compliance.

What are its objectives?

The form exists so that a qualifying merchant can show, requirement by requirement, that a connected payment application is run securely:

To establish eligibility and scope in Parts 2a to 2h, including the single-store LAN, the isolation of the payment application and whether segmentation is relied on.

To demonstrate network, configuration, anti-malware, patching and change control over the payment application system and its LAN (Requirements 1, 2, 5 and 6).

To keep account data out of storage and encrypted in transit, including over end-user messaging (Requirements 3 and 4).

To authenticate and limit every user and administrator, with six-monthly access reviews, idle timeouts and multi-factor authentication (Requirements 7 and 8).

To log, review, retain, scan and test the environment on the schedules the form sets, document each targeted risk analysis, manage providers and incidents, and sign the Attestation of Compliance (Requirements 9 to 12).

Framework in Context

SAQ C sits above SAQ B-IP, whose standalone PTS terminals need no anti-malware or logging requirements, and beside SAQ C-VT, for merchants who key transactions into a third-party virtual terminal from one isolated computer. A merchant that outgrows the single-store criteria or stores account data electronically moves to SAQ D for Merchants. The requirement text in Section 2 is drawn from PCI DSS v4.0.1 (June 2024), and the appendices on multi-tenant service providers (A1), SSL and early TLS (A2) and designated entities (A3) are listed only to confirm they do not apply.

Common Framework Mappings

With all twelve requirements present, SAQ C shares most of the parent standard's mappings: its network, configuration, malware, access, logging and testing controls correspond to the control families of the frameworks listed below.

Mapped frameworks include:

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST 800-53 Rev.5

PCI DSS 4.0.1

PCI PA-DSS

SOC 2