Your questionnaire, answered in advance.

Start here

Most vendor questionnaires assume the vendor holds the data. That assumption does not hold here, and it changes the answer to a large fraction of the questions you are about to ask.

Where is our data hosted?

On infrastructure you own and operate. We have no hosting environment in the processing path, and no route to your media. The one optional exception is cloud processing, off by default: if an administrator turns it on for a catalog (the agreement is recorded with who and when), that catalog's GPU work goes, encrypted end to end, to a cloud GPU provider you choose.

What data do you collect from our deployment?

None. Mokuji sends no telemetry or analytics and makes no license check-in, and bundled third-party components ship with their usage reporting switched off. Once models are staged locally, a deployment is designed to run with outbound traffic blocked or with no internet connection at all.

Which parts of our questionnaire will be marked not applicable?

Typically: data-center and physical controls, cloud hosting and tenancy isolation, vendor backup of customer data, data residency, cross-border transfer, and vendor breach of customer data. Not because we decline to answer, but because you provide the infrastructure those questions are about.

Are you a data processor under GDPR?

Not for your media. You are the controller, and in the standard install the processing happens entirely on your systems and we never receive your data, so we are not a processor of it. If you turn on cloud processing, the GPU provider you choose processes that work for you and is your sub-processor, not ours. If you ask us to host the relay that routes that work (an added service), it forwards encrypted work it cannot read, and we cover it, including where it runs, in a processing agreement with you. We may process limited contact details for support, which is a separate and much smaller matter.

Do you have sub-processors?

None of ours for the product. In the standard install nothing in the processing path is operated by anyone but you. If you turn on cloud processing for a catalog, the cloud GPU provider you choose is your sub-processor for that catalog's GPU work: it receives frames, the clips' audio, short transcript passages, on-screen text, captions, the names and places already found, and search queries, encrypted end to end, keeps them in memory (or sealed with a key that exists only in memory), and drops them when each job ends. Databases, identities and voiceprints never leave. If you ask us to host the relay that routes that work (an added service), it forwards encrypted work it cannot read, and we cover it, including where it runs, in a processing agreement with you.

Deployment and architecture

What is the deployment model?

Self-hosted. The indexing system needs GPUs and ships as a containerized service stack that you run. There is no version of it hosted by us.

What ports and services are exposed?

A single entry point, reverse-proxied. The standard install publishes no internal service ports; the databases and internal services are reachable only inside the deployment. The optional add-ons for multiple nodes and GPU captioning publish further ports without authentication of their own, so they belong on a private network segment. Workers reached through a relay receive signed, encrypted tasks and have no access to the databases.

Does it require outbound internet access?

No. It is designed to run with no internet connection once installed; models are staged locally, so nothing needs to be fetched while it runs. A formal offline acceptance test is not yet part of the release. Cloud processing, if you turn it on, needs a route to the GPU provider you choose.

Can it run in a segmented or classified network?

Yes, by design: it runs with no internet connection once installed, because models are staged locally. A formal offline acceptance test is not yet part of the release, so test it in your environment. Multi-node scaling shards work across GPU hosts on your own network, with control traffic between nodes mutually authenticated and encrypted; no node needs to reach the internet.

Do you have standing access to customer deployments?

No. There is no support tunnel, no VPN back to us, no phone-home channel and no credential we hold. A deployment that is never granted access is never reachable by us.

Then how does support actually work?

In three steps, and you control which one you are on. First, you build a diagnostics bundle from the admin screen in one click and send it to us. Secrets are redacted, but it includes recent logs and searches, which can contain names, so review it before sending. That covers most issues and requires giving us nothing. Second, if we need to look deeper, you grant access to the deployment across your own network, for as long as you choose, under your own controls, and revoke it afterward. Third, where the support tier allows it, an engineer attends on site and works on the system in front of you.

Does support ever need credentials to our systems?

Only if you decide to issue them for a specific escalation. We do not hold standing credentials, and we would rather work from diagnostics you send than from access you have to remember to revoke.

What are the infrastructure requirements?

GPU hosts sized to your library, storage for media and derived data, and a network you control. We size it against your actual footage rather than quoting a spec sheet.

Access and identity

How are users authenticated?

Signed bearer tokens carrying the user and role, with a configurable lifetime that defaults to seven days. Passwords are stored with a per-user salt and PBKDF2-HMAC-SHA256 at 200,000 rounds. A failed login against a username that does not exist pays the same cost as a real one, so the endpoint is not a user-enumeration oracle. Repeated failures are throttled per client address and per username, held in memory on a single instance. Sign-in is enforced by default, and the services refuse to start enforcing it without their secrets set.

Is the password hash memory-hard?

No. It is PBKDF2, which is compute-hard rather than memory-hard, so it offers less resistance to GPU-accelerated cracking than Argon2id or scrypt would. The iteration count is set high to compensate. We would rather tell you the algorithm than describe it in adjectives.

How is authorization enforced?

Role-based permissions decide what each user can change, and they are checked by the services rather than only hidden in the interface. Collections can be shared with a team or with named users. Today any signed-in user can search and view the whole library; restricting viewing per asset or per team is on the roadmap. Role changes take effect within a minute. Disabling or deleting an account, changing or resetting its password, or removing its administrator flag ends its existing sessions across every service within about thirty seconds.

Is there a privileged integration key that bypasses the model?

User tokens carry the user's role, and integrations use service-account keys with roles of their own. One internal token, used only between Mokuji's own services, has full access. It lives in the deployment's environment file and should be rotated at handover.

Do you support SSO or directory integration?

Not built in today. Tell us what you run, whether LDAP, SAML or OIDC, and we will scope the work.

Is there multi-factor authentication?

Not built in today. Deployments commonly place the system behind an identity-aware proxy that provides it. Tell us if you need it natively.

Can an administrator see everything?

Yes. An administrator of your deployment can reach the material and the derived data. The access model constrains users, not the people who run it. That boundary is yours to staff.

Encryption and keys

Is data encrypted in transit?

TLS terminates at the entry point, on your load balancer or a reverse proxy in front of Mokuji, with your certificates. Control traffic between nodes is mutually authenticated and encrypted. Internal services talk over the deployment's private network, which is not exposed outside it.

Is data encrypted at rest?

On your disks, under your full-disk encryption. Backups the software writes are encrypted to your public key, with the private key kept off the box. The software's own secrets live in its environment file on the host, so protect that file as you would any credential.

Who holds the encryption keys?

You do. We hold no key material belonging to any customer deployment.

How is media access granted?

Through signed URLs rather than open file paths. Each signature covers one file and expires, after six hours by default, configurable, and it is not the user's session token. A collection can also be shared by link: anyone holding the link sees it without signing in, a link shared for editing lets them rate and label its clips, and the link works until sharing is turned off.

Development and supply chain

Describe your secure development lifecycle.

Automated tests cover the services and the web interface. A gated release pipeline with static analysis and dependency vulnerability checks is being built; until it is in place, releases are built by our own team.

How are third-party dependencies managed?

Declared per service. Automated vulnerability checks arrive with the release pipeline that is being built.

Can you provide an SBOM?

Not yet. A CycloneDX SBOM per release is being prepared alongside the release pipeline. Ask and we will tell you where it stands.

How are releases built and verified?

From our own source repositories, by our own team. Published checksums come with the release pipeline that is being built.

What is your patch cadence for security issues?

Fixes are produced as quickly as severity warrants and released with an advisory. Because you control deployment, the time-to-patched on your estate is yours. We will tell you clearly when something warrants urgency.

Has the product had a third-party penetration test?

No. A scoped brief for one is ready. You are free to test your own deployment; good-faith research is explicitly welcome.

Vulnerabilities and incidents

How do we report a vulnerability?

security@neurotik.io, with machine-readable details at /.well-known/security.txt. Acknowledged within two business days, and you are kept informed while it is fixed.

Is there a safe harbor for security research?

Yes, for good-faith research against your own deployment. We will not pursue anyone for it.

Will you notify us of a vulnerability in software we are already running?

Yes. That is the obligation that matters most for self-hosted software, since the flawed code is already on your estate and only you can replace it.

What is your incident response commitment?

We support your investigation and disclose anything affecting you. Detection, response and regulatory notification are yours, because the systems and the logs are yours. There is no vendor-side copy for us to investigate.

What audit logging exists?

Every change made by a person or an integration key, including corrections to transcripts and speakers, is recorded with the actor, the route, the target and the time, in your own database, as is every change refused for lack of permission and every failed sign-in. Service logs cover request-level activity. Views are not logged yet, so there is no consolidated access log covering every asset view. If that is a control you must evidence, tell us; it is a known gap.

Continuity

What happens if Neurotik stops trading?

The software keeps running. It is on your hardware, it needs no license server, and it needs no connection to us. You would lose support and future releases, not the system. If you want the stronger guarantee, we will enter a source-code escrow arrangement as a contract term.

What is your uptime SLA?

There is no vendor-side service to have one for. Availability is a property of your infrastructure. Support response commitments are a separate conversation and are contractual.

Who is responsible for backups?

You are, with tools we provide: a built-in scheduler that writes backups off the box, encrypted to your public key, and a written restore procedure. Where they go, how long they are kept and testing restores are yours. We hold no copy of anything.

Is there vendor lock-in?

Your media is untouched on your own storage. Derived data exports through a documented API, and interchange is in formats other systems already read. There is no format here that only we can open.

AI, biometrics and privacy

Is our media used to train models?

No. It runs on your hardware and sends nothing to us; with cloud processing off it sends nothing anywhere. With it on, the GPU worker you chose keeps that work in memory (or sealed with a key that exists only in memory) and drops it when each job ends.

What biometric data is created?

Face embeddings, face crops and voiceprints, derived from media you already hold, plus an estimate of apparent age and sex for each detected face. The estimates help a reviewer tell unnamed faces apart and are not offered as a search filter. A person's profile can also carry a gender your team enters, used to word scene descriptions. No external enrichment and no reference database supplied by us.

Does deletion actually remove it?

Mostly, and we will tell you exactly where it does not. Removing an asset deletes its face crops, face embeddings, transcripts, descriptions and index entries. Voice data taken from that asset, and its proxy files, are not yet removed with it, and deleting a person keeps their reference faces and voice samples until they are removed separately; both are being fixed. Copies in your backups, and sidecar files written beside your media, follow your own retention.

Is a DPIA required?

Almost certainly yours is, because biometric data is special category under GDPR Article 9 and large-scale processing of it triggers Article 35. We supply the vendor half of the assessment so your team is not starting from a blank page.

How accurate is identification?

Good enough to be useful and not good enough to be left unsupervised. Results are ranked with a match score and a breakdown of why each matched, and anything with consequences attached needs a person confirming it. We will measure it on your own footage rather than quote a benchmark number at you.

Is any output automatically actioned?

No. The system surfaces candidates to a human. Its automatic labels on faces and speakers are suggestions inside the index, shown as such and editable; it takes no action outside the index and makes no decision about a person, which is the single most important thing to know about it from a governance standpoint.

Commercial and legal

How is it licensed?

A self-hosted license sized to the deployment, agreed per customer while we take early deployments. No egress billing, and nothing that depends on a connection to us.

Will you sign our DPA?

We will sign one covering support interactions if your process requires it. Be aware it would not be describing processing of your media, because that never reaches us. If you turn on cloud processing, the DPA that covers it is the one with the GPU provider you choose.

Do you carry cyber liability insurance?

Ask and we will tell you what is in place at the time you ask, rather than publishing a figure here that may be stale.

What is the export control position?

Tell us the jurisdiction and the deployment and we will get you a straight answer before you need it for a filing.

Is there an accessibility conformance report?

Not yet. If a VPAT is a gate for your procurement, as it is for most US federal and university buyers, raise it early.

---

Documents

• Security architecture overview: Deployment model, network surface, identity and access, encryption, biometric handling, audit, supply chain, and the limits. (On this site)
• Pre-answered security questionnaire: The fifty questions that recur across SIG-Lite, CAIQ, VSAQ and HECVAT, answered. Downloadable to attach to a ticket. (On this site)
• Shared responsibility model: Line by line, what we are responsible for and what you are. Shorter on our side than you may be used to. (On this site)
• Data inventory and flow: Every class of data the system creates, where it lives, who can reach it, and what happens when it is deleted. (On this site)
• AI and biometric governance: Intended use, prohibited use, accuracy and its limits, human oversight, how your media is never used for training, and the EU AI Act position. (On this site)
• Vulnerability disclosure policy: Where to report, what response to expect, and safe-harbor terms for good-faith research. (On this site)
• Detailed architecture and data-flow diagrams: Component-level diagrams with trust boundaries and port inventory, for a reviewer who needs more than the overview. (In preparation)
• Completed SIG-Lite / CAIQ / HECVAT: Send us your framework's workbook and we will return it completed rather than asking you to map our prose onto it. (On request)
• Software bill of materials: Third-party component inventory with versions and licenses, for supply-chain review and for your legal team's attribution obligations. (In preparation)
  • CycloneDX, generated against the exact release you are running rather than a generic one, once the release pipeline is in place.
• Deployment hardening guide: How to stand the system up to the configuration we would run ourselves, including the settings that fail closed. (In preparation)
• Open-source license inventory: Components and their licenses, with the attribution text. Usually what legal actually wants when they ask for the SBOM. (In preparation)
• DPIA support pack: The systematic description of processing, data categories, recipients, retention and deletion mechanics, Article 32 measures, and the residual risks we think are real. (On this site)
  • Biometric processing makes a DPIA mandatory for you under GDPR Article 35. This is the vendor half of it, written to drop into your template.
• SOC 2 Type II report: An attestation over a service organization's controls. We do not operate a service that touches your media, so the controls it would cover are not in your data path. (Not held)
  • Tell us if your policy requires one regardless of architecture. It is a fair requirement and we would rather know early than at contract.
• ISO 27001 certificate: Certification of an information security management system. Not held. (Not held)
  • Same question applies, and the same answer: ask us early rather than late.
• Penetration test report: No third-party penetration test has been commissioned. (Not held)
  • You are free to test your own deployment; good-faith research is explicitly welcome.
• Data processing agreement: In the standard install we never receive your data, so we are not a processor of it and there is no processing for an Article 28 agreement with us to govern. If you turn on cloud processing, the GPU provider you choose processes that work for you and is your sub-processor, not ours. If you ask us to host the relay that routes that work (an added service), it forwards encrypted work it cannot read, and we cover it, including where it runs, in a processing agreement with you. (Not held)
  • If your process requires a signed DPA anyway, we will sign one covering support interactions. Just do not mistake it for us processing your media.
• Sub-processor list: We have none for the product. In the standard install nothing in the processing path is operated by anyone other than you. If you turn on cloud processing for a catalog, the cloud GPU provider you choose is your sub-processor, under your agreement with them. If you ask us to host the relay that routes that work (an added service), it forwards encrypted work it cannot read, and we cover it, including where it runs, in a processing agreement with you. (Not held)
• Data residency attestation: Your infrastructure, your residency. We cannot attest to where your data lives because we are not the ones holding it. With cloud processing on, the region is the one your chosen GPU provider runs in. (Not held)
• VPAT / accessibility conformance report: No formal conformance report has been produced for the interface yet. (Not held)
  • Required by most US federal and university procurement. Raise it early if it is a gate for you.
• Cyber liability insurance certificate: Not published here. (Not held)
  • Ask and we will tell you what is in place at the time you ask.
• Source code escrow: No standing arrangement. We will enter one as a contract term if you need it. (Not held)
  • The usual answer to “what happens to us if you stop existing”, and a reasonable thing to want for software you run yourself.