Payment Card Industry Data Security Standard (PCI DSS) compliance is an annual requirement for any organisation that accepts, processes, or transmits cardholder data. Depending on how your organisation takes payments using Spektrix, your compliance responsibilities typically involve completing a Self-Assessment Questionnaire (SAQ) and, for web payments, conducting external vulnerability scans.
The current version of PCI DSS is 4.0.1. PCI DSS 4.0 was published in 2022, with version 4.0.1 following in 2024 to clarify and correct parts of the standard. Version 4 introduced additional requirements compared to earlier versions, for example ASV scanning which we’ll cover later in this article.
WARNING: This article does not provide formal PCI DSS compliance advice or legal counsel. Spektrix is not a Qualified Security Assessor (QSA) and cannot confirm which requirements apply to your organisation.
To view Spektrix’s PCI DSS compliance and documentation, visit the Spektrix Security and Compliance page.
What is PCI DSS compliance?
PCI compliance is adhering to a set of requirements established by the Payment Card Industry (PCI) to ensure that all companies that process, store or transmit card data maintain a secure environment.
The rules which you must adhere to increase in number and complexity depending on the scale and risk profile of your organisation. Your organisation’s PCI requirements will depend on your unique circumstances. The more ways you take card payments the more your risk for data loss is increased?
PCI DSS compliance is mandated by the card schemes (for example, Visa, Mastercard) and enforced throughout the payment chain of:
| Body | Definition | Example |
| Card schemes | The financial network processing card schemes | Visa, Mastercard |
| Issuing bank | The body that issues cards | High street banks |
| Acquirer | Enables merchants to accept card payments | Adyen |
| Payment processor | Processes card transactions | Adyen |
| Payment Service Provider (PSP) | Provides payment services to merchants | Adyen |
| Merchant | The body selling goods or services | Your organisation |
Each body in the payment chain must also meet their own PCI DSS requirements. Requirements will vary for each body depending on the volume of transactions. For example, Adyen and Spektrix hold PCI DSS Level 1 compliance which is based on the number of transactions processed.
Organisations who use Spektrix may have a lower compliance level as fewer transactions are processed through each individual system.
How often should I review my organisation’s PCI DSS compliance?
You should also review your PCI DSS scope annually and whenever you make a significant change to how you take or handle payments. For example:
- Changing your website payment journey
- Using a new payment provider or terminal
- Enabling call recording or transcription
A change may affect which people, processes and systems are in PCI DSS scope, or which Self-Assessment Questionnaire (SAQ) you need to complete.
What PCI DSS terms do I need to know?
Throughout this article we’ll refer to some of the key terminology used in PCI DSS compliance:
-
Attestation of Compliance (AOC): A formal declaration of the scope and result of a PCI DSS assessment. An AOC may accompany either a self-assessment or an independent assessment.
For details on reading an assessment report, see How do I read an Attestation of Compliance (AOC)?.
-
Approved Scanning Vendor (ASV): An organisation which is approved to conduct external vulnerability scans that comply with PCI DSS requirements.
Take a look at What is an Approved Scanning Vendor? for further information.
-
Cardholder Data Environment (CDE): The people, processes, and technologies that store, process, or transmit payment card data.
-
Cardholder Data (CHD): The card number, cardholder name, expiry date and service code.
-
PCI DSS: Payment Card Industry Data Security Standard.
-
PCI SSC: Payment Card Industry Security Standards Council is a global open forum that develops, manages, and promotes security standards for safe payment card transactions worldwide.
-
Payment Service Provider (PSP): The third party providing payment services. For example, Adyen, Opayo, Worldpay.
-
Qualified Security Assessor (QSA): Qualified PCI DSS experts providing audit and consultancy services.
-
Self Assessment Questionnaire (SAQ): The checklist that organisations that qualify for self assessment complete. There are multiple types.
-
Sensitive Authentication Data (SAD): Information such as the card security code, PIN or full magnetic-stripe or chip data. It must not be stored after authorisation.
-
Shared Responsibility Matrix (SRM): The document that lists who is responsible for different elements of PCI DSS, you or a service provider.
Take a look at What is the Shared Responsibility Matrix? for further information.
- Third Party Service Provider (TPSP): A third party that provides services that are part of your Cardholder Data Environment (CDE). For example, Spektrix is a TPSP.
To view more terminology, take a look at the Glossary of Payment and Information Security Terms.
What is a Self-Assessment Questionnaire (SAQ)?
The Self-Assessment Questionnaire (SAQ) is the form your organisation (also referred to as the merchant in this context) completes annually to demonstrate PCI DSS compliance.
There are different SAQ types depending on how you handle card data. The SAQ type you need determines how many security requirements you must meet and therefore how much work, cost, and risk compliance involves.
Self-assessment is most commonly available to organisations that process fewer than six million card transactions a year, although this figure is only a guide. Eligibility also depends on your payment channels, how you handle card data and the requirements set by your payment provider or acquirer. The SAQ you need will depend on the details of your operations, and in some cases you may be required to complete more than one.
The table below provides an overview of the SAQ types that are most likely to apply to your organisation. This information is simplified and does not include all of the SAQ types, take a look at the PCI Security Standards website for further information.
| SAQ | When does it apply? |
Approx Requirements (Number of clauses in scope in the SAQ). |
Practical Impact |
| SAQ A |
All cardholder data functions are outsourced to PCI-compliant third parties. The merchant's systems never receive, process, or transmit card data. For organisations who use Spektrix, this applies to e-commerce (where the customer enters card details into Adyen's hosted iframe on your website). |
~30 |
Lightest burden. This mostly applies when you haven't done anything to bring card data into your environment. Although there are minimal technical controls, there are requirements for quarterly ASV scanning of web servers. |
| SAQ B-IP |
You use only standalone, PCI-approved physical payment terminals connected via IP. No card data is transmitted or stored on a PC. If you use Chip and PIN via Spektrix Payments, you may need to complete this SAQ. |
~80 |
Moderate burden. This mainly focuses on the security of payment terminals, the network used and the processes for managing them. Using a terminal does not automatically determine the SAQ for your whole organisation. |
| SAQ C-VT |
You key card data into a web-based virtual terminal (browser) on a computer. No electronic storage of card data. |
~80 |
Moderate-to-high burden. Your computer, browser, and network are in PCI DSS scope. This requires patching, anti-malware, and access controls on the machines used for payment entry. |
| SAQ D | Catch-all for anyone who doesn't fit the other categories. Handles or stores card data in any other way. | ~300+ |
Heaviest burden. This is a full PCI DSS assessment. It includes penetration testing, network monitoring, and extensive documentation. This often requires professional help from a QSA or other consultancy. Most organisations using Spektrix Payments will not need to complete this SAQ, provided that card data is not brought into their wider systems or stored electronically. |
What is an Approved Scanning Vendor (ASV)?
An Approved Scanning Vendor (ASV) is an organisation certified by the PCI Security Standards Council to run external vulnerability scans to validate adherence with the external scanning requirements of PCI DSS.
PCI DSS v4 introduced additional requirements for merchants using SAQ-A. In most circumstances your risk may be small, as cardholder data is not transmitted via your website or Spektrix. Cardholder data is only ever transmitted directly to your Payment Service Provider, however, the scan is still required.
The change in PCI DSS 4.0 extends the requirement to merchant servers as part of SAQ-A. A merchant server is a server operated by your organisation which hosts your website.
Under PCI DSS v4.0.1 (SAQ A), your organisation is responsible for quarterly ASV scans of the web servers that host the pages embedding the payment form.
Spektrix handles security and ASV scanning for the payment iframes hosted within our infrastructure, validated in our annual AOC.
Spektrix does not offer ASV scanning, Take a look at the Approved Scanning Vendors on the PCI Security Standards website.
How do I read an Attestation of Compliance (AOC)?
The Spektrix Attestation of Compliance records the outcome and scope of our annual PCI DSS assessment. It is completed by the QSA and signed by both parties providing an independent verification of our compliance.
Below we’ve outlined each section of the AOC and what information you can find:
Cover Page
The cover page confirms:
- The name of the ‘entity’ or organisation being audited,
- The date of the report
- The date the assessment ended.
As the report takes time to compile, there is usually a delay between the end of the formal assessment period and the date of the report. A delay between the date of the assessment and the date of the report does not impact the validity of the AOC.
Section 1: Assessment Information
- Part 1: Contact information: Spektrix office address and contact title
- Part 2: Executive summary:
- 2a Scope Verification: Which services have been audited during the assessment and any services that are provided by the organisation being audited but which are out of scope for the assessment.
- 2b Description of role with payment cards: What the organisation does and how they manage card data.
- 2c Description of Payment Card Environment: A high level description of the technical details of what is being audited.
- 2d In-scope locations/facilities: Any physical location covered by the assessment.
- 2e PCI SSC Validated Products and Solutions: If this section is relevant, it will list tools used. For example, software that comes under the PCI SSC definitions.
- 2f Third-Party Service Providers: Any third parties whose services are part of the scope being assessed. For example, in a full assessment, your AOC should list Spektrix.
- 2g Summary of Assessment: A high level summary of the results of the assessment, showing the organisation’s status against each of the requirements
Section 2: Report on Compliance
The Report on Compliance provides details of the assessment. For example, whether any legal constraints apply and whether remote testing was used.
Section 3: Validation and Attestation Details
The Validation and Attestation details provide a high level summary of the assessment and includes:
- Full or partial: Whether the assessment covered the organisation’s full PCI DSS scope or only part of it. Check that the services you use are included within the stated scope.
- Outcome of compliant or non compliant: Confirms whether the service provider (such as Spektrix) has met all requirements. While this validates that Spektrix is compliant, your organisation must still complete your own PCI assessment.
- Sign offs: Signatures of the assessors and their details
Section 4: Action Plan for non-compliant requirements
- Action plan for any non-compliance: Details of any remediation actions and dates
What is the Shared Responsibility Matrix (SRM)?
A service provider should be able to provide a Shared Responsibility Matrix, which documents which organisation is responsible for particular clauses. There are three options for who is responsible for a clause:
- Shared responsibility: Both organisations have responsibility
- Merchant responsibility: The merchant (your organisation) has sole responsibility
- Service provider responsibility: The service provider (Spektrix) has sole responsibility. Please note that you are still responsible for confirming that the service provider is fulfilling their obligations.
Where to find more information
You can find our current PCI DSS compliance information and Attestation of Compliance through the Spektrix Trust Centre.
The PCI Security Standards Council’s Document Library provides the current PCI DSS standard, SAQs and supporting guidance. You can also find lists of Qualified Security Assessors and Approved Scanning Vendors.