Tag: Technology

From Trust, but Verify to Zero Trust to CYA

There’s an aspect to auditing internal controls that has always seemed straight forward to me that for some reason others have trouble grasping. I figure it’s just a personality trait. It doesn’t really matter if the control is financial, operational, or technological, it all boils down to taking the control in question and asking the control owner to “prove it”.

In essence, as an auditor, we’re asking the control owner to prove that the control occurred on a specific day, week, month, or year, depending on the frequency of the control. This thought process has also served me well in the current dis/misinformation age. However, what do we do when the evidence provided is questionable at best? This is being taken to another level now with AI, which allows control owners to create evidence that is perfect. What do we do when the evidence is too perfect?

This ISACA SmartBrief on AI article got me thinking about the topic –> The Audit Evidence Crisis: How AI Deepfakes Are Rewriting Assurance Standards. The article recommends we move on from the “Trust, but Verify” approach to auditing into a new era of “Zero-Trust”.

Why a Zero‑Trust Approach is Essential

A zero‑trust mindset ignites inquisitive and professional skepticism that strengthens the auditor’s ability to:

  • Independently obtain audit evidence from IT and OT environment without interference
  • Validate the authenticity of evidence before relying on it
  • Detect manipulation in digital documents, images, and communications
  • Assess whether controls are resilient against AI‑enabled fraud
  • Reduce audit risk in environments where deception is increasingly automated.

Taking this a step further, this got me to thinking about how audit firms go about what I like to refer as CYA. I’ll refrain from spelling that out in hopes we all know what it means. There are a few steps during an engagement that deal with fraud and non-compliance, which requires the organization being audited to verify (sign) that they are unaware of a fraud or non-compliance.

  1. Contract/Engagement Letter – Signed prior to the engagement, this documents details auditor and client responsibilities, amount other topics. Client responsibilities include notifying the service auditor of any fraud or instances of non-compliance.
  2. Fraud and Non-Compliance Inquiry – Performed during the planning phase, this step involves inquiring with control owners at various levels (e.g., management, staff) whether they are aware of and fraud or instances of non-compliance.
  3. Management Representation Letter – Signed by the client at the completion of the engagement, prior to issuing the final report, this document reiterates responsibilities by the client to notify the auditor of any instances of fraud or non-compliance.

Now, let’s be real. They’re all manual responses and don’t really prove anything, just a CYA for the audit firm. However, I wouldn’t be surprised if audit firms update their engagement letter, fraud and non-compliance inquiry, and representation letter templates to include references to if/when AI is used to create audit evidence. To an extent, it’s already somewhat tangentially included, but it might need to be specifically noted going forward.

What is an SOC Examination/Report?

It’s hard for me to believe, but I originally got started with SOC examinations around 2004 when it was referred to as a SAS 70 (Statement on Auditing Standards No. 70). I was an internal auditor for a financial services company back then tasked with managing the individual SAS 70’s of various business units, of which there were upwards of 20 per year, and also managing the relationship with the audit firm performing the audits.

At the time, service organizations used the SAS 70 as an all-encompassing internal controls audit of operations and technology/security. It didn’t matter what type of company was providing the services, be it a payroll processing company or data center services provider, or who the prospective reader of the report was going to be, the SAS 70 report was used to fit the bill.

The industry realized there was a need to create separate report types to meet the unique requirements of service organization and their customers. This brought about the SOC 1, SOC 2, and SOC 3 examinations and reports.

The System and Organization Controls (SOC) examination was designed to help service organizations that provide services to other entities (clients/customers) build trust in the services being performed by assessing the controls over the services provided. A service organization could be a payroll processing company, credit card processing company, or just about any X as a service company (e.g., SaaS).

The independent service auditor SOC examination report provides assurance to the service organization’s clients on the suitability of design and operating effectiveness of the controls in place at the service organization to achieve the related control objectives. The independent service auditor is what many would refer to as a CPA firm.

Included below is a brief breakdown of the 3 SOC reports:

SOC 1

This examination and report most closely aligns with the former SAS 70, so much so that it’s still somewhat common to see references to SAS 70 in contracts between service organizations and their customers. This report is prepared in accordance with AT-C Section 320, “Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting”.

These reports are typically triggered by clients interested in the financial statement impact of the service provided by the service organization. With that said, the examinations will still include control objective and controls covering both operations and technology / security, similar to its predecessor, SAS 70.

Example cover page for an SOC 1 Type 2 Report.

SOC 2

This examination and report was created to meet the needs of modern IT and cloud services providers, focusing on the 5 trust services principles. The trust services principles include security, availability, processing integrity, confidentiality, and/or privacy. I’ll get into more detail regarding the trust services principles in a future post.

These reports are typically triggered by clients interested in the protection of data. Distribution of these reports tends to be more restrictive.

Example cover page for an SOC 2 Type 2 Report.

SOC 3

This report is based on the SOC 2 report, but is meant as a general use report that can be distributed more freely. The report includes a less detailed description of the system and does not include tests of controls and results. I like to refer to it as an executive summary of the SOC 2 report.