Protect sensitive academic documents while keeping metadata, citations, and discovery available to the right audience.
Authentication is only the first boundary. Every protected action must also pass institution, role and record-access checks.
Users see the workspace functions and records allowed by their role, institution and the record's access policy. Private file paths, password hashes, API secrets and verification tokens are not included in public output or personal-data downloads.
Publication, privacy, account and sensitive administrative actions are audited. The separate hash-chained security log makes silent retroactive alteration detectable when the audit-chain feature is enabled and its key/storage are protected.
Checksums and storage-integrity checks can identify a missing or changed repository file. Personal-data exports include a SHA-256 value covering the exported data object so a recipient can detect later modification.
Security depends on correct deployment: HTTPS, a strong application key, protected backups, least-privilege database credentials, patched servers, working email security and disciplined administrator access must be maintained by the party operating each component. No control can guarantee absolute prevention of every breach or misuse.
Every sensitive action should be visible, reviewable, and tied back to a record.
Original documents stay outside public folders and are served through controlled application routes.
Institution, role, subscription and oversight boundaries are checked before protected workspace actions.
View-only and approved-access sessions use controlled routes and expiring credentials instead of public file paths.
Sensitive actions are written to the operational audit log and chained security log so later alteration can be detected.
Stored document checksums support missing-file and unexpected-change detection without exposing the private file.
Restricted files require a request and authorised institution decision before release.
Downloads can be limited to open-access records or approved temporary access windows.
Cloud files use private platform storage; Campus files remain on the institution server; Connect links inherit provider controls.
Inrep Scholar manages metadata, discovery, workflow, citation, analytics, and repository presentation around the storage model your institution chooses.
| Question | InRep Connect | InRep Cloud | InRep Campus |
|---|---|---|---|
| Who stores the file? | Institution/provider | Inrep Scholar private storage | Institution |
| Who pays storage cost? | Institution | Included in plan | Institution |
| Can Inrep enforce view-only? | Limited by provider settings | Yes, through protected viewer | Yes when integrated |
| Can the link break? | Yes, tracked by link health | No external link dependency | Less likely, depends on integration |
| Best for | Fast onboarding and pilots | Protected access and analytics | Enterprise/data sovereignty |
Choose open access, metadata-only, view-only, institution-only, restricted, or embargoed access depending on policy and document sensitivity.
View repository examplesHosting, access control, backups, and data rights — the full compliance reference is at the Trust Center.
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.
