Which Security Standard Should I Use?

One of the big questions we get is "which standard should we use?"  Or "which security certification should we get?"  Oh and what is a SOC 2 Type 2 anyway???

Although securityprogram.io is neutral to which standard you use, we have seen customers mature through different levels of security in different standards and to be blunt, we've seen people get stuck.

The TL;DR of this post is to start with something simple and achievable but work with a standard over the long term toward something more robust. We recommend CIS 20 to NIST CSF to NIST 800-53.  

In securityprogram.io, we have a Simple Program that is even simpler to do than the CIS 20 and makes it easy to do the most important things first, regardless of the standard or certification you care about.  

We recommend doing the certifications when you need to but not before.


Often companies come to us with the idea that they need to do SOC 2 or FedRamp because a prospective customer asked for it.  There is a really big difference between asking for a SOC 2 and requiring it.  Often, the best response is to say that you don't have it yet - is it required?  If so, when is it required?  Then, you can plan.  On some level, if you are going to have to do a big security lift to land a deal, that is a business decision.

Note that any of these certifications are a long term commitment.  Once you do it once, you will probably want to conduct annual audit activities.

Obviously, in some areas organizations need to be more proactive.  For example, companies that process credit cards need to think about PCI-DSS.  Companies that handle health information should be aware of HIPAA and HITECH.  Companies in the DoD supply chain should know about CMMCNIST 800-171 and ITAR.  Public companies have SOX and financial institutions have FFIEC.  Education companies and institutions worry about COPPAFERPA and even state laws like SOPPA.  

These are all useful and have their place, but we wouldn't necessarily build a security program around them.  We typically like to see a functional security program based on a broad open standard (typically NIST 800-53 or ISO 27001) with the more specific certifications or standards layered on top.  We like NIST CSF too because it can be used to model improving maturity over time and it can be easier to read and understand.


First we should say that we don't do SOC 2 audits or certifications, but we work with a number of firms that do.  To get a fully authorized answer, you should probably talk to them - maybe get a quote and understand directly what they think you need to do.  That being said, it is a common enough question that we thought it might be useful to demystify it all a bit.

Broadly speaking, a SOC 1 is more of an administrative or financial control audit which doesn't mean so much for companies demonstrating information security.  

A SOC 2 is an audit that checks the organizational and information security controls you have in place.  There is a SOC 2 Type 1, which reflects a point in time and there is a SOC 2 Type 2 which audits that the controls have been implemented over a period of time. Most engagements we have seen start with a gap assessment then do a SOC 2 Type 2 (after 6 months of information gathering from the starting gun).  In some cases, there is a strong need to do a SOC 2 Type 1 because it can be done faster.

A SOC 3 is just a more public version of the SOC 2 Type 2 report that is intended for distribution to partners.  Of course, it costs more to do each piece so you want to navigate based on what you need.

In some cases we have seen efficiencies from combining audits (eg. SOC 2 and ISO-27001) at the same time.  Sometimes the work is actually duplicated, so it doesn't actually save your company time.  Of course, if you are collecting evidence it can be useful to collect it once and push it to two different places - but the systems I have seen for supporting these audits are pretty limited in terms of saving the subjects of the audits time or money.

While we're talking about SOC 2, we should mention that we also see SIG Lite and Cloud Security Alliance CAIQ and CCM with some frequency.  These are also useful references, but in our estimation lack the backing of the SOC 2 for formal certification and the breadth and backing of NIST 800-53 for general program alignment.

We should also note that companies sometimes believe that once they do their SOC 2 Type 2 they will be able to just reply to security inquiries from prospects or partners with a PDF of the report.  While the report goes a long way to substantiate the program to third parties, there is often still a more specific questionnaire that goes along with it.


Since securityprogram.io abstracts away which standard or certification goal is requiring you to do the tasks of building a program, as a user you just do the tasks and work toward a more secure state.

Then when it is time to consider or prepare for an audit, you have mappings to different frameworks and you can start to understand how close or far you are from being ready.

SPIO gives you a contextual sense of the progress you are making overall.  This type of dashboard can be useful on a week to week basis to ensure that progress is being made.

SPIO also maps your work (live) to different standards to show progress against those.  Here is an example of the first few CIS 20 controls.

securityprogram.io's CIS 20 audit compliance progress dashboard

Below is an expanded view of NIST CSF.  You might imagine trying to get all of the green bars to 50% as an initial goal.

securityprogram.io's NIST CSF audit compliance progress dashboard

Again, while you're doing all of this work, the core tasks you see explain what to do and map to NIST 800-53, which has the advantage of being a fairly comprehensive open standard.  ISO 27001 is comparable but has a licensing model, which makes it a little less portable.


We know.  We just threw a lot of acronyms at you.  You don't really care about the acronyms, you just want the work to get donethe deal to close and to be able to know that you are doing the right work.  

SPIO was conceived as a solution that could democratize access to awesome security help.  If you use SPIO, you know you are doing the right work.

At the same time, one of the biggest lessons we have learned in helping people build programs is that we can't do all the work for you.  Some of the tasks will inevitably come back to someone in your HR department, an engineer with access to production or a team that handles laptops.  To succeed, you have to commit to do that work yourselves.  It makes sense.  You can't get security without doing the work.

The neat thing about SPIO is that you can largely bite off that work yourself and prepare your organization by doing the baseline security work that is required for all of these standards.  When you need help, you can bring in an expensive hired gun or start hiring a security team.


The point of this post is to explain our underlying strategy for SPIO users as it emerges from our work in securityprogram.io - which is the culmination and amalgamation of many hard won lessons from customer projects over the last 7 years.

  1. Align to NIST 800-53 over the long term
  2. Separate the idea of the task from the standard and cross map them so that you get credit for doing the work against any of the supported standards
  3. Work through the tasks in thematic Rounds where you focus on different areas
  4. For shorter term goals, and to immediately take action on the most important items, start with the Simple Program
  5. Then move to CIS 20
  6. Then move to NIST CSF and gradually set maturity goals and work toward those
  7. Then move to NIST 800-53
  8. Use maturity against the standards (SOC 2, ISO, CMMC) to know that you are ready for audits

The benefit of this approach is that you get to focus on smaller chunks of work on a week to week basis, while working toward a larger goal that will help you meet whatever challenges come your way.  SOC 2 or no, you will be ready.

Again, SPIO was conceived as a solution that could democratize access to awesome security help.  If you use SPIO, you know you are doing the right work.  The contents of this post explain how you know we know you are doing the right work.

We'd love to hear your feedback or talk more about it!

Security Culture: Vulnerable Dependencies

In the latest video of our Security Culture series, we talk about software dependencies. You can also listen in on our podcast.


When we build software, we use lots of libraries that we didn’t write. They could be open source, they could be commercial, they could even be framework code provided by a big company as part of a platform.

In any case, we have lots of code running in, over, under and around the code we actually write. If there is a problem in any of that surrounding code, it can effect the security of the software we are writing.


It is important to realize that frameworks, stacks and operating systems represent very rich targets for attackers. As an attacker, if I can find a vulnerability in Jemurai.com’s code then I can attack Jemurai.com. But if I find a flaw in say Rails or Struts, then I can attack all the sites across the internet running Rails or Struts. That means my work applies across a lot more targets. So I’m going to spend some time on this. In addition, often that code is available and open source so I can create and analyze it in a test environment.


To avoid being exposed by dependencies, we need to do two things:

  1. Update in general
  2. Detect and update in the case of a vulnerable dependency

The second item is obvious, and we list a number of tools below that you can use to detect vulnerabilities in your dependencies. You may also want to watch mailing lists for major libraries that you use so that you know what is happening with security updates.

The first item is less obvious - and turns out to be challenging in practice. We need to update in general because you never know when you’re going to quickly need to do number 2 (childish giggle) and if you are not up-to-date that can be really hard.

What do I mean by that? If you are say a major version or two off of a library like Rails, JQuery or almost anything else, you have to expect a certain amount of drift in the signatures and methods you use to interact with that library. The more the signatures change, the more work it is to update from Version 2.1 to Version 4.2. So we need to keep up to prevent ourselves from getting into a spot where we want to update by tomorrow but can’t for 3 weeks because there is so much migration work.





Our Posts: