Cloud security self-assessment
Aligned with the Cloud Security Alliance CAIQ v4 and Cloud Controls Matrix v4.
Published 14 October 2026; listed on the CSA STAR Registry (Level 1, self-assessment) since
17 October 2026. Describes the Haihtuva service as at release v60; the latest internal security review was
completed on 12 October 2026. We review and update this self-assessment at least annually, and after any material
change.
What this is, and is not. This is a self-assessment in the style of the Cloud Security Alliance's
STAR Level 1 programme, organised by the 17 domains of the Cloud Controls Matrix v4. It is our own honest statement
of what is in place, what is inherited from Microsoft Azure, and what is still in progress. It is not a
certification, an audit or a third-party attestation: no independent audit of Haihtuva has been performed yet, and
our SOC 2 readiness work is described plainly in the governance section below. A completed CAIQ v4 questionnaire,
and a criterion-by-criterion SOC 2 readiness mapping, are available to customers and prospects on request.
Scope. Haihtuva (haihtuva.com), a confidential two-sided AI due-diligence data room, operated by
Biotech Start-Up Management Oy (BSUM), Finland, on Microsoft Azure. One Azure confidential virtual machine per room;
room state in RAM only; deal documents remain in the customer's own storage and are read on demand.
How to read the status column.
Yes means the control operates today, almost always in product code or infrastructure.
Partial means the mechanism exists but a component or its recorded evidence is still being
put in place. No means we do not have it, said plainly, with the design fact or plan that
matters. Inherited means the control is provided by Microsoft Azure and covered by
Microsoft's own assurance reports.
1. Audit and assurance (A&A)
| Area | Status | Our answer |
|---|
| A&A-01, 02 | Partial | No independent audit or certification exists yet. We maintain a SOC 2 readiness mapping of 51 Trust Services criteria and an ISO 27001 Statement of Applicability, and completed an internal adversarial security review on 12 October 2026. An independent audit is planned once revenues cover it; we never claim certifications we do not hold. |
| A&A-03, 04 | Partial | Review findings are fixed or scheduled and recorded in release notes. A standing deficiency tracker with owners and due dates is being introduced as part of the SOC 2 Type I gap plan. |
| A&A-05, 06 | Yes | Independent verification customers get today: every room verifies the SHA-256 of its running package against the approved build digest, remote attestation of the confidential VM is shown in the room, and the room's audit hash chain is verified in its security report. |
2. Application and interface security (AIS)
| Area | Status | Our answer |
|---|
| AIS-01, 02 | Yes | Secure development policy; strict Content Security Policy (self-only scripts, frame-ancestors none), X-Frame-Options DENY, nosniff, HSTS, no-store caching, a global origin check on state-changing requests, CSRF tokens and honeypots on public forms. |
| AIS-03, 05 | Partial | An automated test suite including security regression tests is the release gate; the internal adversarial review of 12 October 2026 covered the application end to end. No external penetration test has been performed yet; one is planned. |
| AIS-06, 07 | Yes | A single model gateway is the only path from a room to any AI endpoint: text in, text out; tools, function calling and file APIs are rejected; per-provider field whitelists; the endpoint host and region are checked on every call; provider error codes only; keys are held per lane, in memory, never logged. |
| Output controls | Yes | Every AI output passes an output gate: a 25-word verbatim cap, copied-table removal, identifier redaction with check-digit validation (IBAN, Finnish HETU, US SSN), citation stripping for excluded files, and per-user per-file quote budgets in live Q&A. |
3. Business continuity and operational resilience (BCR)
| Area | Status | Our answer |
|---|
| BCR-01, 02 | Partial | A business continuity and backup policy exists. The decisive design fact: source documents always remain in the customer's own storage, so the loss of a room never loses the documents. No formal continuity exercise has been run and recorded yet. |
| BCR-08 | Yes | Each room keeps an encrypted recovery copy of its database (AES-256-GCM, key released only to the attested machine, never document bytes), on by default and customer-controllable, deleted at close. All infrastructure is redeployable from code. |
| BCR-09, 10 | No | No restore test or disaster-recovery exercise has been recorded yet, so we do not commit to recovery time or recovery point targets. Targets will be stated once a tested restore backs them. No uptime SLA unless an order form includes one; rooms are deliberately short-lived. |
4. Change control and configuration management (CCC)
| Area | Status | Our answer |
|---|
| CCC-01, 03 | Partial | All changes are in version control with release notes, behind an automated test suite as the release gate. A change-approval evidence trail beyond the repository history (recorded approvals per release) is being added; with a single developer, compensating controls below carry the design. |
| CCC-04, 09 | Yes | Deployment integrity is verifiable: the room checks the SHA-256 of its running package against the approved build digest at runtime and shows the result to customers. |
| Customer-visible change control | Yes | Any change to a live room's configuration, model, region, output rules or AI prompts invalidates the approved policy hash and pauses AI work until both sides approve the updated specification again. |
5. Cryptography, encryption and key management (CEK)
| Area | Status | Our answer |
|---|
| In transit | Yes | HTTPS everywhere with HSTS; TLS 1.2 minimum; FTPS and plain protocols off. |
| At rest | Yes | Room state is held in RAM rather than on disk; the room VM's OS disk uses confidential disk encryption; the only persisted artifact is the recovery copy, encrypted with AES-256-GCM. |
| In use | Yes | AMD SEV-SNP confidential VM memory encryption with secure boot and vTPM, verified by Microsoft Azure Attestation and shown in the room. |
| CEK-02, 03 | Yes | Azure Key Vault Premium with role-based access and purge protection. The room's key is released only through Secure Key Release to a machine that attestation confirms is a genuine confidential VM. Model credentials use per-secret grants and exist only in room memory, never in logs. |
| Key destruction | Yes | Each room has its own key, destroyed at close (crypto-shredding) together with the recovery copy; both sides receive a signed destruction receipt. Passwords and codes are hashed with scrypt and compared in constant time. |
6. Datacentre security (DCS)
| Area | Status | Our answer |
|---|
| DCS-01 to 15 | Inherited | Physical and environmental security is inherited from Microsoft Azure data centres (rooms in North Europe or East US 2; the operator console in Sweden Central). BSUM operates no data centre and holds no customer data on premises; Microsoft's SOC 2 and ISO assurance reports cover these controls. |
7. Data security and privacy lifecycle (DSP)
| Area | Status | Our answer |
|---|
| DSP-01, 03 | Yes | Data is minimal and classified by design: account data (name, work e-mail, organisation, authentication data); deal documents read on demand from the customer's own storage into room memory; questions, answers and reports created in the room; content-free audit and billing records. Logs never contain document content. |
| DSP-10, 19 | Yes | Data residency is checked at deploy and at room start (EU profile: North Europe; US profile: East US 2). Where a customer approves an AI model processed in the United States, this is disclosed in the model picker, the signed specification and the legal texts before any AI runs. |
| DSP-02, 16 | Yes | At close the room erases memory, deletes the recovery copy, destroys keys and issues a signed destruction receipt to both sides. Room machines also shut down in the evening, wiping RAM state. |
| GDPR roles | Yes | A GDPR Article 28 data processing agreement is part of our Terms (Schedule 1). BSUM is processor for customer content and controller only for the account, acceptance and security records described in the privacy notice. Supervisory authority: the Finnish Data Protection Ombudsman. We do not sell personal data. |
| AI training | Yes | Customer content is not used to train AI models (Terms; AI Use Notice). |
8. Governance, risk and compliance (GRC)
| Area | Status | Our answer |
|---|
| GRC-01, 06 | Partial | Ten information security policies are drafted (information security, access control, change management, incident response, business continuity and backup, data retention and disposal, risk assessment, vendor management, secure development, acceptable use); formal adoption sign-off and the first annual review cycle are in progress. |
| GRC-02 | Partial | A risk assessment policy defines the method and scoring; the first dated, recorded company-wide risk assessment is scheduled as part of the SOC 2 Type I gap plan. |
| GRC-05 | Yes | A named person is accountable for information security: Juhani Lahdenperä, founder. BSUM is a small founder-operated company and says so: there is no separate security department; security is enforced primarily through automation (attestation of every room, package digest verification, an automated test suite as release gate, content-free operations, both-side approval of each room's configuration). |
9. Human resources security (HRS)
| Area | Status | Our answer |
|---|
| HRS-01, 02 | No | No formal background-screening procedure exists yet. The design fact that matters: no BSUM role has plain-text access to customer documents through the service, because the room key is released only to an attested confidential machine. |
| HRS-04, 11 | Partial | Security awareness training and policy acknowledgement records are not yet formalised; both are in the SOC 2 gap plan with records to follow. |
| HRS-09 | Partial | The access control policy requires same-day access removal and secret rotation on termination. No leaver event has occurred yet, so no records exist; we state that rather than invent evidence. |
10. Identity and access management (IAM)
| Area | Status | Our answer |
|---|
| IAM-01, 14 | Yes | Two-factor authentication is mandatory for every room user and every operator: password plus authenticator app, no SMS. Sensitive operator actions require a fresh code. Account recovery uses an e-mail link plus a backup code or recovery key, resets 2FA, and is enumeration-safe and rate-limited. |
| IAM-04, 05 | Yes | Role-based access with least privilege: a centralised permission layer plus service-layer checks that re-derive side and lane from the database on every request. Sellers and each buyer work in separate lanes; buyer lanes are isolated from each other and from the seller; per-lane AI indexes apply allowed-file filters; view-only files are purged from indexes and citations. |
| IAM-07, 08 | Yes | Provisioning is invitation-only: hashed invitation codes that self-destruct after repeated failures, single-use hashed registration tokens, and customer administrators who suspend or remove their own users with immediate effect across all sessions. |
| Sessions | Yes | Signed revocable session cookies: HttpOnly, Secure, SameSite=Strict, 10-hour maximum, revoked on sign-out or suspension. |
| SSO | No | No SSO or SAML today; room sign-in is password plus mandatory authenticator code. |
| IAM-10 | Partial | Quarterly internal access reviews are required by policy; the first recorded review is scheduled. The production access list is very small by construction. |
11. Interoperability and portability (IPY)
| Area | Status | Our answer |
|---|
| IPY-01, 03 | Yes | There is no lock-in on documents because they never leave the customer's own storage. Reports, risk analyses and Q&A export to PDF, Word, Excel and PowerPoint; the destruction receipt is a signed, portable record of closure. |
| IPY-02 | Partial | Storage is linked read-only through standard interfaces (SharePoint and OneDrive, Google Drive, Box, Dropbox, including folders shared with the seller). There is no public API yet. |
12. Infrastructure and virtualisation security (IVS)
| Area | Status | Our answer |
|---|
| IVS-01, 02 | Yes | Tenant isolation is physical at the data layer: one confidential virtual machine per room, no shared room database. The machine attests itself before the key is released. |
| IVS-03, 04 | Partial | Network: inbound 443 only from allowlisted sources, deny-all default, SSH closed by default; the operator console is IP-restricted with TLS 1.2 minimum. Known gap, stated plainly: room VM outbound traffic on 443 is not yet restricted to a named-host allowlist; that hardening is planned. |
| Hardening | Yes | Secure boot and vTPM; RAM filesystem mounted noexec, nosuid, nodev with swap off; systemd hardening (ProtectSystem strict, NoNewPrivileges, PrivateTmp, dedicated user); boot diagnostics off. |
| Capacity | Partial | A memory guard triggers a controlled resize with a recovery-save precondition; formal capacity thresholds and review records are being documented. |
13. Logging and monitoring (LOG)
| Area | Status | Our answer |
|---|
| LOG-01, 05 | Yes | Every room keeps an append-only, hash-chained, content-free audit trail (sign-ins, failures, views, downloads, approvals, AI-use events). The chain is verified in the room's security report. Customers see their own logs: a per-user access log, side-wide logs for administrators. |
| LOG-02, 04 | Yes | Logs are tamper-evident through the SHA-256 hash chain, and privacy-protective by construction: the web server access log is disabled so no URLs or addresses leak to platform logs, and operator signals carry room, rule, severity and time only. |
| LOG-03, 07 | Partial | In-product misuse detection alerts the affected side's own administrators; layered rate limits give enumeration-safe responses; copy measurement raises alerts. There is no 24/7 security operations centre: monitoring is founder-operated with automation, alerting by e-mail, and the formal alert-review routine is being documented. We state this plainly rather than overstate coverage. |
14. Security incident management and forensics (SEF)
| Area | Status | Our answer |
|---|
| SEF-01, 02 | Partial | An incident response policy with severity levels, roles and a seven-step procedure exists; formal adoption and a first tabletop exercise are scheduled and have not yet been run. |
| SEF-03 | Yes | Containment capabilities operate today: user, side and room suspension; an emergency stop that requires a typed room identifier plus a fresh authenticator code; session revocation; secret rotation; seller storage unlink. |
| SEF-05 | Yes | Personal data breaches are notified without undue delay under the data processing agreement, and to the Finnish Data Protection Ombudsman within 72 hours where required. |
| SEF-06 | Yes | Forensic records are preserved until a matter is closed: the hash-chained audit trail, signed records and content-free signals. Incident records never contain customer content. |
15. Supply chain, transparency and accountability (STA)
| Area | Status | Our answer |
|---|
| STA-01, 07 | Yes | The sub-processor list is short and published: Microsoft (Azure hosting, confidential computing, key management, attestation, e-mail, AI model hosting) and Stripe Payments Europe (card payments). Customers are notified of changes with a right to object. |
| STA-05 | Partial | A vendor management policy with a tiered register exists; the first recorded annual review of Microsoft's and Stripe's assurance reports is scheduled. |
| STA-09, 13 | Partial | Software supply chain: the room verifies its package digest at runtime; OCR language artifacts are hash-pinned and production runs offline from model hubs. Full dependency pinning with hash enforcement at install is designed and scheduled for an upcoming release. Open-source components are permissively licensed (MIT, BSD, Apache 2.0) and listed. |
16. Threat and vulnerability management (TVM)
| Area | Status | Our answer |
|---|
| TVM-01, 07 | Partial | Microsoft Defender for Cloud alerts at the subscription level; automated dependency scanning is in the gap plan and not yet in place. |
| Penetration testing | No | No external penetration test has been performed yet. An internal adversarial code review was completed on 12 October 2026 with findings fixed or scheduled; an independent external test is planned once revenues allow. We say which is which. |
| TVM-03 | Yes | Patching by rebuild: room machines are short-lived and rebuilt from the current image; the operator console is redeployed from code rather than patched in place. |
| Disclosure | Yes | We accept vulnerability reports at the contact below and handle them under the incident response policy, with a published responsible-disclosure request on our trust page. |
17. Universal endpoint management (UEM)
| Area | Status | Our answer |
|---|
| UEM-01, 05 | Partial | BSUM devices follow the acceptable use policy (full-disk encryption, screen lock, endpoint protection); device-level verification records are being formalised. |
| Design limit on endpoints | Yes | Customer documents never reach BSUM endpoints through the service: the operator console is content-free by design, and documents exist in plain text only inside the attested room machine. |
Summary
Where Haihtuva's design carries the control in code and infrastructure, the answer above is Yes: cryptography and
key release, access control and lane isolation, logging, output controls, disposal and destruction receipts. Where
the answer is Partial or No, the gap is almost always organisational evidence: adopted policies, recorded reviews,
and exercised procedures. Those are the same items our SOC 2 Type I plan closes, in order, before an independent
audit. We would rather show you exactly what is in place and what is planned than claim a certification we do not
have.
Questions about this self-assessment, requests for the completed CAIQ v4 questionnaire or the SOC 2 readiness
mapping: juhani.lahdenpera@bsum.fi.
Biotech Start-Up Management Oy, Business ID 2574531-6, Vanhatie 70, 86100 Pyhäjoki, Finland.