Skip to main content

What we will say about security, and what we will not.

Event infrastructure sits close to a company's most sensitive records. That deserves precision rather than reassurance. This page describes the architectural principles we design to.

Statement of restraint

We display no compliance certifications, audit reports, uptime figures or incident history on this site. Where such attestations exist for a deployment, they are shared under review with your security team — not shown as badges to visitors.

01Design principles

Principles we hold in the architecture

Data minimisation

A stream should carry the fields a workload needs. Where identifiers are enough, payloads stay out of the log.

Boundary validation

Schema is enforced at ingest, so malformed or unexpected data is rejected at the edge rather than propagated.

Explicit retention

Retention is a decision per stream, made against replay requirements — not an unbounded default.

Least privilege

Access is scoped per stream and per workload, so a consumer reads only what it needs.

Traceable change

Workload versions and their start positions are recorded, so it is always answerable which code produced a result.

Environment control

The platform is designed to run inside infrastructure you control, keeping residency aligned to your existing boundaries.

02 Due diligence

Questions we expect, and answer in writing

Security review is part of the technical conversation, not a later formality. These are answered specifically for the deployment being discussed.

  • 01Where does event data physically reside, and who can reach it?
  • 02How is data separated between environments and between workloads?
  • 03What is retained, for how long, and how is deletion handled across derived state?
  • 04How is access granted, reviewed and revoked?
  • 05What is logged about administrative and operational actions?
  • 06What happens to derived views when an upstream record must be removed?

Reporting a security concern

If you believe you have found a vulnerability affecting Ferrite, contact us through the form on the contact page and mark the message as a security report. Describe the issue and how it can be reproduced. We will not publish a disclosure timeline we cannot yet commit to; the report is handled by the engineering team directly.

Contact the team

Next step

Put your security review to us early.

We would rather answer hard architectural questions in the first session than discover them at procurement.