PCI DSS Compliance

PCI DSS (Payment Card Industry Data Security Standard) Compliance applies to any organization that accepts, transmits, or stores cardholder data, regardless of its size or transaction volume. Established by major payment card brands (Visa, MasterCard, American Express, etc.), the standard aims to reduce credit card fraud by increasing controls around cardholder data.

For businesses that handle payments over the phone or assist customers on checkout pages, every interaction is within the scope of PCI DSS. Using a remote collaboration tool like co-browsing requires specific technical safeguards to ensure that sensitive authentication data and cardholder information are never exposed to agents or stored improperly.

The Six Control Objectives of PCI DSS

The standard is organized around six core security goals, which are supported by twelve main requirements:

• Build and Maintain a Secure Network and Systems: Protect the infrastructure that handles cardholder data.
• Protect Cardholder Data: Use encryption and other methods to secure data both in transit and at rest.
• Maintain a Vulnerability Management Program: Protect systems against malware and regularly update security systems and applications.
• Implement Strong Access Control Measures: Restrict access to cardholder data on a need-to-know basis.
• Regularly Monitor and Test Networks: Track all access to network resources and cardholder data.
• Maintain an Information Security Policy: Uphold a policy that addresses information security for all personnel.

For any organization that includes payment pages or card-not-present transactions in its customer journey, maintaining PCI DSS compliance is mandatory. A co-browsing solution, if not properly secured, can introduce significant risk by potentially exposing Primary Account Numbers (PAN), CVV codes, and other sensitive data to agents. Surfly's architecture is specifically designed to remove the agent and the collaboration platform from PCI DSS scope.

Preventing Cardholder Data Exposure

The most direct risk in a support session is an agent seeing or hearing a customer's payment card information. Surfly's proxy architecture intercepts and modifies the data stream, providing technical controls that make it impossible for an agent to access this data.

• Server-Side Data Masking: Surfly can be configured to automatically identify and redact payment card fields (PAN, CVV, expiration date) before the page is streamed to the agent. This redaction happens on the proxy server, meaning the sensitive data never reaches the agent's browser, directly supporting PCI DSS Requirement 3 (Protect stored cardholder data) and Requirement 4 (Encrypt transmission of cardholder data across open, public networks).
• Zero-Storage Architecture: The platform is built on a zero-storage principle. No session content, including any masked or unmasked data that passes through the proxy, is ever written to disk or stored. This eliminates the risk of cardholder data being compromised from Surfly's systems.
• No Customer-Side Installation: Because Surfly requires no plugins or software installation for the customer, it does not create a new potential vulnerability on the customer's machine that could be exploited to capture keystrokes or screen data.

Maintaining a Secure and Controlled Environment

Beyond just hiding data, PCI DSS requires proof of a secure and accountable operational environment. Surfly provides the logging and access control features necessary to demonstrate that security measures are in place and being enforced during every collaborative session.

• Comprehensive Audit Logging: Every session creates an immutable log detailing which agent connected, what pages were visited, and the duration of the session. This directly supports PCI DSS Requirement 10, which mandates tracking and monitoring all access to network resources and cardholder data.
• Granular Access Controls: Administrators can use allowlists to ensure co-browsing can only be initiated on specific, pre-approved domains, preventing agents from starting sessions on insecure or out-of-scope websites. This aligns with Requirement 7 (Restrict access to cardholder data by business need-to-know).
• End-to-End Encryption: All session traffic is encrypted using TLS 1.3. This protects the integrity and confidentiality of the entire data stream between the user, the Surfly proxy, and the target website, meeting the standard for protecting data in transit.

A customer for a large telecommunications company is on the payment page to settle their monthly bill but is having trouble applying a discount code. They contact support for help.

1. The support agent initiates a Surfly co-browsing session to view the customer's checkout page.
2. The agent guides the customer to the correct field to enter the discount code and sees it applied successfully.
3. The customer then proceeds to fill in their credit card number, expiration date, and CVV code. On the agent's screen, these fields appear as masked (e.g., **** **** **** 1234, **/**, ***). The agent can confirm the fields are filled but cannot see the sensitive data.
4. The customer clicks the "Submit Payment" button, and the transaction is processed directly and securely by the company's payment gateway.
5. The session ends, and a complete audit log is created without any cardholder data ever having been exposed to the agent or stored by Surfly.

The agent resolves the customer's issue and secures the payment, all while the company remains compliant with PCI DSS standards.