Skip to main content


Assess your state of compliance and the risks and potential costs of non-compliance in order to prioritize, fund and initiate corrective action.

About SimpleRisk

SimpleRisk is a comprehensive GRC platform that can be used for all of your Governance, Risk Management and Compliance needs. It boasts functionality that is comprehensive enough to be utilized by some of the largest organizations on the planet while presenting a user interface that is so simple and intuitive it can be used by the least technical people in your organization.

Our SimpleRisk Core can be downloaded for free from our website, installed in minutes, and provides all of the capabilities that you need when first launching your GRC program. As your organization grows and matures its processes, our SimpleRisk Extras are licensed modules that provide enhanced functionality on par with competitors that cost orders of magnitude more and require months of professional services to install and configure. There's no need to waste all of that time and money when you can be up and running with SimpleRisk today.

What is Enterprise Compliance?

Enterprise compliance activities are designed to ensure that an organization is conforming with its stated requirements. Management will identify which requirements are applicable based on laws, regulations, contracts, strategies and policies. Once the applicable requirements have been identified, the organization then needs to assess the state of compliance with those requirements.

Any areas where the organization is not meeting the requirements is considered a deficiency, which typically equates to a risk in our environment. The mitigation for these risks can then be prioritized against all of the organization's other initiatives.

Identifying Applicable Requirements

The first stage of any Compliance program is to identify all of the applicable requirements. The list of requirements for a given organization can vary based on industry, geography, customers and a variety of other factors. We typically recommend a data-driven approach to requirements gathering. This means analyzing each of your organization's systems and processes in order to identify what kinds of data is stored or processed by each of them. You should especially be on the lookout for the following types of data:

Personally Identifiable Information (PII)

This is information that, when used alone or with other relevant data, can be used to identify an individual. It may include direct identifiers, such as a social security number, drivers license number or passport number, or other information that when combined can successfully identify an individual, such as race, date of birth and address.

Protected Health Information (PHI)

This is information about health status, provision of health care or payment for health care that is created or collected and can be linked to a specific individual. This includes any part of a patient's medical record or payment history.

Cardholder Data

This is specifically related to the full payment card number, also known as a Primary Account Number (PAN), found on payment cards such as credit and debit cards. There are additional requirements on the Card Verification Value (CVV) found on many of these cards, as well.

Customer Confidential Information

This is information that your organization is in possession of on behalf of a customer and is under a contractual Non-Disclosure Agreement (NDA) to keep that data secure.

Company Confidential Information

This is information that your organization considers to be proprietary, a trade secret or that could otherwise damage the organization's finances or reputation should it become public.

While not an exhaustive list, these represent some of the most common types of data that you will need to identify for your organization, as each of these will likely bring new requirements into scope. You should also take the time to discuss compliance with your Human Resources and Legal departments in order to ensure that you are taking all of the data into consideration and aren't leaving any gaps that could introduce risk at a later time.

Control Framework Requirements to Protect the Data

Once you've identified what types of data you need to protect, the next step is to determine the requirements to protect that data. With the types of data outlined above, we frequently see the following control framework requirements identified:

Personally Identifiable Information (PII)

There are a large number of requirements around the protection of PII that end up being largely based on where an organization operates. For example, if you collect the PII from EU citizens, then you should be concerned with the General Data Privacy Regulation (GDPR).

Protected Health Information (PHI)

The primary requirements around the protection of PHI in the United States stems from the Health Insurance Portability and Accountability Act (HIPAA).

Cardholder Data

The Payment Card Industry (PCI) Security Standards Council is the organization responsible for the development, enhancement, storage, dissemination and implementation of security standards for account data protection. They have released the Data Security Standard (DSS) as a standard set of requirements around protecting cardholder data

Customer Confidential Information / Company Confidential Information:

There is no universal framework that all organizations use for their privacy and security requirements around confidential information.

For United States government organizations, we typically see the NIST Cybersecurity Framework (CSF), NIST Privacy Framework, and NIST SP 800-53 as the basis for their controls.

For organizations handling data on behalf of the government, we frequently see the NIST CSF and NIST SP 800-171 as the required control frameworks.

Outside of the United States, many countries have their own standards organizations which establish their own control frameworks such as the Australian Cyber Security Centre (ACSC), New Zealand Information Security Manual (NZISM), or Dubai Information Security Resolution (ISR).

We've also seen a number of organizations adopt broader proprietary frameworks such as ISO 27001 and HITRUST to protect their confidential information.

Managing Frameworks and Controls

After the frameworks that apply to an organization have been identified, those frameworks will need to be loaded into a GRC tool to manage the controls, validate their effectiveness and associate them with risks. On our Governance page, we provide a step-by-step instructional on the different ways to load controls into SimpleRisk.

While Governance is focused on documenting these frameworks, an organization's Compliance initiatives are going to focus on validating their effectiveness. This is where having a tool to manage your audits is extremely valuable.

Defining Tests to Validate Compliance

In SimpleRisk, functionality around the validation of controls to ensure that they are operating effectively happens within the Compliance menu. For example, in this demonstration environment, we've imported the NIST Cybersecurity Framework (CSF) using SimpleRisk's Import-Export Extra and the CSF import file made available in our public GitHub repository here. As a result, all 108 of the NIST CSF controls are now showing in SimpleRisk's Governance section:


Now, with the proper control framework having been loaded into the system, we can define the testing to validate these controls. To do this, we select "Compliance" from the menu items at the top. There, we will see a list of all of controls and a button to "Add Test" for each of them. When clicked, this gives us the option to specify all of the relevant information that we would need to test the control such as the test name, who is responsible for running the test, how often the test should be run, when it was last ran, the test objective, the steps necessary to conduct the test and the expected results of the testing. Here we see an example of the ID.AM-1 control above with a test defined to "Verify the inventory of physical devices and systems". We can see that this test has never been conducted before and is expected to take approximately 90 minutes to complete.


Initiating an Audit

You can think of the test that we just defined as a template describing the test to be conducted and how to conduct it in the future. If we actually want to create a new audit based on this test, we need to select "Initiate Audits" from the menu on the left. There, we will see a list of every framework defined in SimpleRisk that has a control with a test associated with it. We can expand the name of the framework to see a list of each of those controls. Then, we can expand the name of those controls to see a list of each of the tests.

As you can see in the screenshot below, in SimpleRisk you have the ability to select "Initiate Framework Audit" if you'd like to initiate an audit across all controls and tests associated with that framework, you can select "Initiate Control Audit" to initiate an audit across only the tests associated with a given control or you can select "Initiate Test" to only initiate an audit for the individual test. This enables you to do something like testing the entire framework on an annual basis, while ensuring the operating effectiveness of specific controls on a more frequent basis, such as monthly or quarterly.


Managing Active Audits

Under the "Active Audits" menu, you will see a list of all of the audits that are currently in an active state. Here we can see that our test to "Verify the inventory of physical devices and systems" has been initiated.


By clicking on the test name, we can see and set the status for this test. We can include information in the summary, attach documentation and evidence of our ongoing testing, and add comments for this audit. When we are ready to mark the audit as complete, we set the Audit Status value to "Closed" and give it a test result of "Pass", "Fail" or "Inconclusive". At that point, the test will no longer be displayed in the "Active Audits" menu and now you will still find it under "Past Audits".


Viewing Past Audits

The "Past Audits" menu is designed to show you all of the audit testing that has been conducted in the past and is now completed. Tests displayed here are color coded to show whether they were a pass, fail or inconclusive. If you have third-party auditors such as an Internal Audit team or an external audit firm that reviews the results of your testing, you can use SimpleRisk's fine-grained access controls to provide them with access to review these test results without giving them the ability to view or even change other parts of the SimpleRisk system.

All users with access will be able to filter through the completed audits on the basis of the test result, test name, associated frameworks or controls, some specific test or the date on which the test was conducted. They will be able to view the details of the past audit in order to see all commentary and view the attached evidence. This provides you with a simple, yet effective, way to manage all of your compliance testing from a single location.


Reporting on and Automating the Compliance Workflows

One key report to help you to more effectively manage your Compliance workflows is called the "Audit Timeline" report and can be found under the "Reporting" menu in SimpleRisk. This report will show a list of all audits that have been conducted and highlight both the last time the test was conducted, as well as the next date a test is due. With each test, you'll have action buttons to initiate a new audit, view any currently active audits and view past audits.


With our licensed Email Notification functionality, we can drive automation into your audit workflows. As the audit statuses change or comments are added to them, this functionality will send notifications to key stakeholders about these actions taken within the system. Additionally, SimpleRisk can be configured to check on a daily basis for any audits that will soon be due based on a combination of the last time they were tested and the test frequency. You can configure automated notifications of these pending audits to email to key stakeholders at pre-defined intervals both before the due date and after the due date has been passed.

Audit Trail

SimpleRisk was built by a security professional with a decade of experience running the Information Security Program for a large, publicly traded, global enterprise. He realized that it was critically important for an auditor to be able to look at the data contained in SimpleRisk and trust that it has not been modified. For that reason, all activities that take place within the tool are logged and an audit trail is maintained. At any point in time, an auditor can go back and establish what has been done, who did it, and when.


SimpleRisk was designed from the ground up to be as simple and intuitive as possible in order to enable users of varying skill levels to be effective using it. Over the years, SimpleRisk has evolved into a comprehensive GRC platform encompassing all of the Governance, Risk Management, and Compliance needs of organizations, regardless of their size or industry, while retaining its underlying simplicity.

Most of the features discussed here are available in our free and open source SimpleRisk Core product, but even the licensed functionality can be obtained for a fraction of the cost of other GRC tools. We would welcome having an opportunity to join you on your GRC journey and would encourage you to schedule a call with our team, where we can discuss your requirements and demonstrate, firsthand, how SimpleRisk can help you accomplish your goals.