What is System & Organizational Control Report (SOC 2)?
Businesses are scrutinizing who they work with. There is increasing security and privacy risk between organizations which share data or rely on each other for services. To combat this risk, organizations are implementing vendor management programs to ensure security and privacy are being addressed. Often these programs will have a requirement for a third-party assessment, such as a System and Organization Control Report, also known as SOC 2.
SOC 2 Reports are the easiest of the many assessments organizations can undertake. These assessments are built upon the AIPCA Standard of SSAE 18 and the Trust Service Criteria (TSC). Due to the AICPA’s backing, SOC 2 Reports are widely known and accepted as assurance for security and privacy risk mitigation. Prior to beginning a SOC 2 assessment, an organization must have a documented and implemented an information protection program. To ensure a successful outcome for the engagement, best practice is for the organization to complete a readiness exercise.
An information protection program begins with a collection of policies and procedures which address physical and logical security, data protection, access controls, among much else. Typically, policies and procedures are developed based up on a security framework such as the National Institute of Standards and Technology (NIST) 800-53 or another similar framework. The policy and procedure documentation typically takes 3-6 months. The information protection program begins with documenting current practices and identifying the gaps based on best practice.
During the rollout of the information protection program, SOC 2 readiness can begin. The first step is to determine the scope of the assessment. A SOC Report may address a location, a process, or the entire entity, based upon why the assessment is needed and who will use it. Once the scope is determined, the organization will decide which of the five TSCs should be reported on. The five criteria are Security, Confidentiality, Availability, Processing Integrity, and Privacy. Often this is dictated by user entities of the report. An organization should also consider what is relevant to the services it provides. For example, a data center should report on Security and Availability. Users will want to know that a level of security exists and that they will be able to access their information in accordance with their Service Level Agreement (SLA).
Once the TSC and scope are established, the organization will describe the system in scope based upon the AICPA’s Description Criteria. This document is called the System Description and will identify the internal controls upon which the assessment will be based. This standardized format is what makes SOC Reports comparable in the marketplace. The system description is typically a 10–20-page narrative of the system or process and describes such elements as services being provided, service commitments, and system components, to name a few.
The last step of SOC 2 readiness is drafting of “Management’s Assertion.” Typically, this is a template letter which management drafts and signs to include in the SOC 2 Report.
Readiness can take 3-6 months depending up on complexity and resources available. Upon completion of SOC 2 readiness, an organization is ready for a SOC 2 – Type 1 Report. A Type 1 reports on the fairness of presentation and suitability of design of the controls at a point in time. This report is a review of everything completed in readiness, and a report is issued by a CPA firm to express an opinion as to whether all requirements have been met. It sets the baseline for a SOC 2 – Type 2 Report.
A SOC 2 – Type 2 Report typically occurs 6-12 months after the Type 1 Report is issued. A Type 2 Report reports not only on the fairness of presentation and suitability of design of controls, but also the operating effectiveness of those controls. At this point, the procedures developed in the information protection program need to be in place and operating as defined by the organization. Evidence of control operation should be generated throughout the period. During the assessment, the auditor will sample this evidence to support their opinion on control operating effectiveness. If a control does not operate during a period because a control trigger event did not occur, there are ways of handling that in the assessment without causing a testing exception. However, if a control does not operate, but should have, that is noted in the report as an exception. The auditor may perform additional procedures to determine if the exception(s) rise to a level material enough to warrant a modified opinion.
Assuming an unmodified opinion, the SOC 2 – Type 2 Report is issued to the organization and the assessment recurs on an annual basis. Generally, there is no reason to perform readiness again unless the system or scope of the report change dramatically.
10 SOC 2 Tips
- Redundant Controls – The same control will be used multiple times in the TSC mapping. Use the exact same wording each time the same control is used. This will reduce complexity of the report and increase audit efficiency. Audit efficiency is important to keeping fees down and reducing the amount of evidence an auditor requests.
- Single control for criterion –Attempt to have multiple controls to support a criterion. Should one control fail it will be necessary to have a compensating control for backup. If there is no compensating control, a control failure could result in a modified or qualified opinion.
- Internally audit your controls – Throughout the period, self-audit your controls. No one likes to find out about a control failure during the assessment. Saving your internal control evidence in a centralize repository is also helpful. It ensures when audit time comes there is one place where all your evidence is located.
- Evidentiary dates – Auditors look to ensure the documentation they collect is date stamped during the reporting period. This includes policies and procedure documents. Ensuring these documents are annually reviewed is critical not only for the assessor evidentiary support, but to match documentation to changes in the business and business processes.
- Be proactive – If you are in an industry sharing data with business associates providing services to large businesses or government agencies, you will need a SOC 2 Report at some point. Don’t wait until it is requested. Having a SOC 2 ready when requested demonstrates not only that an organization is mature, but it will likely be easy to work with.
- Reduce customer questionnaires – As part of the vendor management process, businesses will often send lengthy security and privacy questionnaires. Leverage your SOC Report to avoid filling out these documents. Often a SOC 2 Report is an alternative to these questionnaires, or an abbreviated questionnaire can be filled out.
- Leverage your auditor – Your audit firm has very likely worked with many different clients and probably several in your industry. They have real-world experience and can reduce the effort on your end.
- Be honest – Only document what you are doing or can do. Adding controls or information to a SOC 2 Report because “it would look good” or you “plan to implement” can lead to a qualification of the report if there is not sufficient evidence to support the statement or control.
- SOC 2 is not an IT responsibility – IT plays a large role in the execution of internal controls, but much of the information needed for the assessment is business governance. IT doesn’t necessarily know long-term business objectives or risk tolerance. Often business owners or compliance personnel lead the SOC 2 effort, and are supported by IT, HR, and other departments.
- Address change – Businesses change, people within businesses change, policies and procedures change. Ensure all policies and procedures along with the SOC 2 System Description is reviewed annually. Changing these documents is not a bad thing. It demonstrates that the Company is monitoring and managing its security and privacy risk.