GEIT Framework at Work, Part 4: Outlining the Work Products

No governance of enterprise IT (GEIT) initiative can be accomplished without careful attention to the work products and the project plan. They are the elements that deliver tangible results from GEIT. This article—the fourth in a 6-part series that looks at the practical application of a GEIT framework—outlines the work that is required to create the defined work products and execute the project plan in an efficient, effective and successful manner.

Within the 3 practices of the APO13 Manage Security process, there are 6 work products defined. The project plan detailed how the creation of these will take place and who would be responsible for them. At this point, the work products themselves need to be defined and resources put in place to ensure they will be produced properly and in a timely manner ( figure 1).

Figure 1—APO13 Work Product Outputs

For each of the defined work products, a business process owner and any other relevant parties must be identified to define and create the product. The next step is to elaborate each work product and engage the necessary parties to create them.

ISMS Policy

The ISMS policy describes the context within which information security operates and calls out what standards are needed to support it. It can also specify related policies within the enterprise. The policy provides the foundation that enables the enterprise to assure that it is protecting its electronic assets and necessary security levels are achieved.

The organization of the ISMS policy can follow established formats such as Plan, Build, Run, Monitor or Plan, Do, Check, Act, or the enterprise may use an internally developed format. The important point is to identify all relevant security resources that are necessary to perform the security function.

The primary resource for creation and approval of the ISMS policy is the chief information security officer (CISO) and his or her delegates. Existing policy creation, review and approval processes can be leveraged to create the ISMS policy. Additional resources can include the chief information officer (CIO), the head of IT administration and information security mangers.

ISMS Scope Statement

The ISMS scope statement defines what services exist within the security system and related resources. These include physical and human resources assets. The ISMS scope statement must include all systems identified as central to achieving the enterprise’s security strategy. There can be multiple ISMS systems within an enterprise, so it is important to clearly state what area is being served and what services are included. It is also important to describe what resources are not included in the scope statement to keep the project team focused.

The ISMS scope statement is part of the ISMS policy and will be generated as part of the policy creation process. It is important to make certain this work product is included in the project schedule for the ISMS policy.

Information Security Risk Treatment Plan

A risk assessment informs several aspects of a governance structure. The ISMS is one such element. Identified risk factors are described in terms of the vulnerabilities they address, the threat actors they face, and potential severity and impact should those risk factors materialize into incidents or events. A risk treatment plan defines whether risk should be accepted, avoided, transferred or mitigated.

The primary resource for creation and approval of the risk treatment plan is the CISO and his or her delegates. Existing risk assessment and risk response creation, review and approval processes can be leveraged to create the risk treatment plan. Additional resources can include the CIO, the head of IT administration and information security mangers.

Information Security Business Cases

The use of business cases is very much enterprise-specific. Business cases are typically used to create a rationale for moving forward with a project. These are not needed for processes that have become business as usual, but for establishing the enterprise’s reason to invest in IT-enabled investments.

Business cases can also contribute to the selection of risk treatment strategies and can be considered part of the risk treatment plan creation. Analysis of a process should include an overview of potential threat actors and vulnerabilities facing the systems under consideration. This is the basis for risk treatment strategy selection and stimulates thinking around which scenarios are most realistic and merit preparation activities.

ISMS Audit Reports

Internal audit must be informed of the new work products that are being created. This will provide the auditors with clearer expectations regarding what is available to substantiate the internal control environment and afford them the opportunity to make suggestions for continuous improvement initiatives. There is another benefit to working with internal audit early on in creating, or amending, management practices: Any type of dashboard or performance reports that are generated can be designed with internal audit’s needs in mind. This contributes to a common language and common understanding internally.

When created collaboratively, the audit reports are overseen by the CISO, but many other resources can be involved in the detailed work. These include: business process owners, the project management office, the CIO, enterprise architecture, development, IT operations, system administration, service, information security, business continuity and privacy managers.

Recommendations for Improving the ISMS

Improvements to the ISMS can come from many directions. The resources bringing this knowledge forward include the same roles detailed in creating the audit reports. Mechanically, the process goals and metrics build reporting and monitoring pathways into this work product. This is where improvement opportunities will be found. Leading and lagging indicators or key risk indicators (KRIs) can provide early information that ISMS changes can be made. Using monitoring reports for identifying such opportunities also provides information needed to create new business cases to substantiate the need for change and assist in the change readiness process.

With all the work products accounted for and established, the ISMS is ready for operation. The work product creation process ensures alignment between work products and their related process and business goals.

Confirming the Results

The next installment in this series will discuss how to confirm that the necessary components of the APO13 Manage Security process were successfully created and implemented. This will become the basis for operations and later metrics development and performance reporting.

Peter C. Tessin, CISA, CRISC, CISM, CGEIT

Is a senior manager at Discover Financial Services. He leads the governance group within business technology (BT) risk. In this role, he is responsible for ensuring that policy, standards and procedures align with corporate objectives. He serves as the internal party responsible for regulatory exam management and is the internal liaison to corporate risk management. Prior to this role, Tessin was a technical research manager at ISACA where he was the project manager for COBIT 5 and led the development of other COBIT 5-related publications, white papers and articles. Tessin also played a central role in the design of COBIT Online, ISACA’s website that offers convenient access to the COBIT 5 product family and includes interactive digital tools to assist in the use of COBIT. Prior to joining ISACA, Tessin was a senior manager at an internal audit firm, where he led client engagements and was responsible for IT and financial audit teams. Previously, he worked in various industry roles including staff accountant, application developer, accounting systems consultant and trainer, business analyst, project manager, and auditor. He has worked in many countries outside of his native United States, including Australia, Canada, France, Germany, Italy, Jordan, Mexico and the United Kingdom.