Security & Compliance
Before signing, companies usually send a vendor security questionnaire. This page answers it up front — and lists only what is actually in place. What is not in place has its own section, with how it is offset.
1 · Client data
Before the client shares internal documents or real data, both sides sign a non-disclosure agreement. If the project touches personal data, a data processing agreement (DPA) is signed too, setting roles: the client is the Controller, the studio the Processor.
Development and testing use synthetic or anonymised data. Real data is used only when genuinely needed (migration, a bug that only reproduces on real data), only the necessary subset, and with the client’s written consent.
The studio has one principal engineer. By default only that person accesses project data and systems. Any additional person (a contractor) needs prior client approval, signs their own NDA and gets access scoped to their task only; access is revoked when the task ends.
At contract end: data is handed back in the agreed format, the studio’s copies are deleted (backups included), keys and accounts are revoked, and a data-deletion record is signed with the client. Anything the law requires to be retained is listed explicitly in that record.
Law on Personal Data Protection No. 91/2025/QH15
In force 1 Jan 2026. Controller / Processor roles; data-subject rights, including the right to deletion.
Decree 356/2025/ND-CP
Implements the PDP Law, in force 1 Jan 2026, replacing Decree 13/2023/ND-CP. A valid deletion request: respond within 2 working days, complete within 20 days.
Cybersecurity Law 2018 (24/2018/QH14) and current implementing or superseding instruments
Relevant to data-retention, information-provision and system-protection duties — the exact scope depends on the client’s type of system.
This page describes how the studio works. It is NOT legal advice. The specific legal obligations of each project should be confirmed by the client’s counsel.
2 · Technical practice
Access & secrets
Network & transport
Data & operations
Release & incidents
3 · Sub-processors
VPS (máy chủ thuê) / Rented VPS
Runs the application, PostgreSQL database, local backups
Data: All application data
Cloudflare
DNS, proxy/CDN in front of the site; R2 for uploaded files and off-server backups
Data: HTTPS traffic in transit; user-uploaded files
GitHub
Source code hosting, CI and operational jobs
Data: Source code; no user data
modelapi.vn
Primary LLM gateway for AI features
Data: Content users send to AI features (prompts, extracted text of attachments)
rambo.ai.vn
Secondary LLM gateway, for the coding assistant and some interactive AI tasks
Data: Content sent to those features
Groq
Some voice / auxiliary AI features
Data: Audio or text sent to that feature
Resend
Transactional email (verification, password reset, notices)
Data: Email address, message content
PayOS · VNPay
Payment gateways
Data: Order ID, amount; the studio stores no card numbers
Sentry
Error tracking (when enabled)
Data: Error traces stripped of cookies, auth headers and bodies
4 · AI & data
In a client product only the AI features written into the spec send data to a model, and only the data that feature needs. A project without AI sends nothing to an LLM.
AI features are built to be switched off by configuration, without code changes. On the studio’s own site all background AI jobs are OFF by default, with per-user token caps and a daily spend cap.
The studio does not use client data to train any model. Whether an LLM gateway provider retains or uses data depends on that provider’s policy — the studio cannot guarantee it on their behalf. So for sensitive data, the LLM provider is chosen in the DPA, or the client’s own AI account/infrastructure is used.
When data must not leave the machine or internal network: open models can run on the client’s hardware with llama.cpp. The studio already ships this in its own desktop app (offline AI mode) — the trade-off is a smaller model with lower quality than cloud models.
Client documents, source code and data go into an AI tool only with the client’s written consent, through a provider named in the DPA. AI-assisted changes are labelled and reviewed by someone else before merge. The details are in the AI usage policy template signed alongside the contract.
5 · Plainly stated
| Not in place | How it is offset |
|---|---|
| No ISO/IEC 27001 certification or SOC 2 report | Accept audits by the client or a third party it appoints; answer the client’s own security questionnaire; templates reference ISO 27001 Annex A controls. |
| No professional liability insurance | Liability limits, warranty and acceptance are spelled out in the contract; payments follow acceptance milestones so the client’s risk is not back-loaded. |
| One principal engineer | Source code, documentation, runbooks and infrastructure access belong to the client and are handed over in full, so another team can take over — no single-person dependency. |
| No MFA on admin accounts of the studio’s own site | Client products get admin MFA when required (item 1.5 in the security checklist). Work can happen entirely on infrastructure and accounts the client manages (the client’s SSO and MFA). |
6 · Vendor assessment
The full version as Markdown, to paste into your questionnaire or send to procurement.
Vendor assessment answersAs agreed in the DPA. By default on infrastructure the client owns (the client’s cloud/VPS account). If the client wants the studio to operate it, location and provider are written into the DPA before deployment.
In transit: yes — HTTPS enforced, TLS 1.2/1.3, HSTS. Passwords: bcrypt-hashed. At rest: Cloudflare R2 object storage is encrypted at rest per Cloudflare; disk/database encryption at rest depends on the chosen infrastructure and is set per the client’s requirements — the studio does not claim it by default.
The studio’s principal engineer, and only people the client approves in writing. Server access is by SSH key, no passwords. Access is revoked when the task or contract ends.
On the studio’s product: the database is backed up automatically every night, kept 30 days, with an off-server copy mechanism and a script that test-restores into a throwaway database. For client projects: frequency, retention and RPO/RTO are set in the contract.
Per the SLA in the contract/maintenance agreement. If personal data is involved, the studio (Processor) notifies the client (Controller) promptly so the client can meet its legal notification duty. A postmortem follows.
The client, once paid per the contract. Code lives in a repository the client owns or is transferred with documentation, runbooks and infrastructure access.
Returned in the agreed format, all studio-side copies deleted including backups, keys revoked, and a signed data-deletion record produced.
Possibly, depending on the project (hosting, email, payments, LLM). The list is fixed in the DPA and approved by the client; adding one requires prior notice so the client can object.
Not by the studio. LLM-provider retention/use depends on that provider’s policy, so the provider is chosen in the DPA; there is a local-model option so data never leaves the client’s infrastructure.
Compile and type-check when building images; the required test suite before code lands on main; no deploy-on-push; post-deploy smoke-test; an OWASP ASVS checklist before major releases; third-party keys kept server-side.
No. The studio accepts audits by the client or a third party it appoints, and can work on the client’s infrastructure to inherit the client’s certified controls.
The process follows PDP Law 91/2025/QH15 and Decree 356/2025/ND-CP (Controller/Processor roles, right to deletion, response deadlines). Not legal advice — specific obligations are confirmed by the client’s counsel.
Email the channel in /.well-known/security.txt (see "Report a vulnerability" below). Please don’t disclose publicly before the studio has had time to fix it.
7 · Responsible disclosure
Email cuongthaihnhe176322@gmail.com with a subject starting with [Security].
Machine-readable: /.well-known/security.txt
