Your data
The portal exists to run an internship from application to sign-off, so it keeps a record of that internship and of the people in it. This page describes that record as the code actually implements it.
One thing to know first: most of what the portal exports and reports is keyed to a portal reference rather than to your name. If you are a student that is your program ID, like SSP-123456. Everyone else — mentors, managers, administrators, developers — has no program ID, so the portal generates a staff reference instead, shaped so that it can never be mistaken for a student’s. The rest of this page says “your portal reference” and means whichever of the two you have. It is a real protection and it is used throughout, but it does not make the record anonymous — the reference still leads back to you.
Grouped roughly the way your own download groups it. The download has one sheet per kind of record; the groups below merge and rename some of those sheets so the list reads as prose, so treat this as a description rather than a sheet index.
You, as a Person
Your name, work email and username. If you supply them: a personal email address, phone number, LinkedIn address and profile photograph. Your university, degree type, major and expected graduation. Your pay rate, organization and office location. Your region and country, your role or roles, your notification preferences, your interface language, your program ID, and which version of the privacy notice you were shown and when. Where password sign-in exists at all, a hashed password — never a readable one, and it is on a short list of fields that never leave the database, including in your own download.
Your Application to the Program
Name, email, chosen username, a password hash, the decision and who made it. This record exists before your account does, and is matched to you by email or username.
Your Internship
The placement, its dates, its region and country, its supervisors, the outcome, the name of the administrator who recorded that outcome, and two pieces of free text: the written reasoning behind the outcome, and feedback on your goals.
Your Goals
Each goal’s name, target, action steps, resources and how success is measured.
Your Evaluations
Midterm and final ratings on a four-level scale, your mentor’s comments, your own comments, per-target comments, and — if the below-expectations advisory fired — whatever you wrote in response.
Your Reflections
Your description of your work, new skills, challenges, the most rewarding part, collaboration, progress, and reflections on each goal.
Your Sign-offs
Who signed and when, HR comments, and up to four handwritten signature images — yours, your mentor’s, your manager’s and HR’s — stored as image data.
Your Learning Hours
Each entry with its description and who approved it.
Your Feedback Survey Answers
Your answers to the midterm and final surveys.
Files You Uploaded
Filename, type, size and the contents of the file. Where file storage is configured, the storage path contains your account id.
Documents You Were Asked For
What was requested, any note attached to the request, and the file that answered it.
Who Supervised You
Each supervision stint, when it began and ended, and a free-text reason for every change.
Requests You Made
Requests to change supervisor or role: who asked for what, the free-text note or reason, and who decided.
Groups You Are In
Which named team, who added or removed you and when, and a free-text note. A team is a label for organising people — see “Teams grant nothing” below.
Messages
Mail threads and their subjects, who is on them, the message text, the author’s name, and who was mentioned.
Notifications
The title and body of every in-app notification sent to you.
Emails
The recipient address, subject and complete text of every email the portal generated for you — whether or not it was actually sent.
The Audit Trail
Who did what and when: the actor’s name, the action, which record it touched, and a one-line summary. Many of those summaries name a person.
Problem Reports
What happened, what was expected, how it was resolved, the reporter’s name, the browser and device identification string, an optional screenshot, and sometimes the person the report is about.
Who Wrote the Program Content
These records each keep the name of the staff member who created, changed or published them, and keep it indefinitely: Feedback question sets, Teams, Custom deadlines, Feature flags, Resource links, Link allowlist, Privacy notices and Retention policies. Nothing about students. The list is generated from the same registry the download and the erasure walk, so a new kind of program content cannot quietly appear here without appearing here.
Two things kept outside the database
- A signed “view as” ticket in a cookie, carrying an administrator’s id and the id and name of the person they are viewing.
- A signed token in a link, which lets a first-time sign-in send their own approval request to an administrator before any account exists.
This installation has no external file storage configured, so the contents of files you upload are kept inside the database with everything else rather than outside it.
5 kinds of record hold no personal data at all and are named here only so the list is complete: Program terms, Site settings, Page copy, Organization list and University list. Both the count and the names are read from that same registry rather than typed out.
You
Your own record on your own screens, a self-serve copy of all of it from your profile, and — if the below-expectations advisory fired — that advisory, with the ability to attach your own comment to it.
Your Mentors and Managers
A supervisor can read your internship record while they are its mentor or manager, or hold a supervision stint on it that has not ended. A supervisor who rotated off loses that access: ended stints are ignored when the check runs. A manager can read and write the same things a mentor can for their own students, and two things a mentor cannot: request a document from one of their students, and send them a notification. Beyond their own students a manager reaches the program-wide progress and reports screens, which are read-only, and the shared goal-template library, which they may also edit. A manager cannot assign or change supervisors, reassign a mentor, or change what an internship is required to complete — those are administrator actions.
Administrators
An administrator is either global, narrowed to one region, or narrowed to a named set of countries within a region. A narrowed administrator is filtered when a list is loaded and re-checked whenever a single record is opened by its address, so there is no way in through a direct link. They cannot open, export, erase or “view as” anyone outside their area — the check is made against the record’s own region and country, never against the administrator’s. They see only part of the audit trail. And the narrowing fails closed in three ways: a region-scoped account with no region set matches nothing rather than everything, a country-narrowed account does not match a record with no country of its own, and an account whose reach cannot be worked out is treated as the narrowest rather than the widest.
Developers
A tier above administrator, holding everything an administrator holds and never narrowed to a region.
Problem Reports
Any administrator can read the problem-report queue inside their own area, and a global administrator can read all of it — including the reporter’s name, the browser and device identification string and any screenshot. Only a developer can change a report’s status. The queue is reachable by a plain administrator on purpose: the same queue carries account escalations they raise themselves, and someone who cannot see whether theirs was actioned simply files it again.
Administrators, on Each Other
An administrator cannot export, erase, block, “view as” or change the role of a fellow administrator or a developer — taking a full copy of a colleague’s record is an extraction, not a subject-access request. A developer can block, unblock, reset a password, change a role, set the reach of and “view as” an administrator, and can also export or erase one: an administrator has the same right to a copy of their own record, and to have it erased, as anybody else, and that request has to be able to land on somebody. No developer can do any of this to a fellow developer, so two developers can never lock each other out or erase one another.
“View As”
An administrator or developer can browse the portal as a student, mentor or manager inside their area. An administrator is refused another administrator; a developer is not, because repairing an account sometimes means seeing what it sees. It refuses anyone outside their area, is recorded in the audit trail, and runs on a signed cookie that stops working after four hours.
Teams Grant Nothing
Being in a team never changes who can see or do what. A team’s member list is filtered through the reach the viewer already had, so it is always a subset of the people they could already see — that part is enforced in the code that builds the list. On top of it, a test scans the source and fails the build if the team records turn up in a new place that decides who can see whom. That scan is a guard rather than a proof: it reads text, so a helper or a re-export could step around it, and the list of files it permits has grown twice with a written reason each time.
Getting a full copy of one person’s data
Only that person, or an administrator or developer whose area covers them and whose target is not a fellow administrator. It is limited to 10 exports per account every 10 minutes, and every export is written to the audit trail under the portal reference.
This page cannot tell you which named people can currently see your record. That is worked out live from who holds which role and which countries they cover, and any sentence written here would go out of date the next time somebody changed job. An administrator can see the current answer inside the portal.
A cleanup is scheduled to run once a day. A period can be set for the whole program, for a region, or for a single country — the most specific one wins. A region or country can be given its own period, longer or shorter than the program-wide one, so the table below is the starting point, not a ceiling for your country. Who may change one is worth stating exactly: only a developer — the tier above administrator — can set, change or remove a period, or force a cleanup by hand. An administrator, global or narrowed, can read the periods that apply to their own area and nothing more. The built-in defaults, and what the cleanup does with each:
| What | Kept for | Then |
|---|---|---|
| Audit log | 2,555 days (about 7 years) | Deleted. |
| Email log | 90 days | Deleted. |
| Notifications | 180 days, and only the newest 500 per person | Deleted. |
| Mail and discussion messages | 365 days (about 1 year) | Deleted. |
| Declined / withdrawn applications | 60 days | Deleted. |
| Performance records | 2,190 days (about 6 years) | Nothing is changed today — the daily job only records what it would have done. |
- Performance records are the exception. Today the cleanup does not touch them at all: it writes down what it would have done and stops there. Its configured action is to replace the identifying parts with your program ID, never to delete — the program record is the reason the system exists.
- A region’s period follows the person a record is about, never whoever wrote it. An audit entry and a discussion message carry only who acted or who typed — supervision crosses borders here, so bucketing by the writer deleted the wrong records in both directions. Both are placed instead by what they point at: the internship, or the account. An entry that points at neither — a note about a whole conversation, a nightly job’s summary — keeps the period set for the whole program, which is always the longest one, because a guess about whose record it is would be worse than not narrowing at all.
- 8 kinds of audit entry never age out, so “seven years” is not true of every one. Both the count and the breakdown are read from the list the cleanup itself consults, so nothing can be added to it without being described here:
- 4 are the evidence that a request was answered — the record of the cleanup itself, of erasures, of data exports, and of privacy-notice acknowledgements.
- 3 are not really logs at all: they are the counters and clocks the system reads back to avoid repeating itself.
- 1 is a record of a change to what a group of students is required to complete, which somebody may have to explain years later.
- Never aged out: program content and who wrote it — deadlines, goal templates, learning resources, feature switches, retention settings, survey question sets, and privacy notices, which have to stay readable for everyone who ever acknowledged one.
- Kept as long as the account exists, with no clock of their own: the account itself, uploaded files, supervision history, team membership, document requests, supervisor and role-change requests, and problem reports. These change only when someone is erased.
- Two honest notes. Only declined applications are ever cleaned up; approved and pending ones are never aged out. And there is a surge guard: when the nightly run finds it would remove more than 5,000 records in a single category, it skips that category and records the refusal loudly. The other categories in the same run are unaffected, so the run as a whole is not cancelled. A developer can still force the deletion by running the cleanup by hand, behind a confirmation; that run proceeds and the surge is recorded either way.
A copy — you can do this yourself
Sign in and open Profile → Download my data. You get a spreadsheet with one sheet per category, built by walking the same list of records that erasure walks — a new kind of record added to the system without an entry on that list fails the build, which is why the download can be expected to stay complete. Adding ?format=json gives the same content in a machine-readable form.
Correction
Through the ordinary profile and settings screens.
Erasure — this one goes through a person
There is no button for erasing yourself. An administrator runs it; they must be inside your area, cannot erase themselves or a fellow administrator, and have to type your portal reference to confirm. Ask your program administrator.
Objection
The portal has no objection switch, queue or screen, and holds no record that one was made. If you want to raise one, it is handled by people rather than by this software — contact your program administrator.
What the download deliberately leaves out, and says so on its own cover sheet
- Signature images. The sheet reports them as present or not captured instead, because the same record carries other people’s signatures.
- The contents of uploaded files. They are listed by name, type and size, and linked to instead.
- The password hash.
- Anything past the newest 5,000 rows on any one sheet — named and counted rather than quietly dropped. A single value longer than 32,000 characters is shortened and says so in the cell.
The audit sheet contains actions you performed as well as records about you. That is deliberate, and it is flagged on the cover sheet, because those descriptions can name other people.
What an erasure actually does
- Your account is never deleted. Your name becomes your portal reference; email, username and password become unusable placeholders on a domain that cannot receive mail; personal email, phone, LinkedIn, photograph, university, degree, major, graduation date, pay rate, organization, office location and notification preferences are cleared; the account is blocked and marked as erased. The id, the program ID if you have one, region, country, role and creation date stay, so the record still makes sense.
- Deleted outright: notifications you received, copies of emails sent to you, mail threads you started along with their participants and messages, messages you wrote, uploaded files (the stored contents as well as the record of them), your application, document requests, supervisor requests and role-change requests.
- Kept under your portal reference: the internship record, goals, evaluations, reflections, learning hours and survey answers — this is the program record. The sign-off record survives too, but all four signature images on your own forms are removed, and your own signature is removed from every form you signed as a mentor or manager, including for stints that have ended.
- Kept but closed: supervision history and team membership survive, because a finished internship still has to be able to say who supervised it. Their free-text reason or note is dropped, and anything still open is closed, so an erased account is never left as somebody’s live supervisor.
- The audit trail survives with the account id removed and the name replaced by the portal reference.
- Text the portal composed itself is handled. Audit summaries, notification titles and bodies, and email subjects and bodies get an exact replacement of the stored name with the portal reference — including on records belonging to other people. No guessing is involved: it is a literal match on the name as stored.
- The record of the erasure is itself keyed to the portal reference, so the erasure can be proved without re-identifying the person.
These are things the system genuinely cannot do. They are stated here rather than left out because a page that only described the good parts would not be worth reading.
- Free text that people wrote is not searched for names. If a supervisor typed a student’s name into an evaluation comment, a reflection, or a message somebody else wrote, that text survives an erasure. Scrubbing names out of prose is unreliable, and doing it badly would give false assurance.
- An HR signature image can survive on other people’s forms. The system records that HR signed and when, but not which administrator signed, so there is no field that could be used to find and clear it.
- Deleting stored file contents cannot be made all-or-nothing. If one file fails to delete, the failure is counted, listed individually in the record of the erasure, and shown to the administrator — because by that point the database entries pointing at those files are already gone.
- An already-issued sign-in session cannot be pulled back. Sessions are signed tokens with a seven-day life and no entry in the database, so nothing can revoke one that has already been handed out. Instead, who you are is re-read from the live account on every request, and the export routes refuse a session belonging to a blocked or erased account.
- This page describes the application only. Backups are not modelled anywhere in the code, so nothing here should be read as a promise that a deletion has reached every copy that exists.