Deal-side aware permissions

What deal-side awareness does for you on a live mandate

Every data room has an internal working area and an area the other side sees. On a sell-side mandate, the bank and its seller client share the internal room and the buyers are external. On a buy-side mandate the arrangement is reversed. The bank and its buyer client share the internal room, and the seller is the outside party.

CogniSuite stores which of those two arrangements a deal has, and the permission engine reads it. You do not tell the room that buyers are external. You tell it the mandate is buy-side, and the room works out on its own that the seller is now the counterparty and belongs outside the internal folders.

The result on a live deal is that the counterparty starts with no access to the internal room, on either kind of mandate, without anyone building a matrix by hand. The default is no access to internal folders, and access exists only where your team granted it.

Why this is structurally different from setting permissions carefully

A careful administrator can reach the same end state by hand at setup. Three things separate that from side-awareness.

First, hand-set permissions record the conclusion and lose the reason. A grant table says this organization has no access to those folders. Nothing in it says that the buyer is the counterparty on this deal. When someone creates a folder next week, the table has nothing to say about it, so the new folder inherits whatever the org-wide ceiling happens to be.

Second, the default is what actually governs a room. Most folders in a working data room never receive an explicit grant. Careful configuration sets exceptions. Side-awareness sets the baseline that every unconfigured folder resolves to, which is the far larger surface.

Third, the default is computed in one place. The folder tree a counterparty sees and the files the download path will serve resolve access through the same rule, so the two cannot disagree. That matters because a second implementation of the same rule can omit a check. If a listing path worked out visibility on its own, separately from the access check, a folder scoped to one organization could appear in another organization's tree while the files inside it stayed blocked. A folder name can disclose plenty by itself, including the identity of a bidder or the existence of a dispute. Resolving both questions through one path removes that failure mode.

How the room decides who the counterparty is

The room reads the deal type from the project's own record. It treats a deal as buy-side only on an exact match. Anything missing, unrecognized, or unreadable returns sell-side, so a read failure degrades to the more conservative of the two shapes rather than to an untested one.

From that single value, the room derives which party shares the internal room with the bank: the buyer on a buy-side deal, the seller otherwise. A folder is treated as internal by walking up the tree to the nearest ancestor that sets a visibility label, and failing closed to internal if none resolves. If the actor's role is neither the bank's nor the internal client's, and the folder resolves to internal, the default access for that folder is none.

This is a default rather than an absolute block, and that is deliberate. Deals routinely require handing one internal document to the other side. An explicit folder grant written by the deal team is applied on top of the default and wins, so a single internal folder can be opened to the counterparty without weakening anything else. The same internal-versus-external split also decides which folders appear in the tree listing, so a blocked folder does not appear in the counterparty's tree at all.

How a folder gets scoped to one organization for clean teams

Folders carry a visibility label: internal, external, all buyers, or specific. A folder marked specific names one organization and is readable by that organization alone, not by every bidder in the room.

The lookup walks up the tree the same way, but with a rule that prevents scope from leaking. It returns the target organization only when the nearest ancestor that sets any visibility value is set to specific. If it meets any other visibility value first, it returns nothing. So a specific grandparent sitting under an external parent does not silently narrow the parent's subtree, and it does not project its own scope downward past a folder that has already declared itself open. Any organization that is neither the bank nor the internal client, and whose identifier does not match the target organization, defaults to no access.

The canonical M&A folder structure the room can build for a new deal tags its restricted categories as internal with a clean-team marker rather than as specific. That is honest about a real constraint: a specific folder needs a target organization, and at the point a deal is created that organization does not exist yet. You point the folder at the clean team when the clean team becomes a real party in the room.

Why reading and exporting are enforced as two separate decisions

Folder access resolves to one of four grades: full, watermark, view, or none, with a separate upload permission. View is worth spelling out. A view folder is readable in the in-browser viewer, and its files cannot be downloaded or exported.

Both export routes are gated on the same condition. The attachment download and the inline native stream that the in-browser viewer uses to render spreadsheets and Word files on the client are refused together when the organization's download level is none, or the folder level is none, or the folder level is view. A restricted viewer therefore falls back to the watermarked rendition, and native interactive rendering stays reserved for viewers who were already allowed to have the file.

Bulk export repeats the check for every file inside the archive rather than trusting a single check at the top. A single check would answer the question for the request rather than for each file, and a ZIP can contain files from several folders with different access levels, so one answer for the whole request cannot be right for all of them. Anything the viewer is not permitted to export is left out of the archive.

How watermarking resolves when the folder and the organization disagree

Stored files are always clean originals. The watermark is applied at the moment of serving, carrying the viewer's name, their organization, a UTC timestamp, and the word CONFIDENTIAL. Two people downloading the same document receive two different files, and neither one is the copy held in storage.

Precedence runs one way. The handler starts from the organization-wide download setting, then asks whether an explicit folder grant exists anywhere up the tree. Only an explicit grant overrides, and it overrides in both directions. An explicit full grant on one folder deliberately yields a clean copy to an organization whose overall policy is watermarked. An explicit watermark grant forces a mark on an organization whose overall policy is clean. Absent any explicit grant, the organization default stands unchanged. The same resolution is applied to single-file preview, to the rendition of Office formats, and to every file inside a bulk ZIP, since files in one archive can come from folders with different settings.

Marking covers PDF, Word, Excel, PowerPoint, and common image formats. Any file type with no marking support returns an error rather than the clean original, and the request is refused with an explicit message. Refusal is the safe outcome: a viewer whose policy requires a watermark is told the file cannot be marked and asked to contact the deal team, rather than being handed an unmarked copy.

Where this stops

Watermarks here are visible, not forensic. There is no invisible per-recipient marking. The Office variants express the mark as a document header, which a determined recipient can strip, so the mark deters casual redistribution rather than preventing it.

Watermarking and view-only levels are configuration, not a default posture. A new organization's default is full download, so a room where nobody sets folder rules stays open by design. If your policy is restrictive, set it.

Retrieval for AI features admits any folder where access is not none, which includes the view and watermark levels. An answer can therefore quote text from a document the asker is only permitted to view. That is consistent with read access, and it is a real distinction worth knowing before you rely on view-only as a confidentiality boundary rather than an export boundary.

The activity log is a tool for the bank. It records the source IP of the events it captures, but it is readable and exportable only by bank roles, so it is oversight rather than a mutual record either side can independently audit. It is also not cryptographically tamper-evident.

See /security for how the room is protected more broadly.