A framework helps to develop a clear understanding of business needs and processes by virtue of it providing a place to record knowledge about the business and its ability to evolve as this knowledge or the business changes.

Using a framework to reason about changes to workflow and manage the relationships between documents virtually guarantees that centralized standards are created. It virtually guarantees the creation of centralized standards because the whole point of electing to define a framework is the benefit it provides in managing these documents.

Of course, there a lot of things that affect the scope of assessment. These go far beyond the ability of a framework to control. For example, is a framework able to reduce the scope of Requirement 1.2, where firewall configurations are needed between trusted and untrusted networks and any system components in the cardholder data environment?

If firewalls are not in place, then there is an unmanaged element required by PCI DSS in the network. A framework can shine here because it provides a starting point for the introduction of the network plan and the documents for managing this plan. In this case, a framework helps control the scope of assessment through the introduction of processes, procedures and plans that ensure these changes remain in place.

If firewalls are in place, then the only value a framework provides is to document the best practices that led to this network design, assuming that these best practices aren’t already documented. If these best practices are documented, then the value of the framework is limited to the possibility of being extended to include them. In this case there isn’t much affect on the scope.

In this example, the value of the framework for controlling the scope of assessment diminishes as the requirements gap shrinks. This implies that managing the introduction of PCI DSS using a framework is more valuable if the organization lacks documented policies, processes and procedures.

I'll add that the only consultant you want is one that can introduce compliance in a way that is sustainable. They have help create an on-going process.

Since the framework includes configuration standards for firewalls and processes to mange the testing, approval and review of changes to firewalls it is natural ask if any of these can be extended to include firewall ruleset reviews.

There are compelling reasons for including a review of the firewall ruleset while configuring production firewalls.

• Rulesets are an output created by the activity of configuring the firewall. 
• The individual configuring the firewall is in the best position to capture the updated ruleset. 
• The timing is optimal because configuration errors can be identified when they are introduced. 

Using this reasoning, the review appears to fit well in the workflow of an individual configuring a firewall. If this approach is used to introduced the review into the process for changing a firewall then it partially satisfies Requirement 1.1.6. What remains to address is the frequency of this review.

If the firewall is updated at least every six months then nothing is needed beyond ensuring that the date of each review is recorded. If it is not, then scheduling regular reviews is needed. The same individual could be required to include a recurring event in a calendar.

If there are compelling reasons that prevent reviews from occurring when changing a firewall, the framework is still valuable. For example, if the approach described above is feasible but there is a preference for different people to configure and review the ruleset then the review and approvals processes would introduce a workflow that involves another individual.

Even this simple framework helped identify the smallest workflow change that meets the requirement and provided a basis for analyzing the change in light of organizational preferences. Still not convinced?

Imagine trying to introduce this requirement to an already overworked IT team. They aren’t going to be happy about taking on additional tasks. Present them with the requirement and a framework that introduces the smallest possible change to existing workflows and they may be more receptive. Furthermore, objections to the change can be dealt with in a rationale manner that is consistent with the framework and the organization’s way of working.

Here is an example of some documentation requirements in PCI DSS, version 1.2: