The goal of ISMS tool selection is to find the software that best fits your organization and situation. An important prerequisite for this is that you, as the person responsible for the selection process, have determined and understood the general conditions and requirements of your own organization. With the following list you can gather the requirements from the contact persons in your organization in a structured way.
The results are used for important considerations and form the basis for the criteria catalogs with which the vendors are later compared.
1 ISMS software
1.1 Functional requirements
Which standards should the software be able to map?
e.g. ISO 27001, TISAX etc.
1.2 Specifics of the organization
What specifics exist in your organization that need to be considered or could become difficult to address in an ISMS tool.
Are there special organizational structures that need to be mapped?
Are there sub-organizations whose data must be kept separately?
Are there special processes and procedures?
To what extent must the data of these sub-organizations be separated?
Is the separation via a flag in the database sufficient or do they have to be kept in separate databases? (e.g. according to regulatory requirements or for security reasons)
Are there cases in which sub-organizations with actually separate data sets should be able to see their data mutually?
For example, in the case of overlapping projects or jointly operated systems.
Are companies from countries with fundamentally different legal systems to be included, whose data must be strictly separated? (e.g. China)
1.3.1 Number of users
The number of users is often relevant for calculating the license of the tools and for dimensioning the infrastructure.
How many users should be generally able to work with the system? (named user)
Some license and usage models are based on "named users", i.e. the amount of the license or usage fee to be paid is calculated, among other things, from the number of users who are basically approved for use.
Can users be grouped by intensity of use?
These could be, for example: power users who use the system consistently and perform many work steps every day. In contrast to occasional users, who only have to work with the system occasionally and then only have to complete a few work steps.
These figures are useful for estimating the maximum number of users working with the system simultaneously. Example: 5 power users who work with the system daily and continuously; 30 occasional users who log in about once a week for about 20 minutes. The system or license does not then have to be designed for 35 concurrent users, but can be based on a lower value, since probably never all 30 occasional users want to use the system at the same time.
How many users should be able to work with the system simultaneously? (concurrent user)
Some license and usage models are based on "concurrent user", i.e. the amount of the license or usage fee to be paid is calculated, among other things, from the number of users who can work with the system simultaneously.
Furthermore, the infrastructure must be designed accordingly: The more users are on the system at the same time, the more powerful the server, database, etc. have to be designed to ensure good response times.
It should be noted that there can be different situations. Besides normal operation, peaks may have to be expected, e.g. before upcoming audits.
Different usage intensities should be included in the estimation. In the example above, the following could be calculated: 5 power users + 3 occasional users = 8 users who can work with the system simultaneously.
How are these figures likely to change in the coming years?
Could these figures change due to upcoming organizational restructuring?
The estimated amount of data helps to calculate the necessary storage capacity.
What data volumes can be expected for the master data?
e.g. number of organizational units
What data volumes can be expected for the operational data?
e.g. number of assets
How much data is regularly added? (e.g. monthly or annually)
What quantities can be expected in the future due to organizational changes? (e.g. through acquisition of other companies)
1.4.1 Business data interfaces
From which other systems should the ISMS application obtain technical data?
Many organizations have a configuration management database (CMDB) in which IT assets are stored. In certain cases, it can make sense to connect this to avoid having to maintain the assets twice. However, synchronization between two different systems can quickly grow into a complex problem, so efforts and benefits should be well weighed.
Interfaces could also be useful to systems that provide compliance status.
To which other systems should the ISMS application transfer business data?
1.4.2 Technical interfaces
Should there be a connection to a user administration (LDAP, Active Directory)?
Should there be a technical connection for user authentication?
Examples are Single Sign-On (SSO) or authentication against LDAP
With an SSO solution, a user logs on to his workstation computer only once. When accessing the ISMS application, he does not have to log in again, but is logged in automatically. Technical solutions include SAML or Kerberos.
Should a monitoring system be connected to track the system status?
Which mail systems should be connected?
The systems send out mails to notify users about upcoming tasks and appointments
2 General requirements
2.1 Legal and regulatory framework
Which special legal regulations are subject to the company or organization that are generally relevant when introducing an ISMS or software? Which requirements result from this?
- EU GDPR with special category data
Is the software subject to co-determination by the work council?
2.2 Requirements of IT operations
Which is preferred: on-premises installation or cloud?
2.2.1 On-premises / installation in your own data center:
Which IT platforms are available in the own data center or on the clients and have to be supported by the ISMS software? (databases, server, browser, etc.)
What are other delivery obligations for internal operations? (e.g. operating manual)
2.2.2 Cloud / Software-as-a-Service (SaaS)
What requirements must a cloud provider meet?
e.g. certification according to ISO 27001
2.3 Data security and information protection
What data security requirements must be met so that critical information cannot be leaked to external parties such as competitors, actors from other countries, criminals, etc.
May the often sensitive data on an ISMS (e.g. details of the IT infrastructure, protective measures) be with an external provider?
Are there exclusion criteria, e.g. no providers from the USA or which are subject to the Patriot Act?
2.4 Data protection
Which requirements for the protection of personal data must be met?
Processing of data subject rights according to EU GDPR? (Information, export, deletion/anonymization, restriction of processing)
Deletion of data after expiration of retention periods or discontinuation of the purpose of processing?
Under what conditions may personal data of the company or organization be processed in cloud systems of an external provider?
2.5 Failover and recovery
How should the availability of the system be?
What availability of the ISMS tool should your own data center or SaaS provider ensure?
Recovery Time Objective (RTO): How long can the ISMS system be down in case of an emergency?
Recovery Point Objective (RPO): How much data loss can be accepted in an emergency?
Accessibility enables people with disabilities to use the system.
What are the accessibility requirements for software within your organization?
3 Further considerations
Are there other divisions in the company or organization that could already be using such software?
- Can an existing instance be shared?
- Exchange of experience?
For which divisions would the use of such software also be interesting?
What changes in the organization can be expected in the future? For example, acquisitions/M&A, mergers with other organizations, spin-offs.
Continue reading ...