SOC on Amazon Web Services (AWS) What You Need To Know Understanding the regulatory roadmap for SOC on AWS

Transcription

1 SOC on Amazon Web Services (AWS) What You Need To Know Understanding the regulatory roadmap for SOC on AWS Jeff Cook November 2015 Summary Service Organization Control (SOC) reports (formerly SAS 70 or SSAE 16) are designed to help service organizations that operate information systems (and provide information system services to other entities) build trust and confidence in their service delivery processes and controls through a report by an independent Certified Public Accountant (CPA). Each type of SOC report is designed to help service organizations meet specific user needs. If you are leveraging Amazon Web Services (AWS) as a platform for your cloud offering (SaaS/PaaS), this FAQ will help you: Understand the value of SOC reporting Understand what AWS SOC validations can be leveraged Understand how your SOC audit would be affected by leveraging AWS What You Need To Know for SOC Audits Question Who does SOC apply to? Answer There are various roles in relation to SOC. Here are the common terms you will hear: Service Organization an entity that possesses, stores, or handles information or transactions on behalf of its customers (user entities) User Entity the company that outsources its information or business processes to a service organization Service Auditor a CPA firm that reports on the controls of a service organization User Auditor a CPA firm that audits a user entity that uses the service organization 1

2 Question What are the different SOC reports? Answer There are 3 different versions of SOC reports. SOC 1 (formerly SSAE 16), SOC 2, and SOC 3. Each report serves a different purpose, which is summarized below: Report type Intended Users of the Report Business Need What SOC 1 Management of the service organization User entities User auditors Audit of the financial statements of user entities Controls relevant to user entity financial reporting (e.g., payroll processing) SOC 2 Management of the service organization User entities User auditors Regulators Other SOC 3 Any users with need for confidence in the security, availability, processing integrity, confidentiality, or privacy of a service organization s system Audit of the financial statements of user entities Meeting governance, risk, and compliance programs Oversight Due diligence Marketing purposes General public information Detail not needed Controls relevant to a service organization system s security, availability, processing integrity, confidentiality, or privacy Seal and report on controls 2

3 Question As a Cloud Service Provider (CSP), how do I know which SOC report is right for me? Answer The AICPA (2015) summarized the need for SOC reports in the following table: HOW TO IDENTIFY THE RIGHT SOC REPORT FOR MY ORGANIZATION? Will the report be used by your customers and their auditors to plan and perform an audit or integrated audit of your customer s financial statements? Yes SOC 1 Report Will the report be used by your customers as part of their compliance with the Sarbanes-Oxley Act or similar law or regulation? Yes SOC 1 Report Will the report be used by your customers or stakeholders to gain confidence and place trust in your organization s systems or fulfill contractual obligations? Yes SOC 2 or 3 Report Do you need to make the report generally available or seal? Yes SOC 3 Report Do your customers have the need for and ability to understand the details of the processing and controls at a service organization, the tests performed by the service auditor and results of those tests? Yes No SOC 2 Report SOC 3 Report Question What is the difference between a Type 1 and Type 2 report? Answer A type 1 report focuses on the description of a service organization s system, related control objectives, and the suitability of controls to achieve those objectives as of a specified point in time. A type 2 report contains the same information as a type 1 report with the addition of an assessment of the operating effectiveness of the controls to achieve the control objectives included in the description throughout a specified period of time. A type 2 report also includes a detailed description of the service auditor s tests of controls and results over that period of time. Question What are the trust principles for SOC 2 and 3? Answer Trust services are a set of services based on a core set of criteria that address the risks and opportunities of IT-enabled systems and/or privacy programs. A service organization can choose to report on any of the trust principles for a SOC 2 engagement. 3

4 The following criteria are used in SOC 2 and 3 trust services engagements: Security - The system is protected against unauthorized access (both physical and logical). Availability - The system is available for operation and use as committed or agreed. Processing Integrity - System processing is complete, 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 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 (Chartered Accountants of Canada). What You Need To Know for SOC and AWS Question What SOC reports has AWS performed and what do they do? Answer There are three types of AWS SOC reports (all are 6 month reports 10/1-3/31 and 4/1-9/30): AWS SOC 1: A description of the AWS control environment and external audit of AWS defined controls and objectives o Focuses on AWS's processes and controls relevant to their customers financial reporting. Many AWS customers use the AWS SOC 1 as a part of their Sarbanes-Oxley efforts and other security and compliance initiatives where key controls operated by AWS are evaluated and validated. o Attests that the AWS control objectives are appropriately designed and the controls safeguarding customer data are operating effectively. The AWS SOC 1 report includes AWS data centers in US East (Northern Virginia), US West (Oregon), US West (Northern California), AWS GovCloud (US) (Oregon), EU (Dublin), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and South America (Sao Paulo) that support in-scope services. These regions include AWS edge regions, of which more detail can be found here: o Purpose is to provide information to customers and their auditors about AWS' control environment that may be relevant to their internal controls over financial reporting and their assessment and opinion of the effectiveness of those controls. 4

5 o AWS Partner Consideration: The AWS SOC 1 report potentially serves your organization for the determination of AWS as a subservice organization related to your system, and also how your company monitors the controls of AWS as a subservice organization (see below for further discussion of subservice organizations). AWS SOC 2: Security and Availability Principles o This report is leveraged by a wide range of AWS customers, including but not limited to customers in the technology, healthcare, banking, and financial services industries. This report is leveraged to meet a wide range of security control and compliance requirements based on the AICPA s mature industry control criteria. o An evaluation of the design and operating effectiveness of controls that meet the criteria for the security and availability principles. This report provides additional transparency into AWS security and availability based on a defined industry standard and further demonstrates AWS commitment to protecting customer data. The AWS SOC 2 report includes AWS data centers in US East (Northern Virginia), US West (Oregon), US West (Northern California), AWS GovCloud (US) (Oregon), EU (Dublin), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and South America (Sao Paulo) that support in-scope services. These regions include AWS edge regions, of which more detail can be found here: o The purpose is to provide customers and users with a business need with an independent assessment of AWS' control environment relevant to system security. o AWS Partner Consideration: The AWS SOC 2 report potentially serves your organization for the determination of AWS as a subservice organization related to your system, and also how your company monitors the controls of AWS as a subservice organization (see below for further discussion of subservice organizations). AWS SOC 3: Security and Availability Principles (the AWS SOC 3 report is publically available here: df) o A summarized version of the SOC 2 report and enables you to validate that AWS has completed a favorable independent audit against the AICPA s Security Trust Principles. 5

6 o The report includes the external auditor's opinion of the operation of controls (based on the Trust Principles included in the SOC 2 report), the assertion from AWS management regarding the effectiveness of controls, and an overview of AWS Infrastructure and Services. The AWS SOC 3 report includes AWS data centers in US East (Northern Virginia), US West (Oregon), US West (Northern California), AWS GovCloud (US) (Oregon), EU (Dublin), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and South America (Sao Paulo) that support in-scope services. These regions include AWS edge regions, of which more detail can be found here: This is a great resource for customers to validate that AWS has obtained external auditor assurance without going through the process to request a SOC 2 report. o The purpose is to provide customers and users with a business need with an independent assessment of AWS' control environment relevant to system security without disclosing AWS internal information. o AWS Partner Consideration: The AWS SOC 3 report potentially serves your organization for the determination of AWS as a subservice organization related to your system, however more detail would be needed (a SOC 2 report) in order to monitor the controls of AWS as a subservice organization (see below for further discussion of subservice organizations). 6

7 Question What AWS services are in scope for the SOC reports? Answer AWS Cloud Formation AWS Cloud HSM AWS CloudTrail AWS Direct Connect Amazon DynamoDB Amazon EC2 VM Import/Export Amazon Elastic Amazon Elastic Block Amazon ElastiCache Beanstalk Store (EBS) Amazon Elastic Compute Cloud (EC2) Amazon Elastic Load Balancing (ELB) Amazon Elastic MapReduce (EMR) Amazon Glacier AWS Identity and Access Management (IAM) AWS Key Management Service (KMS) Amazon Redshift Amazon Relational Amazon Route 53 Database Service (RDS) Amazon SimpleDB Amazon Simple Service (SES) Amazon Storage Service (S3) Amazon Simple Amazon Simple Queue AWS Storage Gateway Workflow (SWF) Amazon Virtual Private Cloud (VPC) Service (SQS) Amazon WorkSpaces As always, AWS moves quickly in service additions so check in with your AWS account representative periodically to ensure what are the latest services under these SOC boundary validations. Question How do I request a AWS SOC 1 or 2 report? Answer You can request an AWS SOC 1 or SOC 2 Report through your Business Development representative. Don t have one? You can request one here. 7

8 Question Why do the AWS SOC 2 and SOC 3 reports only include the trust principles of security and availability? Answer Because the nature of AWS services is to provide its customers a virtualized platform to use for their services, the most critical principles as they relate to AWS customers would be the security of the AWS environment and to make sure that the AWS environment is available for use. AWS in these situations is not processing your organization (or user entity data), therefore the other trust principles are excluded. AWS Partner Consideration: The determination of what trust principles your organization is to report on should be based on the needs of your customers and what they would want to know about your system. Using the AWS platform will provide some insight as to the use of a subservice organization (discussed below) for your system, but ultimately, your consideration of the appropriate trust principles for your report should be independent of what AWS reports on. Question Does that mean I don t need to perform any work for the principles of security and availability? Answer NO! Your organization would still need to have a description of the system and related controls for security and availability at your level as it relates to the needs of your user entities (customers). If your organization is processing data, you may also have to include the principles of processing integrity and confidentiality (and if you handle PII, privacy). The controls related to those trust principles would also have to be tested in the case of a type 2 report. 8

9 Question - What control objectives does the AWS SOC 1 provide? Answer The report itself identifies the control activities that support each of these objectives and the independent auditor s results of their testing procedures of each control. Security Organization Amazon User Access Logical Security Secure Data Handling Physical Security and Environmental Safeguards Change Management Data Integrity, Availability and Redundancy Incident Handling Controls provide reasonable assurance that information security policies have been implemented and communicated throughout the organization. Controls provide reasonable assurance that procedures have been established so that Amazon user accounts are added, modified and deleted in a timely manner and are reviewed on a periodic basis. Controls provide reasonable assurance that unauthorized internal and external access to data is appropriately restricted and access to customer data is appropriately segregated from other customers. Controls provide reasonable assurance that data handling between the customer s point of initiation to an AWS storage location is secured and mapped accurately. Controls provide reasonable assurance that physical access to Amazon s operations building and the data centers is restricted to authorized personnel and that procedures exist to minimize the effect of a malfunction or physical disaster to the computer and data center facilities. Controls provide reasonable assurance that changes (including emergency / non-routine and configuration) to existing IT resources are logged, authorized, tested, approved and documented. Controls provide reasonable assurance that data integrity is maintained through all phases including transmission, storage and processing. Controls provide reasonable assurance that system incidents are recorded, analyzed, and resolved. 9

10 Question If we are leveraging AWS, what considerations do I have for my SOC audit? Answer If you are using AWS services, you would have to follow the guidance from the AICPA for the consideration of subservice organizations. Per the AICPA, a vendor (AWS) is considered a sub-service organization only if: the services provided by the vendor are likely to be relevant to the user s understanding of the service organization s system as it relates to the principle included in the scope of the engagement, and the service organization is relying on controls at the subservice organization to meet one or more of the applicable trust services criteria. For example, if AWS is responsible for monitoring server capacity and usage and projecting future capacity demands based on historical trends, the controls at AWS may be needed for your organization to meet its availability commitments and, consequently, the applicable trust services criteria for the availability principle. However, controls at AWS may not be needed if your organization independently performs high-level capacity monitoring and reviews the future capacity demands projected by AWS for appropriateness. In some instances, a service organization may stipulate in its contract with a vendor that the vendor perform certain controls that the service organization believes are necessary to address the risks related to the vendor s services. When a service organization has determined that its controls alone meet the applicable trust services criteria or that its monitoring of the vendor s services is sufficient to meet the applicable trust services criteria, the service auditor evaluates the suitability of the design of the service organization s controls over the services provided by the vendor in meeting the applicable trust services criteria and in a type 2 report tests the operating effectiveness of those controls or the monitoring performed by the service organization. 10

11 Question - We ve determined that AWS is a subservice organization relevant to our SOC report, now what? Answer If AWS is a subservice organization, you will have to determine if the carve-out or inclusive method of reporting will be performed for your description of your system. Carve-out Method: When the carve-out method is used, your description of your organization s system identifies the nature of the services and functions performed by the subservice organization (AWS) and the types of controls that you expect to be implemented at AWS but excludes details of the AWS system and controls. Your description does not include the detailed processing or controls at AWS. Your description prepared using the carve-out method generally is most useful if the services provided by you are not extensive or if a type 1 or type 2 report that meets the needs of user entities is available from AWS. Inclusive Method: When the inclusive method is used, your description of the AWS system includes a description of the nature of the services and functions performed by AWS, as well the applicable trust services criteria and controls implemented by AWS. Your controls are presented separately from those of AWS. Although the inclusive method provides more information for user entities, it may not be appropriate or feasible in all circumstances. In determining which approach to use, you should consider (a) the nature and extent of the information about AWS that user entities may need and (b) the practical difficulties entailed in implementing the inclusive method. The inclusive method is difficult to implement in certain circumstances because the approach entails extensive planning and communication among the service auditor, your service organization, and AWS. With Either Method: Regardless of which method is used, your description should include controls at your organization that monitor the services provided by AWS. Examples of monitoring controls include testing performed by your internal audit function at AWS, reviewing output reports, holding periodic discussions with AWS, making site visits to AWS, and reviewing reports on AWS system (SOC reports). 11

12 Question - What other considerations are there for CSPs using AWS infrastructure? Answer Considerable judgment is necessary to identify the boundaries of the system based on the services provided by AWS. In the cloud environment, concerns arise from the dynamic nature of the architecture itself. The ability of your offering to rapidly expand, through the use of subservice organizations or contract, by decommissioning virtualized components, may present you with unique challenges. In evaluating the boundaries of the system, you should begin by considering the broadest boundaries of the system. These broad boundaries may encompass multiple subservice organizations or the subservice organizations of AWS. If the boundaries of your system are defined too narrowly, you have to consider whether your report will be meaningful and useful to user entities. Due to the complexity of cloud services, the challenge of defining the boundaries of your system often goes beyond the usual considerations in a SOC 2 engagement. You also have to understand the architecture involved. The risks to you include failure to identify all the third parties that have potential access to client data or subservice organizations that share responsibility for implementing controls necessary to achieve the applicable trust services criteria. A SaaS provider, for example, may itself use services from an IaaS, which may sometimes outsource its overflow to a subservice organization. These multiple levels of providers would be a particular concern if, for example, you are contractually or otherwise bound to limit access to protected information to a contractually identified group of personnel. Other Information for SOC Question Who can perform SOC audits? Answer SOC engagements were developed by the CPA profession, which has long been a thought leader in assurance engagements. CPAs are the premier providers of SOC reports for service organizations that must reassure users about their systems. As provided from the AICPA, here are some reasons why you would choose a CPA as a trusted provider of SOC reports: 12

13 Question Are there independence considerations for firms providing SOC support? Answer Yes, independence is required by the AICPA Code of Professional Conduct for examination engagements. The AICPA has also issued a plain English guide to independence found here: uments/plain%20english%20guide.pdf While there are other considerations for independence listed in the guide, the largest requirement affecting SOC is the assumption of management responsibilities. An attest (audit) client must agree to assume certain responsibilities related to nonattest services (advisory) provided in order for independence to be maintained (including management responsibilities, oversight, evaluation, and acceptance of responsibility for results). 13

14 Question - How long do most SOC audits take? Answer Most SOC Type 1 audits are fairly quick to turn around. Because the audit is performed at a point in time and only requires an audit opinion on the description and design of controls, a Type 1 audit can take usually 1 2 months (assuming all documentation, system descriptions, and controls are written and ready for audit). A SOC Type 2 audit will take longer, and is directly related to the audit period for the Type 2 report. For example, a 12 month Type 2 audit will take place primarily toward the end of the period, but there is testing that needs to be performed throughout the period (usually at certain points chosen by the auditor). The report itself can typically be expected within 1 2 months after the end of the period. Question - What is the best approach to determine SOC readiness/success? Answer As with many other IT assessments, a gap analysis would provide your organization with a high-level initial review of your system and related documentation in order to determine your readiness for a SOC audit. The results of a gap analysis performed by a qualified firm can provide you the strategic roadmap you need to get your organization ready for your audit with minimal exceptions in the report. For further information about the approach for SOC, see the following whitepaper: Question - My organization already has other IT assessments being performed (FISMA, FedRAMP, ISO, HIPAA, etc.) is there potential for re-use of that information? Answer Yes! SOC shares many common objectives with other IT assessments and there is potential for re-use of your policies/procedures and other control documentation to repurpose for SOC. A gap analysis (as discussed above) can help determine the amount of re-use you have, saving your organization time and money. 14

15 Navigating the complexities of cloud ecosystems can be a daunting task. Understanding the boundaries around what regulatory bodies are applicable, how and where they apply, and what preparation is needed to be successful are key elements of a successful SOC audit. If you have any questions and wish to speak further, feel free to send an inquiry and we can assist on how SOC and the AWS ecosystem come together. Jeff Cook Manager, Strategic Accounts jcook@verisgroup.com Veris Group, LLC