The Cloud Compliance Framework Maze: SOC 2, ISO 27001, FedRAMP, and What They Actually Prove

SolarWinds was SOC 2 Type II compliant when its Orion update mechanism distributed the Sunburst backdoor to 18,000 organizations, including the U.S. Department of Homeland Security, the Treasury Department, and the National Nuclear Security Administration. Equifax was PCI DSS compliant when a failure to patch a known Apache Struts vulnerability exposed the personal data of 147 million Americans. Capital One passed its SOC 2 audit while a misconfigured WAF allowed a former cloud employee to exfiltrate 106 million credit card applications from S3.

These are not anomalies. They are the predictable result of a compliance industry that certifies processes rather than outcomes, evaluates controls rather than security, and produces reports that measure what an organization says it does rather than what it actually does. The global compliance and certification market reached $45 billion in 2025, according to Allied Market Research. The correlation between compliance spending and breach prevention remains statistically insignificant.

This is not an argument against compliance. It is an argument for understanding what compliance proves, what it does not prove, and why organizations that equate “compliant” with “secure” or “private” are operating on a dangerous assumption.

SOC 2 Type II: The Industry Standard

What It Certifies

SOC 2 (System and Organization Controls 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A SOC 2 Type II report evaluates an organization’s controls against one or more Trust Services Criteria (TSC):

• Security (mandatory): Controls against unauthorized access.
• Availability (optional): Controls ensuring system availability per SLA commitments.
• Processing Integrity (optional): Controls ensuring data processing is complete, valid, accurate, and timely.
• Confidentiality (optional): Controls protecting information designated as confidential.
• Privacy (optional): Controls governing the collection, use, retention, and disposal of personal information.

A Type II report covers a specified period (typically 6-12 months) and includes the auditor’s testing of whether the controls operated effectively during that period.

What It Does Not Certify

SOC 2 does not certify:

• That the system is secure. SOC 2 certifies that specified controls exist and operated as designed. A control can operate as designed and still be insufficient to prevent a breach. An organization with a weak password policy (8 characters, no MFA) can pass SOC 2 if the policy is documented, implemented, and consistently enforced.
• That data is encrypted end-to-end. SOC 2 Security requires access controls but does not mandate encryption standards. An organization can achieve SOC 2 compliance while storing sensitive data unencrypted, as long as access controls are in place to restrict who can read it.
• That the organization does not access customer data. SOC 2 Confidentiality requires controls to protect designated confidential information, but it does not prohibit the organization from accessing that information. A cloud provider that reads customer data for machine learning training, product improvement, or analytics can be SOC 2 compliant if these uses are disclosed in its terms and the data handling is controlled.
• That vulnerabilities are patched promptly. SOC 2 requires a vulnerability management program. It does not specify patching timelines. An organization that identifies a critical vulnerability and schedules a patch for 90 days later is potentially compliant if the 90-day timeline is within its documented policy.

The Audit Gap

SOC 2 audits are point-in-time (Type I) or period-in-time (Type II) evaluations. A Type II audit covering January through December examines controls during that period. A breach occurring in February of the following year is outside the audit scope. The organization’s SOC 2 report remains valid despite the breach.

Furthermore, SOC 2 auditors examine a sample of evidence, not the complete record. An auditor testing access control effectiveness might review 25 access change requests out of 10,000. The sample is statistically selected, but a systemic weakness that affects 5% of cases could be missed with a sample of 25.

The AICPA’s own guidance acknowledges that SOC 2 reports provide “reasonable assurance” rather than absolute assurance. In practice, “reasonable assurance” means “we looked at a sample and it seemed fine.”

ISO 27001: The International Framework

What It Certifies

ISO 27001 is an international standard for Information Security Management Systems (ISMS). Certification (by an accredited body) confirms that the organization has:

1. Established an ISMS with a defined scope.
2. Conducted a risk assessment.
3. Selected controls from Annex A (93 controls in the 2022 revision) to mitigate identified risks.
4. Implemented those controls.
5. Established a continuous improvement process.

The 2022 revision reorganized controls into four categories: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls).

What It Does Not Certify

ISO 27001 is a management system standard, not a technical security standard. It certifies that the organization has a system for managing information security. It does not certify specific technical outcomes.

An organization can select controls based on its own risk assessment. If the risk assessment determines that server-side encryption of customer data is not a required control (perhaps because the organization’s own risk tolerance accepts the residual risk), the absence of encryption does not prevent ISO 27001 certification.

The certification audit verifies that the selected controls are implemented and effective. It does not evaluate whether the right controls were selected — that judgment is the organization’s, based on its own risk assessment. An organization that underestimates risk (a common human failing) selects insufficient controls, implements them correctly, and receives certification.

Additionally, ISO 27001 certification scope can be limited. An organization can certify its ISMS for a specific product, division, or data center while leaving the rest of the organization uncertified. A cloud provider with ISO 27001 certification for its “Enterprise Cloud” product may not have the same certification for its internal tools, development environments, or employee systems — any of which could be an attack vector to the certified product.

FedRAMP: The Government Standard

What It Certifies

FedRAMP (Federal Risk and Authorization Management Program) is the US government’s standardized approach to security assessment for cloud services. It is based on NIST SP 800-53, which defines approximately 1,000 security controls across 20 families. FedRAMP defines three impact levels:

• Low: 125 controls. For systems where loss of confidentiality, integrity, or availability has limited adverse effect.
• Moderate: 325 controls. For systems where loss has serious adverse effect. Most federal cloud deployments.
• High: 421 controls. For systems where loss has severe or catastrophic adverse effect. Law enforcement, defense, healthcare.

FedRAMP authorization requires a Third Party Assessment Organization (3PAO) to evaluate the cloud service against the applicable control set, and a government authorizing official to accept the residual risk.

What It Does Not Certify

FedRAMP is the most rigorous commercial cloud certification available. It also has significant limitations:

Shared responsibility gaps. FedRAMP certifies the cloud service provider’s controls but does not audit how the customer configures and uses the service. A FedRAMP-authorized AWS environment with a publicly accessible S3 bucket is still “FedRAMP authorized” — the misconfiguration is the customer’s responsibility, not a deficiency in the authorization.

Continuous monitoring vs. continuous assurance. FedRAMP requires continuous monitoring (monthly vulnerability scans, annual assessments, Plan of Action and Milestones for remediation). But continuous monitoring of controls is not continuous assurance of security. The SolarWinds Orion platform was used in FedRAMP-authorized environments. The supply chain compromise was not detected by FedRAMP’s continuous monitoring because the monitoring framework does not evaluate the integrity of software supply chains at the depth required to detect a nation-state backdoor.

Scope limitation. FedRAMP authorization is specific to the boundary defined in the System Security Plan. Features, services, or infrastructure outside that boundary are not covered. A cloud provider may have FedRAMP authorization for its core compute service but not for its AI inference service, its data analytics tools, or its partner integrations.

HIPAA: The Healthcare Framework

HIPAA does not certify cloud providers. There is no “HIPAA certification” — no third-party audit resulting in a badge or certificate. What exists is the Business Associate Agreement (BAA): a contract between covered entities and business associates committing to HIPAA Security Rule requirements. AWS, Azure, and GCP offer BAAs.

The Security Rule requires administrative, physical, and technical safeguards but is technology-neutral — specifying outcomes, not implementations. An organization storing PHI unencrypted may technically satisfy access control requirements, though the HHS Office for Civil Rights has increasingly emphasized encryption.

In 2024, the HHS Office for Civil Rights settled 15 HIPAA enforcement actions for $6.7 million combined. The most common violations were procedural: failure to conduct risk assessments, failure to implement access controls, and failure to encrypt ePHI. Basic failures, years after HIPAA’s enactment.

PCI DSS: The Payment Standard

PCI DSS (Payment Card Industry Data Security Standard) is the most technically prescriptive of the major compliance frameworks. Version 4.0 (effective March 2024, with full enforcement by March 2025) defines 12 requirements with approximately 250 sub-requirements covering network security, access control, monitoring, and testing.

PCI DSS mandates specific technical measures:

• Encryption of cardholder data at rest using AES-128, AES-256, RSA 2048, or equivalent.
• TLS 1.2+ for all transmissions of cardholder data.
• Multi-factor authentication for all remote access.
• Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV).
• Annual penetration testing.

PCI DSS is more prescriptive and more technically rigorous than SOC 2 or ISO 27001. It is also narrower in scope: it applies only to the Cardholder Data Environment (CDE), not to the entire organization. Systems outside the CDE are out of scope, even if they are connected to CDE systems.

And PCI DSS compliance has not prevented breaches. Target was PCI DSS compliant when attackers stole 40 million credit card numbers through a compromised HVAC vendor’s VPN credentials. The attack vector (third-party vendor access) was technically outside the PCI DSS scope of Target’s CDE assessment, even though it provided the entry point that reached the CDE.

The Compliance Theater Problem

The term “compliance theater” describes the phenomenon where organizations invest in compliance certifications as a substitute for — rather than a complement to — actual security engineering. The symptoms are recognizable:

Checkbox mentality. Controls are implemented to satisfy the auditor, not to mitigate risk. A vulnerability management policy is created because SOC 2 requires one, not because the organization has analyzed its vulnerability exposure.

Audit-driven security. Security improvements are prioritized based on what the auditor will evaluate, not on what the threat model requires. An organization preparing for a SOC 2 audit may prioritize documenting its access control procedures while neglecting to patch a critical kernel vulnerability — because the auditor evaluates the procedure, not the patch status.

Certification shopping. Organizations select the compliance framework that is easiest to achieve, not the most relevant to their threat model. SOC 2 Type II is popular partly because it is less prescriptive (and therefore easier to achieve) than FedRAMP or PCI DSS.

Scope minimization. Organizations define the narrowest possible scope for certification, excluding systems and processes that are difficult to secure. A cloud provider may certify its production environment while excluding its development environment, its CI/CD pipeline, and its employee workstations — any of which could be compromised to attack the production environment.

The result is an industry where “SOC 2 compliant” is a marketing claim rather than a security guarantee. A 2024 Coalition Cyber Insurance report found that organizations with SOC 2 Type II attestation had a 4% lower breach rate than organizations without — a statistically measurable but hardly reassuring difference, given the cost and effort of achieving and maintaining the attestation.

What Compliance Frameworks Miss

Supply Chain Risk

No major compliance framework adequately addresses software supply chain security. SOC 2 does not evaluate the integrity of third-party dependencies. ISO 27001 includes a control for supplier relationships (A.5.19-5.22) but does not require evaluation of transitive dependencies. FedRAMP requires a supply chain risk management strategy but does not mandate software bill of materials (SBOM) analysis.

The SolarWinds, Log4Shell, and XZ Utils incidents demonstrated that supply chain compromise is the most impactful attack vector in cloud environments. The compliance frameworks have not caught up.

Data Minimization

GDPR Article 5(1)(c) requires data minimization — collecting and processing only the personal data necessary for the specified purpose. No compliance framework operationalizes this into testable controls. SOC 2 Privacy addresses data collection practices but does not measure whether the collected data is minimal.

For zero-persistence architectures, data minimization is axiomatic: data that does not persist cannot be excessive. But compliance frameworks do not recognize zero persistence as a compliance control — an organization that stores nothing receives no compliance benefit relative to an organization that stores everything (with access controls).

Cryptographic Verification

Compliance frameworks evaluate whether encryption is implemented. They do not verify the cryptographic implementation. An organization using AES-256 with a deterministic initialization vector (a fatal implementation error that reduces AES-256 to a substitution cipher) passes the compliance check for “encryption at rest” because the checkbox is “is AES-256 used?” — not “is AES-256 implemented correctly?”

AES-256-GCM provides authenticated encryption with provable security properties — but the compliance framework does not distinguish between AES-256-GCM (secure) and AES-256-ECB (insecure for most use cases). Both satisfy the “AES-256” checkbox.

Insider Threat

Compliance frameworks require access controls and audit logging. They do not prevent insider access. A cloud provider’s employee with production access can read customer data, and the compliance framework’s control is that this access is logged — not that it is prevented.

For zero-trust architecture, the mitigation is to assume insider compromise and encrypt data with keys the insider does not possess. Compliance frameworks do not require this level of architectural mistrust.

The Alternative: Architectural Guarantees

Compliance frameworks certify that an organization follows a process. Architectural guarantees prove that a system has a specific property — regardless of whether any individual follows the process.

The difference is enforcement mechanism. A compliance guarantee is enforced by human process: someone must follow the policy, the policy must be monitored, violations must be detected and remediated. A human must consistently make the right decision. An architectural guarantee is enforced by the system: the system is designed so that the undesirable outcome is not possible, regardless of human behavior.

This does not mean architectural guarantees are perfect. They depend on the correctness of the implementation — a bug in the encryption library, a flaw in the V8 isolate sandbox, or a hardware vulnerability in confidential computing silicon could compromise the guarantee. But the failure mode is a technical defect (fixable, detectable, bounded) rather than a human error (recurring, undetectable, unbounded).

The Stealth Cloud Perspective

Stealth Cloud does not dismiss compliance frameworks. We recognize their role in providing a common baseline for organizational security practices and satisfying regulatory requirements. What we reject is the assumption that compliance implies privacy.

Our architecture is designed to provide guarantees that no compliance framework can certify, because no compliance framework evaluates the properties we care about:

• Zero persistence is not a SOC 2 control. No auditor checks that data is never written to disk. Our architecture enforces it through the V8 isolate model: there is no disk to write to.
• Zero knowledge is not an ISO 27001 control. No certification verifies that the server cannot decrypt user data. Our architecture enforces it through client-side AES-256-GCM encryption: the server never possesses the key.
• Zero identity is not a FedRAMP requirement. No framework certifies that a system does not collect PII. Our architecture enforces it through wallet-based authentication: no email, no phone number, no government ID.

We operate from Switzerland — a jurisdiction whose data protection laws are among the strictest in the world and whose constitutional commitment to privacy predates digital computing. Swiss regulatory compliance is a floor, not a ceiling.

The ceiling is architecture. Compliance proves you wrote a policy. Architecture proves the policy cannot be violated. When the next SOC 2-compliant company suffers a breach — and it will — the question will not be whether they followed their controls. It will be whether their architecture was capable of protecting their users even when the controls failed. For systems that store everything and trust their operators, the answer will continue to be no. For systems built on zero persistence, zero knowledge, and zero trust, the answer is structural.