The terms, in language you should not need a lawyer to read.

When you write to us

An email is the one thing that gives us your personal data, and it gives us whatever you chose to put in it — typically a name, an address to reply to, and an institution. We use it to answer you and to carry on the conversation that follows, and for nothing else: it is not added to a mailing list, and there is no mailing list to add it to.

Correspondence is kept while it is live and for as long afterwards as an enquiry might reasonably be picked back up — the working assumption is two years from the last message. Ask and it goes sooner.

Who else sees anything

Loading a page means your browser fetching files, and three parties are asked for some of them. They receive what any web request discloses — an IP address, a browser string, the file wanted — and nothing we send them, because we send them nothing.

What leaves the server

A short, closed list, and this is all of it. Eight kinds of message go out: a visit itinerary a member of staff composes and sends, which may carry a link to the public visitor map’s page for each building the sender chooses, one link to a public page of biographies of the colleagues the sender ticks, one link to the public office contacts page naming the sections and people the sender ticks, and one more link the sender builds on the Info Pack tab of the dialog they send it from, as the Info Pack dialog builds one — to the visitor map, the biography page, the office contacts page, the links and files page or the factsheet, naming what the sender ticks there, to the factsheet’s video or presentation, or to an info pack gathering several of them — rebuilt by IRIS from what was ticked, never taken from the sender’s browser; a notice and a receipt raised when somebody submits the public request form; a weekly digest to the install’s own administrators and to any colleague an administrator has added to that one list — record-quality figures, the headline figures of six of the system’s pages (totals and averages that name nobody), where students on a joint or double degree are tracked, a count of those students, each once however many years they have on file — how many are in progress, how many have a requirement past its due date and how many requirements fall due in the coming fortnight, by direction and degree programme, counts only and never a student’s name or ID number — whether the software libraries the installation uses are up to date, and with them some names: the contacts most recently added (name, title, institution and email address; never a telephone number), for each agreement it names at the approval or signature stage, the member of staff leading it and the partner’s contact point for it (name and email address; never a telephone number), for each scheduled visit it lists in the coming fortnight the names of the institution’s own people assigned to that visit (their names only, and nobody from the other institution), and for a visit request nobody has decided yet the delegation, its country, the purpose given and the date asked for, none of the requester’s own contact details; a copy of that same digest when an administrator presses the test button on the configuration page, which goes to that administrator’s own address and to nobody else; a reminder of a scheduled visit, sent automatically where the office has switched reminders on, on the days it sets before the visit (a week before and the day before, unless it chooses otherwise — one whose morning was missed, or had passed before the visit was entered, may go on a later morning instead, at the latest the morning of the visit itself), to each of the institution’s own people linked to that visit as a contact, at their main email address, and never to anybody at the other institution — the visit’s itinerary, which names the delegation and the partner’s point of contact, under a short note, with nothing kept of it but a record that it went, which names the contact by number and holds a one-way fingerprint of the address rather than the address — and the same reminder sent as a test, which goes only to the office’s contact point or to an administrator’s own address; a reply to a visit request the office declines, only when the reviewer declining it chooses to send it from IRIS — the letter they wrote, drafted from the office’s own templates and filled in from the request, sent as they left it to the email address on that request and to no other, with a copy to the office, and with nothing kept of it on the request but when it went, to which address and from whom; and a password-reset link when a user asks for one — carrying a link and nothing else, sent only to the address already on the account and never to one typed on the form. They travel through the mail relay configured for the install, and nothing is mailed to a partner institution on a schedule. A member of staff may also copy a link to the visitor map, the biography page, the office contacts page, the links and files page or the factsheet, naming the meeting points, the people, the sections, or the groups of links and files they choose — or single links and files from those groups — or one link that gathers several of those pages into an info pack, the factsheet’s video and presentation among what it can carry, and send it from their own email or a messenger; IRIS sends nothing and saves nothing when they do.

Beyond mail there is one call that carries anything about a person, and it is worth naming precisely. Where an institution has configured captcha keys, submitting the public request form sends Google the captcha token and the IP address the submission came from. A stranger pressing Submit triggers it, not a member of staff; an institution that configures no keys never makes the call.

The calendar can also be read from outside, but only where an administrator makes links to the install’s calendar, on the configuration page, one for each person they are given to and each named for that person, who adds theirs to a calendar app — Google Calendar, Outlook or Apple Calendar — so that it can be followed from an account with no sign-in. The server sends nothing: the calendar app fetches the link on its own schedule — from its provider’s servers for Google Calendar, Outlook on the web or a subscription kept in iCloud, or from the subscriber’s own computer or phone for one kept on the device — and keeps what it reads there. A link carries every series of the calendar, or only those ticked when it was made — the visits of either direction, the calendar entries, the agreement expiries and the open visit requests of either direction — from a year back onward: institutions’ names, dates, and what each one is, and no contact name, email address or meeting link, though a title or description carries whatever staff typed in it. Making a link stops no other, and revoking one stops that one alone from its next read: a calendar subscribed to it stops updating, but keeps what it last read until the link is removed from it. Each link is kept with the name the administrator gives it — usually the name of the person it is for — who made it and when, and when a calendar app last read it, which app that was and how many times it has been read; only administrators see these, on the configuration page, and the name is never passed to the calendar app. A revoked link’s name and dates stay as a record of it, and can be erased if the person it was for asks. An administrator may also make links, the same way and one for each person, for the visits of the institution’s own people the office has chosen to highlight: such a link carries every visit one of them is linked to, past and to come and whatever its status, with what a calendar link carries of a visit and no more, in a calendar named for the office’s label for them, and it names none of those people — though whoever holds it learns which visits they are linked to. It is fetched, made and revoked as a calendar link is, and apart from them. A link of either kind made before links had names was made for the install as a whole: it keeps working until it is revoked, unnamed until an administrator names it, and a calendar link of that age carries every series. Where no link has been made, nothing is fetched.

Two more kinds of request leave the server, and neither carries record data. Each time the weekly digest is built — its test copy included — and whenever an administrator runs the same check by hand, the server asks the npm registry for the newest release of each front-end library it pins, and OSV.dev whether any pinned version carries a published security advisory. It reads a published public-holiday calendar only when an administrator imports one. Each of these requests names a library and a version, or a calendar feed, and carries no record data and nothing about any person. Nothing is sent to us.

Keeping it, and getting rid of it

IRIS does not delete on a timer, deliberately: a partnership record whose value is that it survives the staff who made it cannot also expire quietly. Retention is the institution’s policy to set and its administrators’ to apply — the records are theirs to remove, and we do not remove them on our own initiative. The same holds for people: a colleague who leaves has their account switched off rather than deleted, so every line the trail signed with their name still resolves to a person, and a contact who moves on is marked inactive rather than removed from the visits they attended.

When this changes

The effective date at the top of the page moves whenever anything here does, and the release it describes is named beside it. Corrections and clarifications take effect when they are published. Anything that materially changes what an institution has agreed to is not done by editing this page — it is raised with that institution directly, in writing, before it applies.

Asking about any of this

Everything here — a question about the terms, a data-protection request, a sub-processor list for a procurement file, a security questionnaire — goes to the same address, and is answered by the person who wrote the software.

iris@irissystem.io