Tag Archives: iso

When is a Security Program not a security program? ISO 27001 and such things

When is a security program not a security program? This is a question I have been pondering lately, and I have an idea to share and debate.

First off what is a security program, and how do I define it? A security program for this purpose is one that operationalizes the orchestration of information security functions. It is constituted by both a documented structure of documents, and implemented technology processes. An example of a starting point for companies is ISO 27001. Now I am a proponent of creating a custom control framework, as reinforced by my book on this subject. I do though believe that such programs can be formed using such standards. Will an organization grow beyond, of course.

On to the question at hand…. When is a security program not a security program? It is when one is built in form and not substance or substance and not form. Yes, that is correct. Both are valuable and necessary. The form of a program is required to support efficiency, consistency, coverage, and visibility. The substance is necessary to provide effectiveness, compliance, and this little thing referred to as security in the common industry.

The challenge is that many organizations develop policies and procedures that mimic standards, but are not operational. This is especially prominent in U.S. Companies if one empirically bases this on the number of security certificates issued based on ISO. Though this is also supported by years of client engagements. It is one thing to have policies that have the same table of contents of ISO 27001, and quite another to actually have the program deployed.

This creates a mental challenge for many leadership, as according to the surface…their policies are “aligned” with these global standards. Conveying the difference and importance of each is critical for businesses as we move forward in 2011. How one might ask?

I would propose the following logical flow:
1. As in everything good, the truth shall set you free. Sharing the real risk is pivotal. Everyone has the same desire – to be part of a great company, enable them!
2. Bring management into the process. This is a fundamental aspect of the ISO 27001, start small and communicate.
3. Be great… Following the lowest common denominator for industry technology deployment, products, customer service, and security is silly. Lead.

While the above are philosophical, I feel that in this point in time we need a bit of an adjustment of perspective. Other thoughts?

I will be speaking in San Francisco next week at RSA on PCI, and looking forward to seeing everyone live and in person.


James DeLuccia

Do ISO entities need to be PCI DSS Compliant?

Who needs to be compliant with the Payment Card Industry Security Standards Council standards?  Well, the default response is usually – anyone who stores, process, and transmits card holder data.  There is constant discussion on pre-auth / post-auth / banking partners / etc..

A recent question I received was … Do ISO (Independent Sales Organizations) need to be compliant with PCI DSS?

This is a great question because it brings into the forefront the Third Party Providers.  While the classic response – “it depends” applies generically, let me elaborate and provide where it DOES exist.

According to Visa’s website, an ISO for this definition is also more broadly classified as a “Third Party Agent”.  Specifically here are the various functions that can be performed (This is key for eliminating the it depends statement from your situation):

A TPA can perform any or all of the functions of an: Independent Sales Organization (ISO), Third Party Servicer (TPS), Encryption Support Organization (ESO) and Merchant Servicer (MS). Each function performed by the TPA must be registered by each Visa client that is utilizing those services. TPA functions that require registration include but are not limited to:

  • Merchant or cardholder solicitation activities and / or customer service — these are performed by an ISO
  • Prepaid program solicitation activities and / or customer service — these are performed by an ISO
  • Loading or injecting encryption keys into ATMs, terminals or PIN pads — these are performed by an ESO
  • Loading software into an ATM or terminal — these are performed by an ESO
  • Storing, processing or transmitting Visa account numbers — these are performed by either a TPS or a MS
  • Deploying and / or servicing ATMs – these are performed by an ISO

Beyond registration requirements, all service providers – need to be compliant, as it is the acquiring banks liability if they are not.

Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are properly registered with Visa. Where applicable they must also ensure that all such entities are compliant with the PCI DSS and PCI PIN. Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa acquirers are responsible for any liability that may occur as a result of non-compliance.

In addition, Visa has provided enhanced clarification in their list of ISOs (published 7/15/2010) that lists registered organizations.  The document states that “entities utilizing this list should perform their own additional due diligence to ensure that the service prover is also compliant with any additional requirements that the entity may have in place.”… “Entities that store, process or transmit cardholder data must be registered with Visa and validate PCI DSS compliance.”

There are certainly relationships that may provide exceptions, but the process above shows that if you store, process, or transmit card holder data – proper security and compliance (and Validation where appropriate) with PCI DSS is necessary.

James DeLuccia IV