Security Compliance Simplified.

Aberrant’s loosely coupled service neutral approach to security and privacy scales better than any other solution in market.


Important Features


Aberrant’s Open-ISM™ will save you hundreds of hours writing your own Information Security
Management (ISM) policies and procedures. It’s also free for non-commercial use.


What is the Open-ISM?

The Open-ISM™ is a templatized corpus of documentation that is designed to serve as your security program’s ‘control standard’—e.g., documented policies and procedures that describes how you comply with security controls. 


You may have heard of an ISMS—ISM documentation is the central component of your Information Security Management System (ISMS). The Open-ISM is templatized ISM documentation that contains all of the documentation that you’ll need to start a security program.


Can’t I write it myself?

Writing your own ISM documentation can take 500 hours or more. Aberrant’s Open-ISM is equivalent to making a cake from cake mix. It requires a little work, but 80% of the heavy lifting has been done for you. Aberrant’s Open-ISM will easily save you hundreds of hours of time.


What’s policies and procedures are included in the Open-ISM?

The Open-ISM™ is templatized ISM documentation that contains most, if not all of the documentation that you’ll need to start a security program.

How do I get the Open-ISM for my organization?

Only Open-ISM™

If you want the Open-ISM for commercial use and you don’t want to use Aberrant’s ISM-P then click HERE.

Non-commercial Use

If you’re a non-commericial organization--e.g. an academic institution or a 501(c)(3)

Aberrant product

If you want to use Aberrant’s ISM-P then the OPEN-ISM is deeply discounted, and in some cases free.

More Info

How did Open-ISM come about? Why are you doing this?

There are many security standards and privacy frameworks, but very little by way of ISM documentation that is publicly available. If you’re starting with a security program, the task of writing hundreds of pages of documentation to map to security controls can be overwhelming. Open-ISM is designed to get you 80% of the way to a working control standard. Our documentation is battle-tested and has withstood multiple reviews by third-party auditors and registrars with flawless results. 


A quality control standard is the cornerstone of a good security program. Think of controls and the control standard as a pre-flight checklist—documented processes are one of the reasons air travel is so safe. Our ISM documentation is meant to help you avoid process gaps that would inevitably result if you had to write your own control standard from scratch. 


At the end of the day, we're simply trying to make it easier for companies to implement a formalized security program by demystifying the process. In aggregate we believe this helps to mitigate a national security vulnerability. Having a documented process that is audited to ensure consistency increases the quality and reliability of control compliance. Our ultimate goal is to make the internet a safer place to conduct business.


What do you mean 80% of the way? Can’t I just use the Open-ISM and be done with it?

The composition of your infrastructure, processes, and procedures is highly variable. As a result, it’s really not possible to write a one-size-fits-all control standard that fits every organization perfectly. The Open-ISM is designed to give you a strong foundation. We give you a starting point and allow you, or a consultant, to modify the documentation to fit your organization. Think of the Open-ISM as an off-the-rack suit that requires tailoring—you or your security consultant provides the tailoring.


What security standards does the Open-ISM support?

The Open-ISM is explicitly designed to support CIS V8 Controls, but it has also been used by companies that support ISO 27001:2013, SSAE 18 SOC 2, CMMC, NIST CSF, and HITRUST. The Open-ISM will support any security standard or privacy framework to some degree. It should be noted that Open-ISM currently makes no mention of patient health information (PHI)—although there is a strong overlap between personally identifiable information (PII) and PHI, they are not the same thing. The Open-ISM requires more modification for complicated standards like HITRUST or NIST 800-53, but it will still save you substantial time and effort than if you had to start the process of writing documentation from scratch.


Can I support multiple security standards and privacy frameworks with the Open-ISM?

Yes. A control standard can support one or more security standards or privacy frameworks. In instances where you have to support more than one security standard, you should consider using common controls with a cross-walk framework.


Is it Free?

This work is licensed under a Creative Commons Attribution-NonCommercial-No Derivatives 4.0 International Public License (the link can be found at (https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode).


It’s free depending on your use case. It’s free if you’re using it for non-commercial use—this applies to 501(c)(3) organizations as well as educational institutions. The Open-ISM™ can also be acquired for free depending on your membership type with Aberrant. Please see pricing for details on how it’s priced for commercial use.


I'm a security consultant. Can I use Open-ISM with my clients?

Your customers in some cases may need to purchase an Open-ISM™ license depending on their Aberrant membership type. Regardless of membership type customers that use the Open-ISM for non-commercial purposes can use the documentation for free.


Does Open-ISM support State Regulations like MA 201 CMR 17.00 or DFS 23 NYCRR 500?

The Open-ISM™ paired with a security standard will put you in compliance with state regulations, however, you’ll want to review legislation and augment your ISM documentation accordingly to ensure that you're in compliance.


Can I use Open-ISM to comply with the GDPR, California’s CCPA / CPRA, or Canada’s PIPEDA?

Yes, privacy is a new and emerging area that overlaps tightly with security. It’s a best practice to use your control standard to manage privacy. Check out ISO 27701:2019 and the NIST Privacy Framework for more information.


What about HIPAA / HITECH, Sarbanes-Oxley Section 404, GLBA, FedRAMP, etc.

It’s important not to conflate laws and regulations with security standards. Security standards are controls that put you in compliance with laws and regulations. The Open-ISM supports all security standards, albeit to varying degrees.


Do I need all the documents in the Open-ISM? There are a lot of documents!

You probably don’t, some of the documentation will be superfluous to you. For example, if you don't have a physical office the Physical Security Policy can be deleted since any physical security controls will be out of scope for your program. Likewise, if your organization doesn’t do software development you can jettison the SDLC. You may also need to add additional documentation to comply with security standards like SSAE 18 SOC 2: e.g. a “SOC 2 System Description.”


Does the Open-ISM address program governance?

Yes, we think including governance in your security program design is a best practice. Governance defines things like approval workflow. That said if you disagree you are free to eliminate the governance documentation. It should be noted Governance is superfluous to the CIS V8 Controls standard, but we still think it’s a good idea that you include it.


What’s the difference between a standard, a policy, and a procedure?

The term standard is overloaded in the security space. We define the control standard as, “a set of company approved policies and procedures that describe the company’s security program. Technically, there should only ever be one control standard per security program. The rule is one security program has only one control standard.”

Governance documents are sometimes referred to as standards because they apply to the control standard generally—e.g. the ISMS Document and Records Control Standard.

A policy is a document that requires formal approval by a governing committee. Policies are directives and are generally devoid of information related to implementation.

A procedure is more of a ‘how to’ document and as a result is uses a less formal approval process—procedures contain implementation details. If your program does not include governance then this distinction likely isn’t important to you. As your security program gets bigger this distinction may become relevant to you. It should also be noted that federal auditors of regulated entities are more likely to want to review your policies than your procedures. That said, you’re free to rename documents if you need to. 

More questions?

Getting started is easy. Contact us or contact one of our implementation partners.

Copyright © 2022 Aberrant - All Rights Reserved.