Audit Reporting: Practical Advice for Dealing with Auditors

Audit Reporting: Practical Advice for Dealing with Auditors

Being an IBM i audit and compliance management vendor, SEA has a unique view on auditor requests. Not only do we program IBM i auditing reports for a broad range of customers, our customers often ask us what are the best IBM i reports they should run for their own auditors.

We’ve generally found that there are four general principals IT shops should follow when dealing with auditors and five types of reports that auditors usually look for. Whether you program your own audit reports or buy auditing report software to produce the reports for you, here’s some practical advice that can provide a starting point for dealing with IBM i auditors and the audit reporting information they seek.

Best advice for dealing with auditors and audit reporting

Here are four general principles that are valuable for dealing with external auditors.

1. Listen to your auditors and management team. Plan your audit responses according to your auditor’s needs, not yours. They’re the ones who are going to drive what you need for compliance. Auditor needs are usually defined in an audit requirements document, which should be provided ahead of the audit. Also, you should be prepared to document whatever remediation efforts you enacted in response to the audit points that were documented in your last audit report.
2. Don’t volunteer unrequested system information or suggest additional information you can provide. Don’t volunteer what your shop problems are or talk about the big beautiful report you just put together for internal accounting. Volunteering information frequently leads to additional audit points. Unexpected information usually causes an auditor to either 1) ask for multiple copies of any custom reports you have or 2) request even more reports detailing the issues that you brought up. Stick to providing information that meets audit areas from the requirement list or that answers previous audit points. Be friendly but don’t over-volunteer. Don’t give your auditors a chance to find audit points covering unrelated problems.
3. Never show an auditor your report menus. If an auditor sees that your application menus have 200-300 options for reports, they’ll want multiple copies of any reports that interest them. To paraphrase those popular Geico commercials: If you’re an auditor,you ask for tons of reports. That’s what you do. Study the audit requirement and determine what reports you’re going to give the auditors in response to their requests, and that’s it. Don’t let them shop through the report menus fishing for any additional information they might like.
4. Get a GUI audit reporting generator. Auditors like subsets of data. An auditor will take a 300 page report and may ask you to provide detailed information on 1-20 specific items. As I said before, auditors have a big appetite for data, and it’s harder to slice and filter that data without a GUI-based report generator. GUI report generators like the Visualizer Business Intelligence System that comes with our iSecurity Firewall or iSecurity Audit software, can help you pull out the valuable information behind the events you’re auditors are questioning. A GUI report generator allows you to review summary data and then drill down and deliver the detailed report information an auditor is looking for. Without a GUI, IT management would have to develop and continual update IBM i techniques to find the information themselves, using SQL, DFU, IBM i Query, or plain old IBM i programming. Using a GUI report generator to guide you through finding and filtering information will make your auditing life a lot easier.

Detailed IBM i information that auditors like

Although each auditor (and the companies they represent) will decide what information they want, there are generally five different types of audit reports many auditors ask for. If you’re looking for audit reporting software, check to make sure the software has built in capabilities (and a GUI interface) to produce reports focusing on these areas.

1. Anything and everything regarding user profiles and how they are used in your system, including:
   1. Users with default passwords
   2. Which users are in which user groups
   3. Active user profiles that haven’t signed on to your IBM i partition in the last 90+ days
   4. Profiles with security officer access or command line access
   5. Use that have passwords that never expire or don’t match security parameters,
   6. Users who log on after hours. This is a popular request in the banking industry but it’s not as popular in other industries where users routinely log in after hours.
2. List of system configuration and network changes, including:
   1. Current system values and which system values have been changed from their default values
   2. Network changes (especially security changes, such as firewall changes) and when they occurred.
   3. Lists of Help Desk or Service Desk tickets to detect problems and system changes
3. Lists of file, program, and object usage, including:
   1. Which application programs and IBM i commands were recently created, changed, or deleted, when the change occurred, and who approved and performed the change
   2. Who has the ability to change files inside an application
   3. Who has authority to use which application options and menus
   4. Object, source code, and file structure changes. They are several good packages on the market such as iSecurity Change Tracker, that perform these functions.
4. Reports detailing file access using commands that provides uncontrolled access to data, such as Start DFU (STRDFU), Update Data with Temp Program (UPDDTA), Start SQL (STRSQL), Prodata’s DBU File Utility/File Editor, and Run Query (RUNQRY).
5. Logs and reports detailing remote IBM i access that again, provide uncontrolled access to system data. Some of this information may include:
   1. What users have logged in remotely to the system (and when) using ODBC, FTP, SQL, and other remote file access and update techniques, and what files they modified
   2. Log files of firewall or remote activity accessing your IBM i partitions
   3. Exit point monitoring logs

Getting help with your auditing needs

Although, this blog contains a lot of practical advice for dealing with auditors and their reporting needs, it doesn’t cover everything. Please feel free to feel free to contact us at SEA software for more information and advice about handling your particular audit reporting situation. We have extensive experience creating auditing and compliance solutions that provides summary and detailed auditing information about your IBM i partitions.