PCI DSS compliance levels: what they mean and how to qualify

PCI DSS compliance levels at a glance

Overview of merchant Levels 1-4

The Payment Card Industry Data Security Standard (PCI DSS) categorizes organizations into four merchant levels based on annual card transaction volume and overall risk exposure to determine proper validation requirements. Understanding your compliance level is critical for meeting obligations and maintaining proper security measures to keep the ability to process card payments.

Level 1 merchants process the highest volume of transactions, typically over 6 million transactions per year, and face the strictest validation requirements. Level 2 merchants manage high transaction volumes but lower than Level 1, typically between 1 and 6 million card transactions per year, and are validated through self-assessment with additional oversight. Level 3 merchants are generally mid-market e-commerce businesses that usually process between 20,000 and 1 million card transactions and are validated through self-assessment. Level 4 merchants are small businesses with the lowest transaction volumes, fewer than 20,000 e-commerce transactions or up to 1 million total transactions annually, and are validated with self-assessment with the simplest compliance obligations.

It is important to note that organizations that process or store card data on behalf of other organizations (service providers) follow a separate two-tier system for validation requirements that are distinct from merchant validation and depend on annual card transaction volume. Level 1 service providers process more than 300,000 transactions per year or store cardholder data for third parties. Level 2 service providers process fewer than 300,000 transactions annually.

Why your level matters

Your compliance level directly determines how your organization must validate compliance and the effort involved in maintaining it. Merchant level defines whether an organization should complete a Report on Compliance (ROC) through a Qualified Security Assessor or a Self-Assessment Questionnaire (SAQ), as well as the depth and type of compliance evidence it must maintain.

Higher merchant levels require more documented evidence and regular testing of security controls. For example, Level 1 merchants require a formal Attestation of Compliance (AOC) signed by a Qualified Security Assessor (QSA). While compliance is an ongoing obligation, merchant level also influences how often assessments are needed, such as quarterly network scans by an Approved Scanning Vendor. Card brands and acquiring banks may impose additional requirements based on compliance level. It is critical to correctly identify and maintain your compliance level to meet regulatory expectations, avoid penalties, and efficiently demonstrate required due diligence in protecting cardholder data.

How card brands determine your PCI DSS compliance level

Transaction volume thresholds

Card brands primarily use annual card transaction volume to establish the compliance level of an organization. These thresholds help determine what kind of validation and reporting structure an organization must follow to maintain PCI DSS compliance:

• Level 1: Merchants processing over 6 million transactions annually across all channels (in-store and online)
• Level 2: Merchants processing between 1 and 6 million transactions annually
• Level 3: Merchants processing between 20,000 and 1 million e-commerce transactions annually
• Level 4: Merchants processing fewer than 20,000 e-commerce transactions per year or up to 1 million total transactions across all channels

Level 1 merchants typically need annual on-site assessments by a Qualified Security Assessor (QSA), while lower levels require self-assessments using questionnaires (SAQ) and additional requirements such as quarterly network scans.

Breach and incident escalation

Annual transaction volume is the primary factor in establishing compliance level, but it is not the only one. Card brands reserve the right to manually escalate any merchant to Level 1 if they see a high risk to the payment ecosystem. If a merchant has suffered a data breach or security incident that compromised cardholder data, card brands can escalate the merchant to Level 1 regardless of transaction volume. Additionally, if the card brand identifies systemic vulnerabilities such as inadequate security controls, lack of compliance evidence, or a high-risk profile based on transaction patterns, industry type, or fraud history, they can mandate Level 1 validation requirements.

Role of the acquiring bank

While card brands set global security standards, acquiring banks have the ultimate authority in assigning PCI DSS level. The acquiring bank is responsible for ensuring an organization's proper merchant level and reviews actual transaction data and any card brand specific criteria to confirm compliance level. The acquirer collects and reviews compliance validation documents such as Attestation of Compliance, SAQ, or Reports on Compliance, and can impose additional requirements beyond minimum card brand standards. Different card brands such as Visa, Mastercard, Discover, and American Express have slightly different thresholds for PCI compliance levels. Merchants processing with multiple brands must follow all card brand compliance levels, and the acquiring bank mediates and enforces these requirements.

The four merchant levels: requirements and evidence

Level 1: highest assurance

Who qualifies: Merchants processing over 6 million card transactions annually across all channels combined (card present, e-commerce, mail or phone orders), including all transaction types such as purchases, refunds, credits, and authorizations. Additionally, any merchant that has experienced a data breach involving data compromise or has been designated as Level 1 by card brands based on risk assessments, earlier compliance violations, or a business model presenting substantial risk, regardless of transaction volume.

Validation requirements: PCI DSS Level 1 compliance represents the highest risk exposure and therefore requires the most rigorous validation:

Level 2: high volume without QSA by default

Who qualifies: Level 2 merchants such as mid-to-large e-commerce retailers, regional retail chains, and multi-location hotels and restaurants represent substantial risk but are allowed to self-validate unless otherwise directed by their acquiring bank.

Validation requirements:

Note: Acquiring banks or card brands may require a full ROC and QSA-led assessment for Level 2 merchants based on risk profile, security breach history, complex infrastructure, or poor compliance posture.

Level 3: mid-market e-commerce focus

Who qualifies: Merchants processing 20,000 to 1 million e-commerce transactions annually, particularly those with a significant online presence with Card-Not-Present (CNP) scenarios.

Validation requirements: Level 3 merchants typically include growing e-commerce businesses, SaaS companies with payment integrations, digital marketplaces, and subscription-based businesses. They must provide the following validations:

Level 4: small merchant baseline

Who qualifies: Merchants processing fewer than 20,000 e-commerce transactions or up to 1 million total transactions for all channels annually qualify for Level 4 compliance.

Validation requirements: Level 4 merchants typically include small businesses, local retail shops, single-location hotels and restaurants, and small online retailers. They must complete the following validations:

Common misconception: Level 4 merchants are obligated to meet all applicable PCI DSS requirements such as maintaining a secure network with firewalls and encryption technologies, protecting cardholder data, vulnerability management, access controls, continuous monitoring, and network testing. The level only affects the validation method, not the security obligations.

PCI DSS levels for service providers

Two-tier service provider model

Service providers play a significant role in the payment processing ecosystem because they store, process, or transmit cardholder data on behalf of merchants and can affect the security of cardholder data. While merchants are categorized into four compliance levels, service providers follow a two-tier classification model with strict validation requirements due to their shared responsibility role across multiple clients.

Level 1 service providers: Any organization that processes, stores, or transmits more than 300,000 card transactions annually on behalf of merchants, or any organization specifically designated by a payment card brand regardless of transaction volume. They must undergo an on-site audit performed by a Qualified Security Assessor (QSA) for the ROC, submit the AOC, perform quarterly ASV scans, and execute mandatory annual penetration testing. This category of service provider typically includes payment gateways, managed service providers, and cloud and hosting providers.

Level 2 service providers: Any organization that processes, stores, or transmits fewer than 300,000 total transactions annually and is not designated as a Level 1 service provider by card brands. Level 2 service providers must fulfill validation requirements through the annual SAQ D for Service Providers to address all PCI DSS requirements, submit the AOC, provide quarterly ASV scan reports, and execute annual penetration testing.

Who validates service providers

Service provider compliance can be validated through multiple mechanisms, depending on contractual obligations and risk considerations:

• Self-validation vs. QSA: Level 1 providers must be validated by an external QSA, whereas Level 2 providers may self-validate using SAQ D. However, their clients, merchants, or the card brands may still demand a QSA-signed ROC depending on the sensitivity of the service provided. In some cases, merchant QSAs will review service provider controls during the merchant's own PCI assessments due to the nature of shared responsibility
• Card brand compliance registries: Renowned card brands such as Visa and Mastercard maintain official lists of compliant service providers. Merchants are encouraged and often required to use only those service providers
• Merchant responsibility: Merchants must maintain a list of their service providers, have written agreements with them, and are responsible for verifying the compliance status of their service providers at least once a year. Failure to use a compliant service provider does not transfer the PCI obligation; merchants remain responsible for protecting cardholder data

Picking the right SAQ for your environment

SAQ selection matrix

Self-Assessment Questionnaires are validation tools defined by the PCI Security Standards Council (PCI SSC) to help merchants and service providers self-assess PCI DSS compliance. The correct SAQ depends on how merchants accept, process, transmit, and store cardholder data.

Tips to avoid scope creep

Choosing the wrong SAQ type can increase compliance burden, create security gaps, and cause audit rejections.

Map your payment flows: Document every point where cardholder data enters your organization, how it is processed and stored, and where it exits your environment. Identify all systems and services involved in data capture and processing, including backup systems, logs, or archives.

Understand cardholder data touchpoints: If any part of your infrastructure touches cardholder data, it may move the SAQ type from a lighter SAQ to SAQ D. If any system stores, processes, or transmits cardholder data, it can influence the security of cardholder data. Also consider systems that can access the cardholder data environment and systems that are on the same network segment as the CDE.

Use segmentation: Proper network and system segmentation can reduce the scope of PCI DSS, reducing the effort required for compliance. Use firewalls and VLANs to isolate payment terminals or POS systems from the rest of the corporate network. Always document changes and regularly validate effectiveness to support ongoing compliance.

Consult a QSA: If a merchant offers both retail store and e-commerce services, they may need to complete multiple SAQs or a single SAQ D. It is always a good idea to involve a QSA who can help prevent over- or under-compliance efforts.

From scope to evidence: what auditors expect per level

Scoping and documentation

Auditors evaluating PCI DSS compliance focus first on scope validation and foundational documentation because all relevant evidence depends on an exact definition of the Cardholder Data Environment (CDE).

Accurate CDE scoping: Auditors require clear identification of all systems, networks, and locations that store, process, or transmit cardholder data. Clear boundaries of the CDE must be documented. Which systems are in scope, such as point-of-sale terminals, payment gateways, and databases, and which systems are out of scope must have exclusion evidence such as network segmentation and firewall rules. CDE scoping must be reviewed at least annually and after every significant change in the CDE or associated infrastructure.

Data flow diagrams: DFDs must show end-to-end cardholder data movement from entry points to internal movement, storage, and exit points. DFDs must have high-level and detailed data flows with brief descriptions, marking encrypted and unencrypted routes and mapping to real devices with IP addresses and hostnames.

Network segmentation documentation: If certain servers and devices are claimed as out of scope, technical evidence must be included in documentation that the CDE is not affected. For example, firewall configurations that restrict network traffic between CDE and non-CDE networks, VLAN configurations that logically separate networks, and annual penetration testing results.

System inventory: A complete, up-to-date inventory of all IT assets, such as servers, workstations, network devices, and terminals, with installed operating systems, applications, versions, and patch levels must be documented for anything that could affect the CDE. Change management mechanisms should be implemented to show logs as evidence for system updates, patches, and hardware decommissioning.

Time synchronization: All systems must have accurate and synchronized time using Network Time Protocol (NTP), as time synchronization is critical for log correlation and forensic analysis. Documentation should contain NTP server configuration, time source, and synchronization frequency settings with supporting logs to show successful time synchronization.

Key artifacts by level

Different reporting levels require different types and depths of evidence, but the core artifacts stay consistent; only the validation methods vary based on merchant level. Following are the common artifacts auditors expect across all levels:

• Information security policies: Comprehensive documented security policies covering all applicable PCI DSS requirements, including acceptable usage policy, data retention policy, encryption key management mechanisms, remote access policy, change management policy, physical security, and incident response procedures
• Access control documentation: User access policies and reports showing who has access to what systems and data, role-based access control (RBAC) implementation, and whether roles and permissions follow the principle of least privilege. Multi-factor authentication (MFA) enforced on all access paths in the CDE, privileged access management mechanisms with session recording, and complete audit trail of administrative access to the CDE
• File integrity monitoring (FIM) logs: Evidence that critical system files and configurations are monitored for unauthorized changes, including FIM alerts and reports, baseline configuration definitions, and investigation records for legitimate changes
• User access reviews: Periodic reviews of user accounts and administrative accounts, including reports signed off by department heads, remediation evidence for excessive privileges, and terminated user access removal
• Vulnerability scan results: Quarterly reports by internal scanning tools and external Approved Scanning Vendors (ASV) that show no high-risk vulnerabilities were found, or that vulnerabilities were patched and rescans show vulnerabilities were resolved
• Penetration test reports: Formal reports of internal or external penetration testing results, including network layer testing, application layer testing, and segmentation validation. Findings should clearly identify vulnerabilities with severity ratings and remediation validations after retesting
• Incident response procedures: A documented plan for handling security incidents, including how to classify incidents, escalation paths, response team roles and responsibilities, communication protocols, forensic evidence collection procedures, and business continuity measures
• Change management records: Complete audit trail of changes made to systems and applications, including change request forms, risk assessment forms, approval records, post-implementation validation, and emergency procedure execution justifications

Netwrix audit and compliance capabilities help organizations generate evidence for all PCI DSS requirements, from accurate scope definition and data discovery to access control and multi-factor authentication, privileged access management, and extensive logging and continuous monitoring. Automated data discovery capabilities find and classify Primary Account Numbers (PAN) and other sensitive cardholder data. Data minimization helps identify obsolete or over-retained cardholder data to support secure deletion processes. Regular user access review campaigns automate access attestation to limit CDE access by enforcing the principle of least privilege. Netwrix solutions capture comprehensive audit trails of user activity, system changes, and access events with capabilities to export these logs and compliance reports to meet PCI DSS requirements.

How levels change: triggers to move up or down

Triggers for level changes

PCI DSS levels of compliance are not static; they can move up and down based on business activities, risk events, or decisions made by card brands or the acquiring bank. Merchants and service providers' compliance levels are primarily determined by transaction volume per year. If a marketing campaign during the holiday season increases transaction volume dramatically and crosses the 6 million transaction mark, the acquiring bank will notify the merchant that they must now meet PCI DSS Level 1 compliance requirements reporting.

Similarly, if the transaction volume of a merchant decreases significantly, they might be eligible to downgrade their compliance level, reducing the complexity and cost of audit. Mergers and acquisitions can combine transaction volumes of multiple merchants, and new payment channels or brands inherited through acquisition can affect total transaction count.

Any security incident or data breach can trigger strict compliance action from card brands or the acquiring bank, increasing the level and possibly requiring forensic investigation with remediation efforts before the compliance level can be restored to normal. If a merchant starts using a new third-party service provider or changes outsourced payment processing, it can affect the compliance level. For example, moving from an outsourced payment page to a partially hosted model can raise compliance obligations, while moving from an in-house payment management service to outsourced payment processing can simplify compliance obligations. Card brands reserve the right to reclassify any merchant or service provider based on high fraud rates, repeated non-compliance, or a high-risk business model.

Governance best practice

Compliance is not a one-time event; it is a continuous process. To avoid sudden failures, organizations must integrate PCI compliance level required controls and policies into their business governance model.

Avoid surprises: By tracking transaction volume every quarter or monthly, merchants can predict when they might hit the next level before it happens. Maintain evidence of transactions for reclassification, such as data flow diagrams of new channel additions, incident logs, and remediation records in case of a security breach event.

Validation planning: Moving from Level 2 to Level 1 requires hiring a Qualified Security Assessor (QSA) and incurs technical costs of securing the CDE. These changes require significant and efficient planning to ensure proper budgeting and that resources, such as staff and equipment, are distributed correctly.

Proactive communication: Maintain a transparent relationship with your acquiring bank, which helps in negotiating timelines of security controls implementation if a compliance level change occurs unexpectedly. Always notify the acquirer before launching new e-commerce platforms, tokenization changes, or payment gateway replacements.

Common pitfalls by level and how to avoid them

Level 1 pitfalls

Weak privileged access management: Level 1 cardholder environments and associated infrastructure require strict access control to reduce the attack surface. Comprehensive access management is a key factor in the security of cardholder data. Common issues include usage of shared admin accounts, no MFA implemented for administrative or service accounts and remote access, excessive standing privileges, lack of user access review campaigns, role-based access control (RBAC) that does not follow the principle of least privilege, and lack of monitoring on admin activities.

Incomplete logging: Logs serve a critical role in forensic investigation of data breach events and in validating security controls efficiency. Common issues include missing authentication trails such as important events of authentication failure, privilege escalation, or data access. Logs are collected but not aggregated in a centralized platform for automated analysis and storage. Logs are present but cannot distinguish event trails based on unique IDs tied to particular accounts.

Segmentation effectiveness: Common issues include networks labeled as out of scope without evidence that they cannot access the CDE, no annual penetration test reports present, and incorrect firewall rules that can allow network access.

Change management evidence: Common issues include records of emergency changes implemented without proper approval, PCI impact not assessed post-implementation, upgrades or replacement of hardware and software without proper backup, and no security posture evaluation report after legitimate change management events.

Level 2-4 pitfalls

Wrong SAQ selection: Merchants often choose the easiest or shortest Self-Assessment Questionnaire (SAQ) without realizing that their environment actually requires more detailed and relevant technical assessments. Choosing an incorrect SAQ type leads to incomplete compliance assessment, especially when payment flows are misunderstood and incorrectly represented in documentation. Always map complete payment card data flows before SAQ selection, document where PANs are transmitted, processed, and stored, and verify third-party processor integration methods. When in doubt, always consult the SAQ selection guide or hire a QSA to help with the SAQ selection process.

Missed quarterly ASV scans: Vulnerability scans must be performed by an Approved Scanning Vendor (ASV) every 90 days. Merchants assume that it is an annual task or do not remediate the vulnerabilities identified in the scan within the required time limit to maintain compliance status. Always schedule scans for the first month of every quarter to allow ample time to remediate any vulnerabilities identified and rescan after remediation efforts to achieve the passing report before the same quarter ends. Set calendar reminders 2 to 3 weeks before the due date, track remediation deadlines (30 days for high-risk vulnerabilities), maintain documented evidence of scan results and remediation, and use only PCI SSC-approved scanning vendors for quarterly scans.

PAN in logs and exports: Primary Account Number (PAN) information can leak into places it should not be stored, such as application logs, customer service chat transcripts, audio call recordings, CRM exports, or CSV exports used by the accounting department. Use automated data discovery tools to scan infrastructure for unencrypted PAN at least once a year. Ensure that software solutions mask card numbers, showing only the first or last 4 digits. Review export functions and reporting tools to truncate PAN, train developers on secure coding practices to avoid sensitive information storage in debug logs, and regularly review logs to identify any unencrypted sensitive information.

Where Netwrix accelerates PCI DSS across all levels

Requirement 3: protect stored cardholder data

Netwrix Data Security Posture Management solutions help organizations perform automated data discovery and classification across hybrid environments to find Primary Account Numbers (PAN) and other sensitive cardholder data. Data classification is done using compound term processing and statistical analysis rather than simple keyword matching. Automated redaction capabilities mask card digits when there is no business need to display them. Data minimization and retention tracking demonstrates that only necessary cardholder data is stored and unnecessary data is not retained. Automated workflows allow organizations to quarantine sensitive data in insecure locations and help remove permissions from global access groups.

Requirements 7 and 8: access control and authentication

Netwrix Identity Governance solutions provide visibility into user, service accounts, and admin accounts permissions across premises and cloud platforms. Privilege attestation reporting certifies user privileges to enforce least privilege and ensure that access to the cardholder environment is strictly role-based and documented. Identity governance solutions automate the lifecycle of user identities to ensure that every person has a unique ID, all activities are tracked with that unique ID, and access can be instantly revoked in case of suspicious activity or termination. Privileged account monitoring capabilities allow organizations to monitor and record privileged sessions in the CDE to detect any unauthorized changes or data exfiltration attempts.

Requirement 10: logging and monitoring

Netwrix Auditor provides unified auditing and activity monitoring capabilities across hybrid infrastructure including file systems, Active Directory, and cloud services. Change tracking solutions integrate file integrity monitoring (FIM) features to detect unauthorized changes to critical system files and security configurations and generate alerts when log data is modified. Netwrix solutions provide exportable, audit-ready logs and reports that serve as evidence in Attestation of Compliance and Report on Compliance submissions, significantly reducing audit preparation time.

Requirements 6 and 11: secure systems and testing

Netwrix Change Tracker continuously tracks system configuration, detects misconfigurations that deviate from security baselines, and ensures that servers, endpoints, and network devices always stay secure. Change tracking with before-and-after configuration values shows what changed, when, and by whom to provide a comprehensive evidence-based report on the CDE. These evidence-based reports support secure system maintenance, verification of consistent configuration, and continuous testing to satisfy PCI scanning and testing requirements.

PCI DSS Level 1 deep dive (for enterprises and service providers)

Additional rigor for Level 1

Level 1 merchants and service providers face a higher level of scrutiny because they represent the highest risk to the payment ecosystem. At Level 1, organizations are expected to go beyond the 12 core requirements of PCI compliance; they must implement enhanced controls, documented discipline, and continuous monitoring to fulfill validation requirements properly.

Sampling strategy considerations: When an enterprise has hundreds or thousands of infrastructure components, a QSA cannot evaluate every single one. PCI DSS does not mandate one specific sampling formula, but Level 1 audits inherently require representative sampling across the most critical systems, such as the CDE, segmentation controls, access control, and logging. Standardize sampling by grouping systems with identical configuration. Sampling must include every business process and geographic location that handles cardholder data. Maintain sampling method documentation including population definition, selection criteria, statistical justification, and traceability of the sample to specific PCI requirements with evidence to demonstrate completeness to the QSA. If sampling reveals failure, expand testing or evaluate the entire system class. Level 1 entities should avoid assuming a single representative system covers the whole class.

Expanded penetration testing scope: Level 1 entities must include internal networks, perimeter networks, VPN, cloud infrastructure, APIs, and endpoints annually and in case of any significant change in the network, such as new hardware addition, software upgrades, or migration to a new cloud platform. At minimum, targeted penetration testing is required again. Organizations must prove network segmentation with evidence such as firewall rules and VLAN isolation. Authentication and authorization processes must be assessed from both internal user and external attacker perspectives. After remediation, targeted re-testing is needed to confirm that vulnerabilities are resolved.

Evidence repository best practices: A Level 1 audit can require thousands of pieces of evidence. Organizations must move away from spreadsheets to a proper Governance, Risk and Compliance (GRC) tool to automate the entire process with a centralized data repository. Use automated tools to generate baseline artifacts for every requirement, such as policies, configuration files, logs, and procedures. Organize evidence according to the 12 PCI DSS requirements and sub-requirements. Maintain dated versions of all configurations and policies, role-based access permissions details, quarterly scan reports, log analysis, file integrity monitoring alerts, firewall rules, and encryption implementations.

Continuous compliance: Unlike older point-in-time compliance, PCI DSS emphasizes continuous security. For Level 1 organizations, continuous monitoring must be built into every business process. Apart from quarterly external ASV vulnerability scanning and internal vulnerability scans, logs must be reviewed daily or at least twice a week with implementation of SIEM tools for aggregate analysis. Real-time alert generation mechanisms should be deployed for file integrity monitoring. A formal change management process with documented approval must be in place for every change in the CDE. On a monthly basis, user access review campaigns must be triggered, firewall and router rules must be reviewed, and service provider compliance should be validated.

Maintain organized documentation: Organizations must not wait for audit season; they must create and update documentation periodically for all 12 PCI DSS requirements throughout the year with proper version control and summary change logs. A QSA's first task is often scope discovery. If they find a system or requirement that was not documented, the audit will most likely be delayed or fail.

Working with QSAs

Level 1 validations require an external Qualified Security Assessor (QSA). However, the QSA should not be viewed as an auditor but rather as a partner in reducing risk. Successful engagement requires preparation in advance and efficient collaboration to maximize output from this process.

Prepare evidence in advance: Organizations must conduct internal assessments using the ROC template to identify gaps. Create a checklist mapping each requirement to corresponding evidence. Prepare a complete and up-to-date asset inventory with data flow diagrams, and scoping documentation must include detailed network segmentation to justify scope.

Establish clear communication channels: Appoint a single point of contact for QSA coordination. Identify subject matter specialists for each requirement domain for details. Set up preferred communication channels such as email, video conferencing, and documentation portals. Run pre-audit walkthrough sessions, define escalation paths for disputes or delays in evidence requests, and establish turnaround time for evidence requests, such as 48 or 72 hours.

Address findings promptly: If a QSA finds a gap during the audit, try to remediate it immediately while they are on site. This can often result in a successful pass in the final ROC rather than a non-compliance status. The remediation process should be formal, including confirming receipt that findings are understood, root cause analysis of why non-compliance occurred, and documented actions that were taken to remediate the issue with evidence such as screenshots, configuration details, and new policies.

Next steps: validate your PCI DSS compliance level

Action plan

Understanding your merchant or service level is critical for PCI DSS compliance. Once the level is evaluated correctly, the compliance path forward is about validation, evidence, and continuous monitoring.

Ready to streamline PCI DSS compliance at any level? Visit the Netwrix PCI DSS solution page to see mapped report samples and discover how our data security and audit capabilities accelerate your validation.