PCI DSS v4.0.1 SAQ CSupported in OneClickComply

Complete PCI DSS SAQ C for your connected payment systems

SAQ C is the PCI DSS v4.0.1 self-assessment questionnaire for merchants whose payment application system, such as a point-of-sale system, is connected to the internet but does not store account data electronically. Published by the PCI Security Standards Council in October 2024, it contains the subset of PCI DSS requirements relevant to that environment and is submitted with an Attestation of Compliance.

See the SAQ C requirements

SAQ C Aligned

Automated Evidence

OneClickFix Enabled

Continuous Monitoring

In-House Audit Team

Who needs SAQ C

Is SAQ C right for your organisation?

Brick-and-mortar and mail or telephone order merchants need SAQ C when their acquirer accepts self-assessment and their payment application system is isolated from all other systems, sits at a single location and stores no electronic account data. Merchants who take e-commerce payments, store card data electronically or connect the payment system to other business systems usually need a different SAQ or SAQ D.

It is usually required by customers, partners or schemes rather than by law.

Issued by: PCI Security Standards Council
Latest version: SAQ C for PCI DSS v4.0.1, published October 2024
Applies to: Merchants with isolated, internet-connected payment application systems and no electronic account data storage
Not for: E-commerce channels and service providers
Requirements: 122 in Section 2, plus A2.1.1 in Appendix A2
Validation route: Self-assessment questionnaire and Attestation of Compliance submitted to the acquirer or payment brand
Enforced by: Acquiring banks and payment card brands, through merchant agreements
Type: Standard (contractual)
Region: Global
In OneClickComply: Supported today

How we help

OneClickComply makes it simple

OneClickComply maps SAQ C's requirements to one control set, so evidence for MFA, logging, anti-malware, patching and access reviews is collected automatically from your connected tools and reused across frameworks. AutoComplete generates the policies SAQ C asks for, and continuous monitoring alerts you when controls on the payment environment drift. SAQ C is available on request from our control library.

Requirements covered

122 requirements across all 12 PCI DSS v4.0.1 principal requirements, plus requirement A2.1.1 for POS terminals using SSL or early TLS.

Already working towards another framework?

ISO 2700119% of SAQ C overlaps
SOC 286% of SAQ C overlaps
NIST CSF67% of SAQ C overlaps
GDPR14% of SAQ C overlaps

Evidence you collect once counts towards every framework it applies to.

Manual SAQ C vs. OneClickComply

Manual SAQ C

Working out whether your POS set-up really meets SAQ C eligibility
Screenshotting MFA, password and logging settings for every system
Writing policies and procedures for each of the 12 requirement areas
Chasing service providers for agreements and up-to-date AOCs
Finding control gaps only when the annual SAQ is due

With OneClickComply

Expert guidance from our audit team on SAQ choice and scoping
Evidence collected automatically from your connected tools
Audit-ready policies generated from your real environment
Service provider tracking in one vendor risk register
Alerts as soon as a control drifts, not at renewal time

Capabilities

Everything you need for SAQ C

Automated evidence for MFA, unique IDs and account reviews across Requirements 7 and 8

Logging and log review evidence mapped to Requirement 10

AutoComplete policies for each SAQ C requirement that asks for documented procedures

Continuous monitoring of anti-malware, patching and configuration baselines

Vendor risk management for service provider lists, agreements and responsibility matrices

Ask an Auditor guidance on SAQ eligibility, segmentation and penetration testing

How it works

Three steps to SAQ C compliance

Connect & scan

Connect your cloud, identity and SaaS tools. OneClickComply checks them against SAQ C and shows you exactly where you stand.

Fix & generate

OneClickFix remediates technical gaps in one click, and AutoComplete generates SAQ C-aligned policies from your real environment.

Monitor & evidence

Continuous monitoring keeps you compliant, and our in-house audit team is on hand when you need expert guidance.

Requirements

PCI DSS v4.0.1 SAQ C requirements

All 122 requirements in Section 2 of the v4.0.1 SAQ C, plus Appendix A2 requirement A2.1.1, with short descriptive titles.

Reference	Requirement
1.3.1	Inbound traffic to the CDE is restricted
1.3.2	Outbound traffic from the CDE is restricted
1.3.3	Network security controls between wireless networks and the CDE
2.1.1	Requirement 2 policies and procedures documented and in use
2.2.1	Configuration standards developed, implemented and maintained
2.2.2	Vendor default accounts managed
2.2.3	Primary functions with different security levels managed
2.2.4	Only necessary services, protocols and functions enabled
2.2.5	Insecure services, protocols or daemons justified and secured
2.2.6	System security parameters configured to prevent misuse
2.2.7	Non-console administrative access encrypted
2.3.1	Wireless vendor defaults changed or confirmed secure
2.3.2	Wireless encryption keys changed when required
3.1.1	Requirement 3 policies and procedures documented and in use
3.3.1	Sensitive authentication data not retained after authorisation
3.3.1.2	Card verification code not stored after authorisation
3.3.1.3	PIN and PIN block not stored after authorisation
3.4.1	PAN masked when displayed
4.2.1	Strong cryptography protects PAN over open, public networks
4.2.1.2	Wireless networks use strong cryptography for PAN
4.2.2	PAN secured when sent by end-user messaging technologies
5.1.1	Requirement 5 policies and procedures documented and in use
5.2.1	Anti-malware deployed on system components
5.2.2	Anti-malware detects, removes or contains known malware
5.2.3	Systems not at risk from malware evaluated periodically
5.2.3.1	Targeted risk analysis sets malware evaluation frequency
5.3.1	Anti-malware kept current through automatic updates
5.3.2	Anti-malware scans or continuous behavioural analysis
5.3.2.1	Targeted risk analysis sets periodic malware scan frequency
5.3.3	Removable electronic media scanned for malware
5.3.4	Anti-malware audit logs enabled and retained
5.3.5	Anti-malware cannot be disabled by users without authorisation
5.4.1	Personnel protected against phishing attacks
6.2.1	Bespoke and custom software developed securely
6.2.2	Developers trained in secure software development
6.2.3.1	Manual code reviews of bespoke and custom software
6.2.4	Software engineering techniques prevent common attacks
6.3.1	Security vulnerabilities identified and risk-ranked
6.3.3	Security patches and updates installed
6.5.1	Production changes follow established change procedures
6.5.2	PCI DSS requirements confirmed after significant changes
7.2.2	Access assigned on job need and least privilege
7.2.3	Privileges approved by authorised personnel
7.2.4	User accounts and access privileges reviewed
7.2.5	Application and system account access managed
8.1.1	Requirement 8 policies and procedures documented and in use
8.2.1	Unique ID assigned to every user
8.2.2	Shared, group or generic IDs used only by exception
8.2.4	User ID and authentication factor changes managed
8.2.5	Access for terminated users immediately revoked
8.2.6	Inactive accounts removed or disabled within 90 days
8.2.7	Third-party remote access accounts managed
8.2.8	Re-authentication after 15 minutes of idle session
8.3.1	User access authenticated with at least one factor
8.3.2	Authentication factors unreadable in transmission and storage
8.3.3	User identity verified before changing authentication factors
8.3.4	Invalid authentication attempts limited
8.3.5	Password set and reset requirements
8.3.6	Minimum password complexity
8.3.7	Previous four passwords cannot be reused
8.3.8	Authentication policies and procedures communicated to users
8.3.9	Single-factor passwords changed or access analysed dynamically
8.4.1	MFA for administrative non-console access into the CDE
8.4.2	MFA for all non-console access into the CDE
8.4.3	MFA for remote access from outside the network
8.5.1	MFA systems configured to prevent misuse
8.6.1	Interactive login by system and application accounts managed
8.6.2	System and application account passwords not hard coded
8.6.3	System and application account passwords protected from misuse
9.1.1	Requirement 9 policies and procedures documented and in use
9.2.1	Facility entry controls restrict physical access to the CDE
9.2.1.1	Physical access to sensitive areas monitored
9.2.2	Publicly accessible network jacks restricted
9.4.1	Media with cardholder data physically secured
9.4.1.1	Offline media backups stored securely
9.4.2	Media with cardholder data classified
9.4.3	Media sent outside the facility secured
9.4.4	Management approves media moved outside the facility
9.4.6	Hard-copy cardholder data destroyed when no longer needed
9.5.1	POI devices protected from tampering and substitution
9.5.1.1	Up-to-date list of POI devices maintained
9.5.1.2	POI device surfaces periodically inspected
9.5.1.3	Staff trained to spot POI device tampering
10.1.1	Requirement 10 policies and procedures documented and in use
10.2.1.2	Audit logs capture administrative actions
10.2.1.4	Audit logs capture invalid logical access attempts
10.2.1.5	Audit logs capture credential changes
10.2.2	Audit logs record required event details
10.3.1	Read access to audit logs limited
10.3.2	Audit log files protected from modification
10.3.4	File integrity monitoring on audit logs
10.4.1	Security event and critical system logs reviewed daily
10.4.1.1	Automated mechanisms used for audit log reviews
10.4.2	Logs of other system components reviewed periodically
10.4.2.1	Targeted risk analysis sets periodic log review frequency
10.4.3	Exceptions and anomalies from log reviews addressed
10.5.1	Audit log history retained for at least 12 months
10.6.1	System clocks synchronised
10.6.2	Systems configured to correct and consistent time
10.6.3	Time synchronisation settings and data protected
11.2.1	Authorised and unauthorised wireless access points managed
11.2.2	Inventory of authorised wireless access points maintained
11.3.1	Internal vulnerability scans performed
11.3.1.3	Internal scans after significant changes
11.3.2	External vulnerability scans by an Approved Scanning Vendor
11.3.2.1	External scans after significant changes
11.4.5	Penetration tests on segmentation controls
11.5.2	Change-detection mechanism deployed
12.1.1	Overall information security policy established and disseminated
12.1.2	Information security policy reviewed and updated
12.1.3	Security roles and responsibilities defined and acknowledged
12.2.1	Acceptable use policies for end-user technologies
12.3.1	Targeted risk analyses documented
12.6.1	Formal security awareness programme
12.6.3.1	Awareness training covers threats to cardholder data, including phishing
12.8.1	List of third-party service providers maintained
12.8.2	Written agreements with third-party service providers
12.8.3	Due diligence before engaging service providers
12.8.4	Service provider PCI DSS compliance monitored annually
12.8.5	Responsibility split between entity and service providers documented
12.10.1	Incident response plan in place
12.10.3	Incident response personnel available 24/7
A2.1.1	POS POI terminals using SSL or early TLS not susceptible to known exploits

Always check the official SAQ C text for the exact wording.

SAQ C FAQs

What is PCI DSS SAQ C?

PCI DSS SAQ C is the self-assessment questionnaire for merchants whose payment application system, such as a point-of-sale system, is connected to the internet but does not store account data electronically. It lists only the PCI DSS v4.0.1 requirements that apply to that environment, and is completed with an Attestation of Compliance that the merchant submits to its acquirer or the payment brands.

Who is eligible to use SAQ C?

SAQ C is for card-present or mail and telephone order merchants whose payment application system and internet connection sit on the same device or local network. The system must not connect to any other systems in the merchant environment, the location must not connect to other premises, no account data may be stored electronically, and any retained data must be on paper. It does not apply to e-commerce or service providers.

How many requirements are in SAQ C for PCI DSS v4.0.1?

The v4.0.1 SAQ C contains 122 requirements in Section 2, drawn from all 12 PCI DSS requirements, plus requirement A2.1.1 in Appendix A2 for POS terminals that still use SSL or early TLS. The October 2024 update removed requirement 10.3.3 from SAQ C because the PCI Security Standards Council judged it not relevant to SAQ C merchants.

What is the difference between SAQ C and SAQ C-VT?

SAQ C covers an internet-connected payment application system, typically a POS system, that is isolated from other systems. SAQ C-VT covers merchants who key transactions manually, one at a time, into a third-party hosted virtual payment terminal through a web browser on an isolated computer. SAQ C-VT is the shorter questionnaire because the merchant runs no payment application of its own.

What happens if a merchant does not complete SAQ C?

PCI DSS is enforced through contracts rather than law, so consequences come from your acquirer and the card brands. Depending on your agreement, they can include non-compliance charges, higher processing fees, liability for costs after a breach, or the loss of the ability to accept cards. Your acquirer decides which SAQ you must complete and how often to submit it.

Does SAQ C require vulnerability scans and penetration testing?

Yes. SAQ C includes internal vulnerability scanning, external scans by a PCI SSC Approved Scanning Vendor (requirement 11.3.2), rescans after significant changes, and penetration testing of segmentation controls under requirement 11.4.5 where segmentation is used to isolate the payment application system. Change detection under requirement 11.5.2 is also required.

How does SAQ C relate to ISO 27001?

SAQ C and ISO 27001 overlap heavily on access control, logging, malware protection, vulnerability management, supplier management and incident response, but ISO 27001 does not replace PCI DSS validation. Mapping controls once lets the same evidence, such as MFA settings or log retention, support both your SAQ C answers and an ISO 27001 information security management system.

Does OneClickComply support PCI DSS SAQ C?

SAQ C is mapped in OneClickComply's control library and is available on request rather than enabled by default today. Once enabled, it uses the same evidence collection, monitoring and policy tools as our other frameworks, and our in-house audit team can advise on eligibility. OneClickComply does not issue PCI attestations: you sign the Attestation of Compliance and submit it to your acquirer.

Related standards

All standards

Get SAQ C ready, not stressed

Automate controls, gather evidence continuously and stay audit-ready, all on one platform.