“Regulations and compliance are for the big guys, we are too small!” “It is all to suck up money from the enterprise!!!!” Don't rush to close this article. We've heard these types of comments many times, so Digital Edge decided to put the idea of compliance into the perspective of a small business. We will explain how to BENEFIT from the STRATEGIES that BIG COMPANIES USE WITHOUT PAYING the same amount!
|
1. The PROBLEM:
There's just too much risk in the world!
PROBLEM 1: "I am a small mortgage broker (or anything else); my agent opened an email attachment infecting all the computers in my office."
PROBLEM 2: "I run a wealth management company (or anything else), I have received a fraudulent email instructing me that my client has changed his account number. My agent trusted the instruction and money was transferred to the wrong bank and disappeared somewhere in Nigeria."
These are just two examples of the many different scenarios that can happen. Both problems lay in the area of the organization of cyber security. Cyber security is an ATTITUDE not part of technology. Cyber security is a BEHAVIOR – not technology. Nowadays people think that cyber security can be achieved through purchasing gadgets. This idea is wrong. It’s the same as thinking that we can defend a fortress by accumulating weapons but forgetting that we have to train garrisons.
PROBLEM 1 might be solved by technology, however, it is not guaranteed. Do you want to spend money on tech that can just fail you?
The PROBLEM 2 CANNOT be solved with technology.
2. The WHY
You need to know where you have critical processes in your business and your information technology. Yes, regulators are writing more and more laws, forcing businesses to follow certain rules to get organized around their IT operations, essentially to protect their own and their client’s assets.
The government is increasing the requirements surrounding cybersecurity in regards to protecting customers data. And businesses are trying to get organized in their approaches of managing these complex regulations.
I'm afraid this is just the beginning. We should all gear up for more.
- The financial industry is already “enjoying” FDIC and others penalties for cyber security and AML failures.
- NYS DFS 500 law.
- Recent EU GDPR (General Data Protection Regulation). Do you think the US will fall behind?
- How about this part of Mark Zuckerberg’s Senate Hearing:
“…
GRAHAM: It is a good business decision. My point is that one way to regulate a company is through competition, through government regulation. Here's the question that all of us got to answer: What do we tell our constituents, given what's happened here, why we should let you self-regulate?
What would you tell people in South Carolina, that given all of the things we've just discovered here, it's a good idea for us to rely upon you to regulate your own business practices?
ZUCKERBERG: Well, senator, my position is not that there should be no regulation.
…”
I hope we all have no doubt in where we are going.
But really Risk Management is something that you NEED, not the regulators.
It doesn’t cost much to sit down and get organized around your very own business. It’s critical points, protections, alarms, and organized responses.
3. The HOW
And starting this process with a new business is always fun, asking questions such as:
|
So, let’s get serious. To still have fun and use it later in any type of compliance and be able to go through any certification later if you really need it in the future, here are the 7 simple steps you have to take:
1. ASSIGN: Define a group of people interested in the health and security of the operation of your organization – risk management board, create an email group. Assign Risk Manager, make it part of his or her title. Send an initial email to the group about forming the board and assigning the risk manager and assigning the title.
2. SCHEDULE: Setup a yearly review meeting in your calendar “Risk Review meeting”
3. SETUP: Setup a SharePoint. Digital Edge can help you with that.
Setup 2 SharePoint spreadsheets:
a. Risk Registry (MD5 9c2fe8729e24ab3b8af8c71c50415071)
b. Incidents (MD5 e3a7f62a844fc9aace94b23654f0e3f3)
You will need to download these tempates and import them into SharePoint. We also recommend creating SharePoint forms rather than uploading them as excel files. But you can use them either way.
Enable version control on them. Version control will be important for possible future certifications or compliance. Even if you don’t need it – it doesn’t cost you anything.
4. MEET: Use the first Risk Review meeting to create your Risk Registry. I wanted to warn you about the balance of the risks.
Risk balance notes:
Risks should not be very detailed as there will be too many of them and it will be very hard to track them. For example: you don’t want to have a risk of a “hard drive failure” or a “mouse malfunction”. At the same time risks should not be broad as they should be detailed. You cannot invoke global contingency plan of failover to another AWS geographical availability cluster if you lose one file.
Please see explanation of the Risk Registry, risk categories, particularities or regulations and security standards in The Why section.
Download examples of risks here: RiskRegistryExample. (MD5: 6433a6587e3e67d7e3d55414a603e7f3)
5. RECORD: The Risk Manager uses Incidents SharePoint spreadsheet to record any abnormalities of your operation during the year. The title on his signature will remind him that he has to do it. He has to remember to monitor how the company operates and record all abnormalities in the Incident registry.
6. REVIEW: In a year, the risk review committee gets together and reviews the risks again going through the Incidents. Risks can be upgraded or downgraded. New risks can be added. If risks are not actual anymore they can be deleted. Meeting notes should be distributed to the Risk Management Committee distribution group.
7. DOCUMENT: Document review and all steps.
These 7 basic steps are enough to setup a risk management practice in your company to pass certification regulations of most of the modern frameworks.
4. The DETAILS
Digital Edge’s VP of Compliance suggests to use the following Risk Registry and Incidents format. It was implemented for multiple large enterprises, it is lean and went through multiple audits and certifications. We also suggest you use SharePoint Lists and Forms to manage risks and incidents. Digital Edge can help configure SharePoint to manage Risks or implement full standard compliance.
Whenever you create a list under SharePoint, do not forget to enable version control. Version control of records is a requirement of many standards such as ISO, NIST, SOC etc.
Risk Registry Explained
The following columns and properties form the Risk Registry:
Property Name | Property Description | ||||||||||||||||||||||||||||||||||||
Title: |
Self-explanatory, just a description of the risk.
|
||||||||||||||||||||||||||||||||||||
Risk type: |
We suggest to categorize risks by following risks types:
We feel that it is important to categorize risks by such types as Human Mistakes, for example, cannot be mitigated by technological controls. System Failures and Cyber Security threats MAY or MAY NOT be mitigated with technological controls only. Disaster risks must be mitigated with both, technology and human processes as well. |
||||||||||||||||||||||||||||||||||||
Management Plan: |
Management Plans are:
Assignment of the management plan is important and defined in all the frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Location: |
Businesses have multiple locations. Location could be for example: cloud, datacenters, multiple offices etc. |
||||||||||||||||||||||||||||||||||||
Likelihood: |
What is the likelihood that this event will happen. We categorize it like this: We also assign digital values to each likelihood:
Those values are used in the formula explained below to calculate the rating of the risk. This categorization is very important and is mentioned in many frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Impact: |
Defines how big the impact of the risk is. Each value also defines a digital value that is used in a formula explained later:
Those values are used in the formula below to calculate rating of the risk. This categorization is very important and is mentioned in many frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Risk Rating: |
Risk Rating is calculated based on following: Rating Index = Likelihood * Impact
Risk Rating = LOW if Risk Index < 12 Risk Rating = MEDIUM if Risk Index < 20 Risk Rating = HIGH if Risk Index >= 20
|
||||||||||||||||||||||||||||||||||||
Current Control: |
A text field describing the way you currently control the list. If you follow any standards such as ISO, NIST, SOC you may use it to put controls or control criteria in here. It is very important to put controls in sync with your risks so all risks are controlled and all necessary controls are described in the Statement of Applicability. All not applicable (N/A) controls should be excluded within the explanation.
|
||||||||||||||||||||||||||||||||||||
Effectiveness: |
Defines how the control is managed:
Sometimes the organization did not test the controls and cannot assess the control effectiveness. |
||||||||||||||||||||||||||||||||||||
Owner: |
Organization must assign an owner of the risk. This requirement is defined in multiple frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Last Test: |
Date of the last test of the control.
|
||||||||||||||||||||||||||||||||||||
Test Result: |
Results of the test:
|
||||||||||||||||||||||||||||||||||||
Residual Likelihood: |
What is the likelihood that this event will happen after control are applied. We categorize it exactly like inherent risk likelihood:
Those values are used in the formula explained lower to calculate rating of the residual risk. This categorization is very important and is mentioned in many frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Residual Impact: |
Defines how big is the impact of the risk after the controls are applied. We categorize it exactly like inherited risk impact:
Those values are used in the formula explained below to calculate rating of the residual risk. This categorization is very important and is mentioned in many frameworks and standards. |
||||||||||||||||||||||||||||||||||||
Residual Risk Rating: |
Residual Risk Rating is calculated the same way inherited Risk Rating is calculated.
|
||||||||||||||||||||||||||||||||||||
Additional Notes: |
Text field for additional notes.
|
||||||||||||||||||||||||||||||||||||
Date Created: |
Version control record.
|
||||||||||||||||||||||||||||||||||||
Date Last Time Modified: |
Version control record.
|
Incidents Explained
The following columns and properties form the Incident Registry:
Property Name | Property Description |
Recorded By: |
Name of the manager that recorded the incident. The incident can be recorded by the Risk Manager. Any manager in the company can record incidents. Mature companies write policies where roles are defined and procedures of how incidents are recorded are spelled out. Digital Edge can help with policy writing in compliance with any required standards. |
Date Recorded: |
Date when the record was created. Digital Edge suggest to populate this field automatically with the system date. |
Date Occurred: |
The date of when the incident occured. |
Manager: |
Manager name – the person responsible for recording the incidents. Sometimes the recording person is different from the manager who manages the area the incident is recorded. |
Client: |
Client name if there the incident has any relation to a client. |
Category: |
Digital Edge defines following categories:
This categorization is a free form and can be customized. |
Location: |
The location of where the incident occured. |
Description of Event: |
This description is a brief description of what happened during the incident. This description is written by the manager. |
Description of the Employee involved: |
This description should be written by the employee involved in the incident. |
Manager’s Review/Conclusion: |
The manager's review of the incident. |
Risk Connection: |
This field defines the risk name. |
Each record of an incident that is related to the risk should increase risk “hits” or KPIs. Those KPIs should be reviewed on yearly Risk Management Board meeting.
Cyber Security KPIs will be reviewed in the next article!