Open Mobile Menu

Blog

Using Service Organization Controls (SOC®) to Meet Supply Chain Security Requirements

Views: 2015

Written By: Brian Bertacini August 09, 2016

In today’s world, information systems are under constant assault from a variety of threat actors leveraging multiple attack vectors.  More and more enterprise data security breaches are being attributed to the exploitation of weaknesses and vulnerabilities within the supply chain. 

As a result of these high-profile compromises, larger enterprises and savvy security-minded organizations are mandating and enforcing stricter and more rigorous supplier risk management programs in an effort to mitigate enterprise and supply chain risk. 

Suppliers and service providers are feeling the heat.  They’re seeing more and more friction during the sales cycle, and almost every business transaction is subject to some form of a supplier risk assessment questionnaire and/or audit.  It’s become increasing common for master agreements and contract language to include a number of security requirements as a condition of doing business. 

I often speak with service providers facing this very challenge.  They want to provide their solutions and services to the marketplace, but often have a difficult time demonstrating their security posture and meeting the diverse set of requirements being put forth by their customers.  Most of these firms are startups and midsized businesses where time-to-market pressures or revenue generating projects are a bigger priority than establishing a mature security program.  Then suddenly, a new client opportunity requires the service provider to comply with rigorous supplier risk management mandates in order to close a deal; we see service providers losing business when they have no way to respond to these outside requests.   

So what’s a service provider to do? 

A growing number of organizations are building security programs around the Service Organization Controls (SOC) framework.  SOC is based on auditing standards published by the American Institute of Certified Public Accountants (AICPA) and is intended to be an auditor-to-auditor report providing an independent opinion of an organization’s security and privacy controls. 

There are multiple benefits for a service provider leveraging the SOC report; it provides a consistent framework based on industry standards, is broadly accepted in the marketplace, it can streamline the supplier onboarding process, and demonstrates an organization’s commitment to best practices.   In most cases, we see our customers save a great deal of money and reduce effort by virtue of having a SOC report, as they now have a mechanism to respond to a variety of third party requests that previously would have required individual responses.  In many cases, not having a SOC is a deal breaker; some organizations chose not to incur the risk of working with an organization who does not meet a minimum set of security controls.

So what is a SOC?

There are three different forms of SOC reports; SOC 1, SOC 2 and SOC 3.  Additionally, there are two types of reports; a Type I report that is based on the suitability of controls for in-scope systems/services and a Type II that is based on the operational effectiveness of those same controls over a period of time (typically 6 months).  Most organizations start with a Type I audit and report and then migrate to a Type II report as they mature their program and practices over time. 

What are the differences of these reports and how are they used?

A SOC 1 report is intended to be an independent review of the service provider’s controls for compliance with Sarbanes-Oxley (SOX) requirements (section 404) to demonstrate the suitability and effectiveness of internal controls covering financial reporting.  It can be applied to a variety of service providers employed in the delivery of financial reporting.  A SOC 1, Type I report is based on a point in time whereas a SOC 1, Type II is a report on the operational effectiveness of those controls over a period of time.  SOC 1 reports replace their earlier predecessor SAS70.       

For solutions or services that don’t have a primary financial component, a SOC 2 report is used to identify and validate the IT control infrastructure and supporting processes.  All SOC 2 reports include the Security Principle.  There are four other optional Trust Principles that can be included in a SOC 2 Audit; Confidentiality, Availability, Processing Integrity and Privacy. 

The SOC 3 is an executive summary of the SOC 2 report and is intended to be freely distributed (this is typically used more as a marketing tool to summarize an organization’s SOC status). 

The SOC 2, which is the most common, focuses on 5 Trust Services.  Trust Services are a set of professional attestation and advisory services based on a core set of principles and criteria that address the risks and opportunities of IT-enabled systems and privacy programs. The following principles and related criteria are used by practitioners in the performance of Trust Services engagements:

  1. Security. The system is protected against unauthorized access.
  2. Availability. The system is available for operation and use as committed or agreed.
  3. Processing integrity. System processing is complete, valid, accurate, timely, and authorized.
  4. Confidentiality. Information designated as confidential is protected as committed or agreed.
  5. Privacy. Personal information is collected, used, retained, disclosed and destroyed in conformity with the commitments in the entity’s privacy notice and with criteria set forth in Generally Accepted Privacy Principles issued by the AICPA and CICA. [1]

The control framework outlined above helps provide prospective and existing clients with a functional understanding of security controls and implemented and practiced by the service provider.  It’s not uncommon for the organization reviewing the audit report to have follow-up questions to ensure their security goals and objectives are being met; this process gives the service provider a mechanism to solicit feedback from current and potential customers and provides an opportunity to refine the scope of subsequent audits.  Service providers who are engaged in business overseas should consider ISO27001 in lieu of, or in addition to SOC 2.  ISO27001 is based on International standards whereas SOC 2 is based on US-based AICPA auditing standards; the ISO Standard is widely accepted in overseas markets, where the SOC 1/2/3 has gained a great deal of traction and is widely accepted in the US.  AppSec Consulting will produce a future blog article on the value of ISO27001 Certification. 

It should be noted that AppSec Consulting is not a CPA/Audit firm, and does not develop the final report (this is to ensure that independence is maintained between the preparation and audit functions); our role is to help our clients with all preparation and readiness activities, and make sure that they understand and integrate the SOC framework in a manner that will satisfy an external auditor. It’s important to consider the reputation and capabilities of the advisory and Auditing firms preparing you for and conducting the SOC Audit; firms with higher standards will produce reports that carry more weight than firms known to be “checkbox shops”. 

Before moving forward with a SOC engagement, it’s important to understand your customer’s requirements.  This report is going to be a useful tool for your clients so it’s critical to understand what they need to see.  Talk to your clients; understand what they want and need to see.  It’s highly likely future prospects will want to see the same information from their service providers. 

AppSec Consulting has been in business for over 11 years, and has been a trusted partner to both Fortune 100 firms and smaller startups as they go through the SOC process.  Our company believes in listening closely to our clients’ needs, and helping them build programs and processes that make them safer while enabling them to expand their core business. 

If you have any questions regarding SOC or similar services feel free to reach out to AppSec Consulting.  We’ll put you in touch with a subject matter expert who can provide practical advice and help you determine the best approach for your organization. 

 

[1] AICPA – Trust Services and Information Integrity

Brian Bertacini

Brian Bertacini founded AppSec Consulting in 2005, since then the company has become a leading provider of IT security testing services, PCI assessment and validation, training and security technology integration for businesses of all sizes including starts-up and large global enterprise clients. Mr. Bertacini is a member of ISSA, ISACA, and OWASP. He has more than 20 years experience in software development, systems engineering and information security, fulfilling various roles at IBM, Varian and Fujitsu. Brian is the founding member of the Silicon Valley OWASP chapter and he oversees the management of AppSec Consulting to ensure the company's valued clients receive the highest quality of service.

read more articles by Brian Bertacini