All ContentHow Sarbanes-Oxley Act (SOX) Compliance is Impossible without Identity Governance and Access Management
How Sarbanes-Oxley Act (SOX) Compliance is Impossible without Identity Governance and Access Management
Organizations
must reduce
opportunities
for financial
data tampering,
control who has
access to financial
information,
monitor all
transactions that
affect financial
data and more.
disclosures and their relevant
assertions and, when applicable,
to select the controls to test,
as well as to assess risk and
allocate audit effort.”
The impact on corporate IT
The trend towards using
technology in virtually every
step of the process of producing
financial statements and offbalance-sheet records, combined
with this pressure on audit firms
to provide additional evidence
of IT control operation, has in
turn placed pressure on public
companies to identify, collect and
provide more evidence of effective
IT general controls (ITGCs). Now
more than ever, IT departments
of public companies need to be
ready to provide evidence of
effective IT general controls to
their external audit firms.
3
What does this entail? SOX ITGCs,
which are implied in section
302 and 404 of the Act, include
both basic and enterprise-wide
IT security controls that require
organizations to:
• Reduce opportunities for
financial data tampering — A
good strategy would include
applying a disciplined process of
enforcing formal access requests
and reviews of all changes
to roles and responsibilities
with access to financial data;
requiring regularly updated
attestations by managers that
such access is authorized; and
requiring that the requests and
approvals for such access, and
the related attestations, be
logged. The organization should
also define who is authorized
to approve access to both the
modules within the financial
systems and the applications and
servers that provide access to
unstructured data, such as file
servers, SharePoint servers, NAS
devices and print servers.
• Reduce opportunities for
reporting period tampering
— For example, organizations
can enforce risk-based privileged
user identity consolidation and
cleanup by requiring IT personnel
to attest on a regular basis that
3
individuals with access to the
operating system level of the
financial data environment have
a single user identity across all
systems; this group would include
all system administrators, as well
as other users with reportingperiod, system-clock or timestamp edit privileges. In addition,
the organization should ensure
that such users are assigned a risk
profile in relation to their ability
to modify the timing of historical
information, that risk-based audits
include an evaluation of all system
time change events traced to
specific users, that the accounts of
such users are monitored for this
risk, and that when the users leave
the organization, their accounts
are deactivated in a timely fashion.
• Control who had access to
specific financial data and when
— Organizations can implement
entity level controls (ELCs) and
ITGCs such as:
• Preventative and detective
controls around employee
privileges that pose conflicts of
interest, such a segregation of
duties (SoD) and
least privilege (LP), and those
that could perpetuate fraud,
such as mandatory vacations
and role reassignments
• Risk profiles for users with
access to financial data that
reflect their ability to hide
fraud, based on factors such
as continuous days without
vacation or role reassignment
• Ongoing monitoring by
management of financial data
access approvals
• A running history of all
potential access to financial
data and applications, as well
as programs and devices that
record, transmit or store activity
on systems containing financial
data. This history should include
possible access periods and
access levels for each individual,
along with a record of what
authorizations were granted and
who granted them.
• Monitor automated
transactions that affect
financial data — Examples
include inventory movements
and account reconciliations.
The user access controls included in business
financial applications provide only a portion
of the security you need to achieve, maintain
and demonstrate SOX ICFR compliance.
• Monitor manual transactions
— This includes post-closing
journal entries.
• Ensure ongoing effectiveness
of controls — For example,
organizations should actively
review all suspicious events
occurring within their IT systems
and provide their external auditors
the results of this process.
Risks that every
organization should assess
While the text of the Sarbanes
Oxley Act does not specifically
mention internal controls for
access to financial data, it’s clear
across all industries that an
issuer’s signing officers cannot
assert that their company has
an effective system of internal
controls without ensuring
properly controlled access to their
financial data, via both financial
applications and the underlying
infrastructure. For financial
data access to be properly
controlled, at a minimum, all
public companies must assess
the following risks:
• Lack of separation of
development and test
environments from the live
production environment,
including but not limited to
proper network segmentation
and controls around changes in
the production environment
• Unauthorized or unmonitored
access to financial data the
company relies on or could
potentially rely on when
preparing its financial statements
4
• Unmonitored significant financial
transactions, financial data
updates and related system
controls at the application,
database, operating system,
hypervisor, network device
and hardware level (including
connections from all possible
accessing devices)
• The abuse of system accounts
and utility programs
• Unauthorized, unmonitored or
uncontrolled modifications to
source code
• The use of weak passwords,
default passwords, static
passwords, unencrypted stored
or transmitted passwords,
shared user accounts, nonnamed accounts, and aging
accounts in all environments
where financial data,
authentication data or source
code exists
• Persons granted multiple
privileged access profiles (for
example, roles) that produce a
conflict of interest
One Identity identity and
access management
(IAM) solutions
The security features of
primary applications are
insufficient.
With all of the risks that can
arise from poorly managed user
identities, passwords, roles,
access privileges and related
vulnerabilities, it is not surprising
that auditors today look for
extensive controls related to
identity and access management.
But using the group permissions
and role-based management
features of primary applications
(financials, payroll, ERP, POS,
e-commerce and so on) to
protect sensitive information is
not enough to safeguard that
information. ICFR auditors know
that protected information is
stored and transmitted in a
variety of systems across an
organization’s network, including
the support systems (such as file
servers, mail servers, backup
servers, development and test
servers, and network devices)
and underlying platforms
(databases, operating systems,
hypervisors and VM hosts) that
make up the enviro
Please complete the form to gain access to this content
