mtech labs ai
Eastbourne · UK
/ Secure development

Secure by default — from the first commit to production.

SSDLC is a discipline, not a certificate. This is how we actually do it — threat-modelled before code, scanned continuously, independently reviewed, and hosted on infrastructure we own and run.

01/ Before code

Threat modelling before the first line.

The cheapest time to fix a security problem is before it exists. We spend real time on the shape of the system before anyone opens an editor.

  1. Architecture review before the first line

    We map the components, trust boundaries and data flows on paper before anyone writes code. Obvious mistakes get caught here — not in production.

  2. Identity and permission model, written down

    Who can do what, which role can see which data, which system acts on behalf of which user. Documented as a deliverable, not assumed in the developers' heads.

  3. Data-flow mapping

    Every piece of personal or sensitive data tracked end-to-end — where it enters, where it lives, who it leaves with, how long it stays.

  4. Failure modes on the table

    What happens if a service is down, a token leaks, a dependency is compromised, a user's account is taken over. Designed for, not hoped against.

02/ How we build

Secure-by-default build.

The defaults do most of the work. If the defaults are right, the normal path a developer takes is also the safe one.

  1. TypeScript end-to-end

    Strict types from the database to the UI. A whole class of runtime bugs — and a fair chunk of security issues — never happens.

  2. Identity-aware APIs from commit one

    Every endpoint authenticated and authorised by default. No 'we'll add auth later' — that's how things get deployed without it.

  3. Least-privilege service accounts

    Services get the access they need and nothing else. Rotated, scoped, audited.

  4. Secrets in a vault, not in .env

    Credentials, API keys and tokens live in a managed secret store with access logging — not in a file someone might commit.

  5. Dependencies pinned and reviewed

    Lockfiles respected, versions upgraded deliberately, new dependencies reviewed before they're added to the tree.

  6. Branch protection and required review

    Nothing lands on main without a second pair of eyes. Signed commits. Protected branches. Required checks green.

03/ Continuous scanning

Aikido, every commit, every release.

Static analysis, secrets, dependencies, infrastructure — scanned as code lands and as containers build, not once a quarter.

Aikido

Aikidoruns across every project we build — SAST on the source, secret-leak detection on every commit, CVE scanning on dependencies, IaC checks on the infrastructure code, container-layer scanning on the images, and runtime posture checks on what's actually deployed. Findings are triaged per sprint with severity thresholds that block release — not a dashboard nobody reads.

04/ Independent testing

Optional independent testing by Zoonou.

For engagements where it matters — regulated workloads, high-stakes launches, procurement-sensitive clients — we bring in genuine external assurance before release.

On a case-by-case basis — where the risk profile justifies it or the client asks for it — we bring in Zoonou, an independent UK software-testing firm. Zoonou don't review code; they embed with the delivery team during sprints and test the software against user journeys, documentation and stakeholder expectations. CREST-accredited penetration testing (and soon CHECK) sits alongside that, with performance testing and accessibility auditing where the engagement needs them. Zoonou have tested a number of AI applications and are standing up a specific AI Assurance service — both directly relevant to the work we ship here.

05/ Where it runs

Hosted on our own platform, not re-sold from a hyperscaler.

Nutanix hyperconverged infrastructure, Fortinet-protected perimeter, UK-based, operated by us. A differentiator, not a footnote.

Fortinet

Most firms who build what we build re-sell a slice of AWS, Azure or GCP. We don't. Production systems we build — and the platforms we run for clients — live on our own Nutanix hyperconverged stack behind a Fortinet-protected perimeter, in UK data centres, operated by our own team.

  • UK data residency, known and fixedNo surprise region transfers, no sub-processor chain you can't name.
  • No noisy-neighbour surprisesDedicated capacity we size for the workload, not shared tenancy on someone else's metal.
  • A network posture we actually ownFirewalls, segmentation, WAF and SIEM configured and tuned by the same team that runs the app.
  • Predictable costNo egress-fee cliffs, no invoice surprises after a busy month.
  • We patch, we monitor, we own the incidentOne throat to choke — hosting and application run by the same practice.
We are delighted with the service that we've received from M-Tech, the Fortinet solution is a fantastic way to give us proper insight into the performance and security of our network.
Jay Visram, Senior IT LeadGolding Homes
Read the Fortinet case study
06/ When something goes wrong

Incident response — practised, not improvised.

Every production system will have a bad day. What matters is how we behave on that day.

  1. On-call rota with a named owner

    Every production system has a person who picks up the phone out of hours — not a generic alias nobody watches.

  2. Containment playbook

    First hour steps are documented: isolate, rotate, preserve evidence, stop the bleed before working out the root cause.

  3. Client-comms clock

    If it affects you, you hear from us fast — not a week later when the write-up is polished. Holding messages beat silence.

  4. Post-incident review, written up

    Every real incident gets a blameless review and a short written note. What happened, what we changed, what we're watching for next.

  5. Regulator notification path

    For personal-data breaches, the 72-hour ICO clock is understood and the notification path is pre-mapped — not worked out mid-crisis.

  6. Restore, tested

    Backups aren't backups until you've restored from them. We rehearse the restore, not just the backup.

/ Accredited through M-Tech Systems

The certified frame our engineering sits inside.

Secure development isn't a tick-box on top of a delivery team — it's a discipline anchored to independently assessed controls for information security, quality, environmental management and baseline cyber hygiene.

  • ISO 27001

    / Information security

    Data classification, access control, audit trails and incident response applied to every system we ship. The scaffolding that makes “where does the data go?” a question with a clear, defensible answer — not a shrug.

  • ISO 9001

    / Quality management

    Change control, documented acceptance criteria and version history applied to AI and automation work. What turns a weekend proof-of-concept into a production system you can still reason about six months in.

  • ISO 14001

    / Environmental management

    Model selection, hosting and hardware decisions weighed against energy, lifecycle and supplier impact. The quiet discipline behind not running a frontier model for a task a smaller one handles just as well.

  • Cyber Essentials Plus

    / Baseline cyber hygiene

    Independently tested controls — patching, configuration, identity, malware protection — verified annually rather than self-asserted. The floor every AI rollout sits on, not a certificate we printed ourselves.

  • Assurix

    In progress
    / MSP trustmark programme

    A live assurance programme aligned to NCSC CAF 4.0 — privileged access, supplier risk, monitoring, incident response. Verified evidence, continuously re-checked, for the controls AI and automation rollouts depend on.

  • Continuous assurance

    / Secure development & hosting

    Every codebase — ours and the software we host for customers — runs under Aikido for continuous code, dependency and container scanning. Hosted systems are kept on current framework and library versions and subject to continuous penetration testing. The control loop that turns “secure at go-live” into “secure six quarters in.”

/ Backed by

Delivered with the compliance and security discipline of M-Tech Systems — Cyber Essentials certified, aligned to NCSC CAF 4.0, progressing through the Assurix trustmark programme. Code continuously scanned by Aikido, with independent QA and penetration testing by Zoonou available where engagements call for it, and hosted on our own Nutanix / Fortinet platform.

Back to Our Approach
/ Start a conversation

Want the full SSDLC write-up?

Procurement team asking hard questions? We'll walk you through the controls, the evidence and the independent reviews — or send a written pack you can hand straight on.