Storage options

Two ways to hold your documents, and what each one costs you

Termsroom holds the record of a negotiation and not the agreements. Where the agreements live is your choice, and the two paths do not carry the same custody position. This page sets them side by side.

The short version

On the SharePoint path, Termsroom holds no credential into your tenant. Access is a token your own tenant issues at the moment it is needed, scoped by your administrator to one site, and revocable by them without contacting us.

On the bring your own storage path, Termsroom does hold a credential. You create an access key in your own console and hand it over; we encrypt the secret half of it on arrival and use it to read and write your bucket. That is a real difference and it is the reason this page exists rather than a paragraph saying we never hold anything.

Some organisations do not treat consumer grade file sync as enterprise storage, and will not put a contract archive in one whatever the tenant type says. The API key path exists for them: a bucket with versioning, object lock if they want it, their own retention schedule and their own encryption keys, connected without a directory in the middle.

Side by side

Option	What Termsroom holds	How organisational status is proved	What happens on revocation	What a security reviewer should check
SharePoint or OneDrive for Businessavailableno credential held	Tenant id, site id, drive id, folder name, and the validation report. No credential of any kind.	A directory lookup. A personal Microsoft account cannot produce an organisation profile, and a consumer OneDrive reports its drive type as personal, so the answer comes from Microsoft rather than from a box the user ticked. The drive type is recorded either way, so the connection says whether it is a site library or a personal drive inside your tenant.	Your administrator deletes the Sites.Selected grant on the site. Access stops immediately and needs no contact with us. There is no credential left over on our side, because there never was one.	The consent screen. Termsroom requests User.Read and Sites.Read.All delegated, and Sites.Selected as an application permission, and never requests offline_access, so Microsoft issues no refresh token.
S3 compatible bucket, your keysavailablewe hold a credential	Endpoint, region, bucket, prefix, access key id, the validation report, and a vault reference to the secret access key. The secret itself is readable only by the service role.	An attestation by your administrator, supported by two checks we can run: the bucket is not readable by the public, and it keeps versions. A bucket has no directory behind it, so this is weaker evidence than the Microsoft path and the connection record says so.	You delete or rotate the key in your own console. Access stops at once. Disconnecting in Termsroom retires the connection; ask us to purge the vault entry and we will, but rotating the key is what actually ends access and it does not need us.	The IAM policy attached to the key you issue. Termsroom needs get, put and multipart on one prefix and read on the bucket configuration. It has no reason to hold list, delete or policy rights across the bucket, so do not grant them.
Google Drivecoming soon, not builtno credential held	Nothing. There is no implementation.	Would be a Workspace directory lookup, so that a consumer Google account could be refused the way a personal Microsoft account is.	Not applicable yet.	Nothing to check. If a Termsroom screen ever suggests Google Drive is connected, that is a defect and we want to hear about it.

SharePoint or OneDrive for Business

availableno credential held

What Termsroom holds: Tenant id, site id, drive id, folder name, and the validation report. No credential of any kind.
How organisational status is proved: A directory lookup. A personal Microsoft account cannot produce an organisation profile, and a consumer OneDrive reports its drive type as personal, so the answer comes from Microsoft rather than from a box the user ticked. The drive type is recorded either way, so the connection says whether it is a site library or a personal drive inside your tenant.
What happens on revocation: Your administrator deletes the Sites.Selected grant on the site. Access stops immediately and needs no contact with us. There is no credential left over on our side, because there never was one.
What a security reviewer should check: The consent screen. Termsroom requests User.Read and Sites.Read.All delegated, and Sites.Selected as an application permission, and never requests offline_access, so Microsoft issues no refresh token.

A SharePoint site library and a OneDrive for Business drive are both accepted, and they are not the same thing. A site library is owned by the institution. A OneDrive for Business drive belongs to one person, so a bargaining record placed there follows their retention and sharing and goes with them when they leave. Termsroom accepts either, names which one you connected on the connection itself, and recommends a site library for a record both parties may need years from now. A consumer OneDrive is refused: Microsoft reports it as a personal drive and the product will not take it.

S3 compatible bucket, your keys

availablewe hold a credential

What Termsroom holds: Endpoint, region, bucket, prefix, access key id, the validation report, and a vault reference to the secret access key. The secret itself is readable only by the service role.
How organisational status is proved: An attestation by your administrator, supported by two checks we can run: the bucket is not readable by the public, and it keeps versions. A bucket has no directory behind it, so this is weaker evidence than the Microsoft path and the connection record says so.
What happens on revocation: You delete or rotate the key in your own console. Access stops at once. Disconnecting in Termsroom retires the connection; ask us to purge the vault entry and we will, but rotating the key is what actually ends access and it does not need us.
What a security reviewer should check: The IAM policy attached to the key you issue. Termsroom needs get, put and multipart on one prefix and read on the bucket configuration. It has no reason to hold list, delete or policy rights across the bucket, so do not grant them.

Google Drive

coming soon, not builtno credential held

What Termsroom holds: Nothing. There is no implementation.
How organisational status is proved: Would be a Workspace directory lookup, so that a consumer Google account could be refused the way a personal Microsoft account is.
What happens on revocation: Not applicable yet.
What a security reviewer should check: Nothing to check. If a Termsroom screen ever suggests Google Drive is connected, that is a defect and we want to hear about it.

SharePoint or OneDrive for Business

Google Drive

coming soon, not built

There is no Google Drive implementation. Nothing connects to it, nothing is held for it, and no screen in Termsroom will offer it. It is listed here because customers ask, and because a roadmap item that is honest about being a roadmap item is worth more than a logo on a page.

When it arrives it will refuse a consumer Google account the way the Microsoft path refuses a personal Microsoft account, by asking the directory rather than by asking the user.

What is the same on both paths

Termsroom stores no document bytes and no clause text on either path. What it holds is pointers, hashes, clause structure, findings and the audit trail. Personal accounts are refused rather than warned about, the refusal is recorded, and a connection cannot be made active without a validation report behind it.

Both paths write into a folder or prefix of your choosing, so Termsroom material is never mixed with your own. Both keep every version. Both leave you holding a complete copy of everything you were entitled to see, whether or not you are still a customer.

The full custody position, including the queries you can run against your own data, is on the trust page, and the questions people ask before buying are on the questions page.

Both paths also record a fingerprint of every version, which is how either side confirms that the copy it holds is the one that was agreed, on whichever provider it sits. That is explained on the document integrity page.