N A description of the computer systems in place, including servers, type of network installed, and network operating systems used N A diagram of the network showing key equipment and th
Trang 1N A description of the computer systems in place, including servers, type of
network installed, and network operating systems used
N A diagram of the network showing key equipment and the overall connection
scheme, and in particular, all routes into or out of the network such as primary
and backup Internet connections or private wide area network (WAN) links
N How the network authenticates users, how permissions are managed, and how
users are created and terminated from the system
N An overview of the disaster recovery capabilities of the IT department and any
business continuity plans
N A description of the systems that are within the scope of the audit, such as the
accounting system, any payroll system, stock administration system, and so
forth
N Any custom software or modifications to in-scope systems
N The logical access path from a user to the in-scope systems
N A description of the change management process, including how changes are
authorized, documented, and tested
Disaster Recovery Plan
While not technically part of the system of internal controls, a disaster recovery plan
(also called a business continuity plan) is a document that a public company’s external
auditors will want to evaluate They will be primarily concerned with details of how
the company’s critical business information is protected and how it could be accessed
in the event of a disaster Accordingly, a disaster recovery plan should describe the
company’s backup systems in detail, including the following:
N What sort of backup system is in use, in detail
N If tapes are used, how they are rotated internally on a daily basis
N What type of off-site secure storage is used, how tapes are rotated off-site, and
how rotations are documented
N If a colocation scheme is in place, how it operates and how data is replicated
to the other location(s)
N How the backup system is periodically tested to ensure that it is working as
designed, that it can restore data, and how the testing is documented
N If backups are performed differently for in-scope systems, how they operate for
the in-scope systems (for example, general network backups are typically not
kept for extended periods of time, but backups of an enterprise resource planning
system might periodically make permanent tapes that are kept indefinitely)
Trang 2In addition to details of the backup and recovery systems, a disaster recovery plan should also address more general factors, such as these:
N What hardware and software would be needed to restore operations at a temporary site in the event of a total loss
N What the worst-case information loss would be if, for instance, the building burned to the ground
N How replacement software is obtained, and how much time and what skills would be needed to restore computing operations
N Any important software licenses or license keys that are needed and how they would be accessed in case of a total loss
N How communications are handled in the event of a disaster
N How a detailed remediation plan is generated and implemented once the exact details of the disaster are known
Access Management
An important procedure to carefully document is how the company manages access
to its various systems This document should describe the properties of the access management system and how the various steps are performed One section should describe how users are authenticated to the network generally, and to any in-scope systems in particular, as follows:
N The password policies in place, both for the network and any in-scope systems
N How frequently passwords are to be changed, and whether this is enforced by the system
N How complex passwords must be, and whether this is enforced by the system
N How users are instructed about the nonsystem aspects of the password policy for which they are responsible (for example, that new users acknowledge that they must not share their password with any other individual, what they should do if they think their password has been compromised, and so on)
N How the intruder lockout system functions when an incorrect password is tried repeatedly
You also need to show how permissions to the various parts of the network are approved and documented One way to do this is to develop a form for the creation of new users or modifications in permissions for existing users This form should specify which parts of the network and in-scope systems a user has access to, and it should be approved by the person’s manager For any access to in-scope systems, usually the system
is designed so that the corporate controller approves those permissions (or formally delegates the approval to another person) Once a new user account is created based on the form, the IT department files it and makes it available to auditors on request
Trang 3Similarly, you will need to document employee terminations Of particular concern
to the auditors is account termination for people who had access to financial systems,
and assurance that their access to financial systems was terminated at the same time as
their employment was terminated
System Maintenance
Regular system maintenance of the in-scope systems should be defined and documented
The actual maintenance activities that are performed should be spelled out in a procedural
document For example, a Windows-based server might have the following maintenance
activities defined:
N Examine event logs and note any serious problems
N Save the event log
N Apply any pending Microsoft patches through Windows Update
N Examine disk space to ensure that adequate free space is available
N Examine the backup system logs to ensure that backups are being performed
properly and that there are no unresolved errors
N Restart the system and ensure proper functioning after it restarts
The performance of these tasks should be documented whenever they are done
Depending on the preferences of the company’s auditors, this can be electronic or
through the use of a paper form developed for this purpose
Change Control
A critical procedure to develop is one that governs how changes to any in-scope
systems are managed This includes both changes to the in-scope software, such as
applying an update or upgrade to the application or modifying a program used by the
system, as well as changes to the operating system and hardware in a server that hosts
in-scope systems
All changes to in-scope systems need to be documented, and where approvals are
required, they also need to be documented
A general procedure for a routine change might be a request from a person in
the accounting department to modify a financial report to make it more useful, or to
develop a new report that will help the employees do their job better In such a case,
the requestor might complete a form describing the desired change, which is submitted
to the IT department The IT department then assesses the change to determine how it
can be accomplished and what resources (time and money) are required to make the
change The IT department should also propose a way to test the change to ensure it
is working as designed The IT department then forwards the request, along with this
assessment, to either the company’s controller or CFO, who must approve the change
After the approval is granted, the IT department effects the change, performs the
testing, and usually has the original requestor also accept the result
Trang 4Some routine changes may be initiated by the IT department For instance, say the IT department notices that the server hosting the company’s accounting system
is getting low on disk space The IT department would recommend that additional disk drives be installed in the server, the costs of doing so, and how any risks will be managed The controller or CFO then approves the change before it is effected
The company should consider whether or not to allow emergency changes to the in-scope systems An emergency change would typically be a hardware failure that can be quickly resolved, such as a failed disk drive in a RAID 5 array or a video card that simply needs to be replaced The change control procedure may allow the IT department to make defined emergency changes to the system, and then document them immediately after the fact However, this would need to be negotiated and agreed upon by the IT department and the finance or accounting department
SOX Compliance Testing
Once a company’s system of internal controls is built and implemented, the job is far from over For one thing, most organizations find that they need to adjust their internal controls after they have run them for a while Perhaps the company decides to add some new controls in response to an event that highlights a previously unrealized risk,
or maybe the company overdid its initial SOX compliance by implementing too many controls and needs to slacken them a bit However, the real work in maintaining a system of internal controls is in auditing the controls
Auditing Internal Controls
To show dilligence, companies must demonstrate that their controls are effective and that they are being followed by their employees This means that the controls need to
be tested on a periodic basis
For each control in a system of internal controls, the company should develop a test that verifies that the control is working For example, say your company has a control that mandates that users of the accounting system cannot access the AP functions unless they are an AP operator or manager A test for such a control might have two aspects:
N A listing of the permissions in the accounting system should show which users have which permissions, and an examination of this list should show that no one who is not an AP employee has access to the AP system The listing would become part of the testing evidence file, and a manager in an appropriate position in accounting or IT (or both) would review it and sign it to document that he reviewed it and found no inappropriate permissions
N An auditor may ask one or two employees who do not work in AP to try to get into the AP system Most systems will produce some kind of error message if an unauthorized access is attempted The auditor would take a screenshot of the
“access denied” message, initial and date it, and include it within the test file
Trang 5The frequency of the tests will vary depending on what is being tested For
example, a test for a control that requires the IT department to follow the written
backup procedure regularly may be tested only annually, but a test that general ledger
accruals are being done properly might be conducted quarterly It’s usually up to the
company’s controller and internal audit staff, perhaps with feedback from the external
auditors, to devise a schedule that makes the most sense
Sometimes testing is done on all cases of a particular procedure, and sometimes
only a subset is tested If there were only three changes to an accounting system
over the year, and the change control process is being tested, it would make sense
to examine each change control document On the other hand, if a control applied
to every purchase order the company generated, and the company generates 10,000
purchase orders every year, then a subset would be tested A testing subset may be
a random selection, or it may be only the most expensive orders The auditors will
determine what sort of testing should be done
Deviations from Internal Controls
Since we’re all human, and since the designers of internal controls cannot anticipate all
possible events that may impact a particular control, it is certain that occasionally there
will be deviations between written procedures and what was actually done Perhaps
a key employee was sick, and her replacement didn’t realize that some particular
task needed to be performed, or perhaps an employee wasn’t properly trained on a
procedure
I like to say “there are only two kinds of people in a regulated company: those who
have deviated, and those who will deviate.” Deviations from management systems
such as internal controls should be expected What is important is that the deviations
are detected (perhaps by a downstream control or from an audit), and that some form
of cause and risk analysis is performed, and that corrective action was taken and
documented
The point is that a good system of internal controls should have as one of its
components a procedure for handling deviations and corrective actions
Sample SOPs
Following are some examples of IT procedures that come from a small public company
that stood up to repeated testing by both large and small audit firms Certainly, your
company’s procedures will and should be different, but the following examples should
give you a sense of effective IT procedures