Trust and security
How Lectern handles your business’s data, and the records it keeps about other people. Written for vendor review and customer diligence; signed agreements control where they say something different.
Last updated: August 21, 2026
The rules that do not change
Three rules hold everywhere in the product, whatever a business runs it for. They are not settings, and they are not promises about a roadmap. Anything that could stop being true as the product grows is stated as current fact further down this page instead of being listed here.
Nothing addressed to someone outside your business leaves without a person clicking.
Work is prepared ahead of you and held with the records it was drawn from attached. A reply, an invoice, a report: it waits. Nothing reaches a customer, a client, a family or a patient because software decided to send it. When you schedule something for a time you chose, that schedule is your click.
A connection is something you set up, and something you can take back.
Some features work by connecting an account you already have. That happens through the provider's own consent screen, done by someone at your business, granting only what the feature needs. It never appears because a release added it. The credentials it issues stay server-side and never reach a browser, and disconnecting in Lectern or revoking at the provider is always available.
The software does the admin. It does not do your trade.
It reads a history of what was booked, attended, ordered, owed and delivered, then writes what it found, with the numbers and dates attached. It does not grade, tutor, diagnose, advise, or make a professional judgment about a person in your records. That call is yours, and the evidence it shows is there so you can check it.
Security posture
Every business runs the same codebase against its own data, on its own address. Lectern is designed around least-privilege access, private uploads, and conservative production operations. Where a control is a convention rather than a guarantee the database enforces, it is described that way here.
- Scoping to one business is a convention in the data-access layer, not a database policy. Core tables carry an owning id, the request's subdomain resolves which business is asking, and repository queries filter on it.
- We keep a written per-table audit of every read against a scoped table, including the reads that still carry no predicate and the work to close them. It is maintained rather than finished, and we would rather describe it that way than call the boundary airtight.
- Row-level security is enabled with no policies on the tables exposed through the database API, which closes that API. The application connects with a service role and bypasses it, so isolation comes from the query convention above rather than from the database. The client portal runs on a separate database with real row-level policies keyed to the signed-in user.
- Features are gated by capability: one key controls the nav item, the routes behind it, and the actions those routes call. Turning a feature off removes the surface rather than hiding it.
- Role-based access for the roles a business actually has: owner, admin, staff, assistant, and the limited views given to the people it serves.
- Credentials for a connected account are stored server-side and are excluded from every read that reaches the browser.
- Private storage for sensitive uploads, with server-side validation and signed upload paths.
- No cardholder data is stored. As of the date on this page the product has no payment rails of its own: it records what was invoiced and what was received, and it drafts the reminder. A payment integration would arrive with its own terms and its own row in the subprocessor list below.
- Some links are the authorization. An order a customer opens without an account is reached by an unguessable token in the URL, which means that link should be treated as the credential it is.
- Cloudflare Turnstile on the public intake form, which is the one unauthenticated write surface on this site.
- Service-role secrets and API keys kept server-side and outside browser bundles.
- Production database migrations are hand-authored and applied deliberately.
- A change to a live customer's system is staged on its own preview address and promoted by a person, never by a build finishing.
- Build and typecheck gates before shipping application changes.
Data commitments
- We do not sell your data, or the data of anyone in your records.
- There is no advertising in the product, no ad network, no cross-site tracking, and no analytics on the public website.
- Your records are never shown to another business and are never used to answer another business's question. Where usage improves the product, it is aggregated or de-identified.
- Customer data is not used by Lectern to train general-purpose AI models.
- AI-assisted features are used for service delivery: reading a document, organizing a record, drafting a message that then waits for a person.
- Lectern is sold to businesses, not consumers, and we do not knowingly collect personal information directly from a child. Where a business keeps records about minors, that business is responsible for the notices and permissions its own law requires, and we support those obligations through the agreement, access controls, and export or deletion help.
For more detail, see the Privacy Policy and Terms of Service.
Subprocessors
The services below are the main subprocessors Lectern uses or has wired for service delivery. Which of them touch your data depends on the features you turned on: a business with no connected account never reaches a publishing provider, and one with no AI-assisted feature never reaches a model provider. Ask and we will tell you exactly which apply to you.
Retention and deletion
We retain information as long as needed to provide the service, support customers, protect security, satisfy legal obligations, and maintain business records. Your own business records are governed by your agreement.
On request or termination, Lectern can help you export or delete your data, subject to backups, legal requirements, security logs, and operational constraints.
None of this reaches what already left. Mail that was sent, or a post published to a connected account, is not recalled by a deletion here. That removes our copy of the record, not theirs.
Vendor review packet
Before onboarding at scale, these items should be converted from posture into attorney-reviewed, signed documents.
- Master Services Agreement or platform subscription agreement.
- Order form covering scope, pricing, implementation, support, renewal, and termination.
- Data Processing Agreement, and an addendum for whatever category of record your sector regulates.
- Subprocessor notice and change process.
- Retention, export, deletion, and incident-notification terms.
- Sector-specific and procurement language where it is required of you.