When it comes down to collecting evidence for the SOC 2 audit itself, there are a few key points that one needs to remember. Obtaining and submitting the incorrect audit evidence can cause audit headaches as it will most times mean having to recapture, extract, and submit the evidence again – showing the necessary key elements.
However, remembering the key points beforehand can make this process efficient, seamless, and a total breeze.
The main purpose of an audit evidence is to verify and prove to the auditor that controls, processes, and configurations are in place, as you (the organization) claim they are. For example, if your backup control has a description stating that on a daily basis, there is an image of the production environment captured, and uploaded as a backup, then the evidence provided for this control would need to verify and prove this statement.
Keeping in mind the above control description, it is possible that someone may mistake the backup of the environment control for the audit trail backup control, which is another control required in SOC 2.
In this case, the organization may upload supporting evidence for this control to show that audit trails are captured, uploaded, and retained in a secure manner to prevent tampering, and in accordance with the retention policy. If a screenshot were to be snipped (as screenshots are often used for audit evidence), it may be difficult to see if it is taken from AWS Backup or if it is taken from AWS CloudTrail, for instance. One screenshot represents and logs audit trails, and the other is focused on the actual data backup.
With this knowledge, it is a lot easier to see how audit evidence is not always straightforward. When providing audit evidence, it is important that the relevant control owner understands exactly what they need to upload.
Using the same backup example mentioned above, let’s say the control owner went into AWS Backup and took a full screenshot, which would show the URL in AWS and the information on the screen itself (perhaps the existence of backups) and finally, the system timestamp. This would be a great piece of audit evidence, because:
All of the above will verify both the completeness and accuracy of the evidence.
The timestamp attribute is a very important one in the audit evidence. The system timestamp is what is used to verify when the data is extracted. As a SOC 2 audit report gives coverage over a certain date (Type I) or over a period of time (Type II), it is mandatory to prove all evidence comes from within the audit period itself.
As a SOC 2 audit will be performed over a specific system, it is also important to be able to verify and prove which system the data is extracted from. As customers and customer data are processed through the production environment, this is the environment in ‘focus’ during an audit. It is pointless to provide documentation and processes that take place in the QA environment, as this does not replicate the ‘real-life’ situation of the operations of the business.
Another consideration with audit evidence is the type of audit evidence. In some controls, it will be most efficient to provide screenshots as described above. However, when considering long lists of users, data, or any kind of record that needs to be provided, there are other considerations here. Extracting a listing from a system, saving it as a .csv file, and uploading this as audit evidence can be insufficient. Think about how easily you could extract a listing, remove a few problematic records, and upload the file.
To prevent this, it is necessary to prove that no manipulation has taken place. There are a variety of ways to do this, but some of the best practices include:
As you can see, there are many audit requirements that are non-negotiable when providing audit evidence. However, these concepts are pretty standard in most audit cases and once you are aware of and familiar with the process, collecting evidence will be a hassle-free process.
