GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?

Table of Contents

Lead Story

A new era in digital marketing


Industry Update

Heartland settles some, loses one

U.K. checkless by 2018?

Diners Club: New brand, new voice

A new level of protection


Research Rundown

A capital idea for growth

Selling Prepaid

Prepaid in brief

Understanding prepaid's target audience

Ciao prepaid

Brush up on terminology for 2010


To checklist or not to checklist

Biff Matthews
CardWare International


Street SmartsSM:
New year, new plan

Jon Perry and Vanessa Lang

Manipulation is good

Daniel Wadleigh
Marketing Consultant

Effective tradeshow marketing

Peggy Bekavac Olson
Strategic Marketing

Digging into PCI - Part 7:
Restrict access to cardholder data by business need to know

Tim Cranny
Panoptic Security Inc.

Company Profile

mPayy Inc.

New Products

An ATM for all types of weather

Triton RL5000, Triton RL1600
Triton Systems of Delaware Inc.


Courting curmudgeons


10 Years ago in
The Green Sheet


Resource Guide



2010 Calendar of events

A Bigger Thing

The Green Sheet Online Edition

January 11, 2010  •  Issue 10:01:01

previous next

Digging into PCI - Part 7:
Restrict access to cardholder data by business need to know

By Tim Cranny

In this installment of our multipart series, we drill down on the seventh of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). We will talk about what the issues are, what merchants need to do, and what their ISOs, banks or processors can do to help them.

Requirement 7 is "Restrict access to cardholder data by business need to know." It is the first part of the section "Implement strong access control measures."

Requirement 7 is one of the more "high-level" parts of the PCI. Rather than a listing of narrow, specific technical requirements, it is more about having the right general rules in place to control access to cardholder data. While the more specific details are laid out in Requirements 8 and 9, Requirement 7 is the foundation for those details.

What Requirement 7 is all about

The essence of Requirement 7 is that the best security is preventative, not reactive. The best way to ensure that cardholder data is not compromised is to simply make sure as few people as possible have access to it.

This basic idea is often called the "need to know" or "least privilege" principle. People should be able to access the tools and information they need to do their jobs but should have no access privileges beyond that.

For example, bank managers need access to bank vaults and so should have it. But cashiers or janitors don't need that same access privilege and so should not have it.

Another key point is that it does not say security should stop people from doing their jobs. The ideal is that the least privilege principle should be invisible to people doing the right thing; it should only become visible and active when they try to do something wrong.

For instance, bank cashiers should have access to cash drawers and terminals, but security should kick in when they try to enter the bank vault, since they don't need that level of access.

Think of security privilege controls like the safety barriers on the side of a mountain road - they're always there but only interfere with traffic when something goes wrong.

The challenges of Requirement 7

Unlike some other parts of the PCI, Requirement 7 is simple to understand: There is no mystery about the purpose of the requirement, nor is there a cloud of obscure technical issues to confuse the merchant.

Like Requirements 5 and 6 (discussed in "Digging into PCI - Parts 5 and 6: Maintain a vulnerability management program," The Green Sheet, Dec. 14, 2009, issue 09:12:01), the challenge is more about having the discipline to do unexciting but necessary things before disaster strikes, as opposed to the psychologically easier task of responding to a disaster that has already happened.

Political will is often needed because merchants may need to improve (that is, change) business processes and how their employees operate. This often triggers active or passive resistance, turning supposedly simple compliance issues into political and psychological ones.

This is a rare case in which smaller organizations have an advantage over larger, more sophisticated companies. The smaller the organization, the simpler these Requirement 7 issues usually are.

For example, in the ultimate case of a one-person operation, there are no internal politics to worry about, and all these "who does what" questions simply get answered with, "I pass all these questions because there's just me, and I'm supposed to do everything."

In larger organizations, the political and organizational costs are likely to be much greater, simply because the issues are more complicated, and procrastination is a bigger danger.

One thing merchants (and their advisors) need to remember is that when this requirement discusses "access privileges," it's not just talking about accessing computer files. Any unauthorized access to cardholder data is a problem, so merchants need to take a proactive approach. Find any problems that exist and fix them, rather than take a minimalist "they didn't specifically say I had to worry about that" approach.

For example, physical access to paper records or POS devices is an issue, and I will cover it in more detail when I consider Requirement 9.

What merchants need to do

As with Requirements 5 and 6, merchants need to focus more on confronting the issues raised by Requirement 7 and doing the right thing, rather than on attempting to avoid the issue. With two main aspects to Requirement 7, there are two main sets of actions called for:

What you need to do for your merchants

Again, merchants don't particularly need rescuing from technical nightmares to comply with this part of the PCI, so it should not be a significant pain point in PCI conversations.

Merchants might need assistance in liaising with vendors of payment applications, POS terminals and other PCI devices. They might also require some general advice on security and access control. ISOs can do this themselves, if they choose, but for many, it is simpler and better to partner with a security specialist as part of a broader PCI program that also deals with the other, messier, parts of the PCI DSS.

Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. ( He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at or 801-599-3454.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

previous next

Spotlight Innovators:

North American Bancard | USAePay | Board Studios