In order to ensure an adequate level of information security in the company, measures must be implemented. In data protection, these are often referred to as technical and organizational measures, or TOMs. In the context of information security, we usually talk about “protective measures”.
In this article you will find out which types of TOMs (or protective measures) you should consider for your company. No matter if due to data protection (GDPR), IT security or global information security management requirements, TOMs are always a significant component.
In the following article, the terms TOMs, technical and organizational measures or protective measures are therefore used as synonyms.
In a nutshell: Technical and organizational measures / protective measures of information security
- Requirements for protective measures result from your own requirements, laws, customer requirements or norms and standards.
- Even without mandatory requirements you should implement measures.
- In this article, you will find selected important measures for protecting your information security.
Who needs TOMs anyway and why?
TOMs for ensuring data protection in accordance with GDPR and BDSG (Federal Data Protection Act)
Very often, the requirement for the implementation of TOMs is related to the GDPR. Article 32 GPDR (Link zeigt auf unsere Gesetzesseite) requires “security of processing”. Also in the order processing contract or the standard contractual clauses a separate annex for TOMs is expected. However, it is not correct to found the technical and organizational measures only on data protection.
Protective measures in the ISMS (Information Security Management System)
The technical and organizational measures are also described in managed information security within the framework of an ISMS. Those who have been following our blog for a while know that we are pushing the ISMS according to ISO 27001 or VDA ISA / TISAX®. Here, for example, we find the normative Annex A in the standard, which solely addresses the topic of protective measures. But even the BSI’s IT baseline protection or the ISIS12 approach would not get by without well-implemented protective measures. In addition, the demanding requirements of the automotive standard TISAX® are based on TOMs which are oriented towards the ISMS. In the context of ISMS, the term “technical and organizational measures” is rarely used; instead, you find the term “protective measures”.
Information security safeguards for a secure enterprise
Even if you are not a processor and have not implemented an ISMS, you must ensure that your most important assets in the company are properly protected. You ensure this by implementing (IT)technical and physical measures. But also organizational requirements for employees help to maintain the security level in the company.
Ultimately, this means that it should be in your own best interest to have well-functioning technical and organizational measures implemented in the company. This minimizes the risks of damage to the company information. (dass Ihren Informationen im Unternehmen Schaden zugefügt wird).
What level of protection measures does your company need to implement?
The good answer (from my point of view): There is no predetermined level. You as the person responsible in the company decide on how “secure” your company needs to be. However, I have to say right away that “standard measures” such as password protection should not be discussed. These and other basic topics must be self-evident.
In some companies, single concrete measures have to be enforced technically. For others, an organizational regulation might be sufficient. This decision is completely up to your company and is based on the risks as well as any special requirements which you identify for yourself.
How do you identify YOUR individual security level?
The level of security which must be ensured through technical and organizational measures depends on the criticality of your assets. This means that the first thing you have to do is identify and evaluate your information, data and other important values (so-called assets). I will go into the details of how to to this in a separate blog post. In any case, the assessment should be made with regard to confidentiality / integrity and availability.
Sometimes, the customer takes over the identification of the security level for you. If you work in the medical manufacturing sector or as an automotive supplier, you are by definition in contact with data that needs to be highly or extremely protected. Especially in the automotive sector, your client probably requires a TISAX® label. This automatically means a very high level (XXXX?).
The annoying process of identifying critical values
Practice shows that many companies skip this step and start implementation right away with the (mostly) technical measures. The result? Shooting at sparrows with a cannon. If, for example, the information (and general company values) were evaluated in advance, it might turn out that only a small part of the data is highly confidential and needs special protection (e.g., additional encryption during storage and transmission). In practice, due to the lack of assessment, the protective measure of encryption is applied to far too much data, which involves increasing efforts – and thus dissatisfied employees – as well as cost. This could have been avoided if the values had been identified and assessed in advance.
What are the risks associated with the values?
You have identified critical information and values? Now you can get started and implement information security measures which protect your assets.
Where are still protective measures missing? Where might it be necessary to simply adjust some screws? Maybe things are mostly in place for right now?
The best way to answer these questions is by applying a risk analysis. If it turns out that individual values are not sufficiently protected with the current measures, you should think about additional technical and organizational measures.
An overview of technical and organizational measures
You are probably asking yourself: what exactly do we understand by technical and organizational measures or protective measures of information security / IT security?
Ultimately, it is simply an overview of all the measures a company takes in order to protect corporate assets (including information). In practice, it is usually a mix of
- IT technical protection measures (what is commonly referred to by the term IT security)
- measures for securing the environment (physical measures)
- organizational measures (regulations or binding specifications for the behavior of employees)
Requirements for documenting technical and organizational specifications
There is actually no binding rules for the way in which TOMs are documented. The GDPR requires the implementation of TOMs in Article 32 and concrete measures at the processor in Article 28.
ISO 27001 wants an opinion on all items in Annex A (safeguards) of the standard as to how the requirements have been implemented – and if not, why not. Annex A is divided into various categories.
VDA ISA / TISAX® wants to see a crucial part of the ISO 27001 protection measures – and much more. The documentation required for the audit is more or less a kind of detailed questionnaire. It is similar to the PCI DSS requirements in the credit card sector.
No matter which approach to documentation you choose: the result should be an overview of safeguards your organization is implementing in order to protect the information and assets.
Examples for technical und organizational measures
Below, you find a list of important technical and organizational protective measures – divided into different headings. Please note: The list can never be complete and does not claim to be so. The objectives and measures mentioned can be found (in different bullet points) in each of the requirement catalogs (27001, BSI IT-Grundschutz, VDA ISA / TISAX®, PCI DSS, DSGVO…).
It is up to you whether all of the following goals are applicable to you or whether you may need to implement specific additional measures. As already mentioned above: You decide what level of security you want to implement in your company.
Measures for dealing with employees
| Goal | Measures |
|---|---|
| Select trustworthy staff | Depending on the position being filled, a screening or police clearance may be required. |
| Confidential treatment of information | Non-disclosure agreement |
| Comply with the company´s safety level | Information security policy with organizational rules |
| Employee awareness | Raise awareness of employees through regular training or other measures |
| Confidential handling of personal information | Obligation of data secrecy (protection of personal data) |
Minimum standards for information security (processes, rules, specifications)
| Goal | Measures |
|---|---|
| Know the company´s critical values | No need to launch a huge data classification project, but it should be clear in every company what the most valuable assets are which need protection. |
| Handle information security incidents | Employees know what is considered an information security incident and, more importantly, how to respond to one. |
| Change management process | Even though change management originates from the ITIL family and primarily regulates a part of the IT service processes, it is also an elementary component for optimized processes in information security. |
| Disposal / deletion of media | Media and supplies are safely deleted or physically destroyed before disposal or reuse. |
Suppliers and contracts
| Goal | Measures |
|---|---|
| Non-disclosure agreements | A non-disclosure agreement is concluded with new suppliers / service providers if inspection / access to confidential information cannot be ruled out (if necessary, also already in the tendering phase). |
| Guideline for external parties | If external parties gain access to the company’s internal network or IT services, regulations and usage specifications must be defined and passed on. |
Physical safety measures
| Goal | Measures |
|---|---|
| Safety zones | Divide the buiding into different security zones. Define the requirements for the different classes of security zones. |
| Measurements in safety zones | Depending on the safety zone and risk, appropriate measures must be implemented (e.g. fire protection, windows, other environmental sensors…). |
| Access concept | Authorization assignment including release procedure has been clarified and implemented. |
| Visitor management | Specifications regarding handling of visitors, especially in security areas, are regulated and implemented. |
| Equipment and supply protection | Placement of operating equipment in the server room or internal areas must not pose any risks due to external influences. Also consider protection of the cabling. |
| Redundant supply | Where necessary or identified as a risk, redundant supply must be implemented (e.g. power, internet, telephone…). |
| Maintenance | Regular maintenance of equipment |
IT technical protection measures
| Goal | Mesures |
|---|---|
| Backup | Backup concept incl. recovery concept is defined and implemented |
| Antivirus | Definition and implementation |
| Mobile Security | Security concept is defined and implemented (incl. encryption, access protection…) |
| User management | – Personalized identifiers – Secure transmission of initial login data – Rules for privileged accounts (e.g. admins) – Passwort policy defined and implemented – Process for requesting and changing rights incl. approvals is defined and adhered to |
| Authorization concept | Assignment of rights via roles and groups, need to know principle |
| 2 factor authentication | Where possible and appropriate, 2-factor authentication should be implemented. Particularly important for the external services |
| Development | Specifications for the development of new systems and software development with regard to information security requirements are defined and implemented. |
| Log concept | Simple log concept is defined, implemented and checked regularly. |
| Monitoring | Definition of the most important checks which need to be monitored. |
| Patch management | Security updates are implemented in a timely manner. In general, there is a concept for general patch management. |
| Software Installation | It is regulated which software may be installed and how the installation is carried out. New requirements must be checked. |
| Network security | Separation of networks (internal and to external) to necessary ports and services, if necessary even further restrictions. Authentication of IT systems in the network and regulation of access to the management interfaces of IT systems. Redundancies for critical network components are implemented. |
| IT Services | Requirements for IT services are defined and implemented (mainly for cloud systems, but also for internal services). |
Summary of recommendations
As already mentioned at the beginning, these are some recommendations that we consider important. Standards such as ISO 27001 or the VDA ISA catalog go into much more depth. These would be far too extensive for a start.
From our experience, the above-mentioned points can be used to open up the most important topics in the area of information security in principle and to successively further optimize them.
If you need support, we are happy to help. Just get in touch with us! We look forward to hearing from you.
Note concerning the attachment TOMs in the order processor contract
We regularly review order processor contracts whose TOMs annex are extremely detailed. For example, it describes exactly what the company’s password policy looks like. Or it shows which authorization groups exist in the company.
For two reasons, we advise against this and recommend a more general presentation:
- Formulate the measures in such a way that a minor change in the configuration at your company does not lead to a change in the attachment. For example, formulate in the attachment: Password policy available — do not specify concrete settings, e.g. 12 characters, upper and lower case…
- The specific implementation of the measure is nobody’s business in the AV appendix (to put it bluntly). Your customer needs to know that you implement certain measures (for example, that you use permissions and have a password policy). But he doesn’t need to know how exactly you implement this measure. I would even classify it as a risk to state the exact implementation of your protection measures. By doing so, you provide a potential attack surface that is not necessary.