®
Overview of International
IT Guidance, 3rd Edition
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
ISACA®
With 95,000 constituents in 160 countries, ISACA (www.isaca.org) is a leading global provider of knowledge, certifications,
community, advocacy and education on information systems (IS) assurance and security, enterprise governance and management
of IT, and IT-related risk and compliance. Founded in 1969, the non-profit, independent ISACA hosts international conferences,
publishes the ISACA® Journal, and develops international IS auditing and control standards, which help its constituents ensure trust
in, and value from, information systems. It also advances and attests IT skills and knowledge through the globally respected Certified
Information Systems Auditor® (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance of Enterprise
IT® (CGEIT®) and Certified in Risk and Information Systems ControlTM (CRISCTM) designations. ISACA continually updates
COBIT®, which helps IT professionals and enterprise leaders fulfill their IT governance and management responsibilities, particularly
in the areas of assurance, security, risk and control, and deliver value to the business.
Disclaimer
ISACA has designed this publication, COBIT® Mapping: Overview of International IT Guidance, 3rd Edition (the ‘Work’), primarily
as an educational resource for control professionals. ISACA makes no claim that use of any of the Work will assure a successful
outcome. The Work should not be considered inclusive of any proper information, procedures and tests or exclusive of other
information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any
specific information, procedure or test, control professionals should apply their own professional judgement to the specific control
circumstances presented by the particular systems or information technology environment.
Reservation of Rights
© 2011 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed,
stored in a retrieval system or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise)
without the prior written authorisation of ISACA. Reproduction and use of all or portions of this publication are permitted solely for
academic, internal, noncommercial use and for consulting/advisory engagements and must include full attribution of the material’s
source. No other right or permission is granted with respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
COBIT® Mapping: Overview of International IT Guidance, 3rd Edition
CRISC is a trademark/ service mark of ISACA. The mark has been applied for or registered in countries throughout the world.
2
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Acknowledgements
Acknowledgements
ISACA wishes to recognise:
The Researcher
Jimmy Heschl, CISA, CISM, CGEIT, BWIN, Austria
Expert Reviewers
Patrick Stachtchenko, CISA, CGEIT, CA Stachtchenko & Associates SAS, France, Chair
Steven A. Babb, CGEIT, KPMG, UK
Sushil Chatterji, CGEIT, Edutech Enterprises, Singapore
Sergio Fleginsky, CISA, Akzonobel, Uruguay
John W. Lainhart, IV, CISA, CISM, CGEIT, IBM Global Business Services, USA
Mario C. Micallef, CGEIT, CPAA, FIA, Ganado & Associates, Malta
Derek J. Oliver, Ph.D., DBA, CISA, CISM, CITP, FBCS, FISM, MInstISP, Ravenswood Consultants Ltd, UK
Robert G. Parker, CISA, CA, CMC, FCA, Canada
Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia
Rolf M. von Roessing, CISA, CISM, CGEIT, Forfa AG, Germany
Robert E. Stroud, CGEIT, CA Technologies, USA
ISACA Board of Directors
Emil D’Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., USA, International President
Christos K. Dimitriadis, Ph.D., CISA, CISM, INTRALOT S.A., Greece, Vice President
Ria Lucas, CISA, CGEIT, Telstra Corp. Ltd., Australia, Vice President
Hitoshi Ota, CISA, CISM, CGEIT, CIA, Mizuho Corporate Bank Ltd., Japan, Vice President
Jose Angel Pena Ibarra, CGEIT, Alintec S.A., Mexico, Vice President
Robert E. Stroud, CGEIT, CA Technologies, USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Rolf M. von Roessing, CISA, CISM, CGEIT, Forfa AG, Germany, Vice President
Lynn C. Lawton, CISA, FBCS CITP, FCA, FIIA, KPMG Ltd., Russian Federation, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Director
Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia, Director
Howard Nicholson, CISA, CGEIT, CRISC, City of Salisbury, Australia, Director
Jeff Spivey, CPP, PSP, Security Risk Management, USA, ITGI Trustee
Knowledge Board
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Chair
Michael Berardi Jr., CISA, CGEIT, Nestle USA, USA
John Ho Chi, CISA, CISM, CBCP, CFE, Ernst & Young LLP, Singapore
Jose Angel Pena Ibarra, CGEIT, Alintec S.A., Mexico
Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia
Jon Singleton, CISA, FCA, Auditor General of Manitoba (retired), Canada
Patrick Stachtchenko, CISA, CGEIT, CA, Stachtchenko & Associates SAS, France
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
3
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Acknowledgements (cont.)
Framework Committee
Patrick Stachtchenko, CISA, CGEIT, CA, Stachtchenko & Associates SAS, France, Chair
Steven A. Babb, CGEIT, KPMG, UK
Sushil Chatterji, CGEIT, Edutech Enterprises, Singapore
Sergio Fleginsky, CISA, Akzonobel, Uruguay
John W. Lainhart IV, CISA, CISM, CGEIT, IBM Global Business Services, USA
Mario C. Micallef, CGEIT, CPAA, FIA, Ganado & Associates, Malta
Derek J. Oliver, Ph.D., DBA, CISA, CISM, CITP, FBCS, FISM, MInstISP, Ravenswood Consulting Ltd., UK
Robert G. Parker, CISA, CA, CMC, FCA, Canada
Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia
Robert E. Stroud, CGEIT, CA Technologies, USA
Rolf M. von Roessing, CISA, CISM, CGEIT, Forfa AG, Germany
ISACA and IT Governance Institute® (ITGI®) Affiliates and Sponsors
American Institute of Certified Public Accountants
ASIS International
The Center for Internet Security
Commonwealth Association for Corporate Governance Inc.
FIDA Inform
Information Security Forum
Information Systems Security Association
Institute of Management Accountants Inc.
ISACA chapters
ITGI Japan
Norwich University
Strategic Technology Management Institute (STMI) of the National University of Singapore
Solvay Brussels School of Economics and Management
University of Antwerp Management School
ASI System Integration
Hewlett-Packard
IBM
SOAProjects Inc.
Symantec Corp.
TruArx Inc.
4
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Table of Contents
Table of Contents
1. Purpose and Scheme for Classification of the Guidance.........................................................................................................................6
2. COBIT......................................................................................................................................................................................................9
3. COSO......................................................................................................................................................................................................18
4. ITIL® V3.................................................................................................................................................................................................23
5. ISO/IEC 17799:2000..............................................................................................................................................................................28
6. ISO/IEC 17799:2005..............................................................................................................................................................................35
7. ISO/IEC 20000.......................................................................................................................................................................................41
8. NIST SP800-53 Rev 1............................................................................................................................................................................47
9. FFIEC......................................................................................................................................................................................................54
10. PMBOK................................................................................................................................................................................................58
11. CMMI® for Development, V1.2...........................................................................................................................................................63
12. TOGAF 8.1...........................................................................................................................................................................................73
13. Conclusion............................................................................................................................................................................................80
14. References ............................................................................................................................................................................................82
Appendix—ISACA Professional Guidance Publications...........................................................................................................................84
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
5
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
1. Purpose and Scheme for Classification of the Guidance
ISACA® (www.isaca.org) exists to assist enterprise leaders in their responsibility to ensure that IT goals align with those of the
business, IT delivers value, its performance is measured, its resources are properly allocated and its risk is mitigated. Through
original research, case studies and electronic resources, ISACA helps ensure that boards and executive management have the tools
and information they need for IT to deliver against expectations. One such tool is the COBIT framework. COBIT was initially
created by the Information Systems Audit and Control Foundation® (ISACF®) in 1996. The IT Governance Institute® (ITGI®), which
was founded by ISACA in 1998, released COBIT® 3rd Edition in 2000, COBIT® 4.0 in 2005 and COBIT® 4.1 in 2007. This series of
COBIT mapping papers supports the effective use of COBIT in conjunction with a number of IT-related frameworks and standards.
ISACA intends to effectively support COBIT users with mappings to third-party products once COBIT 5 development is complete
and an approach to mapping is established.
COBIT provides a high-level, comprehensive IT governance and control framework based on the harmonisation of more than 50
IT good practice sources published by various international standards bodies, governments and other institutions.
ISACA has been conducting a research project that provides a detailed comparison between COBIT and a selection of these
standards and good practices, to support ongoing COBIT developments and provide guidance to COBIT users implementing
IT governance. The research addresses questions such as:
• What should be defined?
• What is an appropriate level of detail?
• What should be measured?
• What should be automated?
• What is good practice?
• Is there a certification available?
The results of the research project can be used to further enhance the definition of COBIT’s control objectives and alignment
with other good practices and standards. In addition, the results help entities that are planning to apply standards and guidance to
harmonize those initiatives and use COBIT as the overall framework for sound IT governance.
Although many of these questions can be addressed using the openly available COBIT guidance, more specific information is
required. This project addresses the gaps by mapping the most important and commonly used standards1 to the COBIT processes
and control objectives. The project consists of two components:
1. This high-level overview of international IT guidance.
2. A series of more detailed mapping documents focussing on individual standards or guidance.* The mappings are posted at
www.isaca.org/cobitmapping and available from the ISACA Bookstore (www.isaca.org/bookstore):
– Aligning COBIT® 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit
– COBIT® Mapping: Mapping of CMMI® for Development V1.2 With COBIT® 4.1
– COBIT® Mapping: Mapping of FFIEC Framework With COBIT® 4.1
– COBIT® Mapping: Mapping of ISO/IEC 20000 With COBIT® 4.1
– COBIT® Mapping: Mapping of ISO/IEC 17799:2000 With COBIT® 4.0, 2nd Ed.
– COBIT® Mapping: Mapping of ISO/IEC 17799:2005 With COBIT® 4.0
–C
OBIT® Mapping: Mapping of ITIL V3 With COBIT® 4.1
– COBIT® Mapping: Mapping of NIST SP800-53 With COBIT® 4.1
– COBIT® Mapping: Mapping of PMBOK®With COBIT® 4.0
– COBIT® Mapping: Mapping of SEI’s CMM® for Software With COBIT® 4.0
– COBIT® Mapping: Mapping of TOGAF 8.1 With COBIT® 4.0
COBIT® Mapping: Overview of International IT Guidance, 3rd Ed. an update of the previous detailed mapping overview of the
mapping series issued in 2006. It focuses on the business drivers for implementing the guidance and the risk of non-compliance. It
classifies the guidance publications and provides an overview of their content and how they map to COBIT.
*T
he series includes several mappings that relate to older releases and are included because many enterprises are still using them as
their reference documents. Therefore, ISACA will continue to provide these mappings.
1
The term “standard” is used in this document to encompass guidance publications.
6
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
1. Purpose and Scheme for Classification of the Guidance
This publication is limited to the guidance in the following list, which is not meant to be exhaustive. A brief overview of the
standards mapped against each other in this document is as follows:
• COBIT—Released as an IT process and control framework linking IT to business requirements, COBIT initially was used mainly
by the assurance community in conjunction with business and IT process owners. With the addition of management guidelines in
2000, COBIT was used more frequently as a management framework, providing management tools such as metrics and maturity
models to complement the control framework. With the release of COBIT 4.0 in 2005, it became a more complete IT governance
framework. Incremental updates to COBIT 4.0 were made in 2007; they can be seen as a fine-tuning of the framework, not
fundamental changes. The current version is COBIT 4.1.
• COSO Internal Control—Integrated Framework defines a framework that initiates an integrated process of internal control.
• ITIL® V3—The IT Infrastructure Library® (ITIL) is a collection of best practices in IT service management. It is focused on the
service processes of IT and considers the central role of the user.
• ISO/IEC 17799:2000—Code of Practice for Information Security Management is an international standard based on
BS 7799-1:1999. It is presented as best practice for information security management.
• ISO/IEC 17799:2005—The Code of Practice for Information Security Management is an international standard based on
BS 7799-1/ISO/IEC 17799:2000. It is presented as best practice for implementing information security management.
• ISO/IEC 20000—This series consists of two publications:
– Specification (ISO/IEC 20000-1:2005), which describes audit requirements
–C
ode of Practice (ISO/IEC 20000-2:2005), which provides further guidance for service providers
• NIST SP800-53 Rev 1—Recommended Security Controls for Federal Information Systems, issued in February 2005 is the first in
this series.
• FFIEC—The FFIEC IT Examination Handbook represents a collection of documents that can be classified as generally accepted
best practice for IT governance, control and assurance for financial institutions.
• PMBOK—A Guide to the Project Management Body of Knowledge (PMBOK© Guide) is described as ‘the sum of knowledge
within the profession of project management’. It is an American National Standard, ANSI/PMI 99-001-2004.
• CMMI® for Development, V1.2—Capability Maturity Model Integration® combines three source models—Capability Maturity
Model for Software (SWCMM) V2.0 draft C, Electronic Industries Alliance Interim Standard (EIA/IS) 731 and Integrated Product
Development Capability Maturity Model (IPD-CMM) V0.98—into a single improvement framework for use by organisations
pursuing enterprisewide process improvement.
• TOGAF 8.1—It provides a detailed method and a set of supporting tools for developing an enterprise architecture.
Scheme for Classification of the Guidance
To enable a proper comparison of each standard or guidance publication, a scheme for classification to be used in evaluating all the
guidance was defined as follows.
Document Taxonomy
This section lists the type of guidance, such as an international or a national standard or a collection of best practices.
Issuer
The issuer refers to the issuing body of the paper and lists the organization standing behind the guidance and keeping the document
up to date.
Goal(s) of the Guidance
This section lists the primary goals of the document. For example, the guidance may focus on information security management,
baseline protection, guidance for software development or management of tactical issues.
Business Drivers for Implementing the Guidance, Including Typical Situations
The business case for implementing the guidance and the typical situations indicating implementation of the guidance are listed here.
Related Risk of Not Implementing the Guidance
The business risk of not implementing the guidance is considered in this section.
Target Audience
This section discusses whether there is a special target audience for the guidance. For example, are public organisations, assurance
professionals, security management or general IT professionals the target audience?
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
7
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Timeliness
Timeliness considers whether the guidance is up to date and how frequently it is revised.
Certification Opportunities
This section considers the certification path, what can be certified and the certification body, if applicable.
Circulation
Circulation considers whether the guidance is used internationally or limited to a certain region, and whether information on usage
is available.
Completeness
The completeness is classified using two dimensions:
• Vertical—The detail of the guidelines in terms of technical or operational profundity. The higher the level of detail, the higher the
document is classified.
• Horizontal—Guidance completeness, e.g., the extent to which COBIT is addressed by the guidance. The higher the level of detail,
the higher the document is classified.
Availability
Availability addresses how and where the information can be obtained.
COBIT Processes Addressed
A high-level mapping of COBIT processes addressed by the respective guidance is presented. The COBIT processes are described in
the section on COBIT in this publication. Those areas of COBIT that are frequently addressed are colored blue.
Information Criteria Addressed
This section addresses which of the following COBIT information criteria are referenced within the particular guidance:
• Efficiency
• Effectiveness
• Confidentiality
• Integrity
• Availability
• Compliance
• Reliability
IT Resources Concerned
This section focuses on which of the COBIT IT resources are addressed by the respective guidance:
• Applications
• Information
• Infrastructure
• People
IT Governance Focus Areas Addressed
This section rates as primary, secondary or not addressed, the following IT governance areas:
• Value delivery
• Risk management
• Resource management
• Performance Measurement
• Strategic Alignment
Description of the Guidance and Its Content
The fundamental concepts covered by the guidance are discussed.
Further References
This section lists sources of additional information.
8
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
2. COBIT
2. COBIT
For purposes of this publication, COBIT is the framework to which the other guidance is compared.
Document Taxonomy
COBIT represents a collection of documents that can be classified as generally accepted good practice for IT governance, control
and assurance.
Issuer
The first edition of COBIT was issued by ISACF in 1996. In 1998, the second edition was published with additional control
objectives and the Implementation Tool Set. The third edition was issued by ITGI in 2000 and included the management guidelines
and several new control objectives. In 2005, ITGI finalised a complete rework of the COBIT content and published COBIT 4.0,
which demonstrated a clear focus on IT governance. The current version, COBIT 4.1, encompasses incremental updates.
Goal of the Guidance
The COBIT mission is:
…to research, develop, publicise and promote an authoritative, up-to-date, internationally accepted IT governance
control framework for adoption by enterprises and day-to-day use by business managers, IT professionals and
assurance professionals.2
Business Drivers for Implementing the Guidance,
Including Typical Situations
COBIT is usually implemented subject to one or more of the following business cases:
• There is a need for IT governance.
• Services delivered by IT are to be aligned with business goals.
• IT processes are to be standardised/automated.
• A framework for overall IT processes is needed.
• IT processes are to be unified.
• A framework is needed for a quality management system for IT.
• A structured audit approach is to be defined.
• Mergers and acquisitions with an IT impact are occurring.
• IT cost-control initiatives are desired.
• Part or all of the IT function is to be outsourced.
• Compliance with external requirements (e.g., regulators, organisations or third parties) is of concern.
• Important changes in an enterprise, its business goals and processes affect IT.
Related Risk of Not Implementing the Guidance
Risk of not implementing COBIT includes:
• Misaligned IT services and divergence
• Weak support of business goals due to misalignment
• Wasted opportunities due to misalignment
• Persistence of the perception of IT as a black box
• A shortfall between management’s measurements and expectations
• Know-how tied to key individuals, not to the enterprise
• Excessive IT cost and overhead
• Erroneous investment decisions and projections
• Dissatisfaction of business users with IT services supplied
2
ISACA, COBIT® 4.1, USA, 2007
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
9
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
• Regulatory breaches with potential significant financial penalties on enterprises, restrictions on operating licences, and fiduciary
liability on directors and officers when deemed not to have exercised due care and responsibility
• Unfulfilled information criteria
• Adverse effects on the enterprise’s internal control system due to a weak enterprise architecture for IT
Target Audience
All types of enterprises, public and private companies, and external assurance and advisory professionals form the relevant target
group. Within enterprises, COBIT intends to support executive management and boards; business and IT management; and
governance, assurance, control and security professionals. The level of detail primarily depends on the role of the function. If the
function is responsible for fulfilling the requirements, thorough knowledge should be ensured, but if the function is accountable or
involved otherwise (consulted or informed), an overview should be applicable. The level is indicated in figure 1.
Figure 1—Chart of COBIT Audiences
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
T
O
T
O
O
O
T
O
O
O
O
T
O
O
Chief Architect
T
Head of Operations
T
Business Process Owner
T
Chief Information Officer (CIO)
O
Business Executive
O
Chief Financial Officer (CFO)
O
Chief Executive Officer (CEO)
Head of Development
Functions: Thorough knowledge of the document (T), Overview of the document’s
intention and content (O)
COBIT
O
O
O
T
O
O
O
Plan and Organise
O
O
O
T
O
O
T
Acquire and Implement
O
O
O
T
Deliver and Support
O
O
T
T
O
O
Monitor and Evaluate
O
O
O
Timeliness
The core content of COBIT was updated in 2005, resulting in COBIT 4.0, and was further refined in 2007, resulting in COBIT 4.1.
The research conducted for these updates addressed components of the control objectives and management guidelines. Specific areas
that were addressed include:
• COBIT—IT governance bottom-up and top-down alignment
• COBIT and other detailed standards—Detailed mapping between COBIT and ITIL,3 CMM,4 COSO,5 PMBOK,6 ISF’s Standard
of Good Practice for Information Security,7 ISO/IEC 27000 series,8 and other global and regional frameworks and standards, to
enable harmonisation with those standards in language, definitions and concepts
ritish Office of Government Commerce (OCG®), IT Infrastructure Library® (ITIL), UK, 1999-2004
B
Software Engineering Institute (SEI) of Carnegie Mellon University, Capability Maturity Model for Software® (CMM®), USA, 1993, and Capability Maturity Model
Integration® (CMMI®), 2000
5
Committee of Sponsoring Organizations of the Treadway Commission (COSO), Internal Control—Integrated Framework, USA, 1994, and Enterprise Risk
Management—Integrated Framework, 2004
6
Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK®), 3rd Edition, USA, 2004
7
Information Security Forum (ISF), Standard of Good Practice for Information Security, UK, 2003
8
International Organization for Standardisation (ISO)/International Electrotechnical Commission (IEC), 27000 (Series working title: Information Technology—
Security Techniques—Information Security Management Systems—Overview and Vocabulary), Switzerland. The first document, 27001, was published in 2005 and
27002 and 27006 were issued in 2007. Others are still in development.
3
4
10
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
2. COBIT
• Review of critical success factors (CSFs) content—Splitting the CSFs into ‘what you need from other’ and ‘what you need to
do yourself’. CSFs were replaced by process inputs (success factors needed from others) and activity goals (goals that the process
owner must address).
• Linking of business goals, IT goals and IT processes—Detailed research was conducted in eight different industries, resulting in
a more detailed insight into how COBIT processes support the achievement of specific IT goals and, by extension, business goals.
• Review of maturity models’ content—Ensured consistency and quality of maturity levels between and within processes, including
better definitions of maturity model attributes
The range of COBIT-related products was expanded in 2007 to include the IT Assurance Guide: Using COBIT® and COBIT®
Control Practices, 2nd Edition. Implementing and Continually Improving IT Governance, which replaced the implementation guide,
was issued in 2009.
Certification Opportunities
The IT Assurance Guide is aligned with COBIT 4.1 and can be used for auditing and self-assessment against the control objectives,
but there is no certification for enterprises. However, the COBIT framework is used frequently by Certified Public Accountants
(CPAs) and Chartered Accountants (CAs) when performing a Statement on Auditing Standards (SAS) No. 70 service organisation
review, earning SysTrust certification or pursuing Sarbanes-Oxley compliance.
Individuals can complete the COBIT Foundation CourseTM and obtain a certificate of completion. Non-COBIT certification is
available through ISACA in the form of the Certified Information Systems Auditor® (CISA®), Certified Information Security
Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems
ControlTM (CRISCTM) certifications.
Circulation
COBIT is used worldwide. In addition to the English version, COBIT has been translated into Chinese, French, German, Hebrew,
Hungarian, Italian, Japanese, Korean, Portuguese, Romanian, Russian and Spanish. Further updates of translations to COBIT 4.1 are
in development.
Completeness
COBIT addresses a broad spectrum of duties in IT management. It covers the most significant parts of IT management, including
those covered by other standards. Although no technical details are included, the necessary tasks for complying with the control
objectives are self-explanatory. Therefore, it is classified at a relatively high level, aiming to be generically complete, but not
specific.
Availability
COBIT 4.1 is readily accessible for complimentary electronic download from the ISACA web site at www.isaca.org/cobit.
COBIT Online® can be purchased at www.isaca.org/cobitonline. COBIT Online allows a user to customise a version of COBIT just
right for the enterprise, then store and manipulate that version as desired. It offers online, real-time surveys and benchmarking. IT
Assurance Guide: Using COBIT is posted on the ISACA site for complimentary download for ISACA members. Alternatively, the
print versions of COBIT 4.1 and most related publications can be purchased from the ISACA Bookstore at www.isaca.org/bookstore.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
11
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
COBIT Processes Addressed
Plan and Organise
2 3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
COBIT
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Note: The chart is not a comparison; this is COBIT itself.
Information Criteria Addressed
Information Criteria
+
+
+
+
+
+
+
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
Note: The chart is not a comparison, this is COBIT itself.
IT Resources Concerned
IT Resources
+
+
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
Note: This chart is not a comparison, this is COBIT itself.
12
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
2. COBIT
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MANENT
FOR
PER SUREM
MEA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
IC
EG NT
AT ME
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of the Guidance and Its Content
Enterprise governance (the system by which enterprises are governed and controlled) and IT governance (the system by which the
enterprise’s IT is governed and controlled) are, from a COBIT point of view, highly related. Enterprise governance is inadequate
without IT governance and vice versa. IT can extend and influence the performance of the enterprise, but IT has to be subject to
adequate governance. On the other hand, business processes require information from the IT processes, and this interrelationship has
to be governed as well.
In this subject matter, the plan-do-check-act (PDCA) cycle becomes evident. The concept of the PDCA cycle is usually used in
structured problem solving and continuous improvement processes. The PDCA cycle is also known as the Deming cycle or the
Deming wheel of a continuous improvement process. Both the information needed (enterprise governance) and the information
delivered (IT governance) must be planned with measurable and constructive indicators (plan). The information and, possibly
information systems, must be implemented, delivered and used (do). The outcome of the information delivered and used is measured
against the indicators defined in the planning phase (check). Deviation is investigated and corrective action is taken (act).
Considering these interdependencies, it is apparent that the IT processes are not an end in themselves; instead, they are a means to an
end that is highly integrated with the management of business processes.
IT Governance Using COBIT
ISACA has defined IT governance as follows:
IT governance is the responsibility of executives and the board of directors, and consists of the leadership, organisational
structures and processes that ensure that the enterprise’s IT sustains and extends the organisation’s strategies and objectives.9
COBIT supports IT governance by providing a framework to ensure that:
• IT is aligned with the business
• IT enables the business and maximises benefits
• IT resources are used responsibly
• IT risk is managed appropriately
Performance measurement is essential for IT governance, is supported by COBIT, and includes setting and monitoring measurable
objectives of what IT processes need to deliver (process outcome) and how they deliver it (process capability and performance).
The COBIT IT Processes
The COBIT processes are grouped into four domains, as indicated in figure 2.
9
ISACA, Board Briefing on IT Governance, 2nd Edition, 2003, p. 10
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
13
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Any service delivered by IT and all services provided to the core processes have to be integrated into the IT service life cycle, as
indicated in figure 2. Plans and organisational structures already developed can be adopted, depending on the significance of each
service, rather than developing a new plan for the IT service. Services are subsequently implemented and all necessary precautions
for ongoing service, delivery and monitoring are considered.
From the IT governance point of view, single services are merely in the background. The focus must be on the PDCA cycle
discussed previously, for the sum of services delivered by and with IT.
Each process is described by using the following information:
• A process description
• Control objectives
• Information criteria affected by the process
• IT resources used by the process
• IT governance focus areas
• Inputs and outputs
• A responsible, accountable, consulted and informed (RACI) chart
• Goals and metrics
Figure 2—Overall COBIT Framework
Source: COBIT 4.1, figure 23—Overall COBIT Framework, p.26
14
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
2. COBIT
Information Criteria
To satisfy business objectives, information needs to conform to certain control criteria, which COBIT refers to as business
requirements for information. Based on the broader quality, fiduciary and security requirements, seven distinct, certainly
overlapping, information criteria are defined as follows:
• Effectiveness deals with information being relevant and pertinent to the business process as well as being delivered in a timely,
correct, consistent and usable manner.
• Efficiency concerns the provision of information through the optimal (most productive and economical) use of resources.
• Confidentiality concerns the protection of sensitive information from unauthorised disclosure.
• Integrity relates to the accuracy and completeness of information as well as to its validity in accordance with business values
and expectations.
• Availability relates to information being available when required by the business process now and in the future. It also concerns the
safeguarding of necessary resources and associated capabilities.
• Compliance deals with complying with those laws, regulations and contractual arrangements to which the business process is
subject, i.e., externally imposed business criteria, as well as internal policies.
• Reliability relates to the provision of appropriate information for management to operate the entity and exercise its fiduciary and
governance responsibilities.
IT Resources
Following the COBIT definition, the resources used by IT are identified as follows:
• Applications are automated user systems and manual procedures that process the information.
• Information is the data, in all their forms—input, processed and output—by the information systems in whatever form is used by
the business.
• Infrastructure is the technology and facilities (hardware, operating systems, database management systems, networking,
multimedia, etc., and the environment that houses and supports them) that enable the processing of the applications.
• People are the personnel required to plan, organise, acquire, implement, deliver, support, monitor and evaluate the information
systems and services. They may be internal, outsourced or contracted as required.
Maturity Models
Maturity modelling for management and control over IT processes is based on a method of self-evaluation by the enterprise.
A maturity model has been defined for each of the 34 COBIT IT processes, providing an incremental measurement scale from 0,
non-existent, through 5, optimised. Using the maturity models developed for each IT process, management can identify:
• The actual performance of the enterprise—Where the enterprise is today
• The current status of the industry—The comparison
• The enterprise’s target for improvement—Where the enterprise wants to be
The maturity attributes list the characteristics of how IT processes are managed and describes how they evolve from a non-existent to
an optimised process. These attributes can be used for more comprehensive assessment, gap analysis and improvement planning. The
maturity attributes are:
• Awareness and communication
• Policies, plans and procedures
• Tools and automation
• Skills and expertise
• Responsibility and accountability
• Goal setting and measurement
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
15
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
COBIT Cube
The previously mentioned components (IT processes, business requirements of information and resources) are three-dimensional,
thus illustrating the IT function. These dimensions, shown in figure 3, represent the COBIT cube. The COBIT components
interrelate, as shown in figure 4.
Figure 3—COBIT Cube
Business Requirements
e
ss
y
ity
ty
lity
nc
ne ienc ntial grity abili
lia liabi
l
c
e
p
i
e
i
t
f
a
d
m
In
Ef onfi
Re
Av
Co
C
Information
Applications
IT Processes
DOMAINS
PROCESSES
People
Ef
Infrastructure
ve
ti
fec
ACTIVITIES
s
rce
u
so
Re
IT
Source: COBIT 4.1, figure 22—The COBIT Cube, p.25
Figure 4—Interrelationships of COBIT Components
Business
Goals
requirements
information
IT Goals
IT Processes
nto
ni
bro
for outcome
Outcome
Measures
oll
ed
by
derived
from
Control
Objectives
imp
ith
lem
dw
e
dit
ity
Performance
Indicators
ntr
tur
Responsibility
and
Accountability
Chart
p
co
ma
for
Control
Outcome
Tests
for
rf
pe
m
for
er
a
orm
y
e
nc
ur
as
e
m
Key
Activities
b
ed
y
b
ed
audited with
n
ke
w
do
au
Control
Design
Tests
Maturity
Models
based on
Source: COBIT 4.1, Figure 4—Interrelationships of COBIT Components, p. 8
16
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
ent
ed
wit
h
Control
Practices
2. COBIT
The IT processes and control objectives, activity goals, outcome measures, performance indicators and maturity models are
documented in COBIT 4.1. For more information, refer to the appendix, ISACA Professional Guidance Publications.
Further References
Internet
ISACA
www.isaca.org/cobit
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
17
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
3. COSO
Document Taxonomy
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control—Integrated Framework is
a report that consists of four volumes. It is dedicated to improving the quality of financial reporting and ethics through effective
internal control.
Issuer
The report was issued by COSO, which is a voluntary, private-sector organisation. The committee was formed in 1985 to sponsor
an initiative of the US National Commission on Fraudulent Financial Reporting to study causal factors that can lead to fraud. The
sponsoring organisations are the American Accounting Association, American Institute of Certified Public Accountants, Financial
Executives Institute, Institute of Internal Auditors and Institute of Management Accountants.
Goal of the Guidance
The goal is to improve the ways of controlling enterprises by defining an integrated control system. It enables senior executives
to put internal controls in place to assure the achievement of the mission and profitability goals and manage risk. It is the most
comprehensive study on internal control.
Business Driver for Implementing the Guidance,
Including Typical Situations
COSO is usually implemented subject to one or more of the following business areas:
• Need for a structured approach when defining a control system
• Improvement of the efficiency of internal controls
• Assessment and evaluation of the internal controls
• Need to structure the internal controls
• Guideline for reporting to external parties, such as enterprises required to comply with the US Sarbanes-Oxley Act
Related Risk of Not Implementing the Guidance
Risk of not implementing COSO includes:
• Non-systematic approach for controls
• Incomplete controls
• Weak control environment
• Inefficient controls
• Inadequate processes and reporting due to a lack of controls
Target Audience
The responsible parties for internal control are addressed by the guidance. They range from senior management, boards of directors
and internal auditors to every individual in the enterprise.
The level of detail primarily depends on the role of the function. If the function is responsible to fulfill the requirements, thorough
knowledge should be ensured, but if the function is accountable or involved otherwise (consulted or informed), an overview should
be applicable. The level is indicated in figure 5.
18
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
3. COSO
Figure 5—Chart of COSO Audiences
Head of Operations
Chief Architect
O
T
O
O
Compliance, Audit, Risk and Security
Business Process Owner
O
Project Management Office
Chief Information Officer (CIO)
T
Head of IT Administration
Business Executive
O
Head of Development
Chief Financial Officer (CFO)
COSO
Chief Executive Officer (CEO)
Functions: Thorough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
Timeliness
COSO published Internal Control—Integrated Framework in 1992, but the content is still up to date.
Certification Opportunities
There is no opportunity for a certification.
Circulation
The report is referenced as the international baseline for internal control systems; however, it is available in English only.
Completeness
The report covers the topic of controls in a comprehensive manner. As it is focused on a management and control framework point
of view, it may be seen as an additional reference for a framework for IT governance efforts. It is on a very high level and does not
address IT requirements in a comprehensive manner, but its key concepts and definitions may be applied to control and management
of diversified IT issues.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
19
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
COBIT Processes Addressed
As mentioned previously, the COSO report is focused on internal controls and is not IT-specific. Thus, the mapping is on a higher
level than other guidance in this document.
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT 4.1 processes addressed by
COSO Internal Control—
Integrated Framework
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
Information Criteria Addressed
Information Criteria
+
+
+
+
+
+
+
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
+
+
20
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
3. COSO
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MANENT
FOR
PER SUREM
MEA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
C
GI T
TE EN
A
M
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The report consists of four volumes:
• Executive Summary gives a high-level overview of the framework of internal control. The executive summary is also included
in Framework.
• Framework defines the framework of internal control and its components and contains criteria to assess the internal control system
of the enterprise.
• Reporting to External Parties provides guidance to establish reports in a properly controlled manner. It is addressed to enterprises
that publish their financial statements and to entities receiving those statements.
• The fourth volume, Evaluation Tools, consists of material that might be useful for an evaluation of the internal control system.
Framework is the core part of the report in terms of establishing and maintaining an internal control system for corporate and IT
governance; consequently, its content is discussed in a higher level of detail.Framework contains the executive summary as an
abstract of its content. After the summary, the key concepts and meanings are defined to enable a common understanding of internal
control issues.
COSO defines internal control as follows:
Internal control is a process, effected by an entity’s board of directors, management and other personnel, designed to
provide reasonable assurance regarding the achievement of objectives in the following categories:
• Effectiveness and efficiency of operations
• Reliability of financial reporting
• Compliance with applicable laws and regulations
Internal control is to be built into the entity’s processes. Control is part of them and not an isolated activity, event or circumstance.
The guidance reports that there are five components that form internal control. The way they interrelate, interact and how they
influence the objectives of the enterprise constitute the system of internal control. The system of internal control is individual to
an enterprise; in other words, no two entities have the same system of internal control. It depends on the size of the enterprise, the
industry, and the culture and management philosophy.
The components of the system are:
• Control environment—The environment in which people operate. People are seen as the core of any business, and people have
individual attributes as ethical values or competences.
• Risk assessment—The awareness of risk is a crucial factor for the organization to set objectives. Risk is to be identified, analysed
and managed in an appropriate manner.
• Control activities—Policies and procedures are to be established for sound management of risk and to achieve the objectives
defined by the organization. The policies and procedures define the activities that have to be executed.
• Information and communication—Information and communication systems are used to manage the process. Those systems
enable people to carry out their responsibilities, including control activities.
• Monitoring—The process has to be monitored permanently. Possibilities for modifications are to be unveiled and implemented in a
timely manner.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
21
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
The objectives of an enterprise can be divided into three categories:
• Operations
• Financial reporting
• Compliance
An effective internal control system helps an enterprise:
• Achieve its objectives
• Publish reliable financial statements
• Comply with applicable laws and regulations
Further References
Internet
COSO
www.coso.org
AICPA Store
www.cpa2biz.com
22
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
4. ITIL® V3
4. ITIL® V3
Document Taxonomy
ITIL V3 is a set of five core books plus a number of complementary publications. It is referred to as the only consistent and
comprehensive best practice for IT service management to deliver high-quality IT services. ITIL is developed by the Office of
Government Commerce, part of the UK Government, and is published under license by TSO. ITIL is not a standard, although there
is an associated standard, ISO/IEC 20000, which is based on ITIL. The books are titled:
• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvement
• Official Introduction to the ITIL Service Lifecycle
Issuer
This mapping publication focuses on the five core books. The ITIL collection was first published by the Central Computer and
Telecommunications Agency (CCTA), now the British Office of Government Commerce (OGG), which holds the ITIL copyright and
trademark. The CCTA was commissioned to develop a methodology for efficient and effective use of IT resources within the British
government. ITIL V3, which was published in 2007, is the latest version of ITIL.
Goal of the Guidance
The goal is the development of a vendor-independent approach for service management. The ethos behind the development was the
recognition of increased dependence on IT service, which has to be managed by high-quality processes throughout the lifecycle of
the service.
Business Driver for Implementing the Guidance,
Including Typical Situations
ITIL is usually implemented subject to one or more of the following drivers:
• Service processes within an enterprise’s IT function or within a service provider’s organisation need to be defined.
• The quality of services needs to be defined and improved.
• There is a need to focus on the customer of the IT services.
• There is a need to implement specific IT service management tasks such as creation of a service desk function and service level,
incident, problem, and availability management.
• It is necessary to mitigate the risk of implementing a service management system that does not work (right away).
• The predictability of services and service delivery (warranty) needs improvement.
Related Risk of Not Implementing the Guidance
Risk of not implementing ITIL includes:
• Inefficient services provided to users and customers
• Unclear services and processes
• Inefficient and ineffective communication of service delivery objectives
• Lack of common language for IT service delivery and service support
• Inappropriate priority given to different services provided
• Dissatisfaction of users and customers with services provided
• Ineffective planning and maintenance of services and required resources
• Misalignment of IT services and business requirements
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
23
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Target Audience
The level of detail primarily depends on the role of the function. If the function is responsible to fulfil the requirements, thorough
knowledge should be ensured, but if the function is accountable or involved otherwise (consulted or informed), an overview should
be applicable. The level is indicated in figure 6.
Figure 6—Chart of ITIL V3 Audiences
Project Management Office
Compliance, Audit, Risk and Security
O
O
T
O
O
O
O
O
O
O
O
O
T
O
O
O
O
O
T
O
O
O
O
O
O
T
T
Service Transition
O
O
O
T
Service Operation
O
T
Continual Service Improvement
T
O
O
Service Strategy
O
O
Service Design
Business Executive
O
ITIL V3
Chief Financial Officer (CFO)
O
Chief Executive Officer (CEO)
Head of Development
O
Chief Architect
O
Head of Operations
O
Business Process Owner
O
Chief Information Officer (CIO)
Head of IT Administration
Functions: Thorough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
Timeliness
ITIL V1 (focused on managing technology) was created in the 1980s and ITIL V2 (focused on implementing service management
processes) in the 1990s. The ITIL V3 publications were released in mid-2007 following a wide consultation with users of ITIL.
Certification Opportunities
Individuals can get certification against ITIL V3. There are four levels:
• Foundation
• Intermediate
• Expert
• Master
Circulation
ITIL is used internationally and is available in several languages.
Completeness
The ITIL books examine and describe IT service management processes in extensive detail (more than 1,500 pages). ITIL V3 covers
the full life cycle of the management of ITIL services, including strategy and continual service improvement. It does not attempt to
cover the entire breadth of IT technology management or IT governance.
24
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
4. ITIL® V3
ITIL comprehensively describes most of the processes, which are also described in the COBIT Deliver and Support (DS) domain.
Processes of the Plan and Organise (PO), Acquire and Implement (AI) and Monitor and Evaluate (ME) domains are partially
covered, with the focus on services.
Availability
ITIL V3 is available for purchase in paperback and also for online access via OGC’s publishers, The Stationery Office (TSO),
at www.best-management-practice.com.
COBIT Processes Addressed
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
ITIL
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Information Criteria Addressed
Information Criteria
+
+
o
o
o
-
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
o
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
25
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MAN NT
E
FOR
PER NAGEM
MA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
IC
EG NT
AT ME
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The five core books of ITIL V3 are:
• Service Strategy (SS)—Covers the strategic planning of service management capabilities and the alignment of service and business
strategies. Furthermore, it provides guidance on value creation, market and offerings strategies, structure of services, types of
service providers, organisational development, sourcing, and financial management. It outlines four key processes: demand
management, strategy generation, service portfolio management and IT financial management.
• Service Design (SD)—Outlines the design and development approach of services and service management processes. Processes
covered by this volume are service catalogue management, service-level management, capacity, availability, IT service continuity
management, information security management, and supplier management. It identifies availability management, capacity
management, continuity management and security management as key elements used in the design of the services to be provided.
• Service Transition (ST)—Illustrates how the requirements of previous stages (strategy and design) are realised and how capabilities
for the ongoing delivery of a service can be maintained. The processes covered are transition planning and support, change
management, service asset and configuration management, release and deployment management, service validation and testing, and
evaluation and knowledge management.
• Service Operation (SO)—Covers the effective and efficient delivery and support of services, and provides a benchmarked approach
for event management, incident management, request fulfillment, problem management and access management. It also provides
references to operational activities in other processes.
• Continual Service Improvement (CSI)—Covers ongoing improvement of the service and the measurement of process performance
required for the service. There are three key areas: service measurement, service reporting and service improvement. The principles
of CSI are covered in a seven-step improvement process.
The processes described in ITIL V3 follow a mostly similar structure:
• Purpose, goals and objective
• Scope
• Value to the business
• Policies, principles and basic concepts
• Process activities, methods and techniques
• Triggers, inputs, outputs and (interprocess) interfaces
• Key performance indicators (KPIs) or metrics
• Challenges, critical success factors (CSFs) and risk
26
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
4. ITIL® V3
Figure 7—Service Life Cycle Governance and Operational Elements
Service Lifecycle Governance Processes
Continual Service Improvement
Processes
Service Lifecycle Operational Processes
Service Strategy Processes
Service Design Processes
Service Transition Processes
Service Operation Processes
Demand Management
Strategy Generation
Service Portfolio Management
IT Financial Management
Service Catalogue Management
Service Measurement
Service Level Management
Capacity Management
Availability Management
Service Continuity Management
Information Security Management
Supplier Management
Transition Planning and Support
Service Reporting
Change Management
Service Asset and Configuration Management
Release and Deployment Management
Service Validation and Testing
Evaluation
Knowledge Management
Event Management
Service Improvement
Incident Management
Request Fulfilment
Problem Management
Access Management
Operation Management
Source: ITIL V3, Official Introduction to the ITIL Service Lifecycle, figure 10.2 produced by OGC. Reprinted with permission from OGC.
Further References
Internet
OGC
www.ogc.gov.uk
Best Management Practice www.best-management-practice.com
ITIL
www.itil-officialsite.co.uk
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
27
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
5. ISO/IEC 17799:2000
Note: ISO/IEC 17799:2000 and ISO/IEC 17799:2005 were superceded by ISO/IEC 2700x.
Document Taxonomy
ISO/IEC 17799:2000 Code of Practice for Information Security Management is an international standard.
Issuer
The international standard was published by the International Organization for Standardisation (ISO) and International
Electrotechnical Commission (IEC), which established a joint technical committee, ISO/IEC JTC 1. The historic source for the
standard was BS 7799-1, which contributed essential parts to ISO/IEC 17799:2000. It was developed and published by the British
Standards Institution (BSI), labelled as BS 7799-1:1999. The original British Standard was issued in two parts:
• BS 7799 Part 1: Information Technology—Code of Practice for Information Security Management
• BS 7799 Part 2: Information Security Management Systems—Specification with Guidance for Use
Goal of the Guidance
The goal of ISO/IEC 17799:2000 is to provide a code of practice. As such, it offers guidelines and voluntary directions for
information security management. It is meant to provide a high-level, general description of the areas currently considered important
when initiating, implementing or maintaining information security in an enterprise.
Business Driver for Implementing the Guidance,
Including Typical Situations
Business drivers for implementing the guidance are:
• Defining an information security management system and applying best practice in security management based on a
systematic approach
• Identifying critical assets via the business risk assessment
• Enhancing the knowledge and importance of security-related issues at the management level
• Defining responsibility and organizational structures for information security
• Need for a basis for certification of the information security management system
• Need for contractual relationships
• Protection of the confidentiality, integrity and availability of the corporate information assets. Those security requirements may be
essential to maintain competitive edge, profitability, legal compliance and commercial image.
Related Risk of Not Implementing the Guidance
Related risk of not implementing the guidance include:
• Information disclosure, alteration, deletion or unavailability, including related risk such as loss of customers’ confidence and trust,
reputation, and competitiveness
• Incomplete risk assessment, thus an inadequate level of risk management
• Inadequate business continuity management
• Lack of security awareness within the enterprise
• Inadequate security requirements when interacting with third-party organizations
• Inadequate level of physical and logical security
• Flawed procedures due to the lack of incident management
• Breach of statutory, regulatory or legal obligation, such as protection of private data
• Inappropriate use of corporate resources
28
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
5. ISO/IEC 17799:2000
Target Audience
The document targets people responsible for information security within enterprises willing to initiate, implement or maintain
information security. The level of detail primarily depends on the role of the function. If the function is responsible to fulfil the
requirements, thorough knowledge should be ensured, but if the function is accountable or involved otherwise (consulted or
informed), an overview should be applicable. The level is indicated in figure 8.
Figure 8—Chart of ISO/IEC 17799:2000 Audiences
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
ISO/IEC 17799:2000
Chief Information Officer (CIO)
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
O
O
O
O
O
T
Timeliness
The first edition of the standard was published in 2000 and, along with COBIT, is the basis of this publication. The second edition
was released in 2005. As an official ISO standard, it will automatically be revised and updated when required every three to five
years. ISO plans to include the standard in the ISO 2700x series, Information Security Management System, in April 2007. The
standard can be classified as current best practice in the subject area of information security management systems. The originating
BS 7799-1 was revised in 2000, and BS 7799-2 was issued in September 2002.
Certification Opportunities
A certification for ISO/IEC 17799:2000 is not available. However, a certificate of compliance with BS 7799-2 can be obtained, as
BS 7799-2 contains binding specifications for a certification of an information security management system, as well as normative
controls.
Circulation
The standard is used worldwide, and several countries have published local versions.
Completeness
Generic measures for information security management are provided, as well as the imperative of compliance with laws and
regulations.
The standard is focused on security issues and does not cover the full scope of IT management duties. The level of detail is
comparable to COBIT.
Availability
The standard can be purchased from ISO and from most local standardisation bodies.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
29
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
COBIT Processes Addressed
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
ISO/IEC 17799:2005
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
Information Criteria Addressed
Information Criteria
+
+
+
+
o
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
o
+
30
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
5. ISO/IEC 17799:2000
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MANENT
FOR
PER SUREM
MEA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
C
GI T
TE EN
A
R M
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The guiding principles are the initial point when implementing information security. They rely on either legal requirements or
generally accepted best practices.
Measures based on legal requirements are (among others):
• Protection and non-disclosure of personal data
• Protection of internal information
• Protection of intellectual property rights
Best practices mentioned are:
• Information security policy
• Assignment of responsibility for information security
• Problem escalation
• Business continuity management
When implementing a system for information security management, several critical success factors should be considered:
• The security policy, its objectives and its activities reflect the business objectives.
• The implementation considers cultural aspects of the enterprise.
• Open support and engagement of senior management are required.
• Thorough knowledge of security requirements, risk assessment and risk management is required.
• Security targets all personnel, including management.
• Security policy and security measures are communicated to contracted third parties.
• Users are trained in an adequate manner.
• A comprehensive and balanced system for performance measurement is available, which supports continuous improvement by
giving feedback.
After presenting introductory information (scope, terms and definitions), guidance for initiating, implementing and maintaining
information security is provided. The guidance is structured into 10 sections, which contain 36 objectives.
Information security should—following the standard—at least consider the following parts (the numbers in the brackets refer to the
clauses of the international standard):
• Security policy (3)
– An information security policy should define the direction and contain the commitment and the support of management.
– The policy should be regularly reviewed for effectiveness, efficiency and change of the corporate risk pattern.
• The policy should define organisational security (4).
– The definition of adequate organisation structures for the management of information security within the enterprise should include:
. A management information security forum
. A forum for co-ordination
. Assignment of responsibility for information security to individuals
. Definition of responsibility areas for managers
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
31
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
. Definition of an authorisation process for IT facilities
. Definition of responsibility for investigation of security-relevant know-how
. Defined range for co-operation with third parties as well as independent security reviews
– Comprehensive measures should exist for management of third-party services (definition or risk and security requirements).
– Risk caused by outsourcing contracts should be managed.
• Asset classification and control (5)
– The inventory of assets and the assignment of the responsibility should be seen as prerequisites to sound accountability for assets.
– Information should be classified following a generally accepted system, thus ensuring an appropriate level of protection.
• Personnel security (6)
– Security responsibilities, confidentiality agreements and the contract of employment should be part of the job responsibility, for
staff and third-party users.
– Adequate controls for personnel screening should be in place.
– Information security education and training should increase users’ security awareness.
– The process of reporting security incidents, weaknesses and software malfunctions should be defined. This should include the
assessment of the adequacy of the controls implemented by a permanent process of learning from incidents.
– Fair disciplinary processes should be defined and published.
• Physical and environmental security (7)
– Central equipment should be installed only within a secure area, where adequate physical access controls and damage prevention
are implemented. These areas include offices, rooms and facilities. There is also a need for special attention to delivery and
loading areas.
– Equipment should be protected against loss, damage or compromise by being sited and protected in an appropriate manner. Power
supplies, an adequate level of cabling security and correct maintenance of equipment should be in place.
–E
quipment installed off premises and disposal or reuse of information should be considered.
– General controls (such as a clear desk and clear screen policy and a removal of property policy) to protect information processing
facilities or to prevent damage caused by unauthorised offsite usage of equipment should be in place.
• Communications and operations management (8)
– Operations should follow documented procedures.
– All changes to equipment should be documented.
– Procedures for sound incident management should be defined.
– Duties should be segregated, ensuring no individual can both initiate and authorise an event.
– Development, test and operational facilities and activities are to be separated.
– Risk caused by contracted external facilities organisations should be covered.
– Capacity demands should be observed and future demands should be projected.
– Acceptance criteria for new and upgraded systems should be defined.
– Damage caused by malicious software should be prevented, using preventive and detective controls, formal policies and defined
recovery procedures.
– Information should be backed up and the backup files tested regularly.
– Activities performed by operational staff and errors should be logged and reviewed.
– Networks should be set up and managed with a view to ensuring the necessary level of security, including safeguards from
public networks.
– Removable media should be handled with special care.
– Media with sensitive information should be disposed of in a secure manner.
–A
dequate controls in information handling procedures (e.g., labelling of media, ensuring completeness of inputs, and storage of
media) should be considered.
– System documentation is to be protected, as it may contain sensitive information.
– Agreements for the exchange of information and software should be established, including media in transit, electronic commerce
transactions, electronic mail, electronic office systems, publicly available systems and other forms of information interchange
(such as fax, video conference and phones).
• Access control (9)
– Access to information should be granted in accordance with business and security requirements on a need-to-know basis.
– A formal access control policy should be in place.
– Access control rules should be specified.
– User access management (registration, privilege management, password management, review of user access rights) should follow
a formal process.
– Responsibilities of users should be clearly defined, documented, published and enforced.
– Networked services, operating systems and applications should be protected appropriately.
– System access and use should be monitored constantly.
32
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
5. ISO/IEC 17799:2000
– Mobile computing and teleworking should be performed in a secure manner, with dedicated security mechanisms commensurate
with the specific risk.
• Systems development and maintenance (10)
– Security requirements should be taken into account as part of the business requirement analysis for new and upgraded systems.
– Security in application systems should take into account the validation of input data, adequate controls of internal processing,
message authentication and output data validation.
– Use of cryptographic systems should follow a defined policy. Related key management procedures should be implemented.
– Access to system files (including test data and source libraries) should be controlled.
– Project and support environments should allow for security by being rigorously controlled (e.g., change management procedures
and arrangements for outsourced development).
• Business continuity management (11)
– A comprehensive business continuity management process should permit prevention of interruptions to business processes.
– The business continuity management process should not be restricted to IT-related areas and activities.
–A
n impact analysis should be executed and result in a strategy plan.
– Business continuity plans should be developed following a single framework.
– Business continuity plans should be tested, maintained and reassessed continuously.
• Compliance (12)
– Relevant legal requirements should be identified and followed.
– Any unlawful act (e.g., breach of data protection acts) should be avoided.
– Compliance with the security policy should be ensured by periodic reviews.
The 36 objectives stated in ISO/IEC 17799:2000 are listed in figure 9.
Figure 9—ISO/IEC 17799:2000 Objectives
Section Title
Objective
3.1 Information security policy
To provide management direction and support for information security
4.1 Information security infrastructure
To manage information security within the organisation
4.2 Security of third-party access
To maintain the security of organisational information processing facilities and information assets
accessed by third parties
4.3 Outsourcing
To maintain the security of information when the responsibility for information processing has been
outsourced to another organisation
5.1 Accountability for assets
To maintain appropriate protection of organisational assets
5.2 Information classification
To ensure that information assets receive an appropriate level of protection
6.1 Security in job definition and resourcing
To reduce the risk of human error, theft, fraud or misuse of facilities.
6.2 User training
To ensure that users are aware of information security threats and concerns and are equipped to
support organisational security policy in the course of their normal work
6.3 Responding to security incidents and
malfunctions
To minimise the damage from security incidents and malfunctions, and to monitor and learn from
such incidents
7.1 Secure areas
To prevent unauthorised access, damage and interference to business premises and information
7.2 Equipment security
To prevent loss, damage or compromise of assets and interruption to business activities
7.3 General controls
To prevent compromise or theft of information and information processing facilities
8.1 O
perational procedures and
responsibilities
To ensure the correct and secure operation of information processing facilities
8.2 System planning and acceptance
To minimise the risk of systems failures
8.3 Protection against malicious software
To protect the integrity of software and information
8.4 Housekeeping
To maintain the integrity and availability of information processing and communication services
8.5 Network management
To ensure the safeguarding of information in networks and the protection of the supporting
infrastructure
8.6 Media handling and security
To prevent damage to assets and interruptions to business activities
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
33
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Figure 9—ISO/IEC 17799:2000 Objectives (cont.)
Section Title
Objective
8.7 Exchanges of information and software
To prevent loss, modification or misuse of information exchanged between organisations
9.1 Business requirement for access control
To control access to information
9.2 User access management
To prevent unauthorised access to information systems
9.3 User responsibilities
To prevent unauthorised user access
9.4 Network access control
Protection of networked services
9.5 Operating system access control
To prevent unauthorised computer access
9.6 Application access control
To prevent unauthorised access to information held in information systems
9.7 Monitoring system access and use
To detect unauthorised activities
9.8 Mobile computing and teleworking
To ensure information security when using mobile computing and teleworking facilities.
10.1 Security requirements of systems
To ensure that security is built into information systems.
10.2 Security in application systems
To prevent loss, modification or misuse of user data in application systems.
10.3 Cryptographic controls
To protect the confidentiality, authenticity or integrity of information.
10.4 Security of system files
To ensure that IT projects and support activities are conducted in a secure manner.
10.5 S ecurity in development and support
processes
To maintain the security of application system software and information.
11.1 A spects of business continuity
management
To counteract interruptions to business activities and to protect critical business processes from
the effects of major failures or disasters.
12.1 Compliance with legal requirements
To avoid breaches of any criminal and civil law; statutory, regulatory or contractual obligations; and
of any security requirements.
12.2 R
eviews of security policy and
technical compliance
To ensure compliance of systems with organisational security policies and standards.
12.3 System audit considerations
To maximise the effectiveness of and to minimise interference to/from the system audit process.
Reprinted with permission from ISO. A copy of the International Standard can be obtained at www.iso.org.
Further References
Internet
ISO
www.iso.org
IEC
www.iec.org
BSI
www.bsi-global.co.uk
34
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
6. ISO/IEC 17799:2005
6. ISO/IEC 17799:2005
Note: ISO/IEC 17799:2000 and ISO/IEC 17799:2005 were superceded by ISO/IEC 2700x.
Document Taxonomy
ISO/IEC 17799:2005 Code of Practice for Information Security Management is an international standard.
Issuer
The international standard was published by ISO and the International Electrotechnical Commission (IEC), which established a joint
technical committee, ISO/IEC JTC 1. The historic source for the standard was BS 7799-1, of which essential parts were taken in
the development of ISO/IEC 17799:2005 Information Technology—Code of Practice For Information Security Management. It was
developed and published by the British Standards Institution (BSI), labeled as BS 7799-1:1999. The original British Standard was
issued in two parts:
• BS 7799 Part 1: Information Technology—Code of Practice for Information Security Management
• BS 7799 Part 2: Information Security Management Systems—Specification With Guidance for Use
Goal of the Guidance
The goal of ISO/IEC 17799:2005 is to provide information to parties responsible for implementing information security within an
enterprise. It can be seen as a best practice for developing and maintaining security standards and management practices within an
enterprise to improve reliability on information security in interorganisational relationships. It defines 133 security controls strategies
under 11 major headings. The standard stresses the importance of risk management and makes it clear that one does not have to
implement every stated guideline, only those that are relevant.
Business Driver for Implementing the Guidance,
Including Typical Situations
Business drivers for implementing ISO/IEC 17799:2005 include:
• Definition of an information security management system, applying best practice in security management based on a
systematic approach
• Identification of critical assets, including information assets, via the business risk assessment
• Enhancement of the knowledge and importance of security-related issues at the management level
• Definition of responsibility and organizational structures for information security
• Need for a basis for certification of the information security management system
• Need for contractual relationships
• Reduction of trade/e-trade barriers due to its international acceptance
Related Risk of Not Implementing the Guidance
Related risk of not implementing ISO/IEC 17799:2005 includes:
• Risk of information disclosure, including related risk such as loss of confidence and trust
• Incomplete risk assessment and, thus, an inadequate level of risk management
• Inadequate business continuity management
• Lack of security awareness within the enterrprise
• Inadequate security requirements when interacting with third-party organisations
• Inadequate level of physical and logical security
• Flawed procedures due to the lack of incident management
• Inadequate security controls coverage in outsourcing/contractual arrangements
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
35
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Target Audience
The level of detail primarily depends on the role of the function. If the function is responsible to fulfill the requirements, thorough
knowledge should be ensured, but if the function is accountable or involved otherwise (consulted or informed), an overview should
be applicable. The level is indicated in figure 10.
Figure 10—Chart of ISO/IEC 17799:2005 Audiences
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
ISO/IEC 17799:2005
Chief Information Officer (CIO)
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: Thorough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
O
O
O
O
O
T
Timeliness
The first edition of the international standard was published in 2000, and the second edition was released in 2005. Since the current
version (ISO/IEC 17799:2005) is an official ISO standard, it will automatically be revised and updated when required every three to
five years. ISO plans to include the standard in the ISO 2700x series, Information Security Management System, in April 2007. The
standard can be classified as current best practice in the subject area of information security management systems. The originating
BS 7799-1 was revised in 2000, and BS 7799-2 was issued in September 2002.
Certification Opportunities
A certification for ISO/IEC 17799:2005 is now available. A certificate on compliance with BS 7799-2 can be obtained, as BS7799-2
contains binding specifications for a certification of an information security management system, as well as normative controls.
BS 7799-2:2002 was withdrawn when ISO/IEC 27001:2005 was issued on 15 October 2005. There are currently 287 ISO 27001
certifications—112 BS 7799-2:2002 upgrades and 175 new certifications (see www.iso27001certificates.com/Register%20Search.htm).
Circulation
The standard is used worldwide, and several countries have published local versions.
Completeness
Generic measures for information security management are provided, as well as the imperative of compliance with laws and
regulations.
The standard is focused on security issues and does not cover the full scope of IT management duties. The level of detail is
comparable to COBIT.
36
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
6. ISO/IEC 17799:2005
Availability
The standard can be purchased from ISO and most local standardisation bodies.
COBIT Processes Addressed
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
ISO/IEC 17799:2005
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
Information Criteria Addressed
Information Criteria
+
+
+
+
o
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
37
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MANENT
FOR
PER SUREM
MEA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
C
GI T
TE EN
A
R M
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The need for information security is based on the fact that information and related systems are important assets for enterprises. As
enterprises face information security threats, the protection of information is essential to maintain organisational stability.
Sources for the identification of security requirements are:
• Risk the enterprise faces and the impact on business strategy and objectives
• Legal requirements
• Specific requirements, principles and objectives for information processing to support business operations
Controls should be selected and defined considering:
• Legal requirements
• Business requirements
• Cost of implementation
• Potential impact of a security breach
When implementing a system for information security management, several CSFs should be considered to ensure:
• That the security policy, its objectives and its activities reflect the business objectives
• That the implementation considers cultural aspects of the enterprise
• Open support and engagement of senior management
• Thorough knowledge of security requirements, risk assessment and risk management
• That effective marketing of security targets all personnel, including members of management
• That the security policy and security measures are communicated to contracted third parties
• That sufficient and adequate funding is available
• That users are well trained
• That a comprehensive information security incident management process is established
• That a comprehensive and balanced system for performance measurement is available that supports continuous improvement by
giving feedback
After presenting introductory information (scope, terms and definitions) in chapters 1 to 3, chapter 4 briefly describes methods
for risk assessment and treatment wherein references to ISO/IEC TR 13335 are made. The guidance is structured into 11 sections
(security control chapters) that contain 39 main security categories.
The main security categories consist of a control objective and one or more controls to achieve the control objective. Guidance is
provided to implement controls, and references to further information are made. ISO chapters are listed in parentheses.
According to the standard, information security should consider at least the following parts:
• Security policy (5):
– An information security policy should define the direction and contain the commitment and support of management.
– The policy should be reviewed periodically and communicated throughout the enterprise.
38
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
6. ISO/IEC 17799:2005
• Organisation of information security (6):
– Information security should be supported by management; therefore, a demonstrated commitment should be made.
– Relevant activities should be co-ordinated throughout the enterprise, and responsibilities for information security should be
clearly defined.
– Confidentiality agreements should be in place.
– Appropriate contacts with authorities (e.g., fire department, law enforcement) and special interest groups (e.g., security forum)
should be maintained.
– Information security should be subject to independent review.
– Controls should be implemented to manage identified risk related to external parties (including customers).
– Outsourcing arrangements should address information security.
– An authorisation process for information processing facilities should be in place.
• Asset management (7):
–A
n inventory of assets and the assignment of responsibility for their protection should be made as a prerequisite to sound
accountability for assets.
– All assets should have a nominated owner, and the use of assets should be based on defined rules.
– Information should be classified and labelled following a generally accepted system, thus ensuring an appropriate level of protection.
• Human resources security (8):
– Security requirements for employees should be identified throughout the life cycle—prior to employment, during employment,
and upon termination or change of employment.
– Security responsibilities, confidentiality agreements and the contract of employment should be part of the job responsibility and
terms and conditions of employment.
– Adequate controls for personnel screening should be in place.
– Information security education and training should increase the security awareness of all employees.
– A formal disciplinary process should be in place for individuals who breach security policies.
– Rules for termination and change of employment should be defined and followed.
• Physical and environmental security (9):
– Central equipment should be installed only within a secure area (including offices, rooms and facilities) where adequate access
controls and damage prevention (against environmental factors and threats) are implemented.
– Equipment should be protected against loss, damage or compromise by being sited and protected in an appropriate manner. Power
supplies, an adequate level of cabling security and correct maintenance of the equipment should be in place.
– Equipment installed off premises and the disposal or reuse of information should be considered; authorisation for taking
equipment offsite is recommended.
– Special attention is needed in public access, delivery and loading areas where the central equipment is installed.
• Communications and operations management (10):
– Operations should follow documented procedures.
– All changes to facilities should be controlled.
– Duties should be segregated, ensuring that no individual can both initiate and authorise an event.
– Development and operational facilities are to be separated.
– Risk caused by contracted organisations should be covered and third-party services should be controlled.
– System planning and acceptance should consider capacity management and the definition of acceptance criteria.
– Damage caused by malicious software and mobile code should be prevented, using preventive and detective controls, formal
policies, and defined recovery procedures.
– Information should be backed up, and the backup files should be tested regularly.
– Networks and network services should be set up and managed with a view to ensuring the necessary level of security and
service levels.
– Removable media should be handled with special care.
– Media with sensitive information should be disposed of in a secure manner.
– Adequate controls in information handling procedures (e.g., labelling of media, ensuring completeness of inputs, storage of
media) should be considered.
– System documentation should be protected, as it may contain sensitive information.
– Agreements for the exchange of information and software should be established, including media in transit, e-commerce
transactions, e-mail, electronic office systems, publicly available systems and other forms of information interchange.
– E-commerce services and their use should be controlled.
– Security-relevant activities should be logged and monitored, and the effectiveness of controls should be assessed.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
39
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
• Access control (11):
– Access to information should be granted in accordance with business and security requirements.
– A formal access control policy should be in place.
– Access control rules should be specified.
– User access management (registration, privilege management, password management, review of user access rights) should follow
a formal process.
– User responsibilities concerning password use and protection of unattended equipment, as well as a clear desk and clear screen
policy, should be clearly defined.
– Networked services, operating systems and applications should be protected appropriately.
– System access and use should be controlled efficiently, considering secure logon procedures, user identification and
authentication, password management, usage of system utilities, and session time-out.
– Software and information access should be restricted to authorised users.
–M
obile computing and teleworking should be performed in a secure manner.
• Information systems acquisition, development and maintenance (12):
– Security issues should be considered when acquiring or implementing information systems following defined requirements;
security requirements should be specified.
– Security in application systems should take into account the validation of input data, adequate controls of internal processing,
message integrity and output data validation.
– Use of cryptographic systems should follow a defined policy and consider best practices.
– Security of and access to system files (including test data and program source code) should be controlled.
– Project and support environments should allow for security by being rigorously controlled (e.g., change management procedures,
arrangements for outsourced development, information leakage).
– Damage through published vulnerabilities should be prevented.
• Information security incident management (13):
– Security events and weaknesses should be reported.
– Responsibilities and procedures for managing security incidents and improvements should be defined, and evidence for security
incidents should be collected.
• Business continuity management (14):
– A comprehensive business continuity management process should permit prevention of interruptions to business processes.
– The business continuity management process should not be restricted to IT-related areas and activities.
– An impact analysis should be executed that results in a strategy plan.
– Business continuity plans should be developed following a single framework.
– Business continuity plans should be tested, maintained and reassessed continuously.
• Compliance (15):
– Relevant legal requirements should be identified and followed.
– Any unlawful act (e.g., violating data protection acts) should be avoided.
– Compliance with the security policy should be ensured by periodical reviews.
Further References
Internet
ISO
www.iso.org
IEC
www.iec.org
BSI
www.bsi-global.co.uk
40
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
7. ISO/IEC 20000
7. ISO/IEC 20000
Document Taxonomy
The ISO/IEC 20000 series consists of two publications: the Specification (ISO/IEC 20000-1:2005), which describes audit
requirements, and the Code of Practice (ISO/IEC 20000-2:2005), which provides further guidance for service providers.
Issuer
ISO/IEC 20000:200510 was issued jointly by ISO and IEC. ISO/IEC 20000:2005 Information technology—Service management
documents are available from the ISO web site at www.iso.org or any local standards body that is part of the ISO.
Goal of the Guidance
ISO/IEC 20000:2005 is the first worldwide standard specifically aimed at IT service management. It describes an integrated set of
management processes for the effective delivery of services to the business and its customers.
ISO/IEC 20000-2:2005 notes:
The ISO/IEC 20000 series enables service providers to understand how to enhance the quality of service delivered to
their customers, both internal and external.
With the increasing dependencies in support services and the diverse range of technologies available, service providers
can struggle to maintain high levels of customer service. Working reactively, they spend too little time planning, training,
reviewing, investigating, and working with customers. The result is a failure to adopt structured, proactive working
practices.
Those same service providers are being asked for improved quality, lower costs, greater flexibility, and faster response to
customers. Effective service management delivers high levels of customer service and customer satisfaction.11
Business Driver for Implementing the Guidance,
Including Typical Situations
Implementation and subsequent organisational certification is a means for service providers to demonstrate well-controlled
provisioning of IT services that is substantiated by an independent party. Certification demonstrates that a service provider is
effectively delivering its managed services to its customers and continually improving its service management. The quality of
services is assessed through service management processes, e.g., business relationship and service level management.
Related Risk of Not Implementing the Guidance
ISO/IEC 20000:2005 is not for everyone: Although the standard was written in such a fashion that all types of IT providers can
comply (internal or external, small or large), compliance can be difficult for some enterprises—especially if the effort is not fully
supported by the enterprise’s business objectives. The standard requires unwavering management commitment, and if management
and all other role players in the IT service chain do not commit to the requirements (and associated effort required to achieve
certification) of the standard, enterprises may find it difficult to achieve or maintain certification.
ISO/IEC 20000 is not intended for product assessment. However, enterprises developing service management tools, products and
systems may use all parts of ISO/IEC 20000 to help develop tools, products and systems that support internationally recognised
service management systems requirements and recommendations.
10
11
I SO, ISO/IEC 20000:2005 Information technology—Service management, Switzerland, 2005
Ibid.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
41
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Special Consideration for External Service Providers
ISO/IEC 20000:2005 requires that enterprises aspiring to achieve ISO/IEC 20000:2005 certification demonstrate ‘Management
Control’ over all the processes (clauses 3 to 10), and organisations should be well advised to address this issue first. The use of
the word ‘shall’ (as used in the standard) indicates a requirement. Requirements are not optional. Any enterprise that wishes to be
certified against ISO/IEC 20000-1 should check that it can define a suitable scope for the audit. Scope also needs to be defined as
part of planning for service management.
Target Audience
The primary and secondary audiences are indicated in figure 11.
Figure 11—Chart of ISO 20000
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
ISO/IEC 20000:2005
Chief Information Officer (CIO)
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
T
O
T
T
O
T
T
T
Timeliness
ISO/IEC 20000-1 was prepared by the British Standards Institution (BSI) (as British Standard [BS] 15000-1) and was adopted,
under a special ‘fast-track procedure’, by ISO/IEC Joint Technical Committee (JTC) 1, Information Technology, in parallel with its
approval by national bodies of ISO and IEC.
ISO/IEC 20000:2005 is the starting point for enhancements, extensions and other improvements that will make the standard
international in its approach and applicability. This includes harmonisation with other international standards. The next version was
scheduled to be updated by December 2010, but at the time of this publication, it has not been issued and is expected in the first
quarter of 2011.
As an international standard, ISO/IEC 20000:2005 is used and endorsed by local standards authorities worldwide.
Certification Opportunities
Certification of organisations is administered by registered certification bodies (RCBs) that conduct a major audit every three years
and surveillance audits at least yearly.
Circulation
As an international standard, ISO/IEC 20000 is used and endorsed by local standards authorities worldwide. Some local standards
such as BS 15000 and Australian Standard (AS 8018) are replaced by ISO/IEC 20000:2005.
42
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
7. ISO/IEC 20000
Completeness
ISO/IEC 20000:2005 is a service management standard and is largely based on quality management principles and de facto IT
service management good/best practice at the time the standard was defined. The standard is not intended to be substantially
comprehensive or to cover all aspects of an IT organisation; it is intended to cover all aspects of IT service management and only IT
service management.
COBIT Processes Addressed
The intent and use of ISO/IEC 20000:2005 is limited to the issue of IT service management—COBIT, on the other hand, is intended
as a control framework. It would be misleading to say that there is a definite one-on-one link between ISO/IEC 20000:2005 and
COBIT. Rather, this document describes touchpoints between processes defined in ISO/IEC 20000:2005 (intended to direct IT
service management initiatives) and COBIT (to direct governance and control initiatives). The mapping, thus, attempts to match the
content or activities described in ISO/IEC 20000:2005 processes and COBIT processes, not to equate processes described in both
ISO/IEC 20000:2005 and COBIT.
Plan and Organise
2 3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
ISO/IEC 20000:2005
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Information Criteria Addressed
Information Criteria
+
+
o
o
+
+
+
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
43
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MANENT
FOR
PER SUREM
MEA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
C
GI T
TE EN
A
M
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The ISO/IEC 20000 series enables service providers to understand how to enhance the quality of service delivered to their customers,
both internal and external.
With the increasing dependencies in support services and the diverse range of technologies available, service providers can struggle
to maintain high levels of customer service. Working reactively, they spend too little time planning, training, reviewing, investigating
and working with customers. The result is a failure to adopt structured, proactive working practices. Those same service providers
are being asked for improved quality, lower costs, greater flexibility and faster response to customers. Effective service management
delivers high levels of customer service and customer satisfaction.12
The ISO/IEC 20000 series draws a distinction between the best practices of processes, which are independent of organisational form
or size and organisational names and structures. The ISO/IEC 20000 series applies to both large and small service providers, and the
requirements for best practice service management processes do not change according to the organisational form that provides the
management framework within which processes are followed.
The Specification (ISO/IEC 20000-1:2005) will be used as the reference during an audit (it is the requirements to be met by
enterprises); this document’s focus is largely on ISO/IEC 20000-1:2005. In some instances in which the Specification did not state a
specific requirement, but in which it was felt that the Code of Practice addresses some core principles that, if not considered, would
make it very difficult to meet the requirements of the Specification (ISO/IEC 20000-1:2005), the Code of Practice
(ISO/IEC 20000-2:2005) was used as additional or supplementary material.
Both documents (the Specification and Code of Practice) are subdivided in equally numbered clauses. An overview of the structure
of both documents is as follows:
1. Introduction to the standard and its constitute parts (Specification and Code of Practice)
2. Terms and definitions
3. The management system, which also reiterates the need for management commitment and ownership of service management,
clause deals with:
3.1. Management responsibility
3.2. Documentation requirements
3.3. Competence awareness and training
4. The planning and implementing service management clause deals with planning, implementation and continual improvement based
on the Deming PDCA approach and consists of the following subclauses:
4.1. Plan service management, including the approach, events to be considered, scope and contents of plans, etc. (Plan)
4.2. Implementing service management and addressing some common project management principles and requirements for
implementations (Do)
4.3. Monitoring, measuring and reviewing not only the implementation, but the continued operation of service management in the
enterprise (Check)
4.4. Continually improve, including ensuring that continual improvement is underpinned by a policy and properly planned in its
own right (Act)
12
ISO, ISO/IEC 20000:2005 Information technology—Service management, Switzerland, 2005
44
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
7. ISO/IEC 20000
5. The planning and implementing new or changed services clause also requires that a number of considerations should be regarded
before changes to services and stresses the need for proper change controls of all changes to services.
6. Service delivery processes, including:
6.1. Service level management
6.2. Service reporting
6.3. Service continuity and availability management
6.4. Budgeting and accounting for IT services
6.5. Capacity management
6.6. Information security management (supplemented by the ISO/IEC 27000 series)
7. Relationship processes, including:
7.1. General considerations
7.2. Business relationship management
7.3. Supplier management
8. Resolution processes, including:
8.1. General background to how these processes work together
8.2. Incident management
8.3. Problem management
9. Control processes, including:
9.1. Configuration management
9.2. Change management
10. Release process
The most common route to achieving the requirements of ISO/IEC 20000 is via the use of ITIL practices. Service providers that wish
to demonstrate that they have adopted ITIL practices in an effective manner often adopt ISO/IEC 20000. For some years, the close
relationship between ITIL and ISO/IEC 20000 has benefited those that rely on them. However, ISO editorial rules mean that
ISO/IEC 20000 has to be written so that best practices other than ITIL can be used to achieve the requirements of ISO/IEC 20000.
As ITIL and ISO/IEC 20000 serve different purposes, there are some differences. For example, ISO/IEC 20000 has no requirements
that relate to organisational form, size, names or type. The ISO/IEC 20000 series applies to all service providers irrespective of
size, and the requirements for best practice service management processes do not change according to the organisational form that
provides the management framework within which processes are followed.
One of the objectives for the ITIL V3 project was to retain, and as appropriate, improve alignment to ISO/IEC 20000. There are
fewer differences between ISO/IEC 20000 and ITIL V3 than with ITIL V2. Changes from ITIL V2 to ITIL V3 include the service
life cycle approach in ITIL V3, which is a closer alignment to the service life cycle approach of ISO/IEC 20000.
The Service management system (clause 3) is the overarching system for integrated processes (all subsequent clauses). Planning
and implementing service management (clause 4) applies to all processes and specifically deals with Deming’s PDCA (continual
improvement of the system and the defined processes in the standard). Implementing new or changed services deals with how service
changes should be handled and also has an impact on all subsequent processes, which is illustrated in figure 12.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
45
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Figure 12—ISO/IEC 20000:2005 and Its Constitute Parts
Service Management System
Planning and Implementing Service Management (Plan, Do, Check, Act)
Planning and Implementing New and Changed Services
Service Delivery Processes
• Capacity Management
• Service Level
Management
• Service Continuity
and Availability
• Service Reporting
Management
• Information
Security
Management
• Budgeting and
Accounting
Control
Release
Processes
• Release
Management
• Configuration Management
• Change Management
Resolution Processes
• Incident
Management
• Problem
Management
Relationship Processes
• Business
Relationship
Management
• Supplier
Management
Source: ISO, ISO/IEC 20000:2005 Information technology—Service management, Switzerland, 2005. This figure is a modified version of figure 1 of ISO/IEC 20000-1:2005 and is
reused with permission from the American National Standards Institute (ANSI) on behalf of ISO.
Further References
Internet
ISO
www.iso.org
APMG-International
www.isoiec20000certification.com
46
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
8. NIST SP800-53 Rev 1
8. NIST SP800-53 Rev 1
Note: NIST SP800-53 Rev 1 was superceded by NIST 800-53 Rev 3.
Document Taxonomy
The US NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate
information security for all US federal agency operations and assets. The explicit goal is to assist federal agencies in implementing
the Federal Information Security Management Act (FISMA) of 2002 and in managing cost-effective programmes to protect their
information and information systems. The security controls defined in SP800-53 and recommended for use by enterprises in protecting
their information systems should be employed in conjunction with, and as part of, a well-defined information security programme.
Issuer
SP800 series documents have been issued since 1991. SP800-53, Recommended Security Controls for Federal Information Systems,
was first issued in February 2005, after a period of public discussion. The document was developed and has been issued under the
authority of FISMA, P.L. 107-347.
Goal of the Guidance
The purpose of SP800-53 is to provide guidelines for selecting and specifying security controls for information systems supporting
the executive agencies of the federal government. The guidelines apply to all components of an information system that process,
store or transmit federal information. The guidelines have been developed to help achieve more secure information systems within
the federal government by:
• Facilitating a more consistent, comparable and repeatable approach for selecting and specifying security controls for
information systems
• Providing a recommendation for minimum security controls for information systems categorised in accordance with Federal
Information Processing Standards (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems
• Promoting a dynamic, extensible catalogue of security controls for information systems to meet the demands of changing
requirements and technologies
• Creating a foundation for the development of assessment methods and procedures for determining security control effectiveness
Business Driver for Implementing the Guidance,
Including Typical Situations
The standard provides for mandatory controls applicable to all federal information systems other than those systems designated as
national security systems. As such, the standard serves a diverse federal audience of information systems and information security
professionals including:
• Individuals with information systems and information security management and oversight responsibilities (e.g., chief information
officers [CIOs], senior agency information security officers [ISOs], authorising officials)
• Individuals with information systems development responsibilities (e.g., programme and project managers)
• Individuals with information security implementation and operational responsibilities (e.g., information systems owners,
information owners, information systems security officers)
• Individuals with information systems and information security assessment and monitoring responsibilities (e.g., auditors, inspectors
general, evaluators, certification agents [CAs])
Compliance with the controls is measured using auditor guidance available in SP800-53A, Draft Special Publication 800-53A,
Guide for Assessing the Security Controls in Federal Information Systems (http://csrc.nist.gov/publications/drafts.html#sp800-53A).
Because the selection and employment of appropriate security controls for an information system are important tasks that can have
major implications on the operations and assets of an enterprise, commercial entities may find the use of this baseline will provide
guidance on adequate controls for protecting systems that support the operation and assets of the organisation.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
47
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Related Risk of Not Implementing the Guidance
For a federal agency, FISMA compliance in the form of aggregate scores is public information. Significant funding penalties can
occur from non-compliance.
Target Audience
The primary and secondary audiences are indicated in figure 13.
An additional secondary audience is information systems security officers, and additional primary audiences include:
• Senior agency information officers
• Designated authorising officers
• Inspector general
Figure 13—Chart of NIST SP800-53 Audiences
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
NIST SP800-53
Chief Information Officer (CIO)
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
O
O
O
O
O
T
Timeliness
The core content of NIST SP800-53 is under continuous revision through public discussion, with a commitment to a biennial review and
update cycle. Rev 1 contains relatively modest changes in a few notable areas from previous public draft versions of this publication:
• There have been several additions to the security control catalogue, reflecting new controls and control enhancements to provide
users with greater choices in supplementing their security control baselines.
• There have been some minor additions to the security control baselines reflecting an increased need for protection within federal
information systems and to better align the minimum security controls with current federal policy and recommended security practices.
• There have been some changes to the tailoring guidance for security control baselines reflecting environmental considerations and
the application of compensating controls.
• Chapters two and three have been expanded to include guidance on implementing security controls in external environments and
responding to information systems incidents.
• There have been two new appendices added to the publication providing;
– A two-way crosswalk from the security controls in SP800-53 to the NIST suite of security standards and guidelines
– Initial guidance on the application of SP800-53 to industrial control systems
Enhancements to SP800-53 at the time of this publication include SP800-53A, a 300-page document providing explicit control
assessment criteria for the controls documented in SP800-53.
Certification Opportunities
No certification opportunities are available at time of publication.
Circulation
The standard is mandatory for US federal systems that are not national security systems.
48
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
8. NIST SP800-53 Rev 1
Completeness
The SP800-53 criteria are designed to provide technically sound and broadly applicable sets of controls for information systems.
The criteria are intended to be sufficiently rich to satisfy the breadth and depth of security requirements derived from laws,
executive orders, directives, policies, regulations and organizational needs, to ensure the confidentiality, integrity and availability
of the information being processed, stored or transmitted. Whilst intended to be cost-effective, unlike COBIT it does not address
financial issues. However, its catalogue of security controls is intended to demonstrate compliance with a variety of governmental,
organizational or institutional security requirements, facilitating consistent and repeatable control design and measured effectiveness
in a consistent and repeatable manner.
Availability
The standard is readily available from the NIST web site. The document notes that it has been prepared for use by federal agencies,
and may be used by non-governmental enterprises on a voluntary basis. It is not subject to copyright.
COBIT Processes Addressed
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
NIST SP800-53
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Information Criteria Addressed
Information Criteria
o
+
+
+
+
o
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
0
+
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
49
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Governance Focus Areas Addressed
DE VALU
LIV E
ER
Y
E
ANC
ORM NT
PERFSUREME
MEA
IT GOVERNANCE
Primary
MAN RISK
AGEM
ENT
GIC
TE NT
RA NME
T
S IG
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The primary focus of NIST SP800-53 is on selection, implementation and assurance requirements of specific security controls as
part of an effective information security programme. The intent is to establish a normative baseline for risk management for federal
information processing systems. The guidance integrates with the other, extensive and often extremely detailed, standards and
guidelines published under the Special Publications and Federal Information Processing Standards series.
After introductory material, the guidance establishes the fundamental concepts associated with security control selection and
specification, including:
• Structural components and security family organisation
• Baseline controls
• Use of controls in enterprisewide information security programmes
• Use of controls in external environments
• Assurance principles for control effectiveness
• Ongoing maintenance of the controls and control baselines
The guidance next studies the process for selecting and specifying security controls. This is based upon a high-water mark impact
approach, described in FIPS 199. It also describes how to determine additional controls, and how to update the selected controls as
part of a continuous monitoring programme.
This guidance provides detailed security control selection and specification data, including explicit definitions and terms,
assurance requirements, a security catalogue, and also relationships between various NIST standards and controls and associated
control frameworks.
The NIST approach is very system/programme-centric, and follows an explicitly designed security life cycle, as shown in figure 14.
Considering the life cycle shown in figure 14, the service delivery and IT processes are, in some sense, an end; the framework
is designed to maximise ‘the extent to which someone who relies on a system can have confidence that the system meets its
specifications, i.e., that the system does what it claims to do and does not perform unwanted functions’—a formal definition of trust.
It is not intended as a comprehensive IT framework.
The NIST SP800-53 Framework
The security controls in the security control catalogue are organised in a tree-like structure. The first tier separates into three general
classes of security controls:
• Technical—Direct controls primarily implemented and executed by the information system through mechanisms contained in
hardware, software or firmware components of the system
• Managerial—Indirect controls that focus on the management of risk and the management of information systems security
• Operational—Direct controls that are primarily implemented and executed by people (as opposed to systems)
These are then broken into a total of 17 control families corresponding to these three classes.
50
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
8. NIST SP800-53 Rev 1
Figure 14—NIST Security Life Cycle
• After initial
system testing,
the system is
installed or fielded.
Suns
nce
ra
tio
n
pe
• The system is disposed of
once the transition to
a new computer
system is completed.
s/M
ai
• The system performs
the work for which
it was developed.
ntena
• The need for a
system is expressed,
and the system
purpose and
high-level
requirements are
documented.
ent
sm
on
Initiati
u
Imp
l em
en
ta
ti
es
ss
/A
on
Ac
q
• System is designed, purchased, programmed,
developed or otherwise constructed.
This phase often consists of other
ment
elop
defined cycles, such as the
v
e
n/D
system development cycle
tio
of the acquisition cycle.
isi
O
01523a
et (Disposal)
The NIST SP800-53 Control Families
Figure 15 summarises the classes and families in the security control catalogue and associated family identifiers.
Figure 15—NIST Security Control Classes, Families and Identifiers
Class
Family
Identifier
Management
Risk Assessment
RA
Management
Planning
PL
Management
System and Services Acquisition
SA
Management
Certification, Accreditation, and Security Assessments
CA
Operational
Personnel Security
PS
Operational
Physical and Environmental Protection
PE
Operational
Contingency Planning
CP
Operational
Configuration Management
CM
Operational
Maintenance
MA
Operational
System and Information Integrity
SI
Operational
Media Protection
MP
Operational
Incident Response
IR
Operational
Awareness and Training
AT
Technical
Identification and Authentication
IA
Technical
Access Control
AC
Technical
Audit and Accountability
AU
Technical
System and Communications Protection
SC
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
51
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Management Guidelines
The NIST SP800-53 document should be considered, not by itself, but in the context of the full library of NIST Special Publications
and Federal Information Processing Standards. For example, the authority document that mandates the use of the catalogue from
SP800-53 comes from FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, and states:
‘Federal agencies must meet the minimum security requirements as defined herein through the use of the security controls in
accordance with NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, as amended’.
Other elements in the SP800 library address topics ranging from broad management issues, such as security planning, security
engineering principles, control life cycle issues, integrating security into the capital planning programme, and security awareness
and training, to focused, technical specifications such as allowed block encryption modes, key management, Domain Name System
(DNS) deployment, radio-frequency identification (RFID) schema, and cell phone forensics.
Of particular note is SP800-100, Information Security Handbook: A Guide for Managers, a comprehensive guide that ‘summarises
and augments a number of existing NIST standards and guidance documents and provides additional information on related topics.
Such documents are referenced within appropriate subchapters’.
Maturity Models
SP800-53A describes maturity models for information systems security control environments, linking them to impact assessments
derived from the guidance from FIPS 199. Maturity modelling is based over both the presence and configuration of explicit,
auditable criteria as well as language based upon conventional Capability Maturity Model (CMM) approaches. The maturity model
has three (successful) levels of increasing rigour:
• Security controls in place; no obvious errors
• Security controls correctly implemented; operating as intended
• Security controls consistently applied on an ongoing basis with continuous improvement
Explicit language in the assessment provides for a determination of process maturity levels.
Control Practices
Control practices were developed for NIST SP800-53 programmatically as part of the FISMA Implementation Project
(http://csrc.nist.gov/sec-cert/). Input came from a variety of sources including NIST SP800-26, Security Self-Assessment Guide for
Information Technology Systems, US Department of Defense (DoD) Policy 8500, Director of Central Intelligence Directive (DCID)
6/3, ISO/IEC 17799, US Government Accountability Office (GAO) Federal Information System Controls Audit Manual (FISCAM),
and US Health and Human Services (HHS) Centers for Medicare and Medicaid Services (CMS) Core Security Requirements; and
these sources are subject to extensive public review by security professionals. The control practices provide a common baseline with
a high level of detail to ensure consistent, effective control implementation across federal entities.
Audit Guidelines
To achieve the desired goals and objectives, and to provide consistent reporting and oversight to the American public, each federal
entity must audit its procedures constantly and consistently, its reporting status quarterly and the overall programme assessment
annually. The audit guidelines in NIST SP800-53A describe actual assessment activities to be performed by external auditors,
identifying roles, responsibilities, mechanisms for assessment and appropriate metrics. Other NIST guidelines (NIST SP800-26,
Security Self-assessment Guide for Information Technology Systems, and NIST SP800-80, Guide for Developing Performance
Metrics for Information Security) provide a wealth of information for internal assessments.
Relationship to COBIT and the Federal Enterprise Architecture
As can be clearly seen in the graphic illustrating, COBIT processes addressed, the coverage mapping between NIST SP800-53 controls
and the COBIT controls and processes shows a great deal of overlap in some areas, and no overlap at all in others. The objectives of
the two documents are fairly different. COBIT intends to describe the generally accepted good practices for IT governance, control and
assurance, with the framework addressing a broad spectrum of IT processes. However, NIST SP800-53 is intended to provide a security
control catalogue, establishing consistency and auditability across various US federal enterprises. NIST SP800-53 is thus narrower and
more targeted in many areas than COBIT, and NIST can be more focused because of its more specific purpose.
52
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
8. NIST SP800-53 Rev 1
Further References
Internet
NIST SP800-53
http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf
FISMA Implementation Project http://csrc.nist.gov/sec-cert/
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
53
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
9. FFIEC
Document Taxonomy
The FFIEC IT Examination Handbook represents a collection of documents that can be classified as generally accepted best practice
for IT governance, control and assurance for financial institutions.
Issuer
The FFIEC is a formal US interagency body empowered to prescribe uniform principles, standards and report forms for the federal
examination of financial institutions by the Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance
Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC) and the
Office of Thrift Supervision (OTS) and to make recommendations to promote uniformity in the supervision of financial institutions.
In 2001, the Information Technology Subcommittee of the Task Force on Supervision (Information Technology Subcommittee),
composed of representatives from each of the FFIEC agencies, began revising the 1996 Handbook. The FFIEC agencies determined
that the most efficient way to accomplish the revision and to facilitate future revisions would be to release a series of topical
booklets, rather than one comprehensive handbook. This approach facilitates the update process because the individual booklets can
be revised as needed. Going forward, the FFIEC will update each booklet as warranted by changes in technology or by the evolution
of standards related to financial institution IT practices. Additional booklets will be developed as new topics emerge.
The FFIEC issued the initial 12 booklets that make up the FFIEC IT Examination Handbook over a period of approximately 18 months
ending in August 2004. Some of these booklets are: Business Continuity Planning, Development and Acquisition, Electronic Banking,
FedLine®, Information Security, IT Audit, IT Management, Operations, Outsourcing Technology Services, Retail Payment Systems,
Supervision of Technology Service Providers, and Wholesale Payment Systems. The booklets address significant changes in technology
since 1996 and incorporate a risk-based examination approach. The 1996 Handbook has been replaced by these booklets.
Goal of the Guidance
The FFIEC guidance is housed in the FFIEC InfoBase, which contains resource documents, audio presentations, and interactive
training material for FFIEC agency examiners. The FFIEC InfoBase concept was developed by the Task Force on Examiner
Education to provide field examiners in financial institution regulatory agencies with a quick source of introductory training and
basic information. The long-term goal of the InfoBase is to provide just-in-time training for new regulations and for other topics of
specific concern to examiners in FFIEC’s five member agencies.
Business Driver for Implementing the Guidance,
Including Typical Situations
The FFIEC IT Examination Handbook Booklets are usually consulted or referenced subject to one or more of the following
business cases:
• The US banking and finance industry needs guidance for information technology.
• Financial institutions need to understand IT compliance requirements.
• Financial institutions need to define the scope and universe of IT processes and related risk.
• Examiners/auditors need training and audit guidelines.
Related Risk of Not Implementing the Guidance
Risk of not implementing IT controls that meet FFIEC standards includes:
• A lack of understanding of IT compliance requirements and operational risk rooted in related IT risk for financial institutions
• A shortfall between management’s understanding and federal regulations/standards used by federal bank examiners
• Regulatory breaches with potential significant financial penalties on enterprises, restrictions on operating licenses, and fiduciary liability
and potential personal financial penalties on directors and officers when deemed not to have exercised due care and responsibility
• Unfulfilled information criteria
• Adverse effects on the enterprise’s internal control system from a weak risk and control framework
54
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
9. FFIEC
Target Audience
US financial institutions, examiners/auditors, and external assurance and advisory professionals that have regulatory requirements or
interests under the FRB, FDIC, NCUA, OCC and OTS are the primary target audience.
Within enterprises, the FFIEC IT Examination Handbook provides guidance to examiners in reviewing the IT management practices
as well as IT governance, information assurance and security controls of supervised financial institutions.
The primary and secondary audiences are indicated in figure 16.
Figure 16—Chart of FFIEC Audiences
Chief Financial Officer (CFO)
Business Executive
Chief Information Officer (CIO)
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
FFIEC
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
O
O
O
O
O
O
O
O
T
Timeliness
In 2001, the Information Technology Subcommittee, of the Task Force on Supervision (Information Technology Subcommittee),
composed of representatives from each of the FFIEC agencies, began revising the 1996 Handbook. The FFIEC agencies determined
that the most efficient way to accomplish the revision and to facilitate future revisions would be to release a series of topical
booklets, rather than one comprehensive handbook. This approach facilitates the update process because the individual booklets can
be revised as needed. Going forward, the FFIEC will update each booklet as warranted by changes in technology or by the evolution
of standards related to financial institution IT practices. Additional booklets will be developed as new topics emerge.13
Certification Opportunities
There are no certifications associated with the FFIEC IT Examination Handbook.
Circulation
The FFIEC IT Examination Handbook is primarily used by US financial institutions, examiners/auditors, and external assurance
and advisory professionals that have regulatory requirements or interests. The FFIEC IT Examination Handbook is available to the
public, and the latest version is published at www.ffiec.gov/ffiecinfobase/index.html.
13
his description was obtained from the introduction of the FFIEC IT Examination Handbook Executive Summary,
T
www.ffiec.gov/ffiecinfobase/booklets/HandbookExecutive%20SummaryFinalDraft10.pdf.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
55
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Completeness
The FFIEC IT Examination Handbook was developed to provide guidance for US financial institution IT practices. The preliminary
drafts then underwent a series of extensive reviews by a working group composed of representatives of the FFIEC agencies, related
FFIEC committees and subject matter experts. When ready, the booklets were reviewed and tested by field examiners from the
agencies and revised, if necessary, based on examiner feedback. Senior management of each agency performed the final review and
approval, and then formally released the booklets. Each booklet was released at the time it was completed.
Availability
The FFIEC IT Examination Handbook is available to the public, and the latest version is published at
www.ffiec.gov/ffiecinfobase/index.html.
COBIT Processes Addressed
Plan and Organise
2 3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
FFIEC
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Information Criteria Addressed
Information Criteria
+
+
+
+
+
o
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
+
+
56
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
9. FFIEC
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MAN NT
E
FOR
PER NAGEM
MA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
C
GI T
TE EN
A
R M
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
The FFIEC issued the initial 12 booklets (figure 17) that make up the FFIEC IT Examination Handbook over a period of
approximately 18 months ending in August 2004. The booklets address significant changes in technology since 1996 and incorporate
a risk-based examination approach. The 1996 Handbook has been replaced by these booklets.
Figure 17—FFIEC IT Examination Handbook Booklets
Audit
Business Continuity Planning
Development and Acquisition
E-banking
FedLine
Information Security
Management
Operations
Outsourcing Technology Services
Retail Payment Systems
Supervision of Technology Service Providers
Wholesale Payment Systems
Further References
Internet
Federal Financial Institutions Examination Council (FFIEC)
www.ffiec.gov
FFIEC IT Examination Handbook
www.ffiec.gov/ffiecinfobase/html_pages/it_01.htm
FFIEC IT Examination Handbook Executive Summary
www.ffiec.gov/ffiecinfobase/booklets/HandbookExecutive%20SummaryFinalDraft10.pdf
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
57
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
10. PMBOK
Document Taxonomy
A Guide to the Project Management Body of Knowledge (PMBOK) is described as ‘the sum of knowledge within the profession of
project management’. PMBOK is an American National Standard, ANSI/PMI 99-001-2004.
Issuer
PMBOK is published by the Project Management Institute (PMI).
Goal of the Guidance
The primary purpose of PMBOK is to ‘identify that subset of The Project Management Body of Knowledge that is generally
recognised as good practice’. The PMBOK guide ‘provides and promotes a common lexicon for discussing, writing and applying
project management’.
Business Driver for Implementing the Guidance,
Including Typical Situations
PMBOK is usually implemented subject to one or more of the following business cases:
• To establish a common lexicon of the processes for project management
• To gain knowledge of proven best practice for project management
Related Risk of Not Implementing the Guidance
Risk of not implementing PMBOK includes:
• Inconsistent project management practices
• Increased risk of project failure
Target Audience
PMBOK is aimed at providing a foundational reference for anyone interested in the profession of project management. The primary
and secondary audiences are indicated in figure 18.
Figure 18—Chart of PMBOK Audiences
58
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and Security
T
Chief Architect
O
Head of Operations
Business Process Owner
PMBOK
Chief Information Officer (CIO)
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: Thorough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
T
O
10. PMBOK
Timeliness
PMBOK has been subject to periodic review and update since it was initially published in 1983. The most recent update was in 2004.
Certification Opportunities
PMI offers the Project Management Professional (PMP) certification programme for project managers. This is based on a Project
Management Professional Examination Specification for the examination, describing the tasks (competencies) that PMPs perform,
and the project management knowledge and skill PMPs use to complete each task.
Circulation
PMBOK Guide is used internationally and is available in Arabic, Chinese, English, French, German, Italian, Japanese, Korean,
Portuguese, Russian and Spanish.
Completeness
PMBOK provides great detail on the practices and techniques required to achieve sound project management. However, while the
processes and techniques described in PMBOK are applicable to projects involving IT, they do not cover IT management and IT
governance issues specifically.
Availability
PMBOK is available for purchase as a paperback and a CD-ROM.
COBIT Processes Addressed
Plan and Organise
2
3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT 4.0 processes addressed by
PMBOK
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
Information Criteria Addressed
Information Criteria
+
+
-
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
59
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Resources Concerned
IT Resources
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
Primary
T
CE
MAN NT
E
FOR
PER NAGEM
MA
IT GOVERNANCE
MAN RISK
AGE
MEN
IC
EG NT
AT ME
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
PMBOK presents project management practices in two groups or dimensions. One presents project management processes segmented
into five process groups. The other is knowledge areas for project management.
The five process groups are:
1. Initiating—Defines and authorises the project or a project phase
2. Planning—Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project
was undertaken to address
3. Executing—Integrates people and other resources to carry out the project management plan for the project
4. Controlling—Regularly measures and monitors progress to identify variances from the project management plan so corrective
action can be taken when necessary to meet project objectives
5. Closing—Formalises acceptance of the product, service or result and brings the project or project phase to an orderly end
Each PMBOK knowledge area describes project management knowledge and practice in terms of one or more processes. Each
process is further described in terms of its inputs, outputs, tools and techniques.
The knowledge areas are:
1. Project integration management—The processes and activities that integrate the various elements of project management, which
are identified, defined, combined, unified and co-ordinated within the project management process groups. It consists of the
project charter development, preliminary project scope statement development, project management plan development, project
execution direction and management, project work monitoring and control, change control integration, and closure of project
management processes.
2. Project scope management—The processes involved in ascertaining that the project includes all the work required, and only the
work required, to complete the project successfully. It consists of the scope planning, scope definition, work breakdown structure
(WBS) creation, scope verification and scope control of project management processes.
3. Project time management—The processes concerning the timely completion of the project. It consists of the activity definition,
activity sequencing, activity resource estimating, activity duration estimating, schedule development and schedule control of
project management processes.
60
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
10. PMBOK
4. Project cost management—The processes involved in planning, estimating, budgeting and controlling costs, so the project is
completed within the approved budget. It consists of the cost estimating, cost budgeting and cost control of project
management processes.
5. Project quality management—The processes involved in assuring that the project will satisfy the objectives for which it was
undertaken. It consists of the quality planning, quality assurance performance and quality control performance of project
management processes.
6. Project human resource management—The processes that organise and manage the project team. It consists of the human resource
planning, project team acquisition, project team development and project team management of project management processes.
7. Project communications management—The processes concerning the timely and appropriate generation, collection, dissemination,
storage and ultimate disposition of project information. It consists of the communications planning, information distribution,
performance reporting and stakeholders management of project management processes.
8. Project risk management—The processes concerned with conducting risk management on a project. It consists of the risk
management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk
monitoring and control of project management processes.
9. Project procurement management—The processes concerned with purchasing or acquiring products, services or results, as well as
contracting management processes. It consists of the purchases and acquisitions planning, contracting planning, seller responses
request, sellers selection, contract administration and contract closure of project management processes
The relationship between the processes and knowledge area is shown in figure 19.
Figure 19—Relationship of Processes Within Knowledge Areas to Project Management Phases
Project Management Process Groups
Project Management
Phase
Project integration
management
Initiating Process
Group
Planning Process
Group
• Project charter
development
• Preliminary project
scope statement
development
• Project
management plan
development
Monitoring and
Controlling Process
Group
Executing Process
Group
• Project execution
direction and
management
• Project work
monitoring and
control
• Integrated change
control
Project scope
management
• Scope planning
• Scope definition
• WBS creation
• Scope verification
• Scope change
control
Project time
management
• Activity definition
• Activity sequencing
• Activity resource
estimating
• Activity duration
estimating
• Development
scheduling
• Schedule control
Project cost
management
• Cost estimating
• Cost budgeting
• Cost control
Project quality
management
• Quality planning
• Quality assurance
performance
Project resources
human management
• Human resource
planning
• Project team
acquisition
• Team development
• Project team
management
Project
communication
management
• Communication
planning
• Information
distribution
• Performance
reporting
• Stakeholders
management
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Closing Process
Group
• Project closure
• Quality control
performance
61
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Figure 19—Relationship of Processes Within Knowledge Areas to Project Management Phases (cont.)
Project Management Process Groups
Project Management
Phase
Initiating Process
Group
Project procurement
management
Planning Process
Group
• Procurement
and acquisitions
planning
• Contract planning
Executing Process
Group
• Seller responses
request
• Seller selection
Monitoring and
Controlling Process
Group
• Contract
administration
Source: Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 3rd Edition, 2004, figure 3-45
Further References
Internet
PMI
62
www.pmi.org
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Closing Process
Group
• Contract close-out
11. CMMI® for Development, V1.2
11. CMMI® for Development, V1.2
Document Taxonomy
CMMI-DEV consists of best practices that address development and maintenance activities applied to products and services. The
CMM Integration project was formed to sort out the problem of using multiple CMMs. The CMMI product team’s initial mission
was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) V2.0 draft C [SEI 1997b]
2. The Systems Engineering Capability Model (SECM) [EIA 1998]
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) V0.98 [SEI 1997a]
Issuer
SEI, affiliated with CMU, first released SW-CMM V1.1 in 1993. CMMI V1.1 was first issued in 2000, replacing the Software CMM.
Figure 20 shows a history of CMM publications available from the SEI.
Figure 20—History of CMMs
Systems Engineering
CMM V1.1 (1995)
CMM for
Software V1.1 (1993)
INCOSE SECAM
(1996)
Software CMM
V2, draft C (1997)
CMMI for Acquisition
V1.2 (2007)
Integrated Product
Development CMM
(1997)
EIA 731 SECM
(1998)
V1.02 (2000)
V1.1 (2002)
CMMI for
Development
V1.2 (2006)
CMMI for Services
V1.2 (2007)
Source: Software Engineering Institute (SEI), CMMI for Development, Version 1.2 (CMMI-DEV, V1.2), Carnegie Mellon University (CMU), USA, 2006, figure 1.2, p. 7
Of note for the IT audience are the plans to develop Capability Maturity Models for Acquisition and Service Management in 2007.
More information on CMM projects can be found on the SEI CMMI web site, www.sei.cmu.edu/cmmi.
Goal of the Guidance
CMMI focuses on improving processes in an enterprise. It contains the essential elements of effective processes for one or more
disciplines and describes an evolutionary path from ad hoc, immature processes to disciplined, mature processes with improved
quality and effectiveness. As a result of this approach, enterprises increase productivity and quality, improve product and service
development cycle time, and experience more accurate and predictable schedules and budgets.
Business Driver for Implementing the Guidance,
Including Typical Situations
CMMI is usually implemented subject to one or more of the following business cases:
• CMMI maturity is required for contractual obligations.
• Product and services development engineering disciplines are critical to the success of the enterprise.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
63
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
• The enterprise has identified the need to improve its quality, reduce variability of results, and improve effectiveness and efficiency
and is looking for how-to best-practice guidance.
• The enterprise wants a rigorous, objective and repeatable assessment of the current state of the process, with actionable findings
that will fill the gaps.
Related Risk of Not Implementing the Guidance
Risk of not implementing CMMI includes:
• Misaligned project, engineering and supporting processes
• Improvement benefits from investments in implementing processes not realised or sustained due to lack of implementation of
generic goals to achieve institutionalisation
• Inability to co-ordinate or collaborate with enterprises at higher levels of maturity
• Shortfall between senior management’s measurements and expectations
• Know-how tied to key individuals, not to the enterprise
• Excessive product and service development and maintenance variability of costs and overhead
• Contractual breaches with potential significant financial penalties on the enterprise
• Inability to rely on subjective assessment of process capability maturity as a baseline or to objectively measure improvement
Target Audience
The target audience for the model includes anyone interested in process improvement in a development and maintenance
environment. The model is also intended for people who want to use an appraisal or examination of one or more processes by a
trained team of professionals to determine strengths and weaknesses. The CMMI knowledge level of IT functions concerned with
CMMI process categories for developing and maintaining systems and products are indicated in figure 21.
Figure 21—Chart of CMMI Audiences
Chief Financial Officer (CFO)
Business Executive
Chief Information Officer (CIO)
Business Process Owner
Head of Operations
Chief Architect
Head of Development
Head of IT Administration
Project Management Office
Compliance, Audit, Risk and
Security
CMMI
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
O
O
O
O
O
T
O
T
T
Process Management
Project Management
O
Engineering
O
T
O
O
T
T
O
T
T
O
T
T
T
T
O
O
O
O
T
O
T
T
O
T
T
O
O
T
O
T
T
T
T
Support
Timeliness
The following improvements were made in CMMI V1.2, which was released in August 2006:
• Continuous and staged representations are presented together.
• Hardware amplifications were added.
64
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
11. CMMI® for Development, V1.2
• Integrated product and process development (IPPD) practices were consolidated and simplified. There are no longer any separate
IPPD process areas.
• Supplier Agreement Management (SAM) and Integrated Supplier Management (ISM) were consolidated, and Supplier Sourcing
was removed.
• An explanation of how process areas support the implementation of generic practices was added.
Certification Opportunities
The SEI Appraisal Program oversees the quality and consistency of the SEI’s process appraisal technology and encourages its
effective use. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is designed to provide benchmark quality
ratings relative to CMMI models. Appraisals of enterprises using a CMMI model must conform to the requirements defined in the
SEI’s Appraisal Requirements for CMMI (ARC). enterprises may choose to have an appraisal to earn a maturity level rating (based
on the staged model) or a capability level achievement profile (based on the continuous model). Appraisal teams use a CMMI model
and ARC-conformant appraisal methods. There are several types of appraisals described in the ARC document—ranging from full
benchmarking or Class A appraisal to less formal methods defined as Class B or Class C.
For individuals, certification as a SCAMPI Lead AppraiserSM is available from SEI. More information on the SEI SCAMPI is
available at www.sei.cmu.edu/cmmi/appraisals.
Circulation
CMMI is used worldwide, and demand for translations has grown. The current SEI-sanctioned translations are based on
CMMI V1.1 and have not been updated for V1.2. A current listing of sanctioned translations is available at
www.sei.cmu.edu/cmmi/tools/translations.
Completeness
CMMI addresses product and services development and maintenance processes. These are applicable to IT software or application
development and maintenance processes, concerns of IT development management and the IT project management office (PMO).
CMMI also addresses process management, application development and maintenance engineering, project management, and
supporting processes. The practices described are those necessary to define, standardise, institutionalise and continuously improve
product and service development and maintenance processes. Detailed adaptation and augmenting guidance is provided in a
prodigious quantity of companion publications. Technical details have been included as examples to illustrate the standards.
Necessary tasks for complying with the capability and maturity level requirements are specified by the model and detailed in the
appraisal method. CMMI should be considered a medium to very detailed, specific guidance with a relatively narrow focus on IT
processes, aiming to be comprehensive for development and maintenance of products and services. IT operations, also known as
service delivery and support, and IT management and monitoring processes are not addressed.
Availability
CMMI and associated publications and links to services are available for free download. Printed copies may be purchased directly
from SEI. Information on the CMMI main web page, www.sei.cmu.edu/cmmi/cmmi.html, includes:
• Downloadable copies of all CMMI models and modules currently available
• Information to help get started using CMMI
• Adoption information, including publications and presentations
• Performance results from process improvement based on CMMI models
• Currently available CMMI training courses, events and forums
• Detail about appraisal services, which include SCAMPI Lead Appraisers and appraisal results
• Comparisons of CMMI models to other models and standards
• Background information about CMMI, including details about the best practices on which it builds
• Official translations of the CMMI models and other CMMI materials
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
65
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
COBIT Processes Addressed
There are two representations of CMMI:
• Continuous representation—An enterprise may choose to improve the performance of a single process-related trouble spot,
or it can work on several areas that are closely aligned to the enterprise’s business objectives. There are some limitations on an
enterprise’s choices because of the dependencies amongst some process areas. Improvement within a process area is organised by
capability level.
• Staged representation—This is a systematic, structured way to approach model-based process improvement one stage at a time.
Achieving each stage ensures that an adequate process infrastructure has been laid as a foundation for the next stage. The order for
implementing processes is prescribed and organised according to maturity levels. Achieving each maturity level ensures that an
adequate foundation has been laid for the next maturity level and allows lasting, incremental improvement.
Figure 22 illustrates 22 process areas, which are shown by maturity level, acronym, process area and process category (process
management, project management, engineering or support).
Figure 22—CMMI Maturity Levels, Process Areas With Acronyms, and Process Category Affiliation
Process Category
Maturity Level
Maturity Level 2:
Managed
Acronym
Process
Project
Management Management
Process Area
Engineering
Support
CM
Configuration Management
X
MA
Measurement and Analysis
X
PMC
Project Monitoring and Control
X
PP
Project Planning
X
PPQA
Process and Product Quality Assurance
REQM
Requirements Management
SAM
Supplier Agreement Management
DAR
Decision Analysis and Resolution
IPM
Integrated Project Management (includes IPPD)
OPD
Organization Process Definition
X
OPF
Organization Process Focus
X
OT
Organizational Training
X
PI
Product Integration
X
RD
Requirements Development
X
RSKM
Risk Management
TS
Technical Solution
X
VAL
Validation
X
VER
Verification
X
Maturity Level 4:
Quantitatively
Managed
OPP
Organizational Process Performance
QPM
Quantitative Project Management
Maturity Level 5:
Optimizing
CAR
Causal Analysis and Resolution
OID
Organizational Innovation and Deployment
Maturity Level 3:
Defined
X
X
X
X
X
X
X
X
X
X
The scope of the CMMI model may be extended with text described as ‘additions’. According to CMMI-DEV, V1.2:
An addition can be informative material, a specific practice, a specific goal or a process area that extends the scope of a
model or emphasizes a particular aspect of its use. In this document, all additions apply to IPPD.14
14
Software Engineering Institute (SEI), CMMI for Development, Version 1.2 (CMMI-DEV, V1.2), Carnegie Mellon University (CMU), USA, 2006
66
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
11. CMMI® for Development, V1.2
The process areas are organised into four categories, with basic and advanced groupings as follows:
• Process management—These are the process areas containing the cross-project activities related to defining, planning, deploying,
implementing, monitoring, controlling, appraising, measuring and improving processes. The basic process management process
areas provide the enterprise with the capability to document and share best practices, organisational process assets, and learning
across the organisation. These include:
– OPF—Organisation Process Focus
– OPD—Organisation Process Definition
– OT—Organisational Training
he advanced process management process areas provide the enterprise with an improved capability to achieve its quantitative
T
objectives for quality and process improvement. These include:
– OPP—Organisational Process Performance
– OID—Organisational Innovation and Deployment
• Project management—These process areas contain project management activities related to planning, monitoring and controlling
the project. The basic project management process areas address the activities related to establishing and maintaining the project
plan, establishing and maintaining commitments, monitoring progress against the plan, taking corrective action, and managing
supplier agreements. These include:
– PP—Project Planning
– PMC—Project Monitoring and Control
– SAM—Supplier Agreement Management
The advanced project management process areas address activities such as establishing a defined process that is tailored from
the enterprise’s set of standard processes, establishing the project work environment standards, co-ordinating and collaborating
with relevant stakeholders, managing project risk, forming and sustaining integrated teams for the conduct of projects, and
quantitatively managing the project’s defined process. These include:
– IPM—Integrated Project Management
– RSKM—Risk Management
– QPM—Quantitative Project Management
• Engineering—Engineering process areas cover the development and maintenance activities that are shared across engineering
disciplines. These are written using general engineering terminology so that any technical discipline (e.g., software engineering or
mechanical engineering) can use them for development process improvement. The engineering process areas are:
– RD—Requirements Development
– REQM—Requirements Management
– TS—Technical Solution
– PI—Product Integration
– VER—Verification
– VAL—Validation
• Support—Support processes cover the activities that support product development and maintenance. The support process areas
address processes that are used in the context of performing other processes. In general, the support process areas address processes
that are targeted towards the project and may address processes that apply more generally to the enterprise. For example, Process
and Product Quality Assurance (PPQA) can be used with all CMMI process areas to objectively evaluate processes and work
products in all process areas. These support processes are:
– CM—Configuration Management
– PPQA—Process and Product Quality Assurance
– MA—Measurement and Analysis
– DAR—Decision Analysis and Resolution
– CAR—Causal Analysis and Resolution
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
67
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Plan and Organise
2 3
4
5 6
7
8
9 10
4
4
1
5 6
2
3
3
2
COBIT processes addressed by
CMMI
7
Acquire and Implement
1
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
full
none
Information Criteria Addressed by CMMI
When CMMI is used by an IT organisation, the information delivered to the organization results in fulfilment of certain criteria
characterised as follows:
• Quality requirements:
– Effectiveness—Deals with information being relevant and pertinent to the business process and being delivered in a timely,
correct, consistent and usable manner
– Efficiency—Concerns the provision of information through the optimal (most productive and economical) use of resources
• Security requirements:
– Confidentiality—Concerns the protection of sensitive information from unauthorised disclosure and is not addressed directly
by CMMI
– Integrity—Relates to the accuracy and completeness of information and its validity in accordance with business values and
expectations and is not addressed directly by CMMI
– Availability—Relates to information being available when required by the business process now and in the future and concerns
the safeguarding of necessary resources and associated capabilities. It is not addressed by CMMI.
– See www.sei.cmu.edu/products for SEI’s security products and services.
• Fiduciary requirements:
– Compliance—Deals with complying with the laws, regulations and contractual arrangements to which the business process is
subject, i.e., externally imposed business criteria and internal policies. It is not addressed by CMMI.
– Reliability—Relates to the provision of appropriate information for management to operate the entity and exercise its fiduciary
and governance responsibilities and is not addressed by CMMI
Information Criteria Addressed
Information Criteria
+
+
-
68
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
11. CMMI® for Development, V1.2
IT Resources Concerned
IT Resources
+
o
o
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
The resources used by IT are identified as follows:
• Applications are automated user systems and manual procedures that process the information.
• Information is the data in all forms that are input, processed and output by the information systems (IS) in whatever manner is
used by the business.
• Infrastructure is the technology and facilities (hardware, operating systems [OSs], database management systems, networking,
multimedia, etc., and the environment that houses and supports them) that enable the processing of the applications.
• People are the personnel required to plan, organise, acquire, implement, deliver, support, monitor and evaluate the information
systems and services. They may be internal, outsourced or contracted as required.
The IT resources addressed by CMMI are as follows:
• Addressed:
– Applications—Development and maintenance of products, including IT applications
• Moderately addressed:
– Infrastructure—Infrastructure co-developed with the IT application
– People—Personnel engaged in product and service development and maintenance
• Not directly addressed:
– Information—Data and data processing
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
Primary
MAN RISK
AGE
M
CE
MAN NT
E
FOR
PER ASURM
ME
IT GOVERNANCE
ENT
IC
EG NT
AT ME
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
69
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Description of Guidance and Its Content
The model component relationships are shown in figure 23.
Figure 23—CMMI Model Components
Process Area
Purpose
Statement
Introductory
Notes
Specific
Goals
Generic Goals
Generic
Practices
Specific
Practices
Typical
Work
Key:
Required
Related
Process
Subpractices
Generic
Practices
Subpractices
Informative
Expected
Source: SEI, CMMI-DEV, V1.2, CMU, USA, 2006, figure 2.1, p. 17
Integral to both the staged and continuous CMMI models are the CMMI generic goals and practices that are required model
components and applied to all CMMI process areas. The generic goals (GGs) and generic practices (GPs) represent levels of process
capability, as shown in figure 24.
70
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
11. CMMI® for Development, V1.2
Figure 24—Generic Practices Required for Process Area Capability Level
Capability
Levels
Generic Goal (GG)
Generic Practices
(GPs)
Capability
Level 0:
Incomplete
Capability
Level 2:
Managed
GG 1: Achieve
the process area’s
specific goals.
GG 2:
Institutionalize a
managed process.
GG 3:
Institutionalize a
defined process.
GG 4:
Institutionalize
a quantitatively
managed process.
GG 5:
Institutionalize
an optimizing
process.
GP 2.1: Establish
policy.
GP 3.1: Establish
and maintain a
defined process.
GP 4.1: Establish
quantitative
objectives for the
process.
GP 5.1: Ensure
continuous
process
improvement.
GP 4.2: Stabilise
subprocess
performance.
GP 5.2: Correct
the root causes of
problems.
GP 2.2: Plan
to perform the
process.
GP 2.3: Provide
resources—
adequate funding,
appropriate
physical facilities,
skilled people and
appropriate tools.
Capability
Level 3:
Defined
Capability
Level 4:
Quantitatively
Managed
Capability
Level 1:
Performed
GP 3.2: Collect
improvement
information.
Capability
Level 5:
Optimizing
GP 2.4: Assign
responsibility.
GP 2.5: Train
people.
GP 2.6: Manage
configurations.
GP 2.7: Identify
and involve
relevant
stakeholders.
GP 2.8: Monitor
and control
process.
GP 2.9:
Objectively
evaluate
adherence.
GP 2.10: Review
status with higher
management.
CMMI maturity level 2 means that the listed maturity level 2 processes have capability level 2 profiles. As illustrated in figure 25,
to appraise at CMMI maturity level 2—using the staged model—all the listed process areas required for maturity level 2 must be
appraised as having met process-area-specific goals and practices at the capability level indicated by meeting the generic goals and
practices for capability level 2. Similarly, target profile 3 shows the additional process areas and capability level requirements for
maturity level 3 and so on.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
71
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Figure 25—Target Process Area Capability Level Profiles for Maturity Levels
Acronym
Capability
Capability Capability Capability
Level 4:
Capability
Level 1:
Level 2:
Level 3: Quantitatively Level 5:
Performed Managed Defined
Managed
Optimizing
Maturity
Level (ML)
Process Area
REQM
Requirements Management
ML 2:
Managed
PP
Project Planning
PMC
Project Monitoring and Control
SAM
Supplier Agreement Management
MA
Measurement and Analysis
PPQA
Process and Product Quality Assurance
CM
Configuration Management
RD
Requirements Development
TS
Technical Solution
PI
Product Integration
VER
Verification
VAL
Validation
OPF
Organizational Process Focus
Target Profile 2
ML 3:
Defined
Target Profile 3
OPD+IPPD Organizational Process Definition + Integrated
Process and Product Development
OT
Organizational Training
IPM+IPPD
Integrated Project Management + Integrated
Process and Product Development
RSKM
Risk Management
DAR
Decision Analysis and Resolution
OPP
Organizational Process Performance
QPM
Quantitative Project Management
OID
Organizational Innovation and Deployment
CAR
Causal Analysis and Resolution
ML 4:
Quantitatively
Managed
Target Profile 4
ML 5:
Optimizing
Target Profile 5
Further References
Internet
SEI
72
www.sei.cmu.edu/cmmi
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
12. TOGAF 8.1
12. TOGAF 8.1
Note: TOGAF 8.1 was superceded by TOGAF 9.
Document Taxonomy
TOGAF is a detailed method and set of supporting tools for developing an enterprise architecture.
Issuer
Members of The Open Group, working within the Architecture Forum (www.opengroup.org/architecture), developed TOGAF.
TOGAF has been in existence since 1995, when the newly created Architecture Forum developed the first version based on the US
DoD TAFIM. The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on TAFIM. The
members of The Open Group Architecture Forum have developed successive versions of TOGAF that are published on The Open
Group public web site.
Goal of the Guidance
The Open Group operates as a not-for-profit consortium committed to delivering greater business efficiency by bringing together
buyers and suppliers of information systems to lower the barriers of integrating new technology across the enterprise. Its goal is to
realise the vision of Boundaryless Information Flow™.
TOGAF is a key part of its strategy for achieving this goal; The Open Group wants TOGAF to be used in practical architecture
projects, and would like the experiences from its use fed back to The Open Group to help improve it.
Business Driver for Implementing the Guidance,
Including Typical Situations
Business drivers for implementing TOGAF include the following:
• Facilitate business and IT alignment by providing the fundamental technology and process structure for an IT and/or business strategy.
• Manage intellectual capital by formalising models across architecture domains.
• Improve business/IT effectiveness and efficiency.
• Reduce risk for future investment and derive better return on existing investment.
• Manage complexity and change.
Related Risk of Not Implementing the Guidance
Related risk of not implementing TOGAF includes:
• Increased complexity and cost of ownership
• Fragmentation of information resources
• Reduced organisational agility
• Reduced innovation capability
Target Audience
TOGAF focuses on enterprises of varying size. It targets those responsible for enterprise architecture management, strategic
planning, the acquisition and implementation of business systems, risk management, and organisational development. Figure 26 lists
the primary and secondary audiences.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
73
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Figure 26—Chart of TOGAF Audiences
Chief Architect
Head of Development
O
O
T
O
Compliance, Audit, Risk and Security
Head of Operations
O
Project Management Office
Business Process Owner
O
Head of IT Administration
Chief Information Officer (CIO)
TOGAF
Business Executive
Chief Financial Officer (CFO)
Chief Executive Officer (CEO)
Functions: T horough knowledge of the document (T), Overview of the document’s
intention and content (O)
O
O
Timeliness
The publications state that they will be updated in a frequent and ongoing manner. Three versions of TOGAF are available:
• The 2006 edition is based on TOGAF Version 8.1, with Technical Corrigendum U065 applied; it is also known as TOGAF Version
8.1.1.
• TOGAF Version 8, Enterprise Edition, first published in December 2002 and republished in updated form as TOGAF Version 8.1
in December 2003. This document provides the mapping between TOGAF 8.1 and COBIT 4.0. The changes between versions 8.1
and 8.1.1 may be viewed using the online version of TOGAF.
• TOGAF Version 7, Technical Edition, published in December 2001
TOGAF Version 8 uses the same underlying architecture development method that evolved, with particular focus on technical
architectures, through TOGAF Version 7. TOGAF Version 8 applies that architecture development method to all the domains of an
overall enterprise architecture, including business, data (information) and application architecture, as well as technical architecture.
TOGAF Version 9 is due for release in the fourth quarter of 2007 and will provide additional focus on the following themes:
• The enterprise, culture and stakeholders
• Enterprise architecture creation
• Enterprise architecture-based transformation
• Enterprise architecture deployment
• Enterprise architecture realisation
• Enterprise architecture management and governance
Certification Opportunities
TOGAF certification is for both individuals and enterprises. Individuals can become certified by demonstrating their knowledge
of TOGAF by either attending a training course or passing an examination. Enterprises can have their products (TOGAF tools or
training courses) and services certified.
Circulation
TOGAF is used internationally; however, it is available in English only. (A Japanese version has recently been produced, but is not
yet publicly available.)
Completeness
TOGAF provides a common-sense, practical and effective method of developing enterprise architecture.
74
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
12. TOGAF 8.1
Availability
TOGAF is published by The Open Group on its public web server. In addition, TOGAF 8.1, Enterprise Edition, is published in
book format.
COBIT Processes Addressed
Plan and Organise
2 3
4
5 6
7
8
9 10
4
1
4
1
5 6
2
3
3
2
COBIT 4.0 processes addressed by
TOGAF 8.1
7
Acquire and Implement
Monitor and Evaluate
1
1 2 3 4 5 6 7 8 9 10 11 12 13
Deliver and Support
Information Criteria Addressed
Information Criteria
+
+
o
o
o
+
o
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
IT Resources Concerned
IT Resources
+
+
+
+
Applications
Information
Infrastructure
People
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
75
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
IT Governance Focus Areas Addressed
DE VAL
LIV UE
ER
Y
CE
MAN NT
E
FOR
PER NAGEM
MA
IT GOVERNANCE
Primary
MAN RISK
AGE
MEN
T
IC
EG NT
AT ME
R
ST IGN
AL
Secondary
Not Addressed
RESOURCE
MANAGEMENT
Description of Guidance and Its Content
There are four main parts to the TOGAF document.
• Part I: Introduction—Provides a high-level introduction to some of the key concepts behind enterprise architecture and, in
particular, the TOGAF approach
• Part II: Architecture Development Method (ADM)—Core of TOGAF; describes the step-by-step approach to developing an
enterprise architecture
• Part III: Enterprise Continuum—Describes the virtual repository of architecture assets, which includes the TOGAF Foundation
Architecture and the Integrated Information Infrastructure Reference Model
• Part IV: Resources—Provides a set of tools and techniques available for use in applying TOGAF and the TOGAF ADM
Key Architecture Concepts
Architecture has two meanings depending upon its contextual usage:
• A formal description of a system, or a detailed plan of the system, at component level to guide its implementation
• The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time
Enterprise
A good definition of ‘enterprise’ in this context is any collection of organisations that have a common set of goals and/or a single
bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single
department or a chain of geographically distant organisations linked together by common ownership.
The term enterprise in the context of ‘enterprise architecture’ can be used to denote both an entire enterprise, encompassing all of
its information systems, and/or a specific domain within the enterprise. In either case, the architecture crosses multiple systems and
multiple functional groups within the enterprise.
Confusion also arises from the evolving nature of the term ‘enterprise’. An ‘extended enterprise’ frequently includes partners,
suppliers and customers. If the goal is to integrate an extended enterprise, then the enterprise is composed of the partners, suppliers
and customers, and internal business units.
Large corporations and government agencies may be composed of multiple enterprises; hence, there may be separate enterprise
architecture projects. However, there is often much in common about the information systems in each enterprise, and there is usually
great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for
the development of an architecture repository for the integration and reuse of models, designs and baseline data.
Architecture Principles
Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets
across the enterprise. They reflect a level of consensus amongst the various elements of the enterprise, and form the basis for making
future IT decisions. Each architecture principle should be clearly related back to the business objectives and key architecture drivers.
Architecture principles typically address the EA practice and the EA domains.
76
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
12. TOGAF 8.1
EA Domains
There are four types of architecture that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF
is designed to support:
• A business (or business process) architecture defines the business strategy, governance, organisation and key business processes.
• An applications architecture provides a blueprint for the individual application systems to be deployed, their interactions and their
relationships to the core business processes of the enterprise.
• A data architecture describes the structure of an enterprise’s logical and physical data assets, and data management resources.
• A technology architecture describes the architectural principles, component relationships, and hardware and software infrastructure
intended to support the deployment of core, mission-critical applications.
Architecture Framework
An architecture framework is a tool that can be used for developing a broad range of different architectures. It should describe a
method for designing an information system in terms of a set of building blocks and showing how the building blocks fit together,
contain a set of tools, provide a common vocabulary, and include a list of recommended standards and compliant products that can
be used to implement the building blocks.
Architecture Description
An architecture description is a formal description of an information system, organised in a way that supports reasoning about the
structural properties of the system. It defines the components or building blocks that make up the overall information system and
provides a plan from which products can be procured and systems developed to work together to implement the overall system. Thus,
it enables the overall IT investment to be managed in a way that meets the needs of the business.
Architecture Views
Architecture views are representations of the overall architecture that are meaningful to one or more stakeholders in the system. The
architect chooses and develops a set of views that will enable the architecture to be communicated to, and understood by, all the
stakeholders and enable them to verify that the system will address their concerns.
An architecture is usually represented by one or more architecture models that together provide a coherent description of the
system’s architecture. A single, comprehensive model is often too complex to be understood and communicated in its most detailed
form, showing all the relationships amongst various business and technical components. As with the architecture of a building,
it is normally necessary to develop multiple views of the architecture of an information system to enable the architecture to be
communicated to, and understood by, the different stakeholders in the system. For example, just as a building architect might create
wiring diagrams, floor plans and elevations to describe different facets of a building to its different stakeholders (i.e., electricians,
owners, planning officials), so an IT architect might create physical and security views of an IT system for the stakeholders who have
concerns related to these aspects.
The choice of which particular architecture views to develop is one of the key decisions that the architect has to make. The architect
has a responsibility for ensuring the completeness (fitness for purpose) of the architecture, in terms of adequately addressing all the
pertinent concerns of its stakeholders, and the integrity of the architecture, in terms of connecting all the various views to each other,
satisfactorily reconciling the conflicting concerns of different stakeholders and showing the trade-offs made in so doing (as between
security and performance, for example).
Enterprise Continuum
The enterprise continuum is an important aid to communication and understanding, within individual enterprises and between
customer enterprises and vendor organisations. Any architecture is context specific; for example, there are architectures that are
specific to individual customers, industries, subsystems, products and services. Architects, on both the buy side and supply side, must
have at their disposal a consistent language to effectively communicate the differences between architectures. Such a language will
enable engineering efficiency and the effective leveraging of commercial off the-shelf (COTS) product functionality. The enterprise
continuum provides that consistent language. The enterprise continuum represents not only an aid to communication, but also an aid
to organising reusable architecture and solution assets. Contents include Technical Reference Model (TRM), Standards Information
Base (SIB) and the TOGAF Integrated Information Infrastructure Reference Model.
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
77
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Architecture Development Method
Figure 27 is the graphical representation of TOGAF’s ADM.
Figure 27—TOGAF’s ADM
As a brief overview, the ADM is iterative over the whole process, between phases and within phases. The phases include:
• Preliminary phase—Deals mainly with the definition of the architecture framework, as discussed above, as well as the architecture
principles. In addition, the overall scope, constraints, objectives and assumptions are identified.
• Architecture vision—Deals with defining the vision and scope of the architecture and specific segments of work to be performed
• Business architecture—Addresses the description of the as-is business architecture domain, the development of the to-be business
architecture and the gap analysis between the two
• Information systems architecture—Provides the description of the as-is and to-be data, applications domains and conducting the
gap analyses
• Technology architecture—Deals with the description of the as-is and to-be technology domains, and conducting a gap analysis
• Opportunities and solutions—Deals with the formulation of a high-level implementation and migration strategy to transform the
as-is architectures into the to-be
• Migration planning—Deals with a formulation of a detailed implementation and migration road map, including the analysis of
costs, benefits and risk
78
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
12. TOGAF 8.1
• Implementation governance—Ensures that the implementation projects conform to the defined architecture
• Architecture change management—Deals with keeping the architecture up to date and ensures that the architecture responds to
the needs of the enterprise, as changes arise
• Requirements management—Ensures that the architecture projects are based on business requirements and that the business
requirements are validated against the architecture
Figure 28 lists the concerns of various stakeholders.
Figure 28—Architecture Concerns of the Stakeholders
Summary of TOGAF Positioning
TOGAF does not seek to compete with or duplicate other frameworks. What TOGAF does seek to provide is a practical, industry
standard method of doing enterprise architecture, leveraging all relevant assets in the process. It is freely available and supported by
a number of different architecting consultancies. t is sufficient for an enterprise to use as-is or to adapt as the basis of an enterprise
architecture method for other, deliverables-focused frameworks.
Further References
Internet
The Open Group
www.opengroup.org
Architecture Forum
www.opengroup.org/architecture/
TOGAF 8.1
www.opengroup.org/architecture/togaf8-doc/arch
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
79
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
13. Conclusion
The purpose of this paper is to compare various worldwide guidance publications focused on specific issues of IT governance.
Only COBIT addresses the full spectrum of IT governance duties; however, several standards publications describe the duties in a
more comprehensive manner than COBIT. Thus, when implementing sound IT governance, those standards publications have to
be considered, and the guidelines, models and processes should be used to facilitate it, but the framework to integrate the standards
should be COBIT. Please note that all documents discussed in this paper and the information therein are subject to change, and
implementation of those standards requires thorough planning and knowledge of the guidance.
In summary, three figures provide a high-level view of how the guidance documents discussed in this paper link to COBIT and relate
to each other:
• Figure 29 shows the horisontal and vertical classification of completeness of the guidance documents. Vertical refers to how
detailed the guidance is in terms of technical or operational profundity. Horizontal refers to the completeness of the guidance: How
much of COBIT is addressed within it? What is more comprehensively addressed in another standard than in COBIT? What is
missing compared to COBIT?
• Figure 30 displays a high-level mapping of the guidance documents covered in this publication to the COBIT domains.
• Figure 31 shows a high-level mapping of the guidance to the COBIT processes.
Figure 29—Classification of Guidance
deep
CMMI
20000
ITIL
shallow
Vertical
TOGAF
17799
Figure 30—High-level Mapping of Guidance to CobiT Domains
PO AI DS ME
COSO
+
+
o
o
ITIL
o
o
+
ISO/IEC 17799
o
+
+
o
ISO/IEC 20000
o
+
FFIEC
+
o
o
+
PMBOK
o
CMMI
+
o
TOGAF 8.1
o
NIST 800-53
o
o
(+) Frequently addressed
(o) Moderately addressed
(-) Not or rarely addressed
COBIT
FFIEC
NIST
PMBOK
narrow
COSO
broad
Horizontal
COSO
ITIL
ISO/IEC 17799
ISO/IEC 20000
FFIEC
PMBOK
CMMI
TOGAF 8.1
NIST 800-53
COBIT Process
Figure 31—High-level Mapping of Guidance to COBIT Processes
PO 1
+
-
-
-
+
-
-
-
-
PO 2
+
-
+
-
+
-
-
+
+
PO 3
+
+
+
+
+
-
-
+
-
PO 4
+
+
+
+
+
-
-
+
-
PO 5
+
+
-
+
+
+
-
-
-
PO 6
+
-
+
+
+
-
-
-
-
PO 7
+
-
+
+
+
-
-
-
+
PO 8
-
-
-
+
+
+
+
-
-
80
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
13. Conclusion
COSO
ITIL
ISO/IEC 17799
ISO/IEC 20000
FFIEC
PMBOK
CMMI
TOGAF 8.1
NIST 800-53
COBIT Process
Figure 31—High-level Mapping of Guidance to COBIT Processes (cont.)
PO 9
+
-
+
+
+
+
+
-
+
PO 10
-
-
-
+
+
+
+
-
-
AI 1
+
-
-
+
+
-
-
+
-
AI 2
+
-
+
-
+
-
+
-
+
AI 3
+
-
+
-
+
-
-
-
-
AI 4
+
+
+
-
+
-
-
-
-
AI 5
-
-
-
+
+
+
-
-
-
AI 6
+
+
+
+
+
-
+
-
-
AI 7
+
+
+
+
+
-
+
-
-
DS 1
+
+
-
+
+
-
-
+
-
DS 2
-
+
+
+
+
-
-
-
-
DS 3
+
+
+
+
+
-
-
-
-
DS 4
+
+
+
+
+
-
-
-
+
DS 5
+
+
+
+
+
-
-
-
+
DS 6
-
+
-
+
+
-
-
-
-
DS 7
+
-
+
+
+
-
+
-
+
DS 8
-
+
+
+
+
-
-
-
+
DS 9
+
+
+
+
+
-
+
-
+
DS 10
-
+
-
+
+
-
+
-
-
DS 11
+
+
+
-
+
-
+
-
+
DS 12
+
-
+
-
+
-
-
-
+
DS 13
-
-
+
-
+
-
-
-
-
ME 1
-
-
+
+
+
-
+
-
-
ME 2
-
-
+
+
+
-
-
-
-
ME 3
+
-
-
-
+
-
-
-
-
ME 4
+
-
+
+
+
-
-
-
-
(+) Frequently addressed
(-) Not or rarely addressed
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
81
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
14. References
British Standards Institute, Information Security Management Systems—Specification With Guidance for Use, BS 7799-2:2002, UK, 2002
Committee of Sponsoring Organizations of the Treadway Commission (COSO), Internal Control—Integrated Framework, USA, 1992
Common Criteria Project Sponsoring Organization, Common Criteria for Information Technology Security Evaluation 2.0, 1999
Federal Financial Institutions Examination Council (FFIEC), USA, www.ffiec.gov:
• Information Technology (IT) Examination Handbook, http://ithandbook.ffiec.gov/
• IT Examination Handbook Executive Summary, http://ithandbook.ffiec.gov/media/18430/
handbookexecutivesummaryfinaldraft_20100317.pdf
International Organization for Standardization (ISO), Switzerland:
• ISO/IEC 9001, Quality Management Systems, 2000 (replaced by ISO/IEC 9001:2008)
• ISO/IEC 9000-3, Quality Management and Quality Assurance Standards—Part 3: Guidelines for the Application of ISO 9001:1994 to
the Development, Supply, Installation and Maintenance of Computer Software, 1997 (replaced by ISO/IEC 90003)
• ISO/IEC 13335-1, Information Technology—Security techniques–Management of information and communications technology security–
Part 1: Concepts and models for information and communications technology security management, 2004
• ISO/IEC 15408, Security Techniques—Evaluation Criteria for IT Security, 2005
• ISO/IEC 17799, Code of Practice for Information Security Management, 2000, 2005
• ISO/IEC 20000:2005, Information technology—Service management, 2005
ISACA, USA:
• COBIT 4.0, 2005
• COBIT 4.1, 2007
IT Service Management Forum (itSMF), BS15000 for Consultants, UK, 2004
National Institute of Standards and Technology (NIST), Department of Commerce, Computer Security Division, Information
Technology Laboratory, USA:
• FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, 2006
• SP800-12, An Introduction to Computer Security: The NIST Handbook, 1995
• SP800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems, 1996
• SP800-18, Guide for Developing Security Plans for Federal Information Systems
• SP800-26, Security Self-assessment Guide for Information Technology Systems
• SP800-30, Risk Management Guide for Information Technology Systems
• SP800-37, Guide for the Security Certification and Accreditation of Federal Information Systems
• SP800-39, Managing Risks from Information Systems: An Organizational Perspective (Initial Public Draft)
• SP800-53 Rev 1, Recommended Security Controls for Federal Information Systems
• SP800-53A, Guide for Assessing the Security Controls in Federal Information Systems, 2nd Public Draft
• SP800-60, Guide for Mapping Types of Information and Information Systems to Security Categories
• SP800-70, Security Configuration Checklists Program for IT Products
• SP800-80, Guide for Developing Performance Metrics for Information Security
• SP800-100, Information Security Handbook: A Guide for Managers
Office of Government Commerce (OGC), UK:
• Continual Service Improvement, 2007
• IT Infrastructure Library (ITIL), 1989
• Managing Successful Projects with PRINCE2, 2002, 2005
• Official Introduction to the IT Service Lifecycle, 2007
• Service Design, 2007
• Service Operation, 2007
• Service Strategy, 2007
• Service Transition, 2007
82
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
14. References
The Open Group, The Open Group Architecture Framework (TOGAF™) Version 8.1, Enterprise Edition, USA, 2004
Paulk, M.C., et al; Capability Maturity Models for Software, CMU/SEI-93-TR-24, Carnegie Mellon University, Software Engineering
Institute, USA, 1993
Project Management Institute Inc., USA:
• A Guide to the Project Management Body of Knowledge (PMBOK guide), Third Edition, 2004
• Organizational Project Management Maturity Model (OPM3), 2003
Rudd, Colin; itSMF BS 15000 Certification Scheme—Scoping Guidelines, UK, 2005 (out of circulation)
Software Engineering Institute, Carnegie Mellon University , USA:
• Capability Maturity Model Integration for Development, Version 1.2 (CMMI-DEV, V1.2) , 2006
• ‘Improving Processes for Bette5r Products’, CMU/SEI-2006-TR008, ESC-TR-s006-008, 2006
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
83
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Appendix—ISACA Professional Guidance Publications
Many ISACA publications contain detailed assessment questionnaires and work programmes that provide valuable guidance.
Please visit www.isaca.org/bookstore or e-mail bookstore@isaca.org for more information.
Frameworks and Model
• Business Model for Information Security, 2010
• COBIT® 4.1, 2007
• Enterprise Value: Governance of IT Investments: The Val ITTM Framework 2.0, 2008
• ITAFTM: A Professional Practices Framework for IT Assurance, 2008
• The Risk IT Framework, 2009
COBIT-related Publications
• Aligning COBIT ® 4.1, ITIL V3® and ISO/IEC 27002 for Business Benefit, 2008
• Building the Business Case for COBIT ® and Val ITTM: Executive Briefing, 2009
• COBIT ® and Application Controls, 2009
• COBIT ® Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition, 2007
• COBIT ® Mapping: Mapping of CMMI® for Development V1.2 With COBIT ® 4.1, 2011
• COBIT ® Mapping: Mapping of FFEIC With COBIT ® 4.1, 2010
• COBIT ® Mapping: Mapping of ISO 20000 With COBIT ® 4.1, 2011
• COBIT ® Mapping: Mapping of ISO/IEC 17799:2000 With COBIT ®, 2nd Edition, 2006
• COBIT ® Mapping: Mapping of ISO/IEC 17799:2005 With COBIT ® 4.0, 2006
• COBIT ® Mapping: Mapping of ITIL V3 With COBIT ® 4.1, 2008
• COBIT ® Mapping: Mapping of NIST SP800-53 With COBIT ® 4.1, 2007
• COBIT ® Mapping: Mapping of PMBOK® With COBIT ® 4.0, 2006
• COBIT ® Mapping: Mapping of SEI’s CMM® for Software With COBIT ® 4.0, 2006
• COBIT ® Mapping: Mapping of TOGAF 8.1 With COBIT ® 4.0, 2007
• COBIT ® Mapping: Overview of International IT Guidance, 3rd Edition, 2011
• COBIT ® QuickstartTM, 2nd Edition, 2007
• COBIT ® Security BaselineTM, 2nd Edition, 2007
• COBIT ® User Guide for Service Managers, 2009
• Implementing and Continually Improving IT Governance, 2009
• IT Assurance Guide: Using COBIT ®, 2007
Risk IT-related Publication
• The Risk IT Practitioner Guide, 2009
Val IT-related Publications
• Enterprise Value: Getting Started With Value Management, 2008
• The Business Case Guide: Using Val ITTM 2.0, 2010
• Value Management Guidance for Assurance Professionals: Using Val ITTM 2.0, 2010
84
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
Appendix—ISACA Professional Guidance Publications
Academic Guidance
IT Governance Using COBIT® and Val ITTM material:
• Student Book, 2nd Edition, 2007
• Caselets, 2nd Edition and Teaching Notes, 2007
• TIBO Case Study, 2nd Edition and Teaching Notes, 2007 (Spanish translation also available)
• Presentation, 2nd Edition, 2007 (35-slide PowerPoint deck on COBIT)
• Caselets, 3rd Edition and Teaching Notes, 2010
• City Medical Center Case Study, 3rd Edition and Teaching Notes, 2010
• Information Security Using the CISM® Review Manual and BMISTM material:
• Caselets, 2010
• More 4Less Foods Case Study, 2010
• Teaching Notes, 2010
Executive and Management Guidance
• An Executive View of IT Governance, 2008
• An Introduction to the Business Model for Information Security, 2009
• Board Briefing on IT Governance, 2nd Edition, 2003
• Defining Information Security Management Position Requirements: Guidance for Executives and Managers, 2008
• Identifying and Aligning Business Goals and IT Goals: Full Research Report, 2008
• Information Security Governance: Guidance for Boards of Directors and Executive Management, 2nd Edition, 2006
• Information Security Governance: Guidance for Information Security Managers, 2008
• Information Security Governance—Top Actions for Security Managers, 2005
• ITGI Enables ISO/IEC 38500:2008 Adoption, 2009
• IT Governance and Process Maturity, 2008
• IT Governance Domain Practices and Competencies:
– Governance of Outsourcing, 2005
– Information Risks: Whose Business Are They?, 2005
– IT Alignment: Who Is in Charge?, 2005
– Measuring and Demonstrating the Value of IT, 2005
– Optimising Value Creation From IT Investments, 2005
• IT Governance Roundtables:
– Defining IT Governance, 2008
– IT Staffing Challenges, 2008
– Unlocking Value, 2009
– Value Delivery, 2008
• Global Status Report on GEIT 2011, 2011
• Managing Information Integrity: Security, Control and Audit Issues, 2004
• Understanding How Business Goals Drive IT Goals, 2008
• Unlocking Value: An Executive Primer on the Critical Role of IT Governance, 2008
Practitioner Guidance
• Audit/Assurance Programs:
– ApacheTM Web Services Server Audit/Assurance Program, 2010
– Change Management Audit/Assurance Program, 2009
– Cloud Computing Management Audit/Assurance Program, 2010
– Crisis Management Audit/Assurance Program, 2010
– Generic Application Audit/Assurance Program, 2009
– Identity Management Audit/Assurance Program, 2009
– Information Security Management Audit/Assurance Program, 2010
– IT Continuity Planning Audit/Assurance Program, 2009
– Microsoft® Internet Information Services (IIS) 7 Web Services Server Audit/Assurance Program, 2011
– Mobile Computing Security Audit/Assurance Program, 2010
– MySQLTM Server Audit/Assurance Program, 2010
– Network Perimeter Security Audit/Assurance Program, 2009
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
85
COBIT Mapping: Overview of International IT Guidance, 3rd Edition
Practitioner Guidance (cont.)
• Audit/Assurance Programs: (cont.)
– Outsourced IT Environments Audit/Assurance Program, 2009
– Security Incident Management Audit/Assurance Program, 2009
– Social Media Audit/Assurance Program, 2011
– Systems Development and Project Management Audit/Assurance Program, 2009
– UNIX/LINUX Operating System Security Audit/Assurance Program, 2009
– VMware® Server Virtualization Audit/Assurance Program, 2011
– Windows Active Directory Audit/Assurance Program, 2010
– z/OS Security Audit/Assurance Program, 2009
• Cybercrime: Incident Response and Digital Forensics, 2005
• Enterprise Identity Management: Managing Secure and Controllable Access in the Extended Enterprise Environment, 2004
• Information Security Career Progression Survey Results, 2008
• Information Security Harmonisation—Classification of Global Guidance, 2005
• IT Control Objectives for Basel II, 2007
• IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial
Reporting, 2nd Edition, 2006
• OS/390—z/OS: Security, Control and Audit Features, 2003
• Peer-to-peer Networking Security and Control, 2003
• Risks of Customer Relationship Management: A Security, Control and Audit Approach, 2003
• Security Awareness: Best Practices to Serve Your Enterprise, 2005
• Security Critical Issues, 2005
• Security Provisioning: Managing Access in Extended Enterprises, 2002
• SharePoint® Deployment and Governance Using COBIT ® 4.1: A Practical Approach, 2010
• Stepping Through the IS Audit, 2nd Edition, 2004
• Stepping Through the InfoSec Program, 2007
• Technical and Risk Management Reference Series:
– Security, Audit and Control Features Oracle® Database, 3rd Edition, 2009
– Security, Audit and Control Features Oracle® E-Business Suite, 3rd Edition, 2010
– Security, Audit and Control Features PeopleSoft, 2nd Edition, 2006
– Security, Audit and Control Features SAP®ERP, 3rd Edition, 2009
• Top Business/Technology Survey Results, 2008
• White Papers:
– Cloud Computing: Business Benefits With Security, Governance and Assurance Perspective, 2009
– Data Leak Prevention, 2010
– Electronic Discovery,2011
– Leveraging XBRL for Value in Organizations, 2011
– New Service Auditor Standard: A User Entity Perspective, 2010
– Securing Mobile Devices, 2010
– Security Information and Event Management: Business Benefits and Security, Governance and Assurance Perspective, 2010
– Social Media: Business Benefits and Security, Governance and Assurance Perspectives, 2010
– Virtualization: Benefits and Challenges, 2010
86
© 2011 ISACA. A
l l
r i g h t s
r e s e r v e d
.
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org