Information Security Assurance: Which framework is right for you?

Not all information security frameworks are the same.

If your organization handles sensitive data on behalf of its clients, then you’re likely required to comply with one or more security frameworks in order to conduct business. Not all information security frameworks are the same, however; some standards are designed to be holistic while others focus on a specific business function.

Each information security framework was created for a purpose, but the shared goal is some form of assurance that sensitive data is effectively protected. Unfortunately, compliance requests vary by client and too frequently are based on incorrect assumptions or a check-list mentality that jeopardizes true information security. 

Identifying the right security framework (or set of frameworks) for your organization not only provides real information security assurance, it also gives you the opportunity to consolidate the audits you’re conducting or undergoing to save valuable time and money.

First, differentiate each framework’s intent.

So which framework is best and how do you leverage that with clients and prospects while accomplishing the actual goal of information security assurance? Let’s start with a basic understanding of the common information security standards and their intrinsic purposes.

First, let’s take a look at the holistic standards. Holistic standards take a general, risk-based approach to information security by prescribing controls that directly counteract an organization’s defined security risks.

• ISO 27001 is a globally respected holistic information security framework. Most consider it the grandfather of all other standards and for good reason. If your organization is doing business outside the United States, it’s the go-to standard.
• NIST Special Publication 800-53 is a holistic information security standard developed by NIST, a group within the U.S. Department of Commerce. The federal government and its contractors must adhere to SP 800-53 (and associated implementations in 53a) when handling government data. If your goal is to do business with the federal government or its contractors, then you will be required to comply with this standard.
• AICPA Trust Services Principles and Criteria is a holistic set of standards that is utilized in SOC 2 and SOC 3 engagements. It is a set of five information integrity standards focusing each on Security, Availability, Confidentiality, Processing Integrity and Privacy. This standard is frequently requested by financial institutions and publicly traded entities in order to comply with the GLBA and SOX legislation, although neither federal acts directly require them.
• COBIT (Control Objectives for Information and Related Technologies) is a holistic organizational security and integrity framework that utilizes processes, controls objectives, management guidelines, and maturity modeling to ensure alignment of IT with business. It maps directly to standards required for regulatory compliance (ITIL, ISO 2700X, COSO).

There are two common frameworks that target a specific type of data: The Payment Card Industry Data Security Standard (PCI DSS or just PCI) and the HITRUST Common Security Framework (HITRUST CSF).

• HITRUST CSF was privately created by the HITRUST Alliance based on the federal HIPAA legislation and its subsequent revisions. The standard focuses on securing Protected Heath Information (PHI). While there is no legislatively created “certification” for HIPAA compliance, the CSF is the result of a respected cross-industry collaboration that has gained momentum in recent years. If you are a healthcare provider or service provider (known as Business Associates), HITRUST is a viable option.
• PCI DSS directly applies to the protection of payment card data; think VISA, MasterCard, American Express, and Discover. The PCI DSS was created by the PCI Security Standards Council (PCI SSC) and compliance is contractually required of any business that stores, transmits or processes payment card data. PCI is unique from the other frameworks I’ve mentioned due to its prescriptive nature. While others leave much up to subjective interpretation, PCI is a set of requirements that address actual threats and the identified inherent risk to payment data. The result is a set of requirements that don’t allow the avoidance of key security practices for the sake of cost-benefit analysis.

Next, align the framework(s) with your organization’s clients and risk profile.

Some security frameworks are a requirement due to your organization’s client base. For example, working with payment data makes PCI compliance a must, and federal data requires FISMA (NIST SP 800-53) compliance. 

There are many commonalities between standards and it is common to utilize a framework to map multiple compliance requirements together. For example, HITRUST is one vehicle for meeting HIPAA compliance, but it’s not a requirement, and SOC 2 can be used as a vehicle for demonstrating GLBA compliance.

What does this mean? Your organization has the opportunity to take a fresh look at the information security assurance vehicles it needs to effectively meet clients’ risk-reduction objectives.

Because the PCI DSS is a prescriptive standard, you can actually apply its controls not just to payment data, but also to PHI and personal financial data. This means the PCI DSS standards can be applied to other data types to help support HIPAA and/or GLBA compliance as well.

Don’t expect your clients to immediately understand this. You may need to educate. Once you do, consolidating standards is possible and efforts can be concentrated to go beyond compliance to the higher goal of true information security.