About Acmez
Quality and Security
The practices that apply on every engagement, whatever its size, because standards that only apply to large projects are not standards.
Engineering quality
How we keep code maintainable
- Architecture review before build begins, with decisions recorded and their trade-offs stated
- Peer code review on every change, with no self-merged production code
- Automated test coverage appropriate to risk, run on every commit
- Continuous integration with build, test, lint and dependency scanning
- Performance budgets set at design time and enforced in the pipeline
- Accessibility verified against WCAG 2.2 AA by testing rather than by assumption
- Documentation and runbooks maintained throughout, not written at handover
- Technical debt tracked openly and repaid on a schedule you can see
Security practice
How security is built in
- Threat modelling during design for systems handling sensitive data
- Secure defaults: least privilege, encryption in transit and at rest, no shared accounts
- Secrets held in a managed store, never in source control or configuration files
- Dependency and vulnerability scanning in continuous integration
- Static and dynamic application security testing before release
- Access logging and audit trails designed in from the start
- Environment separation with production access restricted and logged
- Security review as part of the definition of done, not a later gate
Data protection
How we handle client data
Our default is to work in your environment with the minimum access required, so that client data does not accumulate on our side unnecessarily.
Client-controlled environments
Where you prefer, work is performed in your repositories, cloud accounts and environments under your access control.
Least-privilege access
Team members receive only the access their role requires, reviewed when people join, change role or leave.
Confidentiality agreements
Company-level and individual confidentiality obligations apply to everyone working on an engagement.
Production data discipline
Production data is not copied into development environments. Test data is synthetic or anonymised.
Intellectual property
Delivered source code, documentation and associated intellectual property transfer to the client.
Exit arrangements
Documentation, runbooks and knowledge transfer are maintained throughout so an exit is straightforward.
AI ethics
How we decide what AI should and should not do
AI systems make mistakes, absorb the biases in their training data, and are easy to deploy faster than anyone has thought through the consequences. These are the commitments we hold ourselves to on every AI engagement, and they occasionally cost us work, which is rather the point of having them.
A person is accountable
Every AI system we deploy has a named owner on the client side who is answerable for its behaviour. Systems without one do not go live.
People are told
Anyone interacting with an AI system is told they are. We do not build assistants that present themselves as human.
Measured before deployment
Accuracy is measured on your real data against an agreed threshold, and reported honestly, including where it falls short.
A route to a human
Where a system affects someone's access to a service, employment or money, there is always a way to reach a person and contest the outcome.
Bias is assessed, not assumed away
Where a system influences decisions about people, we test for disparate outcomes across the groups it affects and document what we find.
Your data stays yours
Client content is not used to train third-party models. We configure deployments so that this holds, and document the data flow so you can verify it.
Proportionality
We recommend against AI where a rule, a form or a better-designed process would do the job more cheaply and more predictably.
Work we decline
We do not build systems for covert surveillance of individuals, deceptive impersonation, or automated decisions affecting people's rights without human review.
What we do not claim
These are our own operating commitments, not a certification, and no external body audits them. Where an engagement is subject to a formal AI governance framework, a client's internal policy, a sector regulator's expectations, or emerging legislation, we work to that framework and say plainly which of its requirements are met and which are not.
On certifications and compliance
Acmez Technologies does not claim to hold certifications it has not been awarded, and does not claim compliance status on a client's behalf. We build systems that support your compliance obligations: access control, audit trails, retention, encryption and structured reporting, and we supply the technical documentation assessors require. Certification against standards such as ISO 27001 or SOC 2 is assessed and granted by accredited certification bodies. Where an engagement requires evidence of specific controls, we will provide it and state plainly what is and is not in place.
Next step
Ask us the difficult questions before you engage us
Security reviews, reference conversations and technical due diligence are welcome. We would rather answer them early.