Here is our agenda:
- IT Compliance introduction
- US, Australian and EU laws
- Introduction to Best Practice Frameworks
- Introduction to COBIT with example
- Introduction to ITIL with example
- Introduction to ISO17799 with example
- Making them play together

IT Compliance – Why bother?
- Companies want a better ROI on IT investments
- Concern over increasing IT expenditure
- Regulatory regulations. E.g. Sarbanes Oxley
- Global outsourcing
- Increasing IT risk (security threats)
- Growing maturity of international best practice frameworks like ISO17799
- The need to benchmark and assess performance against standards and peers
There has been a huge increase in the adoption of IT best practices in the last few years. There are a few reasons for this, but fundamentally its driven by a requirement for to improve the quality and reliability of IT in an organization which in turn is in response to a growing number of regulatory and contractual requirements.
IT best practices are important because:
- Management of IT is critical to the success of enterprise strategy.
- They help enable effective governance of IT activities.
- A management framework is needed so everyone knows what to do (policy, internal controls and defined practices).
- They provide many benefits, including efficiency gains, less reliance on experts, fewer errors, increased trust from business partners and respect from regulators.

IT Governance – Costly?
- It has the potential to be costly
- You need to keep it current (avoid shelfware)
- You need to train staff
- If you don’t understand *why* it is needed, you will fail
- Without board level buy-in, it will probably fail (then they will ask for it within 1 week)
- Should not be treated as technical guidance, but business guidance
There is a danger, however, that any implementation of these potentially helpful best practices will be costly and unfocused if they are treated as purely technical guidance.
Standards and best practices are not a panacea, and their effectiveness depends on several factors.
Firstly they have to be kept up to date. Implementing these standards is not a once off operation that is set and forget. In a lot of organizations it requires a high level of commitment, a change of mindset and importantly a change of habits. To deliver this, staff need the appropriate level of training and sometimes IT departments need to re-organize.
Note: IT departments historically are not well experienced with implementing IT best practice standards, however many other departments within an organization are. We will get into why this has to change (and is changing) further into the presentation.
Standards have to be applied within the business point of view, with the focus on where their use would provide the most benefit to the organization. That primarily is driven by financial considerations, which we will look into a little later.
Note: IT Departments generally are becoming more business focused, despite the relative inexperience when it comes to IT Compliance standards.
So for best practice standards to be effective, all the levels from business management, IT management, auditors, compliance officers, infrastructure and operational staff need to work together to make sure that IT best practices actually lead to cost-effective and well-controlled IT delivery.
The only way to get that level of buy-in and commitment often requires board or senior management level sponsorship. In this model, management have the clout to ‘make it happen’.
Best practice standards are most useful when applied as a set of principles and as a starting point for tailoring specific procedures. To avoid practices becoming ’shelfware’, management and staff must understand what to do, how to do it and why it is important.
Any implementation of best practice should be consistent with the any existing risk management and control framework. For example many engineering service companies certify to ISO9000/9001 for quality process. We do not want apply principles or practices that are not compatible with this.

You *will* be asked
- It is often not IT dept choice.
- Most likely it will come from board level based on business investments that have legislative requirements
- Its amazing how interested company directors become in compliance when they realize their personal liabilities!
More often than not, IT departments have best practice standards thrust upon them. This is particularly true for US and UK companies, but increasingly for Australian and EU companies as well. This is the often the least ideal situation, since the scope is probably bigger than you expect, the timeframe is less than you expect and the likelihood of a poor implementation is increased.
The main driver for this trend has been legislative and legal requirements put upon organizations. Often these requirements explicitly define Company directors liability.
Another big driver is competitive advantage. I have personally had two occasions where a client asked for implementation details of ISO17799. In both cases, we were completely unprepared for this and management naively thought I could knock it out in a couple of days!
In the next section we will look at the US legislation that has had the biggest impact on compliance standards in the last few years.

Sarbanes Oxley (SOX)
- Board level accountability in the wake of Enron/Worldcom type scandals
- Who’s affected: USA corporate subsidiaries, appointed auditors or financials advisors to these companies in Australia or Australian companies listing on the USA markets or those that have joint projects with US companies.
- Requirement that companies evaluate and disclose the effectiveness of their internal controls as they relate to financial reporting
- Directors directly liable for the companies they control.
- SOX recognizes COBIT as the methodology for assessing IT control effectiveness
The Sarbanes-Oxley Act is a significant piece of US federal legislation that was signed into law by President Bush on July 30, 2002 in response to corporate failures such as Enron, WorldCom and the many other corporate accounting scandals that have plagued the US in recent years. It is already having far reaching effects on US public companies, their management, auditors and procedures relating to reporting protocols to US regulatory authorities. The Act also applies to Australian companies and nationals with US parents or who have a significant business-to-business relationship with a publicly owned US company. Compliance to the act is compulsory and has significant repercussions for CFO’s, CEO’s, Board members and Directors of Australian companies. http://www.austrade.gov.au/australia/layout/0,,0_S2-1_1zg-2_2-3_PWB110371167-4_main-5_-6_-7_,00.html
The Sarbanes-Oxley Act’s major provisions include:
- Creation of the Public Company Accounting Oversight Board (PCAOB)
- A requirement that public companies evaluate and disclose the effectiveness of their internal controls as they relate to financial reporting, and that independent auditors for such companies “attest” (i.e., agree, or qualify) to such disclosure
- Certification of financial reports by chief executive officers and chief financial officers
- Auditor independence, including outright bans on certain types of work for audit clients and pre-certification by the company’s Audit Committee of all other non-audit work
- A requirement that companies listed on stock exchanges have fully independent audit committees that oversee the relationship between the company and its auditor
- Ban on most personal loans to any executive officer or director
- Additional disclosure
- Enhanced criminal and civil penalties for violations of securities law
- Significantly longer maximum jail sentences and larger fines for corporate executives who knowingly and willfully misstate financial statements, although maximum sentences are largely irrelevant because of the ability of judges to declare consecutive sentences under the Federal Sentencing Guidelines
COBIT was developed before SOX, and was given higher prominence when the SOX legislation recognized COBIT as the means to provide the assurance for IT internal controls.

It’s a US law, we are not affected!
- The European Union has been considering SOX type controls prior to US adoption of SOX (FSAP)
“Even with, or perhaps so, the three tiers of regulatory bodies in Europe, there are no pan-European requirements for specific internal controls. Given this fact, EU demand for SOX equivalent IT solutions is currently more limited than the US. Over the next three to five years, however, as member states fully embrace EU directives and regulations, the demand for country-compatible or regional IT compliance solutions is expected to grow. And, as Europe strives for higher investor confidence, there is the likelihood of additional, and perhaps more specific, requirements to come.
While EU codes are not as prescriptive as US laws, all of the guidance represents common bottom line goals. Companies will benefit if they can leverage internal experience with SOX by speaking to the benefit of technology in achieving compliance goals; that is, how specific applications and systems increase transparency, lock down network security, protect sensitive information, shore up financial reporting and ultimately improve all of the other business processes that support and justify investor confidence.
http://www.itcinstitute.com/display.aspx?id=466
EU Financial Services Action Plan (FSAP)
In June 1998, the Cardiff European Council invited the European Commission to table a framework for action to develop a single market in financial services. In May 1999, the Commission published a Communication containing a Financial Services Action Plan, which the Lisbon European Council endorsed in March 2000.
The FSAP is a set of 42 measures intended to fill gaps and remove barriers to create a legal and regulatory environment supporting the integration of EU financial markets by 2005. It has three aims:
- the creation of a single EU wholesale market for financial services and products;
- the creation of an open and secure financial retail market; and
- implementation of state of the art prudential rules and supervision

EU Law continued..
- The EU additionally has very strict privacy laws (Data Protection Directive 1998)
- Sector specific compliance: HIPAA, BASEL II
EU Data Protection Act
Personal data are defined as “any information relating to an identified or identifiable natural person (“data subject”); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;”
The notion processing means “any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction;” (art. 2 b)
Principles
Personal data should not be processed at all, except when certain conditions are met. These conditions fall into three categories: transparency, legitimate purpose and proportionality.
Transparency
The data subject has the right to be informed when his personal data are being processed. The controller must provide his name and address, the purpose of processing, the recipients of the data and all other information required to ensure the processing is fair. (art. 10 and 11)
Data may be processed only under the following circumstances (art. 7):
- when the data subject has given his consent
- when the processing is necessary for the performance of or the entering into a contract
- when processing is necessary for compliance with a legal obligation
- when processing is necessary in order to protect the vital interests of the data subject
- processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed
- processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject
The data subject has the right to access all data processed about him. The data subject even has the right to demand the rectification, deletion or blocking of data that is incomplete, inaccurate or isn’t being processed in compliance with the data protection rules. (art. 12)
Legitimate Purpose
Personal data can only be processed for specified, explicit and legitimate purposes and may not be processed further in a way incompatible with those purposes. (art. 6 b)
Proportionality
Personal data may be processed only insofar as it is adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed. The data shouldn’t be kept in a form which permits identification of data subjects for longer than is necessary for the purposes for which the data were collected or for which they are further processed. Member States shall lay down appropriate safeguards for personal data stored for longer periods for historical, statistical or scientific use. (art. 6)
Basel II
Basel II, also called The New Accord (correct full name is the International Convergence of Capital Measurement and Capital Standards – A Revised Framework) is the second Basel Accord and represents recommendations by bank supervisors and central bankers from the 13 countries making up the Basel Committee on Banking Supervision to revise the international standards for measuring the adequacy of a bank’s capital. It was created to promote greater consistency in the way banks and banking regulators approach risk management across national borders. The Bank for International Settlements (often confused with the BCBS) supplies the secretariat for the BCBS and is not itself the BCBS

The Australian Perspective
- Australian government has recognized the business cost of SOX type compliance and does not want to follow the US model
- DOCIT produced a “IT Security and Governance” whitepaper
- Corporations Act 2001. Uphold Due Care
- Privacy Act 1988 Protecting Information
- ATO 2005/9 Income Tax Record keeping
- ASX Principles of Good Corporate Governance
- AS 4360 Risk Management Framework
“SOX is seen by many organizations as a major cost to profit and manpower” (http://money.cnn.com/2006/03/21/news/companies/compliance_complaints/index.htm)
“A global study from European accountants Mazars, found that close to 20% of EU companies are planning to de-list from the US market to avoid complying and more than half feel the costs outweigh the benefits” http://www.laywersweekly.com.au/articles/9D/0C043D9D.asp?Type=53&Category=853
However this has the potential to impact on the cost of credit for such companies as warned in July 2006 by Moodys. “The cost of capital for public companies in countries that choose not to implement US Sarbanes-Oxley (SOX) type corporate governance rules may soon increase to reflect the additional risk premium resulting from companies and their auditors concealing the true level of audit risk”
At present the Australian government is not planning to introduce SOX type legislation, instead believing that the current regulatory provisions are adequate. Major legislation includes: Corporations Act 2001. Uphold Due Care, Privacy Act 1988 Protecting Information, ATO 2005/9 Income Tax Record keeping, ASX Principles of Good Corporate Governance, AS 4360 Risk Management Framework.
The Department of Communications, Information Technology and the Arts (DOCIT) on behalf of the Information Technology Security Expert Advisory Group (ITSEAG) engaged KPMG to produce a report on the governance of IT and information security matters for the corporate governance needs of Australian companies.
They identified 3 main observations to the risk landscape of ICT.
- There is a growing gap between the rate of technology adoption and the rate of controls adoption
- Convergence of technologies has led to a convergence of risk, greatly increasing the the potential impact to the business
- Increased dependences on technology has greatly increased the potential impacts in the event of failure.
They identified 3 main categories representing the greatest threats to critical infrastructure
- Human Error
- System Failure
- Malicious Software
They then define security governance as “implementing a culture of accountability in order for effective security management to take place”. They refer to the ISO17799 as the model for their “Enteprise Security Architecture Model”.
Note the use of the term accountability. It is a recurring theme across all best practice standards.

Why stop at one!
- COBIT v4
- ISO17799/ISO27001
- ITIL
- PMBOK
- SEI CMM
- COSO ERM
We have established that there are legislative/business reasons for best practice. But where to start?
- ITIL—Published by the UK government to provide best practices for IT service management
- COBIT—Published by ITGI and positioned as a high-level governance and control framework. COBIT stands for Control Objectives for Information and related Technology. IT Controls, measures, and processes
- ISO/IEC 17799—Published by the International Organization for Standardization (ISO) and International Electro technical Commission (IEC) and derived from the UK government’s BS 7799 to provide a framework of a standard for information security management Code of practice for information security management . It Security Best Practice
- PMBOK – Project Management Body of Knowledge . Project Management best practice (PMP certification)
- SEI CMM – Software Engineering Institute (SEI) Capability Maturity Model. Software Development Life Cycle
- COSO ERM – Committee of Sponsoring Organizations of the Treadway Commission. Enterprise risk management — Integrated Framework.

Framework Interaction
- The frameworks complement each-other
- Frameworks are vendor agnostic – no focus on tools
- Most frameworks are geared toward a specific subject
- PMBOK – Project Management
- SEI CMM – Software Engineering Maturity
- ISO17799/ISO27001 – Security Best Practice
- COBIT is a high level and considered the ‘umbrella’ connecting the others.
- We will look at COBIT and its relationship with ISO17799 and ITIL. PMBOK and SEI CMM will not be looked at

Framework Strengths
- COBIT is strong in IT controls and IT metrics (measurable). But it does not say how
- ISO17799 is strong in security controls but also does not say how
- ITIL is strong in IT processes (i.e. the how)
COBIT is based on established frameworks, such as the Software Engineering Institute’s Capability Maturity Model, ISO 9000, ITIL and ISO 17799. However, COBIT does not include process steps and tasks because, although it is oriented toward IT processes, it is a control and management framework rather than a process framework.
COBIT focuses on what an enterprise needs to do, not how it needs to do it. Across many aspects of an organizations activities, the board really doesn’t care about the ‘HOW’, they just want to see the ‘need’ addressed. Thus, target audience for COBIT is senior business management, senior IT management and auditors.
ITIL is based on defining best practice processes for IT service management and support, rather than on defining a broad-based control/measurement framework. It focuses on the methods and defines a more comprehensive set of processes.
Due to its high level and broad coverage and because it is based on many existing practices, COBIT is often referred to as the ‘integrator’, bringing disparate practices under one umbrella and, just as important, helping to link these various IT practices to business requirements.
ISO17799 is a more similar to COBIT than ITIL in that it is control driven, not process driven. However it is applied specifically to the area of IT security and thus drills down to a lower level than COBIT. The audience is also more focused from senior management/executive to IT and business unit management.

COBIT
- Business orientation is the main theme of COBIT
- 34 high-level control objectives
- Grouped into four domains:
- Plan and Organize
- Acquire and Implement
- Deliver and Support
- Monitor.
- IT governance guidance is also provided
- 318 Detailed control objectives (not today!)
- Maturity models, CSF, KGI, KPI
Business orientation is the main theme of COBIT. It is designed to be employed not only by users and auditors, but also, and more important, as comprehensive guidance for management and business process owners. Increasingly, business practice involves the full empowerment of business process owners so they have total responsibility for all aspects of the business process. In particular, this includes providing adequate controls. This basically means if the board is going to go down, they will take others with them!
The COBIT framework provides a tool for the business process owner that facilitates the discharge of this responsibility. The framework starts from a simple premise:
To provide the information that the organization needs to achieve its objectives, IT resources need to be managed by a set of naturally grouped processes.
From this premise, the framework continues with a set of 34 high-level control objectives, one for each “IT process”. These are grouped into four domains:
- Plan and Organize
- Acquire and Implement,
- Deliver and Support
- Monitor
By addressing these 34 high-level control objectives, the business process owner can ensure that an adequate control system is provided for the IT environment.
(note my use of the term *owner* – this theme is consistent across a lot of the frameworks)
IT governance guidance is also provided in the COBIT framework. IT governance provides the structure that links
- IT processes
- IT resources
- Information
to enterprise strategies and objectives.
“IT governance integrates optimal ways of planning and organizing, acquiring and implementing, delivering and supporting, and monitoring and evaluating IT performance. IT governance enables the enterprise to take full advantage of its information, thereby maximizing benefits, capitalizing on opportunities and gaining competitive advantage.”
In other words, it ensures accountability rests where it should. We will see a practical example of this in a later slide.

The governance guidelines further enhance and enable enterprise management to deal more effectively with the needs and requirements of IT governance.
The guidelines are action-oriented (activity goals) and generic, and they provide management direction for getting the enterprise’s information and related processes under control, monitoring achievement of organizational goals, monitoring performance within each IT process, and benchmarking organizational achievement.
In addition, corresponding to each of the 34 high-level control objectives is an audit guideline to enable the review of IT processes against COBIT’s 318 recommended detailed control objectives to provide management assurance and/or advice for improvement. So for example, one of the 34 high level objectives is “PO10 – Project Management.” That has 14 detailed control objectives defined.
Finally, COBIT provides maturity models for control over IT processes, so management can map where the organization is today, where it stands in relation to the best in class in its industry and to international standards, and where the organization wants to be. Critical success factors (CSF’s) define the most important management-oriented implementation guidelines to achieve control over and within its IT processes. Key goal indicators (KGI’s) define measures that tell management—after the fact—whether an IT process has achieved its business requirements. Key performance indicators (KPIs) are lead indicators that define measures of how well the IT process is performing in enabling the goal to be reached.
COBIT’s enables management to answer the following types of questions:
- How far should we go and is the cost justified by the benefit?
- What are the indicators of good performance?
- What are the critical success factors?
- What are the risks of not achieving our objectives?
- What do others do?
- How do we measure and compare?

- Business requirements translate into IT Processes
- IT Processes provide information to the business
- IT Processes are controlled by control objectives
- Control objectives are implemented with control practices
- Control objectives are translated into audit guidelines
- IT processes are audited by the audit guidelines
- IT processes are made effective and efficient with activity goals
- IT processes are measured by KPI’s for performance, KGI’s for outcomes and Maturity models for maturity

Each control objective will list the criteria that help organizations define their current ‘maturity model’ in accordance with COBiT definitions. We will see an example of this in future slides

COBIT Control Example
- Control AI3: Acquire and Maintain Technology Infrastructure
- AI = Acquire and Implement
- AI3 has 4 detailed control objectives
- AI3.1 Technological Infrastructure Acquisition Plan
- AI3.2 Infrastructure Resource Protection and Availability
- AI3.3 Infrastructure Maintenance
- AI3.4 Feasibility Test Environment
High level objective: AI3
Organizations should have processes for the acquisition, implementation and upgrade of the technology infrastructure. This requires a planned approach to acquisition, maintenance and protection of infrastructure in line with agreed technology strategies and the provision of development and test environments. This ensures that there is ongoing technological support for business applications.
AI3.1 Technological Infrastructure Acquisition Plan
Produce a plan for the acquisition, implementation and maintenance of the technological infrastructure that meets established business functional and technical requirements and is in accord with the organization’s technology direction. The plan should consider future flexibility for capacity additions, transition costs, technical risks and the lifetime of the investment for technology upgrades. Assess the complexity costs and the commercial viability of the vendor and product when adding new technical capability.
AI3.2 Infrastructure Resource Protection and Availability
Implement internal control, security and auditability measures during configuration, integration and maintenance of hardware and infrastructural software to protect resources and ensure availability and integrity. Responsibilities for using sensitive infrastructure components should be clearly defined and understood by those who develop and integrate infrastructure components. Their use should be monitored and evaluated.
AI3.3 Infrastructure Maintenance
Develop a strategy and plan for infrastructure maintenance and ensure that changes are controlled in line with the organization’s change management procedure. Include periodic review against business needs, patch management and upgrade strategies, risks, vulnerabilities assessment and security requirements.
AI3.4 Feasibility Test Environment
Establish development and test environments to support effective and efficient feasibility and integration testing of applications and infrastructure in the early stages of the acquisition and development process. Consider functionality, hardware and software configuration, integration and performance testing, migration between environments, version control, test data and tools, and security.

I have only listed 2 of the maturity models here but it gives you an idea of what is required even at the basic levels. Where does your employer fit here? ![]()

This where the accountability comes in.
- R: Responsible
- A: Accountable
- C: Consulted
- I: Informed
Accountability defines what activity goals exist for a high control and who has what accountability. For example:
“Define strategy and plan maintenance for infrastructure” understandably does not involve the CEO or CFO. The CIO is accountable – or the owner of this activity. Responsibility (custodianship) is shared between the roles of:
- Head Operations
- Chief Architect
- Head of Development
Compliance, Audit, Risk and Security personnel are to be informed of the activity goals.