What this product holds, and where it lives

Who decides what, and who we are to you

When an organization uses PortfolioPlane, that organization decides what goes into its register and how long it is kept. We store and process it on their instructions and for no purpose of our own. In the vocabulary of data protection law, the customer organization is the controller of its register content and we are its processor. If you are an employee of a customer and want your record changed or removed, your own administrator can act faster than we can, and they are the correct first stop.

For the small amount of data that is genuinely ours to decide about — the email address of someone who signs up before any organization exists, and the billing contact on a paid plan — we are the controller.

What is actually held

• Account identity. An email address, the sign-in credential itself, and a display name if one is given. Passwords are never stored by this application; authentication is handled by Supabase Auth.
• Organization membership. Which workspaces an account belongs to and what role it holds in each.
• Register content. Whatever the customer records: project and program titles and summaries, objectives, requirement statements and citations, risks, dependencies, findings and reviewer notes, capacity and financial figures, test identifiers and failure messages, environment labels and addresses, and uploaded documents. This is business content, and it contains personal data only where the customer puts a person’s name in it — an owner, an approver, an author.
• The decision trail. An append-only record of every act that changes what the register claims: what changed, when, and which signed-in person did it. The actor is taken from the authenticated session by the database rather than supplied by the client, so an entry cannot name somebody else.
• Billing details. On a paid plan, a billing contact and subscription state. Card numbers are entered on Stripe’s own page and never reach this application.
• Ordinary request data. The logs a hosting platform keeps to serve and secure a website.

Clinical, payment and personal data

A portfolio governance register does not need protected health information to do its job, and this one does not ask for any. There is no field for a member, a claim, a diagnosis or a card number, no import path that expects one, and no feature that would work better with one.

That is a design position, and the honest word for a design position is not “guarantee.” A classification is not a control. The three commitments that would turn this into something a reviewer can hold us to — a contractual prohibition acknowledged at onboarding, a named ingestion boundary, and screening at the two bulk import paths — are written and not yet built. The security page states each one and its standing. A customer should not send clinical or payment data into this product, and the terms say so.

Where it is stored

Customer data is stored by Supabase, a managed Postgres platform, in a single United States region. It is encrypted at rest by that platform, and every connection — browser to application, application to database — runs over TLS. The application itself is delivered by Netlify.

There is no data residency commitment. The data is in the United States today, and we will not contract to keep it in any particular region, because a commitment we cannot enforce against a managed platform is not a commitment. A buyer who requires residency should treat the answer as no.

Who else sees it

The full subprocessor list is published on the security page rather than assembled when someone asks. In summary: Supabase holds the database, the authentication identities and file storage; Netlify receives request metadata and serves the rendered pages; Resend receives the email address of anyone invited to a workspace; Stripe receives billing contact and payment details on a paid plan.

One subprocessor is conditional and worth stating separately. If a workspace turns on the optional voice assistant, Google Gemini receives a brief scoped by the same row-level policies the workspace uses — the workspace name and slug, selected project keys, titles and states, aggregate counts — together with the live conversation’s audio and transcriptions. When the assistant is not enabled, it receives nothing at all.

Beyond those, nothing. We do not sell personal information, do not share it with advertising networks, do not disclose it to data brokers, and do not train any model of our own on customer content.

Cookies, and what this site does not do

The only cookie this product sets is the session cookie that keeps a signed-in person signed in. It is marked Secure, restricted to same-site requests, and it exists for authentication and nothing else. There is no advertising cookie, no analytics cookie, and no cross-site tracking identifier — which is why there is no consent banner: there is nothing to consent to.

The public pages embed no third-party advertising or analytics scripts of any kind. A reader can confirm that from their own browser in about ten seconds, which is the standard every claim on this site is meant to meet.

How long it is kept, and the part that cannot be deleted

Register content is kept for as long as the customer keeps it; they can edit and delete it from inside the product. The decision trail is different, and this is the disclosure most notices in this category would leave out.

The trail refuses deletion to everybody — to the organization’s owner, to us, and to the database superuser. That is enforced in the database rather than by policy, and it is the point of the product: a governance record that a participant can selectively erase is not a governance record. The practical consequence for an individual is honest and worth stating plainly: inside a living tenancy, an entry recording that a named person accepted something on a date cannot be removed. It is retained for the life of the tenancy. Deleting a tenancy removes the tenancy and the trail with it; it does not selectively edit history inside one.

Two related things are written and not built: a certified deletion process on termination, and a full machine-readable tenant export. Until they exist, a customer’s ability to take their record with them at the end of a contract is not something we can demonstrate, and it should not be assumed.

Your choices

An employee of a customer organization should ask their own workspace administrator, who can see and change their membership and most of their record directly. For anything an administrator cannot resolve, or if you are not a member of a workspace, the contact page sets out the routes that exist. We will not ask for more information to verify a request than is needed to be sure the request is genuinely yours.

Security

The mechanism, the measured isolation figures, the scheduled proof that a tenant boundary actually refuses, and the standing gaps we have not closed are all on the security page. It opens with what we do not hold rather than closing with it, and it names what our own staff can reach. If you are assessing this product, read that page before this one.

Children

This is business software licensed to organizations for use by their staff. It is not directed at children, and we do not knowingly create accounts for them.

Changes

This notice carries an effective date and changes will move it. A change that materially alters what is held, where it is stored, or who processes it will be told to customers rather than left for them to notice — the same standard the product applies to a register that changes what it claims.