Sapherbox as a virtual data room

A virtual data room is a folder with rules. Somebody, usually a company being sold, audited, financed or sued, puts a few hundred documents in one place and lets a few dozen outsiders read them for a few weeks. The rules are what make it a data room rather than a shared drive: who gets in, what they may do, when it closes, and what evidence remains afterwards.

Dedicated data room products exist for this, and the good ones are good. They are also priced for a transaction, often per page or per gigabyte per month, which is why many smaller deals and most audits end up in a SharePoint site or a cloud-drive link instead. Those are cheaper and have none of the rules.

Sapherbox sits in between. It was not built as a data room, but the controls a data room needs are the controls an end-to-end encrypted collaboration product needs anyway: fine-grained access, outsiders who can be given exactly one thing, time limits, an audit trail that cannot be edited, and reports that answer “who has access to what” on the day somebody asks. This article shows how to set one up, what evidence it leaves behind, and, plainly, which data room features it does not have.

One thing a dedicated data room cannot offer

Start with the property that makes Sapherbox different from both the cheap option and the expensive one. In a conventional data room, the vendor can read every document. Its staff may be contractually forbidden to, and the vendor may be reputable, but the capability is there: the files are encrypted at rest with the vendor’s keys, and a subpoena, a breach or a rogue administrator opens the whole deal.

In Sapherbox the documents, their names and their folder structure are encrypted on the device of the person who uploaded them, with keys that only the people you invited hold. What our servers can and cannot see lists exactly what remains visible: sizes, timestamps, who holds which folder. Not the content, not the names. Whoever hosts the tenant, including us, cannot read the merger file. For a seller whose entire negotiating position is in that folder, this is not a nice-to-have.

Setting it up

One folder per deal. Create the top-level folder and build the index inside it as subfolders: 01 Corporate, 02 Financial, 03 Contracts, 04 HR, 05 IP, and so on. The numbering is your index; keep it stable for the life of the deal, because the audit trail and the reports refer to these names. Access to the top folder flows down the tree, so a bidder admitted at the top sees the whole index, and a bidder admitted only to 02 Financial sees only that.

One group per bidder. Do not share with individuals. Create a group for each bidding party, put their deal team in it, and share the folder with the group at the Viewer level. When a bidder adds an associate, your deal lead adds one person to one group and the associate has the index; when a bidder drops out, your deal lead removes the group from the folder and every person in it loses access in one act. Share with the group, not the person explains why this is also the safer design.

Outsiders are guests. Everyone on the bidder side registers through the invitation as a guest account. Guests have their own keys and their own passwords, your administrators can see that they exist and what they hold, and they do not get anything that was not explicitly shared. If the tenant requires a second factor at login, that applies to guests exactly as it does to your own people. If your own people should not be able to invite new outsiders freely during the deal, the administrator can restrict them to sharing with existing accounts only.

Viewers see and download; nothing else. The Viewer level carries one capability: fetch the file. Viewers cannot upload, rename, move, delete or share, and they cannot see who else has access. If a counterparty must deliver documents into the room, for example a buyer’s financing bank submitting a comfort letter, give them a subfolder at the Uploader level. An uploader sees only what they themselves put there, and never holds the folder’s content keys, so they cannot read the other side’s documents even if the server misbehaved. For a one-off delivery from someone who should not have an account at all, an upload link does the same for a single folder.

Set the closing date on day one. Every folder can carry an expiry date. On that date it either empties itself and stays, keeping the structure and the membership for the next deal, or disappears with everything in it. Choose when you create the room, not when you are closing. Individual documents that must go earlier, a draft that is superseded, a report that was shared by mistake, get their own scheduled deletion date. Both run under a system actor and are written to the audit log, so the evidence shows the room closed on schedule and not by someone’s hand. Deletion and recovery covers what the recycle bin does and does not keep in the meantime.

What the room records

A data room exists partly so that, a year later, nobody can claim they were not shown a document. Sapherbox records three kinds of evidence.

Every download. The audit log holds an entry for each file download: who, which file, when, from which address. It also holds every grant, every change of permission level, every group membership change and every removal, including the key rotation that a removal triggers. The log is HMAC-chained, so the application cannot alter or delete an entry after the fact; an audit trail that cannot be quietly edited describes the mechanism and the verify button. The audit page filters by actor, action and date and exports to CSV.

Who has access, on any day. The administrator’s Reports page answers the access question from both sides: the inventory of every folder and who holds it at which level, expanded through groups so a reviewer sees the people and not just the group names; and the collaborations of each user, so the departure of a single associate can be checked in one view. A third tab lists dormant guests who still have an account but hold nothing, the leftovers of a previous deal. Each report exports to CSV. Who has access to what walks through the tabs; for a data room the practice is simply to export them on opening day, on each bidder change, and on closing day.

Who shared what. Every one of your own people has a narrower version of the same reports for the content they handed out, because in Sapherbox whoever shares is responsible. Your deal lead can see at any time which groups and people hold the room, without asking an administrator.

Together these are the closing binder: the dated CSV exports plus the audit entries for the removals at the end. One point to decide early: folder and file names are encrypted, so the reports show them masked, first and last character only, unless the administrator turns on plaintext names for reporting. For a data room, where the index is not the secret but the documents are, most tenants turn it on for the deal folder’s lifetime, and why we encrypt names too sets out what that trades away.

Closing the room

When the deal closes or a bidder withdraws, remove the group from the folder. Every member of that group loses access at once, and the folder’s keys are rotated, so a stale session or a cached key on a bidder’s laptop no longer opens anything new; revocation means changing the locks explains the difference between deleting a permission row and rotating a key. What a viewer already downloaded, they already have; no data room, including the dedicated ones, can undo a download, and we would rather say so than imply a control that does not exist.

Then let the expiry date do its work, delete the dormant guests the report lists, and file the final exports. A guest who wants their own account gone afterwards can delete it themselves from their profile, with the deletion written to your audit log, which closes the right to erasure without a ticket on your side.

Where a dedicated data room still wins

We publish our limitations, and this list is deliberately complete.

No view-only mode. In Sapherbox, viewing a document is fetching it; the browser decrypts it to display it. A viewer can therefore save it. There is no “may look but may not download”, no disabled printing and no screenshot prevention. Dedicated data rooms often offer these. We think they are weak controls against a determined reader with a phone camera, but they are controls, and a seller’s counsel may require them.
No dynamic watermarking. Documents are not stamped with the viewer’s name and the time. Since the server never sees the plaintext, it cannot stamp it, and we have not built client-side watermarking. We are working on electronic signatures instead, so that the document a party signed at closing is provably the one in the room.
No page-level analytics. The audit log records that a file was downloaded, not which pages were read or for how long. Sellers who use reading heat-maps to judge a bidder’s seriousness will not get them here.
No Q&A module. Questions from bidders and answers from the seller are a central workflow in deal data rooms. Sapherbox has no threaded Q&A; the workable pattern is an Uploader subfolder per bidder for questions and a Viewer subfolder for answers, with the discussion itself by email or in your deal tool.
No redaction tools and no click-through NDA. Redact before upload. Collect the NDA before the invitation.

When it fits

Sapherbox is a good data room when the confidentiality of the documents from the platform itself matters, when a dated access report and an unalterable download log are the evidence you need, and when you would rather use the tool you already have than buy a product for one deal. That covers most audits, most financing rounds, most litigation document exchanges and a good share of smaller acquisitions. It does not cover a controlled auction with strict view-only requirements, and we would rather you used the right tool for that than discovered the gap mid-process.

Questions?

If you are setting up a room and want a second pair of eyes on the folder structure, the group layout and the expiry settings before the first bidder is invited, get in touch at hello@sapherbox.com.