mokuji by neurotik
FAQ Request a demo
  1. Home
  2. Mokuji
  3. Trust center
  4. Responsibility

Who is responsible for what.

Line by line: what we are responsible for, what you are, and every class of data the system creates: where it lives, who can reach it, and what happens when it is deleted.

Last updated

Shared responsibility models are usually written to make a vendor look busy. This one is lopsided in the other direction, and it has to be: for software you run yourself, most of the operational burden genuinely is yours. A matrix that pretends otherwise only sets up an argument during an incident, which is the worst possible time to have it.

The split

Line by line.

The software Writing it, testing it, fixing it, and shipping releases. Deciding when to apply them.
Infrastructure Telling you what it needs and helping you size it. Providing and running it: hosts, GPUs, storage, network, hypervisor, operating system.
Your media Nothing. We never receive it, hold it, or have a route to it. All of it: storage, classification, lawful basis, retention and disposal, and, if you turn on cloud processing for a catalog, choosing the GPU provider and holding the agreement with them.
Derived biometric data Removing derived data when an asset is deleted, documenting what gets created, and telling you plainly where removal is not yet complete. Consent, notice, retention schedule and deletion decisions.
Access control The role and permission model, checked by the services rather than only in the interface. Who gets an account, what role they hold, and removing them when they leave.
Encryption Encrypting control traffic between nodes, encrypting work sent to relayed and cloud workers end to end, encrypting backups to your public key, and documenting where the software keeps its secrets. Disk encryption, key custody for your storage and for the backup private key, and protecting the environment file that holds the software's secrets.
Network exposure Publishing a single entry point and no internal service ports in the standard install, and documenting what a multi-node deployment must keep on a private network. Firewalling, reverse proxy, TLS certificates and who can reach the host.
Backups A built-in backup scheduler, encryption to your key, and a written restore procedure. Where they go, how long they are kept, testing restores, and holding the storage and the keys.
Monitoring and availability Health endpoints, plus the install and operating guides as they are published. Watching them. There is no vendor-side uptime to measure, because there is no vendor-side anything.
Vulnerabilities Finding them, fixing them, and telling you, including when the flaw is ours and already on your estate. Applying the release, and patching the host underneath it.
Incidents Supporting your investigation, and disclosing anything that affects you. Detection, response and any regulatory notification. The logs and the systems are yours.
Support access Working from the diagnostics you send first. Asking before we need more, and only for a specific escalation. Granting it, scoping it, timing it and revoking it. We hold no standing access to any deployment, so nothing is reachable until you decide it is.
Data inventory

Everything the system creates.

This is the table behind most of the other questions. Every class of data that exists once an asset has been indexed, where it lives, who can reach it, and what deletion does to it.

Data classes

Source media
Where: Your storage, where you put it
Who can reach it: Any signed-in user
On delete: Kept unless you choose to delete the file as well
Proxies
Where: A proxy folder you choose on your storage
Who can reach it: Any signed-in user
On delete: Not yet removed with the asset; being fixed
Scene descriptions
Where: Your database
Who can reach it: Any signed-in user
On delete: Removed with the asset
Transcripts
Where: Your database
Who can reach it: Any signed-in user
On delete: Removed with the asset
Face crops
Where: Your storage
Who can reach it: Any signed-in user
On delete: Removed with the asset
Face embeddings
Where: Your vector store
Who can reach it: Not directly readable by users
On delete: Removed with the asset
Estimated age and sex
Where: Your vector store, with each detected face
Who can reach it: Shown to users reviewing unnamed faces
On delete: Removed with the face
Voiceprints
Where: Your vector store
Who can reach it: Not directly readable by users
On delete: Not yet removed with the asset; being fixed
Named identities
Where: Your database
Who can reach it: Any signed-in user
On delete: Deleting a person removes their record; their reference faces and voice samples are kept until removed separately, which is being fixed
Search index
Where: Your vector store
Who can reach it: Reached through the permission model, never directly
On delete: Entries removed with the asset
User accounts
Where: Your database
Who can reach it: Administrators
On delete: Removed on request; audit entries retain the actor reference
Audit log
Where: Your database, not editable through the application
Who can reach it: Administrators
On delete: Retained per your policy; not cascaded
Search log
Where: Your database: each query, how it was read and how many results it found, not who ran it
Who can reach it: Administrators
On delete: Rotates after 90 days by default; not removed with an asset
Cloud processing agreements
Where: Your database: which catalog, who agreed, when, and the wording
Who can reach it: Administrators
On delete: Retained as the record of consent
Backup bundles
Where: The off-box location you choose, encrypted to your public key
Who can reach it: Whoever holds the private key
On delete: Follow your backup retention
Telemetry sent to Neurotik
Where: Does not exist
Who can reach it: Nobody
On delete: Nothing to delete

The audit log is deliberately not removed by deletion: a log of who deleted something is only useful if it survives the deletion. The search log is not removed either; it rotates on its own schedule.

Need this mapped onto your own framework?

Send the control set you have to satisfy and we will map it rather than asking your team to translate ours.

Talk to us The questionnaire