Author: Taylor Gavigan, CPA, CISA

What is it?

Similar to a System and Organizational Control (SOC) 2 examination, SOC for Cybersecurity focuses on an organization’s cybersecurity risk management program. SOC for Cybersecurity is different from SOC 2 in that it is intended for any type of enterprise, not just service organizations.

SOC for Cybersecurity affords a company the opportunity to provide their partners (i.e., customers, stakeholders) assurance that they are committed to cybersecurity best practices.

How an auditor will evaluate an organization’s SOC for Cybersecurity report:

There are two criteria used by the auditor: description criteria and control criteria.

Description criteria – The organization provides a narrative describing their cybersecurity risk management program. There are several requirements, or criteria, for this description as established by the AICPA Description Criteria for Management’s Description of the Entity’s Cybersecurity Risk Management Program.

• Nature of business and operations
• Nature of information at risk
• Cybersecurity risk management program objectives (cybersecurity objectives)
• Factors that have a significant effect on inherent cybersecurity risks
• Cybersecurity risk governance structure
• Cybersecurity risk assessment process
• Cybersecurity communications and the quality of cybersecurity information
• Monitoring of the cybersecurity risk management program
• Cybersecurity control processes

Control criteria – The baseline for the company’s system of internal control is up to management. Typically, management will adopt a framework for risk management and implement related control activities to mitigate cyber risk (i.e., NIST CSF, ISO 27001:2022). The auditor will evaluate the system of controls based on the framework selected.

Advantages of obtaining a SOC for Cybersecurity report:

• Internally, completing a SOC for Cybersecurity examination will help everyone on your team understand what you’re doing well and what you may be able to improve upon with respect to cybersecurity.
• You’re provided an objective opinion from an independent source that your cybersecurity risk management program is strong. Sharing this report with interested parties should provide a high level of assurance that your organization can be trusted with sensitive information.
• Competitive advantage over your competitors. SOC for Cybersecurity is a relatively new type of examination and it’s likely most of your competitors have not been through anything like it. The landscape, and related demands, of cybersecurity is changing everyday – being early will be nothing but helpful as you try to win deals.

Cost

The cost of one of these examinations is dependent on several factors but most importantly the scope (i.e., organizational size and complexity, complexity of the control activities) and the period covered by the auditor’s opinion.

Companies have the option of engaging the auditor to either:

• Evaluate the design of their cybersecurity program at a specific point in time (i.e., as of December 31, 20XX) or
• Evaluate the design and operating effectiveness [of controls] of the cybersecurity program for a specified period of time (i.e., January 1, 20XX to December 31, 20XX).

The latter provides a higher level of assurance to report users that not only do you have well designed procedures implemented but also that they have functioned as intended over a period of time. These types of reports are more costly due to a higher level of involvement from the auditor.

Summary

SOC for Cybersecurity is for all companies offering a service or selling a product, for-profit and non-profit. It’s a fantastic way to demonstrate your commitment to cybersecurity to your customers and stakeholders, and may help close deals that involve sharing sensitive information.

They are also a great tool for on-going management of your cybersecurity program. An external assessment may uncover gaps or weaknesses in your system of control that may otherwise have gone unnoticed.

If you would like to learn more about SOC for Cybersecurity, or discuss other types of assessments that may be beneficial to your organization, please do not hesitate to reach out to our team.

Generative AI tools have become the shiny new toy and perhaps rightfully so. There are various ways teams and organizations may utilize them to help scale and drive business but the one I see most often is as an “assistant” of sorts for Sales and DevOps.  

For example, these tools may provide immense relief to these teams when it comes to administrative tasks and allow team members to focus on customer interactions and product value. In doing so, individuals may be tempted to share personal and/or company proprietary information with the tool. We recommend organizations consider the following concepts to mitigate the assumed risks of using these tools. 

Restrictions When Using Publicly Available Tools

Establish guidelines for employees/contractors that wish to use publicly available tools.  

• Prohibit the use of customer PII or other confidential information
• Tie to other policies (i.e., data classification and definitions of “PII” and “confidential information”) to make communication consistent
• Prohibit the use of organizational data (i.e., product information, personnel)
• Prohibit the use of proprietary/confidential data sourced from other third parties
• If an available option, opt out of allowing the tool to train using the information provided

Contractual Agreements

Establish commercial relationships with tools prior to use. Both sides agree on the service level commitments made and there is (hopefully) an emphasis on the security and confidentiality of the data/information shared with the tool. 

AI Vendor Procurement Process

Explicitly require approval of a generative AI tool prior to integrating with your system(s). This does not have to be a standalone policy and can be included in your Vendor/Third-Party management policy. 

This may already be part of your vendor management program but it’s also wise to classify the tools (if using multiple) by their allowed use cases.  

• Unrestricted – may be used freely 
• Restricted – may only be used in specific circumstances (define use cases as specifically as you can)
• Prohibited – drawback to this is that it may become cumbersome to maintain and may create more questions as more and more tools become available 

Security Awareness Training

Hopefully security awareness training is already part of your cybersecurity program. If you’ve ever helped construct a security awareness training exercise, you are aware that much of the information is also found in company policies. As noted previously, your organization should establish policy and procedure with respect to AI but also be sure to communicate this to your employees and contractors. We suggest adding training regarding AI tooling to your current program that includes, but is not limited to: 

1. Background – what generative AI/LLMs are and how they work
2. Vendors – what tools are allowed and which are not
3. Risks – how the tools may be used in your organization and what types of data may be input

Disclaimer

If you’re using AI to generate responses to inquiries or any other type of output, it’s wise to add a disclaimer to the communication. This lets the reader know the response was generated by using AI and that there is some responsibility on them to proof, review, and/or edit before they use it themselves. 

Technical Considerations

1. If submitting source code to AI tools, ensure the information will not be stored and/or used for training purposes
2. Be careful to not include code samples that mimic or reflect your organization’s proprietary information
3. Engineering teams should conduct input validation testing before release to a production environment in an effort to mitigate the risk of prompt injection
4. Monitor/audit – identify and authenticate users of the service to prevent malicious accounts from gaining access 

These recommended considerations are not exhaustive. Organizations should perform their own risk assessment with respect to AI tools actually used and implement appropriate control activities to mitigate the risks to acceptable levels. 

Timing of your next SOC

Your auditor just sent you your first official SOC report and you can finally satisfy that one (or several) customer request to see it. What now? Below are a few common questions we have received when discussing the timing and cadence for SOC compliance.

Does my SOC report expire?

Technically, no. A SOC report is not a traditional certification, but is rather an attestation, and the auditor’s report does not expire. However, the user of the report may determine that the period covered by the auditor’s report is no longer relevant. SOC reports are often considered stale or irrelevant by users after 12 months.

Additionally, when you initially receive your SOC report from your auditor, you’re able to register with the AICPA and display their SOC logo on your website and other marketing materials. Per the AICPA’s terms and conditions, a service organization may only display the logo for 12 months immediately following the date of the auditor’s report.

How often do other organizations go through SOC?

The most common and recommended cadence for SOC is a continuous cycle of compliance. For example, an organization who has never gone through SOC before will likely decide to go through an initial SOC Type 1, followed by an immediate 3 to 6-month SOC Type 2, and then follow that with 12-month Type 2s in perpetuity. Using dates for reference, SOC Type 1 as of January 1, 20XX, SOC Type 2 from January 1, 20XX to June 30, 20XX, then SOC Type 2 from July 1, 20XX to June 30, 20XX+1. This cadence would provide your organization with continuous, demonstrable compliance in perpetuity.

While the above sequence is typical it is not a requirement. We have had clients complete a SOC Type 2 covering 3 months, and then come back a year later and do another SOC Type 2 covering 3 months. Maybe this could work for your customers, but there are some risks to this approach. For instance, a vendor management department would likely be concerned that there was a 9 month period of time in between in which no independent third-party was attesting that your policies were being followed and your controls were operating effectively.

In summary, continuous compliance is the most conservative approach.

Are there any other disadvantages to putting off our next SOC until next year?

Another important consideration is efficiency. Constantly being engaged in an audit develops familiarity for both your team and the audit team. From the auditor’s perspective, this familiarity may mitigate a number of questions that would otherwise have to be discussed in order to understand your organization and/or system. Likewise, your team would likely develop good habits regarding documenting and providing evidence to support the functioning of internal control on a regular basis. These efficiencies directly impact the price of the examination.

What if our organization and/or service has significantly changed since our last SOC report?

This is common for maturing companies and not a big deal. The AICPA thought of this when designing the Description Criteria® and established a specific criterion for organizations to disclose changes that occur within an auditable period in their next SOC. This section is a convenient way for users of your report to quickly identify those significant changes and evaluate how those changes may impact their organization (if at all). You do not have to put off a SOC examination due to changes you are experiencing.