Written for the Person Reviewing the Vendor
If you are running a security review or a due diligence questionnaire, this page is for you. It states what is architectural, what is configurable, and what we do not claim.
Security by design, and what that actually means
Security is an architectural decision taken before the first line of code, not a feature added when a buyer asks. The difference matters to you because a property of the architecture cannot be switched off by a later configuration change, and a bolted-on control can.
- Tenant isolation at the storage layer. A database per tenant and a blob container per tenant, not a shared table with a tenant column. A query cannot cross a boundary that does not exist in the schema.
- Encryption in transit and at rest. Standard, and the least interesting item on this list.
- Least privilege by default. Access is granted per role, and the absence of a grant is the default state.
- Deprovisioning is automated. When a tenant cancels, the container stops and is removed, the database is deleted, and the blob container is deleted. Leftover data is a breach waiting for a date.
- Observability is self-hosted. Metrics, logs and traces do not leave the perimeter in order to be read.
We follow the ISO/IEC 27001 and 27002 recommendations. We do not hold the certification, and we will not imply that we do.
Where your data lives, and who can be compelled to hand it over
Residency is not only about where a server is. Under the United States CLOUD Act, a United States provider can be compelled to produce data it controls regardless of where the servers physically sit. For a buyer under European rules, that is the reason a European region on an American provider does not always settle the question.
Private AI is the answer to that specific problem. The model runs on infrastructure you control, and no document is sent to a third-party API, so there is no third party to compel.
Deployment models
| Model | Isolation | Chosen when |
|---|---|---|
| Shared multi-tenant SaaS | Per tenant, at database and storage level | The default, where policy allows a shared platform |
| Dedicated database | Same schema, isolated data and backups | Policy requires the data to sit alone |
| On-premises | Entirely inside your perimeter, including the AI | Data cannot leave, by regulation or by policy |
Regulatory scope
We design for European Union and United States frameworks, and for other local legislation where a product answers to it. Naming a framework here means the architecture is built to satisfy it, not that a certificate exists.
- GDPR. Lawful basis, data minimisation, subject rights, and a signable processing agreement under Article 28 where we act as a subprocessor.
- EU AI Act. Where a product falls in scope, the classification drives the architecture rather than following it.
- NIS2, DORA, Cyber Resilience Act. Applied where a client's sector brings them into scope.
- CCPA and CPRA. For products serving California residents.
- eIDAS. Where a record needs a qualified timestamp rather than only an internal one.
- Other local legislation. Products we work on also answer to national regulators outside these frameworks. The approach does not change: the rules become versioned data. Which regimes those are is engagement detail, and we name them to a client rather than in public.
Sector regimes, which sit on top
Horizontal rules are rarely the hard part. A sector supervisor adds its own requirements above them, and those are where the detail bites.
| Sector | Frameworks we design for | What it usually drives |
|---|---|---|
| Banking and payments | DORA, PSD2, EBA guidelines on ICT and security risk management, PCI DSS, and in the United States GLBA and FFIEC guidance | Operational resilience, incident reporting windows, third-party risk registers, strong customer authentication, and evidence that an outsourced component can be exited |
| Insurance | Solvency II and EIOPA guidance | Governance of outsourced systems, record retention, and complaint handling with deadlines that differ from the banking ones |
| Health | EU MDR where software is a device, the European Health Data Space, and HIPAA in the United States | Classification before architecture, audit trails on clinical records, and residency that a hospital's own policy can verify |
| Public sector | eIDAS, national procurement rules, and accessibility requirements | Qualified timestamps, exit clauses, and proof that a record was not altered after publication |
This table is the clearest argument for the one architectural decision that does the work underneath all of it: regulatory rules are versioned data, never code. A banking supervisor and an insurance supervisor of the same market will impose the same obligation with different arithmetic: one counts a deadline in working days, the other in calendar days. Both are correct in their own sector. A product that serves both and hardcodes either is wrong for half its users, permanently, and a configuration screen does not fix it because the rule sits in the code path rather than in the data. Treating the rules as data is what makes a new regime, or a change to an existing one, a data change instead of a release.
Designing for a framework means the architecture is built to satisfy it. It does not mean a certificate exists, and we will not let the two be confused.
Immutability, and what a ledger is for here
Security keeps the wrong people out. Immutability proves that what was written was not changed afterwards, including by the right people. For a vote, a board resolution or a share transfer, that second guarantee is the one that settles a dispute.
We use closed, permissioned ledgers: known participants, a private network, energy-efficient consensus. No cryptocurrency, no tokens, no public chain. If someone offers you a blockchain and cannot tell you who the participants are, they are selling you something else.
What we will not claim
- We do not hold ISO/IEC 27001 certification.
- We do not hold a SOC 2 report.
- We are not a hosting provider, and we do not run your production on our account.
- We do not publish client names without the client asking us to.
A security questionnaire gets the legal and factual answers, not the language on this page. If something here is not precise enough for your review, ask and we will answer it directly.
Questions we get asked
-
Q1. Where does our data live?
Wherever your policy requires. Three deployment models: shared multi-tenant SaaS with isolation at database and storage level, a dedicated database on the same schema, or fully on-premises inside your own perimeter including the AI.
-
Q2. Are you ISO/IEC 27001 or SOC 2 certified?
No. We follow the ISO/IEC 27001 and 27002 recommendations and we hold neither certification, and we will not imply otherwise. If your process requires a certified supplier, say so early and we will tell you whether we can meet it.
-
Q3. Will you sign a data processing agreement?
Yes. Where we act as a processor or subprocessor, a GDPR Article 28 agreement is part of the engagement rather than a negotiation at the end of it.
-
Q4. Our cloud provider has a European region. Why does the CLOUD Act still matter?
Because it follows the provider, not the servers. A United States provider can be compelled to produce data it controls regardless of where that data physically sits. Running the model on infrastructure you control removes the third party that could be compelled.
-
Q5. Do you have access to our production data?
No. We are not a hosting provider and we do not run your production. Where an engagement needs access to diagnose something, it is scoped, time-boxed and logged.
-
Q6. What happens to the guarantees when the engagement ends?
The architecture stays, because it was never bolted on. The Secured by Bitwise Lab mark comes off, and its removal is written into the contract along with what happens on termination.