397 Appendix: Understanding the Sarbanes-Oxley Act 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 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) 398 Networking: A Beginner’s Guide In 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. 399 Appendix: Understanding the Sarbanes-Oxley Act Similarly, 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. 400 Networking: A Beginner’s Guide Some 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. 401 Appendix: Understanding the Sarbanes-Oxley Act The 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. . 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. 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. 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.