CCSP Cloud Audit: SOC 1, 2 and 3 Reports, SSAE, ISAE, Gap Analysis and Audit Planning

Internal audit is an assurance function inside the organisation that must be independent of the activities it reviews; external audit is performed by a party independent of the whole organisation, whose opinion outsiders can rely on. Both test controls, but they serve different audiences, and independence decides how much weight their conclusions carry.

Independence and the self-review threat

An auditor who reviews work they designed, built or operate faces a self-review threat: they tend to see their own controls as sound, and others discount their findings. That is why a cloud platform team cannot credibly audit its own controls, however expert it is, and why an internal audit function that reports to the executive whose areas it audits is compromised. The standard remedy is a functional reporting line to the audit committee, which controls the audit plan, scope and findings, while day-to-day administration can stay with management. The principle is that the audited function must have no say over the plan, scope or findings; any arrangement that gives it that say recreates the threat.

Independence from the audited team is enough for internal purposes, but not when an outside party must rely on the result. A customer, regulator or investor who asks for independent assurance on a company's controls needs an auditor independent of that company. Two things must both be present: an outside party, and an attestation or certification opinion. Work performed inside the company lacks the first however it is shared, and advisory work such as a readiness assessment lacks the second. An attestation by an independent CPA firm, such as a SOC 2 Type 2, supplies both.

Audit requirements shape cloud adoption because the organisation must still produce evidence for its own auditors and regulators after the systems move: if the contract, the service's features or the provider's audit policy prevent that, the obligation goes unmet. The time to deal with this is before signing, not when the auditor asks.

• Evidence must be obtainable under the contract. Identify which records each obligation requires (activity logs, access reviews, change records, configuration history) and confirm the service can deliver them, for the required period, in a usable form.
• Logging and retention are designed in. A provider's default retention may be shorter than the customer's obligation. When an obligation outlasts the service's retention window, the customer delivers the logs to storage it controls and keeps them for the full period the obligation requires. A provider's audited retention control is evidence about the provider's own practice, not the customer's records, and records that have aged out of a provider's window cannot be recovered afterwards.
• Direct audit is often refused. Multi-tenant providers rarely let individual customers audit data centres or shared infrastructure, because one tenant's audit could expose or disturb others. The normal route is reliance on independent reports: SOC 2 Type 2, ISO/IEC 27001 (with 27017/27018) certification, CSA STAR, PCI DSS attestations.
• Map attestations to the requirement first. When a regulator requires assurance over a provider that does not allow customer audits, the first step is to map the provider's independent attestations to each regulatory requirement. The mapping shows whether they suffice and where gaps remain, and only the gaps it reveals justify further steps such as negotiating additional rights.
• Right-to-audit clauses are worth negotiating where the customer's bargaining power allows, and regulated sectors may need regulator access written into the contract. Contract design itself belongs to sub-domain 6.5.

The provider's report covers the provider's controls. Whatever the customer configures and operates (identity, data, logging choices, and in IaaS the guest OS and applications) needs the customer's own evidence.

Virtualization and cloud undermine the traditional audit model of sampling assets from an inventory and inspecting them at a point in time, because resources are ephemeral, change through APIs constantly, and run on shared infrastructure the customer cannot see. The response is to audit the controls that create and govern resources, gather evidence continuously, and rely on independent reports for the provider's layer.

Two cautions. First, a provider's report never covers what the customer runs: in IaaS, patching guest operating systems is the customer's responsibility, so the provider's SOC 2 tells the auditor nothing about it. Second, change alerts report activity, not compliance; continuous monitoring compares state against a baseline and keeps the result, which is what an auditor needs to show controls held throughout the period.

SOC (System and Organization Controls, formerly Service Organization Control) reports are independent auditors' reports on a service organisation's controls, issued under AICPA attestation standards. SOC 1 covers controls relevant to customers' financial reporting, SOC 2 covers controls against the Trust Services Criteria with full test detail, and SOC 3 is a general-use summary of the same criteria without test detail.

Choosing the right report

• A SaaS service whose output feeds the general ledger (payroll, billing, revenue) affects financial reporting, so the customer's financial auditor wants a SOC 1 Type 2. Financial statement auditors rely on reports whose subject matter is financial reporting controls, which is not what any SOC 2 criterion addresses.
• A security team that must see which controls were tested, how, and what exceptions were found needs the SOC 2 Type 2, which the provider shares under NDA. A SOC 3 carries no test detail by design.
• A provider that wants to post assurance publicly without an agreement issues a SOC 3.

The Trust Services Criteria in scope

Every SOC 2 includes the security criteria (the common criteria). Availability, processing integrity, confidentiality and privacy are optional: they appear only if the service organisation puts them in scope. A report "on security" therefore says nothing about availability controls, even though availability is a Trust Services category. Read the report's list of criteria before relying on it for a specific requirement.

Type 1 versus Type 2

A Type 1 report gives the auditor's opinion on the fairness of the system description and the suitability of control design as of a specific date; a Type 2 report adds an opinion on whether the controls operated effectively throughout a period, based on testing across that period. The type and the criteria in scope are independent choices.

A new service typically starts with a Type 1, because there is little operating history to test; a Type 2 follows once the controls have operated for a review period, commonly six to twelve months, although shorter periods are possible. Every report covers only its own criteria and its own date or period, so reports cannot be stacked to fill a gap: a design opinion on a criterion as of one date is not evidence that those controls operated across a period. Where a needed criterion or period is missing, record the gap, ask the provider to bring it into scope for a future period and gather interim evidence, such as service-level performance records.

SOC reports are issued under the AICPA's Statements on Standards for Attestation Engagements (SSAE), currently SSAE 18 as amended, while the International Auditing and Assurance Standards Board (IAASB) issues the international equivalents: ISAE 3402 for controls relevant to financial reporting and ISAE 3000 (Revised) for other, non-financial assurance.

Two distinctions decide most questions. First, match the subject matter: financial reporting controls mean SOC 1 or ISAE 3402; security, availability or confidentiality controls mean SOC 2 or ISAE 3000. Second, SSAE 18 and ISAE 3402 are closely aligned, so a service auditor can perform one examination and report under both, serving US and international user auditors at once instead of producing separate reports.

Do not confuse these with management-system audit standards: ISO/IEC 19011 gives guidelines for auditing management systems (including internal ISMS audits), ISO/IEC 27006 sets requirements for bodies that certify ISMSs and ISO/IEC 27007 gives guidance on ISMS auditing. They produce certifications and audit findings, not SOC-style attestation reports.

An audit scope statement defines exactly what an audit or report covers: which services, locations, criteria, period and parties, and therefore what it does not cover. Under SSAE and ISAE, the main restrictions a reader must check are subservice organisations that were carved out, the criteria and period in scope, limits on who may use the report, and providers' limits on customer audits.

Carve-out versus inclusive method

Many service organisations depend on a subservice organisation, such as a SaaS provider hosted on an IaaS platform. The report handles that dependency in one of two ways.

Under the carve-out method, nobody in this engagement tested the subservice provider's controls, so a customer whose requirements include, say, data centre physical security needs the IaaS provider's own SOC 2 or equivalent. CSOCs are not the same as complementary user entity controls (CUECs), which are the controls the customer must operate; lesson 1.5 on evaluating providers covers CUECs, bridge letters and certificate scope in detail.

Other restrictions

• Distribution. SOC 1 and SOC 2 reports are restricted-use. A customer that receives one under NDA cannot pass it, or any version derived from it, on to its own customers; it points them to the provider's SOC 3 or to the provider, which can share its SOC 2 under its own terms.
• Criteria, services and period. Before relying on any report, confirm it covers the services used, the criteria needed and the period in question.
• Customer audit scope. Where a contract grants audit rights, the provider's scope statement often limits them to the customer's tenant configuration and documentation, excluding shared infrastructure and other tenants. For questions about the shared layer, such as tenant isolation, the customer relies on an independent report whose scope includes logical segregation and documents what remains unverified.

A gap analysis compares an organisation's current state with a target baseline (a framework, standard or internal baseline) and lists the requirements that are missing or only partly met, so they can be remediated. It is commonly run before a certification or external audit, so problems are found first.

• Control analysis examines each control against the target: does it exist, is it designed to meet the requirement, is it operating.
• Baselines are the targets: ISO/IEC 27001 Annex A, ISO/IEC 27017 cloud controls, the CSA Cloud Controls Matrix, NIST SP 800-53 control baselines or an internal configuration baseline.
• Risk and control self-assessment (RCSA) has control owners assess their own risks and controls, through workshops or questionnaires.

Gap analysis is distinct from its neighbours: a business impact analysis estimates the effect of disruption, a vulnerability assessment finds technical weaknesses, and a risk treatment plan records how risks will be handled. Only the gap analysis measures current controls against a chosen baseline.

Objectivity: who performs it

A gap analysis is only as useful as it is unbiased. People who designed or run the controls tend to rate them as more complete than they are, so when management needs results it can trust, the analysis is performed by a party independent of the teams that operate the controls, internal or external.

The two complement each other: RCSA for frequent, inexpensive tracking of control health; independent audit where someone must rely on the result. Independence comes from who performs the assessment, not from who approves it, and any provider report speaks only for the provider's layer.

Audit planning follows a cycle: define the audit objectives, then define the scope, then conduct the audit, then review lessons learned and refine the process for the next cycle. Objectives come first because they say what the audit must show and for whom; scope (systems, providers, locations, period, criteria) follows from them, and execution steps such as requesting reports or selecting samples depend on both.

1. Objectives: the assurance needed, for which audience, against which requirements.
2. Scope: the services, data, providers, locations, period and criteria; confirm contract audit rights and which provider reports exist for each layer.
3. Conduct: collect evidence, test the customer's controls, review provider reports, report findings.
4. Lessons learned: after reporting, refine the process. Whatever slowed or weakened this cycle, such as evidence that was hard to obtain or scope that proved wrong, feeds changes to the next cycle's objectives and scope.

Cloud planning is layered. In IaaS, the customer is responsible for identity, guest operating systems, applications and data, so it tests those; the provider's physical, hypervisor and network layer is covered by its independent report once the report's scope and period are confirmed. The general rule: each source of evidence covers only its own layer, so the plan assigns every layer exactly one source and neither can stand in for the other.

Identifying and involving stakeholders

Scope follows the objective, not IT's inventory. Cloud services are often bought by business units directly, so stakeholder identification must reach:

• Business and data owners, who own the processes and data and can explain how a SaaS service is used. For an audit of how patient appointment data is handled in a scheduling service, the operations lead who owns that process and data is central.
• Procurement and vendor management, whose records reveal subscriptions IT never saw. When the objective covers every service holding a given class of data, services a business unit bought on its own are in scope, and their owners must supply evidence.
• IT and security, for identity, configuration and integration; legal and compliance, for obligations and contract terms; the providers, for reports and evidence; regulators, where they set requirements or receive results; and internal and external auditors.

Planning across jurisdictions (distributed IT)

When systems, data and staff span countries, the audit team cannot assume head office's rules apply. Local law may restrict transferring personal data abroad, limit employee monitoring (often reinforced by works-council agreements), and bring local regulators with their own requirements. The plan should first establish what is permitted, normally through local counsel, and then choose the method: in-country review by local staff, an approved, minimised extract, pseudonymised review, or a narrower scope. The aim is the least intrusive method that still meets the audit objective. The legal side of conflicting jurisdictions is covered in sub-domain 6.1.

An information security management system (ISMS) is the management system that directs, measures and improves security; the internal information security controls system is the set of controls it governs; and policies express the intent and rules both follow. A cloud audit looks at all three.

The ISMS (ISO/IEC 27001)

An ISO/IEC 27001 ISMS has a defined scope (considering interfaces and dependencies with other organisations), a risk assessment and risk treatment process, a Statement of Applicability (SoA), internal audit, management review and corrective action for continual improvement. The SoA lists the necessary controls, the justification for including them, whether they are implemented and the justification for excluding any Annex A control; organisations using cloud services commonly add the ISO/IEC 27017 cloud controls to it. The risk treatment plan is its closest neighbour but records how risks will be treated, not control applicability.

When data moves to a provider, the cloud service and the provider relationship must come inside the ISMS scope and risk assessment, with supplier controls. A provider's ISO/IEC 27001 certificate is evidence for supplier management; it does not extend the customer's ISMS, and the provider operating some controls does not take the service out of the customer's scope.

An organisation can operate many monitored controls and still lack an ISMS if nothing assesses risk to justify them, reviews them at management level or corrects failures. Conversely, an ISO/IEC 27001 certificate attests that the management system conforms, with controls sampled during certification audits; it is not a report that a specific control, such as encryption at rest, meets one customer's requirement. For that, confirm the control is in the SoA and seek tested evidence, such as a SOC 2 Type 2 that covers it.

Organizational, functional and cloud computing policies

• Organizational policy: the top-level statement of management's intent, direction and authority for security.
• Functional policies: specific areas, such as access control, data classification, acceptable use or incident response.
• Cloud computing policy: how the organisation adopts and uses cloud services: approved providers, which data classes may be placed with them, procurement and approval of new services, and required security and contract terms.

Policies must align: the cloud computing policy sits beneath the organizational policy and refers to the functional policies rather than contradicting them. Standards, procedures and tools (such as a cloud access security broker) then implement it. Each layer has its own job: the organizational policy stays short and durable, operational detail belongs in the lower layers, and tools enforce policy rather than replace it. When cloud use has outgrown policies written before it, the gap is filled at the cloud computing policy layer.

Highly regulated industries add sector rules on top of general security frameworks, and in every case the regulated organisation stays accountable when it uses a cloud provider, so the audit must produce evidence against the sector's own requirements. The CCSP outline names NERC CIP, HIPAA, HITECH and PCI.

NERC CIP in the cloud

Moving BES Cyber System Information to a SaaS platform does not move the obligation: the provider does not become a registered entity, and the information does not leave CIP scope. A provider's SOC 2 report or ISO/IEC 27001 certificate is measured against other criteria. It can support the utility's evidence but is not CIP evidence by itself; the utility must show how each applicable CIP requirement is met and contract for the evidence it needs. ISO/IEC 27019 offers security controls for the energy sector, but it is voluntary guidance, not the mandatory North American regime.

HIPAA and HITECH

Before HITECH, business associates were bound mainly by their contracts with covered entities. Since HITECH, a cloud provider maintaining ePHI under a BAA is directly subject to the Security Rule and can face enforcement and penalties itself, alongside the covered entity. Other US laws address different ground: Sarbanes-Oxley governs public companies' internal control over financial reporting, and Gramm-Leach-Bliley protects customer information held by financial institutions; neither sets the health-information rules. The privacy-law detail of PHI and business associates is in sub-domain 6.2.

PCI DSS

For card data, the audit checks that the division of PCI DSS responsibilities with each third-party service provider is written down and that the provider's compliance is verified at least annually. How to verify a provider's PCI DSS status (attestations of compliance and their scope) is covered in lesson 1.5.