Server-owned authorization
Protected operations resolve the authenticated user and authorized company scope before records are queried or changed.
Security at FormEsque
FormEsque protects who can enter a company workspace, what each customer link can open, and how signed documents and activity history are retained.
Authorized boundary
Access narrows at every step
A pipeline or record identifier alone is never treated as authorization to access another company's data.
Security principles
Access controls, record integrity, and operational safeguards work together from the protected company workspace to the customer-facing page.
Protected operations resolve the authenticated user and authorized company scope before records are queried or changed.
Public proposal, signing, and invoice links are bound to the intended record instead of exposing the company workspace.
Signed document versions, signer actions, timestamps, completed artifacts, and audit evidence remain attached to the workflow.
Multiple safeguards work together across sign-in, application requests, stored records, restricted credentials, and operational monitoring.
Customer-facing access
Opaque tokens bind public proposal, signing, and invoice pages to a specific customer record. The customer can take the intended action without receiving general access to company data.
Signed-record integrity
Signed workflows preserve the relevant document version, signer actions, timestamps, completed artifacts, and audit evidence. Completed legal records are archive-only during normal use.
Production traffic uses HTTPS. Browser-safe configuration and sensitive server credentials are separated, while managed providers supply hosting, database, and storage infrastructure controls.
Structured logs, provider delivery events, health checks, and audit records support investigation. Material events follow the Incident Response Policy.
Production traffic is encrypted in transit using HTTPS.
Sensitive administration credentials remain server-only and outside public source.
Constraints and row-level policies add defense in depth alongside server authorization.
Logs, health checks, delivery events, and audit records support investigation.
Implemented controls
These sections describe the current FormEsque approach to authorization, application controls, document integrity, infrastructure, monitoring, and responsible reporting.
Business records are scoped through organization, company, workspace and pipeline identifiers. Protected server operations resolve the authenticated user and authorized scope before querying data. A pipeline identifier alone is never treated as an authorization boundary.
FormEsque uses managed authentication and server-side route protection. Role and ownership checks are performed for protected resources, and sensitive administration keys remain server-only. Organizations are responsible for accurate membership, role assignment and prompt offboarding.
Inputs are validated on the server, structured errors avoid exposing sensitive internals, and opaque tokens bind public signing and invoice pages to a specific record. PostgreSQL constraints and row-level policies provide defense in depth alongside server authorization. Privileged operations use explicit service access.
Signed workflows preserve the relevant document version, signer actions, timestamps, completed artifacts and audit evidence. Completed legal records are archive-only during normal use. Proposal-to-invoice conversion retains the authorized workspace and pipeline relationship.
Production traffic is encrypted in transit using HTTPS. Managed hosting, database and storage providers supply infrastructure security and encryption capabilities. Secrets are stored in deployment configuration rather than public source and are separated between browser-safe and server-only values.
Structured server logs, provider delivery events, health checks and audit records support investigation. Dependencies and configuration should be reviewed before release, and material vulnerabilities are prioritized according to exploitability and affected data. Security events follow the Incident Response Policy.
Do not test against another customer's data, disrupt service, use social engineering, retain personal information or publicly disclose an issue before coordinated remediation. Security reports should include reproducible steps, affected routes, impact and a safe proof of concept through the support or security channel identified in your agreement.
Trust center
Security is one part of the full trust picture. These documents explain signature consent, privacy, retention, provider use, recovery, and incident handling in more detail.
A clear customer record
Start with the documents your business already uses and keep customer decisions, signatures, invoices, and confirmed payment records connected.