Cybersecurity

Almost nobody is breached by something nobody knew about.

The headline breaches are exotic. The real ones are a known vulnerability in a dependency you already ship, a credential in a repository, or an admin account that belonged to somebody who left in March. Security is not mostly a matter of buying products. It is a matter of knowing what you run, fixing known problems quickly, and being able to prove both of those things to a customer who asks. Our cybersecurity work covers all three, built into how your software is made and run.

ONE CRITICAL VULNERABILITY IN A DEPENDENCY YOU ALREADY SHIP THE CLOCK STARTS WHEN IT BECOMES PUBLIC, NOT WHEN YOU HEAR ABOUT IT 42 DAYS EXPOSED DAY 0 DISCLOSED DAY 3 WHERE WE AIM TO BE DAY 5 EXPLOITED IN THE WILD DAY 47 ILLUSTRATIVE PATCH DELAY THE WINDOW IS THE RISK. CLOSING IT IS AN ENGINEERING PROBLEM.
Illustrative timeline. Nothing about it requires a sophisticated attacker. It only requires that you are slower than the people reading the same disclosure.
6Checks that run on every change
24/7Support coverage
800+Projects delivered
100+Senior experts

Assessment findings

What we look for first.

None of these are sophisticated and all of them are exploitable. They are the ordinary gaps that turn up in organisations of every size, which is why an assessment starts here rather than with anything exotic.

  • Credentials committed to a repository

    An API key or database password in git history, still valid, often added years ago by someone who has since left. Rotating it is an afternoon. Usually nobody has looked.

    The fix: Rotate the credential, purge it from history, and add secret scanning so the next one is blocked before it reaches a branch.

  • Dependencies with known critical flaws

    Not obscure ones. Publicly disclosed, with exploit code available, in a library the application loads on every request.

    The fix: Patch or upgrade the affected libraries in order of exposure, then scan every build so the next disclosure is flagged on the next build rather than at the next audit.

  • Over-permissioned accounts and roles

    Service accounts with administrator rights because that made a deployment work once, and nobody wanted to be the person who narrowed them afterwards.

    The fix: Map what each account actually uses, cut its rights to that, and put what remains under a scheduled access review.

  • Storage or databases reachable publicly

    A bucket, a management port or a database that answers from the open internet, usually created for a migration that finished long ago.

    The fix: Close the exposure, check the access logs for what was read while it was open, and add an infrastructure policy that stops it happening again.

  • No usable log of who did what

    Logs that exist but cannot answer the only questions that matter during an incident: what was accessed, by whom, and when.

    The fix: Structured audit logging with retention agreed against your obligations, tested by asking it the questions an incident would.

We report every finding to you in full, ranked by what it would cost your business if it were exploited, including the ones that are inconvenient for us to report.

Continuous control

Security that runs on every change.

An annual penetration test tells you about the software you had in February. These checks run automatically on every commit, which is the only cadence that keeps up with a team that ships daily.

Red patch cables connected into a network switch
You cannot protect an estate you have not inventoried. The first deliverable is always a list of what you actually run.
  • Secret scanning

    BlocksKeys, tokens and passwords

    Blocks the commit before the credential ever reaches a branch, and checks the existing history for what is already there.

  • Dependency scanning

    BlocksKnown vulnerable packages

    Every library checked against disclosed vulnerabilities on each build, with automated upgrade requests for the ones that are safe to take.

  • Static analysis

    BlocksInjection and unsafe patterns

    Code inspected for the categories that cause real breaches, tuned so the team is not drowned in findings nobody acts on.

  • Infrastructure policy

    BlocksPublic exposure and weak defaults

    Infrastructure code checked against policy before it applies, so a bucket cannot be made public by a change nobody reviewed closely.

  • Image and artefact signing

    BlocksUnverified builds

    What runs in production is provably what came out of the pipeline, from a commit you can point to.

  • Access review

    BlocksAccounts that outlived their purpose

    Scheduled review of who and what holds which permissions, with the joiners and leavers process wired to it rather than kept in a spreadsheet.

Who it is for

Who security work is for.

Security engineering matters for any business that holds customer data, and most for those facing a security questionnaire, an audit or a regulator. It is engineering work, and it sits alongside your auditor rather than replacing one.

Security engineering fits

  • A customer or partner has sent a security questionnaire you cannot answer with confidence.
  • You need SOC 2, ISO 27001, HIPAA or GDPR evidence, and the engineering behind it is not done.
  • Your team ships often and security checks happen once a year, if at all.
  • Nobody can say for certain who holds which access or what is exposed to the internet.
  • Something has already happened, and you need it contained and explained.

Look elsewhere first

  • You need a certificate issued. That comes from an independent auditor, and we work alongside whichever one you choose.
  • You want a report to satisfy a checkbox with no plan to fix what it finds. A cheaper scan will produce the same document.

What we do

Six areas, from assessment to the day after an incident.

Security assessment

A clear picture of what you run, where it is exposed and what to fix first, delivered as a ranked plan rather than a list of everything a scanner could find.

  • Architecture and threat review
  • Cloud configuration audit
  • Prioritised remediation plan

Application security

Secure design and code, from authorisation logic to the handling of data you would not want in a log file.

  • Authentication and authorisation
  • Input handling and injection defence
  • Secure code review

Cloud and infrastructure security

Least privilege, network segmentation and encryption applied to real environments, not to a diagram of them.

  • Identity and access management
  • Network and workload isolation
  • Key and secret management

Compliance engineering

The technical work behind SOC 2, ISO 27001, HIPAA and GDPR, built as controls that run rather than documents that describe.

  • Control implementation and evidence
  • Audit logging and retention
  • Data residency and handling

Penetration testing

Testing against your real environment with a written scope, and a retest after the fixes so the report ends with resolved rather than reported.

  • Application and API testing
  • Cloud and network testing
  • Remediation retest included

Incident readiness

The preparation that decides how a bad day goes: detection that works, a plan people have practised, and contacts that are current.

  • Detection and alerting
  • Response runbooks and drills
  • Forensic logging and retention
Brilliant Systems exceeded expectations in terms of accuracy, HIPAA-compliant data handling, and cloud-native integration.
Monica Taylor, Chief Executive Officer, Lilli
Read the full review

How we ship it faster

Five times faster, at a fifth of the cost.

5xfaster to deliver
1/5of conventional cost
Get a like-for-like quote

Security work involves a large volume of careful, methodical review that has traditionally been rationed because it is expensive: reading every authorisation path, checking every configuration against policy, writing the control evidence, keeping the asset inventory current. AI tooling does that first pass across the whole estate rather than a sample of it, and our engineers spend their time on the judgement calls: what the risk actually is for your business, and which findings deserve to interrupt your roadmap. AI accelerates the work. Our engineers stay accountable for the decisions and the software that ships.

Time from assessment to controls in production
Conventional delivery Months
AI-first delivery Weeks
  • Complete review, not a sampleEvery authorisation path and configuration file examined, rather than the subset a fixed-fee audit had time for.
  • Evidence written as you goControl documentation produced alongside the implementation, which is the part that makes an audit painless and the part everyone postpones.
  • Findings with fixes attachedEach issue arrives with a proposed patch and a test that proves it, so remediation is a review rather than a research project.
  • Inventory that stays currentAssets, dependencies and permissions catalogued continuously instead of in a spreadsheet that was accurate on the day it was made.

An indicative comparison, not a quote or a guarantee. The gain depends on the size of your estate, the frameworks you need to meet and how much control evidence already exists. We estimate every project individually and put scope, timeline and price in writing, with a like-for-like comparison against conventional delivery, before you commit.

Two engineers working together at a dual-screen workstation
The first hour decides how the rest of it goes, which is why it is rehearsed rather than improvised.

Incident response

When something does happen.

No honest security firm promises this will never occur. What we will commit to is how the first day goes, because that is what determines whether an incident is contained or becomes a disclosure.

  • You are told immediately

    No internal deliberation about whether it is serious enough to mention. You hear from us as soon as we know, including when the mistake is ours.

  • Containment before analysis

    The first priority is stopping it, not understanding it. The full account of what happened comes afterwards and in writing.

  • Evidence is preserved

    Logs and system state captured before anything is rebuilt, because a clean environment with no evidence leaves you unable to answer a regulator.

  • A report you can hand over

    A written account fit to give a customer, an insurer or a regulator, with the timeline, the impact and what changed as a result.

Questions we get asked

Starting with the one about penetration tests.

Is a penetration test enough?

It is useful and it is not sufficient. A test tells you about one system at one moment, and your code changes weekly. The durable value is in the checks that run continuously, with periodic testing to catch what automation cannot reason about.

We need SOC 2 or ISO 27001. Can you get us there?

We do the engineering half: the controls, the logging, the access management and the evidence they produce. The certification itself comes from an independent auditor, and we work alongside whichever one you choose. Much of the pain in these certifications is technical work being done at the last minute.

How disruptive is adding all this to our pipeline?

The failure mode is noise, so we tune before we enforce. Checks run in a reporting mode first, we deal with the existing backlog, then they start blocking. A gate that fires constantly on things nobody fixes gets switched off within a month.

What if you find something serious in our systems?

You are told straight away, before the report, with what we recommend doing about it today. We have never thought a finding was better kept until the presentation.

Do you work with our existing security team?

Usually, yes. Internal security teams often know what is wrong already and lack the capacity to fix it. We are often most useful as the delivery capability behind a plan your team has been unable to fund.

What does a security engagement cost?

It depends on the size of the estate, the frameworks you need to meet and whether you need an assessment, remediation or both, so we do not publish a price list. Within a week of our first call you get a written approach with a cost and time range and the assumptions behind it, which becomes a fixed proposal with scope, price and milestones when you are ready.

Can you help after an incident?

Yes, both the immediate response and the harder work afterwards, which is fixing what allowed it and producing the account your customers and regulator will ask for.

How do you handle our data during an engagement?

Least privilege and time-bounded access, in your systems rather than copied into ours, with everything we do logged in your environment. Access is revoked at the end of the engagement and we confirm it in writing.

Will this slow our developers down?

Marginally at first, then less than the interruptions it prevents. A vulnerability caught in a pull request costs minutes. The same one found in production costs a week and a difficult conversation with a customer.

Related services

Related case studies

Next step

Tell us what your next security review will ask.

A senior engineer reads every enquiry and replies within one business day, with an honest view on what to fix first and what can wait.

Discuss your security

We reply within one business day. No sales sequence, no newsletter.

Certified, partnered and awarded