I run an offshore development team that produces a host of financial products. We are currently planning the work needed in order to gain PCI compliance.

The offshore team is run by an outsourcing operation who employ the staff directly. In other words the developers are not directly employed by us, but are exclusively resources to projects for our company.

All our infrastructure is UK based (source control, development machines etc). Developers/Testers offshore remote desktop to the development environments they need to use.

Is there anything in this setup that we should be concerned about from a PCI point of view?


2 Answers 2


First of all, good luck.

It would be nice to know exactly what sections you are trying to satisfy so we could provide a more specific answer.

PCI is mostly concerned with separation of duties. (The second thing it is concerned with is the opinion of the auditor, but that is a separate matter). This is to say, developers should not have access to QA, QA should not have access to production, and so on and so on. The other consideration here is the software lifecycle that you use to promote code into production. We based ours off of the Microsoft SDLC, and I suggest you take a look at it.

Basically it follows something like this.

  1. Ticket comes in, get assigned to ba/dev for "requirements gathering"
  2. Security assessment is done. This is in the form of a questionnaire. Basically, does the code touch anything to do with card processing, etc etc.
  3. Based on security questionnaire results, specific security requirements are determined. This is to say, do you need a code review? (external of course). Etc

The separation of duties could look something like this.

  1. Code is made available in source control system for QA to checkout/build.
  2. QA "tests" code. This may include security testing as per questionnaire results.
  3. If required, 3rd party conducts code review. There are many 3rd parties to chose from
  4. QA passes documentation and built binaries to Production Support team
  5. Production support implements.

What you will find, is you will want to create PCI "zones". IE: High risk zone would be any code that touches/interacts with any system/process that deals with credit cards. Obviously any changes in this area will require a code review by a 3rd party (especially in the case where you don't control the development, etc). You would then have a secondary zone. Code changed in this area does not need the same rigor as code changed in the primary zone.

The above only really deals with a couple subsections of the PCI requirement. Really, you have to remember that PCI is more about standards and documenting those standards. Picking "best practices" and then showing that you comply to said best practice. Code reviews are a major win in this area.

The auditor in your case may be concerned with who has access to your source code, and how they gain access to it. Of course you cannot prevent someone from taking a screen shot or copying code by hand, but they may want to see some controls in place so someone can't just copy all the code to a USB and leave with it.


I'm not a legal expert on this, but I was technical lead on bringing a major online retailer in line with PCI compliance.

So for my two-pennyworth:

PCI compliance is about data protection.

Basically - do not give devs access to any personal data. This applies whether it be in-house or out-house. If you must use live-data in dev environments, then sanitize it first by removing all creditcard numbers, changing customer names, address details, phone numbers etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.