Privacy policy

Everything below depends on which of two positions AdmiCate Limited is in, and they are not the same position.

For your own account we are the controller: we decide what is held about your organisation and your staff, because we have to in order to run and bill the service.

For the records inside your workspace — applicants, students, agents, the people at the institutions you work with — you are the controller and we are the processor. We hold that data on your instructions, we do not decide what goes in it, and we do not use it for our own purposes.

One practical consequence: if a student asks us directly to erase their file, we cannot act on it. We pass the request to the workspace that holds the record, because that is the organisation with the authority to answer it.

As controller, and no more than is needed to operate the account:

• The workspace: its name, the kind of organisation you told us you are, and the hostname it answers on.
• The people who sign in: name, email address, role, and the times and addresses of their sign-ins.
• Billing records: subscriptions, the modules switched on, meter readings, invoices, payments and credit notes.
• Correspondence: what you send us, and what we send back.

Card details are handled by the payment provider that takes them and are not stored in the platform. We keep the result of a payment, not the instrument.

As processor, whatever you put there. In practice that is enquiry and application records, the documents attached to them, messages exchanged with applicants and agents, and the files your staff upload.

We access it in three situations only: to run the service, to act on a support request you have made, and where the law requires us to. Access by our staff is limited to the people who need it for those purposes.

We do not sell it, we do not mine it for our own analysis, and we do not train models on it.

Records carry the identity of their workspace in the data layer, and queries are scoped there rather than in each screen — so a report written next year with a clause missing returns nothing extra, because there is nothing extra to return.

Each workspace answers on its own hostname and its session cookies are scoped to that host alone, which is what stops a shared browser becoming a shared session. A custom domain has to prove ownership with a DNS record before it resolves at all.

Your data tier decides how much of our shared catalogue comes with you. The catalogue is reference data — institutions, programs, intakes — and never another workspace’s people.

For account and billing data: because we need it to perform the contract with you, and because tax and accounting law requires us to keep invoices for a defined period.

For sign-in and security records: our legitimate interest in keeping the platform secure and being able to reconstruct what happened after an incident.

For the contents of your workspace: your instructions. Our processing of it is governed by the agreement between us, not by a basis we have chosen for ourselves.

The public site sets no advertising cookies and runs no cross-site tracking. What it does use:

• A session cookie and a request-forgery token, scoped to the host you are on. Without these you cannot sign in.
• Your colour theme, stored in your browser’s own local storage and never sent to us.
• Animation libraries fetched from the public CDN cdnjs.cloudflare.com when a page has an animation on it, which means that provider sees the request. The pages are complete and readable if it is blocked.

We use sub-processors for hosting, email delivery, and payment where a card is taken. Each is bound by terms no weaker than these, and the current list is available on request.

We will tell you before adding a sub-processor that handles workspace data, so you have the chance to object.

Ask privacy@admicate.com for the sub-processor list and the hosting locations. Both change, and a list printed into a page is a list that goes stale.

While your workspace is in service, for as long as you keep it. After access ends, a workspace is held for 90 days rather than deleted immediately — a closed account should be recoverable, and its name should not be handed to a stranger while your old links still point at it.

Before anything is purged you are warned 60 days ahead, and an export is generated and delivered 7 days ahead. A purge refuses to run until that export has been delivered, with the person who authorised it recorded against it.

Invoices and the ledger entries behind them outlive the workspace, because we are required to keep them.

Over the data we hold about your organisation you can ask for a copy, a correction, deletion where we are not required to keep it, a machine-readable export, or that we stop a particular use. Write to us and we will answer within one month.

Over the data inside a workspace, the request goes to the organisation that runs it. If that organisation is you, the export and deletion tools are in your own panel and you do not need to ask us at all.

If you think we have handled something badly, tell us first — but you are entitled to complain to your data protection authority without doing so.

Data is encrypted in transit. Access to production is limited and recorded. Isolation between workspaces is checked by an audit that walks every table and every model and fails the build when one is unaccounted for.

No platform can promise this never goes wrong. What we will do is tell you: if a breach affects the data in your workspace we will notify you without undue delay, with what we know, what we do not yet know, and what we are doing about it.

When the wording changes the date at the top changes with it. For a change that materially affects how workspace data is handled we will tell the account contacts directly rather than relying on you to re-read the page.

AdmiCate Limited, Dhaka, Bangladesh.

Data protection questions: privacy@admicate.com.