PCI Compliance UK – Ultimate Guide [PCI v4 ready – updated January 2026]

Introduction to PCI DSS Compliance

What is PCI DSS compliance?

PCI DSS compliance means meeting the requirements of the Payment Card Industry Data Security Standard (PCI DSS), a global standard designed to improve payment security.

It sets out a series of controls and processes to help organisations protect cardholder data when accepting, processing, storing, or transmitting payments by debit or credit card.

What is the PCI Security Standards Council (PCI SSC)

The PCI Security Standards Council (PCI SSC) is a global forum that develops and promotes the Payment Card Industry Data Security Standard (PCI DSS) and other related payment security standards. It was founded in 2006 by five major payment brands: American Express, Discover, JCB International, MasterCard, and Visa.

The Council is responsible for:

• Developing and maintaining PCI DSS
• Accrediting Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs)
• Providing training and resources to support secure card payment practices

While the PCI SSC sets the standards, it does not enforce them. Enforcement is carried out by the payment brands and acquiring banks, who require organisations to validate their compliance.

What’s the latest version of the PCI DSS?

The current version is PCI DSS v4.0.1, which became the sole active standard on 31 March 2025. It replaces both version 3.2.1 (retired in March 2024) and version 4.0 (retired in December 2024).

Version 4.0.1 was a clarification update with no new controls, but it clarifies the intent of some controls and corrects typographical errors from v4.0. It is now the only version supported by the PCI Security Standards Council.

The update from PCI DSS 3.2.1 to PCI DSS versions 4.0 and 4.0.1 reflects a shift from prescriptive checklists to outcome-based security. It places greater emphasis on risk management, flexibility in implementation, and continuous compliance – all critical for today’s threat landscape.

If your organisation processes or handles payment card data, you must now comply with PCI DSS v4.0.1.

Find out whether you’re ready for PCI DSS v4 in minutes

Click here to read more about PCI DSS v4 and what the changes mean for you

Click here to try our free online PCI DSS quote generator

Why is the PCI DSS Important?

The PCI DSS (Payment Card Industry Data Security Standard) is important because it helps protect sensitive cardholder data and prevent payment-related security breaches. At its core, the standard exists to reduce the risk of fraud, data theft, and reputational damage for any organisation involved in handling card payments.

If your business stores, processes or transmits cardholder data – even if you use a third-party payment processor – you are responsible for maintaining a secure environment. PCI DSS provides a structured framework to help you do that.

It’s not just about ticking boxes

PCI DSS isn’t a one-off exercise. While there is an annual validation requirement, true compliance involves implementing secure systems, following good security practices, and maintaining them throughout the year.

The standard also encourages businesses to take a risk-based, proactive approach to data protection. With growing threats such as phishing, ransomware, supply chain attacks and payment skimming, PCI DSS provides a practical baseline to reduce your exposure and improve resilience.

A step toward wider security maturity

While PCI DSS focuses on protecting cardholder data, many of its requirements – such as strong access control, secure system configuration and continuous monitoring – apply more broadly to general information security. Achieving and maintaining PCI DSS compliance often helps organisations strengthen their overall cyber security posture.

What could be the consequences of not being PCI compliant?

The main consequence of not being PCI compliant is that you may not be protecting cardholder data. This means you could be responsible for a breach and that could be enormously costly for your business and your customers.

• A data breach could result in both financial and identity theft from your customers. This will need to be reported to the Information Commissioner (and your customers) and you could be liable to financial penalties that could be significant under the GDPR (General Data Protection Regulation), as well as the card brands.
• In addition, your bank may set considerable (and costly) requirements for you to be able to continue accepting card payments after the breach. For example, if you have been subject to a cardholder data breach, you will be required to fund a PCI council-approved forensic investigation and then achieve the highest level of compliance (Level 1 – see below) regardless of the number of payments you take.
• Beyond these fines, the impact of a cardholder data breach on your reputation could be catastrophic, significantly impacting customer trust and causing long-term harm to your brand.
• Even in the absence of a breach, failure to be PCI DSS compliant means you are likely to be liable for fines and additional transaction charges from your bank. They may also withdraw the facility to take payment by credit and debit card if you continue to be non-compliant.

How much could I be fined if I am not PCI compliant?

If you continue failing to meet your PCI compliance requirements, in the worst circumstances your acquirer could withdraw your facility for accepting payment cards.

You could also be subject to increased fees for every card payment you take. One company we worked with was unknowingly paying over £1,000 per month in non-compliance fees. We helped them resolve the issue with a one-off investment of around £3,000 – meaning they broke even in just three months and avoided further penalties.

On top of this, you can incur fines costing as much as tens of thousands of pounds depending on the level of breach and cardholder data stolen.

Who Needs to Be PCI Compliant?

Any organisation that handles payment card data must comply with PCI DSS. This includes businesses of all sizes, as well as third-party service providers.

If your organisation processes, stores or transmits payment card data, you must comply with the Payment Card Industry Data Security Standard (PCI DSS).

This applies to:

• Merchants – any business or organisation that accepts payment by credit or debit card, regardless of size, industry or number of transactions
  
• Service providers – any organisation that processes, stores or transmits cardholder data on behalf of another business, such as hosting companies, payment gateways or managed service providers
  

Size does not matter

There is a common misconception that PCI DSS only applies to large businesses or those with high transaction volumes. In fact, all merchants and service providers are required to comply, even if they handle just one card transaction per year.

What does vary is how compliance is validated. Smaller merchants may be able to complete a Self-Assessment Questionnaire (SAQ), while larger or higher-risk organisations may need a formal Report on Compliance (RoC) completed by a Qualified Security Assessor (QSA).

Shared responsibility with payment providers

If you use a third-party payment platform such as Stripe, Opayo, Square or PayPal, PCI DSS still applies. In these cases, compliance responsibilities are shared between you and the provider. Using a compliant payment processor can significantly reduce your PCI scope, but it does not remove it entirely.

You are still responsible for ensuring that:

• Cardholder data does not pass through or get stored on your systems (unless explicitly designed to)
• Your website or application is securely integrated with the payment provider
• You complete the correct level of PCI validation annually

Is PCI compliance necessary in the UK?

Yes!

• All UK merchants and service providers that process, transmit or store payment card data must be PCI DSS compliant.
• For merchants: if you accept payment by debit or credit card for goods or services, you must be PCI DSS compliant, even if you use a third-party organisation or platform to process the payment.
• For service providers: if you are involved in processing, storing or transmitting cardholder data on behalf of another party, you must be PCI DSS compliant.

PCI DSS Compliance for Different Industries

While PCI DSS applies to any organisation that stores, processes or transmits cardholder data, the route to compliance can look very different depending on how payments are taken and the systems involved.

Below are some of the most common scenarios we see in UK organisations.

PCI DSS Compliance for E-commerce Businesses

If you sell online, PCI DSS compliance applies to you, even if payments are handled by a third party such as Stripe, Shopify Payments, PayPal or Opayo.

One of the biggest misconceptions in e-commerce is that using a payment provider removes your PCI responsibilities entirely. In reality, PCI DSS becomes a shared responsibility.

The key question is: does your website influence the payment process?

If your customer is redirected to a fully hosted payment page, or the payment experience is entirely delivered by a PCI DSS validated provider, you may qualify for a simpler route to compliance such as SAQ A.

However, if your website hosts payment scripts, embedded payment forms, JavaScript elements, or controls any part of the checkout experience, you may fall into SAQ A-EP, which carries significantly more requirements.

Under PCI DSS v4.0.1, e-commerce security is receiving greater scrutiny. Organisations must now ensure payment pages are protected against unauthorised script changes and browser-based attacks, such as payment skimming and Magecart-style compromises.

For many online businesses, understanding whether they qualify for SAQ A or SAQ A-EP is one of the most important early compliance decisions.

PCI DSS Compliance for Hospitality and Leisure Businesses

Hotels, holiday parks, visitor attractions, restaurants and hospitality businesses often have more complex payment environments than they realise.

You may take payments:

• Online
• Over the phone
• In person via PDQ terminals
• Through booking systems or third-party platforms

Multiple payment channels often mean broader PCI scope and a higher likelihood of falling into more complex SAQ types.

Telephone payments can present particular challenges. For example, call recordings, reservation systems, and staff writing down payment details can all inadvertently bring systems into PCI scope.

Hospitality businesses also tend to rely on multiple suppliers and booking platforms, making it important to clearly understand who is responsible for what in the payment chain.

PCI DSS Compliance for Charities and Not-for-Profits

Many charities assume that because donations are taken through providers such as JustGiving, Stripe or PayPal, PCI DSS does not apply to them.

Unfortunately, this is rarely the case.

If your organisation accepts card donations online, over the phone, in person, or through fundraising platforms, you still have responsibilities under PCI DSS.

The good news is that many charities can significantly reduce scope by using properly configured third-party payment platforms and avoiding the storage or handling of cardholder data internally.

The challenge is making sure those systems are implemented correctly and understanding which SAQ applies.

PCI DSS Compliance for Universities and Higher Education Institutions

Universities and higher education institutions often face unique PCI DSS challenges because payments are rarely handled through a single, centralised system.

Instead, payment activity is often spread across multiple departments and services, including:

• Student accommodation
• Tuition fee payments
• Catering and retail outlets
• Conferences and events
• Alumni donations and fundraising
• Short courses and continuing education
• Sports facilities and student services

This can create a complex PCI DSS environment, particularly where different teams use different payment providers, booking systems, virtual terminals or card machines.

One of the most common challenges in higher education is simply understanding the full scope of cardholder data across the institution. It is not unusual for universities to discover that departments have introduced payment processes independently over time, sometimes without central oversight.

Telephone payments, legacy systems, locally managed websites, and inconsistent supplier arrangements can all increase PCI scope unnecessarily.

Many universities also need to balance PCI DSS requirements with:

• Complex governance structures
• Procurement processes
• Large, distributed IT estates
• Legacy infrastructure
• Budget pressures
• Internal stakeholders with varying levels of technical knowledge

The good news is that many higher education institutions can significantly simplify PCI compliance through better payment architecture, supplier management and scope reduction.

For example, moving towards fully hosted payment pages, validated third-party providers, and properly segmented payment environments can reduce both risk and compliance burden.

For universities, PCI DSS compliance is often less about introducing entirely new controls and more about gaining visibility, reducing unnecessary scope, and ensuring consistent processes across departments.

Securious can support universities with PCI scoping, gap analysis, QSA-led assessments and practical remediation planning tailored to the realities of higher education environments.

PCI DSS for Service Providers

PCI DSS does not only apply to merchants taking payments directly from customers. It also applies to organisations that store, process or transmit cardholder data on behalf of others.

These organisations are classed as service providers.

Examples of service providers may include:

• Payment gateways
• Managed hosting providers
• Contact centres handling card payments
• Managed service providers with access to payment environments
• SaaS platforms involved in payment processing
• E-commerce technology providers

Many organisations are surprised to discover they fall into this category.

Being a service provider often means greater PCI DSS obligations, because you are responsible for protecting payment security across multiple clients or systems.

Service providers are typically expected to undergo more formal validation and may require a QSA-led Report on Compliance (RoC) rather than a Self-Assessment Questionnaire.

In addition to the standard PCI DSS requirements, service providers may also need to demonstrate:

• Strong segmentation between customers or environments
• Robust access control and monitoring
• Clear responsibility models
• Enhanced evidence and documentation
• More mature vulnerability management and testing processes

Determining whether your organisation is a merchant, service provider, or both is one of the most important scoping decisions in PCI DSS.

Getting this wrong can lead to under-scoping, incorrect validation, and problems with acquiring banks or customers later.

If you are unsure whether your organisation qualifies as a service provider, Securious can help determine your obligations and the right route to compliance.

PCI DSS Compliance for NHS England Trusts

Worldpay and other acquirers are increasingly enforcing stricter compliance requirements. Some Trusts previously using SAQ (self-assessment questionnaires) are now being required to undergo QSA-led Level 2 assessments due to growing transaction volumes.

We know many NHS Trusts are being asked to act quickly – often with little warning and no budget.

Securious provides tailored PCI DSS support to NHS Trusts across England – whether you’re maintaining existing compliance or responding to new mandates. We understand the NHS environment: complex procurement processes, limited budgets, and the need to move fast without sacrificing quality.

Find out more about our QSA-led PCI compliance services tailored for NHS environments by clicking here.

Understanding Your PCI Requirements

How do I know what PCI DSS level I am?

Before you can determine what actions you need to take to become PCI compliant, you need to know what level of compliance applies to your organisation. This is based primarily on how many card transactions you process each year, as well as whether you’ve experienced a cardholder data breach in the past.

The level you’re assigned will determine how your compliance needs to be validated – for example, whether you can self-assess using a questionnaire or need a formal assessment from a QSA.

What are the PCI compliance levels?

There are four levels of merchants based on the number of transactions they handle each year.

For example, PCI Level 1 concerns those merchants that take the highest number of transactions (or who have had a data breach previously) and PCI Level 4 concerns those merchants who take the fewest number of transactions.

The specific criteria for each compliance level are:

• PCI Level 1
  • Merchants who process over 6 million payment card transactions a year (or those who have suffered a cardholder data breach in the past).
• PCI Level 2
  • Merchants who process between 1 million and 6 million payment card transactions a year.
• PCI Level 3
  • Merchants who process between 20,000 and 1 million payment card transactions a year.
• PCI Level 4
  • Merchants who process fewer than 20,000 payment card transactions a year.

See more from VISA and Mastercard.

If you’re still unsure which PCI DSS level applies to your organisation, it’s best to get expert advice. The wrong assumption could result in incorrect validation, missed requirements, or unnecessary cost.

Securious can help you determine your PCI level and the right path to compliance – whether that’s completing a Self-Assessment Questionnaire or undertaking a full Report on Compliance with a Qualified Security Assessor.

Get in touch for a free consultation or use our PCI quote tool to start scoping your requirements.

What are the PCI compliance validation requirements for each level?

The different levels of merchant (see above) require additional reporting procedures, depending on PCI DSS scope, which can be summarised as follows:

Level 1

Annually

• Completion of a ROC (Report on Compliance) by a Qualified Security Assessor (QSA – see below)
• Completion of an AOC (Attestation of Compliance) and submitted to relevant card brands and acquirers.

Quarterly

• Network scan conducted by an Approved Scan Vendor (ASV)

Level 2

Annually

• Completion of a ROC (Report on Compliance) or SAQ (Self Assessment Questionnaire) by a Qualified Security Assessor (QSA – see below) or an internal assessor if signed by a company officer
• Submit an AOC (Attestation of Compliance) to card brands and acquirers.

Quarterly

• Network scan conducted by an Approved Scan Vendor (ASV)

Level 3

Annually

• Complete an SAQ (Self-Assessment Questionnaire – see below) signed by a company officer
• Submit an AOC (Attestation of Compliance) to card brands and acquires.

Quarterly

• Network scan conducted by an Approved Scan Vendor (ASV)

Level 4

Annually

• Complete an SAQ (Self-Assessment Questionnaire – see below) signed by a company officer
• Submit an AOC (Attestation of Compliance) to card brands and acquires.

Quarterly

• Network scan conducted by an Approved Scan Vendor (ASV)

Do I need a QSA or can I complete an SAQ?

If you are a Level 1 merchant or service provider, or have a complex cardholder data environment (CDE), you will need a Qualified Security Assessor like Securious to perform a formal assessment and produce a RoC.

Most small to medium-sized merchants can complete a Self-Assessment Questionnaire (SAQ). However, this is only effective if you fully understand your responsibilities and complete the SAQ honestly and accurately. Many organisations choose to engage expert help even if a QSA is not mandatory.

Securious offers both full QSA-led assessments and assisted SAQ support, helping you choose the right path based on your risk and payment environment.

What’s the difference between an SAQ and a RoC?

• SAQ (Self-Assessment Questionnaire): A form completed by the organisation itself to validate compliance. There are multiple types, depending on how you process payments. SAQs are typically used by smaller merchants and some service providers.
• RoC (Report on Compliance): A formal document produced by a QSA following an on-site or remote assessment. Required for Level 1 merchants and high-risk service providers.
  

If you’re unsure whether you can complete an SAQ or need a full RoC, speak to a PCI QSA firm like Securious for guidance.

How do I decide which SAQ type applies to me?

There are nine different SAQ types, each designed for specific payment processing methods. Choosing the wrong one could result in non-compliance or missed requirements.

Understanding which SAQ applies depends on how you take payments, what systems are involved, and whether you store cardholder data. Securious can help you determine the correct SAQ type as part of our gap analysis or assisted SAQ service.

The nine SAQ types are:

SAQ A

For merchants that fully outsource all cardholder data (CHD) functions to PCI DSS-validated third-party service providers.
Key criteria:

• No CHD is stored, processed or transmitted on the merchant’s systems

• The merchant does not host or control any part of the payment page

• The payment page is entirely served by a PCI DSS-compliant third party, typically via a redirect or iframe

• Applies to e-commerce and mail/telephone order merchants only (no face-to-face channels)

SAQ A-EP

For e-commerce merchants that outsource payment processing but maintain a website that could impact the security of the payment transaction.
Key criteria:

• No CHD is stored, processed or transmitted on the merchant’s systems

• The merchant website hosts or controls content that is part of the payment process, such as JavaScript, form elements or page logic

• The merchant’s website environment is in scope for PCI DSS

• Does not apply to mail/telephone order merchants

SAQ B

For merchants that use standalone payment terminals that connect only via dial-out (analogue phone line), with no internet or IP-based connectivity.
Key criteria:

• No CHD is stored electronically

• The terminals are not connected to any other systems or networks

• No e-commerce or virtual terminal use

• No other electronic cardholder data handling systems in the environment

SAQ B-IP

For merchants that use standalone payment terminals with IP-based connectivity, such as Ethernet or Wi-Fi, that are isolated from other systems.
Key criteria:

• No CHD is stored electronically

• Terminals must be PCI-approved devices listed on the PCI SSC website

• Terminals are connected to the internet or internal network but are segmented and not integrated with other systems

• No e-commerce or other channels in use

SAQ C-VT

For merchants that manually enter a single transaction at a time into a virtual terminal via a web browser on a secure and dedicated device.
Key criteria:

• No CHD is stored electronically

• The virtual terminal is provided by a PCI DSS-validated third party

• The system used to access the virtual terminal is isolated from other applications, such as email or general web browsing

• No other cardholder data processing methods are used

SAQ C

For merchants that use payment applications connected to the internet to process CHD, but do not store it electronically.
Key criteria:

• No CHD is stored electronically

• Payment systems are connected to the internet but are segmented from other parts of the network

• Applies to point-of-sale environments using payment applications installed on merchant systems

• No e-commerce or virtual terminal use

SAQ D for Merchants

For merchants that store, process or transmit CHD electronically and do not meet the criteria for any of the simpler SAQs.
Key criteria:

• Full PCI DSS assessment is required

• Covers all applicable PCI DSS requirements

• Applies to complex or multi-channel environments, or where CHD is stored electronically

SAQ D for Service Providers

For service providers that store, process or transmit CHD on behalf of other organisations.
Key criteria:

• Full PCI DSS assessment is required

• Covers all applicable PCI DSS requirements

• Applies only to entities defined as service providers under PCI DSS

SAQ P2PE

For merchants that use only PCI-validated Point-to-Point Encryption (P2PE) solutions for all card-present transactions.
Key criteria:

• No CHD is stored electronically

• All payment terminals are part of a PCI-listed P2PE solution

• Terminals are managed in accordance with the P2PE implementation manual

• No other payment channels are used

SAQ SPOC

For merchants that accept card-present payments using commercial off-the-shelf (COTS) devices, such as smartphones or tablets, with a PCI-validated Software-based PIN Entry on COTS (SPOC) solution.
Key criteria:

• No CHD or PIN is stored on the COTS device

• A secure card reader for PIN (SCRP) is used in conjunction with the SPOC application

• The SPOC solution must be PCI-validated and listed

• No other payment channels are used

Need help choosing the right SAQ? Securious can assist in selecting and completing the appropriate SAQ for your business.

Can Securious help me determine the right approach?

Yes. Securious is a PCI DSS Qualified Security Assessor Company (QSAC) and has helped hundreds of organisations understand their obligations under PCI DSS.

We can help you:

• Determine your PCI level and validation requirements
• Scope your cardholder data environment
• Identify whether a QSA assessment is required
• Complete your Self-Assessment Questionnaire (SAQ), or work with you to carry out a formal PCI assessment and produce your Report on Compliance (RoC)
• Plan remediation work to close any compliance gaps
  

Whether you’re looking for a one-off assessment or an ongoing managed service, we can provide the clarity and support you need.

What steps should I take to become PCI Compliant?

PCI DSS compliance can be thought of in three phases: Assess, Repair and Report. These phases map to the actions you’ll need to take, from identifying risks to submitting evidence of compliance.

Achieving PCI DSS compliance is a structured process. While the exact steps may vary depending on your merchant level, payment environment and whether you complete an SAQ or undergo a QSA assessment, the typical journey looks like this:

Map your cardholder data environment (CDE)

Before you begin, you’ll need to identify and map your cardholder data environment (CDE) – the systems, processes and technologies that store, process or transmit cardholder data.

This involves:

• Identifying all payment channels (e.g. e-commerce, face-to-face, telephone)
• Locating where cardholder data enters, flows through, is stored, or leaves your systems
• Reviewing payment service providers and integrations
• Documenting data flows and assets in scope

Understanding your CDE is critical because it defines the scope of your PCI DSS assessment. A smaller, well-segmented CDE will typically make compliance simpler and more cost-effective.

Securious can help with scope definition and documentation as part of a PCI gap analysis or formal assessment.

Segmented vs flat networks: reducing your PCI scope

The scope of PCI DSS can be reduced through network segmentation, isolating cardholder data systems from the rest of your network.

• In a flat network, all systems are interconnected, so the entire environment may fall within PCI scope.
• In a segmented network, security boundaries are enforced between the CDE and other systems, which can significantly reduce the compliance workload.

Effective segmentation helps minimise risk and makes ongoing compliance easier to manage. If segmentation is used, it must be tested and validated (typically through a penetration test) to confirm its effectiveness.

Implement technical and organisational measures

To meet PCI DSS requirements, you’ll need to implement a mix of technical controls and security policies. This includes:

• Installing and managing firewalls
• Encrypting cardholder data at rest and in transit
• Enforcing strong password policies and multi-factor authentication
• Applying secure system configurations
• Maintaining up-to-date anti-malware and patch management
• Conducting regular vulnerability scans and penetration testing
• Logging and monitoring access to sensitive systems
• Defining security policies and training staff

PCI DSS v4.0.1 places additional emphasis on outcomes-based security, meaning you must not only implement controls, but also demonstrate how they work in practice.

Complete your SAQ or undergo a RoC

Depending on your merchant level, you’ll either:

• Complete a Self-Assessment Questionnaire (SAQ), or
  
• Undergo a Report on Compliance (RoC) conducted by a Qualified Security Assessor (QSA)

SAQs are structured forms designed for smaller organisations and cover different payment scenarios. There are multiple SAQ types, and choosing the right one depends on how you process card payments (e.g. through e-commerce, point-of-sale, or phone orders).

A RoC is required for larger merchants and service providers, or those who have experienced a data breach. A QSA will conduct a formal audit and produce the required documentation for submission.

Securious offers services to help with both SAQs and RoCs, including scoping, documentation and remediation support.

Click here to learn more about our PCI DSS compliance services.

Submit documentation and maintain compliance

Once your assessment is complete, you’ll need to submit relevant documentation to your acquiring bank or payment processor. This may include:

• A completed SAQ or RoC
• An Attestation of Compliance (AOC)
• Quarterly ASV scan reports if you have internet-facing systems

Compliance isn’t a one-time activity. You’ll need to:

• Keep documentation current
• Conduct regular vulnerability scans and penetration tests
• Review your PCI scope annually
• Maintain security controls and staff awareness

Securious offers a Managed PCI DSS Compliance Service to help you stay on top of these ongoing requirements and reduce the stress of annual validation.

Understanding PCI DSS v4.0.1 Requirements

PCI DSS v4.0.1 is the latest version of the PCI DSS standard, replacing v3.2.1 and v4.0 as of March 2025. It brings a mix of enhanced technical requirements and more flexible implementation options. Below, we explain the 12 core requirements that remain central to compliance, and highlight the key changes introduced in v4.0.1.

What are the twelve Principle PCI DSS requirements?

Build and maintain a secure network and systems

1) Install and maintain network security controls

2) Apply secure configurations to all system components

Protect cardholder data

3) Protect stored account data

4) Maintain a vulnerability requirement

Maintain a vulnerability management programme

5) Protect all systems and networks from malicious software

6) Develop and maintain secure systems and software

Implement strong access control measures

7) Restrict access to system components and cardholder data by business need to know.

8) Identify users and authenticate access to system components

9) Restrict physical access to cardholder data

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

Maintain an information security policy

12) Support information security with organisational policies and programs

What does it take to become PCI DSS compliant in the UK?

How much does it cost to achieve PCI compliance in the UK?

PCI DSS compliance costs vary depending on:

• Your business size and merchant level
• Whether you need a QSA assessment, SAQ support, or a gap analysis
• The complexity of your cardholder data environment (CDE)
• Ongoing compliance needs (e.g. managed services vs. one-off assessment)

Securious provides transparent pricing and can offer a free initial consultation to discuss your specific requirements.

Click here to try our free online PCI DSS quote generator

Click here to read our article on the cost of PCI DSS Compliance in the UK

How long does PCI DSS certification take in the UK?

The timeframe depends on:

• Your current security posture (whether you already meet many requirements or need significant remediation)
• Your merchant level (higher levels require more detailed validation)
• Whether security issues are found that need fixing

For most businesses:

• A gap analysis can take one to two weeks
• Remediation (fixing security gaps) varies depending on your setup
• A full PCI DSS QSA assessment typically takes four to six weeks

Securious offers a tailored approach to help speed up the process where possible.

Click here to read more about our PCI DSS compliance services.

Working with a PCI DSS QSA or QSAC

What Is a PCI DSS QSA?

A Qualified Security Assessor (QSA) is an individual certified by the PCI Security Standards Council (PCI SSC) to assess and validate an organisation’s PCI DSS compliance. QSAs have the expertise to conduct formal security assessments, identify vulnerabilities, and provide guidance on meeting PCI DSS requirements.

Roles and responsibilities of a QSA:

• Assess compliance – QSAs conduct on-site audits and remote assessments to determine whether an organisation meets PCI DSS requirements.
• Identify security gaps – They review cardholder data environments (CDEs) to identify potential vulnerabilities.
• Provide remediation guidance – If compliance gaps exist, the QSA advises on the necessary steps to achieve and maintain PCI DSS compliance.
• Prepare Reports on Compliance (ROC) – For Level 1 merchants and service providers, a QSA is required to submit a full ROC to the acquiring bank or payment brands.

Using a QSA helps organisations navigate complex PCI DSS requirements and ensures a smooth compliance validation process.

When Do You Need a PCI DSS QSA?

Not all businesses require a Qualified Security Assessor (QSA), but for certain organisations, it is mandatory or highly recommended. You may need a QSA if:

• You are a Level 1 merchant (processing over 6 million transactions annually)
• You are a service provider handling cardholder data for other businesses
• Your acquiring bank or payment brand requires a Report on Compliance (ROC)
• You need expert guidance on meeting PCI DSS requirements

Even if you are not required to engage a QSA, working with one can help simplify the compliance process, ensure security measures are correctly implemented, and reduce the risk of costly mistakes.

What Is a PCI DSS QSAC?

A Qualified Security Assessor Company (QSAC) is an independent security organisation accredited by the PCI Security Standards Council to perform PCI DSS assessments. Only QSACs can employ QSAs to conduct official PCI DSS evaluations.

A QSAC must meet strict PCI SSC criteria, including:

• Employing certified QSAs with up-to-date training
• Demonstrating expertise in IT security and PCI DSS compliance
• Following strict quality assurance procedures

What does a QSAC do?

• Conducts PCI DSS assessments for merchants and service providers
• Provides PCI DSS gap analyses to identify compliance risks
• Supports businesses with remediation and security improvements
• Issues Reports on Compliance (ROC) and Attestation of Compliance (AOC)

By working with a QSAC, organisations gain access to expert knowledge and structured assessment processes, ensuring compliance with PCI DSS 4.0.1 and beyond.

Securious is a PCI DSS QSAC, meaning our team of certified QSAs can assess, advise, and guide UK businesses towards achieving and maintaining PCI DSS compliance.

What to Look for in a PCI DSS QSAC

Not all PCI DSS assessors offer the same level of service. When selecting a PCI DSS QSAC, consider the following:

• Accreditation – The firm must be listed as a PCI Security Standards Council-approved QSAC.
• Experience – Choose a company with a strong track record in your industry.
• Support Services – Look for firms that offer gap analysis, remediation advice, and managed compliance services.
• Transparent Pricing – Ensure there are no hidden fees for assessment, documentation, or remediation support.

Securious has been an approved PCI DSS QSAC since 2016, offering expert-led compliance assessments and security consultancy. If you need help achieving PCI DSS compliance, read more about our services by clicking here, or get in touch today.

PCI DSS v4.0.1: What Changed and What It Means for You

Find out whether you’re ready for PCI DSS v4 in minutes

A shift from rules to outcomes

Where previous versions were highly prescriptive, v4.0.1 allows organisations to choose either a traditional defined implementation or a newly introduced customised approach, provided the same security outcomes are achieved. Either way, you’re expected to document how your controls work, why they are sufficient, and how they are maintained.

You’re no longer just ticking boxes. PCI DSS v4.0.1 is designed to ensure you understand the risks, apply appropriate controls, and demonstrate how they work in practice.

Web Application Firewalls (WAFs) are now mandatory

Requirement 6.4.2 mandates that all public-facing web applications handling cardholder data must be protected by a WAF or equivalent control. Vulnerability scanning alone is no longer considered sufficient. This requirement addresses risks such as SQL injection, cross-site scripting and Magecart-style skimming attacks, which have affected many UK websites.

Even if you use hosted payment pages, you’re responsible for any code or scripts your site delivers in users’ browsers. It’s critical to ensure those elements don’t introduce vulnerabilities.

MFA is required for all access to the CDE

Multi-factor authentication is now mandatory for any access to the cardholder data environment (CDE), not just remote or administrative access. This includes every user logging into systems that store, process or transmit cardholder data. MFA significantly reduces the risk of breaches caused by compromised credentials.

Stronger password policies apply

Passwords must now be at least 12 characters long, include a combination of character types, lock accounts after 10 failed attempts, and be reset every 90 days if continuous authentication isn’t used. These changes bring PCI DSS in line with modern best practices and provide stronger defence against brute-force and credential-stuffing attacks.

Annual scope reviews and clear responsibilities

Requirement 12.5.2 now requires organisations to formally review the scope of their CDE at least once a year, or when significant changes occur. You must also define and document all roles and responsibilities for maintaining PCI DSS compliance. These changes are intended to ensure compliance activity is built into your business processes, not treated as a one-off exercise.

Risk-based control frequencies are now allowed

In some cases, PCI DSS v4.0.1 allows you to adjust the frequency of certain activities, such as testing or reviews, based on a documented risk assessment. This process is known as Targeted Risk Analysis (TRA). It can offer flexibility for mature organisations, but you must be able to justify your decisions and show that they do not reduce the intended level of security.

You’re still accountable – even if you outsource

PCI DSS isn’t regulated by UK law, but it is enforced by payment processors and acquiring banks. If you’re found to be non-compliant, you could face increased fees, penalties, or even lose the ability to process card payments.

You’re also accountable for any part of the payment process that passes through your systems, even if you use providers like Stripe, Opayo or Worldpay. Outsourcing reduces scope, but not responsibility.

What to do now

• Check whether your public-facing applications are protected by a WAF or equivalent control
  
• Ensure MFA is enabled for all access to cardholder data
  
• Update your password policies to meet the new complexity and length requirements
  
• Review the scope of your cardholder data environment and update documentation
  
• Assign and document roles and responsibilities for PCI compliance
  
• Decide whether the customised approach is right for your organisation
  
• If you use risk-based frequencies, make sure your decisions are documented and justified
  
• Review your third-party arrangements to confirm your responsibilities are covered

Defined and Customised Approaches for Implementing and Validating PCI DSS

In order to support greater flexibility in how security objectives are met, PCI V4.0 has introduced two approaches for implementing and validating to PCI DSS: the defined approach and the customised approach, which are summarised below.

Defined Approach

• Traditional method: This is the established approach used in earlier versions of PCI DSS (e.g., v3.2.1).
• Clear-cut requirements: PCI DSS sets out specific control statements and testing procedures that assessors use to verify if a control is implemented.
• Less flexibility: Organisations must adhere to the prescribed security controls with limited room for deviation.
• Compensating controls allowed: If an organisation has a technical or business constraint preventing them from meeting a specific requirement, they can propose alternative controls (with documentation and annual validation) to achieve the same security objective. Note that compensating controls must provide a higher level of security than the requirements laid out in the defined approach in order to be acceptable.

Customised Approach

• New in v4: This approach offers more flexibility for organisations with well-developed security practices.
• Focus on objectives: PCI DSS outlines security objectives for each requirement. Organisations that already have robust systems in place that meet these objectives can use their existing systems instead of implementing new measures, providing they achieve the same outcomes and they can demonstrate their effectiveness.
• More effort required: Designing, documenting, testing, and maintaining custom controls requires significant effort and expertise.
• Only for well-established organisations – if you’re new to PCI DSS, you won’t need to think about a customised approach. This is for organisations with longstanding experience of protecting cardholder data, who already have systems in place that meet the objectives of PCI DSS (even if this isn’t achieved in the same way as outlined in the requirements of the defined approach).
• Not for all requirements: Some PCI DSS requirements cannot be met using the customised approach (these are explicitly listed in the standard).

Choosing the Right Approach

The Defined Approach is generally simpler and suitable for most organisations, especially those with less developed security programmes.

The Customised Approach is ideal for organisations with strong security practices and the resources to design and validate custom controls.

Remember, regardless of the approach chosen, the ultimate goal is to achieve a secure environment for cardholder data.

Click here to read more about PCI DSS v4 and what the changes mean for you

Other Services You Might Need for PCI Compliance

Maintaining PCI DSS v4.0.1 compliance often involves more than completing a self-assessment. Depending on how your organisation handles cardholder data, you may also need regular penetration testing, external ASV scans, internal vulnerability assessments, and documented remediation. Securious provides all of these services, aligned with PCI requirements and delivered in a way that’s appropriate to your scope.

Penetration Testing

Penetration testing is required under PCI DSS v4.0.1 if your systems store, process, or transmit cardholder data and are therefore in scope for Requirements 11.4.2 and 11.4.3. Not all organisations will need penetration testing – for example, SAQ A merchants that fully outsource payments typically fall outside this requirement.

Where it is required, PCI mandates both internal and external penetration testing at least once a year and after any significant changes. Testing should also validate segmentation if used to reduce the scope of your PCI environment.

Securious provides penetration testing that is:

• Scoped to your PCI environment
  
• Delivered by qualified testers with PCI DSS expertise
  
• Documented to meet QSA expectations
  
• Supported with clear remediation advice and optional retesting
  

Click here to read more about our penetration testing services for PCI DSS compliance.

Click here to try our free, online, instant penetration testing quote generator.

ASV Scans (External Vulnerability Scanning)

If your organisation has any internet-facing systems in scope for PCI DSS, you must undergo external vulnerability scans at least quarterly. These scans must be performed by an Approved Scanning Vendor (ASV), as required by Requirement 11.3.2.

Securious can provide ASV scans, including:

• Asset discovery and scope validation
  
• Quarterly and ad hoc scanning
  
• Detailed reports showing pass/fail status
  
• Attestation of Scan Compliance for submission with SAQs or Reports on Compliance
  
• Rescanning support following remediation
  

These scans are essential for most merchant types and are a key part of PCI evidence packs. Click here to learn more.

Internal Vulnerability Scanning

PCI DSS Requirement 11.3.1 requires internal vulnerability scans at least quarterly and after any significant change. These scans help identify and address weaknesses in your internal network, including misconfigurations, unpatched systems, and weak segmentation.

Securious offers managed internal scanning services that include:

• Initial scope and setup
  
• Regular scans and risk-ranked reporting
  
• Remediation support and rescanning where needed
  
• Alignment with your broader PCI testing plan
  

Click here to learn more.

Why These Services Matter

Together, these services help demonstrate that your systems are regularly assessed, vulnerabilities are identified and addressed, and your controls are working in practice. Each one maps to specific PCI DSS requirements and may be requested by your acquiring bank, payment processor, or QSA as part of your compliance evidence.

How Securious Can Help

Our services include:

• Penetration testing for in-scope systems (where required)
  
• Approved external scanning (ASV) with attestation
  
• Internal vulnerability scanning and remediation guidance
  
• Scope definition and documentation aligned to your SAQ or RoC
  
• Flexible testing schedules to support continuous compliance
  

We help you meet PCI testing obligations in a way that’s practical, proportionate, and aligned with your business model.

Common PCI compliance myths

There are many myths and misunderstandings about PCI compliance. These are some we encounter on a regular basis:

MYTH – PCI compliance is only ‘a thing’ for big businesses.

If you’ve read this guide you will be clear that every merchant that takes payment by credit or debit card needs to be PCI DSS compliant and can face significant consequences if they aren’t.

MYTH – We use Opayo/Stripe/PayPal etc and they are fully PCI compliant so we don’t need to be.

As previously explained, if you accept or process payment cards, PCI DSS applies to you. Using a payment provider like Opayo, Stripe or PayPal may make it much easier to achieve and demonstrate that you are PCI compliant, but it does not in any way make you exempt.

MYTH – I do not need to be PCI compliant because it is not a legal requirement.

This is not the case, but it is required by the payment card companies and banks. Failure to comply means they can both remove the option for a merchant to take credit card payments and charge them much more for doing so. Should an organisation face a breach of cardholder data and not be PCI DSS compliant, the penalties are likely to be more severe.

Note: If any of the requirements contained in this standard conflict with country, state, or local laws, the country, state, or local law will apply.

MYTH – I can just answer ‘Yes’ to all the questions on the Self-assessment Questionnaire (SAQ).

This is an extremely dangerous position to take. The SAQ has to be signed by an officer of the company. If they answer ‘Yes’ to a question when they aren’t adequately meeting that control, as well as not being truthful, if a card data breach occurs and it becomes clear the merchant was never actually compliant, the consequences for the organisation could be extremely serious.

MYTH – I never committed to being PCI compliant and I can wait until the bank asks me to.

This is a common misunderstanding and another very dangerous one. The terms signed when an entity opens a merchant account will state that PCI DSS compliance is required and you will face penalties for non-compliance (higher processing fees, etc).

Common PCI DSS Compliance Mistakes

PCI DSS can be complicated, particularly for organisations going through the process for the first time. Over the years, we have seen the same misunderstandings repeatedly create unnecessary cost, delays and compliance issues.

These are some of the most common mistakes organisations make.

Assuming Stripe, PayPal or Opayo makes you exempt

Using a third-party payment provider can significantly reduce PCI scope, but it does not remove your responsibilities entirely.

You are still responsible for understanding how payments flow through your environment, ensuring integrations are secure, and completing the correct validation each year.

In many cases, businesses unknowingly choose the wrong SAQ because they misunderstand how their payment pages work.

Choosing the wrong SAQ

Selecting the wrong Self-Assessment Questionnaire is one of the most common PCI mistakes we encounter.

For example, an organisation may assume they qualify for SAQ A, only to discover their website hosts payment scripts or embedded forms, meaning SAQ A-EP is actually required.

Choosing the wrong SAQ can result in non-compliance, failed assessments, or problems if a breach occurs.

Accidentally bringing systems into PCI scope

Seemingly small decisions can dramatically increase your PCI obligations.

Examples include:

• Storing card details in emails or spreadsheets
• Recording payment calls without adequate controls
• Allowing payment data to pass through internal systems unnecessarily
• Poorly implemented website payment integrations

Reducing scope is one of the simplest ways to make PCI DSS more manageable and cost-effective.

Treating PCI DSS as a once-a-year exercise

PCI DSS is not just an annual questionnaire or audit.

Requirements such as vulnerability scanning, penetration testing, access reviews, patching and logging happen throughout the year.

PCI DSS v4.0.1 places even greater emphasis on continuous compliance, meaning organisations must demonstrate that controls are operating effectively on an ongoing basis.

Leaving everything until renewal time often creates unnecessary pressure and remediation work.

Failing to properly define scope

Many PCI problems begin with poor scoping.

If you do not fully understand:

• Where cardholder data enters your environment
• Which systems impact payment security
• Which suppliers are involved
• What sits inside or outside your cardholder data environment (CDE)

…it becomes very difficult to complete compliance accurately.

Getting scope right at the start can significantly reduce both cost and complexity.

Trying to “tick the box”

PCI DSS works best when organisations approach it as a practical security framework rather than an exercise in paperwork.

Simply answering “yes” to controls without understanding them may seem quicker in the short term, but it creates significant risk if vulnerabilities exist or a cardholder data breach occurs.

The organisations that tend to find PCI easiest are those that treat it as an ongoing process of improving security, reducing risk, and simplifying payment environments over time.

PCI DSS Compliance – Frequently Asked Questions (FAQs)

How does a PCI DSS gap analysis work, and do I need one?

A PCI DSS gap analysis is a pre-assessment that identifies areas where your organisation falls short of compliance. This service is ideal for:

• Businesses that have never been PCI compliant and need clarity on what to change
• Companies moving from PCI DSS v3.2.1 to PCI DSS v4.0.1 and needing to understand new requirements and how they fare against them
• Organisations unsure about their current PCI DSS status and wanting expert guidance before an official assessment

Securious provides structured gap analysis reports with clear, actionable recommendations to help you achieve compliance efficiently.

What’s the difference between a PCI DSS audit and a penetration test?

• A PCI DSS audit (QSA assessment) verifies that your organisation meets PCI DSS requirements
• A penetration test actively tests your systems for vulnerabilities by simulating cyber-attacks

Both are essential for compliance, but a penetration test may be required annually under PCI DSS if you store or process cardholder data.

Securious offers both QSA assessments and penetration testing services.

What are the biggest mistakes businesses make with PCI DSS compliance?

Some common mistakes include:

• Assuming a third-party provider covers everything – PCI DSS is still your responsibility
• Not keeping compliance up to date – Annual validation is required
• Failing to segment networks – Cardholder data environments must be properly separated from other systems
• Skipping staff training – Human error is a major security risk

Securious helps businesses avoid these pitfalls through structured assessments and ongoing compliance support.

PCI DSS vs. UK GDPR: What’s the Difference?

PCI DSS protects cardholder data to reduce payment fraud and is enforced by banks/payment brands. UK GDPR protects all types of personal data and is regulated by the ICO. If you handle cardholder data, you must comply with both.

Are there specific PCI DSS requirements for e-commerce businesses in the UK?

Yes, e-commerce businesses must implement additional security controls, including:

• Secure payment gateways – Ensure transactions are processed through PCI-compliant providers.
• SSL/TLS encryption – Protect cardholder data transmitted online.
• Regular security testing – Conduct vulnerability scans and penetration testing.
• Secure coding practices – Protect against web-based threats such as SQL injection and cross-site scripting.

These measures help prevent fraud and protect online payment data.

How often should UK businesses validate PCI DSS compliance?

The frequency depends on the merchant level:

• Level 1 – Annual on-site QSA audit and quarterly network vulnerability scans.
• Levels 2-4 – Annual Self-Assessment Questionnaire (SAQ) and quarterly network vulnerability scans.

Regular validation ensures ongoing compliance and protection against security threats.

What is the difference between PCI DSS compliance and PCI DSS validation?

• PCI DSS compliance means your organisation meets all PCI DSS security requirements.
• PCI DSS validation is the process of proving compliance to your acquiring bank or payment provider, usually via an SAQ or QSA assessment.

Even if validation is not formally required, maintaining compliance is essential to reduce security risks.

Do I need PCI compliance if I use a payment provider like Stripe or Opayo?

Yes!

• If you use a payment service provider, PCI compliance becomes a shared responsibility between yourself as the merchant and the payment provider.
• Using a payment service provider will normally mean you, as the merchant, have no need to see or have any access to the cardholder’s information.
• This makes it much easier to meet your PCI compliance requirements, but it does not remove them.

Can small businesses use SAQ A for PCI DSS compliance?

Yes, if your business qualifies for SAQ A, it’s one of the simplest ways to validate PCI DSS compliance. SAQ A is designed for merchants who:

• Fully outsource all payment processing to PCI DSS validated third parties
• Do not store, process or transmit any cardholder data on their systems
• Only use web-based payment or hosted payment pages (no cardholder data passes through their environment)

It’s most common for e-commerce merchants using providers like Stripe, Shopify, or Opayo.

Securious can help you confirm whether you qualify for SAQ A and how to complete it correctly.

How can Securious help me get or maintain PCI compliance?

Securious has been a PCI QSA company since 2016 and has a team of qualified, highly experienced PCI DSS QSA and 3DS assessors who can help you achieve and maintain compliance with the latest PCI DSS.

We are based in Exeter, Devon but undertake PCI QSA work nationally and internationally. We are the only PCI DSS QSA company in the region, so if you are based in Devon, Cornwall or Somerset, you will also benefit from cost efficiencies with on-site assessments.

Our mission is to build cyber security confidence and when it comes to PCI DSS compliance, we will work with you to make the process as efficient as possible, helping you understand what you need to do, and why.

We have three different options for helping our clients with PCI DSS compliance:

1: PCI DSS QSA Gap Analysis & Assessment (one-off fee)

We’ll help you achieve PCI DSS compliance by conducting a gap analysis, telling you what needs to change and assessing you once remediation is complete.

• We start by assessing your situation to determine the scope and what level you need to be reporting at. Then, we conduct a gap analysis, looking at what you already have in place against the requirements. From this, we can determine any additional measures you need to implement to achieve compliance.
• We will then advise and assist with any remediation work needed to meet the standard.
• Finally, we will carry out your assessment and complete the necessary reports and questionnaires as required.

If you would like to know how much an engagement with Securious is likely to cost, you can try our free online PCI DSS quote generator by clicking here.

Read more about our PCI DSS QSA Gap Analysis & Assessment by clicking here.

2: Managed PCI DSS Compliance Service (fixed monthly fee)

We’ll help you maintain PCI DSS compliance on an ongoing basis, ensuring everything is in good shape before the annual assessment for a much simpler process.

• Our PCI DSS Compliance Managed Service works proactively to ensure your organisation maintains continuous compliance with the latest PCI DSS.
• By focusing on ongoing documentation management, continuous monitoring, and regular risk and compliance reviews, we’ll help you stay ahead of security requirements and minimise the stress of annual assessments.
• This approach is tailored to your specific needs and is well-aligned with the latest PCI DSS V4 standard, which prioritises continuous compliance.

Pricing starts from £535 (+ vat) per month.

Read more about our Managed PCI DSS Compliance Service by clicking here.

3: Assisted PCI DSS SAQ Compliance Service (one-off fee)

We’ll help you with your PCI DSS SAQ so you know what the questions mean and how to answer them, so you can easily achieve compliance.

• We’ll give you qualified support with your SAQ
• So you know what the questions mean and how you should answer them
• The result is far less time wasted trying to understand the SAQ and much greater peace of mind

Pricing starts from £975 (+ vat).

Read more about our Assisted PCI DSS SAQ Compliance Service by clicking here.

To learn more, see our PCI services page, call us on 01392 247 110, email info@securious.co.uk or send us a message using the form below.

Find out whether you’re ready for PCI DSS v4 in minutes

PCI DSS Glossary of key terms

AOC – Attestation of Compliance

A formal document confirming that an organisation has met the applicable PCI DSS requirements. Submitted alongside the SAQ or RoC.

ASV – Approved Scanning Vendor

A company authorised by the PCI Security Standards Council to perform external vulnerability scans as part of PCI DSS compliance.

Cardholder Data (CHD)

Any personally identifiable data associated with a payment card, including the primary account number (PAN), cardholder name, expiration date and service code.

CDE – Cardholder Data Environment

The systems, people and processes that store, process or transmit cardholder data. Defines the boundaries of PCI DSS scope.

Compensating Control

A security control used when a business cannot meet a specific PCI DSS requirement as written, but still achieves the intended level of protection. Must be documented and validated.

Customised Approach

An option introduced in PCI DSS v4 that allows organisations to meet certain requirements using different methods, if they can demonstrate that the outcome is equivalent or stronger than the standard requirement.

Defined Approach

The traditional PCI DSS method, where the organisation follows prescriptive control requirements and testing procedures exactly as set out in the standard.

MFA – Multi-Factor Authentication

A security measure requiring users to provide two or more verification factors (such as a password and a mobile app code) to gain access to systems.

PAN – Primary Account Number

The unique number on a payment card that identifies the issuer and the individual cardholder account. Also known as the card number.

PCI DSS – Payment Card Industry Data Security Standard

A global security standard designed to protect cardholder data and reduce payment fraud. Applies to all organisations that process, store or transmit payment card information.

PCI SSC – PCI Security Standards Council

The body responsible for developing and maintaining PCI DSS and related standards. Formed by Visa, MasterCard, American Express, Discover and JCB.

Penetration Testing

A simulated cyber attack used to identify vulnerabilities in a system or network. Required under PCI DSS for in-scope systems and for validating segmentation.

QSA – Qualified Security Assessor

An individual certified by the PCI SSC to conduct PCI DSS assessments and produce Reports on Compliance (RoC).

QSAC – Qualified Security Assessor Company

An organisation approved by the PCI SSC to employ QSAs and deliver official PCI DSS assessments.

Report on Compliance (RoC)

A formal report produced by a QSA following an assessment of a Level 1 merchant or service provider, confirming whether they meet PCI DSS requirements.

Risk-Based Frequency

An approach allowed in PCI DSS v4.0.1 where certain activities (like scans or reviews) may be performed less frequently if justified through a documented risk assessment.

SAQ – Self-Assessment Questionnaire

A structured form completed by organisations to validate their PCI DSS compliance. There are several types depending on how payments are processed.

Scope

The part of your environment that falls under PCI DSS. Defined by the systems, processes and personnel that touch or impact cardholder data.

Segmentation

Separating cardholder data systems from the rest of your IT environment to reduce the number of systems in scope for PCI DSS and simplify compliance.

Targeted Risk Analysis (TRA)

A method introduced in PCI DSS v4 that allows organisations to set custom control frequencies based on documented risk, rather than fixed schedules.

Vulnerability Scan

An automated scan of systems to identify known security weaknesses. Internal scans and quarterly external scans (by an ASV) are required under PCI DSS.

WAF – Web Application Firewall

A security tool that monitors and filters traffic to and from web applications. Required under PCI DSS to protect public-facing applications handling cardholder data.

To get started with your PCI DSS compliance, see our PCI services page, call us on 01392 247 110, email info@securious.co.uk or send us a message using the form below.

Find out whether you’re ready for PCI DSS v4 in minutes

Click here to try our free online PCI DSS quote generator