Ill-considered technical task leads to other troubles as well. The contractor at the stage of project implementation may face difficulties that were not known in advance. This can interfere with the fulfillment of the contract.

How to properly prepare the terms of reference for the information security tender

When preparing the terms of reference for the tender, it is advisable to be guided by the requirements of the standard GOST 34.602-89 “Information technology. Set of standards for automated systems. Terms of reference for the creation automated system". The document will help to build a clear structure of the terms of reference, determine the sections that will be filled with the necessary requirements.

Consider what you need to pay attention to when filling out the document.

Terms of reference for the tender, sample (approximate structure)

General information

The terms of reference traditionally begins with this section. In it, the customer specifies the name of the system. Provides information about yourself - full and abbreviated name, location address. If the legal and physical address are different, both should be indicated in order to avoid misinterpretation by the contractor.

The basis for the work. Objectives of the system

In this section, you need to indicate the basis for the work, the provision of services and the purpose of creating the system.

Often the basis for creating a system is the requirements of the legislation. In this case, it is necessary to list the normative documents in accordance with which the system should be created. For example, the requirements of 152-FZ "On personal data".

In the subsection "Objectives of the system creation" the customer gives the characteristics and indicators that must be achieved as a result of the system creation. For example, "Protection of personal data transmitted over open communication channels."

The customer should carefully consider filling out this section, since it is he who will allow the contractor to understand what the customer's expectations are from the system being created and in accordance with which documents the system is being created.

General characteristics of information systems

This section is dedicated to describing the existing infrastructure of the customer. It is best to complete this section in as much detail as possible.

Information about existing objects of informatization is indicated here: the exact number of workstations, servers, addresses and their locations, operating systems used, the availability of connections to information and telecommunication networks of international exchange, available information security tools, information about the operating conditions of information systems and other information, which should be taken into account when preparing a technical solution.

Detailed and high-quality filling of this section will allow the contractor to form an optimal technical solution.

Information security requirements

This section specifies the requirements for the protection system, which it must comply with. The section can be conditionally divided into two subsections - General requirements to the system and requirements for the functions performed by the system.

General system requirements

In the subsection "General system requirements" indicate:

• Requirements for the structure and composition of subsystems. For example, "Identification and Authentication Subsystem", "Access Control Subsystem", etc.
• Requirements for the reliability of the system being created. For example, "The protection system must be able to recover and perform its functions after failure (failure) of software and hardware."
• Safety requirements, i.e. requirements for ensuring safety during installation, operation, maintenance and repair of technical means of the protection system. For example, “The hardware components of the protection system must have protective earth, grounding ".
• Operating requirements, maintenance... For example, "The protection system must operate around the clock, in a continuous mode."

Requirements for the functions performed by the system

For each of the subsystems described earlier, a list of functions and tasks that must be implemented by the information security system is established. For example, for the access control subsystem, a requirement is established to limit unsuccessful attempts to enter the information system.

When completing this section, you can focus on the requirements of guidelines in the field of information security. Current normative base, for example, in terms of personal data protection, allows you to correctly formulate requirements for information security subsystems.

Separate subsections in the “Requirements for the functions performed by the system” are advised to highlight “Requirements for software” and “Requirements for hardware”.

Software requirements

In this subsection to the software of the protection system, you should specify:

• requirements for compatibility with operating platforms and hardware used by the customer;
• requirements for the functionality of the described software;
• requirements for protective mechanisms that the program must implement;
• certification requirements, if a certified solution is required by regulatory documents.

Requirements for technical means

The subsection indicates:

• requirements for the hardware platform in which the technical device must be executed;
• requirement for operating system;
• requirements for the functional characteristics of the technical means;
• physical requirements (size, body);
• requirements for operating conditions ( working temperature, humidity, etc.);
• certification requirements.

Composition and content of works

This section should contain a list of stages and stages of work on the creation of the system. The deadlines for their implementation must be indicated for effective control of the work. The customer can form a requirement according to the list of documents presented at the end of the corresponding stages and stages of work.

System control and acceptance procedure

In this section, the customer describes the general requirements for the acceptance of works. It is possible to envisage the procedure for coordination and approval of reporting documentation for each stage and stage of work, or as a whole for the entire range of works.

For example, an act on the performance of work for each stage, signed by the responsible persons of the customer, is required. Upon completion of the work and signing of the certificate of completion, separate acts for each stage will be taken into account.

Requirements for the performer

One of the final sections - "Requirements for the performer".

This section specifies what licenses the performer should have. The requirements for the number and qualifications of the contractor's specialists for the performance of work are indicated. It is important to understand that the requirements for the contractor must be substantiated and reasoned, otherwise a complaint may be filed against the customer's requirements.

Warranty support requirements

At this stage, the customer's warranty claims are specified. In the requirements for warranty support, you can specify the type of support required - by phone, mail, an online consultant on the contractor's website. You can specify the requirements for handling incident requests - incident handling hours, customer service level, response time, etc.

Documentation requirements

The customer specifies the requirements for the list of sets and types of documents to be developed by the contractor, requirements for the provision of documents.

For example, documents must be submitted in hard copy on paper and in electronic form, recorded on CD-Rom, DVD-Rom media.

What mistakes are most often encountered in the preparation of technical specifications

The customer does not know on the basis of which document to prepare the terms of reference.

As a basis, you can take GOST 34.602-89 “Information technology. Set of standards for automated systems. Terms of reference for the creation of an automated system ”and fill the document with the necessary material.

In different places of the same technical task there are contradictions.

Before publishing the technical task, it should be carefully checked. The customer should understand that if the technical task is not well developed, he risks getting a low-quality service, work, goods.

The tight deadlines for the implementation of the technical task.

Terms of reference are often found in which very tight deadlines for the execution of work are spelled out. The customer is guided by his own motives, but runs the risk of receiving low-quality services, works, goods.

We recommend that customers, when preparing the technical assignment, pay more attention to the section "Composition and content of works". At this point, you can detail the work and break them down into separate stages, analyze the timing of each stage. This will allow you to get a more objective picture of the timing of the entire TK.

The terms of reference spell out the requirements for non-existent products.

There are technical assignments in which the customer conducted a thorough analysis of the existing products on the market, selected the characteristics of each of the products that seemed attractive to him, and brought the requirements into one technical assignment. It may happen that there is no product on the market that meets all the requirements.

To avoid this situation, we recommend that when drawing up a technical specification, highlight the most significant characteristics that a number of products have. After the preparation of the technical task, the stated requirements for technical specifications for compliance with real products on the market.

When preparing the TOR for works / services, there are often options when a clear list of works / services is not fixed, the results of the work are not determined / services.

In such cases, conflicts between the customer and the contractor are likely, since the services or work provided by the contractor will not meet the customer's expectations. To prevent this from happening, the customer, when preparing the technical specification, needs to pay more attention to the sections “Basis for work. The goals of creating the system ”and“ Composition and content of work ”. Practice shows that it is better to break the work into separate stages. Describe the requirements for each of the stages, fix the deadlines and results of work for each of the stages. These actions will improve control over the performance of work or the provision of services.

Output

A competently drawn up technical task will be useful at the same time to both the contractor and the customer. It will allow the contractor to adequately assess the scale of work without additional inquiries and explanations, as well as offer the most suitable technical solution for the customer. The customer - will allow you to get a high-quality work to create a protection system that best meets his expectations.

Stanislav Shilyaev, Project Manager for Information Security at SKB Kontur

General provisions of the technical task

If you have a technically complex project (or a very specific one), then be sure to general provisions it should be glossary of terms and definitions ... It might be worth explaining some of your phrases in the glossary. To avoid confusion, immediately put everything in its place.

Objectives of the project

Be sure to specify in the terms of reference what goals your project has, why it is being created, how it will work, what should be the final result. Even if the performer is working on a small part of the project, then he must fully understand its structure, tasks, goals, technical solutions.

Functional requirements

All customer requirements can be divided into two types: functional and special.

Functional requirement- these are the versions that you want to see in yourself.

Special requirement- these are the requirements with the help of which the assigned tasks must be fulfilled. If there are no such requirements, then let the contractor decide on his own what and how he will use when completing your technical task.

Timing

The terms of reference must be specified in the terms of reference. In any case, there should be a clear deadline, and the sanctions for the failure of the indicated deadlines are described. The contractor must understand that this is not just a point of the technical task, but a real installation, not fulfilling which, he risks incurring financial or other sanctions.

Reporting

If the project is large and it takes several months to complete, then divide the work into stages, and set clear time frames for each. After completing a stage, demand reporting on the work performed. There should also be a report on the fact of the work performed.

A responsibility

If you are drawing up a contract, then a liability clause will be in it. If you only limit yourself to a technical assignment, then it is worth describing there what kind of failure to meet the deadline, not the delivery of the project, disclosure of the nuances of the work to third parties, the performer is responsible in accordance with the law, but you can also set your own fines and sanctions.

Sore about the template of the terms of reference for tenders

In my work, I often come across a request to send a template of terms of reference for the creation / implementation / purchase of software in order to include it in the tender documentation. Each time I ask myself what should include such a template, should it be one or several, and is such a template necessary?

For myself, I found the answers, but other opinions have a place to be. Therefore, I will give my logic of reasoning and with great pleasure I will listen to the reasoning of my colleagues.

Technical task(TOR) is the main part of the tender documentation, the purpose of which is to help the initiator of the procurement (buyer) to make an unambiguous choice of product / service / work with ensuring the best conditions for the execution of the contract. Providing the template of the TK, the supplier expects that its TK will satisfy the buyer and will be taken as a basis. And, of course, the supplier's product fully complies with such TK, which is a plus.

It should be understood that during the evaluation of bids for a tender, the procurement initiator does not have the opportunity to check the reliability of all the data and understand how much his requirements are covered by the proposal of the next participant. And after signing the contract, it is not profitable for the client, and sometimes even difficult from the point of view of justification, to terminate it.

Now let's consider the actions of the procurement participant (supplier). If, as a performer, I am interested in obtaining a contract with a client, then I will prepare a detailed explanatory note- an application for participation in the tender, I will study and comment on all points of the terms of reference. Even if my product today “doesn’t know how to do something,” then I will have time to “teach it”, or after signing the contract, there will be time to understand the client's need and propose an alternative option. Of course, everything is within the framework of the law.

On the other hand, no matter how wonderful the template of the terms of reference is made by the suppliers, and no matter how detailed the technical specification is formed by the buyer, this will not give the expected effect for the supplier: the initiator of the purchase will be forced to conclude a contract with the one who will offer the best conditions for the execution of the contract. The terms of reference does not allow for guaranteed weeding out of “unwanted” participants, which is stipulated by the legislation (the procurement procedure is aimed at the possibility of choosing and determining the winner).

The classic vendor question is: “What to do? Would you fold your arms and hope for luck? " Of course not. The terms of reference should be prepared, but not according to a template, but for each tender its own. And for this I propose to pay attention to the points described below, depending on the method of purchase.

Request for quotes and auction- these are the methods of purchasing at the lowest cost. Therefore, the terms of reference should be capacious:

● include detailed description what will be supplied, configured, installed or modified;

● fix a clear order of work / performance of services, so that any potential tenderer sees the volume and complexity and is afraid to take responsibility when submitting an application for participation in the tender.

The terms of reference should include a description of the result, this is what will allow the initiator at the stage of contract execution to control the receipt of the expected and, if necessary, reasonably terminate the contract.

Contest Is a purchasing method to identify a supplier with better conditions execution of the contract. Everything described above is applicable here, but there is an additional "leverage" that suppliers often forget about. These are the criteria for evaluating applications.

The methodology for evaluating applications is detailed in the Decree of the Government of the Russian Federation of November 28, 2013 No. 1085 "On approval of the Rules for evaluating applications, ..". Highlight the performer's strengths that are important to the client in the winning criteria.