Implementing Governance

To govern, organizations must rely on a variety of mechanisms, which are documented in this competency category.

Elements of a governance structure

Organizations leverage a variety of mechanisms to implement governance. The following draws on COBIT 2019 and other sources (ISACA 2012b, ISACA 2018):

  • Mission, Principles, Policies, and Frameworks

  • Organizational Structures

  • Culture, Ethics, and Behavior

  • People, Skills, and Competencies

  • Processes and Procedures

  • Information

  • Services, Infrastructure, and Applications

COBIT terminology has changed over the years, from “control objectives” (V4 and before) to “enablers” (V5) to the current choice of “components”. This document uses the term “elements”, and retains frameworks as a key governance element (COBIT 2019 dropped).

In Elements Across the Governance Interface, varying lengths of the elements are deliberate. The further upward the bar extends, the more they are direct concerns for governance. All of the elements are discussed elsewhere in the book.

Governance elements
Figure 1. Elements Across the Governance Interface
Table 1. Governance Element Cross-References
Element Covered

Principles, Policies, and Procedures

Principles & policies covered in this Competency Category. Frameworks covered in PMBOK, CMMI, ITIL, COBIT, TOGAF Standard, DMBOK®.


Competency Area 7

Organizational Structures

Competency Area 9 on Org Structure

Culture, Ethics, and Behavior

Competency Area 9 on Culture


Competency Area 11

Services, Infrastructure, and Applications

Context I

People, Skills, and Competencies

Competency Area 9 on Workforce

Here, we are concerned with their aspect as presented to the governance interface. Some notes follow.

Mission, Principles, Policies, and Frameworks

Carefully drafted and standardized policies and procedures save the company countless hours of management time. The consistent use and interpretation of such policies, in an evenhanded and fair manner, reduces management’s concern about legal issues becoming legal problems.
— Michael Griffin
“How To Write a Policy Manual"

Principles are the most general statement of organizational vision and values. Policies will be discussed in detail in the next section. In general, they are binding organization mandates or regulations, sometimes grounded in external laws. Frameworks were defined in Industry Frameworks. We discuss all of these further in this Competency Category.

Some companies may need to institute formal policies quite early. Even a startup may need written policies if it is concerned with regulations such as HIPAA. However, this may be done on an ad hoc basis, perhaps outsourced to a consultant. (A startup cannot afford a dedicated VP of Policy and Compliance.) This topic is covered in detail in this section because, at enterprise scale, ongoing policy management and compliance must be formalized. Recall that formalization is the basis of our emergence model.

Vision Hierarchy

policy hierarchy
Figure 2. Vision/Mission/Policy Hierarchy

Vision/Mission/Policy Hierarchy presents one way to think about policy in the context of our overall governance objective of value recognition.

The organization’s vision and mission should be terse and high level, perhaps something that could fit on a business card. It should express the organization’s reason for being in straightforward terms. Mission is the reason for being; vision is a “picture” of the future, preferably inspirational.

The principles and codes should also be brief. (“Codes” can include codes of ethics or codes of conduct.) For example, Nordstrom Inc.'s is about 8,000 words, perhaps about ten pages.

Policies are more extensive. There are various kinds of policies:

In a non-IT example, a compliance policy might identify the Foreign Corrupt Practices Act and make it clear that bribery of foreign officials is unacceptable. Similarly, a human resources policy might spell out acceptable and unacceptable side jobs (e.g., someone in the banking industry might be forbidden from also being a mortgage broker on their own account).

Policies are often independently maintained documents, perhaps organized along lines similar to:

  • Employment and human resources policies

  • Whistleblower policy (non-retaliation)

  • Records retention

  • Privacy

  • Workplace guidelines

  • Travel and expense

  • Purchasing and vendor relationships

  • Use of enterprise resources

  • Information security

  • Conflicts of interest

  • Regulatory

(This is not a comprehensive list.)

Policies, even though more detailed than codes of ethics/conduct, still should be written fairly broadly. In many organizations, they must be approved by the Board of Directors. They should, therefore, be independent of technology specifics. An information security policy may state that the hardening guidelines must be followed, but the hardening guidelines (stipulating, for example, what services and open ports are allowable on Debian® Linux) are not policy. There may be various levels or classes of policy.

Finally, policies reference standards and processes and other governance elements as appropriate. This is the management level, where documentation is specific and actionable. Guidance here may include:

  • Standards

  • Baselines

  • Guidelines

  • Processes and procedures

These concepts may vary according to organization, and can become quite detailed. Greater detail is achieved in hardening guidelines. A behavioral baseline might be “Guests are expected to sign in and be accompanied when on the data center floor.” We will discuss technical baselines further in the Competency Category on security, and also in our discussion of the technology product lifecycle in Architecture and Portfolio. See also Shon Harris' excellent CISSP Exam Guide [Harris 2013] for much more detail on these topics.

The ideal end state is a policy that is completely traceable to various automation characteristics, such as approved “Infrastructure as Code” settings applied automatically by configuration management software (as discussed in The DevOps Audit Toolkit [DeLuccia et al. 2015] – more on this to come). However, there will always be organizational concerns that cannot be fully automated in such manners.

Policies (and their implementation as processes, standards, and the like) must be enforced. As Steve Schlarman notes “Policy without a corresponding compliance measurement and monitoring strategy will be looked at as unrealistic, ignored dogma” [Schlarman 2008].

Policies and their derivative guidance are developed, just like systems, via a lifecycle. They require some initial vision and an understanding of what the requirements are. Again, Schlarman notes: “Policy must define the why, what, who, where, and how of the IT process” [Schlarman 2008]. User stories have been used effectively to understand policy needs.

Finally, Griffin makes an important point to bear in mind: “Company policies can breed and multiply to a point where they can hinder innovation and risk-taking. Things can get out of hand as people generate policies to respond to one-time infractions or out of the ordinary situations”.

It is advisable to institute sunset dates or some other mechanism that forces their periodic review, with the understanding that any such approach generates demand on the organization that must be funded. We will discuss this more in the Competency Category on digital governance.

Standards, Frameworks, Methods, and the Innovation Cycle

We used the term “standards” above without fully defining it. We have discussed a variety of industry influences throughout this document: PMBOK, ITIL, COBIT, Scrum, Kanban, ISO/IEC 38500, and so on. We need to clarify their roles and positioning further. All of these can be considered various forms of “guidance” and as such may serve as governance elements. However, their origins, stakeholders, format, content, and usage vary greatly.

First, the term "standard” especially has multiple meanings. A “standard” in the policy sense may be a set of compulsory rules. Also, “standard” or “baseline” may refer to some intended or documented state the organization uses as a reference point. An example might be: “We run Debian Linux 16:10 as a standard unless there is a compelling business reason to do otherwise”.

This last usage shades into a third meaning of uniform, de jure standards such as are produced by the IEEE, IETF®, and ISO/IEC.

  • IEEE: Institute of Electrical and Electronics Engineers

  • IETF: Internet Engineering Task Force

  • ISO/IEC: International Standards Organization/International Electrotechnical Commission

The International Standards Organization, or ISO, occupies a central place in this ecosystem. It possesses “general consultative status” with the United Nations, and has over 250 technical committees that develop the actual standards.

The IEEE standardizes such matters as wireless networking (e.g., Wi-Fi). The IETF standardizes lower-level Internet protocols such as Transmission Control Protocol (TCP)/IP and HTTP. The World Wide Web Consortium (W3C®) standardizes higher-level Internet protocols such as HTML™. Sometimes standards are first developed by a group such as the IEEE and then given further authority though publication by ISO/IEC. The ISO/IEC in particular, in addition to its technical standards, also develops higher-order management/“best practice” standards. One well-known example of such an ISO standard is the ISO 9000 series on quality management.

Some of these standards may have a great effect on the digital organization. We will discuss this further in the Competency Category on compliance.

Frameworks were discussed in Industry Frameworks. Frameworks have two major meanings. First, software frameworks are created to make software development easier. Examples include Struts, AngularJS, and many others. This is a highly volatile area of technology, with new frameworks appearing every year and older ones gradually losing favor.

In general, we are not concerned with these kinds of specific frameworks in this document, except governing them as part of the technology product lifecycle. We are concerned with “process” frameworks such as ITIL, PMBOK, COBIT, and CMMI.

Frameworks tend to be lengthy. The ISO/IEC standards are brief by comparison, perhaps on average 10% of the corresponding framework. Methods (aka methodologies) in general are more action-oriented and prescriptive. Scrum and XP are methods. It is at least arguable that PMBOK is a method as well as a framework.

There is little industry consensus on some of these definitional issues, and you are advised not to be overly concerned about such abstract debates. If you need to comply with something to win a contract, it does not matter whether it’s a “standard”, “framework”, “guidance”, “method”, or whatever.

Finally, there are terms that indicate technology cycles, movements, communities of interest, or cultural trends: Agile and DevOps being two of the most current and notable. These are neither frameworks, standards, nor methods. However, commercial interests often attempt to build frameworks and methods representing these organic trends. Examples include SAFe, Disciplined Agile Delivery, the DevOps Institute, the DevOps Agile Skills Association, and many others.

standards cycle
Figure 3. Innovation Cycle

Innovation Cycle illustrates the innovation cycle. Innovations produce value, but innovation presents change management challenges, such as cost and complexity. The natural response is to standardize for efficiency, and standardization taken to its end state results in commodification, where costs are optimized as far as possible, and the remaining concern is managing the risk of the commodity (as either consumer or producer). While efficient, commoditized environments offer little competitive value, and so the innovation cycle starts again.

Note that the innovation cycle corresponds to the elements of value recognition:

  • Innovation corresponds to Benefits Realization

  • Standardization corresponds to Cost Optimization

  • Commoditization corresponds to Risk Optimization

Organizational Structures

We discussed basic organizational structure in Organization and Culture. However, governance also may make use of some of the scaling approaches discussed in IT Human Resources Management. Cross-organization coordination techniques (similar to those discussed in Boundary Spanning) are frequently used in governance (e.g., cross-organizational coordinating committees, such as an enterprise security council).

Culture, Ethics, and Behavior

Culture, ethics, and behavior as a governance element can both drive revenue as well as risk and cost; see also Culture and Hiring.

People, Skills, and Competencies

People and their skills and competencies (covered in IT Human Resources Management) are governance elements upon in which all the others rest. “People are our #1 asset” may seem to be a cliche, but it is ultimately true. Formal approaches to understanding and managing this base of skills are therefore needed. A basic “human resources” capability is a start, but sophisticated and ambitious organizations institute formal organizational learning capabilities to ensure that talent remains a critical focus.


Process is defined in Definitions. We will discuss processes as controls in the upcoming Competency Category on risk management. A control is a role that a governance element may play. Processes are the primary form of governance element used in this sense.


Information is a general term; in the sense of a governance element, it is based on data in its various forms, with overlays of concepts (such as syntax and semantics) that transform raw “data” into a resource that is useful and valuable for given purposes. From a governance perspective, information carries governance direction to the governed system, and the feedback monitoring is also transmitted as information. Information resource management and related topics such as data governance and data quality are covered in Information Management; it is helpful to understand governance at an overall level before going into these more specific domains.

Services, Infrastructure, and Applications

Services, infrastructure, and applications, of course, are the critical foundation of digital value. These fundamental topics were covered in Context I. In the sense of governance elements, they have a recursive or self-reflexive quality. Digital technology automates business objectives; at scale, a digital pipeline becomes a non-trivial business concern in and of itself, requiring considerable automation (Betz 2011a, C220). Applications that serve as digital governance elements might include:

  • Source control

  • Build management

  • Package management

  • Deployment and configuration management

  • Monitoring

  • Portfolio management

Evidence of Notability

Governance requires mechanisms in order to function.


Elaborate structures of governance elements (especially processes) can slow down digital delivery and, ironically, contribute greater risk than they reduce.

Related Topics