KIASA

Cybersecurity

Security designed in, and tested like an attacker

We design security into systems from the first sketch, then try to break them the way a determined attacker would, before anyone else does.

Talk to us
The underside of a bridge, seen from below.

Our view

Security added at the end is expensive, fragile and easy to work around. Security designed in from the start is mostly invisible. We put threat modeling in the first design session and attack testing in every release, so risk is found while it is still cheap to fix.

Most breaches still start with something ordinary: an unpatched server, a forgotten account, a secret in a repository. We look for the ordinary things first.

And when we find a problem, we help fix it. A report that sits in a drawer makes nobody safer.

By the numbers

Measured, not assumed

190
attack-path tests run by our offensive security team against client systems in the last twelve months.
11 days
median time to close a high-severity finding once a client adopts our remediation plan, down from 47.
72 hours
the longest a critical patch may wait on any system we run, written into every managed services contract.

KIASA security engagements, October 2025 to September 2026.

What we do

Security across the whole life of a system

  • Threat modeling and secure design

    Who would attack this, how, and what it would cost them. Answered in the first design session, revisited at every major change.

  • Penetration testing and red teaming

    Our testers chain small weaknesses into real attack paths, against applications, cloud estates and the people who run them.

  • Identity and access

    Single sign-on, least privilege and joiner, mover and leaver processes that remove access on the day it should go.

  • Cloud security posture

    Continuous checks on every account and workload, with misconfigurations fixed in code rather than by hand.

  • Security debt assessment

    Every unpatched system and known weakness priced by exposure, with a plan that pays the most dangerous debt down first.

  • Incident readiness and response

    Playbooks, rehearsals with your leadership and a team on call when something does go wrong.

A forest in fog.

“They found a route into our records that three previous audits had missed, and then sat with our engineers until it was closed.”

Helen AchterbergChief Information Security Officer, Tessera Health

Questions we hear

Before you start

How often should we test?

Before every major release, and at least twice a year for systems that hold customer data. Continuous checks on cloud configuration run every day in between.

Will testing disrupt production?

We agree the rules of engagement first: which systems, which hours, and who to call. Destructive tests run against a copy. Most clients notice nothing until the report arrives.

Do you fix what you find?

If you want us to, yes. Every finding comes with a recommended fix and an estimate, and our engineers can pair with yours to close it.

Can you help with regulators and auditors?

We map our work to the frameworks your regulators use, and prepare the evidence they will ask for. We do not certify you ourselves: that stays independent.

Our leaders

Talk to the people who lead this work

  • Yusuf Demir

    Practice Lead, Cybersecurity

    Twenty years in security architecture and incident response. Co-wrote Security debt.

  • Sinéad Gallagher

    Head of Offensive Security

    Leads the team that tests client systems the way an attacker would, and explains the results to boards.

  • Arjun Mehta

    Principal Security Architect

    Designs identity and access for health, banking and public sector clients. Led the Tessera Health design.

Know where you stand

Ask for a security debt assessment. In three weeks you will know your largest exposures and what it would take to close them.