BlueKey IT helps businesses that store, process, or transmit payment card data meet the Payment Card Industry Data Security Standard. We reduce the systems in scope, implement the technical controls, and prepare the documentation and evidence your acquirer expects.
Real reviews from real customers. See why businesses choose BlueKey IT.
Read All ReviewsMost PCI DSS work comes down to two questions: where does card data go in your business, and what protects it along the way? BlueKey IT maps the flow, shrinks the scope where possible, implements the technical controls, and keeps the evidence your acquirer expects.
Scope reduction · Network and endpoint controls · Evidence and documentation · 200+ customers and 6,000+ endpoints managed
The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council and applies to any business that stores, processes, or transmits payment card data, and to the vendors that support them. It is not a law. It is enforced through the agreements between merchants, acquiring banks, and card brands, which is why your acquirer, not the Council, tells you how you validate.
The standard has 12 requirements grouped into six goals. Here is the full set, with how BlueKey IT supports each goal.
| PCI DSS goal and requirements | How BlueKey IT helps |
|---|---|
| Build and maintain a secure network and systems 1. Install and maintain network security controls 2. Apply secure configurations to all system components | Firewall management, network segmentation, and hardened configurations |
| Protect account data 3. Protect stored account data 4. Protect cardholder data with strong cryptography during transmission over open, public networks | Encryption, secure remote access, and help removing card data you do not need to keep |
| Maintain a vulnerability management program 5. Protect all systems and networks from malicious software 6. Develop and maintain secure systems and software | Endpoint protection, patch management, and vulnerability scanning |
| Implement strong access control measures 7. Restrict access by business need to know 8. Identify users and authenticate access 9. Restrict physical access to cardholder data | Role-based access, MFA, account reviews, and workstation and device security |
| Regularly monitor and test networks 10. Log and monitor all access to system components and cardholder data 11. Test security of systems and networks regularly | Audit logging, 24/7 monitoring, and regular internal and external vulnerability scans |
| Maintain an information security policy 12. Support information security with organizational policies and programs | Policies, security awareness training, risk analysis support, and incident response documentation |
Version status as of October 2026: PCI DSS v4.0.1, published in June 2024, is the current version. It has no new or deleted requirements compared with v4.0. v4.0 was retired on December 31, 2024, and the 51 requirements that v4.0 marked as future-dated became mandatory on March 31, 2025. We are not aware of a published successor version, and we will update this page if that changes.
Merchants validate with a Self-Assessment Questionnaire, or SAQ, chosen by how they accept payments. The PCI Council defines the eligibility criteria for each one, and your acquirer or card brand decides which you must complete. This table summarizes the merchant SAQ types. Use it to start a conversation with your acquirer, not to self-select a form.
| SAQ | Typically fits | Notes |
|---|---|---|
| A | Card-not-present merchants (e-commerce or mail and telephone order) that fully outsource all account data functions to PCI DSS validated third parties | No electronic storage, processing, or transmission of account data on your systems or premises. Not for face-to-face payments |
| A-EP | E-commerce merchants that partially outsource payment processing, where the website does not receive account data but can affect the security of the payment transaction or page | No electronic storage, processing, or transmission of account data on your systems |
| B | Merchants that use only imprint machines or standalone dial-out terminals | No electronic storage of account data. Not for e-commerce |
| B-IP | Merchants that use only standalone, PCI-listed payment terminals with an IP connection to the processor | No electronic storage of account data. Not for e-commerce |
| C-VT | Merchants that key card data one transaction at a time into a validated third-party virtual terminal from an isolated computer | No electronic storage of account data. Not for e-commerce |
| C | Merchants with payment application systems connected to the internet | No electronic storage of account data. Not for e-commerce |
| P2PE | Merchants that use only a validated, PCI-listed point-to-point encryption solution | No access to clear-text account data and no electronic storage |
| SPoC | Merchants that use a commercial mobile phone or tablet with a secure card reader from a PCI-listed SPoC solution | No access to clear-text account data and no electronic storage. Not for e-commerce or mail and telephone orders |
| D (merchant) | All merchants that do not fit the other forms, including e-commerce merchants that accept card data on their own website and merchants that store card data electronically | The most extensive questionnaire. Many requirements apply |
A note on e-commerce: in January 2025 the Council updated SAQ A so that merchants no longer validate requirements 6.4.3 and 11.6.1 on that form. Instead, the eligibility criteria now require the merchant to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. Confirm with your acquirer how this applies to you.
The cardholder data environment, or CDE, includes the system components, people, and processes that store, process, or transmit cardholder data, plus any system components that do not handle that data but have unrestricted connectivity to those that do. Every system in scope has to meet the requirements that apply, so the fewer there are, the less there is to secure, document, and test.
Many businesses keep full card numbers in spreadsheets, email, notes fields, or old scans. Finding and removing that data is often the highest value step, because data you do not store cannot be stolen.
Hosted payment pages, validated point-to-point encryption, and tokenization keep card data off your systems. They reduce scope, but they do not remove your obligation. How you integrate them still determines which SAQ applies.
Payment terminals and systems that touch card data should sit on their own network segment with firewall rules that allow only what is needed. Segmentation is the main technical way to keep the rest of your network out of scope, and it has to be tested to count.
A data flow diagram showing how card data enters, moves through, and leaves your environment is the foundation of every assessment. Requirement 12.5.2 expects the scope to be documented and confirmed at least every 12 months and after significant change.
Many requirements that arrived with v4.0 were future-dated and became mandatory on March 31, 2025. If your last assessment predates that, check these first. This is a selection, not the full list.
| Requirement | What it expects | What it means in practice |
|---|---|---|
| 5.4.1 | Processes and automated mechanisms to detect and protect personnel against phishing | Email filtering and anti-phishing controls on top of user training |
| 6.4.3 | Payment page scripts are managed: authorized, with integrity assured and an inventory with written justification | A script inventory for e-commerce payment pages and a way to detect changes |
| 8.3.6 | Minimum password length of 12 characters, or 8 if the system cannot support 12, with numeric and alphabetic characters | Updated password policy and system settings |
| 8.4.2 | Multi-factor authentication for all access into the CDE | MFA is required for all access into the CDE, not just remote or administrative access |
| 10.4.1.1 | Automated mechanisms for audit log reviews | Centralized logging with automated review and alerting rather than manual log reading |
| 11.3.1.2 | Authenticated internal vulnerability scans | Internal scans run with credentials so they see missing patches and misconfigurations |
| 11.6.1 | A change and tamper detection mechanism for HTTP headers and payment page content as received by the consumer browser | Monitoring of what the customer browser actually receives on your payment page |
| 12.3.1 | A targeted risk analysis for requirements that allow flexible frequency | Written analysis explaining how often you perform activities such as log reviews and scans |
| 12.6.3.1 | Security awareness training that covers phishing and social engineering | Training content updated to include phishing and social engineering |
Other requirements also carried the March 31, 2025 date, including items in requirements 3, 4, 7, 8, 9, 10, and 12. Your assessor or acquirer can confirm which apply to your environment.
Requirement 11 is where many small merchants fall behind, because the evidence has to be dated and repeated.
Requirement 11.3.2 calls for external vulnerability scans at least every three months, performed by a PCI Council Approved Scanning Vendor, with vulnerabilities resolved and passing results documented, and rescans as needed. Whether you need them depends on your SAQ type, so confirm with your acquirer.
Internal scans look from inside your network. Requirement 11.3.1.2 requires authenticated scans, which use credentials so the scanner can see missing patches and unsafe settings. We schedule recurring scans through our vulnerability scanning service, track findings to closure, and keep the reports.
Penetration testing applies to environments where it is required, such as SAQ D merchants and service providers. We help scope and perform tests through our penetration testing service, with the report provided by a third party, coordinate access, and track remediation of what it finds.
| Evidence | What it shows |
|---|---|
| Completed SAQ and Attestation of Compliance, or Report on Compliance | The assessment result for your validation type, signed by an authorized officer |
| Data flow diagram and network diagram | Where card data enters, moves, and is stored, and where segmentation sits |
| Inventory of system components | Every device, server, application, and service that is in scope |
| Firewall and configuration standards | How network controls and system builds are defined and reviewed |
| Vulnerability scan reports | Passing external ASV scans if required, and internal scan results with remediation records |
| Access and MFA records | Who can reach the CDE, how they authenticate, and how access is reviewed and removed |
| Logs and review records | Log retention and evidence that logs are reviewed and alerts acted on |
| Policies and risk analysis | Written security policies, the annual risk assessment, and targeted risk analyses |
| Training records | Completion records for security awareness training including phishing content |
| Incident response plan | A written plan with roles and steps, tested at least annually |
We map how your business takes payments, reduce what is in scope where possible, and identify the questionnaire or report that fits you.
We implement the technical controls and write the policies and records that support them.
We monitor, patch, and scan on a schedule, keep evidence current, and support you through your annual validation.
Diagrams and inventories that show what is in the CDE and why.
Findings mapped to the requirements that apply, with owners and status.
Rule sets, change records, and segmentation test results where used.
Internal scan results with remediation tracking, and support coordinating external scans.
Reports showing who has access and how it is authenticated and reviewed.
Security policies and the written analyses that PCI DSS expects.
Awareness training with phishing content and completion reports.
Help completing the SAQ and Attestation of Compliance with your acquirer.
Support requests follow our standard help desk response times: 1 business hour for critical issues, 2 hours for high, 4 hours for medium, and 8 hours for low priority requests.
Full card numbers sit in email, spreadsheets, notes fields, or scanned forms.
Payment terminals, point of sale systems, and office computers share one network with no segmentation.
Remote access or administrative accounts into payment systems rely on passwords alone.
Vulnerability scans are run occasionally and nothing shows quarterly or remediation cadence.
The data flow diagram was drawn once and no one reviewed it when the payment process changed.
Policies exist, but do not match how the business takes payments or handles incidents.
Merchants and service providers that store, process, or transmit payment card data, including medical practices, dental offices, accounting firms, and other businesses that take cards in person, online, or by phone. Formal validation follows your acquirer and card brand rules. We prepare your environment and evidence and work with whoever validates it. Have an in-house IT team? See co-managed IT.
Scoping assessments and remediation projects are quoted individually. Ongoing PCI DSS safeguards can be added to a managed IT or co-managed IT plan.
No. PCI DSS is an industry standard maintained by the PCI Security Standards Council and enforced through the contracts between merchants, acquiring banks, and card brands. Consequences of non-compliance, such as fees or added liability after a breach, depend on your agreements. Some state laws also reference PCI DSS.
PCI DSS v4.0.1, published in June 2024, is the current version. It is a limited revision of v4.0 with clarifications and corrections and no new or deleted requirements. v4.0 was retired on December 31, 2024, and the requirements that v4.0 marked as future-dated became mandatory on March 31, 2025.
The cardholder data environment, or CDE, is made up of the system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data, plus system components that do not handle that data but have unrestricted connectivity to those that do. Reducing and segmenting the CDE is the most effective way to reduce the work of compliance.
It can reduce your scope, especially when card data never touches your own systems, but it does not remove the obligation. You may still need to complete a Self-Assessment Questionnaire, and the way you integrate the processor affects which questionnaire applies. Ask your acquirer which validation applies to you.
It depends on how you accept payments and what your systems do, not on your size alone. The merchant forms are SAQ A, A-EP, B, B-IP, C-VT, C, P2PE, SPoC, and D, and the PCI Council defines the eligibility criteria for each. We help you confirm the right one with your acquirer and prepare the evidence behind it.
An ASV scan is an external vulnerability scan performed by an Approved Scanning Vendor, which is a company approved by the PCI Security Standards Council. Requirement 11.3.2 calls for external scans at least every three months, with vulnerabilities resolved and passing results documented. Merchants that qualify for certain SAQs may not need them, so confirm with your acquirer.
The Attestation of Compliance, or AOC, is the official PCI Council form used to attest to the results of an assessment, whether you completed a Self-Assessment Questionnaire or a Report on Compliance. Your acquirer or card brand typically asks for it.
No. Every business that accepts card payments is expected to protect card data. Your acquirer and card brands decide how you validate, and smaller merchants usually complete a Self-Assessment Questionnaire.
Smaller merchants usually self-assess with an SAQ and sign an AOC. Larger merchants and service providers may be required to use a Qualified Security Assessor or a qualified internal assessor to produce a Report on Compliance. The PCI Security Standards Council sets the standard but does not certify merchants.
No. Compliance is validated through your acquirer and card brand process. We implement and document the technical controls, prepare your evidence, and work with your acquirer or assessor.
Yes, but they may be lighter. Merchants that use only standalone terminals may qualify for SAQ B, B-IP, or P2PE depending on how the terminal connects and whether it uses a validated point-to-point encryption solution. Your network and any devices on it can still affect eligibility, so confirm with your acquirer.
Yes. Many businesses add PCI DSS support to a managed or co-managed IT plan so network security, patching, monitoring, backups, and documentation are handled in one place.
Tell us how your business takes payments. We will explain what PCI DSS means for your environment and put together a clear plan and quote.
Related compliance frameworks: CMMC compliance, HIPAA IT compliance, FTC Safeguards Rule compliance, SOC 2 readiness, and ISO 27001 readiness. See also cybersecurity insurance readiness, cybersecurity and compliance, endpoint security, backup and disaster recovery, and Microsoft 365 and Google Workspace.
Last updated: October 2026. Based on PCI DSS v4.0.1 and PCI Security Standards Council guidance.
