Trust
Security & Data Protection
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.
Audit trail
Every document carries an append-only history: how it arrived, each status change, each export attempt, and each human edit, recorded with the person who made it. Edits capture the before and after value of every field changed, so "who changed this amount, and what was it before?" has an answer without reconstructing it from memory. Posting is guarded too: 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. Retention of documents and extracted data is configurable per customer.
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.
Security FAQ
Common security questions
How is customer data isolated?
Every DynamoDocs customer runs its own isolated instance with a private database, secrets, and credentials. No documents, extracted data, or ERP connections are shared between customers.
How are ERP credentials protected?
Connector credentials are encrypted at rest with AES-256-GCM and are never returned to the browser. The interface shows only that a credential is saved, never its value. Connections can be tested from the Settings screen, and every ERP target runs in simulation mode until you explicitly switch it live, so a misconfigured connection cannot post to your ERP.
Is EDI traffic secure, and how is AS2 handled?
AS2 messages are signed and encrypted in both directions with certificates exchanged with each trading 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 altered after signing, is rejected and no document is created. Plaintext posts to the AS2 endpoint are refused, a replayed message is re-acknowledged without creating a second document, and the signed MDN receipt we return is verifiable by the partner's own stack. Over SFTP, files are written under a temporary name and renamed into place so a partner never reads a half-written file. Partner credentials and certificates are encrypted at rest with AES-256-GCM and never returned to the browser. Both are verified against genuinely foreign implementations rather than only our own code: AS2 in both directions against a public third-party AS2 server and a separate cryptographic toolchain, and SFTP against OpenSSH’s own server software, which is what most partners and VANs run. No trading partner has certified DynamoDocs; every partner runs its own test cycle regardless of vendor.
Do you have SOC 2 or other certifications?
DynamoDocs does not currently hold a SOC 2 report or other formal certification. Security is enforced in the product itself: each customer runs an isolated instance, connector credentials are encrypted at rest with AES-256-GCM, sessions use httpOnly cookies, access is role-gated, and the application is hardened with security headers and per-IP rate limiting. If your procurement process needs a security review or questionnaire, contact us and we will work through it with you.
Where is data hosted and how long is it kept?
Deployments can run in a managed cloud region or fully self-hosted on your own infrastructure. Document and data retention is configurable per customer and defined in your services agreement.
Is there an API, and how is it secured?
Yes, a deliberately read-only one, plus outbound webhooks. The API (/api/v1) authenticates with bearer keys that are shown once at creation and stored only as hashes, and it answers GET requests only: every write method is refused, so an API key can read documents and their extraction and audit data but can never alter them. Corrections happen only in the reviewed UI path. Outbound webhooks POST document-lifecycle events to URLs you configure, signed with HMAC-SHA256 over a timestamped body so your receiver can verify both the sender and the freshness of each delivery; the signing secret is encrypted at rest and never returned to the browser.
Does DynamoDocs hold our bank account details?
Only if you use payment-file export, and then under stricter handling than anything else in the system: vendor account numbers are encrypted at rest, reads are masked, and the banking profile is editable by administrators only. Generating an ACH (NACHA) file, which necessarily contains account numbers, is also admin-only and disabled entirely in the demo. DynamoDocs never moves money: it produces the payment file your bank or ERP payment run executes, gated on documents that passed the approval step, and records each batch on the documents' audit trails.