Four areas, one shape. In each of them there is a point where the machines stop and a named person decides, because that is the step that carries consequence. Everything before it is automated as far as it sensibly goes; everything after it leaves a trace.
Routine decisions run. Consequential ones wait. That is the whole operating model, and it is the reason our work survives an audit rather than complicating one.
Area one
Cybersecurity
Threat detection and response, vulnerability management and testing, security operations, infrastructure and platform hardening. The work usually starts because something is already uncomfortable: an assessment came back thin, a supplier asked a question nobody could answer, or an incident showed the runbook was theoretical.
We work inside your environment and your change process, not beside it. Where a control can be automated and evidenced automatically, it is. Where it cannot, we say so rather than papering over it.
- You receive
- Findings with reproduction steps and severity, a remediation plan sequenced by risk and effort, hardened configurations in your own repositories, and the detection rules written for your stack.
- Evidence produced
- Test scope and method, dated results, before-and-after configuration diffs, and the decision record for anything accepted rather than fixed.
- We need from you
- A named technical counterpart, read access to the systems in scope, and someone empowered to accept residual risk.
- Human approval point
- Before a change reaches production.
Area two
ICT risk and resilience
Operational resilience, continuity, third-party and control evidence, in the context of NIS2 and DORA. This is the area where organisations most often have the intent and the policy, and least often have the evidence that either one is real.
We build the register you can actually maintain, rehearse the failover rather than documenting it, and write the control descriptions in the language the requirement itself uses. Technical, operational, and regulatory perspectives — never legal advice.
- You receive
- A dependency and third-party register that maps to your contracts, tested continuity procedures, control descriptions with owners and frequencies, and a gap list ranked by exposure.
- Evidence produced
- Exercise reports with dates, participants and what failed; register versions with change history; and the trail showing who accepted each residual risk.
- We need from you
- Contract inventory, the people who own the processes, and a window in which a real test can disrupt something.
- Human approval point
- Before a risk is accepted.
Area three
DevSecOps and secure delivery
Secure software delivery, CI/CD, source and infrastructure security, cloud and platform engineering. The usual problem is not that teams refuse security; it is that the security step is slower than the release, so it gets skipped under pressure.
We move the check to where it is cheap — into the pipeline, into the pull request, into the infrastructure definition — so that the fast path is also the safe one. The pipeline gains authority only where someone has agreed it should.
- You receive
- Pipeline stages that fail on what matters and stay quiet on what does not, signed builds and a dependency inventory, infrastructure as code with policy checks, and the runbook for when a gate blocks a release.
- Evidence produced
- Build provenance, dependency inventory per release, policy decisions recorded in version control, and an auditable history of who approved each exception.
- We need from you
- Access to the repositories and pipeline, an engineering counterpart, and agreement on what is allowed to break a build.
- Human approval point
- Before a pipeline gains new authority.
Area four
AI governance and secure adoption
AI risk management, EU AI Act considerations, guardrails, human oversight and traceability — without losing audit evidence. Most organisations are not building models; they are buying tools that contain them, which is a supplier and oversight problem before it is a technical one.
We map where AI already touches your processes, decide with you which steps may run unattended and which may not, and make the oversight leave a record instead of living in someone's memory.
- You receive
- An inventory of AI use across processes and suppliers, a classification of which steps carry consequence, guardrails and oversight points implemented, and transparency wording where users must be informed.
- Evidence produced
- The decision log for every step allowed to run unattended, oversight records naming the person, and supplier documentation collected and assessed.
- We need from you
- Visibility of the tools in use, including the ones bought outside IT, and a business owner for each process in scope.
- Human approval point
- Before an agent acts without review.
What you can put in the audit file matters more than what we did.
Every engagement is scoped so that it ends with something durable in your hands: a register you maintain, a pipeline that keeps working, a decision trail that answers the question a supervisor will eventually ask. If a piece of work cannot produce that, we will tell you before it starts.
Limits
What we do not do
We do not give legal advice, and we do not represent you before a supervisor. We are not a managed security service provider and we do not staff a 24/7 desk. We do not resell tooling, so there is no product we need you to buy.
Where a piece of work sits outside that line, the honest answer is a referral, and you will get one.
Next step
The fastest way to find out if this fits.
Tell us what is uncomfortable right now — an assessment, a deadline, a supplier question you could not answer. A short call is usually enough to say whether this is our work or someone else's.
Regulation notes
Or start from what is on your desk.
The practitioner pages — dated, sourced, and written for engineers and risk officers rather than for search engines.