PCI DSS Compliance for Restaurants

PCI DSS is the payment-card industry security standard. It applies to organisations that store, process or transmit cardholder data, and it can also impose requirements on systems that affect the security of payment pages. A takeaway cannot decide that PCI DSS is “handled by the gateway” without checking its own setup.

Start with the payment channels

List every route that can involve card data:

• direct website or app checkout;
• embedded payment form;
• card terminal at the counter;
• portable terminal at the door;
• telephone orders;
• payment links;
• marketplace orders;
• stored cards or repeat-payment tokens.

For each route, record the provider, merchant account, device or integration, data flow and responsible owner.

Outsourcing can reduce scope, not remove responsibility

A hosted checkout where account-data functions are fully outsourced may qualify for a lower-scope validation route. However, eligibility depends on the exact implementation and the current criteria. Embedded forms, restaurant-controlled pages, telephone payments and card terminals can change the position.

Ask the acquirer or payment provider to confirm:

• the applicable Self-Assessment Questionnaire or assessment route;
• which systems and locations are in scope;
• whether vulnerability scanning is required;
• what evidence must be submitted and how often;
• which third-party providers must be listed;
• how significant changes affect validation.

Understand the SAQ A e-commerce limitation

SAQ A is for eligible card-not-present merchants whose account-data functions are outsourced to compliant third parties. Current PCI SSC clarification distinguishes between redirects and embedded third-party payment pages or forms. Eligibility is not a general label for any restaurant that uses a gateway.

For embedded payment pages, the restaurant must also address the current eligibility criteria relating to protection against payment-page script attacks. Confirm the required controls with the provider and acquirer.

Do not store prohibited authentication data

• Do not retain card security codes after authorisation.
• Do not keep full magnetic-stripe or equivalent chip data.
• Do not record PINs or PIN blocks.
• Do not copy full card details into order notes or support tickets.

If staff currently write card details down for telephone orders, stop and replace the process with a provider-approved method.

Protect e-commerce checkout

• Keep the website platform and extensions supported.
• Restrict who can change checkout code or add scripts.
• Inventory scripts running on payment-related pages.
• Authorise and justify each script.
• Detect unauthorised changes where required by the applicable standard and assessment route.
• Protect API credentials, webhook secrets and administrator accounts.
• Test changes in a non-production environment.

Protect card-present devices

Maintain a device inventory including model, serial number, location and provider. Train staff to inspect devices for:

• unexpected replacement or movement;
• broken seals or casing;
• unfamiliar attachments;
• changed cabling;
• unusual prompts or behaviour.

Use the provider’s approved replacement and incident route. Do not continue processing on a device suspected of tampering.

Access and authentication

• Use unique user IDs.
• Remove default accounts and passwords.
• Apply least privilege.
• Use multi-factor authentication where required or available.
• Review access regularly.
• Disable leavers promptly.
• Log privileged actions.

Third-party service providers

Keep a current list of providers that can affect cardholder-data security, such as:

• payment gateway;
• acquirer;
• ordering platform;
• web host;
• POS supplier;
• terminal provider;
• managed IT provider.

Obtain appropriate evidence of their PCI DSS status and document which responsibilities remain with the takeaway. A provider’s compliance does not automatically cover the restaurant’s configuration or staff practices.

Validation is not a once-a-year exercise

Review the payment environment after:

• a new checkout or app;
• a change from redirect to embedded payment fields;
• new terminals;
• telephone-payment introduction;
• a website rebuild;
• a new third-party script;
• a security incident;
• provider or acquirer change.

Incident plan

1. Stop using the suspected system where safe to do so.
2. Contact the acquirer and payment provider immediately.
3. Preserve logs and devices.
4. Follow the provider’s forensic and notification instructions.
5. Assess personal-data obligations separately.
6. Document remediation and revalidation.

Restaurant checklist

• All payment channels documented.
• Applicable validation route confirmed in writing.
• No card details in email, paper notes or POS comments.
• Device inventory and inspection process active.
• Checkout scripts and administrator access controlled.
• Third-party compliance evidence retained.
• Annual validation and change review scheduled.
• Incident contacts available during trading hours.

Related guides

• Payments — the main guide for the wider topic.
• Payment Security and Compliance — the broader guide that frames this implementation.
• Fraud Prevention for Online Orders — a closely related operational control to review alongside this page.
• Data Protection for Payment Information — a closely related operational control to review alongside this page.

Official guidance checked

• PCI SSC: PCI DSS v4.0.1 and supporting documents
• PCI SSC: PCI DSS v4.0.1 publication notes
• PCI SSC: SAQ A e-commerce eligibility clarification
• PCI SSC glossary, including Attestation of Compliance

Guidance checked: 24 July 2026. The acquirer or payment provider should confirm the assessment route for the restaurant’s exact implementation.

Compliance evidence to retain

• Completed SAQ or other required assessment documentation.
• Attestation of Compliance where applicable.
• Approved scanning results where required.
• Provider and service-provider compliance evidence.
• Device inventory and inspection records.
• Staff training records.
• Incident and change reviews.
• Evidence submitted to the acquirer.

Store the evidence with dates and responsible owners. A badge on a supplier website is not a substitute for the documentation required by the restaurant’s acquirer.

Common myths

• “We never see card numbers, so PCI DSS does not apply.” The scope may be reduced, but validation and website-security responsibilities can remain.
• “Our gateway is compliant, so our website is covered.” The restaurant’s integration, scripts and access may still affect security.
• “The SAQ is the same every year.” The environment and current standard can change.
• “A terminal from the bank needs no local controls.” Devices still need inventory, inspection and access control.
• “Telephone card details can be written down briefly.” Use an approved payment process and avoid creating paper card-data records.