Privacy isn't a feature.
It's the foundation.
We made a deliberate choice to build differently; self-hosted, containerised, private, and deeply customisable. The work security professionals do demands nothing less.
The SaaS model was never built for security work.
Most security tooling asks you to accept a fundamental contradiction: you're in the business of protecting sensitive data, but your own operational infrastructure and data (your clients, engagements, findings) lives on someone else's servers.
Often that's a public cloud, encrypted (if at all) with keys you don't hold.
That arrangement might be acceptable for a time-tracking or cooking app. For security delivery tooling, the compromises are real and the risks compound over time.
Every engagement you log, every client you onboard, every finding you record, lives on infrastructure you don't own and can't fully audit. You have access while the subscription holds and the terms don't change. That's not ownership; it's a tenancy agreement.
Multi-tenant SaaS platforms pool data from dozens to hundreds of tenants. A single misconfiguration, breach or insider can expose many tenants at once, and you have no visibility and no control over the blast radius.
Pricing changes. Terms change. Features get removed. Services get acquired, pivoted, or sunset. When your operational backbone lives in someone else's cloud, you're one announcement away from disruption, and your clients' data is hostage to a migration you didn't plan for.
Per-seat pricing, monthly project caps, and tiered storage
quotas turn your own growth into a cost you can't predict.
The more successful your practice, the more aggressively
the pricing model works against you.
Your success becomes their revenue opportunity.
Every handoff is a
trust boundary.
In threat modelling, every point where data passes to another party's control is a trust boundary, and a potential exposure surface. SaaS tooling routes your data through infrastructure you don't own, arriving as either a vendor-controlled "dedicated" instance or a shared multi-tenant pool. Either way, it's their infrastructure.
With self-hosted, the chain collapses. Your data is stored and processed in your environment, and you choose the topology: one multi-tenant instance or isolated per-client deployments. Either way, it's yours.
Self-hosted
by design.
Self-hosting isn't a compromise position: it's a deliberate architectural decision, because it's the model that gives you genuine control over where your data lives. Everything runs on your infrastructure. Nothing is shared with other customers. The only call home is a daily licence heartbeat, and it carries no client or scan data.
Containerised deployment means you can run on your own hardware, a private VPS, or a restricted network, with offline installs from signed, cosign-verified images (full read/write needs the daily licence heartbeat). You define the update schedule, the network policy, and the access controls.
Your client data, findings, engagement history, and operational records never touch a vendor's shared platform. What lives on your hardware stays on your hardware.
Fully containerised and self-contained. Deploy on your own server, a private VPS, or a restricted network. Clean dependencies, no cloud requirement.
Deploy separate instances per client or security tier. Vendor data, client data, and internal operations remain cleanly isolated at the infrastructure level.
The whole line,
not one slice.
Most security tooling owns a single stage of the work and leaves you to stitch the gaps by hand. We built the opposite. No names, just the shape of the difference, across the things that actually decide an engagement.
Built for work where
the stakes are real.
Certain engagements don't allow for ambiguity about where data lives. Clients in regulated sectors, government bodies, defence supply chains, and legal or financial institutions routinely ask the question: "Where does our data go?"
With BREAKLINE SECURITY, the answer is unambiguous: it stays on infrastructure you control, which you can bring inside your existing certification scope. You can tell your clients that with confidence, and show them.
Working at SECRET or above? Classified systems are assured and accepted by their risk owner, not by a software vendor. Dispatch installs from signed images without internet access, but it then needs a daily outbound licence heartbeat, and goes read-only after 14 days without one. Tell us about your environment and we'll be straight with you about whether it fits.
Keep it inside the scope you've already certified.
Most regulated testing is bought from assured or certified suppliers: NCSC CHECK companies, CREST members, CBEST and STAR-FS providers, and firms with Cyber Essentials Plus, ISO/IEC 27001 certification or a published NHS DSPT assessment. Many of these look at how engagement data is handled: CHECK, for example, requires Cyber Essentials Plus on every system that stores or processes customer engagement data.
A SaaS delivery tool puts someone else's system inside that scope: you rely on their assurances, and every client questionnaire and audit has to account for it separately. Dispatch can run inside that scope: on systems your certification already covers, under your access controls, logging and data-handling procedures. It becomes part of your assured environment instead of an exception to it.
One fewer processor in the chain.
When your delivery tool is SaaS, its vendor processes your clients' data, typically making it a processor or sub-processor under UK GDPR Article 28. That brings a processing agreement, sub-processor notices, their hosting provider's own sub-processors, and possibly international transfer assessments. For financial-sector clients it adds another third party holding their data, weighed under frameworks such as the PRA's SS2/21, or DORA for EU entities. Self-hosted software is still part of their supply chain; it just doesn't hold the data.
Self-hosted, BREAKLINE doesn't host or receive your client data: the licence heartbeat carries none. In normal operation, we are not a processor of your client data. The chain ends with you and the infrastructure you choose.
- Your client
- You
- Tool vendor
- Vendor's cloud
- Their sub-processors
- Your client
- You
No usage telemetry.
No client data to us.
Privacy isn't a setting you toggle or a policy you accept. It's built into how the platform is architected.
-
No usage telemetry or analytics: the licence heartbeat is the only call home
-
Client and scan data is never sent to us
-
Scans, OSINT lookups and email go only where you point them
-
No hosted service holding your data
-
Rides out outages: 14 days read/write without a heartbeat, then read-only, never locked out
-
Runs in containers, separate from other workloads on the host
-
Supports your compliance: data stays inside your control boundary
-
You define the update schedule, with no forced upgrades
-
Clean licensing: you know what you're running and why
Your tooling should earn that same trust.
When you deliver a penetration test, red team engagement, vulnerability assessment or audit, you're handling information that could be catastrophic in the wrong hands.
The tooling you use to manage, report, and store that work should meet the same standard you'd set for your clients.
Self-hosted means you can answer data-handling questions with certainty, not with "it's stored securely by our provider" but with a specific answer you can check on your own network.
can't control."
That principle runs through every architectural decision we make. It's why we build self-hosted instead of SaaS. It's why we ship as containers you can inspect and run anywhere. It's why our licensing is clear and our pricing doesn't punish success.
Security practitioners spend their careers helping clients regain control of their environments. We think their own operational tooling should offer them the same thing.