Security

Effective 1 September 2026

How Pactly protects documents, what we can prove, and - just as importantly - what we cannot. Last reviewed 1 September 2026.

Pactly is an early-stage product. We are not SOC 2 or ISO 27001 certified and have not had a third-party penetration test. We would rather say that here than let a buyer discover it in a questionnaire. What follows is what is actually true today.

Verify any document yourself

Every signed document can be checked at https://app.mypactly.com/verify - with no account and no cooperation from us. Paste the reference from the certificate, or upload the PDF and we will compare its SHA-256 against the copy we sealed. The audit chain is re-walked on the spot and the result is shown either way, including when it fails.

This matters more than any assurance we could offer about ourselves: the party who most needs to check a document is usually the counterparty, who has no account and no reason to take our word for anything.

Document integrity

• Each document is hashed with SHA-256 before a signer signs and after the signed copy is produced. Both are printed on the Certificate of Completion.
• Signed PDFs carry an embedded RFC 3161 document timestamp. This is a real cryptographic signature over the whole file, made by an independent timestamping authority. Open the document in Adobe Reader and the signature panel shows it, and reports the document as modified if a single byte has changed since. It can also be checked with pyHanko or openssl, by anyone, without our involvement.
• If no timestamping authority is reachable when a document is sealed, we fall back to an AES-256 permission lock and record that we did. The Certificate of Completion names which seal the file carries, because the two are not equivalent: permission flags are advisory, viewers choose whether to honour them, and tools exist that strip them.
• What this is still not: a full PAdES signature naming Pactly as the signer. That needs an X.509 certificate from a CA on Adobe's trust list, which requires a validated legal entity and a private key held in certified hardware. A document timestamp needs neither, because the signature is made by the timestamping authority rather than by us - so the file is verifiable, while the identity attached to it is the authority's, not ours.

Audit trail

Every event on a signing request - viewed, identity verified, signed, declined, reminded, cancelled, changes requested - is written to an append-only log. Each row stores a SHA-256 hash of its own contents chained to the hash of the row before it. Altering or removing any entry breaks every hash after it, which is detectable by re-walking the chain. The chain head and its length are printed on the certificate.

Documents signed before hash chaining shipped carry entries with no chain hashes. The verification page reports those as unverifiable rather than as intact. We will not backfill hashes onto them: computing them now would manufacture evidence the rows were never checked against, which is precisely what a chain exists to prevent.

Trusted timestamps

When a signature is recorded we request an RFC 3161 timestamp token from an independent timestamping authority, over a hash of the signature and the document. Only the hash is transmitted - the authority never receives the document or any part of its contents.

This matters because every other time in the record is our own server clock, written to our own database. A timestamp token is an assertion by a party with no stake in the outcome, and it can be verified against the authority directly:

curl -O https://app.mypactly.com/verify/<reference>/timestamp
openssl ts -reply -in timestamp -text

Timestamping is best-effort: if the authority is unreachable the signature still completes, and the certificate states plainly that no token was obtained rather than implying one exists.

Signer identity

By default, each signer must enter a one-time code sent to the email address the document was addressed to before the document opens. Senders can instead issue an access code out of band, which is stronger because it does not travel the same channel as the link.

The certificate records which method was used, including when the answer is that no check beyond the link was made. A signing link that has been forwarded produces a signature at a lower assurance level, and the document says so rather than presenting all signatures as equivalent.

At the moment of signing we also capture IP address, browser user-agent, approximate location derived from the IP, and a device fingerprint derived from those with the link token. These are recorded once, on the first signing session, so later views cannot overwrite them.

Access control

• Each signer receives a unique, unguessable link that authorises that signer and nothing else.
• Uploaded and signed PDFs are stored outside the web root and are served only through routes that check the requester is the owner, an administrator, or a permitted teammate.
• Accounts may enable TOTP two-factor authentication, with single-use backup codes. We recommend it for any account that sends documents.
• Sending documents to other people requires a confirmed email address, so nobody can solicit signatures under an address they do not control.
• Passwords, one-time codes and backup codes are stored only as scrypt hashes. We cannot read any of them.

Where your data lives, and who touches it

These are our subprocessors. Each is a company that may process customer data on our behalf in the course of running the service.

The AI summary, specifically

The plain-language summary shown to signers is produced by sending extracted document text to a third-party language model. If your documents are confidential, this is the disclosure that matters to you. The text is sent once per document, the result is cached so it is not sent again, and the provider is contractually barred from training on it. If that trade is not acceptable, the feature can be disabled for your account - email us and we will turn it off.

Retention and deletion

• Anonymous documents are deleted, along with their files, 24 hours after upload. This is enforced by a scheduled job, not by policy alone.
• Account documents are kept until you delete them. Deleting a template or request removes its stored PDFs.
• Audit records are retained for the life of the account, because a signature without its trail is not worth much.
• Account deletion: email us and we will delete the account and its documents within 30 days. We are building self-service deletion; until it ships, the manual route is the honest answer.

Transport and application security

• HTTPS everywhere, with HSTS.
• Session cookies are HttpOnly, SameSite=Lax, and Secure in production.
• CSRF tokens on every session-authenticated form.
• Rate limiting on sign-in, registration, password reset, one-time codes and anonymous uploads.
• X-Content-Type-Options, X-Frame-Options and Referrer-Policy set on every response.

Data processing agreement

We will sign a DPA. Email hello@mypactly.com and we will send one. If you need specific contractual terms, standard contractual clauses, or a security questionnaire completed, ask - we would rather answer honestly than have you assume.

Reporting a vulnerability

Email security@mypactly.com. We will acknowledge within two business days and keep you informed until it is resolved. We will not pursue legal action against researchers acting in good faith who give us reasonable time to fix an issue before disclosing it.

If something goes wrong

If we become aware of a breach affecting your data we will notify affected account holders without undue delay and within 72 hours of becoming aware, with what we know, what we are doing, and what you should do.