Security
Cybersecurity Services
Security bolted on afterwards protects the thing you already built, flaws included. We engineer it in: threat models of your actual system, code and infrastructure review by people who write production code, and a fix list ordered by what an attacker would reach first.
What Cybersecurity means in practice
Who it’s for: Organisations that would rather find their weaknesses on their own terms than in an incident report, teams building systems that hold sensitive data, and businesses whose customers have started asking hard security questions.
It is worth being precise about what this service is, because "cybersecurity" covers several very different trades and buying the wrong one is expensive. We are an engineering consultancy. What we do is secure engineering: threat modelling your specific system, designing the security architecture, reviewing code and cloud configuration for the flaws that actually get exploited, hardening identity and access, securing the delivery pipeline and its supply chain, and preparing organisations to evidence their controls when a customer or auditor asks. What we are not is a managed security operations centre watching your alerts around the clock, an accredited penetration-testing scheme provider, or a body that can certify you against a standard. Where you need one of those, we say so and help you scope it.
The reason we work the way we do is that breaches are rarely exotic. The recurring causes are dull and well understood: credentials that were phished, reused or left in a repository; an internet-facing service left unpatched; storage or an access policy misconfigured to be far more open than anyone intended; authorisation that trusts an identifier in a request; and a dependency or build system compromised somewhere up the supply chain. Almost none of it involves a novel technique. It involves ordinary controls that were absent, inconsistent, or applied to most systems but not to the one that mattered.
So the work concentrates there, and it is deliberately prioritised. A scanner will hand you hundreds of findings with no sense of which ones an attacker could actually chain into something damaging; that list creates anxiety rather than security, and it usually goes unread. What we produce instead is a small, ordered set of things that genuinely matter for your system, each with the reasoning, the impact and a concrete fix, followed by help implementing them and by moving the checks into your delivery process so the next release starts defensible instead of being hardened in a panic before an audit.
What you get
- A threat model of your actual system: trust boundaries, the data that matters, who could plausibly attack it and what they would try first
- A prioritised findings report with evidence and a specific fix for each item, ordered by exploitability and impact rather than scanner severity
- Secure code review by engineers who write production code, focused on authorisation, injection, session handling and the business-logic flaws tools cannot see
- Cloud and infrastructure configuration review covering identity, network exposure, encryption, logging and the misconfigurations that cause most real incidents
- Automated security gates in your pipeline: dependency, secret, static analysis and infrastructure-as-code scanning, tuned so the signal is trusted
- Identity, access and secrets design: single sign-on, multi-factor authentication, least privilege, and credentials that are short-lived rather than shared forever
- Compliance-readiness mapping and the evidence to support it, with a clear statement of where an independent assessor is required instead
What Cybersecurity does for you
Prevention is far cheaper than the alternative
The economics here are unusually stark. Fixing a design flaw during a threat modelling session costs a conversation. Fixing it after launch costs a change to live software and a migration. Discovering it through an incident costs the investigation, the disclosure, the regulatory engagement, the customer notifications and the time of everyone who would otherwise be building something. The controls that prevent most incidents are individually cheap and unremarkable, which is exactly why they get deferred and why deferring them is such a poor trade.
Security stops blocking your sales cycle
For anyone selling to larger organisations, security has quietly become a commercial gate. Questionnaires, architecture reviews and evidence requests arrive mid-deal, and a team that cannot answer them promptly loses time and credibility at the wrong moment. Controls that are designed, documented and demonstrable turn that from a scramble each time into a repeatable response, which is worth real money in shortened sales cycles quite apart from the risk removed.
Your engineers stop guessing
Most insecure code is not written by careless people; it is written by competent engineers making reasonable decisions without a clear pattern to follow. When authorisation is a shared, tested mechanism rather than a per-endpoint judgement, when secrets have one obvious home, and when the pipeline catches a vulnerable dependency automatically, security stops depending on everyone remembering. That is what makes it hold over years and staff changes.
Why teams choose us for Cybersecurity
- You want engineers who write and operate production code doing the review, so the findings come with a workable fix rather than a paragraph telling you to sanitise inputs.
- You want honest scoping. We say plainly what we do, what needs an accredited assessor or a specialist provider, and where a cheaper control would meet the requirement you actually have.
- You want prioritisation by real exploitability, not a tool export sorted by severity, so limited engineering time goes to the handful of things that genuinely change your exposure.
- You want security moved into how software is built, so it holds after we leave, rather than a report that is accurate on the day it is delivered and stale a fortnight later.
What Cybersecurity includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Threat modelling and security architecture
We work through the system with your engineers, mapping data flows, trust boundaries and the assets that actually matter, then reason systematically about how each boundary could be attacked: spoofed identity, tampered data, escalated privilege, a leaked secret, a hostile dependency. The output is a shared understanding of where the real risk sits and a set of architectural decisions that remove classes of problem rather than instances, such as a single authorisation mechanism instead of per-endpoint checks, or an isolation boundary that limits what a compromise can reach. Done at design time this is the cheapest security work available; done later it is still the most clarifying.
Secure code review
A manual review by engineers who build production systems, structured around a recognised standard such as the OWASP Application Security Verification Standard and directed by the threat model at the code that matters. We concentrate on what tools miss: broken object-level and function-level authorisation, where changing an identifier returns another customer’s data; injection and unsafe query construction; server-side request forgery; unsafe deserialisation and file handling; session, token and password-reset logic; and the business-logic flaws that only make sense in the context of your domain, such as a workflow that can be replayed or a discount that can be applied twice.
Cloud and infrastructure configuration review
Most cloud incidents come from configuration rather than clever exploitation, so we review the environment against recognised baselines such as the CIS benchmarks and against how it is actually used. Over-permissive identity policies and standing administrative access, storage or databases reachable from the internet, security groups that accumulated exceptions, missing encryption, absent or unretained logging, and the long-lived access keys that turn a single leaked credential into a durable foothold. Findings come with the infrastructure-code change that fixes them, so remediation is reviewable and does not drift back.
Identity, access and secrets
Identity is where most attacks now start, so it gets disproportionate attention. Single sign-on through one identity provider with multi-factor authentication, so joiners and leavers are handled in one place rather than fifteen. Standing administrative privilege replaced with scoped, time-bound access. Service-to-service authentication on short-lived credentials rather than shared static keys. Secrets held in a proper store, injected at run time, never committed to a repository or pasted into a pipeline definition, and rotated on a schedule someone owns. We also check history, because a credential once committed is still exposed after the file changed.
Supply chain and delivery pipeline security
Your software is built mostly from code you did not write, on a pipeline that holds credentials to production, which makes both worth defending. We wire dependency and secret scanning into continuous integration so a vulnerable library or a committed key is caught at the pull request, add static analysis and infrastructure-as-code scanning where they earn their place, and tune the set so the signal is trusted rather than dismissed. Then the pipeline itself: least-privilege build credentials, federated authentication to your cloud instead of stored keys, pinned and verified actions or images, protected branches, and a build process that cannot be quietly altered by anyone who can push code.
Incident readiness and compliance readiness
Two kinds of preparation, both engineering work rather than paperwork. For incidents, we make sure the system can actually be investigated: authentication and administrative actions logged, logs retained and protected from tampering, alerting on the signals that matter, and a runbook covering who is called, how access is revoked and how a system is isolated. For compliance, we map the technical controls behind frameworks such as ISO 27001, SOC 2, Cyber Essentials and PCI DSS onto your environment, close the engineering gaps, and produce evidence an assessor can work with.
Where it fits
A customer security review is holding up a deal
A growing company facing a questionnaire, an architecture review or an evidence request from an enterprise buyer, where the controls are partly in place and cannot be demonstrated. We work through what is being asked, close the genuine engineering gaps in priority order, put the evidence in a form that can be produced repeatedly, and are straight about which answers require an independent certification rather than an internal assurance.
Designing a system that will hold sensitive data
A product handling health, financial or otherwise sensitive information, being designed now. This is where security work returns the most, because decisions about data segregation, tenancy, key management, retention and the authorisation model are nearly free at the whiteboard and painful once live. We threat model the design, set the patterns the team will follow, and review the implementation of the parts that carry the most risk.
Engineering remediation after an incident or a near-miss
An organisation that has had a scare, whether a phishing compromise, an exposed credential or an alarming discovery, and wants to close the gaps rather than hope. Immediate containment and forensic investigation belong to a specialist incident response firm, working with your insurer and legal advisers. What we do is the engineering that follows: understanding how the exposure was possible, fixing it properly, and closing the class of weakness that allowed it.
Making security part of how the team ships
A capable engineering team that wants security to be routine rather than an annual event. We establish the threat model, agree the patterns for authorisation, secrets and input handling, wire the automated checks into the pipeline with the noise tuned out, and work alongside the team through the first rounds of findings so the practice is theirs.
How we approach Cybersecurity
We start with a threat model rather than a tool, because the question that matters is not "what does a scanner flag" but "what would actually hurt this business, and how would someone get there". We map the system with your engineers: where the data lives, what the trust boundaries are, what is reachable from the internet, what an authenticated but hostile customer could attempt, what a compromised third-party dependency or a stolen employee laptop would give access to. That model is what turns a generic checklist into a set of priorities specific to your architecture, and it is usually the point at which one or two genuinely uncomfortable realisations surface.
Then we look hard at the places the model says matter, in code and in configuration, and report in a form that can be acted on: a short ordered list, each item with how we found it, what an attacker could do with it, and what to change. We are equally clear about the things that are fine, because a report that inflates everything to critical teaches people to ignore it. After that the useful work is remediation and prevention: fixing the important items alongside your team, and moving the recurring checks into the pipeline so the same class of problem is caught automatically next time rather than found again by the next review.
How an engagement runs
We begin with scoping and threat modelling, and the scoping half is not a formality. We establish what you are actually worried about, what regulatory or customer obligations apply, what systems are in play and, importantly, what falls outside what we should be doing at all. Then we model the system with your engineers: data flows, trust boundaries, exposure, and the attacks that are plausible against this architecture rather than against a generic one. That model sets the priorities for everything that follows and often changes the shape of the engagement.
Next comes the review itself, directed by the model. Code review concentrates on authorisation, data access and the business logic that carries risk. Configuration review covers identity, network exposure, encryption, logging and the supply chain. Automated tooling runs alongside as a first pass, but its output is triaged by an engineer rather than forwarded, because the value is in separating the handful of real problems from the many that are noise in your context. Anything we can safely demonstrate, we demonstrate, with the reproduction steps written down.
Then we report and remediate, and remediation is the point of the exercise. The report is short and ordered by exploitability and impact, each finding with evidence, consequence and a specific fix, plus a plain statement of what looked sound. We then work through the important items with your team, fix the underlying pattern rather than the instance, verify the fixes, and wire the recurring checks into your pipeline. Where the engagement identifies a need beyond our scope, whether an accredited penetration test, a certification audit or continuous monitoring, that is stated explicitly rather than quietly absorbed.
What a defensible system looks like
It assumes compromise somewhere. Good security architecture is not a hard shell around a soft interior; it is a set of boundaries that each contain the damage when something behind them fails. A stolen credential should reach one environment and not all of them. A compromised service should hold permissions for its own job and nothing more. A vulnerability in a public-facing component should not put it on the same flat network as the database. Reducing blast radius is unglamorous and it is what separates an incident that is contained and disclosed calmly from one that becomes a company-defining event.
Identity does most of the heavy lifting, because in a cloud-centric system it has effectively replaced the network perimeter. That means one identity provider with multi-factor authentication, access granted by role and reviewed, standing administrative privilege replaced with scoped and time-bound elevation, service-to-service authentication on short-lived credentials, and no long-lived static keys sitting in configuration files or continuous integration. Most attacks that matter now begin with a legitimate credential used by the wrong person, which is why controls here return more than almost anything else.
Within the application, authorisation is one mechanism rather than a per-endpoint decision, enforced server-side against the authenticated principal at the point data is accessed, so it cannot be bypassed by calling a different route. Input is validated at boundaries, output is encoded for its destination, and queries are parameterised as a matter of course. Secrets have one home. Defaults are safe, so the easy path is also the secure one, because a control that depends on every engineer remembering it will eventually be forgotten by someone under deadline. And the system is instrumented well enough that a question about who accessed what, and when, has an answer.
What we do, and what needs someone else
We are direct about the limits of this service, because the alternative is a client who believes they have bought protection they do not have. We are not a managed security operations centre: we do not watch your alerts around the clock, and if continuous monitoring and response is what you need, the right answer is a specialist provider, with us building the logging, detection and integration that make their job possible. We are also not an accredited penetration-testing scheme provider. We perform authorised technical testing as part of a review and demonstrate what we find, but where a customer, insurer or regulator requires a formal report under a recognised scheme, that must come from an accredited firm, and we will help you scope it and fix what it finds.
Certification is a similar boundary and worth stating plainly: nobody can both prepare you and certify you. ISO 27001 certification comes from an accredited certification body, a SOC 2 report comes from a qualified audit firm, Cyber Essentials Plus requires an assessor under the scheme, and PCI DSS validation at most levels requires a qualified security assessor. What we do is readiness: mapping the technical controls onto your real environment, closing the engineering gaps, reducing scope where that is the cheaper path, and producing evidence in a form an assessor can accept. That is genuinely most of the work, and it is honest about who signs at the end. The same applies to legal interpretation, so questions about UK GDPR obligations, breach notification thresholds or contractual liability belong with your legal advisers, while we make sure the technical measures behind them exist.
One more limit worth stating in advance: we are not an emergency incident response team. In an active compromise the immediate needs are containment, forensic preservation and coordination with your insurer and legal counsel, which is specialist work with its own disciplines. Call a dedicated incident response firm first. We are useful afterwards, and it is substantial work: understanding how the exposure was possible, fixing it at the root, and closing the class of weakness rather than the instance.
Signs it’s time
- An enterprise customer, partner or insurer is asking security questions your team cannot answer with evidence
- You are building or already running something that holds personal, financial or otherwise sensitive data, and nobody has assessed it properly
- A near-miss, a phishing incident or an alarming discovery has shown gaps you have not systematically closed
- Security today is a checklist someone runs occasionally rather than something built into how software is designed and shipped
Risk-based, evidenced, and free of theatre
Our method is to fix things in the order an attacker would reach them, which sounds obvious and is unusual in practice. A great deal of security spending goes to whatever is most visible or most easily bought rather than to what most changes exposure, which is how organisations end up with an impressive tooling stack and administrative accounts without multi-factor authentication. So we insist on prioritisation grounded in your specific system: what is genuinely reachable, what it would give someone, and what it would cost the business. That produces a short list, and a short list gets done, whereas a long one becomes a document people learn to avoid.
We also refuse to sell through fear, which is more of a discipline than it sounds given how easily security work can be sold that way. We tell you when a control you are considering is disproportionate to your risk, when a cheaper or built-in option meets the requirement, and when the honest answer is that your posture is reasonable and the money is better spent elsewhere. Equally, when something is genuinely serious we say so without hedging. The value of this work rests entirely on the report being trustworthy in both directions, and a consultancy that finds everything alarming is no more useful than one that finds nothing.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Cybersecurity?
A short call with a senior engineer, before you write a brief. If Cybersecurity is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
A fix list you can act on
A short, ordered set of findings with evidence and concrete remediation, prioritised by what an attacker would reach first, not an undifferentiated scanner export nobody reads.
Whole classes of flaw designed out
Authorisation enforced centrally, secrets managed properly, access scoped tightly and defaults made safe, so the same category of vulnerability stops recurring in each new feature.
Questions you can answer with evidence
Controls that are documented, enforced in code and demonstrable, so a customer security review or an audit becomes a matter of producing evidence rather than preparing a story.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A fixed-scope assessment as the usual starting point: threat model, code and configuration review, and a prioritised report with evidence and remediation guidance. Priced by the size and complexity of the system in scope rather than by a headline figure, and it stands alone as a deliverable whether or not you use us for the fixes.
- A remediation engagement, quoted after the assessment because that is the point at which the work is actually known: implementing the priority fixes with your team, correcting the underlying patterns, and wiring the automated checks into your pipeline so the class of issue stops recurring.
- A monthly senior engagement for organisations that want security engineering as an ongoing capability: reviewing significant changes before they ship, maintaining the threat model as the system evolves, keeping compliance evidence current, and being the people who already know your architecture when something needs a fast answer.
- Third-party costs are yours and never marked up by us: commercial scanning or monitoring tools, certification body and assessor fees, and any accredited penetration testing are bought directly by you. We will tell you where free or built-in tooling is sufficient, because much of the security tooling market is sold on anxiety rather than need.
Typical timeline
- 01
Scoping and threat modelling
A few days to a week agreeing what is in scope and what is not, understanding your obligations, and modelling the system with your engineers to establish where the real risk sits and what an attacker would try first.
- 02
Review
One to three weeks of code and configuration review directed by the threat model, with automated tooling as a first pass and an engineer triaging its output, and findings demonstrated and documented as they are confirmed.
- 03
Report and prioritisation
A short, ordered report with evidence, impact and a specific fix for each finding, plus what was sound, walked through with your engineers and leadership so the priorities are understood rather than merely delivered.
- 04
Remediation, verification and embedding
Fixing the priority items with your team, correcting the pattern rather than the instance, verifying the result, and wiring the recurring checks into delivery so the next release starts from a defensible position.
What working with us actually means
Engineers who build, reviewing engineering
Our reviews are done by people who write and operate production code, so findings arrive with a fix that fits your architecture rather than a generic instruction. It also means we understand the cost of a recommendation, and will not propose a control that makes your system unmaintainable to close a marginal risk.
Honest about scope
We tell you plainly what we do and what needs an accredited assessor, a certification body or a specialist monitoring or incident response provider. Being sold a certification by someone who cannot issue one is a common and expensive disappointment, and we would rather lose that part of the work than blur it.
Prioritised by real exploitability
You get a short ordered list of what matters for your system, not an exported tool report. Security time is scarce; spending it on the few items that change your exposure is far more effective than spreading it across hundreds that do not.
Built to hold after we leave
The point is not a report that is accurate on the day it is written. We fix underlying patterns, wire the checks into your pipeline, and leave the team with the patterns and the reasoning, so security is part of how you ship rather than an event you repeat annually.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Services in this practice
The specific services that make up this practice.
Related terms
Weighing the options
The decisions people are usually making at the same time as this one.
Common questions
Do you carry out penetration testing?
We carry out authorised technical testing as part of a security review and demonstrate the issues we find, with reproduction steps, so you are not left with theoretical risk. What we are not is an accredited provider under a recognised penetration-testing scheme, and that distinction matters commercially. If a customer, insurer or regulator requires a formal test report from a certified firm, or your contract specifies a scheme such as CREST or CHECK, you need an accredited provider, and we will say so rather than take the work. Where that applies we are useful on either side of it: scoping the test so it covers what actually matters, then doing the engineering to fix what it finds, which is the part that is frequently underestimated after a report lands.
Can you certify us for ISO 27001, SOC 2 or Cyber Essentials?
No, and neither can any consultancy that also prepares you, because the separation is the point of certification. ISO 27001 is certified by an accredited certification body, a SOC 2 report is issued by a qualified audit firm, Cyber Essentials Plus requires an assessor under the scheme, and PCI DSS validation at most levels requires a qualified security assessor. What we do is readiness, which is where most of the effort sits: mapping the technical controls onto your real environment, closing the engineering gaps, reducing scope where narrowing what is assessed is cheaper than securing more of it, and producing evidence the assessor can work with. We will also say whether a given certification is worth pursuing at all, because for some organisations it is a commercial necessity and for others an expensive way to answer a question nobody has asked.
Do you provide twenty-four hour monitoring or a SOC?
No. Continuous monitoring and response is a staffed, round-the-clock operation and it is a different business from engineering consultancy. Anyone offering it as a side service is either subcontracting it or overstating it. What we do is the engineering that makes monitoring effective and, in many cases, reduces how much of it you need: logging the events that matter and retaining them appropriately, protecting logs from tampering, alerting on meaningful signals rather than noise, and writing the runbook that says who is called and what they do. If you need continuous coverage we will help you choose a managed detection and response provider and integrate them properly, which is a considerably better outcome than a monitoring product nobody has configured or is watching.
We think we have been breached. Can you help right now?
Your first calls should be a specialist incident response firm, your cyber insurer if you have a policy, since many require a nominated responder, and your legal advisers, who will guide notification obligations and timings. Active incident response requires forensic preservation, containment under time pressure and evidence handling done in a way that stands up later, and it is a genuinely distinct discipline from building software. We would be doing you a disservice by taking it on. Where we are valuable is immediately afterwards, and it is not a small piece of work: establishing how the exposure was possible, fixing it at the root rather than at the symptom, closing the class of weakness that allowed it, and rebuilding the identity, access and logging posture so the next attempt has fewer places to land.
What is the cheapest thing we could do that would meaningfully improve our security?
Almost always a handful of unexciting basics rather than anything you buy. Multi-factor authentication on every account that matters, especially administrative ones, and single sign-on so identity is managed in one place. Patching whatever is exposed to the internet, promptly and routinely. Removing standing administrative access so privilege is requested and time-bound rather than permanent. Backups tested by actually restoring them and held so a compromised administrator cannot delete them. Dependency and secret scanning switched on in your repositories, which is free on most platforms. The list is dull and it addresses the causes of a large share of real incidents. If someone proposes an expensive tool before those are in place, they are selling comfort rather than security.
Thinking about Cybersecurity?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Cybersecurity is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.