Compliance & Security Statement

How to read this page

This page describes the security and compliance measures that are actually implemented in the Luna Signing Solutions platform today. It deliberately does not describe measures we intend to implement, and it does not claim certifications we do not hold.

An earlier version of this statement listed controls and certifications that were not in place. We have removed them. Each item below corresponds to something a reviewer can verify, and the section titled “What we do not have yet” sets out the gaps we are actively working on. We would rather be checked than believed.

Protecting your records

Encryption

• At rest: Signer personal information, signature images and generated journal PDFs are encrypted with AES-256-GCM before they are written to the database or to object storage. Encryption keys are held in the runtime environment’s secret store, separately from the encrypted data.
• In transit: All traffic between your browser and our servers is carried over TLS. The application refuses to set session cookies over a plaintext connection.
• Two-factor secrets: Where you enrol an authenticator app, the shared secret is encrypted at rest rather than stored in readable form.

Tamper-evident journal

• SHA-256 hashing: Each sealed journal entry is hashed over its own contents.
• Hash chaining: Each entry incorporates the hash of the entry before it, so altering a historical entry invalidates every entry that follows.
• Sequential numbering: Entries are numbered in an unbroken sequence, allocated inside a database transaction so two concurrent notarizations cannot share or skip a number.
• Server-side verification: The seal on an entry is re-computed from its contents on request, rather than compared against a stored value.
• Append-only corrections: A journal entry cannot be edited or deleted through the application. Voiding an entry records an annotation alongside it; the original remains.

Access control

• Two-factor authentication: Available on notary accounts, by authenticator app (TOTP) or emailed code.
• Password storage: Passwords are hashed with bcrypt at a deliberately slow work factor. They are never stored or logged in readable form.
• Record isolation: Every request for journal data is scoped to the authenticated account at the database query itself, so one notary cannot reach another’s records by guessing an identifier. This is covered by automated tests that run on every change.
• Session handling: Access tokens are held in memory only and never written to browser storage. Sessions time out after a period of inactivity, and changing your password or signing out everywhere immediately invalidates all existing sessions.
• Rate limiting: Authentication, password reset and other sensitive endpoints are rate limited per account and per address, with counters held server-side.
• Access logging: Reads, PDF generation, downloads and administrative actions are written to an access log.

Application security

• Content Security Policy: Enforced with a per-request nonce, with inline scripts disallowed in production.
• Cross-site request forgery: Protected by a double-submit token compared in constant time.
• Input validation: Request bodies are validated against explicit schemas, and inputs are sanitised against database operator injection.
• Dependency and secret scanning: Every change is automatically scanned for known-vulnerable dependencies and for committed credentials. Both checks must pass before code can be merged.
• Least-privilege runtime: Application containers run as an unprivileged user, asserted automatically on every build.

Infrastructure

• Hosting: The platform runs on Google Cloud Platform — Cloud Run for the application, Cloud Storage for signature images and journal PDFs, and MongoDB Atlas for the database.
• Managed platform controls: We inherit the physical, network and platform security controls of Google Cloud and MongoDB Atlas. Their compliance reports cover their infrastructure; they do not cover this application, and we do not present them as if they did.
• Database backups: Managed snapshots are enabled on our database cluster.

Notarial recordkeeping

• The journal captures the information required for a notarial record, including signer details, the act performed, the date and the signature.
• Journal entries are retained and are not deleted by the platform.
• Journal records can be exported as PDF.
• The platform presents state-specific reference information, including retention periods and fee limits, to assist the notary.

Identity documents and automated scanning

Where a notary uses the optional ID scanning feature, the photograph of the identity document is sent to Google Vertex AI to extract the printed text, so that the details do not have to be typed by hand. Images are processed to remove camera metadata, including location, before being sent.

This is an aid to data entry. It is not an identity-proofing or credential-verification service, and it does not by itself satisfy any statutory identity-verification requirement. Verifying the identity of a signer remains the notary’s responsibility.

Service providers

We use the following processors. Each receives only the data needed for its function:

• Google Cloud Platform — application hosting, file storage, and the Vertex AI service used for ID text extraction.
• MongoDB Atlas — managed database hosting.
• Stripe — subscription payments. Card details are entered directly into Stripe’s hosted fields and are never transmitted to or stored on our servers.
• Mailgun — transactional email, including password resets and emailed two-factor codes.

We will publish a maintained sub-processor list and notify customers of changes to it.

Privacy rights

You may ask us to give you a copy of your personal information, correct it, or delete it. Requests are currently handled by our team rather than through a self-service tool, and we will acknowledge your request within five business days.

Deletion is subject to the notary’s legal obligation to retain the notarial journal. Where we must keep a record, we will tell you specifically what has been retained and why. To make a request, email privacy@lunasigningsolutionsllc.com. See our GDPR & CCPA page for details.

What we do not have yet

We think it is more useful to tell you what is missing than to leave you to assume. The following are known gaps that we are working through as part of our SOC 2 readiness programme:

• No third-party security certification of any kind, and no independent penetration test.
• No 24/7 monitoring, and no formal on-call rotation. Alerting is being built.
• No published uptime commitment or service level agreement.
• Our disaster recovery procedure has not yet been tested end to end, so we do not publish a recovery time objective.
• Self-service data export and deletion are not yet available; these requests are handled manually.
• No audio-visual recording, and therefore no support for remote online notarization where a recording is required.
• Encryption is applied by our servers. This is not end-to-end encryption, and it is not a zero-knowledge design: we hold the keys and can technically decrypt your data.

Reporting a security issue

If you believe you have found a security vulnerability, please tell us. We will acknowledge your report within five business days and will not pursue action against good-faith researchers who report privately and avoid accessing other people’s data.