SOC 2 CC2: Common Criteria related to Communication and Information

What is SOC 2 Communication and Information (CC2)?

CC2 of the SOC 2 Common Criteria covers communication and information controls recommended to be implemented. Communication and Information, as with the other Common Criteria, incorporates COSO requirements. Developed by the Committee of Sponsoring Organization of the Treadway Commission (COSO), these requirements are used to continuously update and revise the standard for internal controls the SOC 2 represents.

Communication and Information includes policies, procedures, and documentation criteria related to communicating both internal and external to the organization.

What are the Requirements for SOC 2’s CC2?

Documentation

When an auditor puts his or her hat on and starts to gain an understanding of how your company and system operate, the first place that they will turn is to your documentation. While documenting isn’t as fun as doing your day job, it is a way to bring a third party up to speed quickly when they have no other contextual understanding to your company or system. From an auditor’s eyes, if it isn’t documented, then it didn’t happen (or doesn’t exist). .

General Company Policies & Procedures

We have already addressed some of the general company policies and procedures in our article about CC1 – Control Environment. These include having a Code of Conduct, Employee Handbook, and other company and HR policies. As a rule, if we’re discussing a requirement through this SOC 2 requirements series, then it is highly suggested to write down what you do about it and keep that up to date. It may seem like a lot, but it will save your bacon as you’re going through the audit process.

The documentation that we describe below should be made available to employees to reference should the need arise. This means it should be posted on an intranet site, HR portal or other place where your company houses documents for employees.

System Documentation

It’s important to document the functions of the Company’s system. The major components should include data flow charts, network diagrams, as well as pertinent architecture diagrams. System boundaries, system processing and user manuals should also be produced. The documentation should be reviewed at least annually along with any major environment changes.

Information Security Policies & Procedures

Your organization needs information security policies in place that detail the policies you follow when working to ensure information security. At a minimum, the policies should address the following areas:

• Acceptable Use
• Access Control/User Provisioning
• Anti-Malware/Virus
• Asset Management
• Availability and Continuity
• Business Continuity and Disaster Recovery
• Change Management
• Compliance and Audit
• Data Backup
• Encryption and Key Management
• Incident Response
• Security Policy Exception/Variance
• Information Classification
• Log Management
• Media Handling
• Network Security
• Password Management
• Patch Management
• Personnel Security
• Physical and Environmental
• Remote Access
• Risk Assessment
• Secure Development
• Security Awareness and Training
• System Development Lifecycle
• Vendor Management
• Vulnerability Identification

These policies should be continuously updated, including upon change to the environment, but at a minimum annually reviewed and signed off on by management. Policies should also assign the responsibilities within them to a specific individual or group of individuals.

Communication

Communication requirements mentioned within CC2 of the SOC 2 standard follow COSO Principle 14.  Areas touched on include communication expectations between the Board of Directors, management, and employees, and between the company and external parties.

Board of Directors

Communication between the Board of Directors and management includes regular meetings to discuss company objectives and any relevant objective updates. Effective communication at this level helps the Board of Directors and management execute their roles overseeing internal control structure. The board communication is paired with the Oversight of Management item that we discussed in our CC1 post.

Employees and Contractors

We’ve already discussed the Employee Handbook, Job Descriptions and Code of Conduct in our previous post, and it just so happens that distributing that documentation and having employees acknowledge that they’ve read and understood it is a great first step towards communicating with employees. To take a second step, management should determine other communication channels to make sure that employees and contractors can maintain an understanding of the direction of the company objectives and their role in it.

Additionally, the employees and contractors that utilize the system (whether it is your IT staff, customer support or other functions) need to understand the system. In addition to maintaining the System Documentation that we mentioned earlier in the post, there should be a process to communicate changes to employees related to both company policies and procedures and related to changes to the system.

The distribution of release notes to employees is the most common way that we see system changes being communicated to employees and contractors.

Customers

Customers may be the bane of every company’s existence; however, they are often critical for your company to succeed. To be successful with your customers, there should be established methods of communication to sustain the lifecycle with them.

• Initial Contracts – The initial contract with the customer should be executed by both parties and include any commitments that your company is making (for example, security, confidentiality, and availability commitments)
• Commitment Changes – If there are changes to your commitments with your customer or other expectations, those should be communicated in accordance with the contract (i.e. via a contract amendment or other written communication)
• System Documentation – Much like employees and contractors, your customers will need to understand how to utilize your system. Having user manuals, knowledgebases or other forms of documentation are necessary.
• System Release Notes – Customers should be made aware of changes, however, the level of detail that they receive may differ from the level of detail that employees receive.
• Customer Support – Customers should have defined ways to communicate issues to you. For example, a support email address, ticket portal and/or phone number. There should also be a process to manage the issues that are raised including an appropriate escalation process.

Security Awareness Training

We have previously pondered the question whether a company needs security awareness training, and as a spoiler to that article, the answer is a resounding yes. You can develop your own course content, or you can purchase training content from a variety of vendors. Here are the basics that we look for when evaluating your Security Awareness Training program.

General Security Awareness Training

General training gives employees and contractors a baseline of understanding to their responsibilities related to security. While there is not a set of required content, it should be based upon current risks in the security realm that are relevant to your company. Employees and Contractors should be trained upon hire and at least annually thereafter.

Role Specific Security Awareness Training

Certain roles within the organization pose a higher risk than the average employee. This can include your security staff, your development staff and those with privileged access to systems. You should consider the risks posed by these groups and add additional training if it is warranted. At a minimum, we like to see developers receive secure development training (i.e. OWASP Top Ten) as it’ll help support some of the requirements in CC8.

Ongoing Security Communications

The security landscape is not a static environment; thus, your security awareness program shouldn’t be static either. As part of your ongoing assessment of risk, as you identify new or changing risks, they should be communicated to your employees and contractors. This can take many forms such as a regular security newsletter, lunch and learn sessions or sending scrolls via carrier pigeon.

Phishing Program

Phishing programs can help your company measure the effectiveness of its other security awareness efforts and identify personnel who may be susceptible to “being human.” One of the questions we often get is whether a phishing program is required to get through the SOC 2 assessment. Our response is everyone’s favorite answer to hear from an auditor: It depends. Then they ask, “What does it depend on?” and we say “risk”.

We’ll discuss risk more in our future CC3 post, but in short, the company should consider its variety of risks and controls in place and if it feels that a phishing program would mitigate important risks, then one should be implemented. If the company believes that the risk is low enough due to other controls that are in place, then there’s not a need to implement one.

On the plus side, many vendors will bundle their phishing platform with security awareness training content that makes it cost effective to implement both under the same umbrella. If you’ve got it anyway, you might as well use it!

SOC 2’s CC2 Summary

While cannot hope to cover every specific CC2 requirement related to communication and information in a single post, this is a great starting point. If communication between the various internal and external entities of the business are clear, maintained and documented, this section should be an easy pass. Most issues we see here is a lack of maintaining evidence of these control activities, not the lack of control activities themselves. If you want to go further down the rabbit hole, we are here and ready.  Reach out to us with a phone call or drop us a note.  We are ready to connect!