Sixteen questions from CAIQ v4, the questionnaire enterprise security teams already send, answered the way your team answers them once Sovereign Mode carries your protected data path. The answers are written in the vendor’s voice: “we” means the vendor.
Scope note: these answers describe Sovereign Mode as designed, not what is live today. They cover the protected data path — the crown-jewel data. Systems outside that path keep their existing security-review scope.
KEYS
CEK-08.1
Are CSPs providing CSCs with the capacity to manage their own data encryption keys?
Yes, and further. The customer does not manage a key we also hold; the customer holds the only key. There is no vendor-side key to manage, escrow, or compel.
CEK-11.1
Are private keys provisioned for a unique purpose managed, and is cryptography secret?
Yes. The key that governs a sovereign deployment is provisioned per customer and per purpose, held by the customer as a passkey-native credential. We never possess it.
CEK-13.1
Are cryptographic keys revoked and removed before the end of the established cryptoperiod (when a key is compromised, or an entity is no longer part of the organization) per defined, implemented, and evaluated processes, procedures, and technical measures to include legal and regulatory requirement provisions?
Yes, by the customer. Revocation executes against the customer’s own key policy and takes effect immediately. A revoked key ends our ability to process, not just our permission.
CEK-03.1
Are data at-rest and in-transit cryptographically protected using cryptographic libraries certified to approved standards?
Yes, standard. At-rest and in-transit protection use certified libraries, as on any serious stack. Sovereign Mode adds the state this question does not ask about: data in use, decrypting only inside the attested environment.
DATA
DSP-02.1
Are industry-accepted methods applied for secure data disposal from storage media so information is not recoverable by any forensic means?
Disposal is key destruction. Anything kept on this path exists only under the customer’s key, so disposal is the customer destroying that key, which is final by construction and independent of storage media.
DSP-05.1
Is data flow documentation created to identify what data is processed and where it is stored and transmitted?
Yes, generated rather than written. Every deployment produces an attestation quote and a measured compose hash, checked against the on-chain allowlist — naming what image ran, in which attested environment, and under whose approval. The data-flow record is produced by the system itself, and your reviewer can check it.
DSP-10.1
Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope (as permitted by respective laws and regulations)?
Yes, enforced in code. Content moves encrypted under the customer’s key and decrypts only inside the sealed environment. Scope is a policy the environment enforces, not a clause.
DSP-18.1
Does the CSP have in place, and describe to CSCs, the procedure to manage and respond to requests for disclosure of Personal Data by Law Enforcement Authorities according to applicable laws and regulations?
Yes, and the procedure is short: content cannot be produced. We cannot read sovereign content, so no order served on us yields it. Deployment metadata is the honest exception, and the attestation and on-chain record define exactly what that is.
DSP-19.1
Are processes, procedures, and technical measures defined and implemented to specify and document physical data locations, including locales where data is processed or backed up?
Yes, per deployment. The processing venue is named in the attestation: hosted, the customer’s cloud, or the customer’s hardware.
DSP-04.1
Is data classified according to type and sensitivity levels?
Yes, and the customer sets the dial. Data classes route by the customer’s policy: crown-jewel classes run sovereign, routine classes run on the standard stack.
ACCESS
IAM-05.1
Is the least privilege principle employed when implementing information system access?
On this path, no privilege. The minimum privilege for content access is a key no role at our company holds. Least privilege elsewhere follows standard practice.
IAM-09.1
Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated such that administrative data access, encryption, key management capabilities, and logging capabilities are distinct and separate?
Architecturally. Data access, key custody, and logging are not separate roles; they are separate parties. Content access requires the customer’s key, and the log is a public ledger neither of us can edit.
IAM-11.1
Are processes and procedures for customers to participate, where applicable, in granting access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles defined, implemented and evaluated?
Yes, literally. Support access to a sovereign session exists only by customer-key grant, is scoped to that session, expires, and lands on the record.
IAM-14.1
Are processes, procedures, and technical measures for authenticating access to systems, application, and data assets including multifactor authentication for a least-privileged user and sensitive data access defined, implemented, and evaluated?
Yes, standard, plus. Standard MFA governs our systems. The customer’s sovereign key is a passkey, phishing-resistant by construction.
AUDIT
LOG-02.1
Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure audit log security and retention?
Yes, on an append-only public ledger. The on-chain record of approved measurements cannot be altered or quietly deleted: not by us, not by the customer, not by an attacker holding our credentials.
LOG-09.1
Does the information system protect audit records from unauthorized access, modification, and deletion?
Yes, beyond the requirement. The question asks whether we protect records from modification. Our answer is that modification is not possible for anyone, including us.
Portions quoted from the Consensus Assessments Initiative Questionnaire (CAIQ) v4, © 2023 Cloud Security Alliance. IP terms. Answers describe Sovereign Mode as designed, not what is live today.
REQUEST A BRIEFING
If a questionnaire like this is sitting in your deal thread right now, bring it. Thirty minutes: we map Sovereign Mode onto your product and draft your answers with you.
Request a briefing