Making Sense of the Different Audit Frameworks
by Sarah Harvey / March 24th, 2015
SSAE 16, SOC 2, HIPAA, PCI DSS, FISMA, ISO 27001. We’ve all heard of the Alphabet Soup, but what do they all really mean?
Which one is right for me? Which one should I pursue? Why would I get this audit over that audit? As auditors, these are the questions we are most frequently asked.
To help answer these questions and truly familiarize you with the different audit frameworks, we’ve broken down the Who’s, What’s, and Why’s for the most commonly reported on frameworks.
SSAE 16/SOC 1
Who asks for an SSAE 16? If you work with publicly traded companies, financial institutions, or state or local government, you will frequently be required to have an SSAE 16 (or SOC 1) audit performed by a third party. It is the most commonly used form of attestation for service providers in the US. So what is an SSAE 16? It’s an audit and report on internal controls (whether related to information security, financial, operational, or compliance controls) at a service provider that are relevant to their client’s data. The SSAE 16 audit takes a risk-based approach, with specified objectives that are created to address client risk, and controls, or activities, to accomplish each objective. A third-party auditor would be looking at your environment to make sure your objectives are appropriate, your controls are effectively designed, and that you are doing what you say you are doing. An SSAE 16 audit is as good as its scope.
SOC 2
Typically, the same clients who are asking you for an SSAE 16 will be the ones asking you for a SOC 2 audit. Whereas SOC 1 was designed to validate internal controls at a service provider that relate to client financial reporting and validate information security, SOC 2 was a framework specifically designed for companies delivering technology related services. The SOC 2 framework is finally gaining popularity. SOC 2 was specifically designed to report on one of five principles: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The established criteria for each principle address the following questions: How are your policies and procedures relative to the standard documented? How do you communicate those to all interested parties? How do you monitor that those controls are being effectively performed?
HIPAA
If you are working for a healthcare provider or a Business Associate who services a healthcare provider, you are going to be asked for validation of your compliance with HIPAA laws. Any entity who handles Protected Health Information (PHI) will be responsible for compliance with HIPAA. Legislation requires appropriate Physical, Administrative, and Technical Safeguards to protect PHI. Much like the SSAE 16, HIPAA compliance is risk-based. You must begin by performing a Risk Assessment to determine what the appropriate physical, administrative, and technical safeguards are, implement those, and then perform regular monitoring to ensure the safeguards are still appropriate. There is no “hard list” of requirements for HIPAA, and there is no certification. A third-party audit would provide validation of your controls and their appropriateness and effectiveness.
PCI
The PCI Data Security Standard applies primarily to the payment card industry. If you store, transmit, or process cardholder data, you will be required to comply with PCI DSS. Additionally, if you have a client who is required to comply with PCI DSS, they are required to validate your compliance with the standard as well. PCI DSS is a very robust information security standard, and is also sometimes used as a best practice, even without handling credit card data. A PCI audit is an information security audit focused on the protection of credit card data. All PCI audits are performed by a PCI Qualified Security Assessor (QSA). There are over 200 controls and 1,000 audit tests that make up the framework and process. There are six control objectives with 12 subject areas. When a third-party auditor performs a PCI audit, it results in a PCI Report on Compliance (ROC).
FISMA
FISMA Compliance is required of anyone working with the federal government, a federal contractor, or a sub-service provider of a federal contractor. FISMA is the law. NIST Special Publication 800-53 is the actual standard that lists the individual security controls required to comply with FISMA. A FISMA audit is a thorough assessment of your information security practices as it relates to NIST SP 800-53 requirements. It involves a detailed risk assessment, and a selection of comprehensive controls determined by whether you are a low, moderate, or high category. Out of the frameworks we’ve covered so far, FISMA is the most extensive.
ISO 27001-27002
If your customers are doing business globally, chances are you’ll be asked for an ISO 27001 audit. It is a very mature, holistic, information security standard that is widely recognized and highly revered on an international level. 27001 is the entire standard, and 27002 refers to just the controls. An ISO 27001 audit is a complete audit of your Information Security Management System (ISMS). This includes management system, risk management, internal audit, management review, continual improvement, and information security controls.
What is Meant by Audit Framework?
If you are unsure what is mean by an audit framework, please read over these Kirkpatrick Price resources:
Chief Compliance Officer Series: Constructing an Internal Audit Framework
Determining which audit framework is the best for your organization depends on a number of things; who your clients are, who your clients’ clients are, and what kind of information you process. For more information on a specific framework, or if you are interested in speaking with an Information Security Specialist for a consultation, contact us today.
