Four areas, and where each one stops.

01 · For a CTO or an engineering lead

DevSecOps

The trigger is usually one of four: a customer security questionnaire is holding up a signature, an investor has started asking, a CRA deadline is on the calendar, or you already know the pipeline is dirty and nobody has had a week to spare.

All of it runs remotely, because the work is in the repository. The demonstration runs on your code rather than on someone else's case study, which is also why nothing external is needed to establish whether the work is any good.

What the engagement produces

• A CI/CD chain review: what runs, with which credentials, what can inject into a build, and what a compromised dependency would reach.
• Container hardening: base images, build layers, runtime privileges, and what ends up baked into a published image that should not be there.
• Secrets handling: where they live, who can read them, how they rotate, and what the recovery path looks like when one leaks.
• An SBOM produced by the pipeline for every shipped artefact, rather than assembled by hand once and out of date by the next release.
• A published coordinated vulnerability disclosure policy: the intake path, who reads it, and the timelines you are prepared to stand behind.

What it does not cover

• Not a penetration test of the running application. That is a different engagement with a different scope, and calling a code review by that name would be dishonest.
• Not a rewrite. Findings come with the change that fixes them, but the application stays yours to build.
• Not running your platform. The pipeline changes hands back at the end of the engagement, and you keep operating it.

02 · For a CIO with a funded programme

Security project management

The trigger is a programme that already has a budget and has either just started or already slipped: a migration, the integration of a subsidiary, an ERP rebuild, or the exit from a long-standing supplier.

Nobody buys project management in the abstract. What is bought here is someone who holds one named piece of work, on a scope written down before it starts, and who is reachable on the day a decision cannot wait.

What the engagement produces

• A scope and a risk register where every line has a named owner inside your organisation, not a role in the abstract.
• A decision log: what was decided, on what basis, and what was traded away. It is what makes a programme survive a change of people.
• Security requirements written into integrator and supplier contracts before signature, while they still cost nothing to add.
• Acceptance criteria that can actually be failed, and are checked against the delivered system rather than against the slide deck describing it.
• Steering material a CIO can put in front of a board without rewriting it first.

What it does not cover

• Not staff augmentation. This is one person holding a project, not a body added to a delivery team.
• Not the build itself. The integrator integrates and the vendor delivers; the engagement makes sure both are held to something written.
• Not signing decisions that belong to your organisation. Options come with a recommendation and its reasoning; the arbitration stays where the accountability sits.

Two moments in this engagement call for being physically present: the kickoff, and each critical milestone. They are named in the proposal, with the travel, so that neither is discovered halfway through.

03 · For whoever wired it up

AI security

An LLM or an agent has been connected to internal data, and someone has asked whether that is safe.

It is a fair question, and the attack surface is not the one people expect: instructions hidden inside a document the model is asked to read, data leaving through the context window, agents that act rather than answer, and MCP servers exposed far wider than anyone intended. A review walks that surface, then writes down what was found, what is reachable today, and what to change first.

The detail lives on its own page, including what the review produces and what it refuses to promise.

Read the AI security page →

04 · For an organisation without the post

Delegated CISO

The trigger is a security function that has to exist before the full-time post can be justified: a customer, a regulator, an insurer or a board has started asking questions that need a single, consistent answer.

It is the function held on a defined cadence, not a title on an org chart.

What the engagement produces

• Governance that fits the organisation as it is: policies short enough to be read, owners who know they are owners, and a review rhythm that survives a busy quarter.
• A measured gap against a published framework, scored the same way each time so that the second measurement means something next to the first.
• Answers to vendor security questionnaires, written once, kept current, and reusable the next time a customer sends their own version of the same fifty questions.
• Audit preparation: the evidence an auditor will ask for, collected before the audit rather than during it.
• Tabletop exercises and crisis preparation: who decides, who speaks, what gets said, and what the first hour looks like when the usual tools are the ones unavailable.

What it does not cover

• No certificate and no attestation of conformity. Neither is ours to issue.
• Not a monitoring or on-call duty. Crisis preparation is written and rehearsed here; the detection and response capability itself is a separate build.
• Not the accountable officer of your organisation. The function is held and reported on; the accountability stays inside the company that carries the risk.

The framework is the authority

Findings are written against published sources: NIST CSF 2.0, ANSSI guidance, the text of NIS2, the Cyber Resilience Act, the AI Act. Every one of them can be re-read against the source rather than against an opinion, which is what makes a gap arguable instead of personal. Where a source says nothing, the finding says so.

That also fixes where this work stops. Kodetis brings an organisation into shape; a certification body certifies it. Those are two roles, they are held by two different parties, and no engagement here mixes them. It is a rule of conduct rather than a limitation, and it is the same rule that makes the assessment worth reading.