Recap: Understanding SOC 2 Reports: Types, Purposes & Key Benefits Explained

RSI Security hosted a webinar with Mueller to discuss the types, purposes, and benefits of SOC 2 reports. Panelists discussed aspects of SOC 2 audits, risk management, and assessment of organization-specific controls. Read on to learn more about the different SOC reporting frameworks, especially SOC 2 reports.

The webinar host, Eileen, introduced the panelists:

• Drent Shields, an audit partner from Mueller’s risk and control team
• Kyle Wehrli, an audit manager from Mueller’s risk and control team
• Nick Padron, a senior security consultant from RSI Security

 

What is a SOC Report? 

Kyle presented the first portion of the webinar. A System and Organization Controls (SOC) report—previously called a Service Organization Report—is an audit of internal controls over a service organization’s defined system or service. Only CPA firms can issue a SOC report since it is an attestation.

 

Contents of a SOC Report

SOC reports are divided into five sections:

• Auditors opinion
• Service organization’s assertion
• System description
• Auditor’s test of controls (only available for Type 2 SOC reports)
• Other information provided by the service organization

Kyle broke down the various naming conventions for SOC reports:

• SAS 70 – The first SOC 1 reporting format from over 11 years ago.
• SSAE 16 – Superseded SAS 70 but still refers to SOC 1 reports.
• SSAE 18 – Current standard for SOC 1 and SOC 2 reports.

Although “SAS 70”, “SSAE 16”, and “SSAE 18” are still used in contracts by some vendors, they still refer to the respective SOC reports. 

 

Request a Free Consultation

 

Types of SOC reports

Although several SOC reports are currently used, SOC 2 reports are growing in demand.

 

SOC 1 Reports

SOC 1 reports pertain to the internal controls related to financial reporting and apply to service organizations whose services impact users’ financial statements. 

Kyle noted that SOC 1 reports were not designed for distribution to customers. However, providing customers with SOC 1 reports shows the presence of controls.

 

SOC 2 Reports

SOC 2 reports have grown to apply to many service organizations. SOC 2 reports are based on the AICPA Trust Services Criteria (TSC) methodology, with their scope defined by a service organization’s specified system or service.

The primary audience for SOC 2 reports includes:

• Prospective customers
• Existing customers
• Vendors
• Business partners

SOC 2 reports are also in demand due to data security concerns.

 

SOC 3 Reports

SOC 3 reports are brief, accessible to non-technical audiences, and do not contain sensitive information like SOC 2 reports. SOC 3 reporting is also meant for marketing purposes, such as on company websites. 

 

Other SOC Reports

SOC for Cybersecurity reports apply to any company, regardless of industry, and are used for cybersecurity risk management. A SOC for Cybersecurity report communicates the existing cybersecurity risk management controls in an organization.

Also relatively uncommon, SOC for Supply Chain reports are much newer and relate to production, manufacturing, and distribution systems.

 

Which SOC Audit is Right For You?

Kyle noted that customers may not always ask for specific SOC reports in contracts, instead referring to SAS 70, SSAE 16, or SSAE 18.

In such instances, consider SOC 1 reports if you provide services that directly impact your customers financially, such as:

• Payroll services and employee benefits processing
• Medical billing
• Claims and collections processing
• Professional law and accounting firms

You can consider SOC 2 reports if you are a service organization that holds customer data. Most of the growth of SOC 2 reports is due to the need for data security because of greater technology accessibility. 

Organizations that might need SOC 2 reports include:

• Data centers
• Application hosting firms
• Co-location center firms
• Managed security service providers (MSSP)
• Cloud-based Software-as-a-Service (SaaS)

Kyle mentioned that professional law and accounting firms are getting asked for SOC 2 reports because of the sensitive data in their systems.

 

Trust Services Categories

Kyle went ahead to break down the Trust Services Criteria (TSC), classified into five categories:

• Security – Also called the Common Criteria, Security is the most common and extensive category covering operation controls.
• Availability – Applies to organizations that must provide certain uptime for critical services
• Processing integrity – Similar to aspects of a SOC 1 report, this category addresses the accuracy and completion of data processing.
• Confidentiality – Applies to measures that safeguard the confidentiality of sensitive data
• Privacy – Addresses aspects of data privacy, but less commonly used
• Additional SOC 2 Add-Ons – Service organizations can also conduct audits for aspects of other compliance frameworks via add-ons. For example, as an alternative to HITRUST, you can audit your security controls based on the TSC Security Category and the HIPAA Security Rule.

Kyle noted that if your contract asks for a SOC 2 report but does not specify categories or criteria, it typically requires auditing controls related to the Security criteria.

 

How Can You Become SOC Compliant?

SOC audits may be challenging, especially when new to SOC compliance. Therefore, it’s easier to break SOC compliance down into three processes.

 

Readiness Assessment

Compliance starts with a readiness assessment, which can be conducted internally. However, internal readiness assessments require tremendous resources and expertise. A typical assessment involves an organization’s internal auditor and a security firm.

Based on defined audit criteria, the readiness assessment involves:

• Interviewing key stakeholders across departments
• Documenting existing controls after interviewing stakeholders
• Identifying gaps and weaknesses based on SOC 2 controls and criteria

During a readiness assessment, it is critical to engage your auditor on the suitability of control design to ensure you meet SOC 2 criteria. 

 

Remediation

Here, a security firm can help you address gaps and weaknesses identified in a readiness assessment by identifying:

• Suitable controls to address existing vulnerabilities via:
  • Penetration testing techniques
  • Vulnerability scanning tools
• Best practices for implementing remediation steps

An auditor can only help you assess the suitability of controls but cannot provide remediation advice.

 

Undergoing Audit

Factors to consider when preparing to conduct a SOC audit include:

• Selecting an audit firm that suits your needs (ideally, before starting the compliance process)
• Deciding between a SOC 2 Type 1 and Type 2 audit
• Commencing an audit, depending on Type 1 or Type 2 

 

SOC 2 Audit Timeline

The timeline of a SOC 2 audit is variable and includes:

• Readiness assessment (one to three months) – On-site work can take one to three weeks, depending on:
  • Verification of assessment accuracy by control owners 
  • Identification of gaps and weaknesses 
• Remediation (weeks to months) – Is the most variable, depending on:
  • Resources available to a service organization
  • Organization priorities and contract changes
• Type 1 exam – Conducted first, Type 1 audits typically take two months, broken into:
  • Two weeks of testing
  • Six weeks of drafting, quality control, and wrapping up

 

Type 1 vs. Type 2 Reports

Kyle explained the differences between Type 1 and 2 reports:

• Type 1 report is at a place in time and is less intensive than a Type 2 report, which is recurring and conducted over a defined period.
• Organizations typically start with a Type 1 audit to address any findings before they are communicated. 
• A Type 1 report does not provide the assurance most vendors require. However, it shows that a service organization has some established controls.
• SOC 2 Type 2 reports typically take much longer than Type 1 reports.

Understanding the differences between Type 1 and Type 2 can help organizations choose the appropriate audit.

 

Initial SOC Compliance Challenges

Kyle finished by listing challenges to SOC compliance include:

• Incomplete or ineffective risk assessment 
• Lack of documented policies and procedures 
• Resource constraints 
• Lack of executive buy-in
• Inadequate documentation of control performance 
• Inconsistent execution of controls while under audit
• Lack of transparency 

These challenges can affect the effectiveness of SOC reports for organizations, regardless of size.

 

Risk Management

Nick from RSI Security discussed risk approaches to SOC compliance, focusing on security program management to align with core business functions. He emphasized the importance of organizations growing while meeting their security needs.

Organizations must prioritize IT solutions that support mission-critical business functions, especially for technology and web application uptime.

 

Common Risks and Security Services

Organizations must focus risk management efforts on:

• Understanding the risks due to security gaps or process maturity
• Managing a program year over year

Key risks include:

• Loss of corporate, customer, or employee records, addressable via:
  • User access review
  • Workflow authorization for data access
  • 24/7 monitoring and security
• Regulatory compliance (e.g., SOX, GDPR, CCPA), addressable via:
  • Internal and external audits
  • Business partnerships to ensure annual compliance
• Emerging technology and new risks (e.g., remote access to data, collection of data, cloud technology procurement), addressable via:
  • Strategic alignment between business and IT
  • IT involvement in procurement decision-making
  • Thought leader engagement for informed decision-making

Organizations can address key risks with strategic security decision-making processes.

 

Cybersecurity Risk Management 

Nick mentioned five focus areas for maintaining an effective cybersecurity risk management program:

• Formal risk assessment to identify threats and their potential business impact
• Review of existing controls for enhancement
• Tracking of dynamic risks to provide visibility to stakeholders, especially during growth
• Clarity of roles and responsibilities for risk decision-making
• Risk awareness to drive good risk-based decisions

Organizations must address any action items from risk assessment timely and effectively. 

The keys to deciding security initiative implementation include:

• Considering risk reduction
• Demonstrating business value
• Meeting regulatory requirements

Security initiatives will help you implement:

• Core governance processes
• Security for behavioral change
• Enhanced core security
• Plans for ongoing improvements

All of the above processes can help strengthen a security initiative.

 

Critical Security Services and Processes

As a security program matures, Nick emphasized the role of critical processes such as:

• Oversight of documentation and security operations to ensure effective risk management
• Ownership of security processes by security and risk management leaders 
• Ongoing monitoring and communication of security program effectiveness to stakeholders 

However, these processes vary by organization and must be tailored to specific security program requirements.

 

Questions for Panelists

Following the presentations, Aileen opened the floor to questions for the panelists, grouped into themed sections below. 

 

Gap Remediation Tools

When asked about common intrusion detection software, Drent mentioned the availability of various types, depending on organization-specific needs. It all comes down to cost-effectiveness and risk management. 

Nick added that managed services help address gaps, especially for cloud-based applications. Organizations must consider their security staffing needs and mission-specific objectives. RSI Security can help staff, augment, or recommend partners to help organizations address their risk management needs.

 

SOC Reporting for Small and Large Businesses

A question came up asking how to deal with SOC 2 reports from vendors. Drent explained that a SOC 2 report never expires, as it lasts for the period defined in the report. Therefore, although completed SOC 2 reports cover past performance, they do not always indicate the future performance of the vendor in question.

However, he added that organizations must look out for:

• Timing of report completion – Reports must not be older than 13 to 14 months. 
• Consistency of completion – Unlike less consistently completed SOC 2 reports, SOC 1 reports are submitted within the last calendar year quarter.
• Testing period – Although larger service organizations conduct audits every six months, the ideal audit period is three months from testing.

When asked about alternatives for SOC reporting for smaller businesses, Drent suggested that these businesses can address some specific controls. However, it depends on:

• Number of customers – It is easier to demonstrate the security of controls with multiple customers compared to a single customer.
• Type of test –  Some tests can provide security assurance (e.g., pen-testing). 

Kyle agreed by emphasizing the role of size in determining alternatives for SOC 2 audits. Even small organizations must conduct SOC audits. However, he added that SOC 2 audits are less costly for smaller organizations, but not always.

 

Scope and Requirements of SOC Audits

Questions were asked about requirements for SOC audits, including:

• Whether organizations can use detailed audit checklists
• Core requirements for SOC 2 compliance
• SOC audit requirements for privately-held companies

The panelists provided insight on the above topics as follows:

• Use of TSC criteria for audit – Organizations can use TSC criteria to address risks to controls. Specifically: 
  • Drent explained that SOC 2 audits are not examinations and do not require a checklist. 
  • He added that TSC criteria should drive auditing of control design and performance.
  • Kyle agreed that TSC criteria will help organizations define business risks.
  • He also added that security requirements act as TSC categories, especially the Common Criteria.
• The basis for SOC 2 reporting – Customer and risk management needs drive SOC 2 audits. Specifically:
  • Drent emphasized that SOC reporting is customer-driven and is not currently subject to regulatory requirements.
  • Regardless of organization size, SOC reporting will depend on risk requirements and customer needs.
  • Nick also pointed out the need for organizations to conduct SOC 2 audits based on the value provided to customers (e.g., data quality, availability).
  • Service value should be mapped to cost, risk, and revenue management.
• Scope of SOC audits – Defining the scope of SOC audits depends on organization-specific services. Specifically:
  • Drent closed by saying the scope of SOC audits is based on the types of services provided (e.g., hosting, power cooling, or SaaS provision)
  • Kyle added that contractual commitments (e.g., uptime, security) also define scope, especially if not explicitly stated in contracts.

One question also came up about how service organizations can engage with their entities. Drent mentioned the commonality of such scenarios, especially for larger organizations that run data centers. 

Typically, such organizations will conduct isolated audits for SOC 1 Type 2 or SOC 2 Type 2 or both, referencing the underlying data center or MSSP SOC 2 or SOC 1 that they conducted on a separate service. He emphasized that organizations should not leave any components uncovered by a SOC report.

 

SOC 2 Auditing and Compliance

Regardless of your organization size or business needs, RSI Security will help you address aspects of SOC 2 reporting, auditing, overall compliance. RSI Security provides tailored SOC 2 advisory services to help you meet your compliance needs.

Contact RSI Security today to learn more and get started on your SOC 2 audit!