PCI compliance requirement 7: Restrict access

PCI compliance requirement 7: Restrict access

PCI compliance requirement 7: Restrict access

Date: Jun 01, 2009

Diana Kelley and Ed Moyle of Security Curve review PCI compliance requirement 7: "Restrict access to cardholder data by business need-to-know." To meet PCI compliance requirement 7, you must:

  • Have a policy and dcoumented processes that limit who can have access to cardholder data
  • Have systems that enforce the policy

The compliance duo addresses common questions related to PCI compliance requirement 7, like "Do we need an automated access control system?"

Watch the rest of the PCI compliance videos, as Ed and Diana review each particular requirement.

Editor's note: This video is based on PCI DSS version 1.1. For updated information on the changes in PCI DSS version 1.2, see the following:

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.  

PCI compliance requirement 7: Restrict access

Ed Moyle: The next requirement, Requirement 7: Restrict access to

cardholder data. This is pretty intuitive. This just means that you have a

policy, documented processes, and some kind of system that enforces access

control, or restriction of access to those systems that store processes and

transmits to data. Most of the time, most likely you already had this. A

lot of folks ask, 'You mean like with the functionality that is provided by

logging into Windows and being on a domain?' Yes. Just make sure that it is

documented and that you do have the automated access control system, and

you document what that means, and so on. Most of the time, in an evaluation

context, we see that folks have this already, they just do not have the

policy around it that enforce it, that supports it.


Diana Kelley: Right. You can link back to your identity data stores, this

wall to help you with requirement, as well, to get policy and access

control. One 'gotcha' here that I would add is that you may have

applications that were not architected to be very granular in access



Ed Moyle: Great point.


Diana Kelley: It could that all of the developers had the full blown

developer login and that they can still get to and use, even years after

that person has been deployed. Make sure that if you have applications that

are wide open, that you have taken some steps, either to re-architect the

internal access control or to put protection around, wrap them around the

application to make sure that you are really doing the access you need. The

quick hits are that you want to deal with the policy itself. There are a

lot of policies around what the rules are, who can get to what, and where,

and what you, and technical mechanisms you have in place to support that.

Another good thing is you want a default deny posture.


Ed Moyle: That is important, too.


Diana Kelley: Keep this, yes, it is traditional hardcore security, but

really, what you want is, that which is not allowed, is forbidden. Make

sure that you are opening up access as needed to users that need the pan

rather than that you got it wide open and now you are trying to firewall,

cutting people out; you want to go in a reverse direction here.

More on PCI Data Security Standard

  • canderson

    Why infosec will increasingly rely on computer hardware security

    VIDEO - Video: Cryptography luminary Paul Kocher discusses why computer hardware security will play a larger role in the information security product ecosystem.
  • canderson

    PCI 3.0 changes: A PCI compliance requirements checklist for 2015

    VIDEO - In this presentation, compliance expert Nancy Rodriguez offers a line-by-line review of the key PCI DSS changes that become mandatory as of Jan. 1, 2015.
  • canderson

    Gartner on PCI DSS 3.0 changes: Bigger, harder and more expensive

    VIDEO - Gartner analyst Avivah Litan discusses how Gartner clients are reacting to the changes in PCI DSS 3.0, and whether the increased rigor in the standard will prove beneficial to enterprises.
  • National Vulnerability Database (NVD)

    Definition - NVD (National Vulnerability Database) is a product of the National Institute of Standards and Technology (NIST) Computer Security Division and is used by the U.S. Government for security management and compliance as well as automatic vulnerability management.
  • virtual payment terminal

    Definition - Virtual terminals allow sellers to take credit card payments online for orders made online or over the phone without requiring a card reader device.
  • ingress filtering

    Definition - Ingress filtering is a method of verifying that inbound packets arriving at a network are from the source computer they claim to be before entry (or ingress) is granted.
  • Beyond PCI: Out-of-band security tips for credit card data protection

    Tip - Securing credit card data -- both online and at brick-and-mortar stores -- requires security measures beyond those mandated by PCI DSS. Expert Philip Alexander outlines six out-of-band security controls to consider.
  • compensating control

    Definition - Compensating controls were introduced in PCI DSS 1.0, to give organizations an alternative to the requirements for encryption. The alternative is sometimes considered a loophole that creates a security risk.

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: