
Internal Control System in Software Asset Management
In January, we visited Continental AG in Hanover with the Special Interest Group (SIG) SAM & Licensing of VOICE - Bundesverband der IT-Anwender e.V. (Federal Association of IT Users). One of the main topics was the integration of an internal control system (ICS) into software asset management. This blog post summarizes the key findings of the discussion.
What is an ICS and why do you need one?
An internal control system (ICS) is an essential component of corporate governance and risk management. It comprises rules, procedures and measures introduced by an organization with the aim of making business processes efficient and reliable, minimizing risks, protecting assets, ensuring the reliability of financial reporting and ensuring compliance with laws and regulations.
An internal control system comprises 3 lines:

1st line (operations): This line is responsible for carrying out the processes with which the risks are associated. Risks are identified, assessed and managed at this level. The risk owners, who initiate suitable risk mitigation measures, are also located here.
2nd line (Risk Management & Compliance): This line defines the guidelines, standards and procedures, carries out risk assessments and reviews the risk management activities of the first level.
3rd line (internal audit): The third line acts as an independent control body that evaluates the effectiveness of the risk management processes. It generally reports directly to top management / the Executive Board.
Status quo: ICS in SAM
An internal control system is widespread in many companies, particularly in the financial sector and in relation to regulatory requirements. In the area of IT, the focus is often on information security in order to adequately counter risks from external attacks or to meet IT security certification requirements.
Guidelines, standards and procedures are often defined in software asset management, but are sometimes not implemented company-wide. There are also rarely defined checkpoints for software asset management by means of which compliance with the rules and regulations is regularly monitored. There is also a lack of stringent documentation of risks in the software asset management context, particularly in organizations with a low level of maturity.
Blockers and obstacles
In practice, a major blocker that can often be observed is that the necessary backing for a comprehensive SAM is not fully available from management. As much as necessary is spent on countering possible risks in connection with software license agreements. However, this ignores the fact that corresponding measures can also lead to an increase in efficiency in the processes, which in turn leads to a reduction in usage or expenditure. Another blocker is the often scarce resources in SAM or neighboring departments that are needed to set up an ICS. This is exacerbated by staff turnover, which leads to frequent changes of contact persons who need to be won over to the project. Decentrally organized companies in particular also lack access.
Triggers for an ICS
The introduction of an ICS can be promoted by specific compliance incidents in the company that lead to increased awareness. Furthermore, an ICS requires a certain level of maturity in the SAM organization. Guidelines, standards and procedures must first be defined, adopted and rolled out in the company before a meaningful control system can be set up on this basis. The introduction of an ICS is facilitated if the company has economic and organizational stability, so that the project is based on a stable foundation.
(Solution) approaches
As possible solutions (not only for the introduction of an ICS in SAM, but also for the introduction of SAM general), the added value of SAM and possible risks if it is not implemented consistently should be worked out and presented. On this basis, the mandate for the introduction of an ICS for SAM can be obtained from management. If there is a lack of awareness of the risks identified, consideration could also be given to using the internal audit function to have any risks reconfirmed by a third party. It can also be helpful not to focus exclusively on SAM, but to find common points of contact with IT security or business continuity management, for example, or to expand existing ICS mechanisms to include SAM. Good networking with other departments/divisions and a presence in their committees/bodies helps here.

Summary
Unfortunately, as is so often the case, there is no one single path that is guaranteed to lead to success. Instead, the individual starting situation, circumstances and objectives in the company must be taken into account in order to achieve the desired goal. However, some key success factors can be summarized:
Highlight the SAM value for the planned project
Look for allies in your own company
Use possible (temporal) momentum in the company
Proceed step by step with the implementation
Learning from each other, e.g. by exchanging ideas with like-minded people in the SIG SAM & Licensing
Author: Felix Baran