Security at ComplyDP
Last updated: 2026-11-09. Owner: Nihonium Labs Private Limited (ComplyDP).
For a bank's information-security, third-party-risk and AI risk teams: how the ComplyDP appliance protects your data, the evidence each release carries, where complydp.com keeps data, and how to report a vulnerability.
How it works
The ComplyDP appliance runs inside your network, on one Linux VM you control: four containers (the screens, the API, the scan worker and a PostgreSQL database), reachable only through the VM's loopback address. It reads catalogue metadata from your systems, the names and types of tables, columns and files, with read-only accounts you create; the default scan reads no record value. Findings and an append-only audit log stay on the VM, and the log can stream to your SIEM. The appliance makes no connection to ComplyDP. The only thing that can leave is an encrypted export that a second person in your team approves and your operator uploads to complydp.com, where it is imported into your organisation's data map without any AI model.
The evidence pack
Every release carries a signed evidence pack. It comes inside the install kit and on your organisation's Download tab on complydp.com; ask us for the current one if you are assessing ComplyDP before you have an account. Confirm the release key's fingerprint with ComplyDP by phone, then check every file offline as the pack's README shows. Each file below names the code or test it comes from, and the README lists what is still open.
| File | What it shows | Kind |
|---|---|---|
README.md | Start here: how to check the pack's signatures, and what each file answers | Each release |
sbom-{api,ui,postgres}-<v>.cdx.json, .spdx.json | Every package inside each image, with its version and licence (CycloneDX and SPDX) | Each release |
vuln-scan-<v>.md, vuln-exceptions-<v>.json | The known vulnerabilities each image carries, and for any accepted one the reason, the mitigation and a review date | Each release |
build-provenance-<v>.json | That the images were built from the stated source commit by the stated builder | Each release |
release-gates-<v>.md | That the release passed its gates: no client name or private key in what it publishes, no unlisted critical or high vulnerability, a security section in the release notes | Each release |
hardening-<v>.md | Container hardening as tested (non-root, read-only, capabilities dropped, resource limits), with the CIS Docker Benchmark | Each release |
access-control-<v>.md | Roles, second factor, single sign-on, lockout, session timeout and time source, each with the test that proves it | Each release |
audit-logging-<v>.md | What is logged, how the append-only chain shows tampering, how events reach your SIEM, and retention | Each release |
credential-handling-<v>.md | Where connection secrets live and how they are encrypted | Each release |
tls-and-headers-<v>.md | Transport security and the security headers of the appliance's screens | Each release |
egress-proof-<v>.md | That the appliance sends nothing out: the allowed hosts and this release's packet capture | Each release |
network-requirements-<v>.md | The ports and hosts each connector needs, and proxy support | Each release |
metadata-only-proof-<v>.md | That the default scan reads no record value: statement logs, request logs and planted canaries | Each release |
classification-accuracy-<v>.md | How well it finds what it should: precision and recall per category | Each release |
soc-pack-<v>.md, .pdf | What your security operations team whitelists: the signing key's fingerprint, image digests, executable hashes, processes, paths to exclude, ports and hosts | Each release |
threat-model.md | What an attacker would want, the trust boundaries, and what stops a network neighbour, a compromised operator, a compromised vendor, a stolen VM disk or a stolen kit, each with its proof | Standing |
ai-use-statement.md | Where AI is used (none inside the appliance), which model, what it sees and never sees, how to keep it out of your work, and the RBI FREE-AI and DPDP points | Standing, draft |
data-flow-and-residency.md | What the export contains, how it travels, where it is stored on complydp.com, and who at ComplyDP can reach it | Standing |
sub-processors.md | Which providers process an upload, for what, and where | Standing, draft |
continuity-statement.md | That the appliance keeps working without ComplyDP, and how you exit | Standing |
backup-restore.md | What is backed up, how to restore it, and how long that takes | Standing |
edr-compatibility.md | Process names, paths to exclude, and the CPU and memory to expect, for your endpoint agent | Standing |
incident-response-summary.md | Who notifies whom, how fast, and with what | Standing, draft |
support-and-patch-sla.md | Patch timelines and how a fix reaches you | Standing, draft |
support-lifecycle.md | Versions, upgrades, retirement and end of support | Standing |
dpia-input.md | Input for your data protection impact assessment under the DPDP Act | Standing, draft |
KEY_ROTATION.md | How a signing key is replaced and how you verify the new one | Standing |
security.txt | The security contact, as published at /.well-known/security.txt | Standing |
Where data is kept
- On your network: everything the appliance holds, on your VM. Nothing is sent out unless your reviewer approves it.
- On complydp.com: the platform's API, worker, job queue and release downloads run in Google Cloud asia-south1 (Mumbai), and its database in AWS ap-south-1 (Mumbai). The platform's keys are being pinned to asia-south1.
- AI features of complydp.com call a model that is not pinned to a region, and nothing imported from an appliance reaches it. The evidence pack's
ai-use-statement.mdhas the detail.
Sub-processors
The appliance has no sub-processor. For what you upload to complydp.com, these providers process data as ComplyDP's sub-processors. Regions as checked on 2026-10-31; the list is a draft for legal review, and the contractual list comes with your data processing agreement.
On the path of an upload
| Provider | What it runs | What it processes | Region |
|---|---|---|---|
| Google Cloud | The platform's API and worker, the job queue, the keys and the release downloads | The upload in transit and while it is decrypted and imported; import job ids; platform logs | asia-south1 (Mumbai). The keys' replication is being pinned to the same region |
| Supabase | The platform's PostgreSQL database | Imported field rows, import history, audit rows, organisation and member records | AWS ap-south-1 (Mumbai) |
| Vercel | The complydp.com web application, which an upload passes through still encrypted | The encrypted export in transit; session cookies | Its functions run in Mumbai |
| Clerk | Sign-in to complydp.com | Your users' names, e-mail addresses and sign-in events | Being confirmed |
| Mailgun | E-mail to your data protection officer after an import | That officer's e-mail address and the import's counts; no field names | Being confirmed |
Used only by other complydp.com features
| Provider | What it runs | What it processes | Region |
|---|---|---|---|
| Google (Gemini API) | AI drafts a user asks for; field-name classification and tool-name matching for systems connected on complydp.com; vendor names in a code scan | Names of fields, systems, vendors and dependencies; never a record value, and nothing imported from an appliance | Not pinned to a region: treat prompts as processed outside India |
| Firecrawl | Website scanning, and the web search behind a DPA draft | Public web pages of sites you ask the platform to scan; for a DPA draft, the vendor's name | Not stated in the evidence pack |
| Nango | Cloud SaaS connections made from complydp.com, not the appliance | OAuth tokens for those connections | Not stated in the evidence pack |
Report a vulnerability
E-mail privacy@complydp.com with what you found and where (complydp.com, or the appliance and its version), the steps to reproduce it, the impact you expect, and how to reach you. We will confirm that we have it and tell you when it is fixed.
- Test only your own account on complydp.com or your own install of the appliance, never another organisation's account or a client's installation, and do not read, change or delete data that is not yours.
- Give us reasonable time to fix the issue before you disclose it.
- We do not publish an encryption key yet. If your report holds sensitive detail, say so in a first message and we will agree a safe way to send it.
The same contact, machine-readable: /.well-known/security.txt.