At RADAR, we understand how critical it is to keep sensitive information secure. Our clients use RADAR to manage privacy incidents involving Personally Identifiable Information (PII) and Protected Health Information (PHI), and we support this work by following best practices and industry standards for application, network, and infrastructure security.
Next week at the IAPP Privacy. Security. Risk. conference, I will be on a panel discussing the topic of certifications contributing my experience pursuing RADAR’s SOC2 Type II + HITRUST report.
This topic featured at IAPP Privacy. Security. Risk. 2017 Session:
Certification: How We Got There and What We’ve Learned
As part of my preparation for this session, I decided to pull together some thoughts on what a SOC 2 Type II audit entails, sort out the alphabet soup of terms, provide some historical context, and summarize some suggested best practices on navigating the process.
Definitions
SSAE 16 and 18: Statements on Standards for Attestation Engagements (SSAE) framework goes beyond the older SAS 70 framework by requiring a written assertion regarding the design and operating effectiveness of the controls being reviewed. The SSAE 18 standard replaces SSAE 16 for SOC 1 engagements.
SOC 1: A report generated from a SSAE 16 or 18 audit focusing on internal controls over financial reporting. SOC 1 reports have replaced the former SAS 70 reports.
SOC 2: A report generated from SSAE 16 or 18 audit that focuses on a business’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system.
SOC 3: An abstract of a SOC 2 report without any sensitive information so that it can be public facing and suitable for marketing purposes.
HITRUST: Another security framework that has established a Common Security Framework (CSF) to be used by any organization that handles or processes sensitive or regulated data. The CSF includes a set of controls that attempt to normalize the requirements from multiple regulations and standards. There is a mapping of SOC 2 Trust Services Principles to the CSF.
History
The American Institute of CPAs (AICPA) designed the Service Organization Controls Report 2 (SOC 2) specifically for service providers like RADAR who store customer data securely in the cloud. Before the SOC 2 report there really wasn’t anything for service providers.
SAS 70 was the original standard used by service organizations to demonstrate the effectiveness of internal controls for keeping data secure. This audit process was conducted by a CPA to produce a report on the effectiveness of internal control over financial reporting. It is an old standard that was never designed for more modern cloud based service organizations and was eventually replaced by SSAE 16 (and more recently SSAE 18 as of May 1, 2017).
The SSAE standards extends the foundation established by SAS 70 by not only verifying controls and processes, but also requiring a written assertion regarding the design and operating effectiveness of the controls being reviewed, ultimately resulting in a SOC report.
Given there was no well established audit process for service providers originally, companies used the SAS 70 report to provide at least some proof that sensitive/regulated data was securely and safely handled. When the SOC 1 report replaced SAS 70 based reports, the SOC 2 was also introduced as a report to better address the specific auditing needs of service providers.
What is SOC 2?
SOC 2 is a report resulting from a technical audit performed by an independent third party auditor that goes beyond just security policies and procedures by defining criteria known as the Trust Services Principles, which in turn are based on four broad areas: policies, communications, procedures, and monitoring. The AICPA has defined these principles as:
- Security – System is protected against unauthorized access.
- Availability – System is available for operation and use as committed or agreed
- Processing integrity – System processing is complete, valid, accurate, timely, and authorized.
- Confidentiality – Information designated as confidential is protected as committed or agreed.
- Privacy – Personal information is collected, used, retained, disclosed and destroyed in accordance with the privacy notice commitments.
Each of the principles have defined criteria that get mapped to your controls and which must be met to both demonstrate adherence to the principles and to produce an unqualified opinion by the auditor. If deviations i.e. exceptions are found, these are documented—interestingly this is not part of the HITRUST framework.
Just like SOC 1, SOC 2 reports come in two forms. Type I reports concern policies and procedures operational at a specific moment in time. Type II reports, on the other hand, audit policies and procedures over a period of at least six months. A Type II report also includes a description of the service auditor’s tests of the operating effectiveness and the results of those tests. This generally makes SOC 2 Type II reports more comprehensive and useful than Type I reports when considering a possible service provider’s credentials.
Navigating the SOC 2 process
Preparation
If your company has not undergone an audit for a security framework before, you will need to prepare. Explore the AICPA website for examples and resources and search the NIST and SANs websites for policy templates if you are starting from scratch. I highly recommend talking to your peers at other companies to get informed on what experiences they had, problems they encountered, and what to expect in general.
This is also a good time to get some recommendations for an independent and qualified third party CPA firm to perform the audit. If you need to be audited against the HITRUST CSF (based on what your customers or prospective customers demand) you will need to make sure the CPA firm is an authorized HITRUST assessor. Reputation is very important, since the auditor will attest to the findings and make an informed opinion on the suitability of the design and operating effectiveness of the controls. This means you should also determine their methodology and what experience they have before selecting them as your auditor.
Make sure you find experienced CPA firms with a track record who perform over 50 or more SOC reports annually. Also consider what your existing customers and future prospects will require. Many companies will not deem your report acceptable if it was performed by a firm that is not well known and reputable.
Find the holes
Once you have engaged a CPA firm, the real work begins to map your existing corporate controls to the SSAE framework and to identify any gaps. Do not underestimate the time it may take to create and implement missing or incomplete policies. I would recommend planning for 2 months to identify the gaps and create action items, and another 4-6 months to fill those gaps. You may find in your first year you will have a few exceptions and your company will have to communicate an action plan to address these shortcomings.
Make a calendar
If you do not already have one, make an operational security SOC 2 calendar to ensure you are performing all of the many tasks needed to generate the required evidence for an audit.
Use Infrastructure as Code (IaC) and automate
Automation is your friend. Do not do things in an one-off manner, especially when it comes to IT infrastructure. Use declarative forms for defining your Virtual Private Cloud, instances, firewalls, and hardening so that you can use version control and a change management process for accountability and auditing.
Build on a strong foundation
Use Amazon Web Services (AWS) or Microsoft Azure to build your system. These high-end cloud providers have already been audited against multiple security frameworks and are thus highly secure with expert supervision of physical, network, and server security. This kind of focus and expertise is very difficult to replicate by your company’s own IT or data center offering.
Summary
Many companies need to be accredited on one or more security frameworks in order to conduct business with companies providing sensitive or regulated data. Any company storing sensitive or regulated customer data in the cloud should strongly consider getting a SOC 2 Type II report in order to prove that their system is designed to keep its customers’ sensitive and regulated data secure. If you are dealing with healthcare companies you will likely need a SOC 2 Type II + HITRUST CSF report. If you are processing credit card information or working with the federal government, you will need to acquire other accreditations.
Obtaining a SOC 2 report can help differentiate your organization from its peers by demonstrating effective governance and oversight. This allows customers, partners and prospects to gain confidence and trust in your system and company. Not having such accreditation means that you may lose business to competitors who do.
Related reading: