How your data is handled

The data flow

1. Upload. You upload a PDF and enter your email and the signers' emails. The server encrypts the PDF and the transaction details (AES-256-GCM) with a new random key for this transaction.
2. The key lives only in the email links. The server stores the encrypted files and a hash of each link, never the key itself. Without one of the emailed links, the stored files can't be decrypted, even by us.
3. You confirm. We email you a confirmation link. Nothing is sent to the signers until you open it and press "Confirm and send".
4. Each signer signs. They open their link, agree to the terms, review the PDF and sign. We record their email, the times they opened the link, accepted the terms and signed, their IP address and browser (user agent), their typed name and their optional drawn signature, all encrypted with the transaction's key.
5. Sealing. After the last signature, the server adds signature pages and an audit certificate, then seals the PDF with a PAdES digital signature. A SHA-256 hash of the signature (never the document) is sent to an independent timestamp authority (DigiCert, or Sectigo as a fallback), which returns an RFC 3161 timestamp that is embedded in the PDF.
6. Delivery. The sealed PDF is emailed as an attachment to the sender and every signer.
7. Deletion. As soon as every party's email is sent, the transaction's files are deleted. The final PDF is self-proving: anyone can check the seal, the timestamp and the original document's hash without AppKatz.

Who can read your document

Only the people you invite. While a request is in progress, your document is stored so that it can be decrypted only with one of the participants' email links:

• Everything is encrypted before it's stored. Each request gets its own random 256-bit key. The PDF and every detail of the transaction (file name, email addresses, names, signatures and audit data) are encrypted with AES-256-GCM before anything is written to disk.
• The key exists only in your links. It is part of the links emailed to the sender and the signers. Our server keeps only a one-way fingerprint of each link, never the key itself.
• We can't open stored documents, even on purpose. What sits on our server is unreadable data, with no file names or email addresses in plain text, and there is no admin screen that shows documents. Without a participant's link, the stored files, and any backup or copy of them, cannot be decrypted, including by AppKatz staff.

Where this protection stops. When a participant opens their link, the key travels with that request, and our server decrypts the document in memory to show it to them. After the last signature it does the same to add the signature pages and apply the digital seal. Nothing is logged or kept from those steps, and the key is never saved. So the protection covers documents at rest, not a server deliberately altered to capture keys as links are used. The links themselves travel by email and through our network provider, and the final PDF is emailed to every party as an attachment.

Why not end-to-end encryption? In a fully end-to-end design our server would never see your document at all, even while it is being signed. But the final PDF is assembled and sealed on our server with AppKatz's sealing key, which makes it verifiable later without us, and that key can't be put in your browser without making it public. We chose a verifiable, sealed final document, with stored data that only participants can decrypt.

When data is deleted

• Completed: immediately after the final copy is emailed to every party. If an email can't be delivered, we retry for up to 24 hours, then delete regardless.
• Declined: immediately, after all parties are told.
• Unfinished: automatically 14 days after upload, whether or not the sender confirmed. No one is notified, because we can't decrypt the request to find out who to tell.

What we don't keep

• No reading of your document. AppKatz never scans, analyses or extracts the text of your document. The server only parses its PDF structure (page count, password protection, existing signatures) and appends the signature pages and audit certificate. Each party confirms the document follows the Acceptable Use Policy.
• No copies. We can't resend a final copy, confirm a signature or testify about a transaction later. Each party must keep their own copy.
• No logs of your transaction. Our application logs record only event types (for example "signed" or "purged"), never emails, names, IP addresses, file names, document contents, signatures or links. The web server keeps no access log.
• No backups of transactions. In-progress files aren't backed up. Any copy left on disk, for example in a storage snapshot, is encrypted with a key we don't have.
• No temporary files. Uploads and PDF processing happen in memory.
• Abuse limits count requests per IP address and per sender email using one-way hashes, in memory only, for up to 24 hours. They are never written to disk.
• No tracking. E-sign pages load no analytics, ads, pixels, third-party scripts or web fonts, and set no cookies. Sponsor messages are static text and images served by appkatz.com, shown only on screens that never display your document, and never in emails or the final PDF.

Who else handles your data

• Cloudflare is our network provider. It carries all traffic to appkatz.com, including uploads and link addresses, and decrypts it in transit to route it. It doesn't store documents.
• Our email provider delivers the invitations and the final PDF. It handles the attachment in transit and keeps standard delivery logs (sender, recipient, time) under its own policies. Every recipient's mailbox keeps their copy, as intended.
• The timestamp authority receives only a hash, never the document or your details.

What the final PDF contains

The original pages, a signature page for each signer, and an audit certificate listing every party's email, the relevant times (UTC), IP address and browser, the terms each party accepted, and the SHA-256 hash of the original document. It is sealed so that any later change is detectable. Identity is verified by email only.