Trust · Vendor questionnaire
Security questionnaire — Mltitude.
Last updated · 2026-05-15
This page is the questionnaire. Most of what your vendor-risk team puts in a spreadsheet is answered below — search the page or print it. If your team has a specific form they want returned (CAIQ, SIG, custom), email security@edothsoft.com and we'll fill it in within ten business days. Each answer links back to the source document so you can verify the underlying commitment.
About this document
Structure follows the Shared Assessments SIG Lite domains. Where a question is not in scope for Mltitude (e.g. FedRAMP, HIPAA), we say so. Where our position is "not certified", we say so plainly rather than gesturing at a future intent.
A. Risk Assessment & Treatment
A.1Is there a formal information-security policy approved by management?
Yes. Our security policy is maintained internally; the public-facing version is at /security. Material changes are reviewed by the responsible director annually.
A.2Is there a risk-assessment process for the Service and its sub-processors?
Yes. Sub-processors are reviewed before onboarding and re-reviewed annually. Material changes to the sub-processor list are announced 30 days in advance — see /sub-processors.
A.3Is there a documented information-security-management programme?
Yes, informally documented. We are not ISO 27001 certified today and do not maintain an ISMS to that standard — see /trust/compliance.
B. Security Policy
B.1Are policies reviewed at least annually?
Yes.
B.2Is there an acceptable-use policy that personnel must acknowledge?
All Mltitude personnel agree to internal information-handling rules as part of onboarding. Customer-side acceptable use is published at /aup.
B.3Is there a public security-disclosure policy?
Yes — see /trust/responsible-disclosure and the RFC 9116 file at /.well-known/security.txt.
C. Organisational Security
C.1Is there a named individual responsible for information security?
Yes. The legal entity Edoth Electronics retains responsibility for security; the Mltitude product lead acts as the named contact. Reach the function at security@edothsoft.com.
C.2Is there a named Data Protection Officer?
Yes. Contact dpo@edothsoft.com.
C.3Background checks on personnel with privileged access?
Right-to-work checks are performed at hire. Formal pre-employment background checks (criminal record, credit history) are not run today for our small team.
C.4Security training for personnel?
Engineers receive informal onboarding on the company's data-handling rules and the published policies. We do not maintain a tracked, annually-tested training programme.
D. Asset & Information Management
D.1Is customer data classified?
Yes. Customer content is treated as confidential. Operational metadata (logs, audit events) is treated as restricted-internal. We do not handle special-category personal data (Art. 9 GDPR) by default — see /trust/compliance.
D.2Is customer data encrypted at rest?
Yes. AES-256 at the storage layer (database, file storage, backups).
D.3Is customer data encrypted in transit?
Yes. TLS 1.2+ everywhere; TLS 1.3 preferred. HSTS is enforced.
D.4Where is customer data hosted?
European Union (Hetzner, Germany — Falkenstein and Nuremberg). Customer content is not replicated outside the EU. Model-provider calls (OpenAI) transit to US infrastructure under SCCs; outputs return to the EU.
D.5How long is customer data retained?
For the life of the account, plus 30 days post-deletion in active systems and 90 days in encrypted backups. See /trust/data-governance, Question 10.
D.6Can customer data be exported on demand?
Yes. The org admin can export documents and account data. Data-subject erasure requests at dpo@edothsoft.com are honoured within 30 days.
E. Identity & Access Management
E.1How are end users authenticated?
Email + password, with optional OAuth (Google) sign-in. Passwords are hashed with bcrypt (12 rounds, by default). Session tokens are JWT signed with HS256; refresh on the 7-day window. Multi-factor authentication is on the roadmap but not yet generally available.
E.2Is role-based access enforced?
Yes. Five roles today: super_admin (Mltitude-only), org_admin (customer-side), org_user (member), trainer (XLSim author), trainee (XLSim subject). Org-scoped row-level isolation is enforced server-side on every API call.
E.3How is privileged Mltitude personnel access managed?
Production SSH access is keys-only, no passwords. Database access is via short-lived credentials. Application-level access to a specific customer tenant by Mltitude personnel requires support context and is auditable in
audit_events.E.4Is SSO (SAML/OIDC) supported for enterprise customers?
Not at present. SAML/OIDC SSO is a frequent enterprise ask; we will add it ahead of publishing a public timeline when an FSI customer commits.
F. Network Security
F.1Is the production environment isolated from corporate / staging?
Yes. Production runs on dedicated hosts on private networks. Corporate laptops have no production access except through declared engineer SSH keys.
F.2Is the application behind a WAF / DDoS protection?
Yes. Cloudflare provides TLS termination, DDoS mitigation, and basic WAF rules at the edge.
F.3Are external penetration tests performed?
Not on a published cadence today. We will share a redacted report when the next test completes.
G. Application Security
G.1Is code reviewed before merge to production?
Yes. Every change is reviewed via pull request; deploys are triggered from main branch only.
G.2Are dependencies scanned for vulnerabilities?
Yes, continuously via GitHub Dependabot. Critical CVEs are patched within 7 days.
G.3Is static / dynamic application security testing performed?
Lightweight: ESLint security rules and dependency scanning today. No commercial SAST suite. We are open to adding one when justified by deal-size and roadmap.
G.4OWASP Top 10 controls?
Standard controls in place: parameterised queries (no string concatenation against the DB), Helmet HTTP headers, rate limiting on auth and search endpoints, CSP not enabled yet (planned), CSRF protection via SameSite cookies + auth-header tokens.
H. Cryptography
H.1What cryptographic algorithms are used?
AES-256 for data at rest. TLS 1.2+ for transit (1.3 preferred). bcrypt for password hashing. HS256 for JWT signing (with secret rotation on demand).
H.2Are cryptographic keys managed in a KMS?
Application secrets are stored as environment variables on production hosts, mounted at deploy time. We do not run a dedicated KMS today; secret rotation is manual and documented.
I. Operations Security
I.1Are systems monitored for security events?
Application errors via Sentry (EU region). Authentication failures and abnormal access patterns are logged for review. Sub-processors (Hetzner, Cloudflare) run their own platform-level monitoring.
I.2What logs are retained, for how long?
Application audit log: life of the account, exportable by org admin. Authentication log: 90 days. Generation log (model usage metadata, no prompt/output content): 180 days. Error monitoring: Sentry's default 90 days. See /trust/data-governance, Question 9.
I.3Are backups taken and tested?
Yes. Daily encrypted snapshots of the database and file storage, retained for 30 rolling days, kept in the same region. Restore drills are performed quarterly.
J. Incident Management
J.1Is there a documented incident-response plan?
Yes. A short, practical runbook covering detection, triage, containment, customer notification, root-cause analysis, and post-mortem.
J.2What is the breach notification SLA?
We notify affected customers of a confirmed security incident without undue delay and in any case within 72 hours, per Article 33 GDPR. See the DPA, Section 6.
J.3Who is notified — and how?
The named org admin on the customer account is the contact for incident notification. We use email to that admin; for severe incidents, a separate communication is sent directly to the customer's security contact if one has been provided to us.
K. Business Continuity & Disaster Recovery
K.1What is the RPO/RTO?
RPO: 24 hours (driven by daily backup cadence). RTO: 8 hours for the application layer, 24 hours for full restoration including model-provider configuration. These are targets, not contractual SLAs unless agreed in writing.
K.2Is there a published service status / uptime page?
Yes — /status. We aim for 99.5% monthly uptime; we do not currently offer credit-backed uptime SLAs by default.
L. Compliance
L.1What regulatory frameworks does the Service comply with?
GDPR (EU 2016/679) and UK GDPR. Not SOC 2, ISO 27001, or HIPAA certified today. See /trust/compliance.
L.2Is a signable DPA available?
Yes — /dpa. Includes Standard Contractual Clauses by reference for third-country transfers.
L.3Is customer content used to train models?
No. Briefs, documents, modules, decks, and learner data are never used for model training — by Mltitude or by sub-processors. See /trust/data-governance, Question 3.
M. Models & Data Flow
M.1Which model providers are used and for what?
See /sub-processors for the current list with commencement dates. Today: OpenAI for text generation (US, zero-retention) and Google for image generation (Imagen) and text-to-speech.
M.2What customer data is sent in prompts?
Only the brief and explicit form values the user has entered. No authenticated user identifiers, no account metadata, no internal org identifiers. See /trust/data-governance, Question 2.
M.3Are outputs reviewed by humans before publication?
The Service positions every generated output as a draft that the end-user reviews and edits before publishing or exporting. The trainer / L&D author is the accountable reviewer.
M.4Is automated decision-making used that affects individuals (Art. 22 GDPR)?
XLSim assessment scoring is automated and deterministic against a rubric authored or reviewed by a human trainer. Trainees may ask their trainer or org admin to review a score; trainers can override. We do not perform automated profiling that creates legal effects under Article 22.
Format and updates
This page is the canonical Mltitude vendor-security questionnaire. We update it whenever an underlying policy or control changes; the "Last updated" date at the top of the page reflects the current version. For an offline copy, print the page or save as PDF from your browser.
If your procurement team requires a specific format (CAIQ, SIG, custom spreadsheet), send it to security@edothsoft.com and we'll fill it in within ten business days.