Every line below is a property of the system rather than an intention. Where a claim depends on how this deployment is run rather than on how the product is built, this page reads the setting and says only what is true of it.
Uploaded documents are held in object storage separate from the application's database, encrypted in transit and at rest. Encryption at rest uses a key we manage ourselves rather than one the storage provider holds on our behalf. They are stored in a single United States region and are not replicated outside it.
They are never served from a public URL: every download goes through the application, which checks who is asking before it hands anything over. A PDF or an image can be previewed in the browser, from a fixed list of types the browser is told not to second-guess, and each preview is written to the audit log; anything else is only ever handed over as a download, so nothing a client sends can run as a web page. Links that do reach storage directly are signed and expire within minutes, so one copied out of a browser's history is worthless almost immediately.
Every company that can reach a document is named on the subprocessors page.
Unless a firm turns reading off, each document is read to work out what it is, check it against what was asked for, pull out the figures the firm needs and summarize what arrived. That is done by Claude models running on Amazon Bedrock, inside our own AWS account, in United States regions only.
Nothing a client sends is used to train a model — not by Amazon, not by the model's maker, and not by us — which our data processing addendum commits us to. The model's maker never receives the document at all, and Bedrock keeps neither the document nor the answer once it has been read. What is kept is the result, in the firm's own workspace, under the firm's retention setting.
Nor is it sold, or shared for advertising. There is no advertising in this product, and the same addendum commits us to that as well.
A document uploaded into our storage is scanned before anyone can open it. It is withheld until its scan comes back clean, and a scan that failed is never treated as one that passed.
Every workspace is isolated from every other, and that isolation is enforced in the data layer rather than remembered by each query — a model carrying customer data cannot be written without it, and the test suite fails if one is.
Within a firm, what a member may do depends on their role: reading the inbox and working through it is separate from destroying a submission, revoking a client's link, exporting, or reading the audit log. Where the firm's documents are stored, and how long they are kept, are decided by the workspace's owner alone.
Everything that happens in a workspace is written to a log the firm can read and nobody can alter or delete — append-only, enforced by the database itself rather than by the application's good behavior. That includes every time one of your clients' documents is opened through the application, by anyone, our own staff included. Engineers who maintain the systems beneath the application are bound by confidentiality and by the access limits in our Data Processing Addendum; access at that level is not written to your firm's log.
A client's signature is protected the same way. Once written it cannot be changed, and it is deleted only with the answers and documents it vouches for, when your retention setting says their time is up.
Each signing also keeps a log of what happened — when the code was sent, when the client agreed, when they signed — in which every entry carries a fingerprint of the one before, so a changed or missing entry shows. It is made into a document you can download, and the client is sent their own copy. Once a day, a single fingerprint of that day's signing logs is sent to an independent timestamping authority, which signs it with the time. That lets the date of a signing be shown without relying on our clock or our database, and the authority learns nothing about what was signed.
Three separate things are kept, for three different lengths of time. Your firm's audit log is yours: it lives as long as the records it describes, under the retention window you set, and nobody can alter it. The application's own technical log — the one an engineer reads when something errors — is kept by our hosting provider for the short period our plan with them allows, and by our error-monitoring service for up to ninety days, and then rolled off. Between them sits a smaller internal record of what whoever runs the product did with their own internal screens — reading the margin report across firms, for instance. That is kept for a year, because the question it answers is asked long after the fact.
None of the three is a copy of your clients' documents. The technical log goes only to those two services, each named on the subprocessors page. It can carry an identifier — which workspace, which submission — but not a client's answers and not their files. When something errors, we are alerted that it happened, and the alert says nothing about whom it concerned.
What an investigation reads is the same evidence you can read. Your audit log says what was done in your workspace and by whom, and cannot have been edited. Each signing's log carries a fingerprint of the entry before it, so a missing or altered entry shows rather than passing unnoticed, and the day's fingerprints are timestamped by an independent authority — which means the sequence of events can be shown to somebody who trusts neither our clock nor our database.
What we commit to telling you, and when, is in section 8 of the data processing addendum rather than here, because that is the version you can hold us to.
A form's link and a single client's request are separate, so one can be revoked without disturbing anyone else mid-upload. Links can expire. A page holding a client's documents is never indexed and never passes its address on to anything the client clicks.
A request can ask more than one person: a client, their spouse, their accountant or attorney. Each person has a link of their own and sees only their own part of it. Of everybody else they see who is on the request, what each is there as, and whether their part is started or sent, and never what anyone else answered or uploaded. The server enforces this on every page and action a person's link can reach, not the page in front of them, and an automated test tries each of those routes against another person's part. One person's link can be taken back, or their part handed to somebody else, without disturbing anyone else's. The client may answer somebody's part for them, on their word that the person agreed, only before that person has started it, and without being shown what the firm has on file about them; the record says who typed it. Somebody asked to sign reads the whole reply first, because that is what their signature covers.
A workspace keeps documents until the firm sets a retention window. If it sets one, the firm is emailed before anything goes, and when the window expires the document is permanently deleted rather than hidden or flagged.
A file the firm keeps in a client group's vault is outside the window, because it was put there to be kept. It is permanently deleted when the firm removes it, deletes the client group, or closes its workspace.
The record of what was asked for and what arrived outlives the documents, because that record is the firm's own and not the client's.
One third party's script runs of its own accord, on three pages: the ones where a firm enters its card. There, Stripe's own card fields are drawn by Stripe in frames of its own, so the card number goes to Stripe and never passes through us. There is no analytics vendor, no advertising network, and no content delivery network with a view of your clients' documents.
Others can run where a document is attached: on the page a client sends documents from, on a client's portal page where the firm lets them add to a vault, and on every page a firm's member sees signed in, so the button works however they reached it. Whoever keeps a document in Dropbox, Google Drive or OneDrive can attach it instead of downloading it first, and that opens the service's own window, signed in to their own account, listing their files rather than ours. The script that opens it is fetched only where it can be used — on the client's page when a question that takes a document appears, in the portal when it shows a vault they may add to, on the firm's when a member opens the dialog to upload something — so a form that asks for no document never contacts Dropbox, Google Drive or OneDrive. The document travels from the drive to the browser to the same storage uploads already go to. We never hold the key to anyone's drive and never look inside it.
Apart from those, every page — and every page a client ever sees — refuses to load code, fonts or images from any other origin, and the test suite fails if that changes.
Passwords are stored as hashes that cannot be reversed. Two-factor authentication and passkeys are available on every account.
The amended Regulation S-P asks an investment adviser to oversee the service providers that hold its clients' information. This is what that review needs from us, in one place.
What we hold. What your clients send through your forms — their answers, their documents and their signatures — the contact details you enter for them, and the record of what happened to each. Nothing else about them.
If something goes wrong. If we become aware that your clients' information has been reached by someone who should not have it, we tell you without undue delay and within 72 hours, as section 8 of our data processing addendum commits us to: what happened, whose information, what we have done, and what we advise. Telling your clients is yours to do — the amended rule gives you thirty days — and our notice is written to let you do it.
What you can check for yourself. Every company that can reach a document is on the subprocessors page. Your audit log records what was done in your workspace and by whom, and nobody can alter it. You can require two-factor sign-in for everyone in your workspace, set how long records are kept, and have a copy of every email and text sent to a client go to your own archive.
The platform underneath. The application, its database and its job queue run on Laravel Cloud, which holds a SOC 2 Type 2 attestation for Security, Confidentiality and Availability, and an ISO 27001 certification. Their current status and the reports themselves are published at trust.laravel.com (under Cloud) rather than repeated here, so what you read is what is true today. That is their attestation and not ours — see below — but it is the answer to the part of a questionnaire that asks who runs the servers.
We hold no SOC 2 report, no ISO 27001 certification and no PCI attestation, and we are not a HIPAA business associate. The platform we run on holds two of those, as above; a vendor's certification is not its customers' certification, and we would rather say so plainly than let a procurement questionnaire read one as the other. There is no uptime commitment in our terms, because there is nothing measuring one yet.
Write to security@cartenda.com. We will not pursue anyone who reports a vulnerability in good faith and gives us a reasonable chance to fix it before saying so publicly.