Why we use NIST 800-53 as our base-level Security Standard

The SPIO platform helps small companies build, mature, and document their security programs. We designed the SPIO platform around the NIST 800-53 standard. It's the model for the policies, training, and task buckets we’ve created for our clients to use. Our clients don't have to start with NIST 800-53, but we believe it is a useful jumping off point for most small companies. Using it as the model provides an effective roadmap toward developing a robust security program that complies with many common information security standards.

Here’s why we use it as a baseline standard and how it helps small companies achieve compliance.


First titled "Recommended Security Controls for Federal Information Systems," NIST 800-53 was initially published in 2005. Its purpose was to improve security of the information systems of federal agencies. To achieve this, the publication provided guidelines for selecting and specifying security controls.

NIST 800-53 Rev. 3 (2009) was its first major revision. The changes included updating security control baselines to reflect evolving threats, providing recommendations on prioritization of security controls, and more closely aligning NIST 800-53 with other standards.

As part of its fourth revision, in 2013 the publication was renamed as a Special Publication on "Security and Privacy Controls for Federal Information Systems and Organizations". This revision expanded its scope beyond civilian agencies to the Department of Defense and Intelligence Community. It also expanded the scope of threats addressed. For example, security controls were added to address mobile and cloud computing, supply chain security, and insider threats.

NIST 800-53 Rev. 4 remains in effect until September 23, 2021, when NIST 800-53 Rev. 5 will take effect. The control selection process and baseline sections have been moved to other special publications. Instead, NIST 800-53 Rev. 5 focuses on the control families and controls themselves. The goal in moving selection and baseline guidelines elsewhere is to provide greater flexibility for different organizations in determining which controls to use in their security program.

The updated control families and control list has been re-organized and expanded. For example, there are now control families specifically for privacy and supply chain risk management. Overall, revision 5 has 20 control families (up from 18) and over 1000 controls (up from 800).


It isn't enough to have strong security; your company must also be seen to have strong security.  We wanted our platform to help small companies achieve both. We decided to build our platform so our clients could show third parties that their security program aligns with a well-known security standard.

The question at the time was this: Which widely-accepted security standard do we use? We chose NIST 800-53 because it is:

Broad and comprehensive. Many standards have a narrow focus. For example. SOC 2 applies to service organizations and PCI DSS applies only to credit card transactions. These are valuable security standards within their sphere, but they're too specific to work as a baseline.

Open and accessible. Anyone can download all the NIST publications, including NIST 800-53 and its related publications. Other broad standards, like the ISO standards, come with significant licensing fees. Ultimately, these fees would impact cost accessibility of the platform for small companies. More importantly, openness means everyone knows what's in the NIST standards. Companies can demonstrate their compliance without paying for costly certification or auditor services.

Upstream from many other security standards. Many other common standards are derived from NIST 800-53. CMMC, FedRamp, and NIST 800-171 are just a few. With so many standards flowing from 800-53, it's a strong foundation for achieving compliance with other standards. The SPIO platform maps security tasks across most common standards. So as our clients work through task lists based on 800-53, they see how those tasks map to requirements of other standards.

Prescriptive and flexible. NIST 800-53 and its related publications provide a methodology companies can use to guide their selection of controls and a detailed list of controls. Other standards, like SOC 2, outline the domains that companies must address, but don't offer too much specific guidance on how to do it. NIST 800-53 is designed with a variety of controls so that each company has the latitude to make its individual choices while still remaining within the standard.

Our choice of NIST 800-53 as the SPIO platform base-level standard doesn't mean it's perfect. No security standard is. For example, because it's so broad, it can also seem overwhelming. Companies can avoid the overwhelm by working with a platform like ours, which breaks 800-53 into task buckets they can work through sequentially. On balance, NIST 800-53 creates a solid foundation for establishing and maturing a security program. 


The breadth of NIST 800-53's scope and its extensive list of controls provides a practical roadmap for continuous, incremental security improvement. Making progress through each of its control families strengthens your security posture. Its comprehensiveness ensures that you work through all the critical security questions you need to address.

Meeting the NIST 800-53 standards does more than improve your security program. It also improves your company’s security compliance with a broad range of common security standards. The fact that so many other security standards are downstream from 800-53 means complying with it takes you a long way towards complying with other standards.

Security compliance is the "being seen" part of maintaining a strong program. Potential partners and customers may want to see your level of CMMC compliance, a SOC 2 report, or some other popular security standard. Even those that don't require a formal certification or an audit report often want to see proof of a solid security program that aligns with a well-known standard.

The SPIO compliance management software helps provide that proof.  Each task is cross-referenced with the corresponding requirements in many standards. As your company progresses through tasks based on the NIST 800-53 framework, you're also checking off the aligned requirements in other standards. Your SPIO dashboard shows your progress against all the applicable standards.

If your company does a good job with NIST 800-53, then you've eased your path for certification or passing an audit. Each auditor or certifier has their own interpretation of the control framework and checklist of what they want to see. So, most companies still have some work to do before getting certification or the audit is complete to satisfy the certifier or auditor. The question is how much work?

When you've already made good progress through many of the 800-53 control families, your company will have most of that work done. You don't have to start from scratch when a potential customer wants to see how well you comply with their preferred standard. Nor will you have to suffer extensive delays to prepare for certification or an audit since you’ll have completed so much of the work by complying with NIST 800-53.


Because 800-53 is such a broad standard, we start by assessing our clients’ security goals. Then we have them get started in our system by adopting security policies on different issues. From there, tasks within the 800-53 framework are organized in buckets around those IT security policy areas. This approach lets them build towards their goals over time and in a manageable way.

Sometimes a company really wants to ease into building a security program before jumping into a comprehensive standard like 800-53. In those cases, we start with a small group of well-defined tasks, like setting up multi-factor authentication, setting up a program to track data shared with partners, and conducting employee security awareness training. It’s a core of quick wins that build confidence to move to a more formal, complex security standard.


Meeting requirements of 800-53 provides a solid foundation, but the truth is that managing your security program is an on-going project. You’re never done. But if you start making progress now and grow as the standard and its controls evolve, you will reach a maintenance state. In a maintenance state, you re-assess existing tasks previously completed and add new tasks aligned with new control families. Your company continues to make progress against more standards and raise the quality of its security program.

A Guide to Common Security Standards

The growing number of security standards out there, each with their own acronyms and jargon, can seem overwhelming—but they don't have to be. We want to help provide some clarity. Here's an overview of five of the most common security standards.

These standards aren’t targeted towards small organizations, but many provide a useful framework for a small business to transform its IT security policy into a robust security program, allowing it to swim in a bigger customer pool. Others apply to specific industries. Read on to get an understanding of each standard's purpose, structure, to whom it applies, and what it means to be "certified."

ISO 27001

ISO 27001 is a set of processes and guidelines any organization can use to develop its information security management system (ISMS). It's broad and flexible enough to work for organizations of any size, industry, or stage of information security maturity. ISO 27001 helps organizations step through each phase of setting up an ISMS. ISO 27001 is widely used by companies with an international footprint and is desirable for U.S.-based companies looking to expand to the EU and beyond.

The ISO 27001 standard opens with eleven clauses, the first four of which provide the standard's foundation and definitions. The last seven specify the phases and policies required for certification—everything from initial assessment to implementation to continuous improvement.

The second part of ISO 27001 is Annex A. Annex A contains 114 controls divided into 14 categories. While each organization needs to implement only those controls that make sense for its specific threat model, it needs to document why it's made the choices it has. The ISO 27001's approach to its control list adds to its prescriptive yet adaptable nature, making it a good starting place for organizations that don't yet have a formal ISMS.

Certification isn't required. An organization can use the ISO 27001 guidelines to create an initial ISMS framework to build upon and improve its security maturity.

As with other security frameworks, there are specific steps to obtain validation to the standard (which requires an audit by an approved third-party). Obtaining the standard from the ISO governing body costs about $150. Preparing for and navigating the formal audit process can be complicated and time-consuming, as you need to address each control with supporting documentation and evidence. Obtaining an ISO 27001 certification requires engaging with an ISO-approved auditing firm.

In our experience, even with the ability to adapt the applicable controls, ISO 27001 audits require more specific preparation than other audits.

NIST SP 800-171 AND NIST 800-53 

NIST 800-53 is a widely used standard that includes a base of about 200 controls across 18 control areas. It is publicly available and widely used by federal and state governments. Some states and agencies have developed their own audit processes around NIST 800-53, but there is no accredited body that can certify you with NIST 800-53 compliance.

NIST 800-171 is a closely related public standard, with many of the same controls, that applies to federal contractors or subcontractors organizations that handle or generate Controlled Unclassified Information (CUI). CUI is information that requires safeguarding or dissemination controls required by law, regulation, and/or policy but which is not regulated by more stringent requirements such that it is classified. NIST 800-171 is a companion standard to NIST 800-53, which defines a control library and baselines for federal agencies. NIST 800-171 doesn't require external certification. Contractors are expected to self-assess and attest that they meet its standards or report their assessment scores. If you're a contractor, it's also your responsibility to ensure that all your subcontractors with access to CUI comply with NIST 800-171. Usually, you will know if you need to meet NIST 800-171 requirements because your customer or parent vendor will tell you. The Department of Defense must periodically review a DoD contractor's compliance with the standard's security requirements.

NIST 800-171 covers 14 categories (or requirement families) of controls. As is the case with many security standards, these categories/families cover common security areas such as access control, personnel security, and risk assessment. A combined total of 110 security controls are prescribed.

An organization can start by implementing a set of baseline controls, as identified under the standard. From there, it can layer on enhanced controls to achieve a more robust level of security, as outlined in NIST SP 800-172.

While NIST 800-171 and 800-53 provide a helpful framework with which any organization can protect its own information. Like ISO 27001, the assessment and documentation standards published by NIST provide a solid foundation on which an organization can establish an information security program and mature it over time. The standards also provide detailed guidance and methodology for conducting self-assessments and creating action plans.


The NIST Cybersecurity Framework (CSF) can be used build a security program with an eye toward risk across several common security functions. NIST CSF defines the following functions:

Each of the functions includes a number of categories and subcategories. Something extremely useful about the NIST CSF structure is that you can use different standards in what it calls Informative References to get very specific about a particular risk area. NIST CSF also defines tiers which allow you to self-assess your maturity level within the controls and build a roadmap from your current state to your target. The tiers are:

  1. Partial
  2. Risk Informed
  3. Repeatable
  4. Adaptive

NIST CSF is used by many states’ Departments of Education as a common standard. However, it isn’t exactly meaningful to audit against NIST CSF. It is more of a useful tool for self-assessing and building a roadmap.


Introduced in 2020, the CMMC improves and standardizes the cybersecurity requirements for organizations in the Defense Industrial Base (DIB). An organization is part of the DIB if it contracts directly with the DoD or is in the supply chain for another DIB organization. By 2026, any organization that wants to be in the DIB sector must have some level of CMMC certification.

The CMMC model centralizes standards for federal contractors from various sources and then adds some new controls. Where the CMMC is especially interesting is its maturity-based certification model.

An organization can be certified at one of five levels, each requiring a higher level of cybersecurity maturity. CMMC describes each level based on the maturity of its processes and practices. Using CMMC language, a level 1 organization performs basic cyber hygiene. "Perform" describes a level 1 organization's degree of process maturity. "Basic cyber hygiene" represents the maturity level of its practices. The rest of the levels are as follows:

The CMMC includes 171 practices mapped across 17 domains and the five maturity levels. The domains include those found in NIST SP 800-171, plus three more:

Within each domain, the CMMC outlines a set of processes and capabilities required for certification at each maturity level. These are cumulative. Level 1 certification covers 17 practices, while organizations that want a level 5 CMMC compliance certification will need to cover all 171.

The CMMC Certification Accreditation Body (CMMC-AB) has begun certifying the third-party organizations approved to conduct CMMC certifications. Organizations that are or plan to be in the DIB should start preparing for certification now.

We generally recommend that you start with Level 1 and work up to Level 3 as a near-term practical use of CMMC. Level 3 demonstrates a strong but achievable level of security for most small and mid-sized firms. Levels 4 and 5 require dedicated security teams with very advanced capabilities.


SOC 2 is a security auditing process defined by the American Institute of CPAs (AICPA) and applies to service organizations. Such organizations often store sensitive organizational and personal data about their customers, either on-premise or in the cloud. SOC 2 audits assess the organization's processes and systems to determine if it's meeting its obligation to keep client and customer data secure.

Certified external auditors conduct SOC 2 audits. The goal is to obtain a SOC 2 report that attests the organization's security program meets its standards for protecting the security, availability, processing integrity, confidentiality, and/or privacy of sensitive information. SOC 2 groups its controls into five Trust Service Criteria (TSCs), which each cover the following issues:

There are two types of audits to assess an organization's level of SOC 2 compliance. A SOC 2 Type 1 audit and report assess the processes in place on a given day. A SOC 2 Type 2 audit is conducted over a time interval, typically three to twelve months. The SOC 2 Type 2 report assesses whether the security systems and processes have been followed during the period under audit based on a review of evidence provided. If they are, the SOC 2 report "attests" that the organization's security program implements the controls that satisfy the TSC criteria for which it’s being audited. An organization doesn't need to request an audit of all Trusted Services Criteria. It can start with the TSCs that are most important to its customer base and build from there.

For a more detailed look, read our detailed guide to SOC 2 compliance requirements.

SOC 2 Type 2 compliance is extremely beneficial for smaller technology companies. Many larger firms (particularly in North America) have started requiring evidence of SOC 2 compliance as part of their vendor management process.


The CMMC and NIST 800-171 standards are intended for specific types of companies. If you do business with federal agencies or DoD specifically—or if you subcontract with federal contractors—you need to comply with these standards. CMMC compliance can cover much of the NIST 800-171 compliance, depending on the level of CMMC certification you achieve.

If you're a SaaS company or other service provider that manages client data, you don't need to be SOC 2 compliant to operate. However, working from a SOC 2 compliance checklist will go a long way towards a security program that genuinely protects your customers. Since many potential vendors, customers, and partners want to see a level of SOC 2 compliance, getting a SOC 2 audit is almost always worthwhile.

ISO 27001 and NIST CSF both provide well-defined processes and controls to help a company build a security program from the ground up. They also both provide valuable roadmaps to maturing your security program over time.

With securityprogram.io, we build the base controls around NIST 800-53 and map to each of these other standards so that you can identify the work once and track alignment to the other standards automatically. While we will help you design, build, and prepare your program; you still need to have an independent auditor make sure you are prepared for their audit process and perform the audit.