Security
Client confidentiality is a design constraint, not a settings panel.
Field review work is confidential practice. Fermito treats every report, photo, and supporting document as client material under the firm’s custody — and the product is built to that standard before the firm signs. This page carries the full posture: data handling, DPA availability, incident policy, and the SOC 2 roadmap.
By the rule
Field review is confidential practice under PEO guidance.
Field review in Ontario is practice of engineering under PEO Practice Bulletin — Field Reviews, and practice of engineering stays with the licensed practitioner. Fermito is built as a drafting assistant inside that rule, not around it. Nothing Fermito ships is auto-signed, auto-sent, or auto-distributed.
Customer report content is confidential client material by default. It is never used as training data — not opt-in, not opt-out, never. The firm’s revisions tune the firm’s own prompt. Other firms never see it.
Fermito’s handling posture is written against the Trust Service Criteria of SOC 2 and is moving toward a Type I audit on the roadmap below.
Data handling
Four things Fermito makes concrete before a firm signs.
The list below is the posture Fermito runs on today — not a roadmap promise. Each item is a decision that shapes how the product is built, not a box on a compliance form.
01 · Tenant isolation
Firm data lives on a single, isolated tenant.
Visit records, generated drafts, photos, and supporting documents are stored against the firm's tenant and accessible only to seat-holders the firm admin has provisioned. No cross-tenant reads, no shared vector spaces, no background indexing across firms. A report written for Firm A is never visible to Firm B — at any layer of the stack.
Tenant-scoped storage · admin-provisioned access · no cross-tenant retrieval
02 · No training on customer data
Customer report content is never used as training data.
Not opt-in, not opt-out, never. Fermito's prompts are tuned against a published reference corpus and the firm's own template — not against other firms' sealed work. A firm's revisions teach the firm's tuning, full stop. The no-training posture is a product constraint Fermito wrote before it wrote the code.
Explicit no-training · per-firm prompt tuning · reference corpus is published material only
03 · Encryption in transit and at rest
TLS in transit, AES-256 at rest, managed keys.
Every request between the firm's devices and Fermito moves over TLS 1.3. Stored data sits on managed infrastructure with AES-256 encryption at rest and key rotation handled by the platform providers Fermito runs on. Photo blobs, report JSON, and supporting documents are all covered by the same envelope.
TLS 1.3 in transit · AES-256 at rest · managed key rotation
04 · Export and delete on request
The firm owns the data end to end.
The firm can export every report, photo, template, and observation history on request, in the firm's own DOCX format. The firm can also request deletion of any record or the full tenant at any time — Fermito's obligation is to honor the request inside a documented window and confirm when the delete has cleared backups. No lock-in, no retention trap.
Full export on request · tenant-wide deletion · documented retention window
DPA availability
A data processing agreement is available on request.
Fermito ships a standard DPA for firms that need one as part of procurement. It covers processor roles, sub-processors, breach notification windows, and the firm’s rights on data export and deletion. Custom terms are negotiable on the Firm tier and on any custom plan above thirty engineers.
Sub-processor list, infrastructure region, and data residency options are shared under NDA on the rollout call — the firm admin should plan to see them before the procurement sign-off.
Incident response
A written policy, a single point of contact, a committed window.
Fermito runs on a written incident response policy with a named incident lead, a documented severity ladder, and a committed customer notification window measured in hours — not days. The window is written into the DPA.
Post-incident, Fermito publishes a root-cause writeup to affected firm admins under the same standard as every other page on this site: signed, under a real name, correctable if wrong.
SOC 2 roadmap
Fermito is on a documented path to Type II.
The four steps below are the plan as written today. Firm admins in active rollouts get visibility into each milestone as it lands.
- 01Now · Policies drafted
Fermito operates against written security, access, incident response, and change management policies aligned with the SOC 2 Trust Service Criteria. Policies are shared with firm admins on request under NDA during the pre-rollout call.
- 02Next · Readiness assessment
Fermito engages a SOC 2 readiness partner for a gap assessment against the drafted policies and current infrastructure. The output of the assessment becomes the work list for the audit window.
- 03Then · Type I audit
A point-in-time Type I audit closes the readiness window. Firm admins in active rollouts receive the Type I report as soon as it is issued, without a separate request.
- 04After · Type II observation window
The Type II observation window opens directly after Type I. Fermito shares interim status with firm admins on the rollout schedule rather than holding audit state back from the firm.
Before the rollout call
Firm admins are expected to read this page end to end.
If a line above is unclear, incomplete, or wrong, the rollout call is the right place to fix it. Fermito would rather answer the hard question in writing than paper over it in the room.