The Key to a Successful PCI DSS project

Considerations for vendor selection

The choice of supplier for your PCI DSS solution is critically important to the success of your project. A good fit for your business helps ensure a relatively smooth journey. Solutions which are intuitive ease the learning process, foster the sense of the project being an improvement, and contribute to organisational confidence. But suppliers need to be evaluated on two very different criteria:

Firstly, and most obviously comes the product itself – does it meet your business requirements? Does it have a proven track record?

The second is much harder to evaluate, but equally important – does the supplier’s culture fit with your organisation?

Bear in mind that your relationship with the supplier will have two very different phases. During the sales cycle there will be no request too large and no question too small. You will be the most important person in the world. It is not until after the contract is signed that the actual business relationship begins and it is the nature of this that you must gauge. You should feel that the supplier is ethical and honest and would never intentionally mislead you. You must be able to work together through unexpected problems. This one is a question for the gut.

Do you need a consultant?

Not every PCI project requires a full time consultant, or often indeed even a part time one. Much depends on how much in house experience you have available. The scale of the project also feeds heavily into this decision. Often the voice element of PCI DSS is a separate project only considered after the main PCI initiative is complete. Perhaps the solution provider can fulfil this role themselves.

If you do feel that you need a consultant, then much the same selection criteria that apply to solution suppliers apply here too. Some consultants will stress project management skills, others may major on their technical competence whist others will focus on their ability to create an atmosphere of collaboration and consensus.

Be aware that an implementation consulting team is the business equivalent of a shotgun wedding: one
 day a bunch of people show up, sit with you, and start making suggestions on how to do things. There will be friction around who should lead and who should follow; awkwardness around when to accept an answer at face value and when to require background reasoning; uncomfortable personality clashes are a distinct possibility too.

If you are seeking a partnership, and the consulting group seems rather arrogant and dismissive of your naïve questions, you should probably cross them off the list and move on.

Adapting business processes

One of the most difficult tasks you will undertake in your pursuit of a successful PCI implementation is knowing when to change a business process to conform to an out of the box solution, and when it is essential to customise the solution to preserve a strategic business process advantage. The reason it is a difficult task is because, while there will be very few business processes that actually represent a strategic advantage, you will encounter strong resistance to changing any of them.

There is a natural tendency to assume that bespoke solutions are always preferable to out of the box solutions. You should consider the impact on maintainability that this implies. If the solution provided to you by a vendor is heavily customised, is your code branch properly covered in the main suite of regression tests run by the vendor? The answer is almost certainly not. If you have issues what is the likelihood that these are caused by the custom code and, given that this lies at some distance from the main code base, what is the chance of a speedy and effective diagnosis and remedy? You should ask searching questions to try and ascertain to what extent the vendor has really considered these matters.

Change management

Whilst it may seem tempting, simply making speedy adoption of a new initiative a condition of continued employment is probably not the best path to success. The only logical alternative is to manage affected staff in such a way that, even if they are not positive about PCI, they are at least accepting of the change, and understand the business reasons behind it.

The key steps on your journey to change are:

– Identify everyone who will be affected by the change (this is a bigger group than you might think and might take several cycles to fully identify)

– Communicate to this group what change will be coming

– Communicate the compelling business reasons that make PCI necessary

– Explain how they must behave in order for the project to succeed

– Give frequent project updates, always reiterating steps two through four.

Leadership commitment

Having a committed executive group is an important key to PCI DSS implementation success. If everybody in the organisation can see that the board, the steering team and the executive sponsors are aligned around a successful PCI project, they will behave likewise, which will allow you to focus your attention on other key success factors. On the other hand, if middle management senses that they can drive a wedge between the implementation team and the executive group, you will find a disproportionate amount of your time attending review meetings, defending the decisions you have made.

It should not be that difficult to achieve and maintain leadership commitment. Normally PCI is mandated as a matter of compliance but is also recognised as strategically important in its brand protection role so the project will often have been initiated at the highest level.

However, as design sessions make it obvious that PCI will require change, communications from lower ranks up through higher ranks create successive embellishments such that executive leadership will hear that “PCI is going to destroy our business”. Obviously, this type of hyperbole is generally not created by maliciousness, but simple fear of change. So, to ensure that leadership remains confident and supportive of the PCI effort you should take these proactive steps:

– Try to be the first to communicate process change decisions. The critical point is to make certain that decisions are explained in terms of sound business judgment.

– Try to always present executives with a bigger picture narrative when possible. To the extent that you can arrange numerous tactical PCI decisions into a strategic picture with implications, you will engage executives in their comfort zone.

– Solicit executive feedback and do not be defensive when you receive it. Your goal is to remain tightly aligned with the executive leadership, and that will only happen if they are confident that you can listen to and respond to their concerns. Also, this keeps them involved in decision-making; you want them to think of these as “our decisions” not “your decisions”.

–  If your executive leadership remains steadfastly committed, middle management will quickly sense that attempts at sensationalism are a waste of time, and will refocus their efforts on more productive endeavours. This in turn, allows you to focus your time on more productive tasks. Keep your leadership group aligned around and enthused about the project, and your probability of success goes up significantly.

The importance of testing

A huge success factor for a successful PCI implementation is aggressive and extensive testing.

Testing requires more than just assigning manpower.
 It is an iterative process, which means not only testing, but evaluating problems and fixing things. It means having valid master data available to support
 the test and understanding the process you are testing. It means having a dedicated test environment, which can be controlled and monitored. Each test leads to a bigger test, so there is a natural progression of testing sophistication over the course of an implementation.

After initial configuration is completed, all planned transactions are tested for simple transactional validity.

Shortly after this milestone, the first round of integration testing should begin. “Integration testing” in this case means testing an entire business process, from initial input to final output. An integration test is a scripted arrangement of sequential transactions required to execute a specific process in the real world. The key to making this phase successful is to identify the handful of scripts (probably 10 – 20) that represent 90% of the business processes, and working hard on process improvements until they all execute smoothly.

It is here that it can be extremely valuable to involve end users. Select a number of your most experienced operators and give them basic training on the system. Select those who show unusually quick comprehension of the system or high levels of curiosity.

These people contribute beyond their task participation because they bring real world eyes to problems to which the implementation team may have grown blind. They recognise what areas of training are going to be especially problematic. They can look at system output and in a glance spot common sense errors that a team unfamiliar with the day to day data might overlook. They will have an innate feel for the real world importance of the various possible edge cases that fall outside the first developed test scripts.

These people will become the company mavens for the system.

Subsequent rounds of integration tests try to rehearse and execute a go-live, replicating one hundred percent of the activity of a business for a given time period.

It is imperative that some tests are carried out in the actual live environment prior to going live. Some systems are architected in such a way that big bang cutovers are not required making this very much easier. In the absence of this it will be necessary to conduct these tests out of hours which is far from ideal given the time to roll in and roll back. This is something that should be considered as part of the initial vendor selection process.

Every test cycle teaches, uncovers problems, and makes go-live more manageable. Eventually, an inflection point occurs during testing which is incredibly important for a team’s morale and attitude; it is the realisation that the team is certain of a successful go-live. That knowledge and confidence – which can only come from repeated and successful testing – is essential to an implementation’s success.

Training

One of the best ways to increase the likelihood of implementation success is with an effective end user training process. There are several levels of escalating contribution that can result from a well executed end user training program.

Ensuring that on day one, everyone can logon to the new system, and have the knowledge to execute the transactions by themselves is the most basic level of success. Without this baseline of competency, there is no question the effort would fail. This can only occur if the end users have received effective educational instruction, and have been asked to practice applying what they have learned.

The best way to ensure this is to have training workshops conducted by seasoned operators drawn from the ranks of those involved in the testing process, leveraging the social bonds that will already exist in this group. Approached in this way, the training process is not only faster but more effective, resulting in operator confidence which is reflected in customer perception when they interact with your staff.

Selecting the right team

A talented implementation team sees the big picture more completely, appreciates the implications of the strategic plan better, evaluates decisions not only in terms of what is today, but what is likely to become tomorrow, and has the professional capital and organisational respect to sell difficult, but necessary process changes.

So what are some of the indicators of good talent when evaluating individuals for implementation team participation?

– First, if possible, individuals should be seen as promotable. People who are promotable have less allegiance to the status quo, and will later populate the organisation’s higher ranks with fundamental understanding of how the business processes were designed.

–  Secondly, an individual who has high personal intelligence is nice, but an individual who has high team intelligence is a necessity. Being personally smart has nothing to do with – and can occasionally interfere with – being team smart. Being team smart means you recognise the point of consensus, and do not belabour a conversation beyond that point; it means that you do not steer conversations in interesting, but unimportant directions; it means that the quality of a decision is evaluated solely on its effect to the organisation; it means that whatever personal ego you have is left at home where you can conveniently pick it up after work.

– A third attribute is depth of understanding. Talented people not only understand what is required, they understand why it is required, and this comprehension is incredibly valuable when it comes to determining what business practices are subject to change and which are not. And finally, the most intangible, is the ability to listen to multiple points of view, and assimilate the best parts of all into a solution that is better than any.

If you assemble a strong team, everything about the project goes better. Change management is more effective because the team members have credibility. Testing goes better because the test scenarios are chosen wisely, and executed intelligently. Fewer milestones are missed, as team members are used to accepting additional responsibility, and pitch in to help wherever needed.

Defining Success

Defining success for an IT project seems to be inherently more difficult than defining successful financial expectations, or manufacturing objectives. Yet without an articulated set of post go-live expectations, the success of an PCI implementation becomes a matter of opinion – and in the worst case, a matter of infinite opinions. If an organisation is lazy, and adopts a default metric of how many people are bitching about the new PCI system, then almost all implementations would be deemed failures. It is essential for the focus of the implementation team, for the health of the organisation, and for appropriate allocation of resources that a set of measurable criteria be put into place prior to go-live which are the final arbiters of PCI success.

It is also perfectly acceptable if success criteria are time phased, and represent a sequentially higher
bar over time. For instance, an end of week 1 objective might be to have no more than 5% of transactions conducted in a non compliant way falling to 2% over a month and to zero within 2 months.

Additional Information

Colin Westlake is Managing Director at Syntec

For additional information on Syntec visit their Website or view their Company Profile