GoCoMM: A Governance and Compliance Maturity Model * Gabriela Gheorghe Fabio Massacci Stephan Neuhaus Università degli Studi di Trento Trento, Italy firstname.lastname@disi.unitn.it Alexander Pretschner Fraunhofer IESE and TU Kaiserslautern Kaiserslautern, Germany firstname.lastname@iese.fraunhofer.de ABSTRACT Advanced methodologies for compliance such as CobiT identify a number of maturity levels that must be reached: first the existence of an infrastructure for the enforcement of security controls; sec- ond, the ability to continuously monitor and audit quantifiable in- dicators for the controls put in place; and third, the ability to react when a policy violation is detected. In this paper, we go further and define a governance and compliance maturity model (GoCoMM) that is process-oriented. As an instance of the highest level of governance and compliance, we suggest a method of goal correla- tion that provides measurable indicators of security and compliance by systematically refining business processes and regulatory goals. We also introduce a run-time architecture to support this model. Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics—Process metrics; K.6.4 [Management of Computing and Information systems]: Sys- tem Management—Quality assurance; K.6.5 [Management of Com- puting and Information systems]: Security and Protection General Terms Design, Documentation, Legal Aspects, Management, Measure- ment, Security, Standardization Keywords Compliance, Assurance Indicators, Security Indicators 1. INTRODUCTION Recent years have seen regulatory bodies focusing on the protec- tion of assets from (willful or sloppy) company mismanagement. The number and the complexity of requirements placed on IT pro- cesses has increased, as witnessed by the Sarbanes-Oxley Act [25], Basel II [3], the EU Directive 2006/24 on data retention, and many * This work has been partly funded by EU under the project FP7- IST-IP-MASTER. We also thank all members of the A2 MASTER activity for fruitful discussions on the conceptual model. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WISG’09, November 13, 2009, Chicago, Illinois, USA. Copyright 2009 ACM 978-1-60558-787-5/09/11 ...$10.00. others. These trends have a profound impact on the trust models, security policies, security procedures, and security infrastructure that companies need to develop and maintain [13, 14]. Indeed, tra- ditional security research has been concerned with the protection of data such as access control in its classical form [21] or in more so- phisticated variants such as history-based [15], usage based [20, 8, 22], workflow-based [26, 6], or purpose-based [1] access control. Yet, all these works are set out in a classical security model where a one-time failure of a security policy means that the security of the system has failed. In real systems, some failures of legally prescribed forms of usage or access control are always present and regulators are aware of it. What a company has to show to prove its compliance is that it is in control of its processes. To this extent some methodologies that were initially used for auditing have been extended to IT [3, 10, 11]. The problem is that, with the exception of ITIL, such methodologies still clearly show their descent from their initial “auditor” origin. They tell perfectly how to check that you already are compliant; but they offer no hints on how to actually become compliant. The same situation is present in the realm of software engineer- ing and Capability Maturity Models [24]. While the objective of each maturity model may change, their hierarchy is pretty much the same: chaos, documentation, (manual) correlation between objec- tives and techniques, automation, measurements, and occasionally change management. Our starting point is a commonly acknowl- edged gap in these maturity models: While the existence of metrics is stipulated for reaching higher maturity levels (e.g., level 4 in the SE-CMM [9]), little is said about how to derive concrete metrics from existing artifacts in one particular context. We contribute to closing this gap with a maturity model and the concrete elements needed to achieve the higher levels of maturity . To this extent we provide: • A maturity model that allows companies to assess how ef- fective their controls are when it comes to automating the verification of regulatory compliance; • a conceptual model that is needed to achieve the first step of linking controls to objectives; • an architecture for a control IT infrastructure that implements the conceptual model and is needed to achieve the maturity level that pertains to automation; • measurable indicators that show to which extent a business process is compliant with applicable regulations (key assur- ance indicators, KAI) and to what extent controls are used to ensure the compliance of business processes (key security indicators, KSI). 33