I — Datum
Compliance & Security
II — Data Protection
Encryption in transit: All traffic to SVEND is served over TLS. Connections are terminated at the network edge and no application content crosses the public network unencrypted.
Encryption at rest: Sensitive fields are encrypted at the application layer before they reach the database, using authenticated symmetric encryption. Encryption keys are held outside the database.
Your data stays yours: Process data you upload for analysis is used only to produce the analysis you requested. We do not sell it, share it, or use it to train models.
III — Tenant Isolation
Each organization's data is isolated at the database layer with PostgreSQL row-level security. Isolation is enforced by the database on every query — not only by application code — so one tenant's records are never reachable from another tenant's session.
IV — Access & Authentication
Password security: Passwords are hashed with Argon2, a memory-hard algorithm designed to resist offline cracking. We never store or log passwords in plaintext.
Two-factor authentication: Time-based one-time-password (TOTP) two-factor authentication is available on every account and works with any standard authenticator app.
Brute-force protection: Repeated failed sign-in attempts are rate-limited and locked out, and both password and second-factor failures feed the same protection.
V — Audit & Integrity
Hash chaining links each entry to the one before it, so a record is tamper-evident: altering any entry invalidates every entry after it. Two things use it, and they are at different stages.
Internal compliance registers are chained today. Each generation of the Technology Control Plan is recorded in a chained attestation log, and releases of controlled data are recorded in a chained register (section VIII). Both are verified independently of the process that writes them.
A customer-facing audit trail over your own analytical records is in build and is not yet available on any account. The machinery exists; what does not yet exist is a route by which you could verify your own chain, and an unverifiable trail is not worth offering. One honest limit applies to both: a chain detects alteration but cannot, by itself, detect deletion of its newest entries — that needs a signed anchor over the tip, which is not yet in place.
VI — Data Ownership & Portability
Every paid plan includes unlimited data export — your analyses and records leave in open formats whenever you want them. On account closure, data remains available for export for 90 days, after which it is deleted. You may request deletion at any time.
VII — Provenance & Architecture
Every claim in this section is a property of the code rather than a policy, which means each one can be checked. They are here because “enterprise-grade” is unfalsifiable and therefore worth nothing to a careful reader.
Capability is derived, not declared. The number of analyses this platform advertises is computed from the solver registry when the page is requested, not typed into the page. An analysis that is catalogued but whose solver is not registered renders as standby and cannot appear as available — today 165 of 187 are powered and the remaining 22 say so on the row. Two test sweeps assert that every registered analysis actually computes against the production engine, so the marketing figure and the running product cannot disagree.
One door to the engine. The computation lives in a separate engine, and this application reaches it through exactly one module and one namespace. It never imports an engine package directly. That is enforced by a test with an empty allowlist — there are no exceptions, and adding one fails the build rather than being reviewed.
Results arrive on one contract, and nothing is filled in on the way out. Every analysis returns the same structure: the statistics, the assumptions behind them, diagnostics, an evidence grade, the charts, and the engine's own verdict. A verdict is never derived by the page that displays it. Where a solver leaves a field empty the interface shows it empty, because a renderer that invents a confidence or a caveat is producing a number nobody computed.
Numbers carry their reference. Statistical results are checked against values computed independently in R, and the calibration certificate is published in full — including the packages that currently fail. An accuracy claim that cannot show you its own failures is not evidence.
Improvement work carries its origin. An entry in a vandrebok records which value stream map and which kaizen burst produced it. That pair is the entry's identity, so promoting the same finding twice returns the existing entry instead of creating a second one, and an improvement can always be traced back to the observation that started it.
Tenant isolation is enforced by the database. Separation is a Postgres row-level security policy, set per transaction, not a filter the application remembers to add. A query that forgets its scope returns nothing rather than someone else's data.
Configuration is audited daily, and the findings are counted. An automated suite checks platform configuration against a control catalog every day and records what it finds against a ceiling that only moves deliberately. Accepting a risk requires naming an owner and an expiry.
VIII — Export Control
Customers in regulated manufacturing sometimes hold process data that falls under U.S. export control — the International Traffic in Arms Regulations (22 CFR 120–130), the Export Administration Regulations, or Controlled Unclassified Information. SVEND has handling for that. What follows is what is built and what is not, because a compliance page that only lists capabilities is telling you half of something.
An account records an export-control determination. The regime, the basis for the decision, the date, and the person accountable for it. The default is unreviewed, which is deliberately not the same value as not controlled — the obligation is to know, so silence is a finding rather than a pass. An account marked controlled is handled as controlled throughout, rather than the decision being made again per record.
Releases of controlled data are recorded in a hash-chained register. What was released, to whom, when, under what authority, whether it was authorised, and who recorded it. Entries are append-only — a correction is a new entry, because the register is a history rather than a state — and removing an account cannot erase the record that its data was disclosed. The register is written by the application and verified independently by the audit fleet, because a chain whose only verifier is its own writer proves very little.
Access to a marked account is accounted for — who, when, which request, and what the response was, since an attempt that was refused belongs in the record as much as one that was served. Kept outside the operational log, which is size-managed and would eventually delete it.
Sanctioned destinations are named explicitly rather than left implicit, in two tiers: places where providing the service at all is prohibited, and places where technical data specifically may not go. Prospective sponsored organizations are screened against the U.S. Consolidated Screening List — the SDN list, the BIS Entity List, Denied Persons, and ITAR Debarred parties — with the date of the list and the exact name searched kept as part of the record.
The Technology Control Plan is generated from a live audit sweep, not written by hand. Each control cites the checks behind it, so a control cannot claim more than the system actually does, and a control with nothing verifying it renders as a gap rather than being quietly omitted.
Currently failing: Identification of technical data; Encryption carve-out for stored technical data; Prohibited destinations; U.S.-person access control; Need-to-know segregation; No unauthorized third-party disclosure; Disclosure log; Export-control awareness training; Violation identification and voluntary disclosure; Records retention; Physical and host security.
What SVEND does not claim
SVEND is not certified against any export-control standard, is not registered with the Directorate of Defense Trade Controls, and holds no facility security clearance. Classified information must never be uploaded. The Technology Control Plan is a readiness document and not a legal determination; whether any particular dataset constitutes technical data is a question for an export attorney and is not answered by this platform.
Application-layer field encryption is not a FIPS 140-2 validated module. The construction is sound — authenticated symmetric encryption with keys held outside the database — but the validation box is not ticked, which matters to anyone relying on the encryption carve-out at 22 CFR 120.54(a)(5) in a formal submission.
Geographic restriction is a speed bump, not a control. It is defeated by a commercial VPN, and country-level checks cannot express sub-national sanctions — a region may be embargoed while the country containing it is not. Denied-party screening surfaces candidates for a person to judge; it never returns a clearance, because names reach these lists through inconsistent transliteration and an automated “no match” would be an assurance the search cannot support.
Access accounting records requests, not records. It answers who was in an account and when, not which individual dataset they opened. And it fails open: a failure to write an access record raises an alert and lets the request through, because a control that takes a customer’s application offline is one that gets switched off.
Everything above is checkable. If you are evaluating SVEND for regulated work and want the Technology Control Plan itself, including the controls currently failing, ask for it here.
IX — Frameworks
SVEND follows SOC 2 Type II aligned practices and honors GDPR and CCPA data-subject rights. For a current compliance summary or to raise a security question, write to us here.