ATTORNEY REVIEW REQUIRED BEFORE USE. This is a research-grade implementation checklist produced by a non-lawyer, intended as a starting-point for a contract attorney (SaaS / technology-transactions background) and software-architect to collaboratively validate before building. The items below track primary-source statutory text (ESIGN Act, UETA model text) but are NOT a compliance opinion. A signed NDA is only as enforceable as its implementation — the attorney should review this checklist alongside nda-template.md as one deliverable.
Each checklist item names the statutory hook (ESIGN section, UETA section) it satisfies, the practical implementation the portal must deliver, and any attorney-to-confirm flags.
Items marked [MUST] are non-negotiable for enforceability. [SHOULD] items are belt-and-suspenders. [CONSIDER] items are context-dependent.
This document does not prescribe architecture — the software-architect will translate these requirements into the portal's actual data model, storage, and UX in the phase-3 design doc.
1. Consent to electronic records — [MUST]
Statutory hook
ESIGN § 7001(b)(1): "A requirement to deliver information in writing to a consumer is satisfied ... if the consumer has affirmatively consented to such use and has not withdrawn such consent ..."
ESIGN § 7001(c)(1)(A): the consumer "has affirmatively consented to such use and has not withdrawn such consent."
Portal implementation
[ ] Before the NDA content is presented, portal displays a clear-and-conspicuous consent statement covering:
[ ] Right to receive the record on paper if signer chooses (and how to request it).
[ ] Right to withdraw consent, and the procedure to do so.
[ ] Scope of consent: this specific NDA only, vs. all future Raxx communications.
[ ] Hardware / software requirements to access the electronic record (modern browser + email access is sufficient for this use-case; still disclose).
[ ] Contact info to update email address and request paper copy.
[ ] Consent captured via an unchecked-by-default checkbox with explicit label: "I consent to receive and sign this NDA in electronic form and to the use of electronic records and signatures."
[ ] Consent action logged with timestamp, IP, user-agent — separately from the signature event.
Attorney-to-confirm
Is § 7001(c)(1) consumer-consent framework directly triggered in the NDA context (commercial agreement, not a law-requiring-writing-to-consumer scenario)? If not triggered, treat as belt-and-suspenders; if triggered, it's a hard requirement.
2. Intent to sign — [MUST]
Statutory hook
UETA § 2(8) (definition of "electronic signature"): "an electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record."
UETA § 7(a): "A record or signature may not be denied legal effect or enforceability solely because it is in electronic form."
Portal implementation
[ ] Signature action is a distinct, deliberate UI event — not a side-effect of page navigation. Examples of sufficient actions:
Typed name in a signature field + click "I Agree and Sign"
Drawn signature on canvas + click "Submit Signature"
[ ] Signature submit button is visually and textually distinct from non-signing navigation (e.g., "Cancel", "Save Draft").
[ ] After the signature action, signer sees an immediate confirmation page acknowledging that they have just signed a binding NDA.
[ ] Confirmation page includes a link to download the signed PDF.
Attorney-to-confirm
Does typed name satisfy for this context, or should drawn signature be required (or offered as option)? Industry practice: typed is sufficient for most NDAs; drawn adds friction with marginal legal benefit.
3. Attribution — [MUST]
Statutory hook
UETA § 9(a): "An electronic record or electronic signature is attributable to a person if it was the act of the person. The act of the person may be shown in any manner, including a showing of the efficacy of any security procedure applied to determine the person to which the electronic record or electronic signature was attributable."
Portal implementation
For every signature event, portal must capture and store:
[ ] Signer name (typed, matches the signature field).
[ ] Signer email — verified via:
[ ] One-time-code email verification before signing (signer receives 6-digit code, enters it in portal, code is validated before NDA presentation), OR
[ ] Magic-link flow (signer clicks unique link from email, link validates before NDA presentation).
Attorney-to-confirm: which method; magic-link is simpler UX, one-time-code is stronger attribution.
[ ] IP address at signing (IPv4 or IPv6; handle X-Forwarded-For correctly behind Heroku's router).
[ ] User-agent string at signing.
[ ] Timestamp (UTC, ISO 8601).
[ ] Session identifier linking consent event and signature event to the same browser session.
Attorney-to-confirm
Is the above sufficient, or should higher-value signings (e.g., investor NDAs) require 2FA or phone-number verification?
Any specific jurisdiction that requires more than email-verified attribution for commercial contracts?
4. Record retention — [MUST]
Statutory hook
ESIGN § 7001(d)(1): "If a statute ... requires that a contract or other record relating to a transaction ... be retained, that requirement is met by retaining an electronic record of the information in the contract or other record that ... accurately reflects the information set forth in the contract or other record; and ... remains accessible to all persons who are entitled to access ... in a form that is capable of being accurately reproduced for later reference, whether by transmission, printing, or otherwise."
[ ] Signed PDF generated at signing time with all placeholder values merged ([ENTITY_NAME], [SIGNER_NAME], [EFFECTIVE_DATE], etc.).
[ ] SHA-256 content hash of the signed PDF computed at sign-time and stored in a tamper-evident field on the nda_signatures row. Hash should be recomputable from the stored PDF at any later time to prove the document hasn't been modified post-signing.
[ ] Storage per epic #161:
Postgres BYTEA or S3 object (architect to choose).
If S3: server-side encryption at rest (SSE-S3 or SSE-KMS); versioning enabled; lifecycle rules that do NOT auto-delete signed NDAs.
If Postgres BYTEA: backed up in normal DB backup cycle; retention policy applies to the backup tier as well.
[ ] Audit log of every read, download, and administrative access to each signed NDA, with actor ID, timestamp, IP.
[ ] Retention period: NDA term ([TERM_YEARS]) + 6 years (per epic #161). Attorney-to-confirm this maps cleanly to:
PA 4-year breach-of-contract SoL (42 Pa.C.S. § 5525) + 2-year buffer, OR
PUTSA trade-secret SoL (12 Pa.C.S. § 5301 et seq. — confirm current limit, believed to be 3-year), OR
Federal DTSA SoL (18 U.S.C. § 1836(d) — 3 years from discovery).
Attorney-to-confirm
Confirm retention-period calculation against PA SoL landscape.
Does the "accurately reproducible for later reference" standard require storing the underlying HTML/CSS that rendered the PDF, or is the final PDF + hash sufficient? (Industry: PDF + hash is the dominant pattern.)
5. Ability to retrieve / download — [MUST]
Statutory hook
ESIGN § 7001(d)(1)(B): record must remain "accessible to all persons who are entitled to access" in "a form that is capable of being accurately reproduced for later reference."
UETA § 12: same standard.
Portal implementation
[ ] Immediate download available on the signature confirmation page — signer can download their signed PDF before leaving the flow.
[ ] Email delivery of the signed PDF to the signer's verified email address, sent synchronously with the signature event (via SendGrid per epic #161 / overlaps with issue #112).
[ ] Attorney-to-confirm: if SendGrid isn't ready, whether a "PDF will be emailed within 24 hours" SLA is acceptable.
[ ] Signer-initiated retrieval at any future time:
Method A: signer enters email, receives a one-time link that lets them download their signed copy.
Method B: signer is authenticated into a Raxx account (post-auth-epic) and accesses NDAs via account dashboard.
[ ] Method A is the v1 pattern; Method B requires auth infra. Architect to choose.
[ ] "How to request a copy" language in the NDA itself (§9 notices) and on the portal's post-sign confirmation page.
6. Consent-withdrawal mechanism — [MUST] (for future records only)
Statutory hook
ESIGN § 7001(c)(1)(B)(i)(II): the disclosure must inform the consumer of "the right of the consumer to withdraw the consent, including ... any conditions, consequences (which may include termination of the parties' relationship), or fees in the event of such withdrawal."
Critical interpretation
Consent withdrawal applies to future records only. The NDA itself, once signed, is a binding contract; the signer cannot unilaterally "withdraw" their signed NDA. The portal and the NDA language (§10.5) must make this distinction crystal-clear to avoid signer confusion.
Portal implementation
[ ] Clear language in the consent flow: "Withdrawing consent affects future electronic communications but does NOT void this NDA once signed."
[ ] A stated method for signer to withdraw consent for future records (e.g., email to [ENTITY_NOTICE_EMAIL] with subject "Withdraw ESIGN consent").
[ ] Portal retains a flag per signer indicating consent status for future communications; when flag is set to withdrawn, subsequent electronic-only communications to that signer stop.
Attorney-to-confirm
Is email-based withdrawal sufficient, or should there be a self-serve portal page? (Industry: email is fine for low-volume; self-serve is cleaner for higher-volume.)
7. Tamper-evidence — [MUST]
Statutory hook
UETA § 12(d): "A record retained as an electronic record satisfies subsection (a)." Combined with the § 12(a)(1) requirement that the record "accurately reflects the information set forth ..." — tamper-evidence is implicit.
Best practice across the industry: cryptographic hash + append-only audit log.
Portal implementation
[ ] Content hash (SHA-256) computed at sign-time over the full signed PDF bytes. Stored in a column that is not ever updated (append-only for that row).
[ ] Rehashability test: an admin script can fetch the stored PDF and recompute its SHA-256; result must match the stored hash. Any mismatch indicates tampering.
[ ] Append-only audit log table — every event (consent captured, email verified, signature submitted, PDF accessed, PDF downloaded, admin viewed) gets a row. Rows are never updated or deleted. DB-level permissions should enforce this for the app user (only INSERT, no UPDATE/DELETE on the audit table).
[ ] PDF metadata includes a hash-referenced footer: "Signed copy hash: — verified against the Raxx NDA system of record." (Cosmetic — gives signers something tangible to reference.)
Attorney-to-confirm
Is SHA-256 sufficient, or should we use a stronger tamper-evidence approach (e.g., timestamp-authority signature, blockchain anchor)? For the NDA volume Raxx expects (< 1000 signatures/year for years 1-2), SHA-256 + append-only audit is proportionate.
8. UETA state-specific variations — [CONSIDER]
Status as of 2026-04-22
49 states + DC + USVI have adopted UETA.
Illinois adopted UETA in June 2021, replacing the prior Electronic Commerce Security Act (ECSA) [6].
Washington adopted UETA in 2020 via SB 6028, replacing the prior Washington Electronic Authentication Act.
New York is the lone UETA holdout as of April 2026. NY uses the Electronic Signatures and Records Act (ESRA) — substantively similar to UETA but using different statutory language [7].
Portal implementation
[ ] No per-state branching needed for v1 — the portal's consent / attribution / retention flow satisfies both UETA (the 49 states that have it) and ESRA (NY).
[ ] ESIGN federal floor applies in all 50 states regardless, so even NY signers are covered by the same flow.
[ ] Attorney-to-confirm if significant NY-based signer volume warrants NY-specific consent-flow language (e.g., explicit ESRA § 304 attribution language). For v1 alpha-access / investor context, likely not needed.
Data to log per signer
[ ] Signer's self-reported jurisdiction — capture during consent (e.g., "State / country of residence"). Not required for enforceability but useful for future audit if a signer later claims a jurisdictional defense.
9. Accessibility — [SHOULD]
Rationale
ESIGN / UETA do not directly mandate accessibility, but a signer who can't meaningfully read the consent disclosures or the NDA arguably did not give informed consent. For federally-funded contexts there are additional obligations (not Raxx's).
Portal implementation
[ ] WCAG 2.1 AA compliance on the consent page, signature page, and PDF download flow.
[ ] Screen-reader-friendly NDA text (semantic HTML, not just a PDF iframe).
[ ] Keyboard-navigable signature flow — typed signature must be usable without a mouse.
[ ] Font size / contrast sufficient for signers with visual impairments.
10. Privacy — scoped data minimization — [MUST]
Not ESIGN/UETA directly, but epic #161 invariant
Portal implementation
[ ] Data captured (name, email, IP, UA, signature) scoped solely to NDA purpose. Not fed into marketing analytics, not shared with third-party tools beyond what's strictly necessary (e.g., SendGrid for email delivery).
[ ] Third-party integrations (SendGrid, Sentry, etc.) configured to not capture PII from the NDA flow — or, where unavoidable, with a processor-level DPA in place (future work under GDPR/CCPA compliance epic, track via docs/business/privacy-compliance.md when that lands).
[ ] Retention carve-out from GDPR erasure requests: signed NDAs are binding contracts on both parties; the signer's data is required to maintain the contract record. The retention policy (NDA term + 6 years) overrides GDPR Article 17 erasure requests for the NDA record itself. Signer can withdraw consent for future communications but the signed doc + attribution data stays.
Attorney-to-confirm
PA does not have a comprehensive privacy law at the state level (unlike CA/CO/VA/CT). For CA-resident signers (relevant given docs/business/state-of-formation.md CA-foreign-qualification path), CCPA applies once Raxx crosses the 100k-records / $25M revenue / 50%-revenue-from-data thresholds — not applicable for v1 but track as threshold approaches.
11. Admin surface — [SHOULD]
Not strictly an ESIGN requirement, but operationally necessary
Portal implementation (ties into console.raxx.app epic #146)
[ ] Admin dashboard lists all signed NDAs with:
[ ] Signer name, email, sign-date
[ ] NDA version (template hash — so we know which attorney-approved version was active at sign-time)
[ ] Attorney has reviewed + approved nda-template.md and the version is locked in a new file (e.g., docs/legal/nda-template-v1.0-signed.md) with a hash recorded.
[ ] software-architect design doc (phase 3 per epic #161) exists and has been reviewed by attorney.
[ ] All [MUST] items in this checklist have code implementing them.
[ ] FLAG_NDA_PORTAL is on for admin only; internal test signatures are reviewed end-to-end (consent flow, sign, PDF generation, email delivery, download, hash verification).
[ ] End-to-end test: admin signs a test NDA; rehashability test passes; audit log shows the expected event chain.
Qualified electronic signatures (QES) — EU eIDAS concept; not US ESIGN/UETA. Not applicable unless Raxx intentionally targets EU signers.
Digital-certificate-based signatures (PKI) — overkill for Raxx's NDA volume and counterparty profile; industry convention is typed-signature + attribution metadata as described above.
Revocation flow — signed NDAs are binding contracts; revocation is an attorney-driven process, not a self-service feature. Per epic #161 scope.
14. References to other docs
nda-template.md — the template starting-point this checklist operationalizes. Section 10 of the template is the counterpart to this doc.
nda-framework.md — decisions, alternatives, and primary-source citations. Section 6 frames the ESIGN + UETA landscape.
docs/business/questions-for-attorney.md (on research branch research/business-foundation-v1) — aggregated attorney agenda; ESIGN questions should be folded in.
Sources (primary + explainer)
See nda-framework.md §11 for the full citation list. Key items for this checklist:
UETA § 9 — attribution provision, Uniform Law Commission model text.
UETA § 12 — record retention.
DLA Piper, "With Illinois's adoption of UETA..." (2021) — confirmation of near-complete US adoption.
NYC Bar Association, "Modernizing New York's Electronic Signatures Law" (2026) — NY as lone UETA holdout.
ATTORNEY REVIEW REQUIRED BEFORE USE. Review this checklist with the contract attorney (SaaS / technology-transactions background) alongside nda-template.md at the #151 consult. The checklist is an input to software-architect's phase-3 portal design, not a substitute for attorney-blessed compliance review.