Consider a likely scenario: A team is in the middle of working frantically, trying to meet a deadline, and they learn that their team is being audited by their organization’s external auditors. The team lead is asked to provide a list of artifacts. Some of them are easy to gather, but the majority of the items listed will take a few hours to compile. So the options before the team are working late or missing the sprint commitment. What is even more frustrating is that the team was audited several weeks earlier by the organization’s internal audit department. And several weeks before that, the IT risk team performed a controls assessment and asked for the same list of artifacts. The team just wants to get its work done, but it gets sidetracked with these requests.
To effectively assess an organization’s control environment, IT audit and risk rely heavily on artifacts. These artifacts might come in the form of a screenshot of a configuration or an exported list of users from a system. Many times, though, these requests overlap, and asking for the same thing multiple times throughout the year creates an unnecessary burden on the business. To decrease duplication of efforts and let the business do what it does best, the third line of defense (internal audit) and the second line (risk) must work together.
To make this partnership a reality, there are four foundational principles:
- Culture is supportive.
- IT audit is t-shaped.
- IT risk properly tests control effectiveness.
- Common tools are used.
Culture Is Supportive
There are books, courses and even degrees dedicated to organizational culture, but the importance of culture cannot be emphasized enough. Security should never be seen as checking a box, and audit should not be something people fear. Employees across the enterprise must understand the importance of the security and audit teams as they start their careers at the organization, as opposed to learning about them a week before a risk assessment or an audit.1 Risk helps the business make informed decisions. Audit uncovers gaps with organizational processes and standards that hinder the business. And a supportive organizational structure helps influence acceptance of a collaborative culture.
There are myriad organizational structures that effectively support risk and audit. Choosing a structure is a decision based on factors such as organization size and maturity. Larger, more mature organizations have dedicated risk and audit functions. Smaller organizations might instead place IT risk under another functional area, such as IT or security, to avoid duplication of efforts and streamline secure practices.2 Regardless of where risk lands, however, audit must remain independent and should not report under an area that would influence audit outcomes (e.g., IT in the case of IT audit). Therefore, in organizations where risk and audit are within the same functional area, such as in smaller organizations, there should be reporting in place to prevent any conflicts of interest or biases that could influence audit results.
To further enhance the partnership between risk and audit, job shadowing and swapping should be used as much as possible. Risk analysts should perform guest audits. Auditors should assist in assessments of risk and controls. These are excellent opportunities for auditors to upskill their technical knowledge and for analysts to learn more about control evaluation. These are also opportunities for each department to uncover any gaps and overlaps between the two areas.
Audit and risk must regularly market their services to the rest of the organization. If audit and risk have a seat at the table when major decisions are made, the organization will find it easier to implement solutions with a security mindset from the beginning. This could prevent the need for putting a security band-aid on existing solutions, which usually results in the adoption of very inefficient manual processes solely to meet legal and regulatory requirements. Marketing does not have to be a massive effort; it just has to be intentional. Small, frequent interactions, such as lunch-and-learns, or regular touch-bases can keep risk and audit topics top of mind and less intimidating.
IT Audit Is T-Shaped
Audit has a reputation for following checklists and running scripts, and this is understandable considering the breadth of technologies auditors must review. However, although checklists and scripts are important tools, an auditor’s overreliance on them, combined with a lack of knowledge on the controls being audited, is a recipe for unnecessary or even hindered audit findings. Therefore, a t-shaped team is essential for successful and impactful audits.
T-shaped audit teams have a wide breadth of foundational auditing and technical knowledge and are made up of auditors who each have their own areas of expertise. Some will know the ins and outs of distributed operating systems and database platforms. Others will have a strong grasp of cloud controls. The amount of deep knowledge expected from each auditor depends on team size. Larger teams give auditors the opportunity to have deeper knowledge in a handful of specific technologies. They might have an Amazon Web Services (AWS) auditor and another auditor who has deep knowledge about Azure. Knowledge on smaller teams tends to be distributed more broadly. For example, one auditor may be familiar with legacy technology while another is comfortable reviewing cloud controls.
T-shaped audit teams have a wide breadth of foundational auditing and technical knowledge and are made up of auditors who each have their own areas of expertise.
In support of a t-shaped audit team, audit management must keep an inventory of the skills, certifications and degrees of each member of the team; review this inventory periodically; and encourage continuous education via conferences, webinars and certification exam reimbursement. This also helps when external auditors and regulators ask for the credentials of the auditors.
In addition to formal education, auditors need hands-on technical experience to apply the concepts they learned in the certification programs. This can be accomplished by having auditors participate in building the tools and scripts they use for performing audits. This can also be an opportunity for building relationships across the enterprise as these tools might require the help of a subject matter expert. These opportunities will not only help build an auditor’s skills and relationships, but also increase the quality of the tests performed and prevent false audit findings from causing incorrect script output.
IT Risk Properly Tests Control Effectiveness
IT risk and IT audit have a number of similarities. However, one key distinction is that IT audit must always remain independent. Its tools and scripts should not be used as a first or second line of control as that could lead to hiding the root causes and to audit being responsible for auditing its own processes. Because of this, audit should rely on risk’s testing when possible. For this approach to succeed, though, risk must know how to properly test a control’s effectiveness and document it in a reliable way.
Using one shared platform for audits and risk assessments enables both teams to leverage each other’s work and gives risk and audit leadership combined metrics to illustrate the entire picture.
The risk team must be familiar with information provided by the entity (IPE) and information used by the company (IUC) concepts to ensure the reliability of its work. IPE gives an auditor assurance on how an artifact was generated. IUC, on the other hand, gives the control owner assurance on how an artifact was generated. For example, a data owner performs a monthly review of all access to a system in which the data they are responsible for resides. The system administrator provides the data owner with an export of all user access logs for review. Before performing the review, the data owner must know exactly how the list was extracted. Otherwise, there could be a gap that goes unnoticed-for example, if the system administrator filtered out all system IDs thinking the data owner did not care about those IDs. Without the provision of this IUC, the data owner would never catch this large gap in the control.
In the same scenario, IT audit asks the system administrator for the same thing-a list of all users generated from the system. If the system administrator does not provide IPE, the auditor cannot be confident in the completeness and accuracy of the report. Regardless of who is to receive the report, the system administrator must include source, data, report logic and report parameters to ensure its reliability:
- Source data-Refers to the origin of the extracted data, that is, the system of record. In the example, this would be the server that housed the list. Or, if it came from a database, it would be the name of the database.
- Report logic-Refers to how the data were extracted and transposed into the artifact provided. In the example, this might be "export to Excel from active directory." In essence, the report shows how the data got from format A to format B.
- Report parameters-Refers to any filters applied. Again, based on the example, this might be "filtered on user type 'USER.’" This ensures the data’s completeness.
For the audit team to rely on the artifacts the risk team used for testing, IPE/IUC must be provided. Otherwise, audit will have to retest everything to ensure the accuracy and completeness of the data.
Common Tools Are Used
To promote cross-team collaboration, the risk and audit teams must align their tools. Using one shared platform for audits and risk assessments enables both teams to leverage each other’s work and gives risk and audit leadership combined metrics to illustrate the entire picture. For example, "Application A showed strong controls in a recent controls assessment but failed an audit." These findings can point to a needed review of risk and audit programs, scoring methodologies and processes.
Shared tools also allow the storing of artifacts in a shared record. To see if a system and organization controls (SOC) report was issued in a recent third-party review of application B, for example, the IT audit team can simply check the application record’s document repository and pull any artifacts that are needed for review. Access must be configured appropriately when sharing artifacts. Artifacts such as system configurations can be shared between both groups. However, items such as audit interview notes must be kept confidential. Account management must be considered when choosing a platform.
Although using the same platform to store risk assessments, controls assessments and audit workpapers would be ideal, it is not a requirement. For situations in which a shared platform is not utilized, there are other ways to collaborate between teams. An application programming interface (API) can be used between systems, which can help from a reporting perspective. Audit can leverage the data output from risk assessments to determine the highest-risk applications across the enterprise. This can help with audit scope planning. IT risk, on the other hand, can determine which control families have been audited and note their corresponding effectiveness levels. This points to a security gap in the enterprise that could require a risk assessment.
When separate tools are being used, cross-training and access must be considered. Auditors could be trained on and given access to IT risk’s system to pull artifacts that were already requested and stored as part of a controls assessment. Doing so would prevent audit from asking the business for an artifact that was already provided during a controls assessment. Again, access management must be securely configured. For example, audit might be given access to risk’s governance, risk and compliance (GRC) platform for the length of the audit period and only for specific records (or possibly even fields).
Partnership in Action
An example of this partnership in action might look like this: Audit is in the middle of scoping an IT audit of the human resources (HR) function. To help determine the scope of the audit, the team uses a dashboard directly connected to the data source where risk assessments are being stored and sorts the systems and vendors by highest criticality. These data provide audit with an objective way to prioritize the scope of the audit by the third parties and systems most critical to the organization.3 Moreover, the audit team can verify this list with the business to see if anything is missing, as opposed to asking the business to start a list from scratch.
After the audit has been planned and communicated appropriately, the team is ready to perform the audit. Part of this audit includes reviewing third parties that are hosting any of the applications in scope. Rather than the auditors asking the business to reach out to their third-party contacts for proof of an SOC or similar report, IT risk has already performed third-party risk and controls assessments on each supplier. All artifacts are stored within the GRC platform being used. Audit is given temporary access (or a permanent auditor role) to view the results of the third-party reviews. The auditors simply review the assessments that the risk team already performed and document their findings.
Another section being audited within each application is user account management. The auditor who is assigned to application A logs into the GRC tool where the risk team is storing its assessments and pulls up the recent controls assessment performed on application A. One of the controls reviewed addresses user access. After performing this review, the risk analyst thoroughly documents analysis of this control and includes IPE for each artifact provided by the business user. Again, the auditor performs and documents a review of the assessment performed earlier and does not have to interrupt the business user for an artifact request. Of course, timeliness is important here. The original review should have been performed within the same fiscal year as the audit. And if this work will be leveraged by external auditors, it is important for internal audit to work with external auditors to understand reliance expectations and requirements.
When the audit and risk teams are in sync, they can more effectively evaluate the organization’s security posture without constantly interrupting the business.
The HR audit is eventually completed. Later in the year, IT risk performs a risk assessment of the marketing function. One of the applications under review had already been reviewed by internal audit, so the risk team asks for the audit report associated with the audit of the application in scope. The risk team notices three of the controls typically evaluated already were assessed by internal audit according to the audit report and no issues were found. Risk can now mark these controls as effective and avoid sending the owner of the application a duplicate request for the same artifacts.
These examples illustrate the ideal concept of sharing input, output and processing.4 The audit team is using risk’s outputs (risk assessments) as inputs for scoping activities. Similarly, the risk team is using the audit report (output) for control assurance (processing).
Conclusion
When the audit and risk teams are in sync, they can more effectively evaluate the organization’s security posture without constantly interrupting the business. Staying in sync requires more than monthly meetings with the teams. It takes persistence and intention. At the end of the day, IT audit and IT risk have different responsibilities in defending the organization, but their overall purpose is to keep the organization secure.
Endnotes
1 Tarallo, M; "Understanding, Assessing, Aligning and Transforming Organizational Culture," ISACA® Journal, vol. 1, 2023, http://h04.v6pu.com/archives
2 Ho, A; "Roles of Three Lines Defense for Information Security and Governance," ISACA Journal, vol. 4, 2018, http://h04.v6pu.com/archives
3 Schmittling, R.; A. Munns; "Performing a Security Risk Assessment," ISACA Journal, vol. 1, 2010, http://h04.v6pu.com/archives
4 Op cit Ho
BENJAMIN BARTZ | CRISC, AWS CERTIFIED SOLUTIONS ARCHITECT-ASSOCIATE, CCSK, CISSP
Is a governance, risk and compliance (GRC) analyst at John Deere. He is responsible for performing risk and controls assessments of third parties, internal applications and processes. He has seven years of experience in information security, with the majority of his career being in IT internal audit, first as a systems auditor and then as a supervisor and Scrum master. He also teaches network defense topics part-time at Eastern Iowa Community Colleges (Davenport, Iowa, USA).