PCI DSS Compliance Policy

Reviewed: 29 January 2026

At a glance

  • UK Postbox does not store, process or transmit cardholder data (CHD) on our systems. Payments are handled by PCI DSS‑validated payment processors using tokenisation and hosted payment pages.
  • Our goal is to maintain a minimised PCI scope (target SAQ A). If architecture requires our site to handle payment forms/JS, we will adopt SAQ A‑EP controls.
  • We keep Attestations of Compliance (AOC) from payment providers, maintain a current data‑flow diagram, and review scope annually or on change.

Purpose

This Policy defines how UK Postbox complies with the Payment Card Industry Data Security Standard (PCI DSS) by minimising scope, governing third‑party processors, and maintaining appropriate technical and organisational measures.

Scope & boundaries

Business processes in scope

  • Online payments for subscriptions, top‑ups and invoices.
  • Refund processing (via PSP dashboard/API).
  • Customer support interactions related to billing (no CHD collection by phone, chat or email).

System scope (target model)

  • Out of scope (UK Postbox systems): production apps, databases, object storage, support tools—no CHD is stored or transits our infrastructure.
  • In scope (third parties): PCI DSS‑validated payment service providers (PSPs) that host payment pages/iFrames and tokenise PAN.
  • Connected systems: our apps receive non‑sensitive tokens, payment status webhooks and customer identifiers.

Prohibited CHD handling

  • We never ask for or accept PAN, full track data, CAV2/CVC2/CVV2, PIN or magnetic‑stripe equivalents via email, ticket, chat or phone.
  • Support staff are trained to stop collection and redirect customers to the hosted payment page. Support agents must not take screenshots or screen recordings during billing-related interactions.

SAQ determination

  • Default target: SAQ A (website redirects to or embeds a hosted payment page/iFrame managed by the PSP; no CHD passes through our servers).
  • If our site serves payment pages or JS that affects the payment form, we will adopt SAQ A‑EP, adding external vulnerability scans and additional controls.
  • SAQ type is reviewed annually by the PCI Lead and DPO, and upon any change to the payment flow, including PSP changes, new payment methods, or integration changes.

Roles & responsibilities

  • Executive Sponsor (CFO/COO): owns payment strategy and resources.
  • PCI Programme Lead (Security Lead): maintains this Policy, scope, SAQ, data‑flow diagrams, evidence and vendor AOCs.
  • Finance/Billing: uses PSP portals/APIs; ensures refunds and chargebacks follow procedure; never requests CHD.
  • Engineering: implements and maintains hosted payment integrations; ensures no CHD is logged, stored or proxied through our systems.
  • Support/CS: follows no‑CHD handling; uses approved macros; sanitises tickets.
  • Vendors/PSPs: maintain PCI DSS validation and notify incidents without undue delay.

Technical controls (by requirement theme)

We align with PCI DSS v4.0 objectives while targeting scope reduction.


Scope reduction & network segregation

  • Only payment tokens and non‑sensitive metadata are handled by UK Postbox systems.
  • Webhooks from PSPs are authenticated (mTLS or signature) and deliver no CHD; payloads are validated and rate‑limited.
  • No storage locations (DB, logs, analytics) accept CHD; DLP rules are configured to detect PAN patterns (Luhn-valid 13–19 digit sequences) in logs, tickets, emails, and file uploads; alerts are investigated within 24 hours.

Secure application implementation

  • Hosted payment page/iFrame integration per PSP guidance; Content Security Policy includes frame-ancestors restricting payment iFrame embedding to our approved domains only.
  • Strong TLS (1.2+ / 1.3 preferred) between clients, our servers and PSP endpoints; HSTS enabled.
  • Logging excludes sensitive fields by design; secrets/tokens stored in a secrets manager.
  • Dependency/SCA scanning, SAST/DAST for payment‑adjacent code paths; critical issues remediated per Vulnerability Management Policy.

Access control & authentication

  • Admin access to billing and PSP consoles protected by MFA; least‑privilege roles; quarterly access reviews.
  • PSP API keys are rotated at least annually, within 24 hours of personnel departure with access, and immediately upon suspected compromise.

Monitoring & incident response

  • Centralised logging and SIEM monitor webhook anomalies and payment‑flow errors.
  • Suspected exposure or misuse of CHD is handled under the Incident Response & Breach Notification Policy, with PSP engagement and card‑brand escalation as required.

Physical & coaching controls

  • No CHD written on paper or stored physically.
  • Support agents trained to terminate any attempt to disclose CHD and send the secure payment link.

Vendor management (PSPs & sub‑processors)

  • We only use PSPs with current Attestation of Compliance (AOC) or Report on Compliance (ROC) covering the services we use.
  • The PCI Lead maintains evidence files: AOC/ROC, PCI DSS responsibility matrix with each PSP (clearly delineating requirements met by PSP, by UK Postbox, and shared), penetration‑test summaries (where provided), incident SLAs, and data‑flow notes.
  • Contracts require breach notification without undue delay, cooperation on investigations, and clear responsibility demarcation.

Evidence & compliance tasks

  • Annual: Determine SAQ type (A or A‑EP), complete and sign SAQ; refresh data‑flow diagram; collect current AOC/ROC from PSP(s); review this Policy.
  • Quarterly (A‑EP only): External ASV scans of any internet‑facing components that could impact the payment page; address findings.
  • Ongoing: Maintain regression tests ensuring no CHD fields can be posted to our origin; verify logs/analytics do not capture CHD; monitor DLP alerts.
  • Change control: Any change impacting the payment flow requires Security/PCI review before release (e.g., moving from redirect to embedded forms).

Incident response (payments)

  • If CHD may have been captured or exposed, immediately notify security@ukpostbox.com and the PCI Lead.
  • Contain (disable affected forms/logging), coordinate with PSP for investigation, determine card‑brand notification needs (requirements vary by volume and severity; the PCI Lead maintains current contact details and escalation thresholds for each brand), and follow customer/regulator notification per our Incident Response Policy and applicable contracts.

Records & retention

  • Retain compliance evidence for at least 12 months after the period it covers; retain SAQs, AOC/ROC, data‑flow diagrams, ASV scan reports (if applicable), and training records for at least 3 years.
  • Payment tokens, transaction IDs and invoices are retained per the Data Retention & Deletion Policy; no PAN is retained. Introduction of new payment methods (e.g., digital wallets, open banking) requires PCI scope assessment before implementation. We monitor for indicators of e-commerce skimming attacks (malicious JavaScript injection) through integrity monitoring of payment page resources.

UK Postbox Limited

13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, Dorset, BH16 6FH, United Kingdom


Support: support@ukpostbox.com

Security: security@ukpostbox.com

Legal notices: legal@ukpostbox.com

Data protection: dpo@ukpostbox.com

Complaints: complaints@ukpostbox.com

Accessibility: accessibility@ukpostbox.com

Website: www.ukpostbox.com


Registered in England and Wales Company Number: 06723381

MLR registration no: XLML00000192390

ICO registration no: ZA038907