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 a set set of standards, not to set policies and dictate which controls to implement. A chartered accountant who conducts a SOC 2 audit is not a cybersecurity expert. The American Institute of Certified Public Accountants (AICPA) even states this in their guidance. The auditor must be an expert in assurance practices and it must be his or her role to ensure compliance with established security standards. They are not used to tell the organization which technologies to deploy and which controls to implement.

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

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

Redefines the relationship with the auditor

The design of control is the responsibility of the organization, not the auditor. Too often this fundamental truth conflicts with the auditor’s desired practice. Audit prep routinely involves auditors dictating which controls the organization should apply: set these policies, configure this list of cloud provider monitoring settings, and enable automated gates on those checkpoints. This checklist approach is costly, can seem endless, and conflicts with actual security.

Organizations that use a checklist often waste time and money creating useless policies, applying meaningless controls, or even overlooking entire processes. This happens because the checklist approach does not consider an entity’s size, operating model, or maturity. This process can also open the door to auditor-recommended security measures that actually make a company’s data less secure.

An example of an auditor’s recommendation that generates much discussion is the installation of desktop antivirus software. Despite becoming less necessary and creating more vulnerabilities, auditor checklists routinely drive companies to install antivirus software on desktop systems. Implementing such controls can create a false sense of security and incur unnecessary costs. By doing this, the auditor also effectively becomes a de facto CIO or IT director as they dictate which applications should or should not be part of the company’s technology stack.

Management decides on the policy and defines its own unique controls to meet it based on its priorities. They can use the AICPA’s fantastic criteria requirements for Trust Services as a: guideline: to help make policy. Despite what some auditors may suggest, nowhere in that 63-page document is specific policy set forth.

It should be up to the company, based on its own history and careful forecasting, to create policies to design security controls that fit its objectives.

Use your software, not theirs

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

Accountants often make the implementation of their software part of the standard contract. This increases costs and puts pressure on the organization’s IT staff without making work easier for the customer.

Adding another application that is not within IT’s control is an inconvenient vendor lock-in that creates its own security vulnerability. Auditors’ access should be limited to only the systems and data necessary to conduct the audit. Instead of allowing the use of auditor software that they audit, organizations must set up their own data room to keep sensitive information out of the auditor’s hands.

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

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

Organizations must create policies using a thoughtful, risk-based approach to establish security standards. A risk assessment is an important element of many security frameworks such as SOC 2, HIPAA, ISO 27001 and NIST, but auditors often do not have the expertise needed to perform one. In the absence of a guideline for conducting a risk assessment, the checklist becomes a temptation for companies that want a certification or attestation as soon as possible. However, the results may not be optimal and the process often takes much longer than a risk-based approach.

With a risk-based approach, the organization does not waste time on wrong policies or implementing unnecessary technology. The risk assessment can guide the company toward the exact policies it needs, as well as identify the repeatable controls that are appropriate for the organization. The completed risk assessment also serves as a required check for many frameworks.

The resulting control set identified by a risk assessment can be assigned to: each security framework. Once mapped, the gaps in coverage will become apparent. The risk-based approach identifies which additional controls the company must implement. These controls then become the benchmark for the auditor. The organization uses them to facilitate the completion of safety questionnaires and shares them with potential customers.

Risk assessments do not have to be complex or hostile to the auditor. By adopting a risk-based approach, confidence can be built and all parties can focus on making the organization safer and more accountable. Using a risk-based model, the company and auditor function more as partners who stay in their own lanes and work towards the common goal of implementing robust, demonstrable security controls.

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

Justin Beals is co-founder and CEO of Strike chart†