Confidential_-_Supplement_-_ViaPath_PCI_DSS_Certification.pdf

THE ARIZONA DEPARTMENT OF

CORRECTIONS, REHABILITATION AND

REENTRY

RFP #BPM005375 Electronic Payment Transaction Processing Services

CONFIDENTIAL INFORMATION

ViaPath Technologies considers this information highly CONFIDENTIAL AND PROPRIETARY and has labeled it as such. The information contained within the supplemental documents should be kept confidential as they constitute trade secrets exempt from disclosure under Arizona’s Public Records Law.

The confidential documents include:

• Confidential – Supplement -ViaPath NIST 800 53 Cybersecurity Framework Command System Compliance Report.

• Confidential – Supplement – ViaPath PCI DSS Certification

• Confidential – Supplement – ViaPath System and Organization Controls SOC 2 Type 2 Report

The information contained within these documents consists of a formula, pattern, compilation, program, device, method, technique and/or process, and derive independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use. The information is the subject of efforts to maintain its secrecy that are reasonable under the circumstances. We respectfully request that this confidential and trade secret information, submitted solely for ADCRR’s review, be removed from our proposal books prior to any public display.

Closing Date: October 6, 2023

Presented to:

Arizona Department of Administration State Procurement Office 100 N 15th Avenue Phoenix AZ 85007

Presented by:

Nikki Calhoun Payment Specialist Telephone: 602-614-5480 Email: nikki.calhoun@viapath.com or RFP@viapath.com

Payment Card Industry (PCI) Data Security Standard

Attestation of Compliance for Onsite Assessments – Merchants Version 3.2.1

June 2018

CONFIDENTIAL

PCI DSS v3.2.1 Attestation of Compliance for Onsite Assessments – Merchants, Rev. 1.0 June 2018 © 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 1

Section 1: Assessment Information

Instructions for Submission

This Attestation of Compliance must be completed as a declaration of the results of the merchant’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS). Complete all sections: The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact your acquirer (merchant bank) or the payment brands for reporting and submission procedures.

Part 1. Merchant and Qualified Security Assessor Information

Part 1a. Merchant Organization Information

Company Name: Global Tel Link (GTL) DBA (doing business as):

TouchPay Holdings, LLC

Value Added Communications, Inc

Renovo Software, Inc.

ViaPath Technologies

Contact Name: John Farnell Title: VP, Information Security

Telephone: 251-487-2647 E-mail: john.farnell@gtl.net

Business Address: 3120 Fairview Park Drive,Suite 300

City: Falls Church

State/Province: VA Country: USA Zip: 22042

URL: www.connectnetwork.com

Part 1b. Qualified Security Assessor Company Information (if applicable)

Company Name:

Lead QSA Contact Name: Title:

Telephone: E-mail:

Business Address: City:

State/Province: Country: Zip:

URL:

Part 2. Executive Summary

Part 2a. Type of Merchant Business (check all that apply)

Retailer Telecommunication Grocery and Supermarkets

Petroleum E-Commerce Mail order/telephone order (MOTO)

Others (please specify): Inmate Communication Technologies

What types of payment channels does your business serve?

Mail order/telephone order (MOTO)

E-Commerce

Card-present (face-to-face)

Which payment channels are covered by this assessment?

Mail order/telephone order (MOTO)

E-Commerce

Card-present (face-to-face)

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 2

Note: If your organization has a payment channel or process that is not covered by this assessment, consult your acquirer or payment brand about validation for the other channels.

Part 2b. Description of Payment Card Business

How and in what capacity does your business store, process and/or transmit cardholder data?

GTL receives credit card payments for its inmate technology products through its web based e-commerce websites (https://www.connectnetwork.com, https://www.gtlfsonlinepay.com/ and https://www.gtlvisitme.com/app), IP restricted web services (WebPortal), call centers (www.intelmate.com and dcares.gtl.net), inmate facility kiosks and Interactive Voice Response (IVR) systems. This credit card information is encrypted upon receipt from the aforementioned intake systems using an industry approved encryption management appliance. All kiosk payments are encrypted at the card reader and are not decrypted until the credit card data reaches GTL’s data center. As cardholder data traverses the internal GTL network it remains encrypted until the moment it is sent to the merchant bank for authorization. At only that point is the encryption appliance called to decrypt the information and send it to the merchant bank via an encrypted communication path for authorization. Only the encrypted PAN, customer name, address and zip code are stored after authorization and all card holder data obtained during the transaction is purged from memory immediately after a valid response is received from GTL's merchant bank(s). The PAN remains encrypted while at rest in the GTL credit card databases. Network segmentation is utilized throughout this architecture to ensure only processes, applications, servers and employees with a business justification have access to internal credit card applications and servers.

Aside from the SafeNet key encryption management appliance, all applications in scope for PCI have been internally developed and are only used within the confines of GTL credit card authorization process.

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 3

Part 2c. Locations

List types of facilities (for example, retail outlets, corporate offices, data centers, call centers, etc.) and a summary of locations included in the PCI DSS review.

Type of facility Number of facilities of this type Location(s) of facility (city, country)

Example: Retail outlets 3 Boston, MA, USA

Data Centers 2 Allen, TX, USA

Houston, TX, USA

Call Centers 0 Call Centers are all contract to 3rd parties

Part 2d. Payment Application

Does the organization use one or more Payment Applications? Yes No

Provide the following information regarding the Payment Applications your organization uses:

Payment Application Name

Version Number

Application Vendor

Is application PA-DSS Listed?

PA-DSS Listing Expiry date (if applicable)

Yes No

Yes No

Yes No

Yes No

Part 2e. Description of Environment

Provide a high-level description of the environment covered by this assessment.

For example:

• Connections into and out of the cardholder data environment (CDE).

• Critical system components within the CDE, such as POS devices, databases, web servers, etc., and any other necessary payment components, as applicable.

The focus of the assessment was on the data centers in Houston Texas and Allen Texas. This environment includes the e-commerce websites, WebPortal customers and the Interactive Voice Response (IVR) systems supporting GTL inmate products and services.

GTL customer sites in their various locations around the US do not store, process, or transmit cardholder data and are separated from the cardholder environment by FortiGate stateful inspection firewalls and are excluded from the scope of this assessment.

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 4

The executive office in Falls Church, VA and satellite GTL employee offices do not store, process, or transmit cardholder data and are separated from the cardholder environment by ASA stateful inspection firewalls and Access Control Lists applied to the firewalls.

GTL has acquired companies (DSI-ITI, LLC, PCS, VAC, TouchPay and Renovo) that are operated independently and in some cases (at the time of this audit) utilize their own merchant banks and merchant IDs for processing credit card transactions. At the time of this audit, all DSI-ITI credit card transactions originating through the ConnectNetwork

(www.connectnetwork.com), inmate facility kiosks and IVR systems were confirmed to utilize the GTL back office credit card systems and mercant IDs. All PCS credit card transactions had been transitioned to the GTL back office credit card systems, as well. In addition, the majority of the TouchPay web based, kiosk and IVR based transactions utlize the GTL back office credit card systems and merchant IDs. Although a small percentage of TouchPay credit card payments still process through

Authorize.Net to Vantiv rather than utilizing the GTL back office to transmit the transactions directly to Vantiv, all TouchPay in-scope systems were evaluated. The scope of the audit included the following critical payment channels and all systems supporting them: the ConnectNetwork internet facing web system in the Houston, TX data center, the WebPortal API payment systems in the Houston, TX datacenter, the PCS phone platform systems (ICMSec) in the Dallas, Texas datacenter, the TouchPay E-Commerce website, IVR system and kiosks in the Dallas, Texas datacenter, the VAC IVR systems in the Dallas, Texas datacenter and the Video Visitation Payment portals (on premise at customer facilities and centralized in the Edina, MI datacenter).

Does your business use network segmentation to affect the scope of your PCI DSS environment?

(Refer to “Network Segmentation” section of PCI DSS for guidance on network segmentation)

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 5

Part 2f. Third-Party Service Providers

Does your company use a Qualified Integrator & Reseller (QIR)? Yes No

If Yes:

Name of QIR Company:

QIR Individual Name:

Description of services provided by QIR:

Does your company share cardholder data with any third-party service providers (for example, Qualified Integrator & Resellers (QIR), gateways, payment processors, payment service providers (PSP), web-hosting companies, airline booking agents, loyalty program agents, etc.)?

Yes No

If Yes:

Name of service provider: Description of services provided:

InContact GTL outsources much of its Interactive Voice Response (IVR) calling systems to InContact so that customers can fund accounts using an automated phone system.

Chase PaymenTech Chase is GTL’s main merchant bank

Shred-IT Cintas is GTL’s main shredding company. GTL’s policies do not permit for the capture of any CC data on paper but just in case, all documentation is placed in locked shred-bins serviced by Cintas

Vantiv

Acculynk

Vantiv is GTL’s secondary credit card processor.

TouchPay uses Acculynk to process PIN Debit transactions on the gtlfsonlinepay.com website. If a customer wants to use a debit card, they are redirected to the Acculynk website where they enter their debit card details and pin number.

ACI Worldwide/Retail Decisions (ReD)

Heartland Payment Systems

First Data Merchant Services

Credit card fraud checks

Renovo, a subsidiary of GTL, processes credit card transactions through Authorize.Net to Heartland Payment Systems

Value Added Communications, VAC, a subsidiary of GTL’s, process a small portion of IVR transactions through First Data

Authorize.Net

Global Response

Telat

Payment Principles (USA ePay)

TouchPay, a subsidiary of GTL, still processes a small amount of credit card transactions through Authorize.Net to Vantiv.

Provides customer service, including taking payments for GTL.

Provides customer service, including taking payments for GTL.

Gateway interface for credit card volume

Note: Requirement 12.8 applies to all entities in this list.

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 6

Section 2: Report on Compliance

This Attestation of Compliance reflects the results of an onsite assessment, which is documented in an accompanying Report on Compliance (ROC).

The assessment documented in this attestation and in the ROC was completed on: August 31, 2023

Have compensating controls been used to meet any requirement in the ROC? Yes No

Were any requirements in the ROC identified as being not applicable (N/A)? Yes No

Were any requirements not tested? Yes No

Were any requirements in the ROC unable to be met due to a legal constraint? Yes No

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 7

Section 3: Validation and Attestation Details

Part 3. PCI DSS Validation

This AOC is based on results noted in the ROC dated August 31, 2023.

Based on the results documented in the ROC noted above, the signatories identified in Parts 3b-3d, as applicable, assert(s) the following compliance status for the entity identified in Part 2 of this document (check one):

Compliant: All sections of the PCI DSS ROC are complete, all questions answered affirmatively, resulting in an overall COMPLIANT rating; thereby GTL has demonstrated full compliance with the PCI

DSS.

Non-Compliant: Not all sections of the PCI DSS ROC are complete, or not all questions are answered affirmatively, resulting in an overall NON-COMPLIANT rating, thereby (Merchant Company Name) has not demonstrated full compliance with the PCI DSS.

Target Date for Compliance:

An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document. Check with your acquirer or the payment brand(s) before completing Part 4.

Compliant but with Legal exception: One or more requirements are marked “Not in Place” due to a legal restriction that prevents the requirement from being met. This option requires additional review from acquirer or payment brand.

If checked, complete the following:

Affected Requirement Details of how legal constraint prevents requirement being met

Part 3a. Acknowledgement of Status

Signatory(s) confirms:

(Check all that apply)

The ROC was completed according to the PCI DSS Requirements and Security Assessment Procedures, Version 3.2.1, and was completed according to the instructions therein.

All information within the above-referenced ROC and in this attestation fairly represents the results of my assessment in all material respects.

I have confirmed with my payment application vendor that my payment system does not store sensitive authentication data after authorization.

I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.

If my environment changes, I recognize I must reassess my environment and implement any additional PCI DSS requirements that apply.

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 8

Part 3a. Acknowledgement of Status (continued)

No evidence of full track data1, CAV2, CVC2, CID, or CVV2 data2, or PIN data3 storage after transaction authorization was found on ANY system reviewed during this assessment.

ASV scans are being completed by the PCI SSC Approved Scanning Vendor Viking Cloud

Part 3b. Merchant Attestation

Signature of Merchant Executive Officer Date: August 31, 2023

Merchant Executive Officer Name: Rick White Title: Chief Operating Officer

Part 3c. Qualified Security Assessor (QSA) Acknowledgement (if applicable)

If a QSA was involved or assisted with this assessment, describe the role performed:

Signature of Duly Authorized Officer of QSA Company Date:

Duly Authorized Officer Name: QSA Company:

Part 3d. Internal Security Assessor (ISA) Involvement (if applicable)

If an ISA(s) was involved or assisted with this assessment, identify the ISA personnel and describe the role performed:

Jak Kulas, Compliance Manager, ISA

1 Data encoded in the magnetic stripe or equivalent data on a chip used for authorization during a card-present transaction. Entities may not retain full track data after transaction authorization. The only elements of track data that may be retained are primary account number (PAN), expiration date, and cardholder name.

2 The three- or four-digit value printed by the signature panel or on the face of a payment card used to verify card-not-present transactions.

3 Personal identification number entered by cardholder during a card-present transaction, and/or encrypted PIN block present within the transaction message.

© 2006-2018 PCI Security Standards Council, LLC. All Rights Reserved. Page 9

Part 4. Action Plan for Non-Compliant Requirements

Select the appropriate response for “Compliant to PCI DSS Requirements” for each requirement. If you answer “No” to any of the requirements, you may be required to provide the date your Company expects to be compliant with the requirement and a brief description of the actions being taken to meet the requirement.

Check with your acquirer or the payment brand(s) before completing Part 4.

PCI DSS

Requirement

Description of Requirement

Compliant to PCI

DSS

Requirements

(Select One)

Remediation Date and Actions

(If “NO” selected for any Requirement)

YES NO

Install and maintain a firewall configuration to protect cardholder data

Do not use vendor-supplied defaults for system passwords and other security parameters

3 Protect stored cardholder data

Encrypt transmission of cardholder data across open, public networks

Protect all systems against malware and regularly update anti-virus software or programs

Develop and maintain secure systems and applications

Restrict access to cardholder data by business need to know

Identify and authenticate access to system components

Restrict physical access to cardholder data

Track and monitor all access to network resources and cardholder data

Regularly test security systems and processes

Maintain a policy that addresses information security for all personnel

Appendix A2 Additional PCI DSS Requirements for Entities using SSL/early TLS for Card- Present POS POI Terminal Connections