Consulting

Cybersecurity Consulting

Practical security engineering, described honestly

How this is usually engaged

Often begins with a short assessment engagement, followed by remediation support delivered alongside your engineers so the practices remain after we leave. Formal certification audits are carried out by accredited assessors, who must be independent of the work; our role is preparation, remediation and engineering support ahead of such an audit, and we will not be your assessor.

Start a project brief

Practice: Consulting
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Threat modelling, secure development practice, control implementation and incident response preparation — engineering support that improves your defences and prepares you for assessment by others.

01What this solves

The problem this addresses

Security work tends to arrive as a demand from outside: a customer questionnaire, an insurer, an investor, or an incident at a competitor. The response is often to buy a product or to chase a certificate, neither of which changes how software is built or how access is granted on a Tuesday afternoon. Meanwhile the ordinary weaknesses persist — shared credentials, dependencies nobody updates, logs that would not reconstruct an incident, and no rehearsed answer to the question of who to ring first.

02Capabilities

What is included

Threat modelling

Structured sessions per system: what an attacker would want, the routes available to them, and which controls address each route. Produces a prioritised list of realistic threats rather than a generic checklist.

Secure development lifecycle

Security built into how software is produced — design review, code review standards, automated checks in the pipeline, and a defined path for handling a vulnerability report. Practices your team runs, not a document filed away.

Dependency and supply chain management

Inventory of what you depend on, automated alerting on known vulnerabilities, a patching cadence people can sustain, and build pipelines that verify what they are pulling in.

Access control and secret handling

Individual accounts, role-based permissions, multi-factor authentication, and secrets held in a managed store with rotation and access logging rather than in configuration files or a shared vault of passwords.

Logging and detection

Logs sufficient to reconstruct who did what and when, retained for an agreed period, with alerting on the events that actually matter. Most organisations discover their logging is inadequate during an incident.

Incident response preparation

A written plan with named roles, contact routes, decision thresholds and communication templates, rehearsed in a tabletop exercise. Preparation, not a retained response service — we will say plainly if you need one of those.

03Use cases

Where this work usually starts

Answering a customer security questionnaire

An enterprise buyer has sent a long assessment and the honest answers are currently unflattering. We help close the real gaps and describe accurately what is in place.

Professional Services

Preparing for an external audit

Mapping your controls to the requirements an accredited assessor will examine, closing gaps and assembling evidence — before the assessor arrives, and separately from them.

Finance

Hardening a product before it handles sensitive data

An application about to take on patient, financial or child-related data, where the controls appropriate to that data have not yet been designed in.

Healthcare

04Approach

How we approach it

We work on practice rather than posture. That means threat modelling the systems that matter, reviewing how code is written and reviewed, tightening how access and secrets are handled, making logs sufficient to reconstruct events, and rehearsing the first hour of an incident. Where you are heading towards a formal assessment, we help you prepare: mapping controls to the requirements your assessor will examine, closing gaps and assembling evidence. We do not describe any system as secure — we describe the specific controls in place, what they address and what they do not.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Scoping and authorisation
Which systems, which data, what access we are granted and what testing is authorised — named systems, named window, named contact who can stop it. In writing before anything begins.
02
Assessment
Threat modelling workshops, code and configuration review, examination of access, secrets, logging and dependency handling. Evidence gathered rather than assumed.
03
Findings and prioritisation
Findings with impact and likelihood, discussed with your team so severity reflects your context. Circulation restricted to a named list.
04
Remediation support
Engineering work done alongside your team — control implementation, pipeline changes, access restructuring — so the capability remains after the engagement.
05
Preparation and rehearsal
Evidence organised ahead of any external assessment, and the incident plan rehearsed with the people who would actually be called.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Threat models per systemAssets, threats, existing controls and gaps, in a format your team can maintain.
Control assessmentCurrent controls described accurately, with what each addresses and what it does not.
Prioritised remediation planOrdered by risk reduced per unit of effort, with owners and realistic dates.
Secure development standardsReview criteria, pipeline checks and vulnerability handling process, written for your stack.
Incident response plan and tabletop exercise report
Evidence pack for external assessmentPolicies, configurations and records organised against the requirements an assessor will ask about.

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js
Python

Data & Storage

PostgreSQL

Cloud Platforms

Amazon Web Services

DevOps & Operations

Terraform
GitHub Actions
Sentry

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

We hold ourselves to the practices we recommend. Access to your environments is least-privilege, individually attributed and time-limited, with credentials issued to named people and revoked at engagement close. Findings are handled as sensitive material with restricted circulation and an agreed disclosure route. We do not run intrusive testing against production without written authorisation naming the systems, the window and the contact who can stop it.

Our full security and quality approach

09Questions

Asked before we start

Can you certify us to a security standard?

No. Formal certification audits are performed by accredited assessors, and independence from the work being assessed is a condition of that role. Our part is preparation, remediation and engineering support ahead of such an audit: closing gaps, implementing controls and organising evidence. Choosing and engaging the assessor is yours to do.

Will this make our systems secure?

No engagement can make that claim, and you should be wary of anyone who does. What we can do is reduce specific, identified risks and raise the cost of an attack, then describe accurately which controls are in place and which threats remain unaddressed. Security is a practice you sustain, not a state you reach.

Can you tell us what data protection law requires of us?

No — we do not give legal advice, and obligations under regimes such as data protection and financial regulation depend on jurisdiction, sector and circumstance. Take that advice from your own lawyers or compliance advisers. Bring us the technical requirements they specify and we will implement them, document how each is met, and tell you where a stated requirement is not achievable as written.

When do you tell a client they do not need this?

Frequently. A small organisation with no custom software and no sensitive data is usually better served by enabling multi-factor authentication everywhere, patching promptly, backing up with a tested restore, and training staff on phishing — none of which requires a consultant. We say so, and we are happy to point out the free guidance from your national cyber security body.

START HERE

Talk to us about Cybersecurity Consulting

The project brief takes about five minutes and gives us enough to have a useful first conversation about Cybersecurity Consulting rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.