Privacy Policy
What personal information is collected and how it is used.
Read the policy →What Inrep Scholar actually implements, what is documented in your institution's agreement, and how to request a copy of any policy or exercise a data right. Responsibility for storage, backups, and infrastructure changes by deployment tier — see the full responsibility breakdown for InRep Connect, Cloud, and Campus.
Documents already published are linked directly; documents issued per institution are available on request through onboarding or the form below.
What personal information is collected and how it is used.
Read the policy →WCAG target, supported accessibility practices, known limitations, and barrier reporting.
Read the policy →The terms governing use of the platform.
Read the policy →Nigeria Data Protection Act 2023 (successor to NDPR) data subject rights notice.
Read the policy →How cookies and similar technologies are used.
Read the policy →How to request review of repository content.
Read the policy →Institution and Inrep Scholar responsibilities, subprocessors, and retention. Issued per institution as part of onboarding.
Request this document →Controls covering access, encryption in transit, and administrative permissions.
Request this document →Backup frequency, retention, and restoration testing for the subscribed plan.
Request this document →How service interruptions and infrastructure failure are handled.
Request this document →Infrastructure providers and other subprocessors reviewed for institutional data.
Request this document →The most common questions institutions ask during procurement and data protection review.
Hosted Inrep Scholar (InRep Connect / InRep Cloud): Institutional data, user accounts, repository metadata and uploaded research files (for Cloud) are stored on Inrep Scholar's hosting infrastructure. The specific hosting region and data-location arrangements are documented in the institution's service agreement and Data Processing Agreement.
InRep Campus: Campus is installed on infrastructure controlled or selected by the subscribing institution. The institution determines the hosting provider, server location, and backup arrangement, and is responsible for meeting its own data-residency requirements.
Inrep Scholar uses role-based access control — a user can only reach the functions and records permitted for their assigned role and institution. Institution-level authorization is validated on the server for every protected request; a user from one university cannot reach another university's private records by changing the university slug, a URL, a form value, or a record ID. Restricted, embargoed, and institution-only records additionally require an approved access request before the file itself is reachable.
The hosted edition (InRep Connect / InRep Cloud) runs on managed, internet-accessible server infrastructure. InRep Campus can be deployed on an institution's own selected cloud account, private server, or approved hosting environment — the institution remains responsible for infrastructure-level controls in any environment it manages itself.
Inrep Scholar applies layered security controls including encrypted HTTPS connections, secure password hashing, role-based authorization, tenant isolation, server-side input validation, protected document access, and controlled administrative permissions.
Additional controls already in place include: time-limited document access links, active-account validation, PDF watermarking on protected views, file-type and upload validation, restricted and embargoed publication access, supervisor and librarian approval gates before publication, secure session handling, rate limiting on authentication and one-time-code operations, and audit logging for sensitive administrative actions.
We do not claim ISO certification, independent penetration testing, encryption at rest, or Cyber Essentials certification unless that evidence has been issued and can be supplied on request.
Inrep Scholar maintains scheduled backups of repository data and uploaded files. Backup frequency, retention periods, and recovery arrangements are defined in the applicable service plan and institutional agreement, and backup restoration procedures are periodically tested. For InRep Campus, the institution's own backup schedule applies to its self-hosted installation.
Inrep Scholar maintains documented procedures for responding to infrastructure failure, data corruption, security incidents, and extended service interruption. The process covers service restoration, backup recovery, incident escalation, institutional communication, and post-incident review. Specific recovery-time and recovery-point targets are set out in the institutional agreement rather than published generally, since they depend on the subscribed plan.
Data location and any international-transfer arrangement depend on the hosting configuration selected for the institution; any cross-border processing or storage arrangement is disclosed in the applicable service agreement and Data Processing Agreement. For InRep Campus, the institution controls the hosting location and is responsible for selecting infrastructure that satisfies its own data-residency requirements.
Yes. A Data Processing Agreement can form part of institutional onboarding and contracting. It sets out the responsibilities of the institution and Inrep Scholar, permitted processing activities, confidentiality and security obligations, subprocessors, incident handling, data retention, and contract-termination procedures. Request one through the contact form or during onboarding.
Infrastructure providers and other subprocessors are reviewed before they are authorised to process institutional data, covering security controls, service availability, data location, backup arrangements, incident reporting, and contractual safeguards. A current subprocessor list is available on request as part of the Data Processing Agreement package.
Inrep Scholar supports the controlled review, correction, export, and deletion of eligible personal account information, subject to institutional responsibilities, applicable law, and legitimate academic-record or repository-retention requirements. Published research records receive separate handling from personal account data — deleting a user account does not automatically remove an institution's legitimate scholarly record. Anyone can submit an access, correction, export, or deletion request through the Trust Center.
User account and operational information is retained only for as long as needed to provide the service, meet contractual obligations, and satisfy applicable institutional policy. Published research, repository metadata, and institutional records may be retained for long-term scholarly preservation according to the institution's own repository policy — retention periods for account data are configurable per institution rather than fixed platform-wide.
Published or embargoed repository content is retained as part of the institution's scholarly archive; long-term preservation of published research is a core purpose of the platform, not an optional extra. Archived records remain governed by their access classification, embargo conditions, and institutional repository policy.
Eligible records move through a controlled deletion lifecycle: an item is deactivated, moved to a recycle bin, and only permanently purged after explicit, typed confirmation from an authorised administrator — restore remains possible until that final step. Permanent deletion removes the record from the active database and stored files, and is recorded in the audit trail; removal from any retained backups follows the backup retention period in the applicable agreement.
Hosted Inrep Scholar: Before termination, the institution can request an export of its repository metadata, account records, and eligible uploaded files. After the agreed export and transition period, institutional data is deleted or anonymised according to the contract, retention policy, and applicable legal obligations.
InRep Campus: Data remains on the institution-controlled installation at all times. Central indexing, updates, support, and subscription-dependent services may be disabled after termination, but the institution's own server and files are never touched by Inrep Scholar.
No. Research documents, submission information, and private institutional records are not used for unrelated direct marketing. Marketing communications are sent only through authorised channels, with unsubscribe controls.
Standard accounts use password-based login with secure password hashing. Administrator and InRep Campus admin accounts additionally require a one-time email code at login. Single sign-on is available for institutions that configure it — Microsoft sign-in is supported directly, and SAML/OAuth identity providers and LDAP directories can be connected for institutions that already run one. Multi-factor authentication beyond the email one-time code (such as an authenticator app) is not currently offered as a standard option.
An institution administrator can disable a departing user's account at any time, which immediately removes their ability to sign in. Records they submitted or reviewed remain part of the institution's scholarly archive and audit trail — disabling an account does not delete the institutional record of work they were involved in, consistent with how published research is retained under the institution's own repository policy.
For hosted Inrep Scholar (InRep Connect / InRep Cloud), the institution is generally the data controller for its own students', staff, and researchers' personal information, and Inrep Scholar acts as processor under the terms set out in the Data Processing Agreement. For InRep Campus, the institution controls the infrastructure and application directly, so it holds both roles for data on its own installation. The precise allocation for a given institution is confirmed in its own agreement rather than fixed generally, since it can depend on local regulatory requirements.
Report a suspected security issue, vulnerability, or incident through the contact form, marking it as a support/security matter so it is routed and prioritised correctly. Include enough detail to reproduce or verify the issue; do not include real personal data, credentials, or sensitive record content in the report itself.
Use these forms to request review of repository content, or to access, correct, export, restrict, anonymize, or delete eligible personal information. Both are logged and routed to an administrator for follow-up by email. Accessibility barriers have a dedicated form on the Accessibility Statement.
Access, correction, export, or deletion of your personal account information.
Copyright concerns, confidential information, incorrect authorship, or a suspected policy violation.