Security by design: how Lunon engineered trust from day one

At Lunon, the goal is to be the firm clients trust with their most sensitive material.

That trust is not abstract. It arrives as data rooms, CIMs, operating data, and management interviews. It arrives before the work starts, and it has to be protected before the first analysis is run.

So we treated security as a design constraint, not a feature to add later.

A culture of security, not an afterthought

The controls came before the headcount. We scoped access per engagement, logged every access to an append-only trail, and set retention rules before we had a dedicated security function. The founding engineering team built the systems and owned their security in the same breath.

That order matters. A firm that adds security after it has clients has to retrofit it into habits that already exist. We did not want habits to form first.

Our SOC 2 Type I report was issued against the security, availability, and confidentiality criteria, and the Type II observation period is underway.

Compliance is an outcome, not the driver

SOC 2 matters to us because it matters to our clients. It is a shared language for what good looks like.

It is not the ceiling. An audit tells you the controls existed at a point in time. It does not tell you whether they would hold against a motivated attacker with a stolen laptop.

So we start from the threats that apply to a firm like ours: a compromised team member, a malicious document in a data room, a provider that quietly changes its terms. The controls follow from the threats. The certification follows from the controls.

Testing we do not grade ourselves

• Scanning. Every internet-facing service is scanned for vulnerabilities weekly. Every deploy is checked for vulnerable dependencies and container images. Every change is scanned for secrets before it can merge.

• Deadlines. Findings carry remediation deadlines by severity: seven days for critical, thirty for high, ninety for medium. Open findings are reviewed weekly by engineering and monthly by leadership.

• Penetration testing and audit. The full platform, from the browser to the database and the AI systems in between, is tested against real attack paths. The most recent audit found no critical, remotely exploitable exposure. Thirteen of seventeen findings were fixed with tests, and the rest are documented with owners and dates.

• Client review. Clients are welcome to run their own assessments before an engagement. We treat every finding as a gap in our own review rather than a difference of opinion.

Commitments, not assurances

A security page is a claim. A contract is a commitment.

Every engagement begins under NDA. Our terms carry binding commitments on how material is stored, who can access it, that it will not train models, and what happens to it at close. Those commitments apply by default, so a client does not have to negotiate for them.

The same standard applies to the providers we rely on. Model providers must accept zero data retention and no training on client material, and the platform checks those terms before any engagement runs. When a provider cannot meet the bar, we do not use it.

Governance

Security has an owner, a review cadence, and a place on the leadership agenda. Open vulnerabilities and time to remediation are reviewed every week in engineering and every month with leadership, and the policies behind them are reviewed every quarter.

A layered approach

1. Foundational controls. Material is encrypted in transit and at rest. Each client’s data is isolated at the database layer, so one engagement cannot reach another’s material even by mistake. Access follows least privilege, and changes to the systems that handle material are reviewed before they ship.

2. Monitoring. Every access is written to an append-only audit trail that cannot be edited or deleted, so unusual behaviour is visible and reconstructable.

3. Deletion. Material is kept for the life of the engagement. Deleting an engagement removes its documents, deliverables, and working files, and backups roll off within fourteen days.

AI-specific risks, by design

AI-native work introduces risks a traditional firm never had to consider.

Material could be used to train a model and surface for another client. We do not train on client material, and neither do the providers we use. Material is used to do your work and for nothing else.

A crafted document could try to steer a system into a wrong or leaking answer. We treat every document in a data room as untrusted input and every output as a claim that has to be checked before it reaches a deliverable. Systems execute the work. Experts own the judgment.

The job is not finished

Threats change. Our clients’ expectations rise. The right response is not a bigger checklist but a standing habit of asking what could go wrong next, and fixing it before it does.

Security is not a feature of Lunon. It is the condition for being trusted with the work at all.