TCR-IT-020: PCI DSS Policy

Summary

A security addendum documenting how TCR meets applicable requirements of PCI DSS version 4.0.1. Supplements, rather than replaces, TCR’s existing Information Security, Data Privacy, and Technology Use policies.

Why it exists

TCR accepts payment cards for tuition, fees, and other services, which brings PCI DSS obligations into scope. Rather than building card-handling infrastructure in-house, TCR’s approach is to keep cardholder data entirely off TCR-managed systems, out of scope, by relying on PCI-compliant third-party processors. This document exists to make that scope decision explicit and auditable.

Relationship to existing policies

TCR’s existing policies (information security, data protection, access control, incident response, vendor management, user responsibilities) collectively establish the security controls relevant to payment processing. PCI DSS-specific requirements are addressed by combining those existing policies with the PCI-specific clarifications in this addendum; where controls are already defined elsewhere, this addendum references rather than duplicates them.

PCI scope and payment environment

TCR does not store, process, or transmit cardholder data on systems it owns or manages. All payment card processing is performed by PCI-compliant third-party service providers; TCR’s PCI DSS scope is limited to oversight of those providers and the security of systems that access or administer payment processing services.

Payment acceptance channels:

• Web-based payment processing through the student information system, hosted and managed by a third-party service provider.
• Point-of-sale (POS) payment systems operated by third-party vendors for applicable programs. Cardholder data is entered directly into third-party payment environments and is never accessible to, stored on, or transmitted through TCR-managed systems.

Out-of-scope systems: because TCR doesn’t store/process/transmit cardholder data, internal networks, servers, workstations, and applications are out of scope for cardholder data environment (CDE) requirements. They’re governed by TCR’s general Information Security policies instead (access controls, endpoint protection, logging).

Third-party service providers and shared responsibility

TCR’s primary payment-related third-party service providers:

• Populi, including its integrated payment processing services
• Payfactory, the payment processor used by Populi
• Meevo, for point-of-sale payment processing used by applicable programs

Third-party providers are responsible for maintaining PCI DSS compliance within their own payment processing environments. TCR is responsible for maintaining secure access to third-party payment systems, ensuring only authorized personnel have administrative/reporting access, reviewing vendor compliance documentation (Attestations of Compliance) annually, and managing vendor relationships per the Vendor & Contract Management Policy. TCR does not administer, configure, or maintain the underlying payment infrastructure operated by these providers.

Meevo: PA-DSS scope note

Meevo is PA-DSS out of scope, meaning the software itself does not store, process, or transmit cardholder data directly — it relies on Adyen (a PCI DSS Level 1 Service Provider using point-to-point encryption) to handle sensitive payment data. Because of that architecture, Meevo doesn’t fall under PA-DSS validation requirements.

Meevo is designed to align with PCI DSS, but Wi-Fi environments used for its POS terminals introduce added risk and must meet PCI DSS wireless controls specifically:

• Req. 1.2.3: all wireless access points and connected devices must be known and approved.
• Req. 2.1.1: default security settings changed (SSIDs, passwords, SNMP community strings).
• Req. 4.1.1: strong encryption (WPA2/WPA3) for all wireless transmission of cardholder data.
• Req. 11.1: a wireless analyzer regularly detects unauthorized access points.

Best practices for securing Wi-Fi POS environments: segment POS systems on a dedicated VLAN separate from guest/employee Wi-Fi; use WPA2 Enterprise or WPA3 and disable legacy protocols (WEP, WPA1); use enterprise-grade firewalls and IDS/IPS; enable automatic firmware updates on wireless hardware; run quarterly internal/external vulnerability scans; and maintain an accurate network diagram covering all wireless devices.

Targeted risk analysis (PCI DSS 4.0.1)

For requirements that allow flexibility in frequency or control implementation, TCR performs targeted risk analyses: identifying the asset being protected, the relevant threat(s), factors affecting likelihood/impact, and justifying the chosen frequency or control. These are documented and maintained by the IT Systems Coordinator, reviewed at least annually or sooner if the payment environment, providers, or threat landscape change significantly.

Cryptographic standards

TCR does not manage cryptographic implementations for payment card data — encryption in transit and at rest is implemented and maintained entirely by PCI-compliant third-party providers. Oversight consists of reviewing annual Attestations of Compliance (AOCs), confirming providers support current cryptographic protocols/cipher suites, and monitoring industry guidance on cryptographic vulnerabilities. If a vulnerability affecting a provider is identified, TCR works with that provider on remediation timelines or alternative approved services.

Access control and endpoint security

Access to third-party payment systems and related admin/reporting functions is restricted to authorized personnel with documented business need, provisioned/reviewed/revoked per TCR’s Access Management, Onboarding, and Offboarding policies. MFA is required where supported by the provider; credentials are unique, never shared. Workstations/devices accessing payment-related systems follow TCR’s standard Information Security controls (endpoint protection, patch management, configuration standards). Access follows least privilege and is reviewed periodically; anomalies or suspected misuse follow the Incident Response Plan.

Incident response for unexpected cardholder data

If a Primary Account Number (PAN) or other cardholder data is suspected or discovered on a TCR-managed system where it shouldn’t exist, TCR immediately restricts access to the affected system/data, securely removes or isolates it, determines whether sensitive authentication data is present, identifies the source, and remediates the process gap that allowed it to appear. Such incidents are handled per the Incident Response Plan and escalated to leadership and affected providers as required. Personnel with incident response responsibilities receive periodic role-appropriate training.

Review

Reviewed at least once every 12 months for continued accuracy and PCI DSS alignment, including validating that payment data continues to be fully processed by compliant third parties and that no scope-expanding changes have occurred. Updated as needed for changes in payment providers/methods, material system changes, or PCI DSS/industry guidance updates. The IT Systems Coordinator is the custodian of this addendum.

Notes

Digitized from TCR-IT-020 - PCI DSS Policy [Rev 1.0].docx and Meevo PCI.docx (folded into the Meevo scope note above); the originals are kept under source/policies/ in this repo.