1. Skip to content

Payment card industry data security standard policy

Introduction

Payment Card Industry Data Security Standard (PCI-DSS) is the global data security standard adopted by the payment card brands for all entities that process, store or transmit cardholder data.

It consists of a number of steps and security best practices that help to ensure the secure processing of sensitive data throughout the council, and the council has an obligation to protect confidential cardholder information through compliance with PCI DSS.

Failure to comply with these regulations could result in cardholder data becoming compromised, data security breaches, substantial fines, severe reputational damage and/or the loss of income, and potentially the revoking of the council’s authority to accept card payments.

This policy applies to anyone performing council duties or providing council services facilitating card payments. It applies to Councillors, other organisations conducting council business, employees, contractual third parties and agents of the council.

Anyone who uses the council’s systems should be made aware of and be expected to comply with this policy and need to understand that the PCI DSS requirements relevant to protecting cardholder information:

A serious breach of this policy could be regarded as gross misconduct and may lead to dismissal and / or criminal action being taken.

Compliance with this policy is part of your employment contract. All incidents will be investigated, and action may be taken under the council’s formal disciplinary procedure. A serious breach of this policy could be regarded as gross misconduct and may lead to dismissal and / or criminal action being taken. In the most serious cases, this could be dismissal without warning.

Aims and objectives

The objective of this policy is to ensure that all card processing activities of the council will comply with the PCI-DSS industry standard. No activity or technology may obstruct compliance with the PCI DSS.

This policy aims to set out the requirements of the PCI DSS in respect of the transmission, processing and storage of cardholder data, and the key responsibilities in connection with the achievement and maintenance of compliance with PCI DSS. It applies to all individuals and systems within the council that come into contact with cardholder data, whether this is electronic, or paper based.

PCI DSS applicability to the council

The council does not store payment card data but does process and transmit card payments which are subsequently handled by external ‘service providers’ who are each certified as being PCI DSS compliant.

The council is a ‘Level 3 Merchant’ (processing between 20,000 and 1,000,000 transactions per annum) which means that certification to the Standard requires the completion of an annual Self–Assessment Questionnaire (SAQ) to demonstrate compliance. There are a number of different SAQs available and the council needs to submit a SAQ that is relevant to its Cardholder Data Environment (CDE).

Roles and responsibilities

The recognised user groups are:

Services must comply with this policy to minimise the risk to both customers and the council. Failure to comply will render the council liable for fines and may also result in preventing card transactions from being processed.

Definitions

PCI DSS is concerned with account data for debit and credit cards. Account data is made up of cardholder data and sensitive authentication data (also known as sensitive information), and there are specific rules around the use, storage and transmission of these two types of data.

Cardholder data refers to the card number across the centre of the card (otherwise known as the Primary Account Number, or PAN), the cardholder name, the expiry date and the service code (also known as the security code).

The primary account number is the defining factor for cardholder data. If the cardholder name, service code, and/or expiry date are stored, processed or transmitted with the PAN, they must be protected in accordance with the PCI DSS requirements. Storage of cardholder data is permitted but must always be protected with strong encryption. If the PAN is not stored, this requirement is lifted.

Sensitive information is security-related information. This includes (but is not limited to) card validation codes, full track data (from the magnetic stripe or equivalent on a chip), PINs and PIN blocks. This information is used to authenticate cardholders and/or authorise payment card transactions.

Under no circumstances can sensitive information be stored in any form after authorisation.

Approach to PCI DSS compliance

Full compliance to the highest level of requirements is very resource intensive. Where possible, we will look to use systems and processes that reduce the level of compliance required. For this reason, it is important to consult the Finance Officer before starting any process re-design, and particularly any procurement process, involving card payments. It is also important to think about the visibility of cardholder data during the processing of the payment, so the PCI Compliance Officer should also be consulted regarding office moves.

The requirements set out below are based on the full PCI DSS requirements. Implementing systems and processes that reduce the compliance level required will mean that the requirement could be not applicable to all channels. However, they are included in the policy document so that we have an agreed process to follow should any channel be identified as being of the highest compliance level.

Compliance actions

Other actions will be taken to encourage compliance, namely:

Security process and standards reference to SAQ

Build and maintain a secure network and system

To protect sensitive or confidential data, it is critical to design and maintain a secure network infrastructure where this data can be processed and transmitted. The following polices cover the network infrastructure (hardware such as firewalls, routers, and switches) as well as requirements for the secure configuration of all system components (for example, network hardware, servers, workstations).

Install and maintain a firewall configuration to protect card holder data

Firewalls are devices that control computer traffic allowed between LBE networks (internal) and untrusted networks (external). A firewall examines all network traffic and blocks those transmissions that do not meet LBE 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 email 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, as long as they meet the minimum requirements for firewalls as defined in this requirement. 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.

Prohibit direct public access between the Internet and any system component in the cardholder data environment

LBE will prohibit direct public access between the Internet and any system component in the cardholder data environment by doing the following:

Restrict connections between untrusted network segments and the cardholder data environment

LBE will restrict connections from untrusted network segments to system components within the cardholder data by doing the following:

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

System components used in sensitive networks often will come with default vendor settings (for example, usernames, passwords, configuration settings). LBE’s general policy is to always change vendor-supplied defaults for system passwords or other security parameters before systems are installed in the secure network environment (cardholder data network).

Change vendor supplied defaults

All vendor-supplied defaults must be changed on all system components before being used in the cardholder data network. (for example, passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts). (PCI-DSS Requirement 2.1, 2.2.d).

System hardening and standard configuration of devices

Documented system configuration standards must:

Use secure protocols for non-console access

Strong cryptography must be used for any non-console or web-based management interface used for administration of systems or system components. (Use technologies such as SSH, VPN, or the latest secure versions of TLS for web-based management and another non-console administrative access.) (PCI-DSS Requirement 2.3).

Security policies and operational procedures documentation

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. (PCI-DSS Requirement 2.5).

Protect cardholder data

Cardholder data (PAN and sensitive authentication data) must not be stored electronically. Credit card data has many sensitive components, including the Primary Account Number (PAN), magnetic stripe authentication data (Track1, Track2), Card Verification Code (CVC), and the Personal Identification Number (PIN).

Storage of sensitive credit card authentication data

Encrypt transmission of cardholder data across open, public networks

Cardholder data 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.

Transmission of card data over public networks

Transmission of card data via end user messaging technologies

It is prohibited to transmit cardholder data via end-user messaging technologies (for example, email, instant messaging). (PCI-DSS Requirement 4.2).

Maintain a vulnerability management program

System components within the cardholder data network (PCIDSS DMZ) must be part of an active vulnerability maintenance program. This program will control the existence of malicious software (for example, anti-virus software) and provide policies covering development efforts and system or software updates/upgrades such that security is maintained.

Deploy anti-virus software to protect systems

Ensure that all anti-virus mechanisms are current

Ensure that all anti-virus mechanisms are actively running

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 that 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.

Vulnerability risk ranking process

Regularly update systems and software

Restrict access to cardholder data by business need to know

Systems and processes must be in place to limit access to critical data and systems based on an individuals need to know and according to job responsibilities.

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

Restrict access to cardholder data and systems in cardholder data environment

Identify and authenticate access to system components

It is critical to assign a unique identification (ID) to each person with access to critical systems or software. This ensures that each individual is uniquely accountable for his or her 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.

Vendor access

Manage IDs used by vendors to access, support, or maintain system components via remote access, ensuring that they are only enabled for the time period needed, disabled when not in use and they are monitored by LBE employees during use. (PCI DSS Requirement 8.1.5a-b).

User authentication methods

In addition to assigning a unique user ID, access to systems in the card network requires the use of at least one of the following: (PCI DSS Requirement 8.2)

Multi-factor authentication

Incorporate multi-factor authentication for all non-console administrative access to the cardholder data environment. Multi-factor authentication is also required for all remote access originating from outside the cardholder data environment by personnel, including users and administrators and all third parties, including vendor access for support or maintenance. (PCI DSS Requirement 8.3).

Group or shared accounts and passwords

Do not use group, shared, or generic accounts or passwords or other authentication methods as follows: (PCI DSS Requirement 8.5.)

Security policies and operational procedures documentation

Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties. (PCI DSS Requirement 8.8).

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.

If sensitive cardholder data is ever discovered or received, management must be notified and it shall be immediately destroyed, redacted, or truncated following the information in section 9.8 of this policy. (PCI-DSS Requirement 9.8).

Limits and monitor physical access to systems

Restrict access to network jacks by implementing physical and/or logical controls. (PCI-DSS Requirement 9.1.2)

Protection from tampering and substitution

Regularly monitor and test networks

Important components of overall system security are the regular testing of networks for exposed vulnerabilities and the continuous monitoring of security indicators (for example, logs, system events). The following policies address system monitoring and vulnerability testing.

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 without system activity logs. Detailed monitoring procedures should be developed and documented to meet the following policies.

Generation of audit trails

Implement automated audit trails for all system components to capture the following events: (PCI DSS Requirement 10.2)

Audit trail entries

Record at least the following audit trail entries for all system components for each event: (PCI DSS Requirement 10.3)

Log review

Review logs and security events for all system components to identify anomalies or suspicious activity by performing the following: (PCI DSS Requirement 10.6)

Audit trail history

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 DSS Requirement 10.7).

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 must be tested frequently to ensure security controls continue to reflect a changing environment. Detailed testing procedures should be developed and documented to meet the following policies.

Vulnerability assessment scans

Internal and external vulnerability assessment scans must be performed at least quarterly and after any significant change in the cardholder data environment (for example, changes in firewall rules, or upgrades to products within the environment). (PCI DSS Requirement 11.2, 11.2.3).

Internal vulnerability scans must: (PCI DSS Requirement 11.2.1.a-c)

External vulnerability scans must: (PCI DSS Requirement 11.2.2.a-c)

Ensure that results of each quarter’s internal and external vulnerability assessments are to be documented and retained for review. (PCI DSS Requirement 11.2).

Penetration testing

If segmentation is used to isolate the Cardholder Data Environment from other networks, a segmentation test is required to confirm all methods of segmentation are effective in isolating the Cardholder Data Environment from out-of-scope systems one to works. These tests must be documented and performed at least annually and after any changes to segmentation controls or methods. (PCI DSS Requirement 11.3.4).

Change detection

Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files, and configure the software to perform critical file comparisons at least weekly. (PCI DSS Requirement 11.5)

Maintain a security policy that addresses information security for all personnel

A strong security policy sets the security tone for LBE and informs employees and vendors what is expected of them. All employees and vendors should be aware of the sensitivity of data and their responsibilities for protecting it.

Publish, distribute, and update the information security policy

Assign information security responsibilities and train employees

Assign information security management

Security awareness program

Policies for sharing data with service providers

Incident response plan policies

Incidents or suspected incidents regarding the security of the cardholder data environment or cardholder data itself must be handled quickly and in a controlled, coordinated and specific manner. An incident response plan must be developed and followed in the event of a breach or suspected breach. The following policies specifically address the LBE incident response plan:

Security breaches

In the event of there being a security breach of data, staff must report the breach to the DS Service Desk who will follow our Incident Handling Procedure. The Finance Manager must be involved in the investigation.

The PCI Compliance Officer must then contact the customer and/or card provider to ensure that card processing is discontinued immediately if this is appropriate. Additionally if there is a risk to Rights and Freedoms of individuals there is a requirement to report any breach to the Data Protection regulator - please see the Data Protection Policy.

Corporate card payment systems

The council has a corporate electronic card payments system which allows various types of income to be paid using a number of means as listed below:

Online processing

In the first instance customers should make payment for goods and services online using the Pay Online link on the Enfield website, however only certain payments are set up to pay using this method. This is the preferred method and best practice for taking payments.

On completion of a successful payment the online system being used will automatically generate an email payment confirmation to the customer. This is the only Finance confirmation document that will be received by the customer for the payment.

If a customer’s payment has been unsuccessful or declined, the customer in the first instance should contact their card provider. The most common reason for a declined transaction is the card provider suspecting the transaction may be fraudulent.

If a customer faces difficulty in making a payment then they can contact the Customer Service Centre where an agent will answer queries and can take the payment over the telephone if necessary.

Telephone processing

Various payments can be taken over the telephone by either a Customer Service Centre agent or specific service officer. Card details must never be written down by any member of staff for a future payment attempt. For all card details which are processed through the corporate payments system, no card details are retained by the authority.

There is no internal council access to full card details as this information is not stored within the council’s IT network.

Card payment terminals (PDQ machines)

There are specific services that use PDQ terminals and not the Corporate Payments System. Where these terminals are used the following procedures apply.

Customer present with a card

When the customer is present the card should be processed through the PDQ machine according to the machine instructions.

If the transaction is successfully processed, the merchant copy should be stored securely (see Storage of Card Details) and the customer copy given to the customer.

If the transaction is declined, the customer should be advised immediately. The option of paying with a different card should be offered. The customer copy stating that the payment was declined should be given to the customer and the merchant copy should be stored securely (see Storage of Card Details).

By telephone

Where card details are provided during a telephone call, these must be processed directly into the PDQ terminal at that time and must not be written down or noted anywhere.

When card details are being provided in a telephone call these must not be repeated back to the customer in such a way as to be audible to third parties.

If it is not possible to submit the card details immediately then a call back must be requested or offered.

Services using such devices must take ownership of their use and adhere to the requirements listed below in Appendix A, Terminal Security Procedures.

Card details received in writing

Some customers may provide their card payment information in writing for processing (by fax, in a letter, email or by booking form). Customers should be deterred from providing the information in this manner as it is not secure. There is no guarantee that these details have not been intercepted prior to being received by the council.

When details have been received by this method they must be processed immediately upon receipt.

Once the payment has been successfully authorised, the original document showing the full card details must be crosscut shredded.

If the details have been received by email, then the email must be deleted from the Inbox and the Deleted mail folder. If the email requires a response, the card information provided should not be contained within the reply. Note that this does not immediately remove the data which will remain available for a period, hence this should be avoided if possible.

In a situation where it is not possible to process the transaction immediately then the details must be stored in a secure environment such as a locked drawer or cabinet. This is only to be actioned in exceptional circumstances.

For PDQ records, if the transaction is successfully processed, the merchant copy should be stored until transaction reconciliation complete.

If the transaction is declined, the customer should be advised immediately. The option of paying with a different card should be offered. The customer copy stating that the payment was declined should be sent to the customer and the merchant copy should be stored within the till drawer or cash box for the duration of the working day. When storing merchant copy receipts these must be treated as a confidential document and should be marked accordingly.

Storage of card details

Storage of card details on computers in any format (for example, email, Access databases, Excel spreadsheets, USB memory sticks) breaches the regulations. Staff are specifically forbidden from storing data electronically.

If this occurs the result could be large monetary fines from Visa and MasterCard. This is because there is risk of fraudsters obtaining card details by hacking into computers or storage media which stores cardholder information.

Merchant copies of PDQ receipts must be destroyed once transaction reconciliation complete. All other paper records containing sensitive information must be destroyed immediately after authorisation.

Data retention and disposal

Services are responsible for complying with the council’s Retention Schedule which can be found on the councils website.

Services retaining non-sensitive card data must carry out a review, at least quarterly, to remove data that exceeds requirements defined in the data retention policy.

Retained data on paper should be securely disposed of by cross-cut shredding when no longer required.

Electronic transfer of data

It is strictly prohibited to transfer card data electronically both internally or externally to Enfield Council. This includes the use of end user messaging technologies.

Point of sale card services

All devices in use must comply with PCI standards.

All devices are included in the inventory for Enfield Council which contains key data identified by the standard.

Devices must be periodically inspected to detect tampering or substitution.

Staff using such devices must be trained to be aware of attempted tampering or replacement of devices.

Services using such devices must take ownership of their use and adhere to the requirements listed below in Appendix A, Terminal Security Procedures.

Refunds

Corporate electronic payments

Refunds can only be processed back to the originating card if:

The refund must be approved by the responsible Service Head via email then forwarded to the nominated person.

The corporate system is then accessed, and the refund is processed back to the source card from which the original transaction was authorised. It is possible to process part refunds where necessary, but the refund cannot exceed the original amount.

Other payment methods

Refunds for other payment methods have to be processed by completing Payment Request Form which is processed and paid via the Finance system. This is because the original payment does not capture the cardholder’s details to facilitate a refund.

Contacts

If you have any questions about the details in this policy, or have difficulty complying with any part of it, please contact the Finance Manager or the DS Service Desk

Related information

General information about PCI-DSS can be found at PCI Security Standards Council.

Definitions

PCI DSS - The Payment Card Industry Data Security Standards

PSP - Payment Service Providers, for example, Capita, Sage Pay, Spektrix

CDE - Cardholder Data Environment

SAQ - Self-Assessment Questionnaire

PDQ - Process Data Quickly or Pretty Damn Quick

CVV - Card Verification Value (3 digit code on back of card)

CVC - Card Verification Code (3 digit code on back of card)

POS - Payment locations utilising PDQ card devices

Appendix A: Terminal security procedures

These procedures apply to all payment terminals and PIN-entry devices, including:

Acceptable use

Terminals may only be used for taking customer payments for verification.

Terminals may only be used by authorised personnel.

Daily checks – Anti-tampering

To ensure terminals are not tampered with, at start of day, perform routine visual inspections of every device, looking for potential signs of tampering. Also keep track of any operational difficulties that begin happening on a regular basis. Some examples of things to look for include:

If tampering or overlooking of the terminal is suspected, it must not be used. All details must be reported to the DS Service Desk.

Policy details

Author – Information Governance Manager
Owner – Information and Data Governance Board
Version – 1.8
Reviewer – Information and Data Governance Board
Classification – Official
Issue status – Final
Date of first issue – 10.11.2016
Date of latest re-issue – 30.05.2024
Date approved by IGB – 19.05.2024
Date of next review – 30.04.2025

Council news directly to you

The latest news in your inbox every week. Council news, community updates, local events and more.

Sign up Sign up