尽管目前为止大多数人都意识到满足PCI DSS合规的要求是困难的。与其它专注于安全的合规要求不同，例如HIPAA和SOX，PCI DSS大多数内容是高度规范性的。鉴于许多其它合规定义了高级的控制却没有足够的技术实施指导，PCI DSS通常用相对复杂的技术细节来定义可接受的参数用于需要的控制。
这给商家和服务提供商带来合规遵从的挑战，因为规范的控制给标准之外的情形留下的说明性余地（例如，标准没有预见到的情形）相对较小。但是从反方面来看，不太规范的要求也给自身带来了许多挑战。在那种情况下与其说组织受困于处理异常情况，倒不如说组织必须自己判断如何解决技术上的要求，牢记不同的评估人员可能对要求有不同的理解。尽管在PCI DSS合规中很少发生后面这种情况，但它确实存在。
PCI DSS规定7（“按照业务需要来限制对持卡人数据的访问”）是标准比起其它领域在技术上不规范的情形之一。就其本身而言，规定7对于组织来说可能是最难解决的部分之一，因为他们必须自己来判断如何在技术上实施该控制。
规定7简要
PCI规定7的意图十分明确：是围绕越少的人访问资源、这些资源受到侵害的机会也越小的思想来设计的。这不仅包括对数据自身的访问，也包括存储、处理和传输数据的系统。该要求指明措施来确保组织根据最小权限原则来管理和治理用户访问。该原则是定义（并批准）哪些人员需要什么级别的访问来完成他们的工作，并且在满足最低的需要前提下限制他们对系统的访问。
就这些细节而言，规定7由两部分组成：7.1子规定义的策略组成和7.2中定义的技术组成。在策略这面，7.1要求组织维护书面的数据控制策略，从而明确地根据需要知道原则来限制对系统和数据的访问。更具体地说，规定7.1通过它的子规定来要求业务解决一些具体的策略领域：7.1.1中的特权ID（如Administrator），7.1.2中的基于工作职能/角色的特权，7.1.3中的管理层批准文档和7.1.4中的自动访问控制。从技术的角度来看，这些标准要求自动的访问控制系统能解决如7.2.1中所有的系统组件， 7.2.2中的基于角色的特权分配以及7.2.3中的默认设置为“拒绝”（不允许访问）。
意图很明显，但是如同许多商家已经经历过的一样，在实践中可以实施许多不同的方法。
满足标准
那么当商家和服务提供商寻求解决这些规定时该做什么呢？在PCI合规策略7.1中定义的规定应该是易懂的。你会确认有一个成文的数据控制策略并解决在7.1中提出的所有要求点。为达到该目的，该策略必须是清晰的，容易落地的，可用于所有的访问控制流程和关注点的没有歧义的声明，包括特权ID、最小权限、RBAC（基于角色的访问控制）、批准流程和使用自动化的访问控制系统（谨慎些，实际情况可能不止这些。举例来说，如果你在公司使用Windows域，而在零售店铺使用单独的Unix服务器，你的策略需要足够广泛来同时解决这些领域，或者你需要有两个不同的策略来确保涉及这两个领域）。
此外，在标准的要求和实际的策略声明之间具有一对一的映射是极具优势的。对于那些需要经历年度评估的组织来说，这个特别重要：要实行一个QSA（质量保证体系）并在你的整体公司策略内搜索这些声明，就像要求一个人在草堆里寻找一根针。因此，要知道QSA评估你的公司策略只能到他们所发现的程度，拥有一个映射或索引有助于让评估人员在正确的地方查找。
从技术的立场来看，满足规定7.2中列出的技术规定，也就是默认拒绝访问和涵盖所有的组件，对于你来说是重要的。在实施中，一些公司没有完全理解这个事实，“所有的系统组件”不仅仅意味着POS终端、操作系统或单独的支付应用。相反，这意味着它所说的那样：所有的系统组件，范围内的所有系统。这暗示着在一个技术层面上不同的访问控制系统的潜在重叠。
举例来说，一个N层架构的应用在每层可能具有不同的用户/角色/特权集合。可能是在操作系统层面的访问控制（如Windows认证），在数据库层面的（如Oracle认证），和应用自身的（如应用厂商实施的控制）。满足规定的技术实施必须解决这些级别的每个层面，对于每个规定的领域包括：特权ID、默认拒绝访问、基于许可的角色等等。从好的方面来说，这些系统组件的大多数访问控制功能已自然地成为采用技术的一部分；从不利的方面来说你会需要单独地负责每个系统组件，同时还要负责如何让所有的组件一起符合一个技术层次。
对于商家和服务提供商来说，是否通过每年的评估或是提交一个自我评估问卷来验证，它需要以条理和全面的方式来满足规定，特别是因为技术实施没有像PCI DSS规定中一些那样给出详尽的说明。
