SOC 2 on AWS: using AWS's SOC reports and shared responsibility

Some controls sit entirely with AWS because they protect the physical facilities and infrastructure that run its services. For a SOC 2, you usually do not implement these controls yourself. You document that you rely on them and obtain AWS's report as evidence that they operated during the period. The inherited set is narrow, so do not assume a control is inherited because it sounds like a facilities concern.

• Physical and environmental controls: AWS lists these as fully inherited by customers, covering data center access, power, cooling and fire protection.
• Reliance statement: Record in your control matrix that the control is performed by AWS and reference the SOC report and period you reviewed.
• Report currency: Note which report period covers your audit window, and where a gap exists, use the bridge letter in AWS Artifact to cover the time after that period.
• Auditor expectations: Your auditor will want to see that you reviewed AWS's report, identified the relevant controls, and considered any exceptions it contains.
• Service scope: Confirm on the Services in Scope page that the services you use appear in the SOC report.

Before you rely on inherited controls, check the Services in Scope page and confirm that every service in your architecture is covered by the report you review.

Shared controls are implemented by both AWS and the customer, with each party responsible for its own scope. AWS handles the platform layer, and you handle the configuration and operation of the workloads you run. Your control matrix should state precisely where AWS's responsibility ends and yours begins, because auditors will test your part independently of AWS's report.

• Patch management: AWS patches its infrastructure, while you patch the operating systems, runtimes and applications on the instances or containers you run.
• Configuration management: AWS configures its managed services, while you define the configuration of your accounts, networks and workloads.
• Awareness and training: AWS trains its own staff, and your personnel need separate training and records under your own program.
• Evidence split: Keep your own records of patch cycles, configuration baselines and training completion, rather than pointing the auditor to AWS's documents.
• Service variation: The split changes by service, so check the responsibility for each managed service you use.

For each shared control, confirm which party performs which step and check that your own evidence covers your share in full.

Some controls belong entirely to you because they relate to your accounts, configurations, data and access decisions. AWS's model places zone security and the security of what you build in the cloud with you. On Amazon EC2, for example, you manage the guest operating system, its patches, the applications you install and the security group configuration. These controls appear in your system description and must be tested in your examination.

• Zone security: Your network zones, segmentation and access paths are configured by you and must be described in your system.
• Guest operating system and patches: On EC2 you own OS hardening, patch timing and vulnerability remediation.
• Installed applications: Software you deploy, including its authentication and logging settings, is entirely in your scope.
• Security groups: You define inbound and outbound rules, and reviewing them is your evidence to produce.
• Service-specific duties: Managed services shift some of these duties to AWS, so confirm each one against the Services in Scope page and the shared responsibility documentation.

Review this tab's controls first when planning your examination, because they generate the most evidence requests and carry the most exception risk.

Your organization owns the service, the controls and the conclusions drawn from them. Management decides which trust services criteria apply, writes the policies that govern AWS use, approves access and changes, and signs the management assertion and representation letter that the auditor relies on. Management also prepares the system description, which must explain the AWS services in use, the boundary of the system and which controls AWS performs for you. None of these duties can be handed to a partner or an auditor, because the report describes your system as your management represents it.

• Control ownership: Named owners for each control in the matrix, including who reviews IAM access, CloudTrail logs and change approvals in your AWS accounts.
• Policies and sign-off: Approval of the information security policy, access and change procedures, and the exceptions process for AWS-dependent controls.
• System description: Management's description of the AWS services, regions, accounts and subservice organizations, and the carve-out or inclusive treatment of AWS.
• Complementary controls: Any complementary user entity controls that your customers must rely on, documented and communicated.
• Representations: Management's assertion and representation letter, signed by the people who can speak for the control environment.

Before engaging anyone, confirm that a named executive can own the system description and sign the representations.

An implementation partner such as DeployOpen can prepare the AWS environment, controls, evidence collection and documentation under a written scope. Work of this kind typically covers account structure, identity and logging configuration, evidence collection routines and the documentation that the auditor will request. The partner prepares; the organization decides what is accepted into the control environment. The partner does not test controls for the report, does not decide which controls are sufficient, and does not issue any report, attestation or certificate.

• Account and identity preparation: Configuration of AWS accounts, IAM roles, MFA and logging so that the controls exist and can be evidenced.
• Evidence routines: Scripted or scheduled collection of configuration snapshots, access reviews and change records, stored where the auditor can sample them.
• Documentation: Drafts of control descriptions and runbooks that management reviews and adopts as its own.
• Carve-out support: Gathering AWS Artifact reports and bridge letters, and organizing them for the carve-out analysis your team owns.
• Written scope: Deliverables, boundaries and timelines agreed in writing before work begins, with any exclusions stated.

Ask whether the partner will also act as the auditor or perform any testing of its own work. Under an independent model, the answer should be no.

The independent CPA firm performs the SOC 2 examination under the AICPA attestation standards. It obtains written representations from management, tests the design of controls and, for a Type 2 report, their operating effectiveness over the period. The auditor selects samples, reviews evidence directly and reports exceptions. Its opinion is the only SOC 2 report that a customer can rely on. Under the AWS model, the auditor also decides how to treat AWS: whether to carve out the AWS controls and rely on AWS's report, or to include them under an inclusive approach.

• Independence: The firm must be independent of the organization and of the partner that prepared the environment, so the same party cannot both build and attest.
• Testing: Sampling of access, change and logging controls, with evidence drawn from your systems rather than from the partner's summaries.
• Carve-out evaluation: Review of AWS's report, bridge letter and the complementary controls that your organization must operate.
• Report issuance: The only party that issues the SOC 2 report and any exceptions or qualified opinion.
• Engagement letter: Scope, timing, fees and responsibilities agreed directly with the organization.

Confirm the firm's independence from your preparation work in writing before fieldwork starts.