Everything your security officer wants to know.
Contracts, access, data and AI: this page covers what we sign, who sees what, and how we keep your code and data safe.
Paperwork first, then access.
What do we sign, and when?
A mutual NDA and a data processing agreement before we are given access to anything: signed ahead of the kick-off and ahead of the first invoice. For a Hardening Audit, that is all the paperwork there is: one NDA, one processing agreement and one purchase order.
Who exactly gets access?
Named individuals, listed before we start, on accounts you create and can revoke in one click. Read-only by default; write access only where the engagement needs it, and then only to the repository we agreed.
Can your developers see our production data?
No. Development, test, acceptance and production are separate environments, and our developers work on the first three with anonymised data only. Production is reached by operations, on a need-to-know basis. We set this up years ago, before the GDPR came into force, when we started working across Rotterdam and Serbia. It is a good idea for any team, wherever the developers sit: access only what the work needs.
Who are those people, and where do they sit?
We have been connected to Serbia from the start, with our own offices in Novi Sad since 2011 and Belgrade since 2013, alongside Rotterdam. One company: our engineers in all three offices work under the same employment contracts, the same confidentiality obligations and the same ISO 27001 controls. If your own policy requires the work to stay inside the EU, that is part of the scoping conversation.
What our agents do with your code.
This is a newer question, and often the first one your data protection officer asks.
Does our code end up in a model?
We use commercial model providers under agreements that exclude customer content from training. Your code is sent to answer questions about your code, and that is the whole of it; your production data is not part of it, because the agents work in the same anonymised environments as our developers. If you want a specific provider excluded, or the work done on infrastructure you nominate, that is a scoping conversation we are happy to have.
Can you show what the agents actually did?
The change trail, yes: every change arrives as a commit and a pull request in your own repository, reviewed by a second agent against written criteria, blocked or passed by automated checks, and signed off by a named person. That trail lives in your systems and stays there after we leave. A record of every tool an agent invoked or every byte that left the repository is a different thing, and part of the scoping conversation.
What may your agents touch?
Less than a developer. Every agent run starts in a fresh, isolated sandbox in our Azure environment in West Europe, from a pinned image, and is deleted afterwards. The agent never holds a key: a proxy adds credentials on the way out, and the network is closed except for a list of approved hosts. Each role runs under its own limited identity, which cannot push to main, cannot bypass a branch policy and cannot complete a merge. A change only reaches you as a pull request that one of our engineers reviews and approves. Every run is capped and logged, and any step can be stopped with one switch. The full line is on the how we build page.
What happens to your working copy afterwards?
Working copies live on managed company equipment for the duration of the engagement and are removed at the end. You revoke access the day we finish. Your code serves your engagement only; afterwards it stays where it belongs, with you.
Serbia is outside the EU. How is that covered?
Start with your production data: our developers and engineers never work with it, whether in Serbia or in Rotterdam. Development, test and acceptance run on anonymised data and databases; production is reached only by the people who need it for operations. So the question of where a developer sits rarely touches personal data at all, and the same holds for our coding agents: they work in the same anonymised environments. What remains, such as operational access and support, is covered in the contract: standard contractual clauses for our Serbian entities, a transfer impact assessment, and a list of sub-processors with name and location. If your policy or your regulator requires EU-only processing, that is part of the scoping conversation.
Who carries the risk if agent-written code causes a problem?
We do, on exactly the same terms as code typed by a person: the same warranty, the same liability, the same obligation to fix it. In our contracts, code from an agent is simply code. That is the whole reason the gate exists: every line is reviewed before we put our name to it.
Who owns what we build?
You own the code written for you, outright, in your repository. Entry, the foundation underneath it, is open source under Apache-2.0 and stays that way, so it remains free to use for you and for the team after you. The gates and checks we configure for you are yours too.
Since 2006, long before the agents.
We have been building for regulated and public-sector clients since 2006, and our security practice is as old as the company.
Security answers the questionnaire. EnigmaSure answers the exit question.
The habits on this page — separated environments, anonymised data for developers, production on need-to-know — are the foundation. EnigmaSure extends them to the day you have to leave your cloud: escrow of code, pipelines, infrastructure and data, a monthly restore drill on a second European cloud, and a signed record your auditor can use for DORA and the Data Act.
- EscrowCode, pipelines, infrastructure and data in an EU vault; the keys are yours.
- DrillAutomated restore on a second European cloud, every month.
- ProofA signed, dated record; reports on demand mapped to DORA and the Data Act.
Send us the requirement. We tell you whether we can meet it, before you spend time on a proposal.
Forward this page to your security officer, or send us the questionnaire.
Send us your security requirement.
Your security officer’s checklist, your processing agreement, your penetration-test clause: we tell you which points we can sign, which need a conversation, and which we cannot promise, before you spend a procurement round finding out.
Secure by default, since 2006