IT audits serve to verify that an organization's technical practices correlate with its business practices. A legal or accounting department might initiate an audit to satisfy insurance, investment, group membership, or government regulatory requirements. However, in an increasingly connected world, sales and marketing teams are leveraging audits to back up a company's security, privacy, and other technical claims. Although other departments might play an important role in the audit, the IT department is often responsible for preparing for the procedure and working with auditors.
Properly executed IT audits can add tactical and strategic value to your company. You might not have influence over the goal or the reasons behind the audit, but with some basic planning and the right procedures, you can turn the process into an internal system check to increase the overall effectiveness of your IT group. Depending on the circumstances, your organization might perform the audit internally or contract a third-party organization to do the job. Let's concentrate on preparing for an external audit, which is often more expensive and less forgiving than an internal audit. Specialists such as one of the larger accounting firms (e.g., Coopers and Lybrand, Deloitte & Touche) typically perform official audits (e.g., for regulatory purposes).
Know the Purpose
Knowing the strategic value of an IT audit will help you refine your preparation and make the process more fruitful. Ask your internal audit sponsor to outline the entire scope of the audit. Understanding the big picture is essential for knowing whether management intends to validate a specific system or a general process. If you're sponsoring the audit yourself, be sure to work with the auditors to clearly present the scope so that the goals of the audit are clear and achievable.
Assign Responsibilities Early
Coordinate your activities with other participating internal departments to ensure that expectations and responsibilities are clear. Be sure that you understand the reasoning behind the audit, and don't hesitate to ask questions of other departments. Up-front communication minimizes questions and problems that might arise later. If you participate in a series of recurring audits, determine whether you need to update assertions or procedures to reflect your current business or operational model before each audit.
Identify the key players who will be providing information to the auditors, limiting the list of people to the fewest who can accurately represent the material. This step minimizes the potential for ambiguous or potentially conflicting answers. If, for example, multiple systems administrators are responsible for backing up different systems, consider designating one to discuss the entire backup process with the auditors. Designating point people brings efficiency and accountability to the process.
Know the Assertions
Auditors test and validate assertions, which are clearly worded claims published internally for employees or externally for customers. You must compile assertions before an audit begins. An example of an assertion is, "We perform backups daily and verify them monthly." Assertions should directly support the audit's strategic value. Internal audits give you some flexibility in how you word your assertions to represent your processes, but external audits often have rigid predefined assertions. In such cases, your job is to understand the meaning of the assertion and demonstrate to the auditors that your process directly supports the assertion.
Before an audit begins, try to meet with auditors to request a list of passing criteria for each assertion and review the scope of the project. The information you seek should specifically identify what the auditors will examine during the process and will help you coordinate your preparatory activities.
Know the Time Line
An audit encompasses two distinct periods: the period of record and the actual audit. The period of record is the time preceding the audit for which your organization is accountable—in other words, the period that the auditors will examine. The actual audit occurs when the auditors are on site conducting the official review of your systems. If your company asserts that it performs regular backups, auditors might require backup logs or some other evidence that successful backups have occurred throughout the period of record. If you're facing your first audit, be sure to understand how the auditors and your organization's assertions define the period of record and prepare accordingly. Review and update your systems and processes as required to satisfy an audit before the period of record begins.
Understand the Scope
Audits examine a variety of systems, typically evaluating processes and procedures as well as technology and controls. For example, auditors might not only validate a group membership (e.g., who has local administrator access to a server) but also request to see the trouble tickets (or other evidence) demonstrating that you granted the membership through a repeatable, published process. Demonstrating the results of an action is often easier than demonstrating that you followed a repeatable process. Again, how strict an audit is varies depending on the sponsor and purpose, so be sure to understand the expectations and be prepared to deliver sufficient detail.
Before any audit, review the specifics of what auditors will examine and how they will test each assertion. If your company is preparing to undertake a particular audit for the first time, consider running a mock audit to drill and prepare for the real thing. The mock audit will force you to produce sufficient documentation and scripts.
True to definition, an audit will selectively test your entire process. Therefore, pulling sample reports ahead of time (e.g., a cross-referencing of current employees with a list of active network accounts) might not satisfy any random sampling requests. However, writing general documents that describe established processes (e.g., explaining how you reconcile the list of employees against the list of accounts quarterly) and preparing scripts to pull necessary audit data is worthwhile; doing so will save you time and demonstrate to the auditors that you're serious and have your work in order.
Explicitly identify the servers and facilities that fall within the scope of the audit. Create a spreadsheet or a table that lists each potentially auditable object, why it's in the scope, and who's responsible for that object throughout the audit. A comprehensive list shows your willingness to work with the auditors. This list can also help you streamline the process.
Areas of Concern
Let's now look at some areas that auditors like to concentrate on. Data backup and recovery are auditor favorites because of their importance to business continuity planning. Be prepared to show the auditors a dependable system for backing up critical servers. Reviewing the architecture of the backup system might not be enough. Even before the audit period of record, ask the auditors what they expect as evidence of a successful backup system and procedure. For example, auditors might ask you to show backup logs for the entire period of record, a list of what systems are backed up and their purpose, where the backup media is stored (on or off site), the length of the rotation period, and how the backups are validated.
ACLs are any lists of permissions you set on a network device or a server to restrict access to that equipment. Before an audit, be sure that your company's business process clearly defines who has access to key resources. Organize permissions as they make sense within your business and the scope of the audit. For example, consider organizational restrictions (e.g., only the finance department has access to accounting data), client/customer restrictions (e.g., internal teams that have sole access client data), or other logical data boundaries. As I mentioned earlier, clearly defining the assertions and the passing criteria will help you translate and document the necessary access controls.
For example, if an assertion states that "data from each division shall be separate and independent," be prepared to tell auditors who should have access to discrete data as well as who actually does have access to this data. Demonstrate this access by presenting ACLs for your file folders, Microsoft SQL Server objects, Microsoft Exchange Server public folders, and any other shared or collaborative system. Be aware that this process can take some time.
A loosely worded assertion is often more difficult to satisfy. You might have some leeway to alter the wording. For example, you might be able to change the assertion I just mentioned to "client data from each division shall be separate and independent." Adding specifics to assertions can help you tighten the audit's focus.
Use scripts to help you collect ACL data. Sometimes scripting or a creative use of resource kit tools is necessary to extract the massive amount of data that an audit requires. Format the output to clearly support the assertion. Figure 1 shows formatted data from a script that demonstrates local and domain access to a server. This set of tables describe domain groups and individuals that have access to local groups and list the members of the domain groups. Ask the auditors to approve your format before the audit begins. Also, ask whether they'll want to run the scripts themselves or whether the output will suffice.
Multiple assertions might address the broad topic of security, another auditor favorite. You can demonstrate security of data by satisfying some of the criteria that Table 1 outlines. Work with your auditors to determine what security-related evidence is required to support your assertions.
In an audit, data validation might occur when auditors match a customer invoice or a bill of services to the delivery of those services. For example, auditors might require an ISP to demonstrate that it provided the bandwidth it billed customers for.
Data validation is unique to each business. If an assertion applies to your audit, be sure you can explain your methodology for checking the system and demonstrate the accuracy of the data. For example, auditors might ask to witness the correlation of a random sample of bills to network logs. Again, good preparation and prior understanding of expectations will help you avoid surprises. To demonstrate compliance, you might need the assistance of other departments—for example, you might need accounting to pull records or a software group to simulate a transactional service.
A ticketing system can help you demonstrate that you follow processes from start to finish. Using a ticketing system, you create a ticket when you initiate a process, then each person participating in the process annotates the ticket as he or she completes a step. When the process is finished, you close the ticket and retain it as a record of the events. Keep the history of tickets for the audit's period of record because these tickets serve as evidence that you follow the processes as you assert. Commercial ticketing systems, such as Peregrine Systems' Remedy Helpdesk or Network Associates' Magic Solutions, are great for tracking your processes. But you can also work with your auditors to determine whether other tracking systems, such as email records, spreadsheets, or simple databases, are acceptable.
Presenting the Data
How you present and organize your data plays a significant role in the success of your audit. Present data to auditors in a uniform and well-organized fashion before they request it. Doing so expedites the review and might limit questions that result from misunderstandings. To further ensure that you explain your processes to auditors adequately, take the following steps:
- Make sure that all reports have appropriate column headings and legends. Add a section for notes if you're presenting complex or proprietary information.
- Import data extraction, such as information from SQL Server data dumps, to Microsoft Excel or Microsoft Word, and format the data to annotate or highlight important information. To increase clarity, delete data-dump information (e.g., globally unique identifiers—GUIDs—or other internal pointers) that isn't directly relevant to the audit.
- Provide definitions for any company-specific terms.
- Clearly map out correlations within your data so that auditors don't have to draw their own conclusions.
- Preemptively explain any obvious holes or errors in your data.
Create a time line for delivering data and answering questions, as Table 2 shows. Doing so helps you prepare your data early and gives auditors time to review the data and formulate questions that you can answer later.
The Actual Audit
When the auditors arrive, give them a quiet place to work while they review your information. Set up a temporary workstation with an email account so that the auditors can send or request information from you and your team. Put together an agenda and a calendar for the actual audit, and ensure that your team can meet with the auditors on time and with the required information. Establish a preferred method of communication. Ask the auditors to batch their questions so that you can address their needs efficiently without having to face frequent interruptions. Similarly, answer their questions promptly and thoroughly to avoid follow-up questions or clarifications. To avoid miscommunication, I recommend that you follow up in writing (e.g., email) to confirm any conversations. Also consider scheduling periodic status meetings or reports to keep a gauge on the audit process.
Fear of Failure
Audits can be nerve-racking if you're worried that one or more of your assertions might fail. If you have such concerns, work with the auditors immediately to understand why you might fail. Evidence of your efforts to revise or improve a process might exempt an assertion from the period of record. In other instances, you might be able to provide alternative data that explains your business or technical process to the satisfaction of auditors. If you establish good communication and cooperation with the auditors, you probably won't encounter many surprises, and you'll know well ahead of time about any trouble spots. If you do fail an assertion, ask the auditors for details and inquire about any remediation so that you can pass the next time.
Having a clear understanding of the strategic importance of an audit and being prepared goes a long way toward alleviating some of the negative connotations that surround IT audits. However, beyond the big picture, I've realized many side benefits from the tactical exercise of identifying, capturing, and executing the steps that an audit requires. An audit should prove that you do what you say. Trouble spots usually signify larger problems, and knowing the specific shortcomings is the first step toward fixing these problems. So take your next audit in stride. Understand what you're setting out to achieve, and use the audit as yet another tool to help you improve your IT department.