Your contracts never touch our servers

The most effective way to protect a document is to not have it. That sounds like a dodge, so this post explains exactly what we mean: how Pishik's share-link architecture works, precisely what our servers store, and what that design costs and buys you.

The entire integration surface is a link

When you create a contract in Pishik, you don't upload anything. You paste share links to documents in SharePoint, OneDrive, or Google Drive — the storage you already use, via the share links you create. Pishik stores the link and builds the review workflow around it. There is no file-upload feature in the product, and no file-upload endpoint on the server. This isn't a policy we enforce; it's a capability we never built.

When a reviewer's turn comes, their review email points them at your document in your storage. They read, comment, and redline in the editor you already use — with the rights your share link grants — and then record their approve-or-reject decision with Pishik. The decision comes to us. The document never does.

What we store — the complete list

• The share links you paste, plus the labels you give them.
• Workflow state: stages, reviewers, decisions, timestamps, deadlines, signing status.
• Delivery metadata: which email went to whom, and whether it was delivered, failed, or manually logged — reported honestly, never optimistically.
• What your team writes in Pishik: comments, notes, checklists, and reviewer decision comments. Treat these like the work product they are.

And what we never store: your documents' contents, your redlines (they live in your editor, where they belong), or reviewer credentials — reviewers never log in, so there are none to store.

What the design buys you

Access control stays in one place. Your storage's sharing rules remain the single source of truth for who can open a document. Revoke a link in SharePoint, OneDrive, or Google Drive and it's revoked — instantly, without asking us, without a support ticket. Pishik never holds a second copy that outlives your decision.

Redlining works exactly as it always did. Reviewers get Word or Google Docs behaving like Word or Google Docs, not a viewer that approximates them.

The breach math changes. A hypothetical attacker who compromised Pishik's database would find links and workflow metadata — not a warehouse of executed agreements. That's a meaningfully smaller prize. We'll be honest, though: links and metadata still have value, which is why the next section exists.

Scope your links like you mean it

The architecture hands access control back to you, which means link scoping is where your real security posture lives. Our honest guidance: scope share links to your organization or to named reviewers whenever your storage allows it. "Anyone with the link" is convenient and is also exactly what it says — anyone, with the link. And remember that rights follow the link: a view-only link means reviewers can read but not redline, an edit link means they can do both. Choose deliberately. The support center has a practical guide to scoping share links safely, alongside the full explanation of how the share-link model works.

The same discipline, everywhere else

Once you decide documents don't belong on your vendor's servers, other decisions follow the same logic.

Notification emails are deliberately terse: when a teammate @mentions you in a contract comment, the email says who mentioned you and on which contract — and includes none of the comment text. Inboxes get forwarded, scanned, and synced to personal phones; contract discussion stays behind sign-in.

Review email can be sent through your own infrastructure — your Microsoft 365 tenant via Graph, Azure Communication Services, or any SMTP provider — so mail to your reviewers can come from your own domain. Replies go to your team's reply-to address: yours, or a company-wide one your admin sets.

Even our own staff tooling follows the rule: it works on workspace metadata and cannot read your contracts — there's nothing of theirs on our side to read.

No custody also means no hostage

Since your documents were never ours, leaving Pishik can't strand them. And the records we do keep — workflow history, decisions, the audit trail — are exportable at any time: any single contract record, or the whole workspace. Every export is itself audit-logged. The details live in the export and restore guide, and the broader picture — tenant isolation, where data lives, what our metadata-only posture means in practice — is on the data-privacy article and the security page.

We think this is the right architecture for a tool that sits next to privileged documents: your files in your storage, our servers herding the process around them.