Trust & compliance

Cloud Atlantis OS holds no compliance certification today. It is pre-sale, and a certification is earned through an audit, not asserted in a document — so a page that claimed one would be the first thing a security team caught. This page is the opposite: the honest version. It explains what each framework is, who is allowed to grant it, how the audit process runs, what the platform’s architecture already supplies toward it, and the order in which the certifications will actually be pursued.

The load-bearing argument runs through all of it. Most of what an auditor tests — who can reach a record, whether field access is enforced, whether every configuration change is logged, whether data can be genuinely deleted — is already an architectural invariant on CAOS, enforced in the query and in the save order rather than bolted on as policy. That does not make the platform certified. It makes the eventual audit cheaper, the evidence continuous, and the gap between “how it works” and “what the auditor needs to see” small. The remaining gap is real and this page names it: an auditor needs organizational controls — key management, physical datacenter security, HR and vendor process, a signed report from a licensed firm — that no amount of code supplies.

A second distinction governs the whole page and buyers routinely collapse it: certifications are not one kind of thing. A SOC 2 is a report. An ISO 27001 is a certificate. HIPAA “certification” does not officially exist. Getting the category wrong is worse than saying nothing, because it tells the reader you have not done this before.

The landscape — what the frameworks actually are

Five categories, and the difference between them is who grants the thing and whether the thing is a certificate at all.

Framework	Category	Who audits / grants it	What you get	Cadence
SOC 2 (Type I / Type II)	Attestation	A licensed CPA firm (a service auditor)	An attestation report, not a pass/fail certificate	Type II covers a 3–12 month observation window; annual thereafter
ISO/IEC 27001:2022	Certification	An accredited certification body — never ISO itself	A certificate	3-year cycle with annual surveillance audits, then recertification
ISO/IEC 27017 / 27018 / 27701	Certification (extensions of 27001)	The same accredited body, in the same audit	A certificate / statement of applicability alongside 27001	Annual, folded into the 27001 cycle
CSA STAR	Attestation or certification (builds on the above)	A CSA-approved assessment firm; listed on a public registry	Level 1 self-assessment, or Level 2 attestation (SOC 2-based) / certification (27001-based)	Level 2 attestation ~1 year; certification ~3 years
HIPAA	Regulation — no certification exists	Enforced by HHS Office for Civil Rights; no government certificate	You attest to compliance and sign Business Associate Agreements	Ongoing; BAAs per relationship
GDPR	Regulation	Enforced by EU supervisory authorities (DPAs); Art. 42 certification is voluntary and nascent	Demonstrable compliance; a certification does not reduce liability	Ongoing
CCPA / CPRA	Regulation	Enforced by the California Attorney General and the California Privacy Protection Agency	Demonstrable compliance	Ongoing
PCI DSS	Industry-mandated	The PCI Security Standards Council; assessed by a QSA or by SAQ self-assessment	An Attestation of Compliance	Annual — only if card data is handled
FedRAMP	Government	A 3PAO assessment plus agency (or JAB) authorization	An Authorization to Operate	Continuous monitoring; future / if-needed

Two things in that table are not frameworks and belong in the reader’s vocabulary anyway. PII — personally identifiable information — is a data category, not a standard; it is what GDPR, CCPA, HIPAA, and ISO 27018 each govern a slice of, and on CAOS it is a field classification the platform enforces rather than a label. A penetration test and a vulnerability assessment are not certifications either; they are inputs an auditor expects to see evidence of — an independent attacker’s report and a recurring scan — before signing any of the above.

Attestation — SOC 2

SOC 2 is the fastest signal for a SaaS buyer and the one most often misdescribed. It is an attestation engagement performed by a licensed CPA firm under the AICPA’s attestation standards (the SSAE 18 framework), and its output is a report, not a certificate — there is no “SOC 2 certified,” only “we hold a SOC 2 Type II report and here it is under NDA.” The report opines on controls against the AICPA’s five Trust Services Criteria: Security (the one every SOC 2 includes), Availability, Processing Integrity, Confidentiality, and Privacy, the last four included only if scoped in.

The Type I / Type II distinction is the whole timeline:

• Type I opines on whether controls are designed appropriately at a single point in time. It is achievable in weeks and is a weaker signal — increasingly, buyers reject it.
• Type II opines on whether those controls operated effectively over a period — typically 3 to 12 months. That observation window is the cost: there is no shortcut to demonstrating a quarter of continuous evidence, which is exactly why a platform that emits continuous evidence has an advantage here.

Certification — ISO/IEC 27001 and its family

ISO/IEC 27001:2022 is a certification against a management-system standard — an Information Security Management System (ISMS). The critical fact a buyer gets wrong: ISO does not certify anyone. ISO is a nongovernmental developer of voluntary standards; certification is performed by an accredited certification body, one accredited by a recognized national accreditation body and a member of the International Accreditation Forum. The certificate runs on a three-year cycle with annual surveillance audits and a recertification at the end. The 2022 revision restructured the Annex A control set.

Three extensions ride the same audit rather than standing alone:

• ISO/IEC 27017 — a code of practice for cloud-specific security controls, adding seven cloud controls (customer/provider shared responsibility, tenant isolation, VM hardening, admin-operation logging) on top of ISO/IEC 27002. It is audited annually as part of the 27001 certification.
• ISO/IEC 27018 — a code of practice for protecting PII in public clouds where the provider acts as a processor. An accredited third-party body audits it at least annually alongside 27001.
• ISO/IEC 27701 — a Privacy Information Management System (PIMS) extension covering controller and processor duties, with a published mapping toward GDPR. It cannot be obtained independently — only as an extension of an existing 27001 certification.

CSA STAR builds directly on this stack. It combines the Cloud Controls Matrix (CCM) with either SOC 2 or ISO 27001, and publishes the result on a public registry. Level 1 is a self-assessment (the CAIQ questionnaire); Level 2 is a third-party engagement — STAR Attestation (SOC 2-based, ~1-year validity) or STAR Certification (ISO 27001-based, ~3-year validity).

Regulation with no certification — HIPAA, GDPR, CCPA/CPRA

These are laws, not audit programs, and the mistake is treating them like ISO.

• HIPAA is enforced by the HHS Office for Civil Rights. There is no official HIPAA certification — certification “is not a requirement of HIPAA … a voluntary process,” and no government body grants or endorses one. Compliance is demonstrated by attestation, by the Security and Privacy Rule controls, and by signing a Business Associate Agreement (BAA) with every partner that touches protected health information. A vendor’s “HIPAA certified” badge means a third party ran an assessment, not that a regulator blessed it.
• GDPR is enforced by each EU member state’s supervisory authority (DPA), with fines up to €20 million or 4% of global turnover. Article 42 does establish voluntary certification mechanisms, but they are nascent, and the Regulation is explicit that a certification “does not reduce the responsibility of the controller or the processor for compliance” and is “without prejudice to the tasks and powers of the supervisory authorities.” A GDPR certificate is not a shield; the posture is architectural and ongoing.
• CCPA / CPRA is enforced by the California Attorney General and the California Privacy Protection Agency (CPPA), granting consumers rights to know, delete, correct, opt out of sale/sharing, and limit use of sensitive data.

Industry-mandated and government — PCI DSS, FedRAMP

• PCI DSS is maintained by the PCI Security Standards Council and applies to any entity that stores, processes, or transmits cardholder data. It is assessed by a Qualified Security Assessor (QSA) or, at lower volumes, a Self-Assessment Questionnaire (SAQ). It is only relevant if CAOS or an app on it handles payment card data directly — which the architecture is designed to avoid by keeping card data with a tokenizing payment processor.
• FedRAMP governs US federal cloud use: a 3PAO (third-party assessment organization) performs the assessment and an agency (or the Joint Authorization Board) issues the authorization. StateRAMP is the state-government analog. Both are future / if-needed — pursued only when a government customer requires them, because the effort dwarfs the commercial frameworks.

Who decides, and how the process works

Every one of these frameworks runs the same loop, and understanding it is understanding why compliance is a program rather than a project.

1. Readiness. Map the framework’s requirements to actual controls, find the gaps, and close them. This is where policies get written, evidence pipelines get built, and — for the technical controls — where CAOS’s architectural invariants do most of the work.
2. Controls in operation. The controls have to run, continuously, and generate evidence that they ran. For an attestation, this evidence has to accumulate across the observation window — the reason a SOC 2 Type II takes months regardless of how good the controls are.
3. The audit. An independent party examines the evidence: a licensed CPA firm for SOC 2, an accredited certification body for ISO 27001, a QSA for PCI, a 3PAO for FedRAMP. Independence is the point — the whole value of the artifact is that the organization did not grade its own work.
4. The report or certificate. SOC 2 yields a report; ISO yields a certificate; the categories from the table above.
5. Renewal. None of this is once-and-done. SOC 2 is annual, ISO runs a 3-year cycle with annual surveillance, PCI is annual. A certification that lapses is worse than never having held one, because the lapse is visible.

Continuous-compliance and trust-center platforms — Vanta, Drata, Secureframe, SafeBase — exist to automate steps 1, 2, and the presentation. They connect to the systems under audit, collect evidence on a schedule, monitor controls in real time, and host the trust center: a public page showing “continuous, real-time evidence of your active controls — demonstrating trust that goes beyond a one-time compliance snapshot,” with sensitive documents gated behind NDA and access approvals automated. CAOS has a structural advantage feeding one of these, discussed below: the platform already emits the continuous audit and config evidence these tools normally have to scrape.

The presentation model is well-established. A public trust center — CloudFiles’ at trust.cloudfiles.io is a representative example — is structured as compliance badges (HIPAA, SOC 2, GDPR, ISO 27001:2022, CSA STAR, ISO 27017, ISO 27018) → a document vault split into public documents and private, NDA-gated ones (the SOC 2 report is access-requested, not downloadable) → a controls inventory grouped by domain (corporate, endpoint, access, network, infrastructure, application, data, and product security, plus policies and reports including the penetration test) → a sub-processor list → FAQs, carrying a “Monitored On” date that signals continuous monitoring rather than a stale annual snapshot. The incumbents present trust the same way at scale — Salesforce’s compliance portal and AWS Artifact are both self-service document vaults over the same idea.

The shared-responsibility model

This is the single most important concept for a platform as opposed to a single application, and getting it wrong is how a customer assumes they inherited something they did not.

CAOS-the-platform gets certified. An app built on CAOS inherits the platform’s controls but owns its own configuration, data, and users. Dragon Products is customer #1, and the line runs like this:

The platform owns (and gets audited on)	The customer owns (and must handle themselves)
Tenant isolation — schema-per-tenant, enforced by the kernel	Who they invite, and what permission sets they grant them
Access enforcement — FLS and record access in-query	The org-wide defaults, roles, and sharing rules they actually configure
Encryption in transit and at rest across the database	Which fields they classify as sensitive or PII
The always-on audit and log streams	Reviewing those logs, and acting on what they show
The backup and point-in-time-restore machinery	Their own retention and erasure policy choices
Platform-level subprocessor and credential handling	The external systems they connect and the DPAs they sign

A customer’s SOC 2 or ISO effort is therefore smaller on CAOS than on bare infrastructure — they inherit the platform’s certified controls as evidence — but it is not zero, and a platform that implied otherwise would be setting its customers up to fail their own audit. Where the platform’s certification ends and the customer’s begins has to be stated in the trust center in exactly these terms.

What the architecture already provides

The thesis of this page: on CAOS the technical control families an auditor tests are not policies written to satisfy a framework — they are invariants the kernel enforces on every request. Each maps to a mechanism already documented elsewhere in this guide.

Control family (as an auditor names it)	The CAOS mechanism that already implements it	Where it lives
Access control / least privilege	Additive permission sets, no profiles, the 52-permission enumerated catalog, effective-access resolved in-query with no system-mode bypass	Permissions & FLS
Authorization / record segregation	Ownership, org-wide-default floor, role hierarchy, and grants compiled to a per-tenant RLS predicate	Roles & record sharing
Authentication / identity	Separation of identity from authorization, MFA/assurance levels, constrained read-only impersonation with step-up and typed reason	Identity & authentication
Audit logging / monitoring	Three always-on streams — metadata audit, data history, execution trace — sharing one correlation id, nothing paywalled, nothing off by default	Audit & logs
Change management	Every configuration change is a diffable component through retrieve → validate → apply, recorded in the metadata audit with actor and generation	Metadata & deploy
Tenant isolation / multi-tenancy	Schema-per-tenant; a tenant’s root is never a cross-tenant key	Environments
Data classification	A closed classification vocabulary (public…restricted) plus org-editable regimes (gdpr, hipaa, pci…) driving masking, model-visibility, log redaction, and export manifests	Field model
Data retention & disposal	One retention policy per object — recycle bin, archive, purge — with legal-hold veto	Data management
Right to erasure / data-subject deletion	An erasure operation that purges live rows, redacts history in place, and writes a tombstone applied to every future restore	Data management
Backup & recovery	Continuous WAL-based point-in-time recovery, included, not a SKU	Data management
Subprocessor / vendor management	Every external boundary is a declared credential-bound component; secrets live in a write-only store, never a field value	Integrations
Incident / availability signalling	Execution-trace telemetry, per-client rate containment, and the error envelope’s correlation id	Integrations · Errors

The consequence for an audit is concrete. When an ISO assessor asks “show me that a terminated user cannot read customer records,” the answer is a deactivation flow plus an access predicate that evaluates on every query, with the record disposition logged — not a screenshot of a checkbox. When a SOC 2 auditor samples “prove field-level access was enforced across the window,” the data-history stream honors FLS and is queryable as a table. The evidence is continuous because the enforcement is continuous.

What the architecture does not provide, stated plainly, because an auditor will ask:

• Encryption key-management specifics. The database is encrypted at rest and in transit, but formal key-rotation cadence, HSM custody, and key-access separation-of-duties are operational controls that must be documented and run, not derived from the schema.
• Physical and datacenter controls. These are inherited from the hosting provider and evidenced by their SOC 2 / ISO reports; CAOS carries the responsibility of vendor oversight, not of a datacenter.
• Organizational and HR controls. Background checks, security-awareness training, onboarding/offboarding process, a documented risk assessment, an incident-response plan with tested runbooks, a vendor-management program — none of these is code, and every framework requires them.
• Formal written policies. An information-security policy, an access-control policy, a data-retention policy as documents, reviewed and approved on a cadence. The platform enforces the mechanisms; the policies that govern them are still authored by people.
• An actual report. No SOC 2 report and no ISO certificate exists yet. The architecture shortens the path to one; it does not stand in for one.

The trust center as a surface

CAOS should ship a Trust Center — a public surface with the same shape the incumbents use: public compliance badges, an NDA-gated document vault (the SOC 2 report and pen-test summary released on access request, DPAs and the security whitepaper public), a live controls inventory, a subprocessor list, and the current DPA.

The differentiator is where the controls inventory gets its data. On a bolted-on scanner, a trust center reflects what the scanner last observed. On CAOS, the platform already emits continuous audit and configuration evidence — the metadata audit knows the live state of every permission set, org-wide default, and retention policy; the execution trace knows access was enforced on every request. The trust center’s “Monitored On” date can therefore be sourced from the platform’s own state rather than from an external agent’s crawl, and a control can render as currently true rather than true as of the last scan. This is a UI surface with its own security posture (public data must be provably non-sensitive; gated data must respect the same access planes as everything else) and it will be specified separately — this section establishes that it exists and what feeds it.

The roadmap

The sequence is chosen for signal-per-effort against the buyers CAOS actually faces, and it is a decision, not a menu.

1. SOC 2 Type I → Type II, first. It is the fastest credible signal for a SaaS buyer, and the security-controls half of the readiness work is largely already built. Type I lands in weeks and unblocks early deals; Type II follows through a 3–12 month observation window and becomes the artifact enterprise buyers actually require. Starting here means the observation-window clock — the one thing that cannot be compressed — starts as early as possible.
2. ISO/IEC 27001 next, with 27017 and 27018 folded into the same audit. This is the credential international and larger-enterprise buyers weight most, and much of the SOC 2 evidence base carries over. 27017/27018 are cheap to add once 27001 is underway, and 27018 directly addresses the PII-processor question a privacy-conscious buyer asks.
3. HIPAA readiness and BAAs when healthcare demand appears. There is nothing to “get certified” for, so this is a readiness posture — the Security and Privacy Rule controls, which the access, audit, and erasure machinery largely satisfies — plus the operational readiness to sign BAAs. It is demand-triggered because a BAA is a liability commitment, not a badge.
4. GDPR and CCPA/CPRA posture from day one. This is deliberately not last, because it is mostly architectural and already partly built: data-subject erasure with tombstoned restores, field-level classification and regime tagging, export manifests, and per-tenant retention are the technical core of a data-subject-rights program. The remaining work is the paperwork these laws also require — records of processing, a DPA template, a breach-notification process — and a Data Protection Officer function if the processing volume warrants one.
5. PCI DSS and FedRAMP only if the market requires them. PCI is avoided by design — keep card data with a tokenizing processor so the cardholder-data environment never touches CAOS. FedRAMP is pursued only against a concrete government opportunity, because the assessment effort is disproportionate to any other item on this list.

The roles a real program needs, named so they are budgeted rather than discovered:

• An independent auditor — a licensed CPA firm for SOC 2, an accredited certification body for ISO.
• A penetration-test vendor, engaged at least annually and after material change; the report is evidence every framework expects.
• A security owner / CISO function accountable for the program, the risk assessment, and the policies the platform cannot author itself.
• A Data Protection Officer for the GDPR track, if processing scale triggers the requirement.

How the incumbents present and achieve trust

The mature players converge on the same two moves: publish a self-service document vault, and hold a broad, continuously-renewed set of attestations behind it.

Salesforce runs a dedicated compliance portal — “Compliance engineered for the Cloud” — structured as a browsable, self-service catalog (categories, services, documents) over what it describes as “a comprehensive set of compliance certifications and attestations,” with the reports themselves released through a Documents surface rather than posted in the open. The lesson is the shape: a public index of what is held, and gated access to the artifacts that prove it.

AWS Artifact is the document-vault model in its purest form — “on-demand access to AWS and Independent Software Vendor (ISV) compliance reports in a self-service portal,” including “auditor-issued reports, certifications, accreditations, and other third-party attestations,” alongside on-demand acceptance of agreements such as the BAA. The reports are access-controlled artifacts a customer pulls when their own auditor asks, not public downloads. CAOS’s trust center is this pattern, with the controls inventory fed from the platform’s own audit state.

Where CAOS is genuinely better:

• Continuous evidence is a platform output, not a scraper’s guess. The three always-on log streams mean a control’s current state is queryable from the platform itself, so a trust center’s controls inventory can be live rather than as-of-last-scan, and an auditor samples a table instead of a folder of screenshots.
• Technical controls are invariants, not policies. FLS and record access run in-query with no system-mode bypass, so “access was enforced” is a property of every request rather than a claim about a code path a developer might have written correctly.
• Data-subject erasure is enforced against backups. The tombstone-at-restore mechanism makes “the subject cannot come back” a mechanical guarantee, which is precisely the GDPR/CCPA control most vendors implement only for the live copy.
• Change management is the deploy pipeline. Every configuration change is a diffable, audited component, so the change-management evidence an auditor wants is the ordinary artifact of shipping, not a separate ticketing discipline.

Parity: the trust-center-plus-gated-vault presentation, the reliance on independent licensed auditors, the observation-window and renewal cadences, and the shared-responsibility split are all industry-standard, and CAOS adopts them rather than inventing an alternative. There is no clever substitute for an independent audit, and claiming one would be the anti-pattern this whole page exists to avoid.

Costs and risks:

• Certifications are expensive and recurring. Audit fees, a continuous-compliance platform subscription, an annual penetration test, and staff time recur every year. A SOC 2 Type II and an ISO 27001 cycle are ongoing operating costs, not one-time projects, and budgeting them as one-time is how programs lapse.
• A certification can lapse — visibly. A missed surveillance audit or an expired report is worse than never having held one, because a prospect’s security team checks dates. The renewal calendar is itself a control that has to be owned.
• Architecture shortens the technical half only. The organizational controls — policies, HR, risk assessments, incident-response drills, vendor oversight — are the half the code cannot supply, and they are frequently the half a first-time program underestimates.
• A claim you cannot back is a liability, not marketing. Stating or implying a certification the platform does not hold is misrepresentation a security review will catch and a regulator could act on. Every badge on the trust center must correspond to a current, held artifact, and the honest pre-sale state — “in progress, targeting SOC 2 Type II” — is the only defensible thing to publish until the report exists.
• Shared responsibility is a support burden. Every customer building on CAOS has their own audit, and they will ask what they inherit versus what they own. The line has to be documented precisely or it becomes a recurring sales-engineering and support cost — and a source of a customer’s audit failure if they assumed too much.

Sources

• SOC 2 — AICPA & CIMA — SOC reports are issued by CPAs; the five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy).
• SOC 2 Type 1 vs Type 2 — Secureframe — Type I is a point in time; Type II covers a period “typically 3-12 months”; a SOC 2 report is “an attestation issued by a qualified CPA firm or service auditor — not a pass/fail certification.”
• SOC 1 vs SOC 2 — Schellman — SOC 2 is an examination/report performed by a licensed CPA firm; exact definitions of the five Trust Services Criteria.
• CSA STAR — Cloud Security Alliance — the Cloud Controls Matrix; Level 1 self-assessment (CAIQ); Level 2 STAR Attestation (SOC 2-based, 1-year) and STAR Certification (ISO/IEC 27001-based, 3-year); public registry.
• ISO/IEC 27017 — Microsoft Compliance — a cloud code of practice adding seven cloud-specific controls; “audited once a year … as part of the certification process for ISO/IEC 27001.”
• ISO/IEC 27018 — Microsoft Compliance — ISO is “an independent nongovernmental organization and the world’s largest developer of voluntary international standards”; 27018 is an addendum to 27001 for PII in public clouds acting as processors; “an accredited third-party certification body audits … at least once a year”; BSI as the auditor.
• ISO/IEC 27701 — Microsoft Compliance — a Privacy Information Management System extending 27001; “Certification for ISO/IEC 27701 must be obtained as an extension of an ISO/IEC 27001 certification and can’t be obtained independently”; GDPR mapping.
• Implementing ISO 27001 — GRC Solutions — certification is performed by an accredited certification body, “accredited by a recognised national accreditation body and a member of the International Accreditation Forum,” not by ISO; ISO 27001 is the ISMS standard.
• HIPAA certification — The HIPAA Journal — “Certification is not a requirement of HIPAA. It is a voluntary process”; no government-endorsed HIPAA certification; compliance via training, documentation, and Business Associate Agreements; OCR investigations.
• HIPAA for Professionals — HHS — the HHS Office for Civil Rights administers and enforces the HIPAA Security and Privacy Rules. (Primary site; body blocked scriptless fetch — the enforcement and no-certification facts are corroborated by the HIPAA Journal source above.)
• What is GDPR — gdpr.eu — EU regulation; fines up to €20 million or 4% of global turnover.
• GDPR Article 42 — gdpr-info.eu — certification mechanisms are encouraged and “voluntary”; a certification “does not reduce the responsibility of the controller or the processor” and is “without prejudice to the tasks and powers of the supervisory authorities.”
• California Consumer Privacy Act (CCPA) — California Attorney General — enforced by the California Attorney General and the California Privacy Protection Agency; consumer rights to know, delete, correct, opt out, and limit.
• PCI Security Standards — PCI Security Standards Council — PCI DSS is maintained by the PCI SSC and applies to “all entities that store, process, or transmit cardholder data”; assessed by Qualified Security Assessors.
• FedRAMP — authorizing agencies and FedRAMP-recognized assessors (3PAOs) for US government cloud.
• Vanta Trust Center — “continuous, real-time evidence of your active controls — demonstrating trust that goes beyond a one-time compliance snapshot”; NDA-gated documents with automated access approval.
• AWS Artifact — “on-demand access to AWS and Independent Software Vendor (ISV) compliance reports in a self-service portal”; “auditor-issued reports, certifications, accreditations, and other third-party attestations”; on-demand agreement acceptance.
• Salesforce Compliance — a self-service compliance portal (“Compliance engineered for the Cloud”) over “a comprehensive set of compliance certifications and attestations,” with reports released through a Documents surface.
• CloudFiles Trust Center — a representative public trust center structured as compliance badges → a public/NDA-gated document vault → a grouped controls inventory → sub-processors → FAQs, with a continuous-monitoring “Monitored On” date.