Identifying Common Problems When Conducting an IT Infrastructure Audit

The most common problem encountered during an audit is a lack of communication. If management doesn’t understand the scope and purpose of your audit program, they will not provide full support. This will result in their team giving you minimal support. Worst, when pressed, you risk creating a hostile environment between the audit and the IT teams. Effective communications are essential to building trust and being perceived as a value-add partner.

Avoid technobabble and terms that need to be defined. Be clear with presenting risk in clear understandable terms. Practical examples are important. If a risk sounds so unlikely and has minimal impact, the audit finding may be technically correct but would be viewed as adding little to no value. Remember that an audit report ultimately goes to management, not the technical IT staff. Leadership needs to understand what the auditor found and why the auditor thinks it is important.

An audit should be an opportunity to build relationships within all levels of the IT and chief information security officer originations. Make friends with IT and security staff. Understandably, these folks can feel threatened and get a little defensive when an auditor is seen as assessing the quality of their work. Ultimately they should be the experts on the technology, and an auditor is an expert on potential risks. An effective audit should combine these skills to form an opinion for leadership. Disagreements are expected but should be navigated through respect and professional dialogue.

Effective planning and a well-defined scope are essential. Scope creep refers to the expansion of scope after the audit has started. Sometimes this cannot be avoided. For example, suppose you auditing the access management function and determining a potential regular compliance issue. You may choose to expand the scope to include the second-line risk function. Scope creep should always be avoided when possible. When not possible, it should only be used to exam a significant noncompliance issue, and the expanded scope are should be narrowly focused to resolve that specific compliance issue raised. Audits that are full of shame and blame are demeaning and unproductive.

I think it’s easy—and tempting—to write your audit assessment with a scathing or accusatory tone, thinking that if you fill the report with enough high severity findings you will get management motivated to start remediating things. Instead, what often happens is the IT/security staff (the ones responsible for making things better) get reprimanded for your findings, their team morale takes a hit, and everybody suffers audit fatigue from your thousand-page report.

Instead of focusing on reprimands, focus on remediation. At the end of the day, most companies know they have issues, and they’re looking to you for help and guidance. One item to include with the audit deliverables is a security objectives that offers remediation guidance for each identified risk, along with the expected time. That way, clients can couple the detailed audit report with their proposed management action plan and essentially have a playbook they can follow to improve the control environment That’s what we as consultants and auditors want for our clients and organizations, and that’s why we got into the audit profession in the first place, right?

NIST defines several areas of potential challenges when conducting security testing and assessments. All these areas could potentially apply to an audit as well. These areas include the following:

• Time and resources—A solid plan is critical to maximizing the use of available time and resources. Both are sometimes underestimated for many different reasons. For example, systems might not be testable during normal business hours. Often, there is only a small window of opportunity each day. Because technology evolves so quickly, assessors and auditors might find that they don’t have the requisite skill set to adequately perform specific actions.

• Resistance—IT personnel might be resistant to an assessment or an audit for many reasons. Operationally, IT personnel might have concerns about outages. On a personal level, individuals might be defensive and fearful for their jobs or fearful of being reprimanded.

• Temporary behavior—Users and operators might adjust the processes and systems for which they are responsible before an audit or an assessment to comply with policies. Upon completion of the audit, however, systems and behaviors often return to the state prior to the audit or assessment.

• Immediate response—As weaknesses or audit deficiencies are uncovered, there might be a desire to immediately address the issue. Although generally acceptable and encouraged, changes need to adhere to the organization’s policies and change management procedures.

• Changing technology—Technology and the tools used to assess it are constantly evolving. As a result, auditors need to be committed to ongoing information technology education, including the use of new tools and techniques.

• Operational impact—There is always the possibility that tests might inadvertently disrupt the systems being tested. To limit any negative impact, the assessor or auditor should maintain proper documentation, including a detailed list of actions being performed.