For a smooth SOC 2 process, companies should ensure controls are accurate, efforts are effective, and responsibilities are communicated. Without these, the rest of your program will likely run into exceptions and struggle to meet the criteria.
While performing these seems easy, it can be difficult to understand what should be done to achieve them. Some tips include documenting processes and requirements in-depth, templatizing all communication efforts, and reviewing changes against the control set and legal requirements.
By documenting your processes and requirements in depth, you are ensuring that there is a clearly defined process that everybody should be following and that commitments made by the company are outlined for personnel to carry out. If these are followed, the likelihood of exceptions occurring due to a lack of understanding of responsibilities and commitments will be diminished. Personnel should have access to all policies and procedures that they are expected to adhere to. If personnel run into issues and cannot follow the policy, they can address those with the appropriate parties to see if there is a way to document the issues and decisions made so that control commitments are still met despite the deviation. As such, it is beneficial to include a line within the policy regarding who can be contacted regarding potential issues.
Typical policies, procedures, and other documentation that will help ensure that responsibilities are communicated, and efforts are effective include;
- The procedures for documenting and treating findings from vulnerability scans, penetration tests, risk assessments, audits, and any other assessments, who perform these, and when.
- A policy to include a listing of services used to support the network and system infrastructure and how each must be configured to meet requirements and commitments.
- Documentation to include a listing of system performance and security monitoring tools, what they do, how they are configured, who gets alerts from the tools, and how those alerts should be treated.
- Examples include Cloudflare, Datadog, SolarWinds, CloudWatch, GuardDuty, etc.
- The procedures for every communication channel for users, both internal (e.g., personnel) and external (e.g., customers), to contact the company, how the channel is meant to be used, who is supposed to receive communications, and how they should document and respond.
- Channels for communication can be separated by many different types of concerns, such as privacy and security concerns or a need for technical support.
- Document, typically found on the public website, of commitments and requirements related to security and other included trust services criteria that are made to users.
Your policies and procedures will cover most internal communications. However, when this isn’t the case, templatizing your communication efforts based on the requirements (both legal, contractual, and other) will make it easier to ensure these requirements are met and less likely to be forgotten or overlooked. The types of communication that should be templatized are;
- Commitments made to users, regarding security and other included trust services criteria,
- Changes to the above commitments to users,
- User’s responsibilities to the company, including reporting issues and how to do so,
- How users can contact the company and what for,
- How users can use the system, including system boundaries, what information they will be expected to provide, and what results they can expect,
- Notification of incidents affecting users.
These could be written in an email template, a notification template, a contract template, on the public website, or within a system description template.
- Reviewing Changes
Controls should have control owners, and it is a best practice to obtain a list of controls in order to assign ownership to the members of management that are responsible for ensuring they operate as intended, otherwise known as operating effectiveness. Once these are assigned, all potential changes should be communicated to the control owners and reviewed by them and other members of management. Changes may need to be reviewed with legal advisory at times. Control owners should also ensure that their processes have not changed without their knowledge by performing their own internal checks for the controls (you can use Phalanx GRC as one such way to track and document your checks).
Many changes need to be considered when gearing up for a SOC 2 audit. These would include changes to;
- The procedures in use,
- The business environment,
- Technology in use, and
- The regulatory requirements (e.g., new laws and regulations).
There should also be a way for personnel to suggest changes to policies and procedures for review based on;
- Desired changes to the processes,
- Required changes to the processes, or
- Changes that have already taken place.
This would allow for the changes to be considered regarding the controls put in place for the SOC 2 audit so that the controls or procedures can be corrected in a timely manner. Lastly, ensure that all of these changes and their reviews are documented so you can back up your decisions.
By implementing these procedures, you have a better idea that your controls are accurate, your efforts are more likely to be effective, and responsibilities are communicated. Accurate controls are obtained by ensuring that processes and requirements are documented, and current and changes are reviewed. Effective efforts are met by using your monitoring tools and performing your assessments, including self-assessments, remediating the findings defined in procedures, and reviewing the changes. Communication of responsibilities is met by documenting processes, ensuring access to them, and templatizing required communications.
Questions about SOC 2? Check out our SOC 2 Learning Center!