SOC 2, ISO 27017, CSA STAR, FIPS 140-3: How to Read a Cloud Provider's Proof

In your own data center you can walk to the rack. In a cloud you get a PDF. CCSP objective 1.5 is about evaluating cloud service providers, and in practice that means reading the evidence they publish and knowing what it does and does not prove. The exam tests the alphabet: SOC reports, ISO standards, CSA STAR, FIPS, Common Criteria. The skill underneath the alphabet is simpler, and it is the same every time: who checked, against what, over what period, and for which part of the service?

Proof is a product

Providers publish attestations because customers cannot audit them individually. The result is a market of evidence, and each artifact answers a different question. An audit report says an independent firm examined controls. A certification says a body confirmed conformance to a standard. A product validation says a specific module was tested against a specification. A self-assessment says the provider filled in a questionnaire. Confusing these is how organizations end up trusting a logo on a website.

The SOC reports

SOC reports are audit reports, produced by an accounting firm under attestation standards. There are three, and the numbers do not indicate strength; they indicate subject.

The exam's core distinction is Type I versus Type II. A Type I report says the controls were suitably designed as of a date. A Type II report says they operated effectively across a period, typically six to twelve months, with the auditor testing samples throughout. A control that exists on paper passes Type I and fails Type II, which is why a customer evaluating a provider wants the Type II, and why a provider with only a Type I is usually a provider that is new. A SOC 3 is a marketing document: real, independent, and lacking the detail you would need to rely on it.

Reading the report: scope and the user's own homework

A SOC 2 is not a pass or fail. It is an opinion on a scope, and two things inside it decide what it proves for you.

The scope defines which services, which locations and which criteria were examined. A provider with dozens of services may have a report covering ten of them, and the one you use may not be in it. The exam presents this as a provider "with a SOC 2" whose report, on inspection, does not cover the service in question.

Complementary user entity controls are the other trap. Every SOC report lists controls the provider assumes you, the customer, have implemented: managing your own users, configuring encryption options, reviewing your own logs. If you have not, the provider's clean opinion does not extend to your deployment. A scenario describing a breach at a customer whose provider had a spotless SOC 2 is usually describing a user entity control the customer never implemented. Exceptions noted by the auditor, and the gap between the report period and today, are the remaining things to read before relying on it.

The ISO family

ISO/IEC 27001 is a certification against a management system standard. It proves the provider has a functioning process for managing security: risk assessment, control selection, review, improvement. It does not by itself prove much about any individual control, which is the exam's nuance: 27001 certification is necessary evidence of a managed program and insufficient evidence of any specific protection.

Two extensions matter for cloud. ISO/IEC 27017 adds cloud-specific controls and clarifies which party, provider or customer, is responsible for each. ISO/IEC 27018 adds controls for protecting personal data in public clouds when the provider acts as a processor. A scenario about evidence that a provider handles personal data appropriately as a processor points at 27018; one about cloud-specific control guidance and responsibility allocation points at 27017. Both ride on top of a 27001 certification rather than replacing it.

CSA STAR: three levels

The Cloud Security Alliance's STAR program is a registry built on the Cloud Controls Matrix, the CSA's cloud-specific control framework. It has three levels, and the level is the whole question.

• Level 1 is self-assessment: the provider publishes its completed Consensus Assessments Initiative Questionnaire. Useful for reading how the provider describes itself; not independent.
• Level 2 is third-party assessment: an independent attestation or certification against the Cloud Controls Matrix, typically combined with a SOC 2 (STAR Attestation) or ISO 27001 (STAR Certification).
• Level 3 is continuous auditing, the highest level, in which the provider's controls are monitored and reported on an ongoing basis.

The exam's scenario: an organization that accepted a provider's STAR listing as independent assurance and discovers it was Level 1 has accepted a questionnaire.

Product validations: FIPS and Common Criteria

The remaining evidence covers products rather than services, and the exam draws the line carefully.

FIPS 140-3 validates a cryptographic module: a specific hardware or software component, at a specific version, at one of four levels from software-only to tamper-responsive hardware. A provider's "FIPS validated encryption" means a validated module is available and is used when configured. It does not mean everything in the service is validated, and it does not mean your deployment is using it, which is a user entity control in disguise.

Common Criteria evaluates a product against a security target (what the vendor claims) or a protection profile (what a class of product must do), at an evaluation assurance level from EAL1 to EAL7. The number measures how rigorously the claims were checked, not how secure the product is: an EAL4 firewall was examined more thoroughly than an EAL2 one, and may or may not be stronger. That distinction is the single most tested Common Criteria fact, and it appears in CISSP Domain 3 as well.

Government programs such as FedRAMP in the United States sit at the top of the ladder for their own jurisdictions: a whole cloud service authorized for government use after a controls assessment, with continuous monitoring afterward. Other regions have equivalents, and the exam's point is that authorization is the strongest and most specific evidence, and the least portable.

Building the evaluation

Objective 1.5 frames all of this as verification against criteria: you decide what the service must satisfy, then map the evidence to each criterion and note what is left uncovered. The criteria come from your own classification of the data going into the service, the regulations that apply to it, and the recovery objectives the business set. The evidence comes from the ladder above. What is left uncovered becomes either a contractual requirement, a control you implement yourself, or a documented residual risk that someone with authority accepts. A provider evaluation that ends with "they have a SOC 2" has skipped the first step and the last one, and the exam's scenarios about provider assessments going wrong are almost always about one of those two omissions.

Four stems, decoded

1. A provider's website shows a SOC 2 badge; on request, the report turns out to be a Type I from eighteen months ago covering a different service. Wrong type, stale, and out of scope. Ask for the current Type II covering the service you use.
2. A customer with a compliant provider suffers a breach because its own administrators never enabled the logging the report assumed. A complementary user entity control was not implemented. The provider's opinion did not extend to the customer's configuration.
3. Procurement wants evidence that a provider handles personal data properly when acting as a processor. ISO/IEC 27018, on top of 27001.
4. An architect chooses between two hardware security modules and picks the one with the higher Common Criteria EAL as "more secure." EAL measures rigor of evaluation against the vendor's own claims. Compare the security targets and the FIPS levels, not the EAL numbers alone.

Evaluating cloud service providers is objective 1.5 of CCSP Domain 1, Cloud Concepts, Architecture and Design, 17% of the exam, and it is the evidence side of the shared responsibility model the domain is built on. The same independence rules govern assessment and audit on the CISSP. Work all 31 topics with our CCSP Domain 1 study guide.

#CCSP #ISC2 #CloudSecurity #SOC2 #ISO27017 #CSASTAR #FIPS140 #CommonCriteria #CloudCompliance #CyberSecurity