Trust

Security & Data Protection

Last updated October 2026 · DynamoDocs is a product of Uptimize Solutions LLC.

DynamoDocs handles invoices, purchase orders, and ERP credentials, so security is built into how the product is architected and operated, not bolted on. This page summarizes our controls for buyers and procurement teams.

Tenant isolation

Each customer gets a dedicated, isolated instance with its own database, secrets, and credentials. There is no shared multi-tenant document store, so one customer's data can never be reached from another's instance.

Encryption & credentials

Connector credentials are encrypted at rest with AES-256-GCM and are never shown back to the browser. The interface shows only that a credential is saved, never its value. Sessions use httpOnly cookies and access is role-gated. Connections can be tested from the Settings screen, and every ERP target runs in simulation mode until you explicitly switch it live, so a half-configured connection cannot write to your ERP.

Application hardening

The application is hardened with security headers, per-IP rate limiting, and strict request validation. Edits to extracted data are whitelisted against your configured field schema rather than merged blindly, so a malformed or unexpected payload cannot introduce fields or overwrite the system's own validation state.

EDI and partner transport

Trading-partner traffic is protected in transit and authenticated on arrival. Over AS2, messages are signed and encrypted in both directions using certificates exchanged with the partner: an inbound message is decrypted and its signature verified against that partner's certificate before anything is stored, so a message signed with an unknown certificate, or one whose payload was altered after signing, is rejected outright and no document is created. Plaintext posts to the AS2 endpoint are refused. A replayed message is re-acknowledged without producing a second document, and a message that failed verification can never register itself as seen. The signed receipt (MDN) we return is verifiable by the partner's own stack. Over SFTP, connections use key-based or password authentication and files are written under a temporary name and renamed into place, so a partner polling the folder never reads a half-written file. Partner credentials and certificates are encrypted at rest with the same AES-256-GCM handling as ERP credentials and are never returned to the browser.

The third option moves no credentials at all: where a VAN client such as SPS Commerce, Cleo, or TrueCommerce is already in place, DynamoDocs can simply read and write the folder it maintains. Your existing provider continues to own the connection to each partner and the certificates behind it, and DynamoDocs holds nothing beyond filesystem access, which for some security reviews is the easiest of the three to approve, since it adds no new externally-reachable endpoint.

Both transports are verified against genuinely foreign implementations, not only against our own code. AS2 in both directions: a public third-party AS2 server accepted our messages and we verify its signed receipts, across multiple encryption and digest combinations, and inbound messages are additionally built with a separate cryptographic toolchain. SFTP against OpenSSH’s own server software, which is what the great majority of partners and VANs actually run. That last check earned its keep immediately: it found a case where re-sending a file under a name already present was refused by a real server and accepted by our own test harness, because the harness shared a protocol library with our client. It is fixed, and the regression test now models the stricter behaviour. No trading partner has certified DynamoDocs; each partner runs its own test cycle regardless of vendor.

Sign-in and roles

People sign in with Microsoft 365 (Entra ID) or Google Workspace, or with a password where single sign-on is not in use. Microsoft sign-in accepts only the tenants you list, refuses personal Microsoft accounts, and every token's signature, issuer, and audience is verified on the server. Once single sign-on works, password sign-in can be switched off, with an administrator-only break-glass for emergencies. Every sign-in, successful or refused, is recorded.

Four roles decide what each person can do: viewers read, reviewers correct documents and clear flags, approvers post to the ERP and override review, and administrators change configuration and archive records. Every action that changes data declares the least role allowed to perform it, and the server enforces it; an automated test calls every one of those actions as every role and fails if any is unguarded. Roles can come from your own Entra app roles or security groups, so membership is managed in your tenant rather than in ours, and an account with no recognized assignment gets the least privilege, never more.

Sessions and passwords follow your policy: sign people out after a period without activity (clicks and typing count; the app's own background refreshes do not), cap how long any session lasts, set a minimum password length, and lock an account after repeated failed sign-ins, with administrators able to unlock it early. Every sign-in, refusal and lockout is recorded. Microsoft and Google accounts follow your tenant's own password and multi-factor rules.

Two periodic reviews are built in for auditors: a user access review listing every account, its role, where the role comes from and when it last signed in, and an audit-trail review that summarizes a period and flags edits made after a document was approved or posted, reviews approved with issues outstanding, re-posts and archives. Marking either complete records who reviewed what, and when, in the change log.

Audit trail and records

Every document carries a complete history: how it arrived, each status change, each export attempt, each review decision, and each human edit, recorded with the named person who made it and the before and after value of every field changed. "Who changed this amount, and what was it before?" has an answer without reconstructing it from memory.

The history is kept in its own append-only table that the database itself refuses to update or delete, and each entry is hash-chained to the one before it. Preventing a change through the application is one property; being able to tell that a record was altered some other way is another, and the chain provides the second. An entry altered, removed, or inserted outside the application breaks the chain at that point, and the check reports the first broken link.

Any record can be produced as an inspection copy, printable or as JSON, carrying the extracted data, the full history, and the result of verifying the chain at the moment it was exported, so the copy carries its own evidence. Records are archived, never deleted: archiving keeps the record and its original file and is itself an attributed entry, and each record carries a retention date (seven years by default). Once a document has been exported or archived, its fields can no longer be edited.

Posting is guarded too: a document with open review issues cannot be posted, and once a document has posted successfully to an ERP target, DynamoDocs refuses to post it there again unless someone explicitly confirms a re-post, so a double-click or a retried job cannot create a duplicate record in your ledger.

Outbound webhooks & the read-only API

Integration is designed to let data out without letting writes in. Outbound webhooks deliver document-lifecycle events (ingested, validated, flagged, approved, exported, and others) to endpoints you configure, each request signed with HMAC-SHA256 over a timestamped body so your receiver can verify origin and reject replays; signing secrets are encrypted at rest and never returned to the browser. The API (/api/v1) is read-only by construction: bearer keys are shown once and stored only as hashes, and every write method is refused, so an integration can fetch documents, extraction results, and audit history but cannot modify anything. Corrections stay in the reviewed, whitelisted UI path.

Payment files & banking data

DynamoDocs moves no money. Payment-file export produces the artifact your bank or ERP payment run executes: a payment-proposal CSV or an ACH (NACHA) file, from bills that have passed the approval gate. Because an ACH file necessarily contains vendor account numbers, banking data gets the strictest handling in the system: account numbers encrypted at rest, masked on read, an admin-only banking profile, admin-only NACHA generation, and the whole feature disabled in the public demo. Every batch is recorded on the audit trail of each document it contains.

Deployment options & data residency

Run DynamoDocs as a managed cloud deployment in a chosen region, or fully self-hosted on your own infrastructure so documents never leave your environment. Every record carries a retention date (seven years by default, configurable per customer), and nothing in the application destroys a record before or after it: disposal at the end of retention is a separate, deliberate act.

21 CFR Part 11

For suppliers and manufacturers whose records fall under FDA 21 CFR Part 11, DynamoDocs implements the record controls of §11.10 in the product itself: a tamper-evident, attributed audit trail (11.10(a) and (e)); accurate and complete copies for inspection (11.10(b)); records retained rather than deleted (11.10(c)); access limited to authorized people, with role-based authority checks (11.10(d) and (g)); and enforced sequencing, so a document cannot be posted before its review clears, cannot post twice, and cannot be edited after posting (11.10(f)). Each control is covered by named automated tests we can walk through as part of your validation.

Electronic signatures are a setting (§11.50, §11.70, §11.200). With them on, every release (approving, approving a review, posting) is signed: the signer re-enters their password, or signs in to Microsoft again and the server checks when, and the signature records the printed name, the date and time, and a fixed meaning such as “Released to the ERP”. It lives on the audit entry of the action it signs, inside the hash chain, with a fingerprint of the record as signed, and it prints on the inspection copy. Failed attempts are logged.

What stays with you: the letter certifying to the FDA that your electronic signatures are binding (§11.100(c)), and validating the system as you use it, with your procedures and training. We provide the controls and the named tests behind each.

Separation of duties

A setting, off by default so a small team where one person enters and posts is never blocked. With it on, whoever entered or changed a document (uploaded it by hand, edited a field, confirmed a reading) cannot approve it, approve its review, or post it; a second person does. It is decided from the document's own history. A document that arrived by email or EDI and that nobody changed was entered by the system, so one approver may approve and post it. This is the maker/checker control SOX testing looks for.

Other standards for regulated records

The same controls answer most records standards. EU GMP Annex 11 and ALCOA+ for life sciences selling into Europe; ISO 13485 for medical devices, and the records clauses of ISO 9001, AS9100, and IATF 16949; SOX for finance. Each page says where DynamoDocs meets the standard and what stays with you. Every field edit records a reason for the change, and every change to settings, rules and user access is kept in an attributed, tamper-evident change log. DynamoDocs holds no SOC 1 or SOC 2 report.

Compliance & subprocessors

DynamoDocs does not currently hold a formal SOC 2 or ISO 27001 certification. Security is enforced through the technical controls described above: per-customer isolation, encryption at rest, and application hardening. We keep a current list of subprocessors (for hosting, email capture, and the demo scheduler) available on request. Our published support commitments and response targets are on the Support page. For a security review, a questionnaire, or to discuss your compliance requirements, email scott@uptimizeme.com.