The service provides a hosted installation of the Service Provider’s Digital Repository Solution with access to their professional support services.
This enables customers to access a secure, reliable, and scalable repository service without the need for internal specialist IT software or infrastructure resources.
- The Service Provider’s Digital Repository Solution
- Service Management and Reporting
- Phone Support Desk 5*8 as standard
- Support Tracking system
- Access to the Service Provider’s Support and Professional Services Teams
- Support and Consultancy Days Included
- Access to Customisation Services
- Comprehensive Service Level Agreement
- Other Third Party Integration (Crest, CRIS)
- Combine open-source flexibility with enterprise level assurances
- Tailor the Repository to suit your institutional priorities
- Access a thriving community of users and practitioners
- A service that will grow as your institutional usage grows
- Migration from other or different repository platforms
- Automated import of content
- User Access Mechanism
- Institutional Theming
£3691 per instance per year
- Free trial available
6 1 3 1 3 3 1 1 3 9 5 0 8 9 8
University of London
|Software add-on or extension||No|
|Cloud deployment model||
|Service constraints||We operate a weekly maintenance window (Tues 07:00-09:00) where service maintenance may involve downtime. All such planned maintenance will be notified with at least five (5) business days' notice.|
|System requirements||Browser: IE9+, Opera, Safari, Firefox|
|Email or online ticketing support||Email or online ticketing|
|Support response times||
Response and resolution times vary according to severity an OOH service is available at additional cost:
P1 – Critical, Response 30 minutes, Resolution 4 hours
P2 – High, Response 1 hour, Resolution 4 hours
P3 – Medium, Response 3 hours, Resolution 2 business days
P4 – Medium/Low, Response 4 hours, Resolution 4 working days
P5 – Low (Service Request), Response 1 business day, Resolution 5 business days
|User can manage status and priority of support tickets||Yes|
|Online ticketing support accessibility||WCAG 2.1 A|
|Phone support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support||No|
|Onsite support||Yes, at extra cost|
The Research Technologies team can provide a broad range of expertise for the Customer to draw on to ensure the successful operation of their Service.
When logging a Support Case the case will be classified depending on the type of issue
• Hosting Platform Issue – Service failure due to issue with the hosting environment
• Current Service Incident – Issue regarding the platform application (i.e. non-hosting based problem)
• Advice / Consultancy
• Customisation or Request for Change
There will be annual meetings with a technical account manager available
The service includes a Support and Consultancy Allowance of included days per annum.
As Current Service Incidents and Advice Support Cases are worked, the time taken will be deducted from the current Support and Consultancy Balances.
For the purposes of calculating the Support and Consultancy Balance, a day is defined as seven (7) hours. At the end of each 12-month period, on renewal the Support and the Consultancy Balances will be reset to the annual figure. There is no ‘rollover’ of balances to subsequent years.
Customers may purchase additional Support+ service which increases the allowance provided.
|Support available to third parties||Yes|
Onboarding and offboarding
The Service can be configured to meet individual organisations’ needs. Typically, the following areas may be customised at initial implementation:
• Organisational Structure
• User Access Mechanism
• Other Third Party Integration (Crest, CRIS)
• Automated import of content
• Migration from other or different repository platforms
In addition, it can be enhanced with additional features and resources, such as additional storage or the provision of Archive or Off Site Replication services.
The Service Provider will work with the Customer to determine their specific needs and create an implementation scoping document that defines the exact requirements for Implementation. Implementation Charges will be based on this scoping document and are not part of the standard service.
|End-of-contract data extraction||
The entire source code of their Digital Repository Service at the time of termination
All Customer content stored within the Digital Repository Service
A Redacted Database dump where “Redacted” means the removal of any confidential data such as passwords.
This is made available by way of an sFTP site.
A Customer can request Exit Services from the Service Provider on Termination of the Service.
The scope and charge for these services is not included within the Service and needs to be agreed separately as part of a Professional Services Agreement.
However, subject to the purchase of the specific Exit Service the Service Provider can typically provide, to the Customer:
• The entire source code of their Digital Repository Service at the time of termination
• All Customer content stored within the Digital Repository Service
• A Redacted Database dump where “Redacted” means the removal of any confidential data such as passwords.
These items will be provided to the Customer on up to two (2) dates of his choosing with the last being no later than the Termination Date. These items will be provided via an sFTP location which the Customer will be able to access for ten (10) days after the content being added to the location. After this period, the sFTP location and access to it shall be removed and the data shall no longer be available.
Using the service
|Web browser interface||Yes|
|Application to install||No|
|Designed for use on mobile devices||Yes|
|Differences between the mobile and desktop service||The service is provided with a fully responsive UI so that all functionality is available via mobile devices|
|Description of customisation||
As well as customisation specific to their own Institution, the Customer may, at any time, propose an addition to the Product Roadmap for the Community Platform which they feel will enhance the Service for all Customers. Customisation may take one or more of the following forms:
• Addition of new or updated Third-Party Plugin
• Addition of Customer-developed Plugin
• Addition of application Patch
• Modification of functionality developed by the Service Provider
• Addition of new functionality proposed to be developed by the Service Provider
• Modification of application Core Code.
The Customer shall record all requests for Customisation via the Service Desk which will also record the status of the request.
The Service Provider will solely determine whether (or not) to incorporate a Customisation request into a future Community Platform update and these would normally be funded by the proposing Customer.
If a request for Customisation is accepted, funded, and approved, it will be made available in a future update and will be provided to all Customers.
|Independence of resources||Customers service instances have dedicated virtualised resources across multiple physical hosts which can dynamically migrate instances to alternative physical hosts where necessary to maintain performance.|
|Service usage metrics||No|
|Supplier type||Not a reseller|
|Staff security clearance||Staff screening not performed|
|Government security clearance||Up to Security Clearance (SC)|
|Knowledge of data storage and processing locations||Yes|
|Data storage and processing locations||United Kingdom|
|User control over data storage and processing locations||No|
|Datacentre security standards||Supplier-defined controls|
|Penetration testing frequency||At least once a year|
|Penetration testing approach||Another external penetration testing organisation|
|Protecting data at rest||
|Data sanitisation process||No|
|Equipment disposal approach||A third-party destruction service|
Data importing and exporting
|Data export approach||Users can extract data via industry standard APIs, built-in functions for content export and using our support services to perform custom extracts of low-level data.|
|Data export formats||CSV|
|Data import formats||CSV|
|Data protection between buyer and supplier networks||
|Data protection within supplier network||
Availability and resilience
|Guaranteed availability||The Digital Repository Service will be accessible twenty-four (24) hours a day, seven (7) days a week, with a 99.9% targeted uptime. 99.9% uptime means that for 99.9% of the time during any calendar month, the Digital Repository Service will be available. Unavailability is a condition in which the Digital Repository Service’s Primary URL cannot be accessed from a UK location. Each instance of unavailability is a Service Outage.|
|Approach to resilience||Available upon request|
|Outage reporting||We have e-mail, SMS and Voice alerts which are also available to customers, upon request.|
Identity and authentication
|User authentication needed||Yes|
|Access restrictions in management interfaces and support channels||Support channels are restricted to specific named customer contacts. Access to support via our service portal is via credentials issued by us.|
|Access restriction testing frequency||At least once a year|
|Management access authentication||Username or password|
Audit information for users
|Access to user activity audit information||Users have access to real-time audit information|
|How long user audit data is stored for||User-defined|
|Access to supplier activity audit information||Users contact the support team to get audit information|
|How long supplier audit data is stored for||Between 1 month and 6 months|
|How long system logs are stored for||Between 1 month and 6 months|
Standards and certifications
|ISO/IEC 27001 certification||No|
|ISO 28000:2007 certification||No|
|CSA STAR certification||No|
|Other security certifications||No|
|Named board-level person responsible for service security||Yes|
|Security governance certified||No|
|Security governance approach||
Responsibility for the production, maintenance and communication of this top-level policy document and all sub-policy documents lies with the University’s IT Security Manager.
This top-level policy document has been approved by the Information Technology Governance Group. Substantive changes may only be made with the further approval of this group.
Responsibilities for the approval of all sub-policy documents is delegated to the Information Security Group. Where necessary.
each of the documents constituting the Information Security Policy will be reviewed annually. It is the responsibility of the IT Security Manager to ensure that these reviews take place. I
|Information security policies and processes||
The University has a defined Information Security policy based upon industry best practice, it employs a full-time security manager whose primary function is to ensure that policies and process are followed. They are backed up by an information security board, that regularly review the policies and procedures as well as any potential breaches. There is mandatory staff training for information security which takes place during induction (over the past year all members of staff have been required to take the training and pass the exam at the end).
The information Security policy is one of a group of interlinked policies that are regularly reviewed they are :
User Account Management
System configuration and maintenance
Any individual suspecting that the security of a computer system has been, or is likely to be, breached should inform the IT Service Desk immediately.
In the event of a suspected or actual breach of information security, IT Security, with or without consultation with the relevant department, may require that any systems suspected of being compromised are made inaccessible.
Full policies & processes available on request
|Configuration and change management standard||Supplier-defined controls|
|Configuration and change management approach||
Change Management is by way of a change board Requests for change (RFC) are first reviewed by a technical expert (depending on speciality) before submission to the Change Board for approval. All non-standard changes must be approved before they are implemented all changes are reviewed by the security team for any potential security impacts before implementation. All RFCs are reviewed upon completion of the change
The University maintains a Configuration Management database (CMDB) where all configuration items (CI) are maintained and tracked through their lifetime
|Vulnerability management type||Supplier-defined controls|
|Vulnerability management approach||The University uses advanced technologies to identify and address security weaknesses in web-orientated servers, applications and activities. The systems are also actively monitored for any potential security events and other vulnerabilities. In particular, all system access events are monitored and mailed on a daily basis to the sys-admin lists for assessment and action. The University service platform is based on hardened, Linux and Microsoft systems which are automatically and non-destructively monitored daily by ULCC for susceptibility to known attacks. Operating System patches and updates are continuously monitored for security vulnerabilities. They are tested and installed as appropriate to ensure protection.|
|Protective monitoring type||Supplier-defined controls|
|Protective monitoring approach||
We run a Network Intrusion Detection System - SNORT at the entry point to our network.
We have full Unified Threat Management capability on our main firewall equipment.
Our Linux systems use a range of Host Intrusion Detection Systems such as tripwire
All new web facing systems are put through our standard Penetration testing process.
Response is measured against the issue identified and whether it is a confirmed compromise or not. We secure the system if an attack is currently underway. To do this we isolate the system from the internet to prevent further damaged/data loss.
15 minutes initial response
|Incident management type||Supplier-defined controls|
|Incident management approach||
ITIL v3 is the common standard for incident management used by the University.
The reporting of an incident can be either by portal, email or telephone to the service desk, any of these methods will generate a unique incident identifier, initial triage will categorise and prioritise the incident, trigerring the appropriate SLA. The initial diagnosis will identify the appropriate team to respond and resolve the incident in line with the SLA. Typically resolution reports are provided within the incident record by the resolving engineer.
P1 incidents are followed up by a formal report through the senior management team.
|Approach to secure software development best practice||Supplier-defined process|
Public sector networks
|Connection to public sector networks||Yes|
|Connected networks||Joint Academic Network (JANET)|
|Price||£3691 per instance per year|
|Discount for educational organisations||No|
|Free trial available||Yes|
|Description of free trial||There is a community version of the software available as a free download|