PCI DSS Cross Reference/Index

This section indicates where to find information about selected PCI DSS requirements in the Theatre Manager installation documentation. The purpose of this section is so that you can look at a PCI requirement and then view where in our implementation documentation this is referenced.

The PCI Security Council supplies a document to merchants that provides a Prioritized Approach to PCI compliance. This document is quite good because it breaks down the standards into 6 milestones - what to do first, what to do second, etc. according to what will have the biggest impact in safeguarding your customer data.

Following the document and this index should help you address that most important PCI implementation standards quickly.

Source: PCI Prioritized Approach

Build and Maintain a Secure Network

In the past, theft of financial records required a criminal to physically enter an organization’s business site. Now, many payment card transactions (such as debit in the U.S. and “chip and pin” in Europe) use PIN entry devices and computers connected by networks. By using network security controls, organizations can prevent criminals from virtually accessing payment system networks and stealing cardholder data.

Requirement 1: Install and maintain a firewall

Install and maintain a firewall and router configuration to protect cardholder data

Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network.

A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.

All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

Other system components may provide firewall functionality, provided they meet the minimum requirements for firewalls as provided in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.

Section PCI Requirement Comments Provided by Artsman Cloud
1.1 Establish firewall and router configuration standards that formalize testing whenever configurations change; that identify all connections to cardholder data (including wireless); that use various technical settings for each implementation; and stipulate a review of configuration rule sets at least every six months. You will need a hardware router to protect your network.

However, if you need to set up firewalls on computers themselves, the built in firewall on windows is very flexible. On OSX, do not manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the OSX PF firewall.

1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks Refer to Recommended Network Diagram and adapt as neccessary N/A
1.1.3 Current diagram that shows all cardholder data flows across systems and networks Refer to cardholder flow N/A
1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone Refer to NGINX Server setup to describe DMZ with one or two router situation. SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
1.1.5 Description of groups, roles, and responsibilities for logical management of network components   YES
1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure

Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

Refer to Firewall rules for purpose of ports that are open. YES
1.1.7 Requirement to review firewall and router rule sets at least every six months   YES
1.2 Build a firewall configuration that denies all traffic from "untrusted" networks and hosts, except for protocols necessary for the cardholder data environment.

Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

Refer to Firewall rules to see the ports to open. YES
1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.   YES
1.2.2 Secure and synchronize router configuration files.   YES
1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. refer to venue lan setup. Wireless is not to be used in the Theatre Manager LAN segment and should be setup carefully on another separate, isolated VLAN SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.   YES
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols and ports   YES
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.   YES
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.   SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
1.3.4 Implement anti-spoofing measures to detect and block forged source IP address from entering the network.

(For example, block traffic originating from the internet with internal source addresses).

Use commercial grade firewall YES
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. Implement specific permissions as per the firewall rules SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only "established" connections are allowed into the network.) Use commercial grade firewall YES
1.3.7 Place the components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. This is generally interpreted to mean:
  • The web server should be on its own machine or VM so that it can, in effect, be sacrificed if hacked. It should have really tight firewall rules managing traffic into the device and out to ONLY the web lsitener on specific ports
  • The database and web listeners could be on the same machine as long as access to each is carefully managed with appropriate firewall rules and they are not exposed to traffic from the the main firewall appliance directly
1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties.

Note: Methods to obscure IP addressing may include, but are not limited to:

  • Network Address Translation (NAT)
  • Placing servers containing cardholder data behind proxy servers/firewalls or content caches
  • Removal or filtering of route advertisements for private networks that employ registered addressing
  • Internal use of RFC1918 address space instead of registered addresses.
1.4 Install personal firewall software on any mobile and/or employee-owned computers that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the organization's network.

Firewall configurations include:

  • Specific configuration settings are defined for personal firewall software
  • Personal firewall software is actively running
  • Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
These days, alll computers have one - it just needs enabled. SPLIT
  • Artsman: YES
  • Customer: Enable Firewall on Workstations
1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.   YES

Requirement 2: Change Vendor Passwords

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

The easiest way for hackers to access your internal network is to try default passwords or exploits based on default system software settings in your payment card infrastructure. Far too often, merchants do not change default passwords or settings when they deploy the software. This is the same as leaving your store physically unlocked when you go home for the night. Default passwords and settings for most network devices are widely known. This information, combined with hacker tools showing them what devices are on your network, can make unauthorized entry a simple task – if you have failed to change the defaults.

Section PCI Requirement Comments Provided by Artsman Cloud
2.1 Always change vendor-supplied defaults and remove or disable unneccessary default accounts before installing a system on the network

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocl (SNMP), community strings, etc.

Change the Master User password when setting up the system.

Change any other vendor supplied passwords as described.

2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Theatre Manager does NOT needs wifi for operation. Refer to venue lan setup for network diagram and what to do when placing wireless devices is a separate VLAN NO
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted hardening standards.

Sources of industry-accepted system hardening standards may include, but are not limited to:

Arts Management regularly reviews industry information and implements the latest components and security patches in installers as soon as possible. SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. For example, web servers, database servers and DNS servers should be on separate servers.

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

Refer to Network Diagram for components. Also, refer to postgres setup on windows servers YES
2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. refer to Disable SNMP service on Practical Automation Ticket Printers SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Note: SSL, TLS 1.0 and TLS 1.1 are not considered strong cryptography and cannot be used as a security control after June 30, 2016.

Effective immediately, new implementations must use TLS 1.2 or later.

POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

The NGINX Server config disables all SSL protocols and enables only TLS 1.2

Theatre Manager will connect to service providers using the latest TLS that they support and have been verified to connect via TLS 1.2 when available.

2.2.4 Configure system security parameters to prevent misuse   SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.   SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
2.3 Encrypt all non-console administrative access such as browser/web-based management tools. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access. Theatre manager does not provide or require web based management tools

We suggest that customer use RDC, Teamviewer or equivalent internally for remote access management.

and that strong security be implemented similar to the password requirements for PCI compliance and use of SSH or VPN's for conection
2.4 Maintain an inventory of system components that are in scope for PCI DSS For Theatre Manager, this includes You may need to include other point of sale terminals that you obtained from your bank. N/A
2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.   NO
2.6 Shared hosting providers must protect each entity's hosted environment and cardholder data. These providers must meed specific requirements as detailed in Appendix A: "Additional PCI DSS Requirements for Shared Hosting Providers." Not Applicable. Theatre Manager is not typically installed in a shared environment. N/A

Protect Cardholder Data

Cardholder data refers to any information printed, processed, transmitted or stored in any form on a payment card. Organizations accepting payment cards are expected to protect cardholder data and to prevent their unauthorized use – whether the data is printed or stored locally, or transmitted over a public network to a remote server or service provider.

Requirement 3: Protect stored cardholder data

Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.

Section PCI Requirement Comments Provided by Artsman Cloud
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all card holder data (CHD) storage:
  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
  • Specific retention requirements for cardholder data
  • Processes for secure deletion of data when no longer needed
  • A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements
Theatre Manager provides automatic retention and shredding capability which removes stale card information based on a retention period and/or usage for recurring transactions.

We generally recommend a maximum of 30 days for card retention, and this is only for future authorizations to supplement the original sales in case of changes. See below for post dated payments and/or which do not factor into the retention period.

There is an option to never store card information allowing a venue to implement either Schedule C or D compliance. For web Sales you can even implement Schedule A if using Moneris hosted payment.

Venues that occasionally refund to cancelled concerts do not need to store credit card data specifically for that purpose. All providers currently support linked refunds - meaning they refund to the same order and card using tokens, without needing card data stored in the database.

Post dated payments cause a card to be retained until the last automatic payment is processed, after which it is deleted.

Cloud only permits
  • Schedule A-EP - using Moneris Hosted Payments
  • Schedule C - keep no card data
  • Schedule D - with one day retention for post dated payments only
3.2 Do not store sensitive authentication data after authorization (even if it is encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process

Sensitive authentication data includes the data as cited in the following requirements 3.2.1 through 3.2.3

Refer to PCI compliance statement on PAN etc.

Should the end user put credit card data into any text field (against recommended practice), Theatre Manager offers an option to search the database for possible entry of credit card numbers in non-payment text fields.

NO - Customer must occasionally search for end user entry errors
3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: in the normal course of business, the following data elements fro mthe magnetic stripe may need to be retained:

  • The cardholders name
  • Primary account number (PAN)
  • Expiration Date
  • Service Code
To minimize risk, store only these data elements as needed for business
If a card is swiped, the only information retained from the swipe are the following
  • The cardholders name
  • Card number (PAN), encrypted
  • Expiration Date
Theatre Manager has NEVER stored CVV2, mag stripe, or pin block data per PCI requirements.
3.2.2 Do not store the card-verification code or value (three-digit or four- digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization Theatre Manager does not store this data to disk under any circumstances - it is merely passed through to the credit card authorizer. N/A
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block. Theatre Manager does not support entry or storage of PIN. N/A

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personell with a legitimate busines need can see the full PAN.

Note: this requirement does not supercede stricter requirements in place for displays of cardholder data - for example, legal or payment card rand requirements for point-of-sale (POS) receipts

Theatre Manager follows these rules. Card numbers are displayed as last four digits only and is only revealed if employee has permission - in which case it is logged.

All reports and most windows mask PAN

External receipt printing or web interface uses a common routine to mask the PAN immediately upon retrieval from the database so that last 4 digits only are displayed per law in most states.

3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
  • One-way hashes based on strong cryptography
  • Truncation (hashing cannot be used to replace the truncated segment of the PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key management processes and procedures
Note: it is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to the truncated and hashed version of a PAN.
Theatre Manager uses secure high encryption for all keys and card data. N/A
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. Theatre Manager does not use Disk Encryption.

It uses field level encryption for PAN.

3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

Note: this requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data encrypting keys. Such key encrypting keys must be at least as strong as the data-encrypting key.

Theatre Manager handles creation and hiding of keys automatically. The user never sees them and cannot input them.

Mechanisms exist for re-encryption of any currently encrypted cards in one of two ways:

  • By the user, on demand where they invoke a function to re-encrypt all card data with a new key (that they don't know)
  • By the system, if cards have not been re-encrypted within the mandated PCI time frame, Theatre Manager will start re-encrpyting them with a new key automatically

Key encryption keys use same cryptographic specification as the encryption keys.

NO - Customer must protect user account passwords
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary

Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

  • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key
  • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device)
  • As at least two full-length key components or key shares, in accordance with an industry- accepted method

Store crpytographic keys in the fewest possible locations


Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data including the following:

refer to re-encryption of credit cards for discussion on keys, generation and re-encryption. Any upgrade will automatically perform this process if more than 300 days have elapsed since last re-encrption.

Split 'knowledge' of the keys is achieved by bringing together a key generated programmatically and another portion generated by the customers interfacing with the key creation screen in system preferences.

Both keys are required to generate the final encryption key. Arts Management never has knowledge of the customers portion of the key. The customer never knows the value of any key. A key valid for one database for a period of time will not work on any other database.

Old keys are securely deleted from the database by writing over the key value and then deleting it immediately after a new seed key is generated.

NO - Customer must protect user account passwords
3.6.1 Generation of strong cryptographic keys
3.6.2 Secure cryptographic key distribution
3.6.3 Secure cryptographic key storage

Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher- text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).


Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.


If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control

for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key.

3.6.7 Prevention of unauthorized substitution of cryptographic keys
3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities

Venues do not know the cryptographic key.

However, they should have a form signed by the people/person responsible for key management that they reset the key once a year at a minimum or when suspected compromise occurs. Note it will be changed automatically on you during an upgrade if Theatre Manager detects it hasn't been changed for 300 days.


Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

  • Artsman: This documentation and Artsman staff training
  • Customer: Training of own staff

Requirement 4: Encrypt transmission of cardholder data

Encrypt transmission of cardholder data across open, public networks

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Section PCI Requirement Comments Provided by Artsman Cloud
4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
  • Only trusted keys and certificates are accepted.
  • The protocol in use only supports secure versions or configurations.
  • The encryption strength is appropriate for the encryption methodology in use

Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

  • The Internet
  • Wireless technologies including 802.11 and Bluetooth
  • Global System for Mobile communications (GSM)
  • General Packet Radio Service (GPRS).
  • Satellite communications
See Direct Card Processing which all use HTTPS.

Theatre Manager uses TLS 1.2 wherever possible to connect to credit card authorization servers for one time authorization and only allows TLS 1.2 or later for incomming web sales.

Theatre Manager does not use any wireless communication methodologies of any form.

Theatre Manager does not transmit any credit card information across public networks for any reason except in the process of authorization

  • Artsman: Uses TLS 1.2 and TLS 1.3, when available.
  • Customer: Must ensure that all workstations support TLS 1.2+
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i - aka WPA2) to implement strong encryption for authentication and transmission.

Note: The use of WEP as a security control is prohibited.

Theatre Manager does not use or require wireless capability when transmitting any card data. Refer to venue lan setup and considerations for separate wireless access points NO - If customer is using wireless networks to access cloud services, then they must secure them appropriately
4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.). see misc PCI requirements N/A - authorization of cards is only supported in Theatre Manager
4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. Venues are advised during installation about this requirement including not saving CVV2 and protecting card data in a safe if written down.

You will need write a policy on how you manually save CC data, how you track who has access to it, how you store it in a safe and/or behind locked doors.

Make sure the policy also includes that you never email card data in entirety and card data on paper is only kept as long as you need it.

Theatre Manager handles all transmission of data via TLS 1.2 or better (it only users the latest transmission security protocols as mandated by PCI.)

NO - Customer must educate own staff on card handling policies

Maintain a vulnerability Management Program

Vulnerability management is the process of systematically and continuously finding weaknesses in an organization’s payment card infrastructure system. This includes security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy.

Requirement 5: Use and regularly update anti-virus software

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

Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many business- approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.

Section PCI Requirement Comments Provided by Artsman Cloud
5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers). See specifics for SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. You must keep your anti-virus software up to date with latest definitions SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.

For Theatre Manager database and TM server, ensure those processes are the only thing running on the machine. Keep them separate from a domain server to limit who can actually log in to the server.

Check with the vendor of other systems in use.

  • Artsman: Process isolation is used extensively and services are continuously monitored
  • Customer: Workstations must be audited
5.2 Ensure that all anti-virus mechanisms are maintained as follows:   SPLIT
  • Artsman: Web sales and database
  • Customer: Workstations
5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Note: Anti-virus solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.

  • Artsman: Web sales and database
  • Customer: Workstations
5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.   SPLIT
  • Artsman: This documentation and staff training
  • Customer: Own staff training

Requirement 6: Develop and maintain secure systems and applications

Develop and maintain secure systems and applications

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

Section PCI Requirement Comments Provided by Artsman Cloud
6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as 'high', 'medium', or 'low') to newly discovered security vulnerabilities.

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization's environment and risk- assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a "high risk" to the environment. In addition to the risk ranking, vulnerabilities may be considered "critical" if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data.

  • Artsman: Web sales and database
  • Customer: Workstations
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identifies according to the risk ranking process defined in requirement 6.1

There are two settings in Company Preferences Other Tab that enable:
  • checking daily for updates to TM processes and/or
  • automatically update affected components (optional).
You may need to enable a specific outbound ports for update checking to www2.artsman.com.

Refer to the list of past and present issues to assist you updating your own vulnerability assessment.

We regularly review Postgres, NGINX & OpenSSL to provide the latest patches in each version our installers.

  • Artsman: Web sales and database
  • Customer: Workstations
6.3 Develop internal and external software application (including web-based administrative access to applications) securely, as follows:
  • in accordance with PCI DSS (for example, secure authentication and logging)
  • based on industry standard and/or best practices.
  • Incorporating information security throughout the software development life cycle.

Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

  • Artsman: Web sales and database
  • Customer: Workstations
6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.   N/A
6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
  • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices
  • Code reviews ensure code is developed according to secure coding guidelines
  • Appropriate corrections are implemented prior to release
  • Code-review results are reviewed and approved by management prior to release
6.4 Follow change control procedures for all changes to system components. The procedures must include the following:   SPLIT
  • Artsman: Theatre Manager applications, web sales and database
  • Customer: Workstations
6.4.1 Separate development/test and production environments and enforce the separation with access controls  
6.4.2 Separation of duties between development/test and production environments  
6.4.3 Production data (live PANs) are not used for testing or development Only specified test cards are used
6.4.4 Removal of test data and accounts before production systems become active  
6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures must include the following: Documentation of impact Documented change approval by authorized parties. Functionality testing to verify that the change does not adversely impact the security of the system. Back-out procedures. Development uses git and branches so that changes can be reverted.
6.5 Address common coding vulnerabilities in software development process as follows:
  • Train developers in secure coding techniquies, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory
  • Develop applications based on secure coding guidelines

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Refer to Current OWASP Top 10 SPLIT
  • Artsman: Applications and default web page templates
  • Customer: Customized web page templates
6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws
6.5.2 Buffer overflow
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 All 'high risk' vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
6.5.7 Cross-site scripting (XSS)
6.5.8 Improper Access Control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions)
6.5.9 Cross-site request forgery (CSRF) TM server ensures all <form> have CSRF token for prevention.
6.5.10 Broken authentication and session management Theatre Manager web services uses encrypted secure cookies that are httpd-only.
6.6 For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
  • Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
  • Installing an automated technical solution that detects and prevents web-based attacks (for example web-application firewall) in front of public-facing web applications, to continually check traffic

AMS updates NGINX builds as needed (and config settings) to respond to newly reported threats.

AMS uses SPI for all web traffic internally.

6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.   SPLIT
  • Artsman: This documentation and staff training
  • Customer: Own staff training

Implement Strong Access Control Measures

Access control allows merchants to permit or deny the use of physical or technical means to access PAN and other cardholder data. Access must be granted on a business need-to-know basis. Physical access control entails the use of locks or restricted access to paper-based cardholder records or system hardware. Logical access control permits or denies use of PIN entry devices, a wireless network, PCs and other devices. It also controls access to digital files containing cardholder data.

Requirement 7: Restrict access to cardholder data

Restrict access to cardholder data by business need-to-know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need-to-know and according to job responsibilities.

Need-to-know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

Section PCI Requirement Comments Responsibilities on Artsman Cloud
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.   Artsman: web sales and database
Customers: user access setup/permissions
7.1.1 Define access needs for each role, including:
  • System components and data resources that each role needs to access for their job function
  • Level of privilege required (for example, user, administrator, etc.) for accessing resources
Access to various data can be set on a per user basis in Employee Access Customers: user access setup/permissions
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. Creating a user in Theatre Manger defaults to minimal access to card data/ and/or functions. Users are advised to only use the administrator account on a rare-need to administer the system basis. Customers: user access setup/permissions
7.1.3 Assign access based on individual personnel's job classification and functions   Customers: user access setup/permissions
7.1.4 Require documented approval by authorized parties specifying required privileges   Customers: user access setup/permissions
7.2 Establish an access control system for systems components that restricts access based on a user's need to know, and is set to "deny all" unless specifically allowed.

This access control system must include the following:

7.2.1 Coverage of all system components Refer to employee settings and function access for credit cards Customers: user access setup/permissions
7.2.2 Assignment of privileges to individuals based on job classification and function Customers: user access setup/permissions
7.2.3 Default "deny-all" setting Customers: user access setup/permissions
7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.   Customers: user access setup/permissions

Requirement 8: Assign a unique ID to each person

Assign a unique ID to each person with computer access

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.


  • These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).
  • However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

Section PCI Requirement Comments Responsibilities on Artsman Cloud
8.1 Define and implement policies and procedures to ensure proper user identification management for non- consumer users and administrators on all system components as follows: Theatre Manager implements PCI standards. You may need a manual process for other applications or hardware. Customer: via Theatre Manager
8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.  
8.1.3 Immediately revoke access for any terminated users.  
8.1.4 Remove/disable inactive user accounts within 90 days. Refer to the PCI Security Tab in System Preferences for settings. Theatre Manager enforces stronger password policies than the minimum PCI standards.
8.1.5 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
  • Enabled only during the time period needed and disabled when not in use.
  • Monitored when in use.
Theatre Manager uses Teamviewer for one-time access, granted as needed.
8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. Theatre Manager limits incorrect password attempts to a total of 6 since the last successful attempt and locks out the account on failure.
8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. Lockout duration in Theatre Manager is permanent. Locked out employee must be re-instated by administrator.
8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. Theatre Manager has two timeouts. After 15 minutes of inactivity, the user will see a lock screen and need only put in their password again to continue.

There is a longer timeout in Company Preferences->Reports where you can specify when an idle user will be forced log off the system.

The process is:

  • After 15 minutes, lock the screen and require a only a password to continue. This means any sales in progress or reports on screen will not be closed and are available once you enter your password after 15 minutes
  • After the longer timeout, quit Theatre Manager completely.
In addition to the feature built into Theatre Manager for auto log out, you are encouraged to use the screen saver provisions that require passwords after the screen saver is activated.
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card, specific IP, key access to a locked room
  • Something you are, such as a biometric
  Customer: password via Theatre Manager, tokens and biometrics for Operating System login
8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. Passwords are never transmitted in clear text when logging on to the database.

User Passwords are stored in the database in encrypted format and established in PostgreSQL as a hash of that encrypted value.

When a user logs in, the password is converted to the salted hash and that is used to login. All communication to the PostgreSQL Database is over a secure connection, currently TLS 1.2 or better.

automatic via Theatre Manager
8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys. Only administrators are able to reset a password, reinstate an employee and/or regenerate credit card encryption keys. automatic via Theatre Manager
8.2.3 Passwords/phrases must meet the following:
  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
Theatre Manager enforces
  • Minimum 7
  • One upper
  • One lower
  • One numeric
  • One Special
  • No repeated characters
automatic via Theatre Manager
8.2.4 Change user passwords/passphrases at least once every 90 days. Theatre Manager enforces this Customer: follow Theatre Manager prompts to change password
8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used. Theatre Manager enforces 12 and that can be raised automatic via Theatre Manager
8.2.6 Set passwords/phrases for first- time use and upon reset to a unique value for each user, and change immediately after the first use. Theatre Manager enforces change of password at time of login for first time users automatic via Theatre Manager
8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

Examples of two-factor tehcnologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens, and other technologies that facilitate two-factor authentication.

Two factor authentication means something you know and something you are given. Our QSA (the auditor who assesses Theatre Manager's ability to meet PCI compliance) has indicated that Teamviewer meets that requirement when used per the instructions. The multiple factors include:
  • The user must start the application manually (it is not active by default)
  • A unique Id must be provided to Artsman by the customer
  • A single use token must be provided to ArtsMan that cannot be reused.
effectively being 3 factors that must occur for access to be granted successfully.
automatic via Theatre Manager
8.4 Document and communicate authentication policies and procedures to all users including:
  • Guidance on selecting strong authentication credentials
  • Guidance for how users should protect their authentication credentials
  • Instructions not to reuse previously used passwords
  • Instructions to change passwords if there is any suspicion the password could be compromised.
All Theatre Manager user passwords are encrypted in the database. MD5 authentication is recommended at a minimum for accessing the database (this is the default standard in the pg_hba.conf file) automatic via Theatre Manager
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
  • Generic user IDs are disabled or removed.
  • Shared user IDs do not exist for system administration and other critical functions.
  • Shared and generic user IDs are not used to administer any system components.
There are no generic passwords. User ID's and Passwords are created by the user on installation. automatic as part of Theatre Manager installation practices
8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

Arts Management does not require permanent remote access to your servers. Temporary access is always initiated by the customer as described in the teamviewer remote support help page. Customer: provides Local access via Teamviewed if required
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
  • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
  • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
  Artsman: cloud
Customer: workstation
8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
  • All user access to, user queries of, and user actions on databases are through programmatic methods.
  • Only database administrators have the ability to directly access or query databases.
  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

Access to the db is controlled by the pg_hba.conf file and it is set so that all users must log in to read data.

The user's id for the database is set by the application and not known.

The password in postgres is set by the application and stored encrypted. Thus, the user cannot access the database even knowing their user ID and password because it is not the same as plain-text.

Cloud database access for users is managed through an access broker system (with revokable tokens) followed by customer user id/password

Artsman: cloud
Customer: workstation
8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.   Artsman: cloud
Customer: workstation

PCI UserId and Password Requirements

Theatre Manager implements fully PCI DSS compliant AES256 encrypted passwords per PCI DSS standard 8.1 and this feature cannot be changed or overridden.

In addition, Merchants must use PCI DSS compliant passwords to access to all system components (i.e. any computer, firewall, router, etc. on the network) and these passwords must be changed from any vendor supplied initial values per PCI standard 2.1.

Note: Do not reduce the level of authentication complexity or compliance in these other system components if it will result in PCI non-compliance.

This means all login passwords must be:

  • reviewed and changed every 90 days. Theatre Manager will enforce password changes automatically. This must be manually done on those devices that do not force change of passwords like routers and firewalls. (PCI DSS 8.1.4)
  • 7 characters or more (PCI DSS 8.2.3)
  • mixed case consisting of at least uppercase and one lowercase letter (PCI DSS 8.2.3)
  • contain at least one number and special character (PCI DSS 8.2.3)
  • cannot be the same as an previous 12 passwords (PCI DSS 8.2.5)
  • cannot have characters or numbers repeated together
Change all passwords from any vendor default password that might be used for installation per PCI DSS 2.1. For example, you must:
  • Change the Theatre Manager 'Master User' password when the system is installed.
  • Change the user and password on any router from anything printed in the manufacturer's documentation
  • Make sure that accessing each computer requires a password and does not 'auto-login'
  • Ensure that screen savers are implemented that require passwords to be entered whenever the screen saver is activated. Screensavers (or some other mechanism for locking computers) must activate after 15 minutes of idle time or less on all workstations and servers. Theatre Manager also has an inactivity timeout that will log people out of the application. Using both features improves security. (PCI DSS 8.1.8)

Each user that has access to any systems in your network must have a unique user id and password per PCI-DSS standard 8.1.1

Never use the Master User account for daily operations.

It should only be used when creating other accounts or for other very specialized needs as directed by Arts Management Systems.

If your network has 'master' domain server (or open directory on OSX) available that could control password authentication for all machines, please ensure that the security policies on the domain/directory server is set to enforce PCI/DSS passwords and that all machines in the network log in using authentication from the server.

If a domain/open directory server is not available to enforce password settings, then each machine/user must use PCI/DSS compliant passwords.

If a user tries more than 6 times to gain access to the system, Theatre Manager automatically resigns the user - which means that they are locked out permanently until manually re-instated per PCI-DSS standard 8.1.6 and 8.1.8

Teamviewer: ArtsMan Technical Support

Theatre Manager staff should not required permanent access to your machines, except under very specific circumstances. The remote access feature in Theatre Manager is designed for one time, permitted access.

Remote Access/Support

The process for actual access to the remote machine is as follows:

  • The customer must initiate a support request that involves a phone conversation
  • In that phone conversation, it is determined that a timely resolution involves connecting remotely to provide assistance
  • Arts Management confirms the identity to the customer by providing the customer with the case number they created to continue with support (PCI requirement for second authentication).
  • The customer then starts the remote assistance software by either:
    • clicking the Remote Assistance button on the toolbar after logging into Theatre Manager. It is on the right side of the toolbar as per the above image. Since you must have logged into Theatre Manager to activate remote support, It is not active by default. -OR-
    • By starting Theatre Manager and clicking the Support button on the login page as per the diagram to the right. This is useful if you are unable to log in for any purpose
  • The customer provides two keys created by Teamviewer: an ID and a random generated 8 character password (containing numbers and letters and, unique to the session) as per the image below. Both of these are conveyed to the AMS support representative.
  • Arts Management Support activates remote assistance manager and enters both keys to gain remote access
When Remote Access is disconnected, another remote support session requires a new set of keys to be provided. The customer is in complete control of the session at all times with a visual indicator showing the connection status.


How does it work?

TeamViewer uses SSH for authentication and brokering of session keys. It communicates with the master cluster through DNS names, which delegates the brokering of the session to the TeamViewer servers. Connection to the routing server and KeepAlive server is done directly via IP addresses.

The servers are spread across the globe and located at large data centers; their IP addresses are not organized in common subnets or IP ranges. TeamViewer continuously top scales the server network as the number of TeamViewer users grows, so it is not possible to have a fixed set of IP addresses, because this list would very soon be outdated.

Communication is done to URLs of the format:

  • *.teamviewer.com
  • *.dyngate.com
By default TeamViewer uses only the outgoing port 80 (HTTP) so that no firewall configuration is necessary. Alternatively you can open port 5938 (TCP) for outgoing connections if you wish to block port 80.

Requirement 9: Restrict physical access to cardholder data

Restrict physical access to cardholder data

Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. “Media” refers to all paper and electronic media containing cardholder data.

Section PCI Requirement Comments Responsibilities on Artsman Cloud
9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. This means locks on a computer room door or places (like box office) where people can access machines that can access card holder data. Artsman: cloud
Customer: workstation
9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

Note: "Sensitive areas" refers to any data center, server room or any area trefers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of- sale terminals are present, such as the cashier areas in a retail store.

  Artsman: cloud - SOC 2 compliant data centres
9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks.

For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.

  Artsman: cloud - SOC 2 compliant data centres
Customer: internal network
9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.   Artsman: cloud - SOC 2 compliant data centres
Customer: internal network
9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:
  • Identifying onsite personnel and visitors (for example, assigning badges)
  • Changes to access requirements
  • Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
Artsman: cloud - SOC 2 compliant data centres
Customer: internal network
9.3 Control physical access for onsite personnel to sensitive areas as follows:
  • Access must be authorized and based on individual job function.
  • Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.
  Artsman: cloud - SOC 2 compliant data centres
Customer: internal procedures
9.4 Implement procedures to identify and authorize visitors.

Procedures should include the following:

  Artsman: cloud - SOC 2 compliant data centres
Customer: internal procedures
9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.  
9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel.  
9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration.  
9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.

Document the visitor's name, the firm represented, and the onsite personnel authorizing physical access on the log.

Retain this log for a minimum of three months, unless otherwise restricted by law.

9.5 Physically secure all media   Artsman: cloud - SOC 2 compliant data centres
Customer: internal procedures
9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location's security at least annually.   Artsman: cloud - SOC 2 compliant data centres
9.6 Maintain strict control over the internal or external distribution of any kind of media, including the following:   Artsman: cloud - SOC 2 compliant data centres
Customer: internal procedures
9.6.1 Classify media so the sensitivity of the data can be determined.  
9.6.2 Send the media by secured courier or other delivery method that can be accurately tracked.  
9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals).  
9.7 Maintain strict control over the storage and accessibility of media.    
9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.   Artsman: automated backups, recycle and deletion policies
9.8 Destroy media when it is no longer needed for business or legal reasons as follows:    
9.8.1 Shred, incinerate, or pulp hard- copy materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed.   Artsman: automated secure deletion
9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. There is a tool on windows called Eraser that will handle this for you. On the Mac, use Secure-Empty Trash. Refer to this link for more information about using them. Artsman: automated secure deletion Customer: should ensure no local cardholder storage in spreadsheets etc
9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

Note: These requirements apply to card- reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

This does not apply to Theatre Manager as it does not use card reading devices for card present transactions. Customer: protect any pin pad devices accordingly
9.9.1 Maintain an up-to-date list of devices. The list should include the following:
  • Make, model of device
  • Location of device (for example, the address of the site or facility where the device is located)
  • Device serial number or other method of unique identification.
For point of sale devices Customer: wokstation inventory
9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

For point of sale devices Customer: wokstations and /or pinpad
9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:
  • Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.
  • Do not install, replace, or return devices without verification.
  • Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
  • Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
For point of sale devices Customer: wokstations and/or pinpad
9.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.   Artsman: Cloud
Customer: wokstations and devices

Regularly Monitor and Test Networks

Physical and wireless networks are the glue connecting all endpoints and servers in the payment infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain unauthorized access to payment card applications and cardholder data. To prevent exploitation, organizations must regularly monitor and test networks to find and fix vulnerabilities.

Requirement 10: Track and monitor all access to network

Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

Section PCI Requirement Comments Responsibilities on Artsman Cloud
10.1 Implement audit trails to link all access to system components to each individual user.   Artsman: via Theatre Manager
Customer: workstation
10.2 Implement automated audit trails for all system components to reconstruct the following events:    
10.2.1 All individual accesses to cardholder data Refer to PCI Audit Logs. Theatre Manager tracks every time a user views the entire credit card data for any patron.

The Theatre Manager logs can be exported to your common logging tools. Refer to exporting logs to see how to accomplish this.

Theatre Manager tracks access to card data for Customers
10.2.2 All actions taken by any individual with root or administrative privileges Not applicable to Theatre Manager - it is applicable to your operating system. Only access to CC data is via Theatre Manager
10.2.3 Access to all audit trails   via Theatre Manager
10.2.4 Invalid logical access attempts Incorrect login attempts to Theatre Manager are tracked in the audit logs. via Theatre Manager
10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges Theatre Manager tracks each log in and log out, user creations and when people are given a temporary priviledge. These transaction are of type 'A' in the database (for Audit) via Theatre Manager
10.2.6 Initialization, stopping, or pausing of the audit logs Theatre Manager access audit logs cannot be stopped or deleted via Theatre Manager
10.2.7 Creation and deletion of system-level objects This is not possible in Theatre Manager Theatre Manager does not allow entity deletion
10.3 Record at least the following audit trail entries for all system components for each event: refer to PCI audit Log description via Theatre Manager
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource
10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

Note: One example of time synchronization technology is Network Time Protocol (NTP).

You must allow each computer to access a respected NTP Server (network time protocol). This is typically built into the operating system and firewall rules should automatically enable this feature.

Theatre Manager uses the time at the postgres server as the single time source for transactions across all workstations. All data istimestamped with now(), making time diferences on workstations irrelevant.

Regardless, an alert is given to a user if their workstation does not match the server to within 30 seconds.

Effectively, if the postgres server is set according to an NTP server; all workstations transactions are synced with the postgres server to create a unified approach to time.

via Theatre Manager
10.4.1 Critical systems have the correct and consistent time
10.4.2 Time data is protected
10.4.3 Time settings are received from industry-accepted time sources
10.5 Secure audit trails so they cannot be altered   Artsman: SOC 2 compliant data centres with real time monitoring and logging
Customer: Workstation controls
10.5.1 Limit viewing of audit trails to those with a job-related need Theatre Manager logs are not sensitive in themselves due to what they track. However, after exporting them and storing them in your centralized logging facility, you will need to limit access because of the other systems you may be logging.
10.5.2 Protect audit trail files from unauthorized modifications. You cannot modify or delete Theatre Manager logs
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. In addition to exporting logs, the multiple daily database backups create redundancy in the storage of the TM audit logs.
10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN. This means things like router logs need to be stored internally.
10.5.5 Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).  
10.6 Review logs and security events for all system components to identify anomalies or suspicious activity Refer to exporting logs to see how to export TM access logs in excel format so that you can import to your common log server. Artsman: SOC 2 compliant data centres with real time monitoring and logging
Customer: Workstation controls
10.6.1 Review the following at least daily:
  • All security events
  • Logs of all system components that store, process, or transmit CHD and/or SAD
  • Logs of all critical system components
  • Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
PCI Audit Logs
10.6.2 Review logs of all other system components periodically based on the organization's policies and risk management strategy, as determined by the organization's annual risk assessment.  
10.6.3 Follow up exceptions and anomalies identified during the review process.  
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup). PCI logs are permanent in the database via Theatre Manager
10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.   Artsman: web sales and database
Customer: workstation

Requirement 11: Regularly test security systems and processes

Regularly test security systems and processes

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

Section PCI Requirement Comments Responsibilities on Artsman Cloud
11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.

Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

iStumbler is a great little tool on the mac that is donation ware - it can find a lot of items that are broadcasting signals.

Alternately, inspect each device that is within the card portion of the network and make sure wireless is off.

Note: on AMS cloud servers, all network connections are physical wiring - there are no possible WIFI access points.

Artsman: N/A - no access points
Customer: workstations
11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification.   Artsman: N/A - no access points
Customer: workstations
11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected.   Artsman: N/A - no access points
Customer: workstations
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies

  1. the most recent scan result was a passing scan,
  2. the entity has documented policies and procedures requiring quarterly scanning, and
  3. vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred.
  Artsman: web sales and database scans
Customer: workstation scans
11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all "high-risk" vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.   Artsman: web sales and database
Customer: workstations
11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

  Artsman: web sales and database
Customer: workstations
11.2.3 Perform internal and external scans, and rescans as needed, after any significant change.

Scans must be performed by qualified personnel.

  Artsman: web sales and database
Customer: workstations
11.3 Implement a methodology for penetration testing that includes the following:
  • Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
  • Includes coverage for the entire CDE perimeter and critical systems
  • Includes testing from both inside and outside the network
  • Includes testing to validate any segmentation and scope-reduction controls
  • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
  • Defines network-layer penetration tests to include components that support network functions as well as operating systems
  • Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
  • Specifies retention of penetration testing results and remediation activities results.
  Artsman: web sales and database tests
Customer: workstation tests
11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).   Artsman: web sales and database
Customer: workstations
11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).   Artsman: web sales and database
Customer: workstations
11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.   Artsman: web sales and database
Customer: workstations
11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.   Artsman: web sales and database
Customer: workstations
11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

  Artsman: web sales and database
Customer: workstations
11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

  Artsman: web sales and database
Customer: workstations
11.5.1 Implement a process to respond to any alerts generated by the change- detection solution.   Artsman: web sales and database
Customer: workstations
11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties   Artsman: web sales and database
Customer: workstations

Maintain an Information Security Policy

A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.

Requirement 12: Maintain a policy that addresses information security for employees and contractors

Maintain a policy that addresses information security for employees and contractors

As part of Theatre Manager's PA-DSS implementation process, creating a policy guide will be brought to the attention of venues desiring to be PCI compliant

Section PCI Requirement Comments Responsibilities on Artsman Cloud
12.1 Establish, publish, maintain, and disseminate a security policy. This relates to practices surrounding PCI Card data Artsman: Network Security Policy for Employees/cloud (ams/network-security) Customer: employees & workstations
12.1.1 Review the security policy at least annually and update the policy when the environment changes.   Artsman: cloud
Customer: workstations
12.2 Implement a risk-assessment process that:
  • Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
  • Identifies critical assets, threats, and vulnerabilities, and
  • Results in a formal, documented analysis of risk.
Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
  Artsman: cloud
Customer: Review own document
12.3 Develop usage policies for critical technologies and define proper use of these technologies.

Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Ensure these usage policies require the following:

  Artsman: cloud
Customer: workstations
12.3.1 Explicit approval by authorized parties   Artsman: cloud
Customer: workstations
12.3.2 Authentication for use of the technology   Artsman: cloud
Customer: workstations
12.3.3 A list of all such devices and personnel with access Arts Management allows only tools approved for use by Management on workstations. The customer is responsible for tools on their machines. Artsman: cloud
Customer: workstations
12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices)   Artsman: cloud
Customer: workstations
12.3.5 Acceptable uses of the technology   Artsman: cloud
Customer: workstations
12.3.6 Acceptable network locations for the technologies   Artsman: cloud
Customer: workstations
12.3.7 List of company-approved products   Artsman: cloud
Customer: workstations
12.3.8 Automatic disconnect of sessions for remote access technologies after a specific period of inactivity   Artsman: cloud
Customer: Workstations have limited login time per System Preferences.
12.3.9 Activation of remote access technologies for vendors only when needed by vendors, with immediate deactivation after use Team Viewer is designed in exactly this manner.
  • Artsman support is trained to only ask for one time access if needed and disconnect when done.
  • The customer is required to provide the access and quit Teamviewer when a session is over.
Customer: workstations
12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.

Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

All card data in the database at rest is encrypted or shredded. All card data in motion is encrypted via TLS 1.2 between machines and enforced by database connection. Reports do not show complete PAN, per PCI compliance

Customer: responsible for local policies secure storage of paper copies of PAN data and not transmitting to patrons via email.
12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.   Artsman: cloud
Customer: workstations
12.5 Assign to an individual or team the following information security management responsibilities   Artsman: cloud
Customer: workstations
12.5.1 Establish, document, and distribute security policies and procedures.  
12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.  
12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.  
12.5.4 Administer user accounts, including additions, deletions, and modifications  
12.5.5 Monitor and control all access to data.  
12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.   Artsman: this document and staff training
Customer: own staff training
12.6.1 Educate employees upon hire and at least annually.

Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.

  Artsman: cloud
Customer: workstations
12.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures. This can be a signed document that they have reviewed the security policy Artsman: cloud
Customer: workstations
12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

  Artsman: cloud
Customer: workstations
12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows: Theatre Manager is designed so that cardholder data cannot be shared with any body. Staff do not have access to card data. Customer: workstations- inform staff not to share card data
12.8.1 Maintain a list of service providers. We suggest placing them in Theatre Manager and adding them to a mail list called PCI Compliance contacts Artsman: cloud
Customer: workstations
12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer's cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

  Artsman: cloud
Customer: workstations
12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.   Artsman: cloud
Customer: workstations
12.8.4 Maintain a program to monitor service providers' PCI DSS compliance status at least annually. Arts Management is responsible to ensure Theatre Manager is audited for PCI-DSS and approved by the PCI council. Artsman: vendor PCI DSS annually
Customer: merchant responsibilities
12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.   Customer: this document describes areas which Artsman is responsible
12.9 Additional requirement for service providers only: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer's cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include th

  • Theatre Manager provides technology to manage data securely in PCI context but does not enter or use card data, nor maintain any merchant accounts on behalf of the customers.
  • Each customer is solely responsible for engaging a merchant provider, processing all card (using Theatre Manager to assist). deciding on card data retention requirements, and maintaining policies for managing their data and merchant relationship.
12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach.   Artsman: cloud
Customer: workstation
12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
  • Roles, responsibilities and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
  • Specific incident response procedures
  • Business recovery and continuity procedures
  • Data backup processes
  • Analysis of legal requirements for reporting compromises
  • Coverage and responses of all critical system components
  • Reference or inclusion of incident response procedures from the payment brands
12.10.2 Test the plan at least annually.  
12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.  
12.10.4 Provide appropriate training to staff with security breach response responsibilities.  
12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion- prevention, firewalls, and file-integrity monitoring systems.  
12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.