Use Cases

Mergers & Acquisitions

Your company takes over a competitor and integrates both the product line as well as the staff into the existing company, including the IT systems. This leads to many changes in the data- and role structure and the associated access rights. The existing employees will also experience changes with regard to their roles and responsibilities.

Previously:

The applications require substantial adaptations. This applies to the business logic and even to a greater extent to the defined roles as well as the access- and editing rights. The flexibility is severely limited by time- and budget restrictions. Only those things are feasible which fit into this tight framework. Accordingly, both new and existing employees are frustrated. In addition, the dedicated IT specialists face the uncertainty of whether all security vulnerabilities are known and have been eliminated.

Using DACS:

Most of the changes can be performed by reconfiguring the roles and the applicable set of rules. Time and budget are even sufficient to make the necessary adjustments, also in terms of ease of use. The users – existing and new – are pleasantly surprised by the rapid change and impressed by the performance of the IT-department which, in turn, feels totally at home in the role of active enabler and already has plans with regard to additional functions and even better services for the internal customers.

Testing and Revision

A substantial extension of the application has been developed and shall now undergo the final tests and shall subsequently be transferred to production. Due to the high level of confidentiality of the data contained therein, the demands with regard to security are very high in accordance with internal security policies (determined by the national regulator). The test specifications are correspondingly extensive.

Previously:

The intensive test procedure requires a substantial effort. All new features are extensively tested with regard to their access security. The major challenge is to cover all possible combinations of the program functions, particularly also in conjunction with the rest of the application. Within the given time before the going-live, efforts are made to achieve optimum results without knowing whether all relevant cases have been "caught". The new application goes into production in these circumstances. The auditors accept the report, knowing full well that the further procedure is partially based on the principle of hope.

Using DACS:

The development of the application is based on the separation of business logic and data access control. This principle is also pursued for the testing. The security policy and its implementation in the form of a set of rules are tested separately from the application. This procedure can be automated and thus accelerated to a higher degree than the functional application tests. The access security as the first priority can therefore first be thoroughly tested. The transparency and the levels of compliance are considerably higher for the audit. Hope turns largely into knowledge.

Dynamic Rules based on the "Cross Border" Challenge

Bilateral agreements demand limited and precisely controlled data access to critical customer data (generally those which can uniquely identify the customer) from outside the country of residence. The current location of the "observer" is the decisive factor. The details of the agreements vary from country to country and are subject to periodic change.

Previously:

Few solutions, even solutions which have been specifically designed for customer service such as CRM, are able to offer a fine-granular and, at the same time dynamically configurable, access control.  The requirements are either programmed with a lot of effort and updated with the corresponding delay, or the applications are simply not available to the users due to lack of adaptability for certain user groups, locations and functions.

Using DACS:

Selective and precise anonymization of data – adaptable at any time – is a prime discipline/key skill of the DACS from Inventage. This is also known as "data masking". If reliable site identification can be provided, e.g. by IAM, the changes can be practically updated in real time by means of specific roles and/or dynamic rule allocation, without having to change the application code.