Consider this, an organization has an internal or external audit about to start or an incident has occurred that needs to be investigated. These activities each require evidence to support the who, when, what, where, and why of the activity. One way this can be done is by tracing the activity through an audit trail. This article explains the concepts, uses, potential components, and various forms of an audit trail.
What is an Audit Trail?
An audit trail is a detailed set of information that provides evidence for an activity that has occurred. It allows an individual to trace all the steps in a particular activity from start to finish, from point of origin to final destination.
What is the definition of an audit trail? Merriam-Webster defines it simply as, “a record of a sequence of events (such as actions performed by a computer) from which a history may be constructed.”
The components of an audit trail for an activity trying to be traced can flow through multiple systems or evidence pulled from more than one system may be needed to provide the full audit trail for the activity being reviewed. Multiple parties can be involved in providing the pieces of the full audit trail, as multiple parties may be responsible for different parts of the audit trail should it impact more than one business process.
The audit trail can take various forms depending on the application or tool and the type of audit trail.
- With the change in application code, the history of the change can show the line items that were changed.
- Record of a financial transaction or operational transaction.
- Monitoring of activity for services provided to clients – such as being a subservice provider.
- User access such as identification of a breach and the path the bad actor took to gain access and once access was gained.
What Format Can an Audit Trail Take?
An audit trail requires the retention of historical information which can take the form of a set of physical or electronic documents or a system log of activity. Physical and electronic documents, once identified as part of the audit trail, are generally easy to review and identify the needed information within the document. Obtaining information from a system log is a whole different matter. A log is just that – a log, until someone decides to use it in some manner. The value of a log also depends upon what activity the log captures. For example, the log captures that someone or a device signed on versus what that device or individual actually did. The breadth of the activity automatically logged for a system can vary by the system (ie., all activity is logged, only certain activity is logged).
Considerations When Using a Log:
- What format is the log?
- Is it easily accessible for use?
- Is the format of the data in the log easily able to be read or queried?
- Is the log the one automatically defined by the application or tool or defined by an individual (as this impacts the content of the log)?
- What information may be contained in the audit trail or log?
- Date and time of activity.
- Who performed the activity (which validates the user ID; but, in the case of malicious activity, may only document which ID was used) or where the activity originated (IP address)?
- What activity was performed?
- What systems or system resources were accessed, modified, or utilized?
- Have reports been created that query the log contents to create certain activity in a report and easily digested form? The content of these reports is based on parameters defined by the individual who created the report. Thus, the report can be subjective in nature.
Uses of an Audit Trail
The uses of an audit trail depend upon the individual and the objective at hand. Usage can be for routine tasks, audits, specifically identified needs, etc. The following bullets provide examples of different uses:
- To monitor activity for certain, specifically defined events.
- To allow for a look back on a certain activity for daily use purposes.
- To allow for activity related to a historical event to be queried for in the case of a forensic investigation.
- To provide support for internal or external audits.
- To provide proof of compliance and operational activity and validate outcomes and actions.
Individuals must objectively review audit trails to determine if the audit trail is meeting their needs and answering the question or request at hand. The audit trail may provide a set of information; but, may not provide the information needed to answer the question or request.
Tools can be purchased whose function is to monitor and report on an activity as it occurs and provide historical support (both authorized, unauthorized, and activity specifically defined to be monitored). In addition, an audit trail may already be pre-defined or may need to be created in the case of investigating unauthorized or malicious activity. An example would be a Security Information and Event Management Tool (SIEM) that aggregates and analyzes activity from different sources in a company’s IT infrastructure. The company configures the SIEM to capture and report on activity from its different external and internal-facing systems. The SIEM allows a company to store, aggregate, and provide analytics on the data captured which, in effect, can provide an audit trail of activity that has occurred.
Obtaining the Information or Data Contained in an Audit Trail
As previously mentioned, audit trails can involve physical and electronic information and multiple systems and applications. Thus, the individual requesting the information may require the support of others in terms of time, knowledge, and resources in order to obtain the needed information. This could be the business process owner to pull the support, the IT resource to obtain a log, an individual with analytics skills to query a log, etc. It also may take time to obtain the needed information depending upon how difficult it is to obtain the information or where the information lies, such as in archived data logs.
Audit Trails in Relation to a SOC 1 or SOC 2 Audit
When considering audit trails and the impact on a SOC 1 report or SOC 2 audit:
- AT-C section 205 (Examination Engagements) paragraph .04 provides the definitions for Appropriateness of Evidence and Sufficiency of Evidence as factors when the service auditor is performing his/her procedures. Should the audit trail not provide the evidence needed or not be retained, available or reliable for the service auditors, the audit procedures may be hindered and a fully informed or correct conclusion may not be able to be reached.
- Statement on Standards for Attestation Engagements (SSAE) No. 18 paragraphs .A66-.A68 relate to professional skepticism of the service auditor in relation to reviewing evidence presented as part of the SOC audit procedures. Per paragraph .A67, “Professional skepticism is necessary to the critical assessment of evidence. This includes questioning contradictory evidence and the reliability of documents and responses to inquiries and other information obtained from the appropriate party. It also includes consideration of the sufficiency and appropriateness of evidence obtained in light of the circumstances.”
- SSAE No. 18 paragraphs .A69-.A70 calls for the service auditor to also exhibit professional judgment when “evaluating whether sufficient appropriate evidence for the service being provided has been obtained…”
Conclusion
In conclusion, an audit trail provides the history and evidence to support a particular activity, transaction, or event. It can also be used for a variety of purposes in addition to supporting internal and external audits. Without the availability of an audit trail, the ability to trace an activity, transaction, or event from start to completion is lost and conclusions cannot be appropriately attained or needed support obtained. Audit trails, though, are often quite readily available through the normal daily routines and transaction flows.
Please reach out if you would like to learn more about SOC 2 compliance requirements. Additionally, if you would like to learn more about any of our other audit services please don’t hesitate to contact us.
Lois started with Linford & Co., LLP in 2020. She began her career in 1990 and has spent her career working in public accounting at Ernst & Young and in the industry focusing on SOC 1 and SOC 2 and other audit activities, ethics & compliance, governance, and privacy. At Linford, Lois specializes in SOC 1 and SOC 2 audits. Lois’ goal is to collaboratively serve her clients to provide a valuable and accurate product that meets the needs of her clients and their customers all while adhering to professional standards.