It’s your technology and your security controls: Don’t let an auditor become your CTO

Auditors are meant to assess the effectiveness of an organization’s security controls against an established set of standards, not set policies and dictate which controls to implement. A certified public accountant who performs a SOC 2 audit will not be an expert in cybersecurity. The American Institute of Certified Public Accountants (AICPA) even states this in their guidance. The auditor should be an expert in assurance practices, and their job should be to ensure that security standards put in place are being met. They are not employed to tell the organization which technologies to deploy and controls to implement.

For businesses with decades of experience dealing with ever-changing regulations, audits and auditors, this is obvious. To their vendors, perhaps not so much. Now, more and more organizations are discovering that achieving SOC 2 compliance and demonstrating effective security protocols is required to do business. For these companies newer to the certification game, audits and audit preparation can be a minefield that complicates technology stacks, disrupts operations and busts budgets. 

I have been through this process many times over the years and have developed an understanding of how to avoid the mines. Here are my tips for managing a successful audit of your security controls.

Redefine the auditor relationship

Control design is the responsibility of the organization, not the auditor. Too often this basic truth conflicts with the auditor’s desired practice. Audit prep routinely includes auditors dictating which controls the organization should adopt: draft these policies, configure this list of cloud provider monitoring settings, and enable automated gates at those control points. This checklist approach is costly, can seem endless, and works against actual security.

Organizations using a checklist approach often waste time and money by creating useless policies, applying meaningless controls or even overlooking entire processes. This happens because the checklist approach does not account for an entity’s size, operational model or maturity. This process can also open the door for auditor-recommended security controls that will actually make a business’s data less secure.

An example of an auditor recommendation that stirs debate is the installation of desktop antivirus software. Despite becoming less and less necessary and increasingly likely to create vulnerability, auditor checklists routinely direct companies to install antivirus software onto desktop systems. Implementing controls like these can create a false sense of security and incur needless costs. Doing so also effectively turns the auditor into a de facto CIO or IT director as they are dictating what applications should or should not be part of the company’s technology stack.

Management decides on policy and defines its own unique controls to meet them based on its priorities. They can use the AICPA’s fantastic Trust Services criteria requirements as a guideline to help create policies. Despite what some auditors may suggest, specific policies are not laid out anywhere in that 63-page document. 

Policy creation should be up to the company, based on its own history and diligent forecasting, to craft security controls to fit its objectives.

Use your software, not theirs

Unfortunately, some auditors cross the line of AICPA recommendations and initiate the project by trying to implement their own software to track the audit internally.

Auditors often make the implementation of their software part of the standard contract. This adds cost and puts the burden on the organization’s IT staff without making the work more convenient for the client. 

Adding another application that is not within the control of IT is an uncomfortable vendor lock-in that creates a security vulnerability of its own. Auditor access should be limited to only the systems and data necessary to perform the audit. Rather than allow the deployment of auditor software that they control, organizations should prepare a data room themselves to keep sensitive information out of the hands of the auditor.

Any auditor should be able to work within these parameters using the technology stack in place unless company-defined standards cannot be met without additional deployments.

Focus on risk assessment, not checklists, for your security controls

Organizations need to create policies using a thoughtful, risk-based approach to setting security standards. A risk assessment is a key element of many security frameworks like SOC 2, HIPAA, ISO 27001 and NIST, but auditors often lack the expertise necessary to conduct one. Absent a guiding resource for performing a risk assessment, the checklist becomes a temptation for companies who want a certification or attestation as fast as possible. However, the results may not be optimal, and the process often takes far longer than a risk-based approach would.

With a risk-based approach, the organization does not waste time on misguided policies or the implementation of unnecessary technology. The risk assessment can lead the business to the exact policies it needs, as well as identify the repeatable controls appropriate for the organization. The completed risk assessment also serves as a required control for many frameworks. 

The resulting control set identified by a risk assessment can be mapped to any security framework. Once mapped, the gaps in coverage will become apparent. The risk-based approach identifies what additional controls the company needs to implement. These controls then become the standard of measure for the auditor. The organization uses them to facilitate the completion of security questionnaires and shares them with prospective clients.

Risk assessments don’t have to be complex or adversarial to the auditor. Adopting a risk-based approach can foster trust and focus all parties on making the organization more secure and accountable. Using a risk-based model, the company and the auditor function more as partners staying in their own lanes and working toward the common goal of implementing robust, demonstrable security controls. 

Audits are paving the way for greater trust between companies. They are a good thing. However, they can be a trap. Don’t let your auditor act as the CTO and don’t fall into the checklist trap. Right-sized compliance efforts using an effective risk-assessment process will ensure that control environments focus on the organization’s priorities. 

Justin Beals is cofounder & CEO of Strike Graph.