Key Controls Versus General Controls
Early on in the IT audit for Sarbanes-Oxley compliance, it's important to establish two main groupings of IT controls that should be checked: key controls and general controls.
For the purposes of Sarbanes-Oxley audits, key controls are controls that are key to ensuring that the values on the balance sheet are accurate and reliable. Every expense/transaction must be initialized, authorized, controlled, implemented, reported/documented, and validated/cross-checked using key controls. Some of these key controls will be IT based, and should be covered in the IT audit. An example might be a trigger on a database table that ensures that adding any entry into the accounts receivable table automatically creates an entry into the general ledger. It would be important to ensure that this trigger is in place, is correctly coded, and can be changed only by authorized personnel.
Another key control might be the use of database transaction-handling to ensure that either all sub-transactions involved in one big logical transaction are posted or that the whole logical transaction is rolled back, to ensure that the data is never in an inconsistent state. It would be important to check key transactions to ensure that the transaction code is written correctly and that guidelines/standards make it clear how transactions should be structured within the organization to ensure that this is the case.
In some companies, email is so crucial to a process that it's considered to be a key control; in such cases, this email should be subject to message queuing technology, to ensure that if the email fails to be sent, it's re-sent later.
Some other examples of key controls are reports that are used to check the totals of transactions or check that two separate systems tally with one another. Code reviews, design walkthroughs, unit testing, and user-acceptance testing are examples of ways in which reports should be validated as being reliable.
It's the IT auditor's job to ensure that key controls are effective, reliable, and reproducible.
General controls are controls that go across all IT systems and are essential to ensuring the integrity, reliability, and quality of the systems. All of the following are examples of general controls:
Security policies and procedures
Change management policies and procedures
Disaster recovery policies
Backup and recovery procedures
Service-level agreement policies
When assessing general controls, it's important to look at the effects of those controls across all IT systems that are within the scope of the Sarbanes-Oxley audit. General controls usually incorporate at least the following types of controls:
Change management procedures
Version management/release management procedures
Source code/document version control procedures
Software development lifecycle (SDLC) standards:
Clear process and structure, documented
Design documentation standards
Security policies, standards, and processes:
Intrusion prevention and detection policies
Physical access security
Internet usage policies (see Microsoft's article "Why You Need a Company Policy on Internet Use")
Incident management policies and procedures
Technical support policies and procedures
Hardware/software configuration, installation, testing, management standards, policies, and procedures
Disaster recovery/backup and recovery procedures
Generally speaking, if it's an IT "best practice," it's usually good from a Sarbanes-Oxley perspective. There are a few exceptions to this rule, though; for example, some open source strategies, while seen as a best practice in the IT world, are arguably not in line with Sarbanes-Oxley requirements, as they contradict the key ideas within Sarbanes-Oxley that access to information should be purely on a "need to know" basis, and that processes should be controlled. It's usually a good thing for Sarbanes-Oxley purposes if a policy, procedure, or process is
standardized across the company
Thus, it often makes sense for it to be automated (as this theoretically also makes it more difficult for individuals to manipulate the control either maliciously or by mistake). For example:
Many companies use a centralized software-driven source code control system or document management system in order to implement version control policies.
Backup and recovery procedures are often automated using scripts (centrally administered by the relevant MIS department) to back up data at regular intervals, as well as using clustering techniques, RAID, etc. to automatically transfer control to backup hardware when the primary hardware fails.
Authentication and access-control procedures are often automated using centralized directory services such as LDAP or Active Directory.
Intrusion prevention and detection processes are often automated using centralized services such as IPS/IDS software.
Antivirus policies are often automated using centralized software such as McAfee or Symantec antivirus software.
Even in smaller IT companies, to conform to Sarbanes-Oxley, it's a good idea to ensure the following:
The same SDLC/methodology (design, creation, and installation of IT systems) is used across all applications.
Coding standards exist and are adhered to, and code is reviewed to enforce the coding standards.
All changes to code must go through a documented approval process before being implemented.
Incident-management procedures should exist, and all involved should know how to respond to key incidents.
A centralized list should be kept up to date showing all IT infrastructure assets (PCs, firewalls, servers, routers, hubs, and so on).
All changes made to assets/objects within the IT infrastructure should be authorized, recorded, and reviewed.
An intranet (or other centrally held, easily available document repository) contains up-to-date versions of all key documentation (including the latest policies and procedures, emergency telephone numbers, etc.).
For each general control, it's important that the internal auditor can show how the relevant policies/procedures/processes are
Createdevidence of the policy/procedure documentation
Approvedevidence of sign-off/approval
Implementedtest system/procedure to ensure that the policy/procedure is followed
Reported uponevidence of ongoing reporting (not just a one-time report produced for audit)
Monitored/reviewedevidence that the policy is enforced and is reviewed
Improvedevidence of a process that includes a feedback loop for changes to be made in response to improvements