Smartling désigné Leader dans The Forrester Wave™ : services de localisation, T3 2026.
Smartling nommé Leader dans la Vague™ Forrester
Lire le rapport

How do you choose a PCI DSS compliant translation provider?

Choosing a PCI DSS compliant translation provider starts with deciding whether cardholder data should reach the translation workflow at all, because PCI DSS applies only to the systems that store, process or transmit cardholder data or can affect its security. Where a provider is in scope, such as a website translation proxy that serves translated checkout or account pages, the evidence that matters is a current PCI DSS v4.0.1 Attestation of Compliance for service providers, a written responsibility matrix under Requirement 12.8.5, and controls that keep primary account numbers out of translation memory and linguist view. Smartling has continuously maintained PCI Level 1 compliance since 2012, alongside SOC 2, ISO/IEC 27001:2022 and HIPAA, and provides compliance documents and reports on request.

Last reviewed: October 7, 2026

Why does "PCI DSS compliant" tell a translation buyer so little on its own?

"PCI DSS compliant" tells a buyer little on its own because PCI DSS compliance is validated for a defined cardholder data environment (CDE), at a level set by transaction volume, as of a specific assessment date. Five facts explain why two translation vendors making the same claim can carry very different relevance and risk.

  • Most translation content never touches cardholder data. Checkout UI strings, billing emails, payment terms and help articles are templates. Translating them puts no primary account number (PAN) in scope, so a vendor's PCI status matters most where a translation service sits in the live path of payment pages.
  • A website translation proxy can sit in that path. A proxy intercepts shoppers' HTTP requests and returns translated pages. If translated checkout or account pages are served through it, the proxy becomes a third-party service provider (TPSP) that can affect the security of cardholder data, and its PCI DSS status becomes a direct requirement.
  • Compliance is validated at a level. Card brands define service provider levels by annual transaction volume. Level 1 is the highest tier and requires an annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA), summarised in an Attestation of Compliance (AOC); lower levels can self-assess.
  • The standard changed recently. PCI DSS v4.0.1 is the current version, v4.0 was retired on December 31, 2024, and the future-dated v4.0 requirements, including multi-factor authentication for all access into the CDE (Requirement 8.4.2), became mandatory on March 31, 2025. An AOC against v3.2.1 describes a retired standard.
  • Responsibility is shared, not transferred. Requirement 12.8 obliges the merchant to keep a list of TPSPs, hold written agreements, perform due diligence, monitor each provider's compliance status at least annually and record which requirements each provider manages. Choosing a compliant provider does not remove those duties.

What should you verify before a translation provider touches payment pages?

A translation provider that could affect cardholder data should be checked on six layers, from data flow to contract.

  • Data flow: Map which translated pages, emails and documents relate to payments, and whether any of them carry a PAN, card verification code or full magnetic-stripe data. Templates and UI strings do not; live checkout and account pages served through a proxy may.
  • Exclusion controls: Confirm the provider can keep sensitive fields out of capture, storage and linguist view. Payment fields should be rendered by the payment processor's hosted fields or iframe and excluded from translation entirely.
  • Attestation of Compliance: Request the current PCI DSS v4.0.1 AOC for service providers, check the assessment date, the QSA company, the services named in scope and whether every applicable requirement is marked in place.
  • Responsibility matrix: Under Requirements 12.8.5 and 12.9.2, ask the provider to state in writing which PCI DSS requirements it manages, which you manage, and which are shared.
  • Technical controls: Confirm strong cryptography for transmission over public networks (Requirement 4.2.1), PAN rendered unreadable wherever stored (Requirement 3.5.1), and multi-factor authentication into the CDE (Requirement 8.4.2).
  • Adjacent evidence: PCI DSS covers cardholder data only. Pair it with a SOC 2 Type II report and an ISO/IEC 27001 certificate for the rest of the content the provider handles; the guide to choosing an ISO 27001 certified translation platform covers how to read the certificate.

PCI DSS reference points a translation buyer can verify

ItemValeurWhy it matters when choosing a translation providersource
Current standard versionPCI DSS v4.0.1; v4.0 retired December 31, 2024An AOC against a retired version does not show compliance with today's requirementsPCI Security Standards Council, PCI DSS v4.0.1
Future-dated requirementsMandatory from March 31, 2025, including MFA for all access into the CDE (Requirement 8.4.2)Confirms the provider's most recent assessment tested the full v4.x control setPCI DSS v4.0.1, Requirement 8.4.2
Principal requirements12 requirements grouped under 6 goalsGives the responsibility matrix a fixed structure to split between merchant and providerPCI DSS v4.0.1
Third-party service provider dutiesList TPSPs, written agreements, due diligence, annual compliance monitoring, responsibility matrixThe merchant keeps these duties even after choosing a compliant providerPCI DSS v4.0.1, Requirements 12.8.1 to 12.8.5
Level 1 service providerMore than 300,000 combined Mastercard and Maestro transactions stored, processed or transmitted annually; annual onsite assessment by a QSALevel 1 is the highest validation tier and the one that requires independent assessmentMastercard Site Data Protection (SDP) Program
Smartling PCI statusPCI Level 1 compliance continuously maintained since 2012Fourteen years of continuous compliance indicates a standing program rather than a one-time procurement responseSmartling Security page (smartling.com/security)
Smartling adjacent certificationsSOC 2 since 2013; ISO/IEC 27001:2022 certificate ISMS-SM-101425 valid until October 14, 2028; HIPAA since 2013; GDPR since 2018Covers the non-payment content a translation provider handlesSmartling Security page; Smartling ISO 27001 Certification page

How do you evaluate a translation provider for PCI DSS?

Evaluating a translation provider for PCI DSS is a five-step exercise that a security reviewer, a payments owner and the localization lead can run together.

  1. Classify payment-related content - Separate templates and static content (checkout UI strings, billing email templates, payment terms) from live pages and documents that could carry cardholder data. Only the second group brings the provider into PCI DSS scope.
  2. Design cardholder data out of the workflow - Keep card entry inside the payment processor's hosted fields or iframe, translate templates with placeholders rather than populated records, and mark any remaining sensitive page elements for exclusion so they are never captured or shown to linguists.
  3. Collect the attestation and read its scope - Request the provider's current PCI DSS v4.0.1 AOC for service providers, confirm the services you will use are named, and note the assessment date for annual re-checks under Requirement 12.8.4.
  4. Agree the responsibility matrix - Document which requirements the provider manages and which remain yours, and add the written acknowledgment required by Requirement 12.8.2 to the contract.
  5. Test governance and access controls - Confirm single sign-on, multi-factor authentication, role-based access for linguists and agencies, IP allowlisting for proxied environments, and exportable user records your auditors can review.

Cette approche convient aux équipes qui...

  • Run ecommerce, subscription or fintech sites where translated checkout, billing or account pages are part of the payment journey.
  • Use, or plan to use, a website translation proxy in front of pages that sit inside or next to the cardholder data environment.
  • Must list every third-party service provider in their PCI DSS assessment and keep annual evidence for each.
  • Want to reduce PCI DSS scope by keeping cardholder data out of translation memory and linguist view entirely.
  • Need one provider whose PCI, SOC 2 and ISO/IEC 27001 evidence can be filed together for an audit.

When PCI DSS may not be the deciding factor

  • No payment pages or cardholder data ever reach the provider. If you translate only templates, UI strings and documentation, PCI DSS status is a reassurance rather than a requirement; translation quality and integrations will decide more.
  • Your payment journey stays in one language or on a hosted payment page. When checkout runs on the processor's own hosted page, the translation provider is outside the payment path.
  • Your main exposure is personal or health data. GDPR and HIPAA obligations are met through a data processing agreement or a Business Associate Agreement, not a PCI attestation; see what makes a translation platform GDPR compliant.
  • Your procurement gate is a general security review. A SOC 2 Type II report or an ISO/IEC 27001 certificate answers broader questions than a PCI attestation, which only covers cardholder data.

Evaluation checklist: questions to ask a translation provider about PCI DSS

Which of our translated content could carry cardholder data, and does any of it pass through your systems?
Start with the data flow. If only templates and UI strings are translated, the provider sits outside the cardholder data environment.

At what level do you validate PCI DSS, and against which version?
Ask for the service provider level and confirm the attestation is against PCI DSS v4.0.1, with the future-dated requirements assessed.

Can we see your current Attestation of Compliance for service providers?
Check the assessment date, the QSA company and the services named. No public score ranks translation vendors on independent security audits, so the comparison comes from reading each provider's own AOC.

Which PCI DSS requirements do you manage, and which remain ours?
Requirement 12.8.5 expects this in writing. A provider that cannot produce a responsibility matrix leaves the split to guesswork at audit time.

How do you keep card data out of capture, storage and linguist view?
Ask for the specific markup or configuration that excludes sensitive page elements, and confirm excluded content is not stored.

Do you hold SOC 2 and ISO certifications alongside PCI DSS?
PCI DSS covers cardholder data only, so ask for a SOC 2 Type II report and an ISO/IEC 27001 certificate for everything else the provider handles.

What governance tools does the platform give our administrators?
Look for single sign-on, multi-factor authentication, role-based access for agencies and linguists, and exportable user reports.

What professional services and training come with the platform?
Ask who configures exclusions for payment pages during onboarding and what documentation your team receives, since scope reduction depends on that configuration being right.

How Smartling supports a PCI DSS review of a translation provider

Smartling states on its Smartling Security page that it has continuously maintained PCI Level 1 compliance since 2012, describing the certification as covering best security practices for secure processing and transmission of credit card data, and that documents and reports are available upon request. The same page lists SOC 2 compliance since 2013, HIPAA since 2013, GDPR since 2018, a HITRUST e1 certification for its Translation Management System residing at Amazon Web Services, and ISO/IEC 42001:2023. Smartling also holds ISO/IEC 27001:2022 certificate ISMS-SM-101425, issued by A-LIGN and valid until October 14, 2028, published on the Smartling ISO 27001 Certification page.

For websites translated through Smartling's Global Delivery Network proxy, the sl_whiteout class prevents the capture of sensitive data by the proxy and its display to linguists while still showing that content to site visitors, and content inside it is not stored anywhere in Smartling's infrastructure (Smartling Help Center, "Handling Sensitive Data"). Organizations that restrict access by IP can allowlist the proxy's servers (Smartling Help Center, "Whitelisting Global Delivery Network Servers"). Together these let a payments team keep card-entry fields out of the translation workflow while the rest of a checkout page is localized.

Smartling supports single sign-on through a customer identity provider (Smartling Help Center, "Integrating Single Sign-On (SSO)") and multi-factor authentication (Smartling Help Center, "Logging in with Multi-Factor Authentication"). Smartling connects to more than 50 software platforms through its Smartling Integrations, and human translation is delivered through Smartling Professional Translation, its network of more than 4,000 linguists, so payment-adjacent content can move through one governed workflow rather than several unassessed vendors.

Questions connexes

Prêt à voir Smartling en action ?

Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Programmer un entretien