Privacy

Tenure is the system of record for organizations where leadership turns over faster than knowledge does, universities, nonprofits and NGOs, small and mid-sized businesses, associations and chapters. The platform holds an organization’s operations and institutional memory, finance, events, members, documents, and the decisions behind them, so the record stays with the seat when the people in it rotate. This page explains, in plain terms, what information we collect, how we use it, and the choices you have. We’ll keep it honest and update it as the product grows.

• Account details you provide, things like your name, email, role, and the organization you belong to.
• The organizational records you choose to store, the finances, events, members, documents, notes, and history your organization decides to keep in Tenure.
• Basic usage data, the operational information we need to run the service reliably and keep it secure.

We use the information to run Tenure, support your organization, and answer questions from the seat’s own record, so an incoming leader can read what the role already knows instead of reconstructing it. We do not sell personal information. We use it to deliver the service you’re asking for, not to build a business out of your data.

One piece of that deserves saying plainly, because a security review will ask. Tenure AI answers from records the person asking already has permission to see, and it shows its sources. To turn those sources into an answer, the relevant record text is sent to Amazon Bedrock, which runs the Anthropic model we use. The same is true when someone asks for a summary of a text document, which sends that document’s contents, and when someone uses Draft Assist, which sends what they typed. So some of your record does leave our own infrastructure at those moments, and you should hear that from us rather than find it later. The Anthropic API can also be called directly as a fallback, in which case that text leaves AWS as well. We do not train or fine-tune models on customer data, and there is no pipeline anywhere in the product that could. Each provider’s own handling of data sent to it is governed by that provider’s commercial terms rather than ours; ask us for the terms in force.

• Your organization’s members, and the boards that inherit the record when a term ends.
• Institution staff at the office that stewards your organization. Today that means any institution account can read every organization in the portfolio, not only the ones it advises.
• Not the public. Records are separated per institution at the database layer; separation between organizations inside one institution is enforced by access rules rather than by that boundary.
• The subprocessors listed below, under confidentiality obligations and only as needed to run the service.

The complete list, so a security review can put it in a risk register rather than ask us for it. An earlier version of this page named only the AI provider, which was not enough to be useful.

• Amazon Web Services, hosting, database and document storage for the application. Data is held in AWS’s United States regions. Encryption at rest uses AWS-managed keys; there is no customer-managed key option today.
• Amazon Bedrock, and Anthropic, the model providers. Synthesis runs on Bedrock, inside AWS, using an Anthropic model; the Anthropic API is retained as a direct fallback, and record text leaves AWS when that path is the one configured. Either receives permission-filtered record text in three cases: when someone asks a question, the records retrieved for it; when someone asks for a summary of a text document, the contents of that document; and when someone uses Draft Assist, the instruction they typed. Processing location and retention are governed by each provider’s commercial terms rather than ours, ask us for the terms in force.
• Vercel, hosting for this marketing website only. It does not touch your organization’s record.

If we add a subprocessor that touches organizational records, we will update this list and tell active organizations before it starts processing.

The marketing site you are reading sets no analytics or advertising cookies, and we do not track you across it. Nothing third-party loads on any page until you ask for it, the scheduler on the contact page is the only such thing, and it loads only after you press a button. If you never open it, no third party sees your visit.

The organization owns its record. That’s the whole point of Tenure: the role persists while the people rotate, so knowledge belongs to the seat, not the person who held it. Individuals do not take the record with them when their term ends. It carries forward to whoever inherits the role.

Access is scoped to the seat a person holds, and the institution or organization owns its records, not Tenure, and not the individuals who pass through a seat. One limit worth stating plainly: an account with an institution-level membership can currently read every organization that institution stewards, so administrative access is broad by design today rather than narrowed per advisor.

We aim to support FERPA-conscious handling of education records and will work with your administration on the policies and controls that fit your institution. That is a statement of intent, not a compliance assertion: no FERPA-specific control is implemented in the product, and this page has not been reviewed by counsel. The security page lists what is and is not built.

The database and the files you upload, documents and images, are encrypted at rest. Documents are never served from a raw file URL: every download goes through a signed link that expires in ten minutes.

Beyond that, we use reasonable safeguards to protect the information in Tenure. No method of storing or transmitting data is perfectly secure, and we can’t promise absolute security, but we take the trust your organization places in us seriously and work to earn it.

You can ask us what we hold about you, ask for an export, or ask for deletion, by writing to us. Two of those are simple. Deletion needs an honest answer, because an earlier version of this page promised something the product is deliberately built to refuse.

• Your personal account details, name, email, profile, can be removed or anonymized on request. There is no self-service control for this and no automated routine behind it: we do it by hand, and assignments and audit rows that reference you are kept.
• An organization’s whole record can be exported and deleted at the end of the relationship, on the instruction of that organization’s current leadership.
• Individual entries you made cannot be erased from a seat’s history on your own say-so. That is the product working as designed: a seat carrying history refuses deletion, and an outgoing officer is moved to alumni rather than removed. If a departing treasurer could delete the budget decisions they made, the record would not survive turnover, which is the entire point of Tenure.

So: access is revoked, history is retained. If you need a specific entry corrected or removed for a legal reason, contact us and we will work with your organization’s leadership on it, but we will not quietly delete institutional history at the request of one person who is leaving. The security page states the same limit from the product’s side.

As Tenure develops, we may update this policy to reflect how the product actually works. When we make a meaningful change, we’ll update the date at the top of this page so you can see when it last changed.

Questions about privacy, or a request about your information? Email us at privacy@tenurework.com and we’ll help.