SOC Reporting Requirements

Security lapses in some of the world’s biggest companies continue to appear in news headlines, and information security is top of mind for businesses. Perhaps as a result, SOC reports are becoming a standard due diligence request before companies procure the services of vendors.

Over the years, the reporting framework has evolved from its original focus on financial reporting controls to include a suite of reporting options that cover cloud service provider security, cybersecurity risk management programs, and even a reporting vehicle to demonstrate compliance with other standards such as HIPAA, CSA, HITRUST, ISO, and others.

Thanks to the evolving usage of the reports, 2017 saw the American Institute of Certified Public Accountants rebrand SOC reports from Service Organization Control to System and Organization Control.

These reports are no longer just between the service provider and the user. They are instead becoming the 10K financial statement audit for cybersecurity programs. Although they were initially derived from AICPA auditing standards such as SAS 70 for service organizations, SOC reports can now come in these forms:

• SOC 1 is focused on internal control over financial reporting. These reports do not come with predefined criteria, but they typically focus on general IT controls and business transaction processing controls.

• SOC 2 is focused on a standard set of cybersecurity criteria, including security, and optional incremental criteria, including availability, confidentiality, processing integrity, and privacy.
• SOC 3 is a shortened version of SOC 2 that can be made available for public distribution because SOC 2 reports contain confidential details about an organization and further require the user to have knowledge of the system to effectively use the SOC 2 report.

• SOC for cybersecurity is focused on an entity-wide program or business unit in order to inform a broader range of stakeholders, from private equity and investors to the board and other internal management.
• SOC for vendor supply chains is under development.

The CPA firm that issues the SOC must adhere to AICPA and international assurance standards. But the beauty of SOC reports is that they are not a regulatory requirement. They’re market-driven reports that have grown organically as businesses around the world have collectively relied on them, and many companies have internally mandated them as part of their various risk management programs.

Reporting Requirements Revealed

There are a number of misconceptions about SOC reports, but the most common is that Service Providers like Azure, Amazon Web Services, and Google Cloud Platform are the ones responsible for reporting. Because cloud responsibilities are shared, there are three entities that must be considered: your company, critical vendors like IaaS cloud service providers, and whichever user entities are using the report.

All three play a part in an effective cybersecurity program, and the SOC report clarifies which controls and criteria each entity is responsible for. One of the most common SOC reports, SOC 2, leverages the Trust Services Criteria. This set of criteria is aligned to the 17 COSO internal control framework principles, but it can also used as a reporting framework to include several other common standards such as NIST CSF, ISO 27001, CSA, and others. The Trust Services Criteria are broken up into these categories:

1. Security: Security is focused on protecting the systems and data from unauthorized access. It consists of both governing and technical controls. First, governing controls like policies, procedures, risk assessment, and security functions are always the complete responsibility of your organization. Second, technical controls such as logical access, change management, operations, and security incident management might have shared responsibility between you and your vendor. For example, physical security would be the responsibility of AWS.

Have written policies and procedures, and identify best practices for the technology being used in your environment. Next, standardize the hardening of the operating system/database, network, and cloud infrastructure. CIS has excellent whitepapers on almost all technology platforms, including AWS, GCP, and Azure. Define a chief information security officer role (or its equivalent), and determine how security functions and roles are disseminated throughout the organization such as in devops and incident management.

2. Availability: Availability is focused on data backups, business continuity, and disaster recovery planning. This criterion is about making data and systems available when they’re needed.

Understand your service-level agreements around uptime and availability. SOC reports are based on commitments, not absolute requirements. For example, a bank with “five nines” (99.999 percent) uptime would be expected to have a more robust business continuity plan than a learning management system that has more tolerance for downtime. The cloud allows options to leverage multi-availability zones and redundancy. Test your BCP at least annually.

3. Confidentiality: Not surprisingly, the confidentiality criterion is focused on data encryption, retention, and disposal.

Understand your commitments to your customers. Confidential data is determined between you and your customer and can include various types of data. Give your customers control of their data in terms of when they can delete it. Know your procedures around the termination of contracts with your customers. How long is data preserved, and when can it be deleted? And how do you validate that data has been deleted in production and in all the backup systems?

4. Processing integrity: Because processing integrity is typically addressed in SOC 1 reports, it’s not commonly reported. Still, this criterion is focused on whether the data processed within the company is complete, accurate, timely, valid, and authorized.

5. Privacy: Privacy isn’t typically relevant in a CSP’s SOC report, as the collection and use of personally identifiable information is the responsibility of the CSP’s customer. However, more organizations are being asked to review certain privacy components as General Data Protection Regulation concerns loom.

Know your requirements. It’s a good idea to avoid collecting personally identifiable information if you don’t need it. But if you do, allow your customers to designate control over the types of PII that are managed and processed. As long as you can process system access requests, individual consumers can delete, access, view, or modify their data. Cloud platforms will also need to adopt programs that sanitize and de-identify data so it’s no longer directly associated with individual users.

Data protection measures aren’t always easy, but they’re in place for a reason. As regulations like the GDPR give control of data back to consumers, companies will need to ensure they’re meeting all regulatory and reporting requirements. By checking these boxes, you minimize your exposure to ever-present cybersecurity risks.

By Brad Thies