Security

Security model

Every signed NDA is treated as a legal record, so the security model is built around keeping that record private, attributable, and tamper-evident from signature to storage. The controls in place today work together toward that:

• Tamper-evident records: every completed agreement carries a SHA-256 fingerprint of its text, so the document can later be checked for any alteration, and a Certificate of Completion with per-signer signing records.
• Private, immutable storage: the executed PDF is stored as the immutable record in Vercel Blob with private access, encrypted at rest, and served only through a token-gated link.
• Attributable signing: each signature is captured with its timestamp and the signer’s IP address, device user-agent, and approximate location for the audit trail.
• Account protection: optional two-step verification (an emailed one-time code) adds a second factor at sign-in, and access to each organization’s data is isolated with role-based controls.
• Encrypted transport: all connections use TLS with HSTS, and signature-verified webhooks gate inbound events.

Each of these is detailed in the sections below.

Posture

FreshNDA is a focused tool for sending and signing NDAs. It is built on established infrastructure providers and follows standard web-application security practices. This page describes what is actually in place today, in plain language.

FreshNDA does not currently hold a formal third-party security certification or audit report, and nothing here should be read as a formal audit, certification, or warranty. The underlying providers listed below maintain their own certifications for the infrastructure they operate.

FreshNDA's controls are implemented and self-assessed against the SOC 2 Trust Services Criteria (Security Common Criteria CC1–CC9, plus Availability and Confidentiality). No third-party audit has been performed, so FreshNDA is not SOC 2 certified or compliant; a formal SOC 2 examination will be pursued when customer demand warrants. A summary of the control self-assessment is available on request. To request it, or to have a security questionnaire answered, email privacy@freshnda.com.

For a procurement or vendor-security review, this page is kept current, and written answers to a security questionnaire and a Data Processing Addendum (DPA) are available on request—see Data processing & DPA below.

Where a control is planned but not yet available, it is labeled as such rather than implied.

Data handling

FreshNDA collects the information needed to generate, send, and track NDAs: the names, email addresses, titles, and organizations of the parties; the agreement text; signatures (the typed name used to sign); signing timestamps; and the IP address, device user-agent, and approximate location (city and country derived from the IP) of signers, which are recorded for the signing audit trail.

Records are stored in a managed Neon PostgreSQL database hosted in the United States. The executed signed-NDA PDF is stored as the immutable record in Vercel Blob (private access, US region, encrypted at rest) and served only through a token-gated link. Data is not sold or shared for marketing purposes.

FreshNDA does not use analytics, advertising, or AI/LLM providers. Fonts and static assets are self-hosted, so loading any page—including the public signing page—sends no request to Google, a font CDN, or any other third party. The only third parties that receive data are the subprocessors listed below. One of them, Google, receives data only if an organization admin connects Google Drive to export that organization’s own signed NDAs—an optional integration that is off unless turned on (see Subprocessors below).

Encryption & application security

• In transit: all connections use TLS, and HTTP Strict Transport Security (HSTS) is enabled.
• At rest: database storage is encrypted at rest by the infrastructure provider (Neon, on AWS). FreshNDA does not add a separate application-level field-encryption layer.
• Response headers: responses enforce a strict, nonce-based content security policy. Scripts are locked to a per-request nonce (with strict-dynamic) and the default source is the site’s own origin, which blocks injected scripts (cross-site scripting), restricts framing (clickjacking protection), blocks plugin-embedded content, and prevents an injected base tag from re-rooting links, alongside X-Content-Type-Options and a referrer policy.
• Webhooks: inbound webhooks from Stripe, Clerk, and Resend are signature-verified before they are processed.
• Payments: card data is handled entirely by Stripe; FreshNDA stores only a Stripe customer reference, never card numbers.
• Monitoring: application errors are monitored through Sentry.

Subprocessors

These third parties process customer data on FreshNDA's behalf. Each operates under its own terms and security program. Google is a customer-elected subprocessor: it appears here only because of the optional Google Drive export, receives data solely for organizations whose admin connects Drive, and receives nothing from organizations that don't.

• Vercel—Application hosting, serverless compute, and signed-PDF storage (Vercel Blob)

  Processes all application traffic during a request; stores the executed signed-NDA PDFs in Vercel Blob with private access (US region), encrypted at rest.

• Neon—Primary application database (PostgreSQL)

  Neon stores the account, organization, NDA, signing, and audit records that form the system of record.

• Clerk—Authentication and account identity

  Clerk receives account email, name, and login/session data.

• Stripe—Payment processing and subscription billing

  Billing details. Card data is handled entirely by Stripe; FreshNDA stores only a Stripe customer reference.

• Resend—Transactional email delivery

  Resend receives recipient name, email address, and NDA notification content.

• Sentry—Error monitoring and performance

  Sentry receives diagnostic and error data, which may include limited request metadata.

• Google (Drive export)—Optional, customer-elected export of signed NDAs to the organization's own Google Drive

  Only for organizations whose admin connects Google Drive: each executed signed-NDA PDF (with the signing details it contains) is uploaded to the folder the admin chooses, using the narrow drive.file scope (access limited to files FreshNDA creates). Organizations that don't connect Drive send Google nothing.

Data processing & DPA

For customer data submitted to the service, FreshNDA acts as a data processor and the customer as the data controller: FreshNDA processes that data to operate the service and on the customer's documented instructions, not for its own purposes.

A Data Processing Addendum (DPA) is available on request for customers who need one for their procurement, GDPR, or CCPA requirements. It covers the scope and purpose of processing, the subprocessors listed above and how changes to them are notified, the security measures in place, breach notification, assistance with data-subject requests, and return or deletion of data when the agreement ends.

To request a copy, email privacy@freshnda.com. Requests are reviewed individually before a copy is shared.

Retention & deletion

Data is retained for the life of the account; there is no automated purge. An organization admin can permanently delete the organization and all of its data (a cascading hard delete). Requests to delete specific records are handled manually and completed within 30days of a verified request—email privacy@freshnda.com. This matches the deletion timeframe in the Privacy Policy.

Access controls & authentication

Authentication is handled by Clerk, a third-party identity provider. FreshNDA never stores user passwords.

Customer data is isolated per organization, with role-based access. Two roles exist: admin and member. Members see only the organizations they belong to. When someone is removed from or leaves an organization, their public links are deactivated and the access tokens on their NDAs are rotated.

The agreement text of NDAs is not surfaced in internal tooling. Access to production data is limited to a small number of authorized personnel and used only to operate the service, provide support, and prevent abuse.

Two-step verification: available as an opt-in second factor. When a user turns it on (under Profile), each sign-in requires a one-time code emailed to their account address before the dashboard unlocks. It is off by default. An authenticator-app (TOTP) or SMS factor is not yet offered; this is stated plainly so a security review has an accurate answer today.

Audit logging & signing records

NDA and membership events are recorded in append-only logs. Every completed agreement includes a Certificate of Completion with a per-signer record—each party's signature, signing timestamps, and (for the recipient) IP address, device user-agent, and approximate location—plus a SHA-256 fingerprint of the agreement text, so the text can later be checked for tampering, and a QR code linking to a public verification page.

Incident response & security contact

To report a suspected vulnerability or security incident, email security@freshnda.com. Please include enough detail to reproduce the issue. Reports are reviewed and acknowledged; affected customers are notified of confirmed incidents that involve their data.

FreshNDA does not currently run a paid bug-bounty program, but good-faith reports are welcome and appreciated.

Documents & artifacts

What can be provided for a vendor review:

• This page, kept current with the product.
• A per-document Certificate of Completion, included with every signed NDA.
• A Data Processing Addendum (DPA) on request—see Data processing & DPA above.
• Answers to specific security questions on request—email the security contact above.

See also the Privacy Policy and Terms of Service.