Privacy Policy

Who We Are

Assessor.io is operated by ChangeAgents AEC Pty Ltd, a company incorporated in Australia. Its registered office is ChangeAgents AEC Pty Ltd, Hampton Park VIC 3976, Melbourne, Australia. “We” and “us” in this policy mean that company.

The product is called Assessor.io. While the platform is in beta it is reached at assessor.bimexcellence.org; at launch it is served from assessor.io, replacing the earlier application published there. Both addresses reach the same platform, and this policy applies whichever one you arrived through.

Who This Policy Covers

This policy covers the Assessor.io assessment platform: the account workspace used by organisations, the campaign and assessment tools their administrators operate, and the assessment surfaces that participants and anonymous respondents use.

Where an organisation runs a campaign on the platform, that organisation decides what is asked, of whom, and why. Assessor.io provides the platform and processes the resulting data to operate it. For platform-level data — your sign-in identity, your account membership, the audit trail of account actions and the operational records listed below — we decide how and why that data is processed.

Your Organisation’s Terms and This Policy

Each account provides and maintains its own privacy statement and usage rules for the programme it runs. That text is shown to you where you join a campaign or answer an assessment, and it governs what that organisation does with your answers. This policy governs the platform underneath it. The two are accepted together, in the terms the account’s own notice states:

These terms are provided and updated by Account and must be accepted in conjunction with the Assessor.io overall Privacy Policy / Terms of Use. Acceptance of one is an acceptance of both.

If the account’s text and this policy differ on something the account controls — what it asks, why, and what it does with the result — the account’s text governs. If they differ on how the platform itself works, this policy governs.

Information We Collect

• Identity. Sign-in is handled by BIMei CID, the BIMei group identity service. Assessor.io receives your CID user identifier, your email address, your display name and avatar, and the organisations and application entitlements CID reports for you. Assessor.io never sees your password.
• Account and workspace data. Account settings, branding, members, roles and permission assignments, invitations, labels, templates and campaign configuration.
• Participation records. Participant rows created by an administrator or by a person joining a campaign, including name, email address, organisation and any metadata the campaign collects, plus invitation and reminder history.
• Assessment responses. Answers, drafts, progress, submission timestamps, auditor notes and review decisions, and the scores and reports derived from them.
• Contact enquiries. The name, email address, organisation and message submitted through the contact form on this site.
• Operational records. Activity and audit logs of account actions, email delivery records including bounces and complaints, and server logs. Rate limiting stores a hashed key rather than a raw address.

How We Use Information

Data is used to authenticate users, authorise account-scoped actions, run campaigns and assessments, send the transactional email a campaign depends on, produce reports and exports for the organisation that commissioned the work, and keep an audit trail of who did what. We do not sell personal information, and we do not use it for advertising.

Where We Use a Language Model

Three features send text to a large language model. The model is Google Gemini, and Google is the provider that processes that text on our behalf:

• Question drafting in the builder. An administrator writing an assessment can ask for a draft question from a statement they supply. What is sent is the statement they typed.
• The knowledge base console. An administrator can ask for drafted content there. What is sent is the prompt they wrote.
• Registration triage. When an administrator runs triage on a registration, the answers that registrant submitted — including anything they wrote about themselves in their own words — are sent to the model so it can suggest a decision. The suggestion is a suggestion: a person makes the decision. This feature is switched on for the beta.

No model is trained on your data. The text is sent to produce that one answer and for no other purpose, and it is not used to improve, tune or train any model.

Where Data Is Processed

• Application and database. Google Cloud — Cloud Run and Cloud SQL — in the northamerica-northeast1 region (Montréal, Canada). Uploaded files, held in Google Cloud Storage, and database backups are kept in the same region.
• Connections. Requests reach the application through Google’s global load balancer, which accepts your encrypted connection at the Google network location nearest to you and passes it on to Montréal.
• Identity. BIMei CID holds the account of record, including your password and any second factor.
• Outbound email. Amazon Simple Email Service, configured for the ca-central-1 region (Canada). Recipient addresses, message subjects and message bodies pass through it, and delivery, bounce and complaint events come back the same way.
• Language model. The features described under “Where We Use a Language Model” call Google Gemini through Google’s global endpoint, which is not tied to one region.

Since 25 September 2026 production has run under Canadian data residency: the database, uploaded files, backups and outbound email are all hosted in Canada.

Cookies and Local Storage

Assessor.io sets no advertising cookies and runs no third-party analytics or tracking. The only cookies it sets are these:

• cid_at — the CID access token for your signed-in session. Set only after you sign in, readable only by the server, and short lived (about an hour).
• cid_rt — the CID refresh token that keeps that session alive. Readable only by the server and capped at eight hours.
• cid_sess_start — a signed record of when the session began, which is what enforces the eight-hour cap.
• cid_pkce_verifier, cid_oauth_state, cid_next — short-lived values used only to complete a single sign-in and return you to the page you asked for.
• asr_lang — the interface language you last chose. It holds a language tag and nothing else, lasts a year, and is never used to make an access decision.

Your light or dark theme choice is kept in your browser’s local storage, not in a cookie, and is never sent to the server. Anonymous assessment sessions set no cookies at all: the access code you are given travels in a request header for as long as the page is open.

You will not be shown a cookie banner, because there is nothing here to consent to. Every cookie above is strictly necessary to deliver the page you asked for, or is a first-party record of a preference you chose yourself; none of them profiles you, follows you to another site, or is shared with anyone. The site loads no third-party script and no third-party font. If analytics is ever added, this section changes and so does the way we ask.

Retention and Deletion

A campaign that collects anonymous responses can set how long it keeps them. That single period is also the lifetime of the access code the respondent is given, and it is stated to the respondent at the moment the code is issued. A scheduled sweep permanently deletes anonymous responses past that date. Campaigns that set no period are never swept: nothing is deleted on a timer nobody chose.

Everything else follows the agreement with the account that commissioned the work. Data is kept for as long as that account is active, and is deleted when the account asks for it to be deleted or when the account closes — on closure the Terms of Use give 30 days to export before deletion. We publish no separate retention timetable and run no clock of our own over identified data: an account’s own terms set anything more specific for the programme it runs.

Your Choices and Rights

If you answered an assessment anonymously, the access code shown when you finished is the only key to that response. Visit the assessment’s My data page and enter the code to download a copy of your answers or to erase them. Erasure is permanent and immediate; we cannot recover an erased response, and we cannot identify it for you without the code.

If you are a named participant or an account member, your profile and communication preferences are editable in the app, your name and avatar are managed in your BIMei account, and requests to access, correct, export or delete your data should go to the organisation whose campaign you are taking part in. You can also reach us directly.

Privacy requests and questions go to bsuccar@changeagents.com.au, or through the contact form on this site. We respond within 30 days.

If you are not satisfied with our answer, you can complain to the Office of the Australian Information Commissioner (OAIC), the privacy regulator for Australia. If you live somewhere else, you may instead complain to the data protection authority for your own country.

Security

Access to account data is restricted by role and by tenancy: every request is checked against the permissions held for that account, and account actions are recorded in an audit log. Session tokens are held in cookies your browser’s scripts cannot read. Join passcodes and anonymous access codes are hashed before they are stored, so a copy of the database does not yield them. Traffic is served over TLS, and the database connection is encrypted in production.

Changes and Contact

Material changes to this policy are published on this page with a new date and a new version, shown below, so that an acceptance recorded against one version can be told apart from an acceptance recorded against another. This policy, and any dispute about it, is read under the law of New South Wales, Australia. Questions can be sent to bsuccar@changeagents.com.au or through the contact form on this site.