Industry security standards, including PCI compliance requirements, are becoming stricter every year as security breaches at large corporations drive the need for tighter controls and audit processes.

Platforms have grown in power and reliability, attracting more solutions that have expanded access to internal and external business data and networks. Old practices such as security monitoring and audit reports are no longer accepted. Many of the new requirements have extensive ramifications across the production environments.

Updated requirements affect everyday processes related to user IDs, software management, data movement and more.

The PCI Security Standards Council, which was founded in 2006 to manage the ongoing evolution of the Payment Card Industry Data Security Standard (PCI DSS), has provided clear definition of what is required to be compliant, which controls you need, and how you can monitor those controls. Applying the defined standards to your company’s structure and current processes should be a top priority.

This guide was designed to help industry professionals define PCI compliance, outline the biggest challenges facing retail, financial and healthcare companies today, and provide best practices and viable solutions to help businesses of all sizes protect their confidential data and be prepared for an audit at all times.

Download this guide for free to read later or share with your colleagues!

Defining PCI Data

PCI defines the data that must be secured as Sensitive Authentication Data (SAD), which includes all card data:

  • PAN
  • PIN or PIN block
  • Security code
  • Cardholder name
  • Expiration date
  • Data from track 1/2 of the card or from the chip

The data that should be secured and will be found in many places you haven’t thought of whether that is “in transit,” “at rest” or “in use.”

Each of these is a segment of the life cycle of your data and must be secured wherever it is at the time. A data review should be completed whenever changes in the payment systems environment occur including application enhancements, upgrades or software release, network landscape or the data storage process. Knowing where that data exists becomes a constant obligation and liability.

Using Encryption & Tokenization to Secure Data

Data is secured by two methods: Encryption and tokenization. These methods are used separately to ensure data is secured from end to end — from transmission of the data into your systems to storage of the data or data in use.


When using encryption, it is imperative that keys are ever-changing and are secured and audited frequently. The current industry-recommended methods of encryption in transit are:

RSA—Named after the technique’s inventors (Rivest, Shamir, and Adelman), this method is a public key encryption that uses a one key to encrypt and one to decrypt. This method is used in PGP and GPG.

AES (Advanced Encryption Standard)—This method is the standard for the U.S. government and currently considered impervious to attach other than brute force.


Tokenization is normally used when data is stored (at rest). Using the correct application for tokenization that is PCI approved is essential.

Controlling Data Access

Do you know who has access to your secure data, or more importantly, who has accessed your secure data? Establishing user access control is the next step to ensure your data is secure and your business is compliant.

Access to data in the clear is a business requirement, but who has access and to what they have access must be controlled. User access must have business justification and must be reviewed periodically for approval. Data that the user accesses should be continually monitored.


MAC — Mandatory Access Control
Access based on data labels by data type

DAC — Discretionary Access Control
Owner of data has control over who has access by using access control lists

RBAC — Role Based Access
Access determined by role and not individual user; the user is assigned a role based on

RBAC — Rule Based Access
Based on rules that deny access

Golden Rules of Compliance


Cardholder data refers to any information printed, processed, transmitted or stored in any form on a payment card.

Entities that accept payment cards are expected to protect cardholder data and to prevent its unauthorized use – whether the data is printed and stored locally or transmitted over an internal or public network to a remote server or service provider.

  • Limit retention time
  • Do not store authentication data
  • Mask PAN when displayed first 6, last 4 is the max
  • PAN must be unreadable when stored. Are you using tokenization?
  • Protect encryption keys
  • Document security processes and procedures and keep those documents updated


Encrypt transmission of cardholder data across open, public networks. Encryption is one technology that can be used to render transmitted data unreadable by any unauthorized person.

Rule #2: Identify Sensitive Data

  • Transmitted (in motion)
  • Stored (at rest)
  • In use

A detailed survey to determine where SAD lives in your environment is the first step towards compliance. This survey should be conducted annually or whenever the environment changes.

The survey for SAD will include when data is in transit, stored and in use. Once the survey is documented, it should be stored as part of the security program.

Where to find cardholder SAD data:

  • In transit
  • In transaction log files
  • In database
  • In extracts
  • In usage accumulation files
  • In SAF (store and forward) files
  • In terminal log files (ATM and POS)
  • In settlement files
  • In network log files
  • In application error messages
  • In reports

Rule #3: Utilize Encryption and Tokenization to Secure Data Transmission

Securing data today requires encryption, tokenization and access controls. Encrypting data in transit is the most secure method. At rest, your data will be secured with tokenization. If breached, the tokenized data has no meaning and no key to unlock it.

When transmitting sensitive data, encryption should be at the source prior to transmission and sent across a secured encrypted tunnel. When at rest, securely storing data requires tokenization.

There are two types of tokenization:

• Reversible Tokens
Used to reverse the token back to its original state. This attribute of reversibility also provides a method of extracting the original PAN in the event it may be required.

 • Irreversible Tokens
Eliminate all capabilities of extracting the original PAN information.

DOUBLE-DOWN ON DEFENSE AGAINST HACKERS Encryption and tokenization work hand in hand to
protect your data while in transit or at rest. While encryption secures your data in transit, tokenizing your
data at rest will render it meaningless if breached and cannot be opened with any keys.

Rule #4: Control Access to Data

The next step in your data review is to determine who has access to the data.

  • Is access available in transit?
  • Is access available at rest? If so, which files are accessible?
  • Is access available when in use?

Access Control is a balancing act between securing the data and providing access to ensure your employees are productive. A business case should be documented for each user with access to SAD on need-to-know justification. Management approval should be required for access to SAD.

Rule #5: Track and Monitor Access

Access to SAD should be monitored daily and documented by storing the evidence to provide in audit reviews.

Access-Based Roles—Roles are based on type of job or function and access is assigned by the type of user (i.e. programmer vs. support technician).

Access-Based Groups—This type of access groups individuals that require the same level of access together when access groups are created and assigned. Apply the Least Privilege principle to give access to what is necessary for the user to perform their job duties and no more.

  • MAC – Mandatory Access Control
    Users are given access to data by the data labels “top secret,” “confidential,” etc. Labels are attached to each file, directory, transmission, batch job, audit log, and so on. The operating system used must support MAC for this model to work.
  • DAC – Discretionary Access Control
    The data’s owner has control over who has access by using access control lists. These lists are set by the owner, but are enforced by the operating system.
  • RBAC – Role Based Access Control
    User access is determined by role and not individual user. The user is assigned a role based on responsibility. The use of RBAC simplifies access control and is best used in companies with high turnover.
  • RBAC – Rule Based Access Control
    This group is based on rules that deny access. For example, access rules can be based on time of day, day of week or whether a file is tokenized.

Rule #6: Conduct Risk Assessment to Identify Vulnerabilities

Facilities that house systems processing secured data should have documented physical access controls. Physical security should be reviewed annually.

Data should be identified as secured and the necessary controls to protect integrity, confidentiality and availability by reviewing the following risks:

  • Physical Damage
  • Human Interaction
  • Equipment Failure
  • Inside/Outside Attacks
  • Misuse of Data
  • Loss of Data
  • Application Issues

Vulnerability Management starts with defining the scope. Assets may include:

  • Network Infrastructure
  • Servers
  • Firewalls
  • Database
  • Log Files
  • Audit Files
  • Extract/Batch Files

PCI definitions and rules continue to evolve. As of January 2018, businesses and corporations are required to adhere to PCI DSS 3.2.1. Under PCI DSS 3.2.1, requirement 8.3.1 states that organizations must incorporate multi-factor authentication and network segmentation for access into the cardholder data environment (CDE). PCI requires businesses to demonstrate network segmentation and multi-factor authentication.

The common solution is a jump server in a DMZ network segment with access to critical hosts. The jump server provides the additional level of authentication while the DMZ provides the network segmentation.

All risks should be identified, classified and evaluated to determine remediation required to reduce the risk.


Changing Technologies

The job of maintaining compliance in an ever-changing world of technology can be one of your organization’s biggest challenges.

Several times a year, credit card companies release new mandates that consist of software changes that must be applied in order to continue credit card acceptance for your customers. All mandates should be reviewed to determine whether they require any remediation steps to ensure compliance and data security is maintained on your systems.

Software and hardware vendors release upgrades, enhancements and new versions that may contain changes that would create a compliance risk. Any hardware or software changes should be reviewed to determine the effect of those changes regarding compliance and data security.

Finally, the technology required to adhere to the PCI, HIPPA, PII, etc., regulation updates, changes and additions that occur more often than most organizations can keep up with.

The most recent PCI mandate software security framework requires the following objectives:

  • PCI Software Security Framework **New**
  • OBJ1 Critical Asset Identification
  • OBJ2 Secure Defaults
  • OBJ3 Sensitive Data Retention
  • OBJ4 Critical Asset Protection
  • OBJ5 Authentication and Access Control
  • OBJ6 Sensitive Data Protection
  • OBJ7 Use of Cryptography
  • OBJ8 Activity Tracking
  • OBJ9 Attack Detention
  • OBJ10 Threat and Vulnerability Management
  • OBJ11 Secure Software Updates
  • OBJ12 Vendor Security Guidance
  • Control OBJA1 Sensitive Authentication Data
  • Control OBJA2 Cardholder Data Protection

Companies must document how the objectives listed above are being met and provide evidence during an assessment or audit.

Cybersecurity Skills Shortage

Cybersecurity professionals are in high demand following a rash of high-profile data breaches at some of the largest U.S. companies. However, according to (ISC)², a nonprofit organization for cybersecurity professionals, there are nearly 3 million cybersecurity positions open and unfilled around the world. Without trained cybersecurity staff, organizations won’t have the capability to deploy the right controls or develop security processes to detect and prevent cyberattacks.

A couple recent surveys noted the worldwide shortage is only worsening—posing long-term security risks for businesses and organizations.

• In a 2018-2019 global survey of IT professionals conducted by independent industry analyst firm Enterprise Strategy Group (ESG), 53 percent of
respondents reported a problematic shortage of cybersecurity skills at their company.

• The third annual global study of cybersecurity professionals by (ESG) and the Information Systems Security Association revealed industry’s skills shortage
has worsened for the third straight year and has impacted 74 percent of organizations.

Skills required to reach and maintain compliance

• Systems Architect — Build and maintain all hardware/software systems; maintain points of vulnerability within the systems architecture

• Network Engineers — Build and maintain network infrastructure including firewall configuration; maintain points of vulnerability within the network infrastructure

• Security Analysts — Implement and monitor compliance controls

• Forensics and Remediation Analysts — Initiate the plan when a breach is discovered; determine mediation steps and ensure they’re completed; document all issues identified and remediation completed to mitigate the breach

• Disaster Recovery Business Continuity Analysts — Develop and maintain disaster recovery plan; document cause and remediation if plan is activated; complete recovery drills at least once a year

Vulnerability Management – Knowing and Managing Your Risk

Vulnerability management must be designed to proactively mitigate the exploitation of your system’s hardware and software. Compliance requirements will drive which steps are to be taken to determine vulnerability.

The following steps must be taken to ensure your systems are not vulnerable:

Penetration Testing—Identify vulnerabilities in the network that could be exploited — firewalls, routers and ports, configuration, connections and traffic from untrusted networks

Segregation of Environments—Production Systems vs Test or Development Systems must be separated. Architectural diagrams that map the different systems should be documented and kept up to date.

Disaster Recovery—Your disaster recovery plan should be tested at least once a year with the following results documented:

  • Time required to recover
  • Point of data that can be recovered – Number of hours of data can you recover and continue to recover
  • Dedicated staff required to support disaster recovery live and dress rehearsals

Systems Vulnerability Review—Computing environments are constantly changing. They may be secure today and out of compliance and unsecure tomorrow. The management of systems vulnerability can be maintained by intrusion detection systems, patch management systems and rigid software or hardware testing of enhancement, upgrades or versions.

By constantly evaluating risks, you can remediate any issues found in a timely manner.

How Odyssey Information Services Can Help

The oversight of data security and compliance is a constant challenge. As technology changes, compliance requirements must keep up. Maintaining training for your company’s staff is expensive and time-consuming. Security and compliance must be a directive from top down in order to succeed. Management should support the time, effort and cost it takes to reach and maintain compliance and the oversight to ensure all data is secured.

Working with a trusted and experienced partner like Odyssey Information Services can help alleviate the stress and hassle of maintaining data security and being ready for the next audit.

Focal Point for Audits

Odyssey can be there during your audit. We can be the focal point to stand with your organization during the audit answer reviews and help provide all the required evidence.

Identify Gaps

Odyssey can review your current production transaction and data flow from a compliance standpoint and identify security gaps in your data protection or evidence gaps in your evidence gathering process.

Organize All Compliance Documents/Evidences

The amount of data required for an audit continues to grow larger—platform profiles, transaction flows, log-ons, network diagrams, administrative commands, logs, sign-off on-log reviews, release procedures and on and on. How do you organize it so that it is easily available when asked for? How do you keep it current? The answer includes process changes to a lot of departments. Odyssey has been there, worked with the departments, automated where possible, knows how to keep it all referenceable and available when needed—an auditor’s dream environment. Simply put, we can make your audit a non-event.

Develop Proactive Approach

We can help your company from a reactive approach (when your annual audit is a month away) to proactive approach where you’re ready any time all year long. Our experienced team can incorporate compliance requirements into your daily processes so that you have all your evidences, logs, diagrams and more are up-to-date at all times.

About the Author

Dorothy JacobsFinancial Payment Systems Professional
Dorothy Jacobs is a financial payment systems professional with an extensive background in
regulatory compliance frameworks for the financial, retail and interchange business sectors including PCI, AML/BSA, and Regulations E, D and Z. Dorothy’s experience in architecting front-end authorization and back-end settlement systems has given her the in-depth knowledge required to provide comprehensive compliance programs to our clients.