Wie eine GRC-Lösung das Risikomanagement optimiert

Bevor das Unternehmen eine GRC-Lösung implementiert, ist zur Vorbereitung jedoch ein gründlicher Readiness-Check erforderlich:

• Gibt eines holistische Methodik für das Unternehmen und ist diese technisch abbildbar?
  Sechs-dimensionale Bewertungsdiagramme mögen gut klingen, steigern aber nicht unbedingt die Transparenz. Häufig werden Methodiken entwickelt, die sich technisch nicht oder nur mit sehr hohem und kostspieligem Aufwand abbilden lassen. Denken Sie schon bei der Erstellung Ihrer Methodik daran, dass diese auch technisch realisierbar sein sollte. Weniger ist möglicherweise mehr.

• Sind die Anforderungen an die Software vollständig bzw. werden alle relevanten Interessensgruppen involviert? Beispielsweise kann der Fall eintreten, dass eine Abteilung spezifische Anforderungen hat, die bei der Anforderungsaufnahme nicht berücksichtigt wurden. Dann wird diese die neue Lösung vermutlich gar nicht nutzen. Umso wichtiger ist es, im Vorfeld systematisch sämtliche relevanten Anforderungen zu erfassen. Je genauer die Anforderungen im Lastenheft beschrieben und dokumentiert sind, desto besser kann die richtige Lösung identifiziert und deren technische Abbildung im Pflichtenheft beschrieben werden. Schließlich erfolgen auch das Testing und die Abnahme auf Basis der Informationen aus diesen Dokumenten – idealerweise durch ein Gremium der beteiligten Stakeholder.

• Ist meine GRC-Applikation revisionssicher?
  Fragen Sie Ihre Softwarelieferanten nach einem Softwarebescheinigung auf Basis des Prüfungsstandards 880 des Instituts der Wirtschaftsprüfer (IDW). Hierbei wird die Software auf ihre Fähigkeit geprüft, ordnungsgemäß im Unternehmen einsetzbar zu sein. Darüberhinaus bietet der IDW-Prüfungsstandard 850 "Projektbegleitende Prüfung bei Einsatz von Informationstechnologie" einen guten Ansatzpunkt, um die Revisionssicherheit bezogen auf die Implementierung und den Betrieb der Lösung im Unternehmen zu gewährleisten. Denn häufig investieren Unternehmen viel Aufwand in eine neue Lösung, vernachlässigen dabei aber klassische IT Kontrollen wie das Zugangs- und Berechtigungsmanagement, Veränderungsmanagement, Archivierung und Datensicherheit auf technischer Ebene oder berücksichtigen diese gar nur sehr unzureichend. Welche Informationen werden benötigt, um ein effektives und effizientes GRC-System zu betreiben?

  Prozesse enden nicht am IT-System. Vielmehr muss beispielsweise die Berichterstattung an den Aufsichtsrat berücksichtigt werden, so der Tenor des BilMoG. Häufig wird dies bei der Softwareauswahl und -einführung als selbstverständlich betrachtet. Doch welche Daten und in welcher Form sollen an den Aufsichtsrat berichtet werden? Welche Informationen interessieren den Aufsichtsrat überhaupt?

  Gleiches gilt für die grundsätzliche Berichterstattung, denn dieses Thema wird häufig auch bei der Definition der RM-Methodik vernachlässigt. Zu klären ist hierbei, welche KPIs relevant sind und welche Key-Risk-Indikatoren von Bedeutung sind, um ein frühzeitiges und aktives Management von Risiken ermöglichen.

• Können die Bestandsdaten migriert werden?
  Häufig sind in den Unternehmen bereits RMS- und/oder IKS-Lösungen (internes Kontrollsystem) im Einsatz, die allerdings voneinander losgelöst und nicht konform zur neuen Methodik genutzt werden. Dennoch wäre es wünschenswert, idealerweise auch diese Daten in der neuen GRC-Lösung zu berücksichtigen.

• Wie kann ich mich heute bereits auf die Herausforderungen von morgen vorbereiten?
  Prüfen Sie, ob eine potenzielle IT-Lösung nicht nur perfekt auf Ihre aktuellen Anforderungen abgestimmt werden kann, sondern behalten Sie auch die mittel- und langfristige Entwicklung im Auge. Hierfür bietet sich an, bereits im Rahmen der Anforderungen eine Roadmap für den Release-Lifecycle zu entwickeln.

  Auch hier gilt: Weniger ist mehr. Doch überlegen Sie auch, wie viel Veränderung sie ihren Anwendern zumuten möchten oder können. Schließlich ist Veränderung in der Regel eher ein Auslöser für sinkende Akzeptanz und nur in sehr seltenen Fällen ein Erfolgsfaktor für software-bezogene Projekte.

  Schlussendlich sollte nicht mit der Überarbeitung der Methodik eine neue Software erforderlich sein. Zum einen können Entwickler bei einigen Applikationen durch Open Source oder klassische API-Funktionen weiterprogrammieren bzw. Anpassungen vornehmen. Zum anderen kann man sich eines flexiblen Datenkonzepts bei statischem Programmcode bedienen. Der Vorteil: Wer customizen kann, muss nicht programmieren.