Policy

Allotropic Ltd builds software for operations that cannot tolerate ambiguity about who holds what, who can reach it, and what happens when something goes wrong. These are the commitments that govern that work for our clients, our candidates, and anyone using a system we have built.


  • Privacy notice

    What we collect through this site and through the systems we operate on a client's behalf, how long it is held, and the lawful basis for each category.

    Request document
  • Data handling standard

    Classification, encryption at rest and in transit, key custody, and the conditions under which production data may be accessed by an engineer.

    Request document
  • Responsible disclosure

    How to report a vulnerability in a system we build or operate, what we commit to in response, and our position on good-faith research.

    Request document
  • Subprocessors and supply chain

    The third parties involved in delivery, how dependencies are vetted and pinned, and the provenance record we keep for every release artefact.

    Request document

Philosophy and approach

Most software is written to be finished. The systems we are asked to build are written to be depended on for years, by people who will never meet the engineers who wrote them, in conditions nobody modelled at the outset.

That changes the discipline. It means fewer dependencies and a longer argument about each one. It means failure modes written down before features are agreed. It means interfaces narrow enough to reason about on paper, and a bias toward designs whose behaviour under stress is boring and predictable.

It also changes how we contract. We would rather decline work than accept a timeline that forces a shortcut through review, and we say so at the proposal stage. Our clients are buying a standard, not a delivery date.


Our operating principles

Six commitments that apply to every engagement, regardless of sector or scale.

  • Where a system holds money, inventory, or an operational history, correctness is not negotiable against speed. We favour designs where the record can be reconstructed and independently verified, and we treat silent data loss as the most serious class of defect.

  • Systems are designed against the assumption that a network, a dependency, or a region will fail during operation. Degraded modes are specified before the happy path is optimised, and recovery procedures are exercised rather than documented and forgotten.

  • Access is scoped to a task and a period rather than a person and a tenure. Production credentials are short-lived, administrative actions are attributable, and no engineer holds standing access to data they do not need to do the work in front of them.

  • Every release carries a trail: what changed, who reviewed it, which tests and checks ran, and which artefact reached which environment. Assurance is a property of the process, not a statement made at the end of it.

  • A client's data belongs to the client. We do not repurpose it, train on it, or move it across jurisdictions without written instruction, and we hand over complete exports and infrastructure control at the close of any engagement.

  • We use automated tooling, including AI assistance, where it improves rigour. Its output is reviewed by the engineer who signs the change, and it is excluded entirely from workflows touching sensitive client data.

Reporting a security issue

If you believe you have found a vulnerability in a system built or operated by Allotropic, write to security@allotropicltd.com. We acknowledge every report within one working day and will keep you informed until the issue is closed. We do not pursue researchers acting in good faith.