There’s quite a bit of chatter today in the world of regulatory compliance regarding SOC 2 vs. NIST 800-53. Both the AICPA SOC auditing framework (which consists of SSAE 18 SOC 1, SOC 2, and SOC 3 reports) and the NIST SP 800-53 publication are major players in today’s growing world of regulatory compliance, so let’s take a deep dive into the SOC 2 vs. NIST 800-53 discussion.
5 Things You Need to Know about SOC 2 vs. NIST 800-53
1. SOC 2 is Part of the AICPA “SOC” Framework: The American Institute of Certified Public Accountants (AICPA) launched the SOC assessment report framework in 2011, and with that came three (3) new reporting options: SOC 1, SOC 2, and SOC 3. SOC 1 reports initially used the SSAE 16 standard – which has been replaced by the SSAE 18 standard – as the official “standard” for issuing SOC 1 reports. SOC 2 reports use the AT 101 standard, as do SOC 3. Together, these three (3) reporting options replaced the one-size-fits-all SAS 70 auditing standard that had been in use since 1992.
Initially, the SOC framework stood for “Service Organization Controls”, but that was recently modified and is now called “System and Organization Controls”. Fast forward now and the SOC 2 standard is now arguably become the most widely recognized out of all three (3) SOC options, and that’s because more and more technology-oriented businesses are undergoing annual SOC 2 compliance. Think data centers, Software as a Service (SaaS), managed security service providers – and more – they are all ideal candidates for annual SOC 2 compliance.
2. NIST 800-53 is a Publication: NIST Special Publication 800-53 is a comprehensive information security publication that provides a robust set of security controls for federal information systems. It’s one of the most well-respected and well-known security publications found anywhere in the world. More specifically, NIST 800-53 contains a catalog listing of control families and related security and privacy controls that entities (i.e., both federal agencies and federal contractors) need to have in place.
According to NIST, 800-53, Revision 4, represents the most comprehensive update to the security controls catalog of controls that were launched in 2005. The publication was developed by NIST, the Department of Defense, the Intelligence Community, and the Committee on National Security Systems as part of the Joint Task Force, an interagency partnership formed in 2009. The updates for NIST 800-53 were primarily undertaken because of the growing threat vectors, and the frequency of such attacks.
As such, various security controls and control enhancements have been developed and added into the catalog of such security controls, effectively addressing such areas as the following: mobile and cloud computing; applications security; trustworthiness, assurance, and resiliency of information systems; insider threat; supply chain security; and the advanced persistent threat. You may find white papers, blogs, and other information online referring to NIST 800-53 as a “framework” also, which can be justified as the entire publication is built on a framework of specific controls.
3. SOC 2 TSP vs. NIST 800-53 Control Families: Both the SOC 2 framework and the NIST 800-53 publication consist of subject matter that serve as the very basis of their existence and intent. For SOC 2, it’s the Trust Services Criteria (TSP), and for NIST 800-53, it’s the Control Families. Let’s take a deeper dive into each of these.
First, the five (5) TSP’s, which consist of the following:
- Security. Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives.
- Availability. Information and systems are available for operation and use to meet the entity’s objectives.
- Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives.
- Confidentiality. Information designated as confidential is protected to meet the entity’s objectives.
- Privacy. Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives.
These very TSP’s form the underlying framework of a SOC audit, for which auditors assess a wide-range of what’s known as “Common Criteria” Controls for each of the respective TSP’s. So, how many of the five (5) TSP’s are included within the scope of a SOC 2 audit? That depends on auditing needs and business processes that must be assessed. You could assess for just one TSP, a few, or all five (5).
As for the “Control Families”, Security controls described in NIST 800-53 have a well-defined organization and structure. For ease of use in the security control selection and specification process, controls are organized into eighteen families (as of NIST 800-53, Revision 4; Revision 5 is said to have twenty (20) Control Families). Each family contains security controls related to the general security topic of the family. A two-character identifier uniquely identifies security control families, for example, AC stands for Access Control.
4. The Real Differences between SOC 2 and NIST 800-53: Again, SOC 2 is part of the actual System and Organization Controls (SOC) framework, where NIST 800-53 is a robust information security publication consisting of numerous control families.
5. You Can Conduct an Audit against the NIST 800-53 Standard: We’re often asked what does it take to be NIST 800-53 compliant or how do we become NIST “certified”? That’s a rather open-ended question as you’ll first need to identify what your ultimate goal is with regards to NIST SP 800-53.
Here are the two most common scenarios we hear, and the best avenue for meeting those goals.
1. Become FISMA Compliant: Thousands of federal contractors have successfully undertaken the comprehensive FISMA certification and accreditation process, one that can take a number of months to complete. If you’re interested in becoming FISMA compliant, then it’s important to note the following: (1). Begin the process with a FISMA Scoping & Readiness Assessment. (2). Expect to remediate any number of security, technical, and operational controls. (3). Be prepared to develop and document your controls within a System Security Plan (SSP). (4). Expect to hire an independent FISMA compliance firm that will conduct an assessment, complete with results that are documented in a Security Assessment Report (SAR).
2. Perform a SOC 2 Audit against the NIST 800-53 Controls: Because of the flexibility within the SOC 2 auditing standard and the accompanying TSP’s, you can conduct a SOC 2 assessment against the various controls. However, even with that said, a word of caution. First and foremost, ensure you hire an auditor well-versed in working with FISMA and the NIST SP 800-53 standard. Why? Because good auditors know how to develop SOC 2 tests of controls that correctly align the TSP’s and Common Criteria with the NIST SP 800-53 controls. Get it wrong and your report will become heavily scrutinized.
Commonly Asked Questions Regarding SOC 2 vs. NIST 800-53
1. Can you Test for NIST 800-53 Controls in a SOC 2 report? Yes, you can, thanks to the flexibility within the SOC 2 framework which allows for assessing and testing of controls from other standards. There are also a number of mapping tools online which illustrate how other standards fit into the SOC 2 Trust Services Criteria.
2. What’s the Best Avenue for Illustrating Compliance with NIST 800-53? The very best path for ensuring compliance with the NIST SP 800-53 publication is to set your sights on becoming FISMA compliant. The Federal Information Security Modernization Act – simply known as FISMA – requires organizations to fully implement and adhere to the prescribed family of controls within NIST SP 800-53 in order to achieve FISMA compliance. Thousands of federal contractors throughout North America have to become FISMA compliant, with many of them also required to become SOC 2 compliant.
Becoming FISMA compliant ultimately requires organizations to produce a System Security Plan (SSP), a Security Assessment Report (SAR), and then submission of such documentation to a specified federal agency in the hopes of achieving Authority to Operate (ATO) designation.