Security and trust

Repository access is the largest thing you will hand us.

This page is for the person who has to sign off on that. It says where your code sits, who can reach it, what we keep, what happens when the engagement ends, and what we do not hold. No adjectives, and nothing you cannot check.

Being audited yourself? The questionnaire guide is the page you want.

Four commitments, each of which you can hold us to.

The rest of this page is these four, expanded into the detail a security reviewer asks for — plus the one question they do not cover, which is where your source physically sits.

Your code stays yours

An ordinary repository, your licence, your history. No proprietary runtime, nothing hosted you cannot leave, no migration to negotiate at the end.

No real customer data in a delivered artifact

Enforced by one of the six checks rather than by a policy document. A rule a person can break by forgetting is not a control.

You decide which models read your code

Delivery uses models we run on our own hardware and a hosted frontier coding model. Before work starts you get, in writing, which of them may read your code. If none of it may reach a third-party model, say so first and we will tell you plainly whether we can deliver that way.

Every change is attributable

Who or what made it, what checked it, and why it was made. That record is the deliverable as much as the code — and it is what answers a security questionnaire from evidence.

Where your code lives

Your repositories, your identity provider, your permission model.

We work in your repositories under accounts you issue, at the narrowest scope the work needs, and every check that ran on a change is part of what you receive. There is no long-lived copy of your codebase in a platform of ours that you would have to ask about, audit, or migrate out of at the end.

Three things sit on our side of the line, and you should price them in rather than discover them. Engineers clone the repositories in scope onto NamiQ workstations, the way any engineer anywhere works. The checks and the delivery board run in our environment, against those working copies. And the delivery process uses two kinds of model: ones we run on hardware we own, and a hosted frontier coding model from a third-party provider — which means that when a task runs, the parts of your source it needs are read either on a machine of ours or by that provider. Source does cross the boundary. Saying otherwise would be the tidier answer and the false one.

What bounds it is scope, retention and use, and each of those is something you can write into the contract: only the repositories you name, nothing of yours retained past the working copy, nothing of yours used to train a model of ours, and the hosted provider named in the contract together with its data terms. Working copies are limited to those same repositories and deleted at offboarding, which is an attestation rather than an enforced control; the timeline below says who signs it. If that boundary is not one you can accept, tell us before the engagement rather than during it, and we will say plainly whether we can work another way.

Which models may read your code is agreed in writing before work starts. If none of your code may reach a third-party provider, tell us before the engagement and we will say plainly whether we can deliver that way, and what it would change.

What we keep

The system that holds your email is not the system that touches your code.

Two separate things get conflated in most vendor answers, so here they are apart. The commercial side — your name, work email, company and whatever you wrote in a form — sits in a CRM we host and operate ourselves. What it holds, where it is, how long it stays and how to make us delete it are set out on the privacy page, including the part about which country it is processed in.

Product and code access is a separate track. Your source, your data and your delivery record are not in that CRM, are not linked to it, and are not used to enrich it. A salesperson looking up your company sees a contact record and nothing from your repository.

In the other direction: no real customer data ends up in a delivered artifact. That one is enforced by check 01, security and code health, which stops the change on the pipeline below rather than warning about it in a policy document — because a rule a tired person can break by forgetting is not a control.

What runs against your code

Two of the six checks exist for exactly the risk you are assessing.

01 · Security and code health

Insecure code, leaked credentials and unreadable work stopped at the door. Runs every change.

04 · Whole system

Rebuilds everything from scratch and scans the full stack for vulnerabilities. Runs on integration.

A change that fails one does not merge with a note attached; it goes back to whoever wrote it. The record of which checks ran, and what they returned, is attached to every change — which is what lets you answer a question about a specific commit six months later.

Six is the one that cannot be satisfied by writing more code to satisfy it: it asks whether a person can finish the job on the running system.

Access and offboarding

You can end our access without our cooperation.

Day one: You grant access in your own systems, at the narrowest scope the work needs. Nothing is granted through us, so nothing has to be revoked through us.
During: Access is per named person, never a shared account. If someone rotates off the work, that is a change you can see in your own audit log rather than one you have to take on trust.
Last day: We write you a list of every account, key and integration you gave us, so you revoke against a checklist instead of a memory. Working copies are deleted, and you get a written offboarding note, signed by a named person, listing each machine that held one. That note is an attestation, not a control — you are trusting a signature, and you should read it as one.
After: The delivery record stays with you because it was always in your systems. There is nothing of yours we need to keep, and nothing you have to ask us to return.

Our own posture

NamiQ does not hold SOC 2.

We have not been audited against it and we are not in an observation window. Nothing on this site says otherwise. If you find anything here that reads as though it does, it is wrong and we want to know.

You would have found this out in week two of your vendor review anyway, and a supplier who made you dig for it has told you something about how the rest of the engagement will go. What we offer instead is narrower and checkable now: a written development process with named steps and stated blocking conditions, and the evidence for every individual change — the ticket, the checks, the results, the approver. Pick a change at random and ask us to produce it.

That is not a substitute, and we will not present it as one. An attestation is an independent party saying your controls operated over a period. Evidence per change is us showing our work. If your procurement rule requires a report, we do not clear it, and the honest thing is for you to know that on the first call rather than the fourth.

One more you should weigh: we are small. The person who answers your security questions is close to the people writing the code, which makes the answers fast and specific — and makes us thinner cover than a large supplier if you need a rota answering at three in the morning. Ask us about continuity before you sign, not after.

If it is your deal stuck in security review

A questionnaire row is answered with evidence, and evidence is something you can produce in a fortnight — long before any report exists. We went through a standard questionnaire row by row: what to show for each one, which two answers end deals, and what to do on Monday. Read it — free, no email →

Ask us the questions you would ask any supplier.

Start with read access to one system. We map it and come back with what we found, what we would build and what it would take — and you get to watch how we handle your code before anything larger is signed.

Start with one system