Internal audit

Definition and brief background

Internal auditing is a profession and activity involved in helping organizations achieve their stated
objectives. It does this by using a systematic methodology for analyzing business processes,
procedures and activities with the goal of highlighting organizational problems and
recommending solutions. Professionals called internal auditors are employed by organizations to
perform the internal auditing activity.

The scope of internal auditing within an organization is broad and may involve topics such as the
efficacy of operations, the reliability of financial reporting, deterring and investigating fraud,
safeguarding assets, and compliance with laws and regulations.

Internal auditing frequently involves measuring compliance with the entity's policies and
procedures. However, Internal Auditors are not responsible for the execution of company
activities; they advise management and the Board of Directors (or similar oversight body)
regarding how to better execute their responsibilities. As a result of their broad scope of
involvement, internal auditors may have a variety of higher educational and professional
backgrounds.

Publicly-traded corporations typically have an internal auditing department, led by a Chief Audit
Executive ("CAE") who generally reports to the Audit Committee of the Board of Directors, with
administrative reporting to the Chief Executive Officer.

The profession is unregulated, though there are a number of international standard setting bodies,
an example of which is the Institute of Internal Auditors ("IIA"). The IIA has established
Standards for the Professional Practice of Internal Auditing and has over 150,000 members
representing 165 countries, including approximately 65,000 Certified Internal Auditors.

History of internal auditing

The Internal Auditing profession evolved steadily with the progress of management science after
World War II. It is conceptually similar in many ways to financial auditing by public accounting
firms, quality assurance and banking compliance activities. Much of the theory underlying
internal auditing is derived from management consulting and public accounting professions. With
the implementation in the United States of the Sarbanes-Oxley Act of 2002, the profession's
growth accelerated, as many internal auditors possess the skills required to help companies meet
the requirements of the law.

Organizational independence
To perform their role effectively, internal auditors require organizational independence from
management, to enable unrestricted evaluation of management activities and personnel. Although
internal auditors are part of company management and paid by the company, the primary
customer of internal audit activity is the entity charged with oversight of management's activities.
This is typically the Audit Committee, a sub-committee of the Board of Directors. To provide
independence, most Chief Audit Executives report to the Chairperson of the Audit Committee and
can only be replaced with the concurrence of that individual.

Role in internal control

Internal auditing activity is primarily directed at improving internal control. Under the COSO
Framework, internal control is broadly defined as 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 internal control categories:
Effectiveness and efficiency of operations.
Reliability of financial reporting.
Compliance with laws and regulations.
Management is responsible for internal control. Managers establish policies and processes to help
the organization achieve specific objectives in each of these categories. Internal auditors perform
audits to evaluate whether the policies and processes are designed and operating effectively and
provide recommendations for improvement.

Internal auditors may assist management with compliance with the Sarbanes-Oxley Act (SOX).

Role in risk management

Internal auditing professional standards require the function to monitor and evaluate the
effectiveness of the organization's Risk management processes. Risk management relates to how
an organization sets objectives, then identifies, analyzes, and responds to those risks that could
potentially impact its ability to realize its objectives.

Under the COSO enterprise risk management (ERM) Framework, risks fall under strategic,
operational, financial reporting, and legal/regulatory categories. Management performs risk
assessment activities as part of the ordinary course of business in each of these categories.
Examples include: strategic planning, marketing planning, capital planning, budgeting, hedging,
incentive payout structure, and credit/lending practices. Sarbanes-Oxley regulations also require
extensive risk assessment of financial reporting processes. Corporate legal counsel often prepares
comprehensive assessments of the current and potential litigation a company faces. Internal
auditors may evaluate each of these activities, or focus on the processes used by management to
report and monitor the risks identified. For example, internal auditors can advise management
regarding the reporting of forward-looking operating measures to the Board, to help identify
emerging risks.

In larger organizations, major strategic initiatives are implemented to achieve objectives and drive
changes. As a member of senior management, the Chief Audit Executive (CAE) may participate
in status updates on these major initiatives. This places the CAE in the position to report on many
of the major risks the organization faces to the Audit Committee, or ensure management's
reporting is effective for that purpose.
Internal auditors may help companies establish and maintain Enterprise Risk Management
processes. Internal auditors also play an important role in helping companies execute a SOX 404
top-down risk assessment. In these latter two areas, internal auditors typically are part of the
project team in an advisory role.

Role in corporate governance

Internal auditing activity as it relates to corporate governance is generally informal, accomplished
primarily through participation in meetings and discussions with members of the Board of
Directors. Corporate governance is a combination of processes and organizational structures
implemented by the Board of Directors to inform, direct, manage, and monitor the organization's
resources, strategies and policies towards the achievement of the organizations objectives. The
internal auditor is often considered one of the "four pillars" of corporate governance, the other
pillars being the Board of Directors, management, and the external auditor.

A primary focus area of internal auditing as it relates to corporate governance is helping the Audit
Committee of the Board of Directors (or equivalent) perform its responsibilities effectively. This
may include reporting critical internal control problems, informing the Committee privately on
the capabilities of key managers, suggesting questions or topics for the Audit Committee's
meeting agendas, and coordinating carefully with the external auditor and management to ensure
the Committee receives effective information.

Nature of the internal audit activity

Based on a risk assessment of the organization, internal auditors, management and oversight
Boards determine where to focus internal auditing efforts. Internal auditing activity is generally
conducted as one or more discrete projects. A typical internal audit project [7]involves the
following steps:
1. Establish and communicate the scope and objectives for the audit to appropriate
management.
2. Develop an understanding of the business area under review. This includes objectives,
measurements, and key transaction types. This involves review of documents and
interviews. Flowcharts and narratives may be created if necessary.
3. Describe the key risks facing the business activities within the scope of the audit.
4. Identify control procedures used to ensure each key risk and transaction type is properly
controlled and monitored.
5. Develop and execute a risk-based sampling and testing approach to determine whether
the most important controls are operating as intended.
6. Report problems identified and negotiate action plans with management to address the
problems.
7. Follow-up on reported findings at appropriate intervals. Internal audit departments
maintain a follow-up database for this purpose.
Project length varies based on the complexity of the activity being audited and Internal Audit
resources available. Many of the above steps are iterative and may not all occur in the sequence
indicated.

By analyzing and recommending business improvements in critical areas, auditors help the
organization meet its objectives. In addition to assessing business processes, specialists called
Information Technology (IT) Auditors review information technology controls.

Developing the plan of engagements

Internal auditing standards require the development of a plan of audit engagements (projects)
based on a risk assessment, updated at least annually. The input of senior management and the
Board is typically included in this process. Many departments update their plan of engagements
throughout the year as risks or organizational priorities change.

This effort helps ensure the audit activity is aligned with the organizations objectives, by
answering two key questions: First, what goals is the organization trying to accomplish in the
upcoming period? Second, how can the Internal Audit Department assist the organization in
achieving these goals?

Internal auditors often conduct a series of interviews of senior management to identify potential
engagements. Changes in people, processes, or systems often generate audit project ideas. Various
documents are reviewed, such as strategic plans, financial reports, consulting studies, etc. Further,
the results of prior audits and resolution of open issues are considered. For example, even if a
business area is important, prior audit work and the nature and status of open issues may render
further audit effort unnecessary. If the organization has a formal enterprise risk management
(ERM) program, the risks identified therein help limit the amount of separate risk assessment
performed by Internal Audit.

The preliminary plan of engagements is documented and prioritized. Audit resources and
expertise are then considered and a final plan is presented to senior management and the Audit
Committee. The presentations vary based on the needs of the stakeholders and may include the
following:
Summary of key goals, risks and corresponding major audits, to illustrate alignment;
Analyses of audit effort along a variety of dimensions (e.g., by business segment, COSO
objective category, IT, Sarbanes-Oxley, vs. prior year, etc.) along with commentary
regarding changes;
Brief description of critical projects identified;
Projects requested but not planned for execution due to prioritization and resources;
Required co-sourcing effort, typically where outside expertise is required or during peak
periods;
Coordination with other risk functions, such as legal, compliance or insurance, to ensure
coverage of key organizational risks;
Update on audit staffing levels, experience and certification; and
 Appendix materials, such as planning approach, assumptions (e.g., days per auditor and
staffing level) and brief descriptions of all planned audits and related prioritization.

Best Practices in Internal Auditing

Measuring the internal audit function

The measurement of the internal audit function can involve a balanced scorecard approach.[9]
Internal audit functions are primarily evaluated based on the quality of counsel and information
provided to the Audit Committee and top management. However, this is primarily qualitative and
therefore difficult to measure. Customer surveys sent to key managers after each audit project
or report can be used to measure performance, with an annual survey to the Audit Committee.
Scoring on dimensions such as professionalism, quality of counsel, timeliness of work product,
utility of meetings, and quality of status updates are typical with such surveys.

Quantitative measures can also be used to measure the functions level of execution and
qualifications of its personnel. Key measures include:

Plan completion: This is a measure of the degree to which the annual plan of
engagements is completed, measured at a point in time. This may be measured using the
number of projects completed, weighted by the planned size of each project, with
estimates for projects in-progress. Measured throughout the year, it is compared against
the percentage of the year elapsed.
Report issuance: This is a measure of the time elapsed from completion of testing to
issuance of the final audit report, including managements action plans. This can be
measured in average days or percentage of reports issued within a certain standard, such
as 30 days. Establishing expectations for the timing of managements response to report
recommendations is critical. In addition, the scope and degree of change involved in the
reports action plans are key variables. For example, a report for a single retail store
requiring only the store managers action might take 3-5 days to issue. However, a report
consolidating findings from 20 retail stores, with action plans with national implications
determined by top management, may take 30-60 days in complex organizations.
Issue closure: Reported audit findings are often called issues or deficiencies.
Professional standards require audit functions to track reported findings to resolution,
which effectively requires the maintenance of an issues follow-up database. The number
of days that reported issues remain open, or open after their agreed-upon closure date, are
key measures. In addition, reporting database statistics such as the number of issues open
(unresolved), closed (resolved), and issues opened/closed during a given period are useful
statistics.
Staff qualifications: This can be measured through the percentage of staff with
professional certifications, graduate degrees, and overall years of experience.
Staff utilization rate: This is measured as the percentage of time spent on projects, as
opposed to administrative time such as training or vacation. Many internal audit
 departments track time by audit project. This is typically captured in a database or
spreadsheet.
Staffing level: The number of positions filled relative to the authorized staffing level. Due
to the challenge of finding qualified staff, departments may have rotational programs to
bring in management to complete tours in the function or be "guest" auditors. Audit
departments also "co-source," meaning they obtain contract auditors from service
providers.

Developing and retaining staff

Developing and retaining quality professionals is a key concern in the profession. Key methods
for developing and retaining internal audit staff personnel include:
Providing challenging, varied assignments
Ensuring quality supervision
Ensuring staff participates in projects from start to finish, to learn all phases of the audit
process
Providing opportunities to lead (in-charge) projects, starting with more structured
projects such as Sarbanes-Oxley work
Participating on departmental improvement task forces, such as preparation for quality
assurance review
Participating in the recruiting and interviewing process for new hires
Rotating through various audit teams (in larger departments) or audits of various
businesses
Providing both outside training (e.g., seminars) and in-house training (e.g., company
systems) for two weeks/year
Participation in annual risk assessment activities, whether asking key questions or just
taking notes

Reporting of critical findings

The Chief Audit Executive (CAE) typically reports the most critical issues to the Audit
Committee quarterly, along with management's progress towards resolving them. Critical issues
typically have a reasonable likelihood of causing substantial financial or reputational damage to
the company. For particularly complex issues, the responsible manager may participate in the
discussion. Such reporting is critical to ensure the function is respected, that the proper "tone at
the top" exists in the organization, and to expedite resolution of such issues. It is a matter of
considerable judgment to select appropriate issues for the Audit Committee's attention and to
describe them in the proper context.

Audit Risk
Definition and brief background
Audit risk is a term that is commonly used in relation to the audit of the financial statements of an
entity. The primary objective of such an audit is to provide an opinion as to whether or not the
financial statements under audit present fairly the financial position, profit/loss and cash flows of
the entity.

Audit risk is the risk of the auditor providing an inappropriate opinion on the financial statements,
particularly when those financial statements contain a material misstatement. Of less concern is
the situation where the auditor states that the financial statements do not meet the standard of fair
presentation, when in fact they do.

Where audit risk fits into the audit process

Audit risk is assessed during the planning phase of the audit, and is a very important activity, as
the testing to be performed during the next phase of the audit (now referred to as the "putting the
plan into action phase", but essentially the testing phase) is determined in response to the risk
assessment. Note that, at this stage, the auditor has not yet done any testing, so his assessment of
risk is essentially a provisional one. During the testing phase, after testing the entity's control
system, the auditor has to consider if the control system is better or worse than expected during
the planning phase, and adjust his testing accordingly.

Having said the above, there are indications that the large auditing firms are shifting elements of
the risk assessment into the preliminary engagement phase of the audit (formerly referred to as
the pre-engagement phase), which refers to the phase where work is done prior to entering into a
contract with the then still prospective audit client. Firms are doing this to avoid involvement
with clients that may cause them reputational damage.

Risk is supposed to be assessed at two levels, being the financial statement level and the assertion
level. Risk at financial statement level refers to a risk factor that can produce a misstatement in
any one of a number of assertions, like the management of the entity being dishonest or
incompetent. Risk at assertion level refers to a risk factor that makes a misstatement of a specific
assertion more likely.

A contentious matter in this regard is the interplay between the determination of materiality and
risk assessment during the planning phase. Some sources state that risk should be assessed before
the determination of materiality, but the argument that materiality should be determined before
the risk assessment makes more sense, for the simple reason that the definition of audit risk
includes a reference to material misstatement. Hence, if the auditor has not yet determined
materiality, he will not be able to do a meaningful risk assessment.

The audit risk formula

Audit Risk = Inherent Risk x Control Risk x Detection Risk
The purpose of this equation is to calculate detection risk, which then indicates to the auditor how
much substantive testing he has to do to arrive at the acceptable audit risk. This is explained
below in more detail.
Components of the audit risk formula

Audit risk
In this context, audit risk (also referred to as residual risk) refers to acceptable audit risk, i.e. it
indicates the auditor's willingness to accept that the financial statements may be materially
misstated after the audit is completed and an unqualified (clean) opinion was issued. If the auditor
decides to lower audit risk, it means that he wants to be more certain that the financial statements
are not materially misstated.

Inherent risk
Inherent risk represents the auditor's assessment that there may be a material misstatement
relating to an assertion in the financial statements under audit, without taking the effectiveness of
the related internal controls into account . If the auditor concludes that there is a high likelihood
of such a misstatement, ignoring internal controls, he would assess the inherent risk as being
high. An example of inherent risk: the valuation of inventory is inherently more risky when the
type of inventory is difficult to value due to its nature, so the valuation of diamonds are inherently
much more risky than, say, tennis balls. Internal controls are ignored during the assessment of
inherent risk because they are considered when assessing another component of audit risk,
namely control risk.

The assessment of inherent risk (and also control risk) is an exercise that requires professional
judgement on the part of the auditor. Hence, two auditors assessing the same company may assess
the inherent and control risks differently, but it is to be expected that their assessments should be
in the same vicinity. Auditors express their risk assessment in one of two ways (and this goes for
all the components of the risk formula): as a percentage, or described as low, medium or high.

Control risk
Control risk represents the auditor's assessment of the likelihood that a material misstatement
relating to an assertion in the financial statements will not be detected and corrected, on a timely
basis, by the client's internal control system. To return to the example of an entity having an
inventory of diamonds, which is inherently risky in terms of valuation: if the entity has
competent, experienced valuers valuing its inventory, the control risk will be lower as compared
to a situation where incompetent people are tasked with performing that function. The product of
inherent risk and control risk is referred to as the Risk of Material Misstatement, and represents
the risk that the auditor adequately has to respond to when doing substantive testing. It is
permissable to do a combined assessment of inherent and control risk, instead of formally
separating the two components as done above.
Detection risk
Detection risk is defined as the likelihood that a material misstatement relating to an assertion
will not be detected by the auditor's substantive testing. It is important to note that the detection
risk indicates the detection risk that the auditor is willing to "live with", given the acceptable
audit risk and his assessment of inherent and control risk. This means that if the detection risk is
high, the auditor is willing to accept a high detection risk, and will do less substantive testing as
compared to a situation where the detection risk is lower.

Audit committee

Definition and brief background

In a publicly-held company, an audit committee is an operating committee of the Board of

Directors, typically charged with oversight of financial reporting and disclosure. Committee
members are drawn from members of the Company's board of directors, with a Chairperson
selected from among the members. An audit committee of a publicly-traded company in the
United States is composed of independent and outside directors referred to as non-executive
directors, at least one of which is typically a financial expert.

Audit committees are typically empowered to acquire the consulting resources and expertise
deemed necessary to perform their responsibilities. The role of audit committees continues to
evolve as a result of the passage of the Sarbanes-Oxley Act of 2002. Many audit committees also
have oversight of regulatory compliance and risk management activities. Not for profit entities
may also have an audit committee.

Responsibilities
Boards of Directors and their committees rely on management to run the daily operations of the
business. The Board's role is better described as oversight or monitoring, rather than execution.
Responsibilities of the audit committee typically include:
Overseeing the financial reporting and disclosure process.
Monitoring choice of accounting policies and principles.
Overseeing hiring, performance and independence of the external auditors.
Oversight of regulatory compliance, ethics, and whistleblower hotlines.
Monitoring the internal control process.
Overseeing the performance of the internal audit function.
Discussing risk management policies and practices with management.
The duties of an audit committee are typically described in a committee charter, often available
on the entity's website.

Role in oversight of financial reporting and accounting

Audit committees typically review financial reports quarterly and annually in publicly-traded
companies. In addition, members will often discuss complex accounting estimates and judgments
made by management and the implementation of new accounting principles or regulations. Audit
committees interact regularly with senior financial management such as the CFO and Controller
and are in a position to comment on the capabilities of these managers. Should significant
problems with accounting practices or personnel be identified or alleged, a special investigation
may be directed by the audit committee, using outside consulting resources as deemed necessary.

External auditors are also required to report to the committee on a variety of matters, such as their
views on management's selection of accounting principles, accounting adjustments arising from
their audits, any disagreement or difficulties encountered in working with management, and any
identified fraud or illegal acts.

Role in oversight of the external auditor

Audit committees typically approve selection of the external auditor. The external auditor (also
called a public accounting firm) reviews the entity's financial statements quarterly and issues an
opinion on the accuracy of the entity's annual financial statements. Changing an external auditor
typically also requires audit committee approval. Audit committees also help ensure the external
auditor is independent, meaning no conflicts of interest exist that might interfere with the
auditor's ability to issue its opinion on the financial statements.

Role in oversight of regulatory compliance

Audit committees discuss litigation or regulatory compliance risks with management, generally
via briefings or reports from the General Counsel, the top lawyer in the entity. Larger
corporations may also have a Chief Compliance Officer or Ethics Officer that report incidents or
risks related to the entity's code of conduct.

Role in monitoring the internal control process

Internal control includes the policies and practices used to control the operations, accounting, and
regulatory compliance of the entity. Management and both the internal auditing function and
external auditors provide reporting to the audit committee regarding the effectiveness and
efficiency of internal control.

Role in oversight of risk management

Organizations have a variety of functions that perform activities to understand and address risks
that threaten the achievement of the organization's objectives. The policies and practices used by
the entity to identify, prioritize, and respond to the risks (or opportunities) are typically discussed
with the audit committee. Having such a discussion is required for listing on the New York stock
exchange. Many organizations are developing their practices towards a goal of a risk-based
management approach called Enterprise risk management. Audit committee involvement in non-
financial risk topics varies significantly by entity. Dr. Ram Charan has argued for risk
management early warning systems at the corporate board level.

Impact of the Sarbanes-Oxley Act of 2002

The Sarbanes-Oxley Act of 2002 increased audit committees responsibilities and authority. It
raised membership requirements and committee composition to include more independent
directors. Companies were required to disclose whether or not a financial expert is on the
Committee. Further, the Securities and Exchange Commission and the stock exchanges proposed
new regulations and rules to strengthen audit committees.

Information technology audit

Definition and brief background
An information technology audit, or information systems audit, is an examination of the controls
within an Information technology (IT) infrastructure. An IT audit is the process of collecting and
evaluating evidence of an organization's information systems, practices, and operations.

The evaluation of obtained evidence determines if the information systems are safeguarding
assets, maintaining data integrity, and operating effectively and efficiently to achieve the
organization's goals or objectives. These reviews may be performed in conjunction with a
financial statement audit, internal audit, or other form of attestation engagement.

IT audits are also known as automated data processing (ADP) audits and computer audits. They
were formerly called electronic data processing (EDP) audits.
Purpose
An IT audit should not be confused with a financial statement audit. While there may be some
abstract similarities, a financial audit's primary purpose is to evaluate whether an organization is
adhering to standard accounting practices. The primary functions of an IT audit are to evaluate
the system's efficiency and security protocols, in particular, to evaluate the organization's ability
to protect its information assets and properly dispense information to authorized parties. The IT
audit's agenda may be summarized by the following questions:
Will the organization's computer systems be available for the business at all times when
required? (Availability)
Will the information in the systems be disclosed only to authorized users?
(Confidentiality)
Will the information provided by the system always be accurate, reliable, and timely?
(Integrity)

The IT audit focuses on determining risks that are relevant to information assets, and in assessing
controls in order to reduce or mitigate these risks. By implementing controls, the effect of risks
can be minimized, but cannot completely eliminate all risks.

Types of IT audits
Various authorities have created differing taxonomies to distinguish the various types of IT audits.
Goodman & Lawless state that there are three specific systematic approaches to carry out an IT
audit:
Technological innovation process audit. The aim of this audit is to construct a risk profile
for existing and new projects. The audit will assess the length and depth of the company's
experience in its chosen technologies, as well as its presence in relevant markets, the
organization of each project, and the structure of the portion of the industry that deals
with this project or product, organization and industry structure.
Innovative comparison audit. This audit, as its name implies, means conducting an
analysis of the innovative abilities of the company being audited, in comparison to its
competitors. This requires examination of company's research and development facilities,
as well as its track record in actually producing new products.
Technological position audit: This audit reviews the technologies that the business
currently has and that it needs to add. Technologies are characterized as being either
"base", "key", "pacing", or "emerging".

Others describe the spectrum of IT audits with five categories of audits:

Systems and Applications: An audit to verify that systems and applications are
appropriate, are efficient, and are adequately controlled to ensure valid, reliable, timely,
and secure input, processing, and output at all levels of a system's activity.
Information Processing Facilities: An audit to verify that the processing facility is
controlled to ensure timely, accurate, and efficient processing of applications under
normal and potentially disruptive conditions.
 Systems Development: An audit to verify that the systems under development meet the
objectives of the organization and to ensure that the systems are developed in accordance
with generally accepted standards for systems development.
Management of IT and Enterprise Architecture: An audit to verify that IT management
has developed an organizational structure and procedures to ensure a controlled and
efficient environment for information processing.
Client/Server, Telecommunications, Intranets, and Extranets: An audit to verify that
controls are in place on the client (computer receiving services), server, and on the
network connecting the clients and servers.

And some lump all IT audits as being one of only two type: "general control review" audits or
"application control review" audits.

The following are basic steps in performing the Information Technology Audit Process:
1. Planning
2. Studying and Evaluating Controls
3. Testing and Evaluating Controls
4. Reporting
5. Follow-up

Security
Auditing information security is a vital part of any IT audit. The broad scope of auditing
information security includes such topics as data centers (the physical security of data centers and
the logical security of databases), networks and application security. Like most technical realms,
these topics are always evolving; IT auditors must constantly continue to expand their knowledge
and understanding of the systems and environment& pursuit in system company.

History of IT Auditing
The concept of IT auditing was formed in the mid-1960s. Since that time, IT auditing has gone
through numerous changes, largely due to advances in technology and the incorporation of
technology into business.

International law regarding IT auditing

US Regulations and Legislation Related to IT Audits

Several information technology audit related laws and regulations have been introduced in the
United States since 1977. These include the Gramm-Leach-Bliley Act, the Sarbanes-Oxley Act,
the Health Insurance Portability and Accountability Act, the London Stock Exchange Combined
Code, King II, and the Foreign Corrupt Practices Act.
European Union Regulations and Legislation Related to IT Audits
Directive 95/46/EC on the protection of personal data exists primarily to ensure the
protection of the privacy of individuals in regards to digital information.
Audit Personnel

Qualifications
As the field is relatively young, not all jurisdictions have developed a pre-defined skill set that is
required when evaluating the qualifications of IT audit personnel. Since auditors will be
responsible for evaluating the controls affecting the recording and safekeeping of assets, it is
recommended that IT personnel have detailed knowledge regarding information systems with a
general understanding of accounting principles.

In the United States, usually it is considered desirable that IT audit personnel have received or
qualify to receive the Certified Information Systems Auditor (CISA), Certified Internal Auditor
(CIA), Certified Information Systems Security Professional (CISSP), Certified Public Accountant
(CPA), Diploma in Information System Audit (DISA from the Institute of Chartered Accountants
of India (ICAI-India)(ICAI)) and Certification and Accreditation Professional (CAP) credentials.

The CISM and CAP credentials are the two newest security auditing credentials, offered by the
ISACA and ISC2, respectively. Strictly speaking, only the CISA title would sufficiently
demonstrate competences regarding both information technology and audit aspects.

Outside of the US, various credentials exist, with differing value and safeguards of
professionalism. E.g., the Netherlands has the RE credential (as granted by the NOREA(Dutch
site) IT-auditors' association), which among others requires a post-graduate IT-audit education
from an accredited university, subscription to a Code of Ethics, and adherence to strict continuous
education requirements.

Professional certifications of note

Certified Information System Auditor (CISA)
Certified Internal Auditor (CIA)
Certification and Accreditation Professional (CAP)
Certified Computer Professional (CCP)
Certified Information Systems Security Professional (CISSP)
Certified Information Security Manager (CISM)
Certified Public Accountant (CPA)
Chartered Accountant (CA)
Chartered Certified Accountant (CCA)
ISO 27002 Lead Auditor (ISO/IEC27002)
Other employees involved in IT audits
Board of directors
Senior management
Audit management
External audit staff
Internal audit staff
Operations managers

Emerging Issues
Technology changes rapidly and so does the issues that IT auditors face. Some emerging issues
include biometric retinal scans, changes in physical security, and transmitting data from cell
phones.

Internal control

Brief background
In accounting and auditing, internal control is defined as a process effected by an organization's
structure, work and authority flows, people and management information systems, designed to
help the organization accomplish specific goals or objectives. It is a means by which an
organization's resources are directed, monitored, and measured. It plays an important role in
preventing and detecting fraud and protecting the organization's resources, both physical (e.g.,
machinery and property) and intangible (e.g., reputation or intellectual property such as
trademarks).

At the organizational level, internal control objectives relate to the reliability of financial
reporting, timely feedback on the achievement of operational or strategic goals, and compliance
with laws and regulations. At the specific transaction level, internal control refers to the actions
taken to achieve a specific objective (e.g., how to ensure the organization's payments to third
parties are for valid services rendered.) Internal control procedures reduce process variation,
leading to more predictable outcomes.

Internal control is a key element of the Foreign Corrupt Practices Act (FCPA) of 1977 and the
Sarbanes-Oxley Act of 2002, which required improvements in internal control in United States
public corporations. Internal controls within business entities are called also business controls.
Internal controls have existed from ancient times. In Hellenistic Egypt there was a dual
administration, with one set of bureaucrats charged with collecting taxes and another with
supervising them.
Definitions
There are many definitions of internal control, as it affects the various constituencies
(stakeholders) of an organization in various ways and at different levels of aggregation.

Under the COSO Internal Control-Integrated Framework, a widely-used framework in the United
States, internal control is broadly defined as 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: a) Effectiveness and efficiency of
operations; b) Reliability of financial reporting; and c) Compliance with laws and regulations.

COSO defines internal control as having five components:

1. Control Environment-sets the tone for the organization, influencing the control
consciousness of its people. It is the foundation for all other components of internal
control.
2. Risk Assessment-the identification and analysis of relevant risks to the achievement of
objectives, forming a basis for how the risks should be managed
3. Information and Communication-systems or processes that support the identification,
capture, and exchange of information in a form and time frame that enable people to
carry out their responsibilities
4. Control Activities-the policies and procedures that help ensure management directives are
carried out.
5. Monitoring-processes used to assess the quality of internal control performance over
time.

The COSO definition relates to the aggregate control system of the organization, which is
composed of many individual control procedures.

Discrete control procedures, or controls are defined by the SEC as: "...a specific set of policies,
procedures, and activities designed to meet an objective. A control may exist within a designated
function or activity in a process.

A controls impact...may be entity-wide or specific to an account balance, class of transactions or

application. Controls have unique characteristics for example, they can be: automated or
manual; reconciliations; segregation of duties; review and approval authorizations; safeguarding
and accountability of assets; preventing or detecting error or fraud. Controls within a process may
consist of financial reporting controls and operational controls (that is, those designed to achieve
operational objectives)."

Context
Under the COSO Framework, objective setting is considered a precondition to internal control.
By setting objectives, management can then identify risks to the achievement of those objectives.
To address these risks, management of organizations may implement specific internal controls.
The effectiveness of internal control can then be measured by how well the objectives are
achieved and how effectively the risks are addressed.

More generally, setting objectives, budgets, plans and other expectations establish criteria for
control. Control itself exists to keep performance or a state of affairs within what is expected,
allowed or accepted. Control built within a process is internal in nature. It takes place with a
combination of interrelated components - such as social environment effecting behavior of
employees, information necessary in control, and policies and procedures. Internal control
structure is a plan determining how internal control consists of these elements.

The concepts of corporate governance also heavily rely on the necessity of internal controls.
Internal controls help ensure that processes operate as designed and that risk responses (risk
treatments) in risk management are carried out. In addition, there needs to be in place
circumstances ensuring that the aforementioned procedures will be performed as intended: right
attitudes, integrity and competence, and monitoring by managers.

Roles and responsibilities in internal control

According to the COSO Framework, everyone in an organization has responsibility for internal
control to some extent. Virtually all employees produce information used in the internal control
system or take other actions needed to effect control. Also, all personnel should be responsible for
communicating upward problems in operations, noncompliance with the code of conduct, or other
policy violations or illegal actions. Each major entity in corporate governance has a particular
role to play:

Management: The Chief Executive Officer (the top manager) of the organization has
overall responsibility for designing and implementing effective internal control. More
than any other individual, the chief executive sets the "tone at the top" that affects
integrity and ethics and other factors of a positive control environment. In a large
company, the chief executive fulfills this duty by providing leadership and direction to
senior managers and reviewing the way they're controlling the business. Senior managers,
in turn, assign responsibility for establishment of more specific internal control policies
and procedures to personnel responsible for the unit's functions. In a smaller entity, the
influence of the chief executive, often an owner-manager, is usually more direct. In any
event, in a cascading responsibility, a manager is effectively a chief executive of his or
her sphere of responsibility. Of particular significance are financial officers and their
staffs, whose control activities cut across, as well as up and down, the operating and other
units of an enterprise.
Board of Directors: Management is accountable to the board of directors, which provides
governance, guidance and oversight. Effective board members are objective, capable and
inquisitive. They also have a knowledge of the entity's activities and environment, and
commit the time necessary to fulfill their board responsibilities. Management may be in a
position to override controls and ignore or stifle communications from subordinates,
enabling a dishonest management which intentionally misrepresents results to cover its
tracks. A strong, active board, particularly when coupled with effective upward
communications channels and capable financial, legal and internal audit functions, is
often best able to identify and correct such a problem.
 Auditors: The internal auditors and external auditors of the organization also measure the
effectiveness of internal control through their efforts. They assess whether the controls
are properly designed, implemented and working effectively, and make recommendations
on how to improve internal control. They may also review Information technology
controls, which relate to the IT systems of the organization. There are laws and
regulations on internal control related to financial reporting in a number of jurisdictions.
In the U.S. these regulations are specifically established by Sections 404 and 302 of the
Sarbanes-Oxley Act. Guidance on auditing these controls is specified in PCAOB
Auditing Standard No. 5 and SEC guidance, further discussed in SOX 404 top-down risk
assessment. To provide reasonable assurance that internal controls involved in the
financial reporting process are effective, they are tested by the external auditor (the
organization's public accountants), who are required to opine on the internal controls of
the company and the reliability of its financial reporting.

Limitations
Internal control can provide reasonable, not absolute, assurance that the objectives of an
organization will be met. The concept of reasonable assurance implies a high degree of assurance,
constrained by the costs and benefits of establishing incremental control procedures.
Effective internal control implies the organization generates reliable financial reporting and
substantially complies with the laws and regulations that apply to it.

However, whether an organization achieves operational and strategic objectives may depend on
factors outside the enterprise, such as competition or technological innovation. These factors are
outside the scope of internal control; therefore, effective internal control provides only timely
information or feedback on progress towards the achievement of operational and strategic
objectives, but cannot guarantee their achievement.

Internal control involves human action, which introduces the possibility of errors in processing or
judgment. Internal control can also be overridden by collusion among employees (see separation
of duties) or coercion by top management.

Describing Internal Controls

Internal controls may be described in terms of: a) the objective they pertain to; and b) the nature
of the control activity itself.

Objective categorization
Internal control activities are designed to provide reasonable assurance that particular objectives
are achieved, or related progress understood. The specific target used to determine whether a
control is operating effectively is called the control objective. Control objectives fall under
several detailed categories; in financial auditing, they relate to particular financial statement
assertions, but broader frameworks are helpful to also capture operational and compliance
aspects:
 1. Existence (Validity): Only valid or authorized transactions are processed (i.e., no invalid
transactions)
2. Occurrence (Cutoff): Transactions occurred during the correct period or were processed
timely.
3. Completeness: All transactions are processed that should be (i.e., no omissions)
4. Valuation: Transactions are calculated using an appropriate methodology or are
computationally accurate.
5. Rights & Obligations: Assets represent the rights of the company, and liabilities its
obligations, as of a given date.
6. Presentation & Disclosure (Classification): Components of financial statements (or other
reporting) are properly classified (by type or account) and described.
7. Reasonableness-transactions or results appears reasonable relative to other data or trends.

For example, a control objective for an accounts payable function might be: "Payments are only
made to authorized vendors for goods or services received." This is a validity objective. A typical
control procedure designed to achieve this objective is: "The accounts payable system compares
the purchase order, receiving record, and vendor invoice prior to authorizing payment."

Management is responsible for implementing appropriate controls that apply to transactions in

their areas of responsibility. Internal auditors perform their audits to evaluate whether the controls
are designed and implemented effectively to address the relevant objectives.

Activity categorization
Control activities may also be described by the type or nature of activity. These include (but are
not limited to):
Segregation of duties - separating authorization, custody, and record keeping roles to
limit risk of fraud or error by one person.
Authorization of transactions - review of particular transactions by an appropriate person.
Retention of records - maintaining documentation to substantiate transactions.
Supervision or monitoring of operations - observation or review of ongoing operational
activity.
Physical safeguards - usage of cameras, locks, physical barriers, etc. to protect property.
Analysis of results, periodic and regular operational reviews, metrics, and other key
performance indicators (KPIs).
IT Security - usage of passwords, access logs, etc. to ensure access restricted to
authorized personnel.

Control precision
Control precision describes the alignment or correlation between a particular control procedure
and a given control objective or risk. A control with direct impact on the achievement of an
objective (or mitigation of a risk) is said to be more precise than one with indirect impact on the
objective or risk. Precision is distinct from sufficiency; that is, multiple controls with varying
degrees of precision may be involved in achieving a control objective or mitigating a risk.
Precision is an important factor in performing a SOX 404 top-down risk assessment. After
identifying specific financial reporting material misstatement risks, management and the external
auditors are required to identify and test controls that mitigate the risks. This involves making
judgments regarding both precision and sufficiency of controls required to mitigate the risks.

Risks and controls may be entity-level or assertion-level under the PCAOB guidance. Entity-level
controls are identified to address entity-level risks. However, a combination of entity-level and
assertion-level controls are typically identified to address assertion-level risks. The PCAOB set
forth a three-level hierarchy for considering the precision of entity-level controls. [6] Later
guidance by the PCAOB regarding small public firms provided several factors to consider in
assessing precision.

Fraud and internal control

Internal control plays an important role in the prevention and detection of fraud. Under the
Sarbanes-Oxley Act, companies are required to perform a fraud risk assessment and assess related
controls. This typically involves identifying scenarios in which theft or loss could occur and
determining if existing control procedures effectively manages the risk to an acceptable level.
The risk that senior management might override important financial controls to manipulate
financial reporting is also a key area of focus in fraud risk assessment.

The AICPA, IIA, and ACFE also sponsored a guide published during 2008 that includes a
framework for helping organizations manage their fraud risk.

Internal Controls and Improvement

If the internal control system is implemented only to prevent fraud and comply with laws and
regulations, then an important opportunity is missed. The same internal controls can also be used
to systematically improve businesses, particularly in regard to effectiveness and efficiency.

Continuous Controls Monitoring

Advances in technology and data analysis have led to the development of numerous tools which
can automatically and continuously evaluate the effectiveness of internal controls. Used in
conjunction with continuous auditing, continuous controls monitoring provides assurance on
financial information flowing through the business processes.
Information systems

In a general sense, the term Information System (IS) refers to a system of people, data records
and activities that process the data and information in an organization, and it includes the
organization's manual and automated processes. In a narrow sense, the term information system
(or computer-based information system) refers to the specific application software that is used to
store data records in a computer system and automates some of the information-processing
activities of the organization. Computer-based information systems are in the field of information
technology. The discipline of business process modelling describes the business processes
supported by information systems.

Overview
There are various types of information systems, for example: transaction processing systems,
decision support systems, knowledge management systems, database management systems, and
office information systems. Critical to most information systems are information technologies,
which are typically designed to enable humans to perform tasks for which the human brain is not
well suited, such as: handling large amounts of information, performing complex calculations,
and controlling many simultaneous processes.

Information technologies are a very important and malleable resource available to executives. [1]
Many companies have created a position of Chief Information Officer (CIO) that sits on the
executive board with the Chief Executive Officer (CEO), Chief Financial Officer (CFO), Chief
Operating Officer (COO) and Chief Technical Officer (CTO).The CTO may also serve as CIO,
and vice versa. The Chief Information Security Officer (CISO), who focuses on information
security within an organization, normally reports to the CIO.

In computer security, an information system is described by the following components [2]:

Repositories, which hold data permanently or temporarily, such as buffers, RAM, hard
disks, cache, etc. Often data stored in repositories is managed through a database
management system.
Interfaces, which support the interaction between humans and computers, such as
keyboards, speakers, scanners, printers, etc.
Channels, which connect repositories, such as routers, cables, wireless links, etc.
Information systems careers
Information Systems have a number of different areas of work:
Information systems strategy
Information systems management
Information systems development
Information systems security

There are a wide variety of career paths in the information systems discipline. "Workers with
specialized technical knowledge and strong communications skills will have the best prospects.
People with management skills and an understanding of business practices and principles will
have excellent opportunities, as companies are increasingly looking to technology to drive their
revenue."

Types of information systems

As new information technologies are developed, new categories emerge that can be used to
classify information systems. Some examples are:
Transaction processing systems
Transaction processing systems(TPS)automate the handling of data about business
activities or transactions, which can be thought of as simple, discrete events in the life of
an organization. Data about each transaction are captured, transactions are verified and
accepted or rejected and validated transactions are stored for later aggregation. Reports
may be produced immediately to provide standard summarizations of transactions and
transactions may be moved from process to process in order to handle all aspects of the
business activity.

The analysis and design of TPS means focusing on the firms current procedures for
processing transactions, whether those procedures are manual or automated. The focus on
current procedures implies a careful tracking of data capture ,flow ,processing and output.
The goal of TPS development is to improve transaction processing by speeding it up,
using fewer people, improving efficiency and accuracy, integrating it with other
organizational information systems or providing information not previously available.

Management information systems

A management information system (MIS) is a subset of the overall internal controls of a
business covering the application of people, documents, technologies, and procedures by
management accountants to solving business problems such as costing a product, service
or a business-wide strategy. Management information systems are distinct from regular
information systems in that they are used to analyze other information systems applied in
operational activities in the organization.[1] Academically, the term is commonly used to
refer to the group of information management methods tied to the automation or support
of human decision making, e.g. Decision Support Systems, Expert systems, and
Executive information systems.
 It has been describe as, "MIS 'lives' in the space that intersects technology and business.
MIS combines tech with business to get people the information they need to do their jobs
better/faster/smarter. Information is the lifeblood of all organizations - now more than
ever. MIS professionals work as systems analysts, project managers, systems
administrators, etc., communicating directly with staff and management across the
organization."

Decision support systems

Decision Support Systems (DSS) are a specific class of computerized information
systems that supports business and organizational decision-making activities. A properly-
designed DSS is an interactive software-based system intended to help decision makers
compile useful information from raw data, documents, personal knowledge, and/or
business models to identify and solve problems and make decisions.

Typical information that a decision support application might gather and present would
be:
o an inventory of all of your current information assets (including legacy and relational
data sources, cubes, data warehouses, and data marts),
o comparative sales figures between one week and the next,
o projected revenue figures based on new product sales assumptions;
o the consequences of different decision alternatives, given past experience in a context
that is described.

Expert systems
An expert system is software that attempts to reproduce the performance of one or more
human experts, most commonly in a specific problem domain, and is a traditional
application and/or subfield of artificial intelligence. A wide variety of methods can be
used to simulate the performance of the expert however common to most or all are 1) the
creation of a so-called "knowledgebase" which uses some knowledge representation
formalism to capture the Subject Matter Experts (SME) knowledge and 2) a process of
gathering that knowledge from the SME and codifying it according to the formalism,
which is called knowledge engineering. Expert systems may or may not have learning
components but a third common element is that once the system is developed it is proven
by being placed in the same real world problem solving situation as the human SME,
typically as an aid to human workers or a supplement to some information system.

As a premiere application of computing and artificial intelligence, the topic of expert

systems has many points of contact with general systems theory, operations research,
business process reengineering and various topics in applied mathematics and
management science.

Office Automation
Office automation refers to the varied computer machinery and software used to digitally
create, collect, store, manipulate, and relay office information needed for accomplishing
 basic tasks and goals. Raw data storage, electronic transfer, and the management of
electronic business information comprise the basic activities of an office automation
system. Office automation helps in optimizing or automating existing office procedures.

The backbone of office automation is a LAN, which allows users to transmit data, mail
and even voice across the network. All office functions, including dictation, typing,
filing, copying, fax, Telex, microfilm and records management, telephone and telephone
switchboard operations, fall into this category. Office automation was a popular term in
the 1970s and 1980s as the desktop computer exploded onto the scene.

Business intelligence
Business intelligence (BI) refers to skills, technologies, applications and practices used to
help a business acquire a better understanding of its commercial context. Business
intelligence may also refer to the collected information itself.

BI technologies provide historical, current, and predictive views of business operations.

Common functions of business intelligence technologies are reporting, OLAP, analytics,
data mining, business performance management, benchmarks, text mining, and predictive
analytics.

Business intelligence often aims to support better business decision-making. [1] Thus a BI
system can be called a decision support system (DSS).[

Information systems development

Information technology departments in larger organizations tend to strongly influence
information technology development, use, and application in the organizations, which may be a
business or corporation. A computer based information system, following a definition of
Langefors, is:
a technologically implemented medium for recording, storing, and disseminating
linguistic expressions,
as well as for drawing conclusions from such expressions, which can be formulated
as a generalized information systems design mathematical program.

Information systems development methodology

Information systems development methodology or ISDM is a tool kit of ideas, approaches,
techniques and tools which system analysts use to help them translate organisational needs into
appropriate Information Systems;
An ISDM is:-
'....recommended collection of philosophies, phases, procedures, rules, techniques, tools,
documentation, management, and training for developers of Information Systems. (Avison and
Fitzgerald, 1988)
IT Structure

Many organizations staff other jobs related to systems administration. In a larger company, these
may all be separate positions within a computer support or Information Services (IS) department.
In a smaller group they may be shared by a few sysadmins, or even a single person.
A system administrator, systems administrator, or sysadmin, is a person employed to
maintain and operate a computer system and/or network. System administrators may be
members of an information technology department.
A database administrator (DBA) maintains a database system, and is responsible for the
integrity of the data and the efficiency and performance of the system.
 A network administrator maintains network infrastructure such as switches and routers,
and diagnoses problems with these or with the behavior of network-attached computers.
A security administrator is a specialist in computer and network security, including the
administration of security devices such as firewalls, as well as consulting on general
security measures.
A web administrator maintains web server services (such as Apache or IIS) that allow for
internal or external access to web sites. Tasks include managing multiple sites,
administering security, and configuring necessary components and software.
Responsibilities may also include software change management.
Technical support staff respond to individual users' difficulties with computer systems,
provide instructions and sometimes training, and diagnose and solve common problems.
A computer operator performs routine maintenance and upkeep, such as changing backup
tapes or replacing failed drives in a RAID. Such tasks usually require physical presence
in the room with the computer; and while less skilled than sysadmin tasks require a
similar level of trust, since the operator has access to possibly sensitive data.
Information technology controls

In business and accounting, Information technology controls (or IT controls) are specific
activities performed by persons or systems designed to ensure that business objectives are met.
They are a subset of an enterprise's internal control. IT control objectives relate to the
confidentiality, integrity, and availability of data and the overall management of the IT function of
the business enterprise.

IT controls are often described in two categories: IT general controls (ITGC) and IT application
controls.

ITGC include controls over the information technology (IT) environment, computer operations,
access to programs and data, program development and program changes. IT application controls
refer to transaction processing controls, sometimes called "input-processing-output" controls.
Information technology controls have been given increased prominence in corporations listed in
the United States by the Sarbanes-Oxley Act. The COBIT Framework (Control Objectives for
Information Technology) is a widely-used framework promulgated by the IT Governance
Institute, which defines a variety of ITGC and application control objectives and recommended
evaluation approaches. IT departments in organizations are often led by a Chief Information
Officer (CIO), who is responsible for ensuring effective information technology controls are
utilized.

IT General Controls (ITGC)

ITGC represent the foundation of the IT control structure. They help ensure the reliability of data
generated by IT systems and support the assertion that systems operate as intended and that
output is reliable. ITGC usually include the following types of controls:
Control Environment, or those controls designed to shape the corporate culture or "tone
at the top."
Change management procedures - controls designed to ensure changes meet business
requirements and are authorized.
 Source code/document version control procedures - controls designed to protect the
integrity of program code
Software development life cycle standards - controls designed to ensure IT projects are
effectively managed.
Security policies, standards and processes - controls designed to secure access based on
business need.
Incident management policies and procedures - controls designed to address operational
processing errors.
Technical support policies and procedures - policies to help users perform more
efficiently and report problems.
Hardware/software configuration, installation, testing, management standards, policies
and procedures.
Disaster recovery/backup and recovery procedures, to enable continued processing
despite adverse conditions.

IT Application Controls
IT application or program controls are fully-automated (i.e., performed automatically by the
systems) designed to ensure the complete and accurate processing of data, from input through
output. These controls vary based on the business purpose of the specific application. These
controls may also help ensure the privacy and security of data transmitted between applications.
Categories of IT application controls may include:
Completeness checks - controls that ensure all records were processed from initiation to
completion.
Validity checks - controls that ensure only valid data is input or processed.
Identification - controls that ensure all users are uniquely and irrefutably identified.
Authentication - controls that provide an authentication mechanism in the application
system.
Authorization - controls that ensure only approved business users have access to the
application system.
Problem management - controls that ensure all application problems are recorded and
managed in a timely manner.
Change management - controls that ensure all changes on production environment are
implemented with preserved data integrity.
Input controls - controls that ensure data integrity fed from upstream sources into the
application system.
IT Controls and the Chief Information Officer
Chief information officers are responsible for the security, accuracy and the reliability of the
systems that manage and report the company's data, including financial data. Financial
accounting and Enterprise Resource Planning systems are integrated in the initiating, authorizing,
processing, and reporting of financial data and may be involved in Sarbanes-Oxley compliance,
to the extent they mitigate specific financial risks.

Internal Control Frameworks - COBIT and COSO

COBIT
COBIT is a widely-utilized framework containing best practices for both ITGC and application
controls. It consists of domains and processes. The basic structure indicates that IT processes
satisfy business requirements, which is enabled by specific IT control activities. It also
recommends best practices and methods of evaluation of an enterprise's IT controls.

COSO
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) identifies
five components of internal control: control environment, risk assessment, control activities,
information and communication and monitoring, that need to be in place to achieve financial
reporting and disclosure objectives; COBIT provide a similar detailed guidance for IT, while the
interrelated Val IT concentrates on higher-level IT governance and value-for-money issues. The
five components of COSO can be visualized as the horizontal layers of a three-dimensional cube,
with the COBIT objective domains-applying to each individually and in aggregate. The four
COBIT major domains are: plan and organize, acquire and implement, deliver and support, and
monitor and evaluate.

IT controls and the Sarbanes-Oxley Act (SOX)

SOX requires the chief executive and chief financial officers of public companies to attest to the
accuracy of financial reports (Section 302) and require public companies to establish adequate
internal controls over financial reporting (Section 404). Passage of SOX resulted in an increased
focus on IT controls, as these support financial processing and therefore fall into the scope of
management's assessment of internal control under Section 404 of SOX.

The COBIT framework may be used to assist with SOX compliance, although COBIT is
considerably wider in scope. The 2007 SOX guidance from the PCAOB [1] and SEC[2] state that IT
controls should only be part of the SOX 404 assessment to the extent that specific financial risks
are addressed, which significantly reduces the scope of IT controls required in the assessment.
This scoping decision is part of the entity's SOX 404 top-down risk assessment. In addition,
Statements on Auditing Standards No. 109 (SAS109) [3] discusses the IT risks and control
objectives pertinent to a financial audit and is referenced by the SOX guidance.
IT controls that typically fall under the scope of a SOX 404 assessment may include:
Specific application (transaction processing) control procedures that directly mitigate
identified financial reporting risks. There are typically a few such controls within major
applications in each financial process, such as accounts payable, payroll, general ledger,
etc. The focus is on "key" controls (those that specifically address risks), not on the entire
application.
IT general controls that support the assertions that programs function as intended and that
key financial reports are reliable, primarily change control and security controls;
IT operations controls, which ensure that problems with processing are identified and
corrected.

Specific activities that may occur to support the assessment of the key controls above include:
Understanding the organizations internal control program and its financial reporting
processes.
Identifying the IT systems involved in the initiation, authorization, processing,
summarization and reporting of financial data;
Identifying the key controls that address specific financial risks;
Designing and implementing controls designed to mitigate the identified risks and
monitoring them for continued effectiveness;
Documenting and testing IT controls;
Ensuring that IT controls are updated and changed, as necessary, to correspond with
changes in internal control or financial reporting processes; and
Monitoring IT controls for effective operation over time.

To comply with Sarbanes-Oxley, organizations must understand how the financial reporting
process works and must be able to identify the areas where technology plays a critical part. In
considering which controls to include in the program, organizations should recognize that IT
controls can have a direct or indirect impact on the financial reporting process. For instance, IT
application controls that ensure completeness of transactions can be directly related to financial
assertions.

Access controls, on the other hand, exist within these applications or within their supporting
systems, such as databases, networks and operating systems, are equally important, but do not
directly align to a financial assertion. Application controls are generally aligned with a business
process that gives rise to financial reports. While there are many IT systems operating within an
organization, Sarbanes-Oxley compliance only focuses on those that are associated with a
significant account or related business process and mitigate specific material financial risks. This
focus on risk enables management to significantly reduce the scope of IT general control testing
in 2007 relative to prior years.
Section Title Description
Corporate Certifies that financial statement accuracy and operational
302 Responsibility for activities have been documented and provided to the CEO and
Financial Reports CFO for certification
404 Management Operational processes are documented and practiced
 Assessment of Internal
demonstrating the origins of data within the balance sheet
Controls
Public companies must disclose changes in their financial
Real-time Issuer
409 condition or operations in real time to protect investors from
Disclosures
delayed reporting of material events
Requires public companies and their public accounting firms to
retain records, including electronic records that impact the
companys assets or performance.
Criminal Penalties for
802 Fines and imprisonment for those who knowingly and willfully
Altering Documents
violate this section with respect to (1) destruction, alteration, or
falsification of records in federal investigations and bankruptcy
and (2) destruction of corporate audit records.

Real-time disclosure
Section 409 requires public companies to disclose information about material changes in their
financial condition or operations on a rapid basis. Companies need to determine whether their
existing financial systems, such as enterprise resource management applications are capable of
providing data in real time, or if the organization will need to add such capabilities or use
specialty software to access the data. Companies must also account for changes that occur
externally, such as changes by customers or business partners that could materially impact its own
financial positioning (e.g. key customer/supplier bankruptcy and default).

To comply with Section 409, organizations should assess their technological capabilities in the
following categories:
Availability of internal and external portals - Portals help route and identify reporting
issues and requirements to investors and other relevant parties. These capabilities address
the need for rapid disclosure.
Breadth and adequacy of financial triggers and alert - The organization sets the trip wires
that will kick off a Section 409 disclosure event.
Adequacy of document repositories Repositories play a critical role for event
monitoring to assess disclosure needs and provide mechanism to audit disclosure
adequacy.
Capacity to be an early adopter of Extensible Business Reporting Language (XBRL)
XBRL will be a key tool to integrate and interface transactional systems, reporting and
analytical tools, portals and repositories.

Section 802 & Records retention

Section 802 of Sarbanes-Oxley requires public companies and their public accounting firms to
maintain all audit or review work papers for a period of five years from the end of the fiscal
period in which the audit or review was concluded. This includes electronic records which are
created, sent, or received in connection with an audit or review. As external auditors rely to a
certain extent on the work of internal audit, it would imply that internal audit records must also
comply with Section 802.
In conjunction with document retention, another issue is that of the security of storage media and
how well electronic documents are protected for both current and future use. The five-year record
retention requirement means that current technology must be able to support what was stored five
years ago. Due to rapid changes in technology, some of todays media might be outdated in the
next three or five years. Audit data retained today may not be retrievable not because of data
degradation, but because of obsolete equipment and storage media.

Section 802 expects organizations to respond to questions on the management of SOX content.
IT-related issues include policy and standards on record retention, protection and destruction,
online storage, audit trails, integration with an enterprise repository, market technology, SOX
software and more. In addition, organizations should be prepared to defend the quality of their
records management program (RM); comprehensiveness of RM (i.e. paper, electronic,
transactional communications, which includes emails, instant messages, and spreadsheets that are
used to analyze financial results) , adequacy of retention life cycle, immutability of RM practices,
audit trails and the accessibility and control of RM content.

End-user application / Spreadsheet controls

PC-based spreadsheets or databases are often used to provide critical data or calculations related
to financial risk areas within the scope of a SOX 404 assessment. Financial spreadsheets are often
categorized as end-user computing (EUC) tools that have historically been absent traditional IT
controls. They can support complex calculations and provide significant flexibility. However,
with flexibility and power comes the risk of errors, an increased potential for fraud, and misuse
for critical spreadsheets not following the software development lifecycle (e.g. design, develop,
test, validate, deploy).

To remediate and control spreadsheets, public organizations may implement controls such as:
Inventory and risk-rank spreadsheets that are related to critical financial risks identified
as in-scope for SOX 404 assessment. These typically relate to the key estimates and
judgments of the enterprise, where sophisticated calculations and assumptions are
involved. Spreadsheets used merely to download and upload are less of a concern.
Perform a risk based analysis to identify spreadsheet logic errors. Automated tools exist
for this purpose.
Ensure the spreadsheet calculations are functioning as intended (i.e., "baseline" them).
Ensure changes to key calculations are properly approved.

Responsibility for control over spreadsheets is a shared responsibility with the business users and
IT. The IT organization is typically concerned with providing a secure shared drive for storage of
the spreadsheets and data backup. The business personnel are responsible for the remainder.
Database management system

A database management system (DBMS) is computer software that manages databases. DBMSes
may use any of a variety of database models, such as the network model or relational model. In
large systems, a DBMS allows users and other software to store and retrieve data in a structured
way.

Overview
A DBMS is a set of software programs that controls the organization, storage, management, and
retrieval of data in a database. DBMS are categorized according to their data structures or types.
It is a set of prewritten programs that are used to store, update and retrieve a Database. The
DBMS accepts requests for data from the application program and instructs the operating system
to transfer the appropriate data. When a DBMS is used, information systems can be changed
much more easily as the organization's information requirements change. New categories of data
can be added to the database without disruption to the existing system.

Organizations may use one kind of DBMS for daily transaction processing and then move the
detail onto another computer that uses another DBMS better suited for random inquiries and
analysis. Overall systems design decisions are performed by data administrators and systems
analysts. Detailed database design is performed by database administrators.

Database servers are computers that hold the actual databases and run only the DBMS and related
software. Database servers are usually multiprocessor computers, with generous memory and
RAID disk arrays used for stable storage. Connected to one or more servers via a high-speed
channel, hardware database accelerators are also used in large volume transaction processing
environments. DBMSs are found at the heart of most database applications. Sometimes DBMSs
are built around a private multitasking kernel with built-in networking support although
nowadays these functions are left to the operating system.

History
Databases have been in use since the earliest days of electronic computing. Unlike modern
systems which can be applied to widely different databases and needs, the vast majority of older
systems were tightly linked to the custom databases in order to gain speed at the expense of
flexibility. Originally DBMSs were found only in large organizations with the computer hardware
needed to support large data sets.

1960s Navigational DBMS

As computers grew in capability, this trade-off became increasingly unnecessary and a number of
general-purpose database systems emerged; by the mid-1960s there were a number of such
systems in commercial use. Interest in a standard began to grow, and Charles Bachman, author of
one such product, Integrated Data Store (IDS), founded the "Database Task Group" within
CODASYL, the group responsible for the creation and standardization of COBOL. In 1971 they
delivered their standard, which generally became known as the "Codasyl approach", and soon
there were a number of commercial products based on it available.

The Codasyl approach was based on the "manual" navigation of a linked data set which was
formed into a large network. When the database was first opened, the program was handed back a
link to the first record in the database, which also contained pointers to other pieces of data. To
find any particular record the programmer had to step through these pointers one at a time until
the required record was returned. Simple queries like "find all the people in India" required the
program to walk the entire data set and collect the matching results. There was, essentially, no
concept of "find" or "search". This might sound like a serious limitation today, but in an era when
the data was most often stored on magnetic tape such operations were too expensive to
contemplate anyway.

IBM also had their own DBMS system in 1968, known as IMS. IMS was a development of
software written for the Apollo program on the System/360. IMS was generally similar in concept
to Codasyl, but used a strict hierarchy for its model of data navigation instead of Codasyl's
network model. Both concepts later became known as navigational databases due to the way data
was accessed, and Bachman's 1973 Turing Award award presentation was The Programmer as
Navigator. IMS is classified as a hierarchical database. IDS and IDMS, both CODASYL
databases, as well as CINCOMs TOTAL database are classified as network databases.

1970s Relational DBMS

Edgar Codd worked at IBM in San Jose, California, in one of their offshoot offices that was
primarily involved in the development of hard disk systems. He was unhappy with the
navigational model of the Codasyl approach, notably the lack of a "search" facility which was
becoming increasingly useful. In 1970, he wrote a number of papers that outlined a new approach
to database construction that eventually culminated in the groundbreaking A Relational Model of
Data for Large Shared Data Banks.

In this paper, he described a new system for storing and working with large databases. Instead of
records being stored in some sort of linked list of free-form records as in Codasyl, Codd's idea
was to use a "table" of fixed-length records. A linked-list system would be very inefficient when
storing "sparse" databases where some of the data for any one record could be left empty. The
relational model solved this by splitting the data into a series of normalized tables, with optional
elements being moved out of the main table to where they would take up room only if needed.
In the relational model, related records are linked together with a "key".

For instance, a common use of a database system is to track information about users, their name,
login information, various addresses and phone numbers. In the navigational approach all of these
data would be placed in a single record, and unused items would simply not be placed in the
database. In the relational approach, the data would be normalized into a user table, an address
table and a phone number table (for instance). Records would be created in these optional tables
only if the address or phone numbers were actually provided.

Linking the information back together is the key to this system. In the relational model, some bit
of information was used as a "key", uniquely defining a particular record. When information was
being collected about a user, information stored in the optional (or related) tables would be found
by searching for this key. For instance, if the login name of a user is unique, addresses and phone
numbers for that user would be recorded with the login name as its key. This "re-linking" of
related data back into a single collection is something that traditional computer languages are not
designed for.

Just as the navigational approach would require programs to loop in order to collect records, the
relational approach would require loops to collect information about any one record. Codd's
solution to the necessary looping was a set-oriented language, a suggestion that would later
spawn the ubiquitous SQL. Using a branch of mathematics known as tuple calculus, he
demonstrated that such a system could support all the operations of normal databases (inserting,
updating etc.) as well as providing a simple system for finding and returning sets of data in a
single operation.

Codd's paper was picked up by two people at the Berkeley, Eugene Wong and Michael
Stonebraker. They started a project known as INGRES using funding that had already been
allocated for a geographical database project, using student programmers to produce code.
Beginning in 1973, INGRES delivered its first test products which were generally ready for
widespread use in 1979. During this time, a number of people had moved "through" the group
perhaps as many as 30 people worked on the project, about five at a time. INGRES was similar to
System R in a number of ways, including the use of a "language" for data access, known as
QUEL QUEL was in fact relational, having been based on Codd's own Alpha language, but
has since been corrupted to follow SQL, thus violating much the same concepts of the relational
model as SQL itself.

IBM itself did only one test implementation of the relational model, PRTV, and a production one,
Business System 12, both now discontinued. Honeywell did MRDS for Multics, and now there
are two new implementations: Alphora Dataphor and Rel. All other DBMS implementations
usually called relational are actually SQL DBMSs. In 1968, the University of Michigan began
development of the Micro DBMS relational database management system. It was used to manage
very large data sets by the US Department of Labor, the Environmental Protection Agency and
researchers from University of Alberta, the University of Michigan and Wayne State University. It
ran on mainframe computers using Michigan Terminal System. The system remained in
production until 1996.

End 1970s SQL DBMS

IBM started working on a prototype system loosely based on Codd's concepts as System R in the
early 1970s. The first "quickie" version was ready in 1974/5, and work then started on multi-table
systems in which the data could be broken down so that all of the data for a record (much of
which is often optional) did not have to be stored in a single large "chunk". Subsequent multi-user
versions were tested by customers in 1978 and 1979, by which time a standardized query
language, SQL, had been added. Codd's ideas were establishing themselves as both workable and
superior to Codasyl, pushing IBM to develop a true production version of System R, known as
SQL/DS, and, later, Database 2 (DB2).

Many of the people involved with INGRES became convinced of the future commercial success
of such systems, and formed their own companies to commercialize the work but with an SQL
interface. Sybase, Informix, NonStop SQL and eventually Ingres itself were all being sold as
offshoots to the original INGRES product in the 1980s. Even Microsoft SQL Server is actually a
re-built version of Sybase, and thus, INGRES. Only Larry Ellison's Oracle started from a
different chain, based on IBM's papers on System R, and beat IBM to market when the first
version was released in 1978.

Stonebraker went on to apply the lessons from INGRES to develop a new database, Postgres,
which is now known as PostgreSQL. PostgreSQL is primarily used for global mission critical
applications (the .org and .info domain name registries use it as their primary data store, as do
many large companies and financial institutions).

In Sweden, Codd's paper was also read and Mimer SQL was developed from the mid-70s at
Uppsala University. In 1984, this project was consolidated into an independent enterprise. In the
early 1980s, Mimer introduced transaction handling for high robustness in applications, an idea
that was subsequently implemented on most other DBMS.

DBMS building blocks

A DBMS includes four main parts: modeling language, data structure, database query language,
and transaction mechanisms:
Modeling language
A data modeling language to define the schema of each database hosted in the DBMS, according
to the DBMS database model. The four most common types of organizations are the:
hierarchical model,
network model,
relational model, and
object model.
Inverted lists and other methods are also used. A given database management system may provide
one or more of the four models. The optimal structure depends on the natural organization of the
application's data, and on the application's requirements (which include transaction rate (speed),
reliability, maintainability, scalability, and cost).

The dominant model in use today is the ad hoc one embedded in SQL, despite the objections of
purists who believe this model is a corruption of the relational model, since it violates several of
its fundamental principles for the sake of practicality and performance. Many DBMSs also
support the Open Database Connectivity API that supports a standard way for programmers to
access the DBMS.

Data structure
Data structures (fields, records, files and objects) optimized to deal with very large amounts of
data stored on a permanent data storage device (which implies relatively slow access compared to
volatile main memory).

Database query language

A database query language and report writer allows users to interactively interrogate the database,
analyze its data and update it according to the users privileges on data. It also controls the
security of the database. Data security prevents unauthorized users from viewing or updating the
database. Using passwords, users are allowed access to the entire database or subsets of it called
subschemas. For example, an employee database can contain all the data about an individual
employee, but one group of users may be authorized to view only payroll data, while others are
allowed access to only work history and medical data.

If the DBMS provides a way to interactively enter and update the database, as well as interrogate
it, this capability allows for managing personal databases. However, it may not leave an audit trail
of actions or provide the kinds of controls necessary in a multi-user organization. These controls
are only available when a set of application programs are customized for each data entry and
updating function.
Transaction mechanism
A database transaction mechanism ideally guarantees ACID properties in order to ensure data
integrity despite concurrent user accesses (concurrency control), and faults (fault tolerance). It
also maintains the integrity of the data in the database. The DBMS can maintain the integrity of
the database by not allowing more than one user to update the same record at the same time. The
DBMS can help prevent duplicate records via unique index constraints; for example, no two
customers with the same customer numbers (key fields) can be entered into the database. See
ACID properties for more information (Redundancy avoidance).

DBMS Topics

Logical and physical view

Traditional View of Data

A database management system provides the ability for many different users to share data and
process resources. But as there can be many different users, there are many different database
needs. The question now is: How can a single, unified database meet the differing requirement of
so many users?

A DBMS minimizes these problems by providing two views of the database data: a logical
(external) view and physical (internal) view. The logical view/users view, of a database program
represents data in a format that is meaningful to a user and to the software programs that process
those data. That is, the logical view tells the user, in user terms, what is in the database. The
physical view deals with the actual, physical arrangement and location of data in the direct access
storage devices(DASDs). Database specialists use the physical view to make efficient use of
storage and processing resources. With the logical view users can see data differently from how
they are stored, and they do not want to know all the technical details of physical storage. After
all, a business user is primarily interested in using the information, not in how it is stored.
One strength of a DBMS is that while there is only one physical view of the data, there can be an
endless number of different logical views. This feature allows users to see database information in
a more business-related way rather than from a technical, processing viewpoint. Thus the logical
view refers to the way user views data, and the physical view to the way the data are physically
stored and processed...

DBMS Features and capabilities

Alternatively, and especially in connection with the relational model of database management, the
relation between attributes drawn from a specified set of domains can be seen as being primary.
For instance, the database might indicate that a car that was originally "red" might fade to "pink"
in time, provided it was of some particular "make" with an inferior paint job. Such higher arity
relationships provide information on all of the underlying domains at the same time, with none of
them being privileged above the others.

Throughout recent history specialized databases have existed for scientific, geospatial, imaging,
document storage and like uses. Functionality drawn from such applications has lately begun
appearing in mainstream DBMSs as well. However, the main focus there, at least when aimed at
the commercial data processing market, is still on descriptive attributes on repetitive record
structures.

Thus, the DBMSs of today roll together frequently-needed services or features of attribute
management. By externalizing such functionality to the DBMS, applications effectively share
code with each other and are relieved of much internal complexity. Features commonly offered
by database management systems include:

Query ability
Querying is the process of requesting attribute information from various perspectives and
combinations of factors. Example: "How many 2-door cars in Texas are green?" A database
query language and report writer allow users to interactively interrogate the database, analyze
its data and update it according to the users privileges on data.
Backup and replication
Copies of attributes need to be made regularly in case primary disks or other equipment fails.
A periodic copy of attributes may also be created for a distant organization that cannot readily
access the original. DBMS usually provide utilities to facilitate the process of extracting and
disseminating attribute sets. When data is replicated between database servers, so that the
information remains consistent throughout the database system and users cannot tell or even
know which server in the DBMS they are using, the system is said to exhibit replication
transparency.
Rule enforcement
Often one wants to apply rules to attributes so that the attributes are clean and reliable. For
example, we may have a rule that says each car can have only one engine associated with it
(identified by Engine Number). If somebody tries to associate a second engine with a given
car, we want the DBMS to deny such a request and display an error message. However, with
changes in the model specification such as, in this example, hybrid gas-electric cars, rules
may need to change. Ideally such rules should be able to be added and removed as needed
without significant data layout redesign.
Security
 Often it is desirable to limit who can see or change which attributes or groups of attributes.
This may be managed directly by individual, or by the assignment of individuals and
privileges to groups, or (in the most elaborate models) through the assignment of individuals
and groups to roles which are then granted entitlements.
Computation
There are common computations requested on attributes such as counting, summing,
averaging, sorting, grouping, cross-referencing, etc. Rather than have each computer
application implement these from scratch, they can rely on the DBMS to supply such
calculations.
Change and access logging
Often one wants to know who accessed what attributes, what was changed, and when it was
changed. Logging services allow this by keeping a record of access occurrences and changes.
Automated optimization
If there are frequently occurring usage patterns or requests, some DBMS can adjust
themselves to improve the speed of those interactions. In some cases the DBMS will merely
provide tools to monitor performance, allowing a human expert to make the necessary
adjustments after reviewing the statistics collected.

Meta-data repository
Metadata is data describing data. For example, a listing that describes what attributes are allowed
to be in data sets is called "meta-information". The meta-data is also known as data about data.

Examples of Database Management Systems

Adabas
Adaptive Server Enterprise
Alpha Five
Computhink's ViewWise
CSQL
Daffodil DB
DataEase
FileMaker
Firebird
Glom
IBM DB2
IBM UniVerse
Ingres
Informix
InterSystems Cach
Kexi
Linter SQL RDBMS
Mark Logic
Microsoft Access
Microsoft SQL Server