How we work: governance, security, and how you leave.
Who hears what and how often, who you escalate to, the security practices every engineer works under, and a documented exit. The same on every engagement, whichever way you bought it. If any of this needs an email to find out, tell us and we will add it here.
Last reviewed 5 September 2026. These terms are the ones in our standard contract.
Governance and reporting
Who hears what, how often, and who you call. The same on every engagement, whichever way you bought it.
| Report | When | Who attends or receives it | What is in it |
|---|---|---|---|
| Weekly written report | Every week | Your sponsor and your technical lead | Progress against plan, decisions needed, risks, spend to date against budget, next week |
| Fortnightly demo | Every two weeks | Anyone you want in the room | Working software, not slides. Acceptance against the criteria agreed at the start |
| Monthly service report | Monthly, managed contracts | Your IT or operations lead | Uptime, incidents and response times against SLA, changes made, change allowance used, cost |
| Quarterly service review | Quarterly | Your sponsor, your finance contact, our director | The quarter in numbers, the roadmap for the next one, contract and commercial review |
Escalation
| Concern | Escalate to | Response |
|---|---|---|
| Day to day | Your named lead engineer | Same working day |
| Delivery or service concern | Head of delivery | One working day |
| Commercial or relationship concern | Director | One working day, meeting within five |
Change requests
Any change to scope, dates or budget is written up with its impact on all three and sent to your sponsor before it is agreed. Nothing is started on a verbal yes. Approved changes appear in the next weekly report with their effect on the plan. On embedded and managed contracts, small changes inside the monthly allowance need no paperwork beyond the ticket.
Security while we work
The practices every engineer works under, on every engagement. Your code never touches our laptops, and every change to your environment carries a name and a time. Full documentation on request.
Access
Named accounts only, single sign-on with hardware-key MFA and conditional access policies, least-privilege roles, quarterly access review, and offboarding within one working day. Every credential lives in a company password manager; nothing is shared over chat or email.
Your code never touches our laptops
All client code is worked on in virtualised development environments (Coder) behind a VPN, under conditional access policies. Nothing is cloned to an engineer’s device. The environments are destroyed when the engagement ends.
Devices
Company laptops enrolled in Microsoft Intune, with full-disk encryption, screen lock, managed updates and endpoint protection. No client data on personal devices.
Chain of custody for your data
Every copy of client data is recorded and audited from the day we receive it to the day it is deleted, so we can show where it has been, who touched it, and that nothing insecure remains once the work is done. Deletion is confirmed in writing.
Changes to your environment as code
Infrastructure and environment changes are made as code (Terraform) through CI/CD, from the virtualised environments, each with a name and a timestamp. Nobody has direct access to your environment except named DevOps operators, and only if you choose to grant it.
Development
Code review on every change, dependency scanning, secrets kept in a vault and never in source, and production changes through a pipeline with an audit trail.
Incidents
A written incident process with a named owner, and notification without undue delay and in any case within 72 hours of any incident affecting your data. You also get a client-facing incident portal: report issues, bugs or security concerns and they go straight to the engineering team and are triaged as the top priority.
Continuity
Documented runbooks for every managed system, tested restores, and at least two engineers familiar with each client environment.
Documentation on request
All of the above is available as written documentation: access and device policies, the environment and change-control model, the chain-of-custody process and the incident process. Ask and it is sent with the proposal.
Insurance, partner programmes, subprocessors and data handling are on trust and assurance, written to be forwarded to a compliance colleague.
Offboarding
What happens if you want to leave. Written down, so you can plan for it.
Notice
Thirty days on every monthly contract: delivery retainers, hosting, and deployment and monitoring. Fixed-price phases end at acceptance. No exit fees, no minimum beyond the stated term.
Ownership
You already own the code, the infrastructure definitions, the documentation and the cloud accounts, because they have been in your name from the start. There is nothing to transfer.
Handover
Current runbooks and architecture documentation, an inventory of every credential and where it is used, a recorded walkthrough for whoever takes over, and rotation of every secret we held.
After
A paid transition period if you want one, at the published day rate, for as long as you need it. Our access is removed on the agreed date and confirmed in writing.
The point of publishing this is that it costs us something to say it, and that is the point. A supplier who cannot describe how you leave is telling you something about how they plan to keep you.
Questions we get asked
How do we know what is going on?
What is in the contract?
Who owns the intellectual property?
How do you handle our code, credentials and data?
Who has access to our environment?
What happens if it goes wrong?
What does it cost and how do we buy?
For insurance, partner programmes and data handling see trust and assurance.
Next step
Request a proposal.
Tell us about the system and the sector. A named engineer replies within one working day. A written scope and an indicative price within two working days of a short scoping call.