The third stage of emotional response to changes is bargaining. Having dealt with our anger and emotional component, we began to think about what really needs to be done to ensure that everything worked for us. It is time to study the standard in more detail, apply it to our current situation and adapt its requirements to our company. It was important here to comply with the requirements of the standard to do with "little blood." Any changes should have been adequate - that is, commensurate with the corresponding risk. The costs of protection should not exceed the possible damage from the implementation of the risk.


On this way, we had to solve many issues that we had never encountered before:

Choosing a tool for working on a policy library

The first (seemingly very simple) question that we faced is where to create and how to store all the necessary documents of an information security management system? It was extremely important for us to maintain the versioning of the documents and to be able to "roll back" the version of the policy several editions back. Having studied the offers on the market, we settled on the Confluence wiki - and we use it to this day.

As a versioning system (version control) we could use git, but for the convenience of users we chose a portal solution (Confluence). We managed to limit ourselves to the free version (up to 10 authorized users): we did not need more, since unauthorized users could view the library.

Preparing an implementation plan

Here we did not apply any creative methods - we simply asked our consultant for a list of necessary policies, appointed those responsible for writing and agreeing on them, put down the key dates and put it all in the form of a Gantt chart (which was also uploaded to Confluence).

Company risk assessment

Obviously, to select the means of protection, we needed to assess the risks (in order to spend resources only where it is really needed). To this end, we created a list of company assets that we plan to protect - it included both physical assets (workstations, servers, paper documents, etc.) and intangible (electronic client information, passwords, etc. )

With the help of an expert group, each asset has been assigned a specific value. Next, we tied one or more risks to each asset to which this asset may be exposed (for example, paper documents can be stolen, destroyed, etc.). Then we estimated the significance of each risk as a product of two parameters: the probability of risk and the significance of the consequences of the risk.

After the risks were divided into groups, we realized which ones we should work with in the first place:

ITKarma picture

1. Employee Knowledge Gaps

The most common risk was the human factor. In addition, we passed certification for the first time, so we had a question of learning the basics of information security. Having already developed the program, we were faced with the problem of automating this process and controlling the residual knowledge. As a result, we began to use a testing system that was built into our corporate portal.

2. Lack of redundant computing power

This problem required large financial and human resources, so leaving it at the end was wrong. We selected a site for backing up our main services: at the initial stage, we used IaaS (infrastructure as a service), which allowed us to quickly and costly set up a reserve of the company's main services; In the future, we purchased additional equipment and set up a reserve in a separate data center (co-location). Subsequently, we abandoned the “cloud” solution in favor of the data center due to the large amount of data.

3.Control of “super-users”, as well as those who work with “special, sensitive” information

In other words, we needed to establish control over users who have extensive access to confidential information. We solved this problem using the DLP system. We chose domestic StaffCop software due to an affordable price and good technical support.

Writing Policies

Here we have connected all possible resources:
- used the policies of other companies that were found in the public domain;
- requested sample policies from our implementation consultant;
- they compiled texts of policies on their own, based on the requirements of the standard.
As a result, it was the third (the most difficult way) that worked best. It was quite a long time, but on the way out we got well-written documents - just for our company. So at the output we got 36 main policies of the Information Security Management System .

Role allocation

Obviously, not all of these policies were really necessary for our employees in their daily work. In order not to force them to read too much, we did the following: assigned each employee one or more roles in the ISMS. There were 5 in total:

ITKarma picture

Absolutely all employees had at least one role - the "user".

In the passport of each role, we prescribed the corresponding responsibilities in the field of information security with an appendix of the list of policies that an employee with a particular role had to comply with. Also for convenience, we made a graphical organizational structure of the company indicating the roles of each employee on it.

Engaging colleagues

In addition to the project manager and the Head of the IT/IS department, the company's operations director was involved in risk assessment and description of stakeholder requirements. Significant involvement was also required of the HR Department Head - she needed to describe the full life cycle of the employee in the policy: from the application for the vacancy to the period after his dismissal. Fortunately, all colleagues understood the importance of certification and came to meet us.

Technical aspects

In the preparation process, we realized that in order to fulfill the requirements of the standard, we need at least the following:
  • Move the server to an external data center;
  • Equip all ACS offices (access control and management system).
In the future, many other things were added to these two points: the introduction of a DLP system, the launch of a backup data center, the introduction of two-factor authorization, etc.

Thus, to adapt the requirements of the standard to our company, we had to do a fairly significant amount of work.

In previous posts:

5 stages of inevitability of adoption of ISO/IEC 27001 certification. Denial : misconceptions about certification of ISO 27001: 2013, the desirability of obtaining a certificate/
5 stages of inevitability of adoption of ISO/IEC 27001 certification. Anger : Where to start? Initial data. Expenses. The choice of provider.