NDA-first, and the code is yours
We work on business-critical systems - repositories, credentials, and data other people depend on. This page states plainly how we handle that access, what we do and don't hold in the way of formal certifications, and where to push us for something more formal in writing.
NDA before anything
Every engagement starts with an NDA, before we get access to a repository, credentials, or any business data. This isn't a formality reserved for large accounts - it applies the same way whether the engagement is a two-week fixed-scope project or a multi-year dedicated team.
The code is yours
Full ownership of the code we write transfers to you. There's no vendor lock-in clause, no dependency on us to keep running it, and nothing about the arrangement requires staying with us if it stops working for you.
Access is scoped, not blanket
Access to your repository, credentials, and systems is granted only after the NDA is signed, only to the people actually doing the work, and limited to what that work requires - a database migration engagement doesn't get production admin credentials it doesn't need. Nothing about your system or your data leaves the engagement without your sign-off.
Data handling
Your data is used only to do the work you've engaged us for - not reused, referenced, or repurposed for any other client or purpose. Where an engagement needs a copy of production data in a development or staging environment (for example, to reproduce a bug in a rescue engagement), that copy is scoped to what the task requires and isn't kept around longer than the task needs it.
Subprocessors & tooling
We don't maintain one fixed list of third-party tools that touch every client's data, because the tooling is scoped per engagement rather than uniform across clients. Whatever source control, project tracking, or communication tooling applies to your engagement is disclosed and agreed with you before work starts, and can be written into the contract if you need it formalized.
Security posture
Security practices are scoped to what a given engagement actually needs, not applied as a uniform checklist regardless of the system. Two examples from work we've shipped:
AxiomFin
Docker containers orchestrated across AWS ECS/EKS with Terraform, AWS KMS envelope encryption, and zero-trust RBAC - architected to SOC 1 Type II, SOC 2, and ISO 27001 controls.
MindShield
Fully containerized on AWS ECS Fargate with AWS KMS envelope encryption at rest and TLS 1.3 in transit - architected to HIPAA, GDPR, and Australian Privacy Principles.
These are controls each client's system was architected to meet for that specific engagement. For modernization engagements specifically, we also follow a documented risk-management process (assessment, parallel testing, rollback plans, phased deployment, production monitoring) - see Risk Management & Validation.
Trust & security questions
The specific questions people usually ask before sharing a repository or production data.
Have a specific access or security requirement?
Tell us what your security or compliance team needs in writing, and we'll tell you honestly what we can commit to before the engagement starts.