______________________________________________________________________________________________ _ 12 February 2020 ISC Operations Committee Page 1 of 4

ISC OPERATIONS COMMITTEE

There will be a meeting of the ISC Operations Committee at 10:00 on Wednesday 12 February 2020, in the Huntingdon Room, Roger Needham Building. Videoconferencing facilities are available.

A G E N D A

UNRESERVED BUSINESS Paper

A – Preliminary Business

Introduction and Welcome

A1 Declarations of Interest

A2. Minutes OC/113/20

The Committee is asked to approve the Minutes of the meeting held on 29 October 2019.

A3. Membership and Terms of Reference

Note: The ISC is considering its own Terms of Reference and the governance of the IT Portfolios.

The vacancy in class h (Senior IT Managers) will be sustained pending the outcome of the wider-reaching decisions. Item C3 on the agenda includes details of the proposed amendments to the governance of IT Portfolios.

A3. Matters Arising

Matters arising not covered elsewhere on the agenda:

a) Data security levels (raised in previous discussion of Institutional File Storage): there has been no reportable progress on the definition of data security levels but some clarification has been provided on the UIS help and support website. (See also item G2)

b) School representation on ISC sub-committees: the ISC will consider the governance of IT Portfolios at its meeting on 5 March 2020 (minute C2c October 2019 refers). See also item C3.

c) Roadmaps for improvements to existing services will be brought to the Committee at an appropriate point (minute B1 October 2019 refers)

d) Discussion on what information the Committee would like to receive from the Service Management Office (minute B1a October 2019 refers) is pending; item C1 is related.

e) School Representatives had been asked to ratify the mapping of School Priorities and IT Portfolio activities (minute C1a October 2019 refers)

f) The standardised request form for new work (minute C1a, October 2019 refers) is available on the Portfolios SharePoint site and a copy has been loaded to the Committee’s meeting page.

______________________________________________________________________________________________ _ 12 February 2020 ISC Operations Committee Page 2 of 4

B – Principal Business

B1. Email provision

a) Strategic review of email provision in the University (Prof Ian Leslie, Director of UIS and Mr Keith Turnbull, External Member of ISC & Chair of the Email Review Group) The ISC will receive the attached report for discussion at its meeting on 5 March 2020.

Committee Members are asked to comment on the report to provide the ISC – via this Committee’s minutes – with a steer on whether the report provides an appropriate recommended approach for the University.

OC/114/20

b) Email Service Provision Technical Scrutiny Panel (Prof Ian Leslie, Director of UIS)

At its November 2019 meeting, Council discussed email security (paper 19.11.25.C2, minute 239, Council, November 2019).

Draft Terms of Reference for a scrutiny panel are attached.

Committee Members are asked to comment on the proposed terms of reference. The Secretary will pass these, in the form of a draft minute, to the ISC’s Officers. (The ISC has been asked to confirm the terms of reference by circulation by 14 February 2020.)

OC/115/20

B2. UIS Support over the Christmas Closure (Mr Jon Holgate, Head of Infrastructure, UIS)

The UIS has historically provided limited first line support during the Christmas closure periods. With current tooling and other support options in place this on-call support no longer appears necessary.

The Committee is asked to agree the recommendation to cease the limited support desk cover provided by UIS during the Christmas closure period.

OC/116/20

C – Other Business

C1. UIS delivery and reporting (Prof Ian Leslie, Director of UIS)

A copy of the current Portfolio Directory is available from the committee’s webpages for information.

The UIS is working through options to better articulate the activities that it supports (including use of the ucisa UK HE Capability Model). This will enable it to better report on the cost of supporting and delivering these activities.

Committee Members are asked to discuss what additional information the UIS might provide to further increase transparency and delivery assurance.

OC/117/20

______________________________________________________________________________________________ _ 12 February 2020 ISC Operations Committee Page 3 of 4

C2. Future Portfolio governance arrangements Following the introduction of IT Portfolios as a framework for managing delivery of IT to the University, the ISC and Portfolio Owners requested a review of the governance structure. The circulated paper outlines the proposed approach.

The Committee is asked to note the proposed approach and that it is likely that the current ISC Operations Committee will morph into an Advisory Group to the Infrastructure Portfolio Board.

OC/118/20

C3. Future agenda items

• Identity and access management • Information Security Responsibilities • Energy cost and efficiency of IT at the University • Policies supporting the cohesion of a pan-University IT

community

Suggestions for topics for future meetings are invited.

D – Decisions Required

D1. To agree the recommendation to cease the limited support desk cover provided by UIS during the Christmas closure period (item B2 refers)

E – RESERVED BUSINESS

None.

F – ANY OTHER BUSINESS

G – STARRED ITEMS

Agenda items starred as straightforward will not be discussed unless the item is un-starred by a member. Requests to un-star an item should be received by the Chair or Secretary by 9.00am on the day of the meeting.

G1. Software supported by central software fund OC/119/20

G2. Institutional File Storage Update OC/120/20

G3. Windows 7 End of life OC/121/20

G4. Delivery and implementation of the Digital Presence Strategy (ISC311, November 2019)

OC/122/20

G5. Digital Presence Strategy Implementation Programme (PRC 2148) OC/123/20

G6. Major Incident Report – Wireless Connectivity Issues 2019-10-18 OC/124/20

G7. Major Incident Report – Wireless Outage 2019-11-13 OC/125/20

G8. Major Incident Report – Moodle antivirus and Unison issue 2020-01-02

OC/126/20

______________________________________________________________________________________________ _ 12 February 2020 ISC Operations Committee Page 4 of 4

Date of Next Meeting: Thursday 14 May 2020, 14:00-16:00.

Dates for the 2019-20 academic year:

• Thursday 14 May 2020, 14:00-16:00 • Wednesday 22 July 2020, 10:00-12:00

Chair: Dr Rachael Padman (rp11@cam.ac.uk)

Secretary: Dr Ian Cooper (ian.cooper@uis.cam.ac.uk)

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 1 of 6

ISC OPERATIONS COMMITTEE

A meeting of the ISC Operations Committee was held at 14:00 on Tuesday 29 October 2019, in the Huntingdon Room, Roger Needham Building and by videoconference with the School of Clinical Medicine.

Present: Dr Rachael Padman (Chair), Dr Jim Bellingham (Secretary of the School of the Physical Sciences), Ms Milly Bodfish (Secretary of the School of Arts and Humanities), Dr Caroline Edmonds (Secretary of the School of Clinical Medicine), Ms Lesley Gray (Deputy Director, Digital Initiatives, University Library), Mr James Hargrave (IT Business Manager, School of Arts and Humanities), Dr Peter Hedges (Head of the University Research Office), Prof Mark Holmes (Chair of the School of the Biological Sciences IT Committee), Dr Markus Kuhn (University Senior Lecturer, Department of Computer Science and Technology), Dr Shui Lam (Secretary of the School of Technology), Professor Ian Leslie (Director of University Information Services), Professor Richard McMahon (Chair of the School of the Physical Sciences IT Committee), Mr Jay Pema (School IT Business Manager, School of the Humanities and Social Sciences, deputising for Mr Evans).

In attendance: Mr Simon Clarke (Infrastructure Portfolio Manager, University Information Services), Mr Jon Holgate (Head of Infrastructure, University Information Services), Mr Martin Keen (Head of the Clinical School Computing Service), Mr Neil King (Acting Head of Service Management Office, University Information Services), Mr Steve Riley (Chief Operating Officer, University Information Services, Mr Vijay Samtani (Chief Information Security Officer, University Information Services).

Secretary: Dr Ian Cooper (Head of Planning and Performance, University Information Services).

Apologies: Dr Jenny Barna (School IT Manager, School of the Biological Sciences), Mr Rob Beardwell (Assistant Bursar, Downing College), Dr Keith Carne (Bursar, King’s College), Mr Julian Evans (Secretary of the School of the Humanities and Social Sciences), Mr Edward Parker Humphreys (President, CUSU), Mr John Rimell (Cambridge University Press).

U N C O N F I R M E D M I N U T E S

UNRESERVED BUSINESS

A – PRELIMINARY BUSINESS

The Chair welcomed Members to the meeting and apologies for absence were noted. Mr Pema was deputising for Mr Evans. The Chair welcomed Mr King for item B1 and Mr Holgate for items B2 and B3. Mr Keen had been invited to participate in the meeting, following Mr Bartlett’s departure.

Dr Edmonds and Mr Keen attended the meeting remotely by videoconference.

The next meeting was scheduled for 8 January 2020 but may be cancelled. Meeting dates for the academic year are included in all agendas and minutes.

A1. Declarations of interest

Members were reminded to declare any interests if these occurred.

A2. Minutes (OC/106/19)

The minutes of the ISC Operations Committee meeting on 20 September 2019 were approved.

A3. Membership and Terms of Reference

The Chair and Secretary had not had an opportunity to discuss the vacancy in class h since the last meeting. Some suggestions had already been made and Members were reminded to send any further to the Chair or the Secretary.

OC/113/20

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 2 of 6

A4. Matters Arising

Matters arising not covered elsewhere on the agenda:

a) Institutional File Storage and data security levels: Members were reminded to contact Mr Samtani if they had any views (minute B2, 20 September 2019 refers).

b) Schools’ representation at ISC sub-committees: A detailed review of the ISC’s own terms of reference and membership was taking place, which would also take into account its subcommittees. The representation of Schools would be considered in this light. See also minute C2c below.

B – PRINCIPAL BUSINESS

B1. UIS Service Management

a) Introduction to the UIS Service Management Office

Mr King provided an overview of the decision within the UIS to establish a Service Management Office during the summer of 2019. There had been a lack of consistency in service management and varying levels of maturity. Individuals identified as Service Managers ranged from those in specific roles covering key business systems, embedded in operational teams, where they were unable to allocate time to improving services, to technical team managers for whom service management tasks only accounted for a very small part of their role. Where common objectives for improvement existed (e.g. communications) there was lack of consistency between individuals. The overall lack of consistency was identified as a risk in the implementation of Portfolio management.

The established team included the Change Manager and was working closely with the UIS Service Desk to ensure that improvements are made from the point of first contact in the department, through to the delivery of changes.

The team had already undertaken a number of activities:

• drafting a process for service decommissioning (see item B1b below) • reviewing the major incident process and making a few improvements • developing a consistent report structure for major incident reports

In addition, the work that Mr Holgate had previously started on the definition of Service Level Agreements had been moved to the team and work was progressing.

The report structure for major incident reports had been used to create the report circulated as paper OC/112/19.

A key piece of work currently underway was a review of the multitude of systems run by UIS in order to articulate these into services that would be recognised by users. Roadmaps for improvements were also being developed and these would be brought back to the Committee for discussion at a future meeting. A further discussion on information the Committee would want to receive from the office should also take place.

Action: Secretary & Mr King The work previously undertaken by the charging working group was raised. Prof Leslie reported that services and costs would be reviewed from both the directions of costing and pricing with the intent of meeting midway. Portfolios provided a holistic view covering both projects and services. Under AOB (see minute F below) Prof Leslie reported the intent for UIS to plan a change in the way that network services are funded

The established Service Management Office was learning from others in the sector and beyond, and it was noted that the University is currently following other large Russell Group members in terms of its maturity in this area.

OC/113/20

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 3 of 6

b) UIS Service Decommissioning (OC/107/19)

The Chair noted that the subject matter related to the item minuted at C3 at the Committee’s September 2019 meeting.

Mr King introduced the circulated paper, which set out a standard process to be followed for all service decommissioning within UIS. The level of documentation required by the process would vary on the service and complexity: in some cases it may be appropriate to have a very short report, in others a detailed project plan with assigned roles would be needed.

The process was intentionally non-prescriptive to try to ensure individuals could not find ‘wriggle room’ (e.g. data preservation or destruction would not always be in scope). Having the process would not ensure that decommissioning would, in itself, go well – that was something which must be reviewed afterwards.

A general discussion took place and Members were generally supportive of the proposed plan. Members were concerned that any decommissioning would have appropriate consultation; the need for good communication – and the development and delivery of a consultation plan –would be key. There would likely be significant differences where services were used by thousands of users compared to those with comparatively few, and the needs of users compared with the business also needed consideration. Timelines needed to be thought about, especially where services are used in, or for, teaching. Balancing costs also needed to be considered: if the burden of decommissioning was made too high then costs borne by the University could only increase.

The Chair asked that the Committee sees materials for at least the first few decommissioning reports. The intention was for a transparent process, with plans being widely available in any event, and Mr King therefore saw no problems in ensuring that the Committee received these.

B2. Collaboration Tools Strategy (OC/108/19)

Mr Holgate spoke to the circulated paper, noting that there were at least 30 tools deployed from UIS. This proliferation, and lack of support, created barriers for collaboration, as staff needed to coordinate the choice of tools, and lacked documentation with advice or guidance on how to use them. The ‘Ways of Working’ workstream in ourcambridge sought a variety collaboration tools. The strategy formed part of a wider landscape, which included the Digital Presence Strategy and the strategic review of email provision.

The initial realisation of the strategy would see UIS investing in development of capability in its staff and support resources for the services available within the Microsoft EES agreement, including Teams; users across the University already make significant use of various tools and services from the Microsoft environment. The lack of reference to other collaboration environments (including Institutional File Store) was not an indication that they would be excluded or shut down.

Mutual trust and development of the Blue Active Directory schema were progressing, and Mr Holgate expected announcements in this area to be forthcoming in the near future.

It was recognised that in order to promote collaboration in a more secure environment that the number of tools needed to be limited. The costs of migration and effort required to persuade users to change tools needed to be considered.

The Committee was largely supportive of the strategy but Members noted that external collaboration (e.g. with researchers at other universities) needed to be considered soon. Research staff were already asking how they could reduce their carbon footprints by remote conference participation, for example.

OC/113/20

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 4 of 6

B3. Windows 7 end-of-life

The Committee had previously discussed the Windows 7 end-of-life planning and PC upgrade work at its previous meeting (minute B3, September 2019 refers) and updates on a number of points were included in in the agenda text. There remained approximately 3,000 Windows 7 machines outside of UIS’ scope that needed to be upgraded and it was noted that a large number of these were within the Library and School of Clinical Medicine remits, where work was underway.

A general discussion highlighting the concerns and thoughts of many Members took place. These included, for those areas where UIS is responsible:

• Requests for reassurance that support would be provided when machines are updated(particularly for those users using shared mailboxes, and Personal Assistants).

• That the lessons-learned from the UAS Exchange Online migration are reviewed incase there are relevant points to be considered in this situation.

Mr Holgate reported that UIS had set up a dedicated page with details about upgrading, and various flags had been put in place across the UIS websites. While this end-user material was helpful, further information and support for institutional Computer Officers may be useful. Mr Keen offered to share information and tools that had been developed within his School.

The remaining machines requiring upgrades were largely the responsibility of institutional Computer Officers. The Chair asked for the School Representatives to continue pushing the message for the need to upgrade, and to pass any wider comments to Mr Holgate.

Action: School Representatives

It was noted that there would be some machines connected to the network that cannot be upgraded (e.g. scientific equipment). These need to be identified and should either be disconnected from the network or have other appropriate network controls put in place to mitigate risks.

C – OTHER BUSINESS

C1. Strategic priorities

School Priorities had previously been discussed in January 2019 (papers OC/67/19 and OC/68/19, minute B1). The development of the Portfolio management model, and lack of consistency in the approach taken to articulate the priorities (minute B3, March 2019 refers), had led to progress being stalled during the year.

a) Progress on mapping School Priorities to IT Portfolio activities (OC/109/19)

Mr Hargrave introduced the circulated paper, which presented a redrafted and simplified view of the School Priorities, articulated in terms of the four Portfolios. Links to existing project and other delivery work had also been considered, and the work had been reviewed between the UIS Relationship Managers and the Portfolio Managers.

A significant amount of time had passed between the original collection of priorities, which had been ratified within the Schools’ governance structures, and the presentation of the current amalgamated list. There was consensus that the Committee’s School Representatives should take the materials back to their Schools for ratification prior to incorporation in formal Portfolio planning (Relationship Managers should be involved in the process). The Committee felt that there was no additional value at this point for Schools to individually score the relative priority of individual items.

Action: School Representatives

OC/113/20

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 5 of 6

Prof Leslie reported that the next meeting of the Portfolios Sub-Committee would be in mid-November, and that tactical prioritisation of work would be covered on the agenda. There was some concern that the ratified School Priorities would not be available for that activity, though Prof Leslie believed the two could work in parallel.

It would be helpful for the School Priorities to be articulated through the standardised request form, and Prof Leslie would ensure this was circulated.

Action: Prof Leslie/Secretary Mr Hargrave indicated that the Relationship Managers, School IT Business Managers, and Portfolio Managers would continue to meet regularly. The progress that was being made was noted.

b) Colleges’ Combined Strategic Priorities List (2019) (OC/110/19)

Neither College representative was in attendance, and it was therefore considered inappropriate to have any detailed conversation about the circulated paper, though the presence of the information was welcomed. The Secretary had observed that the list contained many items in common with those from the Schools; Mr Hargrave reported that the Schools’ list had been shared with the Colleges and may have contributed toward this.

C2. School IT Committee minutes (OC/111/19b,c,e,f)

Mr Pema reported that the School of the Humanities and Social Sciences had recently formed an IT Committee.

a) Software Committee

The School of the Physical Sciences had highlighted concerns that the group operating the Software Site Licensing Scheme had not met, which was reported to have caused incurred expense for the purchase of software. Mr Pema reported that some recasting of the committee was taking place, but that the budget it oversees was currently allocated to existing arrangements. Mr Riley offered to provide a report at the next meeting, which would include the current licenses supported by the fund.

Action: Mr Riley b) Software sales The UIS had already observed significant problems with the service being offered by the contracted third-party supplier, and had organised a meeting with their senior management to discuss these.

c) Transparency

The Secretary had observed that there seemed a consistent theme of concerns over transparency of UIS operations throughout the School committee minutes. Prof Leslie reported that in December the UIS expected to have a management report that articulated where resources were allocated and that in due course this could be shared more widely. It was intended for Portfolio plans and decisions to be widely available.

The discussion moved on to wider issues of how the Portfolio Planning Teams would consider School needs. For the Portfolios other than Infrastructure there were existing committees where Schools were generally already represented. Prof Leslie did not feel that it was appropriate for this Committee to be tightly coupled to the Infrastructure Portfolio (noting its role as the business committee for the ISC). Instead, School representation should be within the Portfolio Planning Team, though it would not be possible to have a seat for each School. The Schools should work out between them how best to represent their combined needs, assuming about three representatives. School representatives on this Committee should contact the Infrastructure Portfolio Manager (Simon Clarke) with their suggestions.

Action: School Representatives

OC/113/20

_____________________________________________________________________________________________________ 29 October 2019 ISC Operations Committee Page 6 of 6

C3. Future agenda items

Members were reminded to inform the Chair or Secretary of any items that should be covered in future meetings. A number of items on the list had been flagged with no apparent action for some time.

D – DECISIONS MADE

D1. The Committee decided that the Schools would not be asked to prioritise items on the amalgamated list of priorities (minute C1a refers).

D2. The Committee agreed that School Secretaries should ensure that the current amalgamated list of priorities should be ratified in the individual Schools prior to incorporation in Portfolio Planning (minute C1a refers).

E – RESERVED BUSINESS

There was no reserved business.

F – ANY OTHER BUSINESS

In discussion of future agenda items (C3, above), Dr Hedges asked about the absence of a major incident report relating to a recent cybersecurity incident. Mr Samtani commented that the incident report lead was another department but that the loop needed to be closed to ensure appropriate reporting. Prof Leslie reported that the incident had been discussed at the ISC.

Prof Leslie reported that the UIS was planning on changing the way that the University’s network services are funded through the next Planning Round, which would be consistent with the charging policies identified by the Charging Working Group. This would include managed firewalls.

A report on the recent problems with the wireless service would be provided in due course.

Progress on the strategic review of email provision was likely to be reported within the next month.

G – STARRED ITEMS

G1. Major Incident Report – Raven Authentication 2019-10-07 (OC/112/19)

DATE OF NEXT MEETING: The next scheduled meeting is 14:00-16:00 on Wednesday, 8 January 2020, though this is likely to be cancelled.

Meeting dates for the 2019-20 academic year (rooms to be confirmed):

• Wednesday 8 January 2020, 14:00-16:00 • Wednesday 12 February 2020, 10:00-12:00 • Thursday 14 May 2020, 14:00-16:00 • Wednesday 22 July 2020: 10:00-12:00

OC/113/20

* position not originally noted in original Reporter article

STRATEGIC EMAIL REVIEW FINDINGS

ISC ERT, 28 JAN 2020 V1.5

INTRODUCTION The University of Cambridge currently has two centrally provided email systems: Hermes, which is a local implementation of an open-source system running on premises in the University; and Exchange Online (ExOl), an external cloud-based service hosted by Microsoft but managed by the University Information Services department (UIS). The University’s Information Services Committee (ISC) decided in March 2019 to conduct a strategic review of centrally provided email services to consider the current and future needs of the University. To do this they co-opted a volunteer Email Review Team (ERT) consisting of 4 senior members (3 current staff and an Emeritus Fellow) of the collegiate University chaired by an external ISC member. A notice was published in the 9 May 2019 edition of the Reporter setting out the review’s remit and seeking views, requirements and recommendations from staff and other interested parties within the University. Originally the ERT was expected to report by early June 2019 but, given the volume and elongated period of input, the ISC extended the timeline of the review and announced this in the 19 June 2019 edition of the Reporter. There was a further delay due to an additional email security review following an email related incident in the latter part of 2019. This has resulted in a decision for all central official administrative staff mail to be protected by two factor authentication (2FA).

THE REMIT FROM THE ISC The following terms of reference and request for submissions appeared in the 9 May 2019 Reporter (No. 6546).

The Information Services Committee (ISC) has commissioned a strategic review of the centrally-provided email systems in the University and is seeking contributions from staff and other interested parties within the collegiate University on the areas under consideration (see below). The ISC has appointed Mr Keith Turnbull, one of its external members, to chair the review, with support from:

Dr Richard Clayton, Department of Computer Science and Technology Dr Andrew Herbert, Emeritus Fellow Computer Science* Wolfson College Dr James Knapton, University Information Compliance Officer Dr Rachael Padman, Department of Physics

Following a two-year programme of rationalisation, the University now has two centrally-provided systems: Hermes, which is a local implementation of an open-source system running on services in the University; and Exchange Online, an external service run by

OC/114/20

2

Microsoft [note: a more accurate formulation would be “hosted by Microsoft and managed by UIS”]. Central email services in the University have, over the last decade and more, become critical to the day-to-day life of the University but a long-term strategy has not been developed which considers the current and future needs of the University. In this context a strategic review of the central email provision is timely.

The review will consider the centrally-provided email systems Exchange Online and Hermes, and the PPSwitch mail transfer agent which supports both email systems. Email systems operated by University institutions other than UIS or those operated by Colleges will not be included in the review, except in considering the dependency of these systems on Hermes, Exchange Online, or PPSwitch.

The review will consider and make recommendations on:

1. A long term strategy for email provision in the University, with specific regard to usability, reliability, eligibility, use policy, security, sustainability and value for money.

2. What part widely-available free-to-use email services from Google, Microsoft and others can play in the University’s strategy for email provision.

3. The relationship between the provision of central email and of related services, including calendar management, contact and address management, mailing lists and collaboration tools, and task and to-do list management.

4. How to support people arriving at and leaving Cambridge to continue to use archives of emails.

5. Opportunities and risks afforded by, and good practice in, providing local email solutions.

6. How the University can effectively discharge its regulatory, statutory and contractual obligations in relation to provision of email services including with regard to the personal use of email facilities by students and staff

The review will draw on existing evidence and evidence submitted during the review, and may also commission or request evidence and advice from within and outside the University. Interested parties may contribute or request further information by emailing the review group via ucam-isc-emailreview@lists.cam.ac.uk from an @cam.ac.uk email address. The deadline for contributions to the review is Thursday, 30 May 2019.

It is anticipated that the report on the outcome of the review will be provided to the General Board and the Council later in Easter Term 2019, prior to publication in the Reporter.

EXECUTIVE SUMMARY AND PRINCIPAL RECOMMENDATION There were 49 submissions to the review, comprising a mixture of departmental and individual comments. The responses were heavily weighted to those working in UIS, computing and scientific disciplines and otherwise were principally the views of IT staff who worked in the departments or colleges. Every submission welcomed having a strategic email review. Some however thought the review’s original timescale too short and recommended a longer and more in-depth investigation of user requirements and solutions. There were calls for a more transparent and phased project methodology and further extended consultation. There were many detailed concerns, some of which needed additional technical due diligence. There were very strong opinions expressed, both for maintaining or moving away from Hermes and for using or discontinuing Exchange Online. Experienced users tended to be advocates of their current system and were hostile to any change. Overall the ERT was surprised that very few who submitted evidence started from a position that acknowledged that integrated new ways of working would be possible and improve productivity and communication. There was instead

OC/114/20

3

concern expressed about the effect on staff of additional workloads if there were changes to current systems.

During the review period, while considering the submissions, the ERT and ISC was made aware by the University’s Chief Security Officer (CISO) of relevant recent incidents and developments. This comprised a number of very serious email security breaches which had as their common cause the discovery of userid-password combinations by the attacker and consequent access to University systems, especially email accounts. To mitigate against further attacks, the CISO strongly recommended extending the Two-Factor Authentication (2FA) system, currently being trialled in some areas using ExOl, across all accounts used by University administrative staff (those using @admin.cam.ac.uk email addresses) and potentially across accounts used by all other University staff and, eventually, students.

Based on the level of security threat and the breaches experienced, and the consequent strong recommendation of the CISO to implement 2FA widely, the majority of the ERT believes the University should accelerate the rollout of ExOl as the principal University email system. Oxford University, which has a comparable structure and similarly complex IT arrangements, has already moved to ExOl (as have most other major UK universities) and its experience suggests that this can be achieved successfully. The ERT nevertheless believes that such a project requires a rigorous and transparent project methodology, to be instituted immediately, whereby all the requirements, issues, resolutions and milestones are dynamically published and there is regular communication between the UIS project owner/team and all identified stakeholders/users. The ERT also acknowledges that there is work required in some departments and colleges to migrate email-based workflows away from Hermes. UIS provide an existing migration tool from Hermes to Exchange Online to accelerate and aid further transitions. In addition, it would be helpful for UIS to set up a community forum, as part of the transition project, to share expertise and best practice. This recommendation does not discount that there may still be a perceived need by some groups for local instances of Exchange or Hermes to be maintained by some institutions. However each case should be vigorously and objectively debated as to why such an exception is needed and indeed how any outlier groups can comply with the overriding need to implement 2FA without recruiting additional specialist staff and incurring additional cost either centrally or at group level. The existing PPSwitch mail transfer mechanism (based on Exim) should continue in the interim, but UIS should investigate a current supportable secure alternative. The ongoing interim use of the current mailing list software, MailMan, is recommended but again UIS should investigate using a current secure supportable alternative such as Sympa.

COMMENTARY AND SUBSIDIARY RECOMMENDATIONS ON EACH AREA OF THE REVIEW’S REMIT

1. Long term strategy for central email provision in the University, with specific regard to usability, reliability, eligibility, use policy, security, sustainability and value for money.

1.1. Value for money. Firstly, there are no enterprise-level ‘free’ email services. Whether using Microsoft, Google G Suite or in-house Hermes there are costs (staffing and licensing) with all of these. With the provision of University-wide Office 365 licenses at Cambridge, the basic cloud email services come as part of the inclusive license fee so

OC/114/20

4

there is little marginal license cost. However, there are additional licence costs for enterprise-level email security features and support coupled with the University staff costs of email management and local support. Although Gmail is not centrally supported at this time, UIS has licensed and enabled all owners of .cam.ac.uk email accounts to use Google G Suite if they so desire. Hermes is being run on very minimal and inadequate levels of management and support, having effectively not been developed much beyond 2003. It would require significant investment to bring it up-to-date, and even then it would still not have all the features and integration that ExOl/O365 has. In particular, developing a 2FA system for Hermes would take time which, given recent incidents, the University does not have. However, overall the ERT does not regard cost as a major decision-defining differentiator between these systems and notes that ExOl gives reasonable value for money as well as enterprise-class security.

1.2. Usability. O365 has had much usability development over many years; it has a very clean and function-rich native client user interface which integrates very well across the whole O365 toolset for all platforms save Linux. The Outlook/O365 web interface has also greatly improved and can run well on Linux browsers. There are even O365 extensions for Chrome and Chromebooks. Gmail can run with most native clients on most platforms including Linux as well as having a web interface that runs on the Chrome browser, which again works on most platforms in use at Cambridge. The basic Gmail web interface still has relatively clunky interfaces and lags behind many native clients such as Outlook or Thunderbird.

1.3. Reliability. Hermes has been very reliable, although it was down for several hours due to a power failure in January 2018. ExOl has suffered some temporary Cambridge-specific issues in the past 18 months as part of the initial rollout but the ERT understands that these issues have been resolved by UIS. There have been some widely reported, albeit short, regional outages from the Microsoft Cloud on at least 2 days in 2019. Gmail is also in the main very reliable, with only occasional short outages. Both ExOl and Gmail claim an SLA of at least 99.9% up-time which equates to a maximum of 8.77 hrs downtime a year. UIS maintains a real-time status page and allows anyone to subscribe to service alerts.

1.4. Sustainability. Hermes relies on a dwindling skillset as the base opensource Cyrus code is used by a decreasing number of institutions. Carnegie Mellon University, which created the original Cyrus codebase, transitioned its own staff to ExOl and students to Gmail in 2016. From a career progression point of view, Cyrus/Hermes-specific code and administration skills are not in any commercial demand. The Cyrus source code relies on updates from a small commercial company, FastMail, and other volunteers. ExOl and G Suite continue to be very actively developed and continuously updated to secure best practice. They are both supported by much larger global teams together with integration across related tools and native client support for updated mobile platforms. The administration and support skills for both are readily available in the job market and there are many established online and classroom based training courses, exams and certifications producing a constant stream of qualified people.

1.5. Migration from Hermes to Exchange Online. A web interface at https://migrate.hermes.cam.ac.uk has been in place since 2016 to allow people to migrate email from Hermes to Exchange Online. It also automatically updates @cam.ac.uk and @hermes.cam.ac.uk email redirections. As of May 2019, 2325 people

OC/114/20

5

had used this to migrate email to the main Exchange Online tenancy, and 1882 people had used it to migrate to the alumni tenancy.

1.6. Security. The commercial cloud platforms are in an aggressive quality cycle of continuously being tested internally and by external bounty and academic researchers, leading to frequent and rapid automated patches. Updates on the server side are transparent and have little local management overhead as they are dynamically run on the cloud-based servers. The on-premises service Hermes has had occasional patches which have to be tracked and manually implemented by University IT support staff. The underlying on-premises Linux platform for Hermes would need patching on a much more frequent basis given the high rate of discovered security vulnerabilities which afflict all operating systems.

2. What part widely-available free-to-use email services from Google, Microsoft and others can play in the University’s strategy for email provision.

2.1. Technically no enterprise-level service is free. However ExOl is already being used as a built-in part of the O365 subscription. As UIS is already on that path with ExOl, and given the strong recommendation to further extend the 2-factor authentication that is being piloted with ExOl, the majority of the ERT recommend making ExOl the core central email service. This is already the case in many enterprises and in other UK universities. A transition period to support Hermes and local instances of Hermes/Exchange should be factored in to work through specific issues. However given the security implications this period should be kept to a minimum. If unresolvable and intractable issues are found with certain institutions, there should be preparedness to accommodate local instances of Hermes or Exchange. However the latter should be an exception of last resort rather than a default and with the institution taking on the responsibility for security issues.

2.2. ExOl is used successfully with a wide variety of native clients other than Outlook e.g. Gmail, iOS, Android, Thunderbird, etc. It also has administrative tools to allow setting of and conformance to policy, with built-in auditing and alerting. It is comprehensively tested from a quality and security point of view to very high standards and conforms to all common enterprise software standards. ExOl also allows easy integration with many Two-Factor Authentication systems, one of which is already being successfully used on a small scale within the University (Duo).

2.3. Although there are some local instances of Gmail being used by University departments, it would require an added overhead to set-up and support Gmail centrally. As mentioned elsewhere, there are potential technical issues with SPF that would need to be investigated if this route was chosen. However, this does not stop individuals from using their own Gmail client and calendars in conjunction with ExOl/O365. Gmail allows Two- Factor Authentication via Smartphone apps, SMS, alternative emails and 3rd party add-ons.

2.4. A more visible and active email project and project team should be established by UIS to working with all stakeholders and other related teams. The list of requirements and issues gathered in this limited review should be expanded and turned into a set of guidance documents and extended functionality milestones agreed with all stakeholders. This should use an Agile rather than Waterfall methodology given the fast-changing landscape of technology, threats and user requirements in this area.

OC/114/20

6

3. The relationship between the provision of central email and of related services, including calendar management, contact and address management, mailing lists and collaboration tools, and task and to-do list management.

3.1. There are several parallel but related University-wide projects looking at collaborative groupware, calendaring , address look up, ad-hoc video conferencing, room booking systems and so on, all of which would benefit from the examination of integration points to give a consistent and useful user experience.

3.2. The Office 365 suite can cover all of these service areas and most other specialist 3rd party products integrate with O365 given its ubiquity. These can be run via native or web clients.

3.3. Likewise, G Suite offers an alternate integrated suite which is Chrome browser based.

3.4. O365 and G Suite use standard calendar formats so can interact successfully with each other.

3.5. Hermes is a standalone email service and has not evolved to integrate with these services and functions.

4. How to support people arriving at and leaving Cambridge to continue to use archives of emails.

4.1. The current operational requirement is for anyone with an @cam.ac.uk email address to have an active ongoing role in the collegiate University. It is recommended that this should continue, with any historical exceptions being subject to a transitioning process to move those users’ content to personal email accounts of their creation. Within legal and contractual constraints, there should be a standardised process to allow for the export of approved archives to an email system of the user’s choice when leaving a University role (and thereby also giving up an @cam.ac.uk email address).

4.2. The policies and procedures in this area should make clear that tools and services signed up to with an @cam.ac.uk email account are those paid for or run by the University and therefore are not transferable to personal non-University use. Individuals should use personal email accounts to sign up for tools and services that they intend to use outside of their University activities, and also which they intend to continue using when they no longer have an @cam.ac.uk email account.

5. Opportunities and risks afforded by, and good practice in, providing local email solutions.

5.1. Local email solutions, while offering flexibility and opportunities for tailoring, are comparatively expensive to maintain and administer in terms of additional staff resources. Consequently, they often fall behind in maintenance which can lead to vulnerabilities not being patched promptly when coppered to enterprise-level cloud systems.

5.2. Modern cloud systems continuously patch and update functionality and security on a 24x7 basis normally with zero downtime and with little or no overhead for University IT teams.

5.3. Modern cloud-based email systems have sophisticated spam filtering which is continuously updated and also smart anomalous behaviour detection. They also use

OC/114/20

7

and/or can support a rich variety of multi-factor authentication methods. All of these make them highly secure as standard with no additional overhead on University staff.

6. How the University can effectively discharge its regulatory, statutory and contractual obligations in relation to provision of email services including with regard to the personal use of email facilities by students and staff.

6.1. Going forward there should be a clearly stated usage policy statement setting out how @cam.ac.uk email addresses should be used (or not used) in regard to University and private business, covering issues such as legal ownership, acceptable use, user confidentiality, institutional access and so on. This statement should be referred to in employment contracts (or equivalently universal documentation) and could be reinforced by the mandatory acceptance of the statement when subscribing or registering for University email services.

6.2. Current practice allows the arbitrary forwarding of @cam.ac.uk email to any internal or external mail service whilst the individual has an active University role. While it might seem inadvisable that email of a potentially confidential or sensitive nature, covering numerous types of University business, should reside outside the central University email system, in practice this is very difficult to control as all non-web clients download locally. Where particular confidentiality is required there could be a forwarding restriction enacted on specific accounts. There may also be a case for some form of encrypted solutions or policy-based Digital Rights Management (DRM). Office 365 has a built in DRM feature to dynamically protect and track sensitive documents. This works natively across Windows, MacOS, iOS and Android though not Linux, where the web client would have to be used.

OC/114/20

8

APPENDIX 1. OBSERVATIONS ON THEMES ARISING FROM SUBMISSIONS TO THE REVIEW

1. There are many policies and sub-policies covering the use of email accounts that are documented in many different places across the University. Cambridge is more complex than most universities in this regard.

• Most submissions stated that there should be a much clearer statement of policies for the use of centrally provided @cam.ac.uk email versus personal email accounts. While this separation of professional and personal email via multiple accounts accessed by a common client is widely accepted in the commercial world, historically in the University there are those who have relied and still rely on their @cam.ac.uk as their sole email account.

• Many submitters stated that their users simply automatically forward all @cam.ac.uk email to their internal (Hermes) or a personal email external provider. Forwarding externally might compromise confidential or otherwise sensitive information so policies must be clear on what is acceptable from a data exfiltration perspective.

• The standards of governance required by organisations today require that, given the correct legal controls, email must be searchable by organisations to support civil and criminal investigations. Therefore individuals who choose to use their centrally-provided email for personal use must be aware of the potential limitations of the privacy afforded to their correspondence.

2. The Hermes system is based on the Carnegie-Mellon(CMU) University developed Cyrus

system (https://en.wikipedia.org/wiki/Cyrus_IMAP_server). CMU have retired Cyrus and replaced it by ExOl for staff and Gmail for students. Cyrus is now an Open Source project (cyrusimap.org) supported on a volunteer best effort basis. The major support comes from FastMail, a commercial organisation which uses the codebase for their own separate cloud-based, paid-for offering. • The current implementation of Hermes does NOT support shared mailboxes. Currently,

shared email addresses and passwords are in common use amongst some staff. This is insecure and not a recommended practice.

• Hermes/Cyrus has very limited University support staff and resources and only supplies 2GB mail quotas, which are too small for most users. There was a mixture of diametrically opposite views expressed on whether to either invest in or deprecate the Hermes system.

• Existing Hermes users are concerned that, if forced to switch to another system, there could be a loss of functionality (especially IMAP compatibility) and additional overheads on users and IT support staff.

• Hermes still runs a very large number of email accounts although all new students (since the 2018 academic year) now start with ExOl as the default. There are currently around 26,500 active accounts (i.e. at least one login each week) on Hermes as of 20/5/19, compared to around 33,500 at the same time last year. ExOl itself has circa 32,000 University accounts.

OC/114/20

9

• The existing 2GB default mail quota in Hermes was stated as inadequate by most. ExOl has 50GB as a default. Some felt this could be addressed by investing in new Hermes hardware. Others, including those who were very technically proficient with Hermes, made the case that the investment required to make it totally resilient would take considerable resources and time over and above merely purchasing additional disk space. In addition, some clients in use may have issues with large local mailboxes of 50GB.

• Hermes hosts email for some retired staff (currently approximately 1067 accounts) and possibly other affiliated people who would not qualify for accounts on Exchange Online. A decision will need to be made on whether to continue support for these users by migrating them to ExOl, or asking them to migrate to their own email provider.

3. The ExOl system was introduced as part of introducing the Office 365 suite. ExOl licensing

comes as part of the integrated suite of standard Office 365 products (Word, Excel, PowerPoint, etc.) that are an accepted standard in both commercial and academic organisational environments. While there is minimal incremental cost for ExOl as part of Office 365, there are additional costs for enterprise-level support and additional enterprise features (e.g. Advanced Threat Protection) that the ERT would recommend that UIS should take up. Originally ExOl was rolled out into UIS in 2017, with other institutions and departments opting in voluntarily. • A number of submissions queried the fact that the rollout was not run as a fully-fledged

project with transparent user, departmental and University requirement-gathering and subsequent refining of said requirements to select and implement a target system.

• As of the 2018/19 academic year all new students have been auto-enrolled onto ExOl unless specifically opting out.

• There were comments on whether this was really ‘free’ and what would happen if licensing costs were arbitrarily increased by Microsoft if there were no alternatives.

• The major objections from submitters were around non-compliance to standards and interoperability. These were:

3..1. IMAP compatibilities. 3..2. ExOl does not preserve structure and formatting of messages PGP issue. 3..3. ExOl has fixed transmission rates which need special handling and scripting.

• It was noted that the University’s instance of ExOl, at the level of licensing it had at the time of this report, does not use the Advanced Threat Protection option to reduce Spam and Phishing mail. Most major enterprises subscribe to this additional functionality.

• Some respondents claimed worse reliability with ExOl than that stated on the officially-generated UIS live status webpage. They reported that they had experienced problems even when the real-time status was showing green. It is not possible for the ERT to verify this historically in detail. However UIS has stated that there were a number of University-specific issues in 2018 and early 2019 that have now been resolved. Nonetheless, there have been well-reported occasional large-scale outages of ExOl which have affected operations, normally over a few hours.

• Currently, there are 32,919 active mailboxes on ExOl. The volume of ExOl users does not appear to be widely known, especially amongst committed Hermes users. (These include Alumni mailboxes.)

• ExOl is stated in submissions as not being under an official Microsoft support SLA agreement at the time of writing. Although incurring an additional cost per annum,

OC/114/20

10

having proper support seems appropriate for the scale of usage at Cambridge and this should be reviewed by UIS.

4. G Suite / Gmail.

• UIS has licensed and enabled all owners of @cam.ac.uk email accounts to use Google G Suite if they so wish but without Gmail at this time. This includes mostly equivalent functionality to Office 365 but is all delivered via the Chrome browser and therefore suitable for all systems including Windows, MacOS, Linux and Chromebooks. In theory it would be easy to enable Gmail as another option alongside ExOl although there are some key technical considerations regarding SPF that need to be considered. Although there was much feedback in many submissions from Linux users as to the unsuitability of web-based email, there is no doubt that Gmail interface is the most popular web-based email user interface in the world. Furthermore, if there is a preference for local native clients with local email storage for offline working, then the current native clients in use such as Alpine and Thunderbird work well with Gmail. However the need to implement 2FA as a matter of urgency means that using the Outlook web client may be required as a stop gap.

• In contrast to free personal Gmail accounts, with paid-for G Suite Gmail accounts, Google states that no email scanning (for targeted adverts) is undertaken and that they are compliant with appropriate data protection standards.

• G Suite is available in Basic, Business and Enterprise Editions, with the latter having the best security and policy controls.

5. In some submissions, mention was made of a Student-Run Computing Facility Hades email

system. This is a volunteer student society-run system. It is not supported by the University in any way. Some respondents stated they would move or have moved to this in anticipation of Hermes being retired. This system, like Hermes, has severely restricted quotas. The ERT feels this is not a credible alternative to support any official @cam.ac.uk email services and would advise against anyone moving to this unless for purely personal use. As per the remit this is not considered further.

6. There was concern that being tied to a cloud-based US email provider could lead to a number of issues such as:

• Vendor lock-in (if the sole provider). The ERT believes that providing a choice of supplier with G Suite Gmail would ease this issue.

• The potentially unrestricted access given to US-based law enforcement and security agencies. The ERT is not qualified to comment on what access US or other overseas security agencies might undertake but notes the comparably wide-ranging UK laws for account access for specified law enforcement and security purposes.

• Emails and attachments being held outside the UK (though UIS has stated that Cambridge ExOl data is held in Dublin or London based servers. The University’s ExOl contract is held with Microsoft UK Ltd).

• Restricting access to users who had visited countries subject to US restrictions or sanctions. An example was given of Slack removing access to users who had visited

OC/114/20

11

such countries and who had used the application there. Given that the University’s contracts are all with Microsoft UK this is thought unlikely.

• An actual external security attack vector on ExOl was quoted where there was a compromised corporate support account. While there always is the possibility of a compromised support account, whether on an internal or external email system, the attack surface is clearly larger in a global cloud-based system. Set against that is the fact that systems such as ExOl have more investment in real time and AI-based security monitoring systems which quickly flag or block anomalous behaviours (e.g. ‘impossible travel’ login alerts or blocking).

7. There was clear need stated in many submissions for flexible mail routing and management of .cam.ac.uk domains and sub domains. Mail from an @cam.ac.uk address is deemed “official” by most recipients and any compromises in terms of spam mails sent from these addresses would affect the University and/or its departments reputationally. PPSW, a SMTP smart host, currently handles this task for most of the 99 different email domains under @cam.ac.uk. ExOl also runs in parallel and is responsible for the routing of a few sub domains. The PPSwitch system is currently run through Hermes. PPSwitch is based on Exim which is opensource and has only volunteer, best-effort support. PPSwitch has been stated to have more flexible rate sending limitations than ExOl which help to prevent outbreaks of spam from malware-affected machines. The current PPSwitch system appears to work well and gives the University additional local control compared to an external cloud system. It is not clear to the ERT whether a better job can be performed purely with ExOl. However more detailed and technical investigation needs to be undertaken to ascertain how it could evolve or be replaced going forward.

8. There were clearly and repeatedly stated needs for a sophisticated mail list manager. Currently, the University uses Mailman for 13160 mailing lists of which half have been active within the last 18 months. It appears that ExOl can only provide basic facilities compared to the current Mailman system. However, the ERT also note that Mailman is deemed by its support staff to be end-of-life and in need of replacing. However, this could be with another package such as Sympa (used by Oxford University amongst others) rather than ExOl given the latter’s limitations with:

• Message moderation

• Automated management of subscriptions and bounces

• External subscribers to mailing lists

• Mailing list archives

This needs further research and follow up by UIS to determine a course of action.

9. Continued native client (as opposed to a pure web interface) support for Linux users was

requested.

• There appear to be numbers of Linux users who want to continue to use their native mail clients e.g. Thunderbird. While there have been some initial issues (that UIS in the main have solved) this client works with ExOl using either POP3 or IMAP4 via the ExQuilla plugin. UIS publishes instructions for this on their email help page.

OC/114/20

12

• Some users use the Linux Alpine client. It is possible to use ExOl with these old clients but UIS only gives setup help for Thunderbird/Exquilla and Evolution clients.

• The Outlook web client is very close to a native client now in terms of performance and user experience so the ERT would recommend users try the latest versions.

However, given the University CISO’s recommendation to move to 2FA, the use of the Outlook web client will provide an easy way to implement this until UIS have assessed whether and when they will be able to integrate 2FA into any of the native Linux clients.

10. Good support for mobile users was requested in some submissions. Curiously, this was not raised by many respondents but it is clear that accessing email through a smartphone is an accelerating and indeed default trend for many users. Clearly webmail provides a base level of access but generally lacks the off network storage and browsing capability of a native iOS or Android App. ExOl can be used with both the native iOS and Android mail apps as well as with the specific Microsoft App so gives flexibility. The impending new Microsoft Office Mobile App will further extend functionality of O365 onto mobile devices.

11. Need to support role based email without shared passwords:

• There were many submissions emphasising the need for role-based mailboxes, especially when dealing with departmental functions or research data.

• The most secure way to handle this is to use individual logins that then have shared access to a role-based mailbox in addition to the user’s normal personal mailbox. Currently Hermes does not support this while ExOl does.

• Some respondents want to or already do use role-based email addresses with shared passwords but that is insecure and a security risk which the ERT views as bad practice. This should not be allowed and phased out rapidly from a policy/security/governance point of view.

OC/114/20

13

APPENDIX 2. COMPARISON WITH OTHER UNIVERSITIES It was observed that many other major universities in the UK have already moved fully to an ExOl based email system. An incomplete but representative set is: Oxford, Warwick, Leeds, Imperial, Reading, Glasgow, Bristol, Edinburgh, Nottingham, Exeter, Aberdeen, Strathclyde. A deeper dive to investigate the process of transitioning to ExOl and assessment of the current performance was undertaken with Oxford University’s IT department since its distributed and collegiate structure is similar to that of Cambridge. The main findings were that:

• Oxford started its move in 2016 and spoke extensively to Imperial College who had successfully transitioned to ExOl before them.

• The current status is that most groups in Oxford have given up internal email servers and use ExOl without issue.

• Oxford do maintain an additional smtp mail router to cope with those few groups who still maintain an internal mail server.

• Most day-to-day mail issues are focused on maintaining the few outlier groups with their own mail servers.

• Oxford also run a mail list server, Sympa, over and above ExOl as the demands of a large University requires the sophisticated management of many thousands of lists with modern mail list management capabilities.

OC/114/20

14

APPENDIX 3. LIST OF DEPARTMENTAL AND INDIVIDUAL SUBMISSIONS

1 Development and Alumni Office 2 School of Physical Sciences 3 Faculty of Mathematics 4 Institute of Astronomy IT staff 5 Department of Physics 6 Department of Materials Science and Metallurgy 7 Department of Chemistry 8 Department of Geography 9 Department of Archaeology 10 Department of Social Anthropology 11 Colleges IT Mgmt Group 12 Clinical School Computing Service 13 Department of Engineering, Information and

Computing services

14 School of Technology 15 Department of Genetics 16 School of the Biological Sciences 17 UIS, Technical Design Authority 18 UIS, DevOps Group 19 UIS, Chief Information security Officer 20 IT and 3D Imaging officer Individual submission 21 UIS, University Postmaster Individual submission 22 UIS, University Postmaster Individual submission 23 UIS, University Computer Officer Individual submission 24 UIS, Security Operations Individual submission 25 UIS, Frontline Services Individual submission 26 UIS, University Hostmaster Individual submission 27 UIS, Telcoms Individual submission 28 UIS Individual submission 29 UIS, CSIRT Individual submission 30 UIS Individual submission 31 UIS Individual submission 32 Department of Engineering, IT Individual submission 33 Department of Engineering, IT Individual submission 34 Department of Engineering, IT Individual submission 35 Department of Engineering Individual submission 36 Dept of Computer Science and Technology Individual submission 37 Computer Lab Individual submission 38 Department of Computer Science and Technology Individual submission 39 Computer Lab Individual submission 40 IT, Fitzwilliam Individual submission 41 Faculty of Education Individual submission 42 Department of Pharmacology Individual submission 43 IT, Darwin & St Edmund’s Individual submission

OC/114/20

15

44 TCM Group, Cavendish Lab Individual submission 45 Department of Chemical Engineering and

Biotechnology Individual submission

46 Department of Geography Individual Submission 47 Department of Geography Individual Submission 48 Department of Archaeology Individual submission 49 University Library Individual submission

OC/114/20

16

APPENDIX 4. REFERENCES [1] David Carter, Tony Finch: Scaling up Cambridge University’s email service.

UK Unix User Group Large System Administration Winter Conference, Bournemouth, February 2004. http://people.ds.cam.ac.uk/fanf2/hermes/doc/talks/2004-02-ukuug/paper.html

[2] Tony Finch: Exim configuration at the University of Cambridge.

First International Exim Conference, Birmingham, February 2005. http://people.ds.cam.ac.uk/fanf2/hermes/doc/talks/2005-02-eximconf/paper.pdf

[3] Tony Finch: Email routing in the University. Techlinks presentation, July 2011.

http://people.ds.cam.ac.uk/fanf2/hermes/doc/talks/2011-07-techlinks/ [4] https://www.admin.cam.ac.uk/reporter/2018-19/weekly/6546/section1.shtml#heading2-7 [5] https://help.uis.cam.ac.uk/service/email/exchange-online/hermes-eol-migration/hermes-migration-advice

[6] http://8bitbatty.com/post/pine-lives-using-alpine-with-gmail/

OC/114/20

Last Modified: 17 January 2020 Page 1 of 1

Email Service Provision Technical Scrutiny Panel Terms of Reference Responsibilities

1. The panel is responsible to the ISC for the scrutiny of actual and proposed implementationsof email service provision in the Collegiate University.

Specific duties 2. To provide support to the ISC by scrutinising the current and planned implementations of

email service provision, paying specific attention to:a. Security;b. Conformance with University policy;c. Reasonable public expectations of the University, and obligations of the University

arising from regulations and laws;d. Interoperation with other collaboration and communication platforms;e. Ease of use and potential disruption to current practices;f. Beneficial impacts within and on the Collegiate University;g. Costs to the University and/or Colleges, including financial and working time costs;

andh. The findings of the ISC-commissioned strategic review of email provision in the

University (see Council Notice published in Reporter no. 6546, p528).3. To report to the ISC its findings and opinions, at times and in a manner to be agreed

between the Chair of the panel and the Chair of the ISC.

Access to information 4. The panel is entitled to review technical documents produced by or used by UIS that are

relevant to email service provision, and to request additional relevant information from staffwhose duties are relevant to email service provision. It should have regard to the costs andeffort of providing additional information when making its requests.

5. The panel is entitled to request advice and opinion from UIS relevant to email serviceprovision, and to request additional relevant information from staff whose duties arerelevant to email service provision. It should have regard to the costs and effort of providingadditional information when making its requests.

6. The panel is entitled to request attendance at any of its meetings by UIS staff to answerquestions or otherwise facilitate the panel’s discussions.

7. The Director of Information Services will arrange for administrative support for the panel,and endeavour to enable UIS staff to attend panel discussions when requested.

Composition and meetings 8. The panel membership will consist of subject matter experts and senior technical staff from

across the Collegiate University and shall be chaired by a Member of the ISC.9. The panel will meet at least twice each term at times determined by the Chair. The Chair can

carry out panel business by correspondence between scheduled meetings.10. The panel will dissolve at the end of Lent term 2021, although this date can be varied by the

ISC.

OC/115/20

UIS Support over the Christmas closure Jon Holgate, Head of Infrastructure (UIS)

Background The UIS (and previously UCS) have provided 1st line support throughout the Christmas closure period. This is provided via the redirection of the UIS Service line telephone number to an individual’s mobile phone number. This is a duty that has been performed by various individuals on a voluntary basis, subject to availability.

24 December 2019 – 2 January 2020 During the previous Christmas closure, the redirected Service desk received a total of six phone calls. These six calls request consists of:

• A single user reported an issue with her laptop. Advice was provided to access emails from aweb-based solution.

• Five callers requested a change of password. None of these callers left contact details orsubstantiated their identities. It is believed that these were malevolent attempts to gainunauthorised access to user accounts.

Christmas closure 2018 - 2019 During the previous closure period, a single user contacted the Service desk. This was a verified user requesting a password change.

Limitations This service provides a redirect for Service desk functions. This provides some intial triaging, basic user support and account management. However, this service does not provide capability for escalation, 2nd or 3rd line support.

Proposal Within the past 12 months, much work has been undertaken by the UIS to enable self-help service for users. This includes a self-service password manager https://password.raven.cam.ac.uk/, and a service desk portal https://uniofcam.saasiteu.com/ enabling users to log incidents and access frequently asked questions.

It is recommended that the Christmas closure support service is now removed, following a lack of need. This will ease operational complexities around providing this service, allowing members of the UIS to take the necessary break from work during the Christmas period.

OC/116/20

IT Portfolio Sub-Committee

Proposed Governance framework: Background Principles

A Current situation

The IT Porfolios are a new framework for the prioritisation, resourcing and delivery of IT services, programmes and projects. In order to oversee the new framework, an IT Portfolio Sub-committee has been established, which reports to the Information Services Committee. This committee has queried whether the current system of sub-committees is structurally appropriate to support the new framework:

• some of the sub-committees do not meet frequently• others meet regularly but their business has become tangential to the decision-making

process• membership in a couple has grown so that they cannot be agile decision-making bodies• the normal reporting workflow via the Business Services Systems Sub-Committee is often

circumnavigate to expedite resource decisions.

The IT Portfolio Framework requires a supporting governance structure that will facilitate its implementation and effective delivery of services, projects and programmes.

B Review

The Secretariat of the ISC was tasked with working with Head of the Delivery Management Office and Deputy Director for Institution Liaison and Relationship Management to propose an alternative governance structure that would:

OC/118/20

• Better support the IT portfolio framework • Enable agile decision making • Facilitate consultation across the collegiate University • Allow for differences across the Portfolios • Ensure transparency • Provide oversight of the delivery of work within each Portfolio • Create a simple workflow for decision making

C Proposal

That each Portfolio establishes its own Portfolio Board, supported by advisory forum/fora. The exact structure would depend on the requirements of each Portfolio, but at a minimum it would be expected to have a Portfolio Board and a Portfolio Advisory Forum. These would replace the current sub-committees that report to the ISC. The diagram below illustrates the proposed structure for the Education Portfolio:

Information flow

Strategy

• ISC agrees overall UIS strategy. • Portfolio Board develops portfolio strategy & roadmaps in line with UIS strategy • ISC reviews and approves portfolio strategy & roadmaps

Delivery

• ISC secures UIS investment • Portfolio Board considers requests for service creation/enhancement/decommissioning • Portfolio Board determines (with input from Advisory Group) requests to be scoped • Portfolio Board determines (with input from Advisory Group) priorities • Portfolio Board works with UIS to determine scheduling options • IT Portfolio Subcommittee agrees cross-portfolio balancing and scheduling based in

limitations of UIS investment

ISC

EducationPortfolio Board

Education Portfolio Advisory

Forum

Programme & Project Boards

Research Business Systems Infrastructure

Portfolio OwnersSub-Committee

OC/118/20

The general principles for the terms of the reference and membership for the various bodies would be:

• Project/Programme Board Remit: decision making body to agree scope, objectives, benefits and direct delivery, implementation & adoption. Membership: Sponsor (usually Portfolio Lead or Service Owner), Representatives from delivery partner (UIS) and users (cross-University as appropriate)

• Advisory Forum Remit: consultative body to help inform some of the Portfolio Board’s decision making. Membership: the size of the forum would be the decision of each Portfolio Board, but would include representation from across the Collegiate University. It would be chaired by a School Secretary, who would be a member of the Portfolio Board, and its Secretariat would include the Portfolio Manager. This would provide consistency up through the structure. The absence of other members of the Portfolio Board would hopefully reiterate the consultative nature of the group. The membership is likely to be similar to the current sub-committees.

• Portfolio Board: Remit: to be accountable for per-portfolio governance, strategy, roadmap, prioritisation, budget, communication and delivery Membership:

Role title Role summary Portfolio Owner (Chair) • Articulate portfolio objectives

• Negotiate cross-portfolio changes • Secure portfolio budget and resources • Final escalation and prioritisation

Portfolio Leads(s) • Delegated authority from PfO • Recommend priorities with SO, UIS • Allocate staff to work

Service Owners • Align IT service needs with operational plans • Prioritise service requests • Ensure adoption and best use of service by staff and students

Portfolio Manager (Secretary)

• Drive delivery of portfolio • Manage resources, budget, plans • Produce portfolio Roadmap

School Secretary • Represent needs of School, Faculties and Departments • Chair Portfolio Advisory Group

College representative • Represent needs of Colleges Head of the Delivery Management Office

• Responsible for portfolio implementation and delivery management

Optionally, the Academic Secretary could be a member of some of the Portfolio Boards, in particular Education and Research. The UIS Portfolio Lead and the Head of the Delivery Management Office could be invited to observe the meetings.

• IT Portfolios Sub-Committee: Remit: to be responsible and accountable for cross-Portfolio decisions on prioritisation, budget and people allocation, Membership: no change is envisaged in the membership

OC/118/20

Role title Role summary ISC Chair (Chair) • Broker allocation of ISC-agreed investment in UIS Portfolio Owner • Articulate portfolio objectives

• Negotiate cross-portfolio changes • Secure portfolio budget and resources • Final escalation and prioritisation

Head of the Delivery Management Office

• Responsible for portfolio implementation and delivery management

• ISC: Remit to be accountable for determining the overall UIS strategy, governance and investment. (The portfolio framework touches all these areas) Membership: this is currently being reviewed, but it should be noted that the Portfolio Owner for Research is the only member of the IT Portfolios Sub-Committee who does not attend the ISC meetings.

In drawing up this structure, consideration was made of the RACI principle as a decision-making principle. The proposed structure sets out the groups / roles that are consultative, those that are to be kept informed, those that will be responsible for taking decisions and assigning tasks, and those that are accountable.

D Representation

A criticism of the current IT portfolio framework is the perceived lack of consultation and involvement of the colleges, the Schools and ourcambridge. The new governance seeks to address these through the membership of the groups.

Head of School

School Secretary

School, Faculties &

Departments

Colleges ourCambridge, non-school

ISC X 3 (or their deputies)

1 x in attendance

-- x 2 --

IT Portfolios -- -- -- -- -- Portfolio Board

-- 1 x member -- 1 x member --

Advisory Forum

-- Chair ? at least x 2 – Bursar and

Senior Tutor

at least x 1

The only body without representation from the Schools, colleges or ourcambridge is the IT Portfolios Sub-Committee. As the group’s decision-making is informed by the Portfolio Boards that has cross-representation, and is overseen by the ISC, this omission seems acceptable. Furthermore, the purpose of this group is to have frank discussion and make swift decisions. That responsibility has been delegated to it by the ISC.

OC/118/20

With four Portfolios, and the ISC, there is opportunity for all the School secretaries to be involved. It is foreseen that the Business Systems Portfolio may wish to consider having two Advisory Fora (Finance and HR), which would require two Secretaries to chair them. Consequently, both Secretaries could be members of the Portfolio Board.

E Frequency of meetings

To allow the structure to provide the agility required, it is suggested that the Portfolio Boards schedule bi-monthly meetings, ideally in the month between the IT Portfolio Sub-Committee meetings.

The Advisory Fora should meet termly, with the possibility of business being conducted remotely if a Board needed to consult quickly.

OC/118/20

Page 1 of 1

Software supported by the central software fund Author: Ian Cooper Date: 6 February 2020 Version: 1.0

Summary The following list includes both software that has been licensed in perpetuity and that which is licensed on a recurring basis:

• Abaqus• ArcGIS• Atlas RI• ChemDraw• Creo• Endnote• Genstat• IBM SPSS• Matlab• NAG• National Instruments• Nvivo• Origin• Scivener• Stata

OC/119/20

Institutional File Storage Update Chris Garrett, UIS, 31st Jan 2020

The Institutional File store is a service for departments to store and share everyday documents with colleagues. It is aimed at desktop and laptop users who access it through a mapped drive on their computer.

Since the September ISC Operations Committee meeting, information about data security classification has been clarified on https://help.uis.cam.ac.uk/service/security/data-sec-classes. Information about what the IFS provides has been improved at https://help.uis.cam.ac.uk/service/storage/ifs too, including greater detail about data protection features.

Encryption at Rest is in the process of being rolled out across all IFS volumes and will complete by the middle of February. This will protect against physical theft of hardware or attempts to obtain data from disks.

Encryption in transit is already the default option for SMB shares, but several institutions have disabled it to cater for Windows 7 hosts. With the end of support life of Windows 7 having passed, UIS will be encouraging institutions to move to using encryption in transit as soon as they are able.

Development has been ongoing on NFS/Kerberos integration and this will be available in the portal after a period of code review and testing. Work will also be done to aid institutions in setting up SMB with Kerberos.

A survey has been circulated amongst Data Owners and Data Managers, which will provide input into how the service may be improved in the future.

Finally, the IFS is included in the University’s internal audit plan for 2020. The terms of reference are being developed. The audit will look at the implementation and operation of the service.

OC/120/20

Windows 7 End of Life

Background Microsoft support for Windows 7 ended on the 14th January 2020. During the previous 6 months the UIS (and Computer Officers) from across the Collegiate University have sought to migrate as many devices from Windows 7 to Windows 10 as possible.

Data on Operating System versions is reported by the UIS Anti-Virus ePolicy Orchestrator (ePO) Server, which provides McAfee patches to connecting devices, and uses this connection to determine O/S version. It is worth noting that not all University institutions use the UIS ePO Server, and as such reports are indicative and not definitive.

Progress Significant progress across the University has been made over the past few months. Total number of Windows 7 clients has reduced from ~2,500 in September 2019, to 1,253 today. The UIS has reduced it’s supported PCs with Windows 7 from 825 to 55 over the same period. Appendix 1.

The UIS will continue to address the outstanding devices and has a plan around the migration of the remaining devices.

There is however some cause for concern with the remaining Windows 7 clients (that the UIS has visibility of), that migration is behind where it should be and will take some time to significantly mitigate the risk of running unsupported Operating Systems.

Ongoing work Beyond the migration of Windows 7 clients, there are a significant number of other unsupported O/S across the University, most notably 133 Windows Server 2008 R2. A number of these are the responsibility of the UIS and work is underway in earnest to reduce this figure. Appendix 2

OC/121/20

Windows 7 per institution

1st Level Group Number of Systems

My Organization\UL\ 244

My Organization\MRC Epid\ 223

My Organization\Churchill\ 107

My Organization\Engineering\ 66

My Organization\FitzMuseum\ 64

My Organization\CIMR\ 56

My Organization\ceb\ 55

My Organization\UIS Managed\ 48

My Organization\MRC Toxicology\ 44

My Organization\Psychology\ 31

My Organization\Physics\ 22

My Organization\Trinity\ 18

My Organization\Girton\ 18

My Organization\Chemistry\ 17

My Organization\Econ\ 16

My Organization\Queens\ 16

My Organization\Plant Sciences\ 15

Page 1 Managed Endpoint Protection Service 05/02/20 15:22

Appendix 1

OC/121/20

1st Level Group Number of Systems

My Organization\CISL\ 14

My Organization\Pembroke\ 14

My Organization\Maths\ 13

My Organization\ADC Theatre\ 12

My Organization\Vet\ 11

My Organization\CL\ 11

My Organization\Genetics\ 11

My Organization\Geog\ 10

My Organization\HSPS\ 10

My Organization\WBIC\ 9

My Organization\Architecture\ 9

My Organization\Clare\ 7

My Organization\PDN\ 6

My Organization\MRAO\ 6

My Organization\CUSU\ 5

My Organization\LucyCav\ 5

My Organization\ad (UIS)\ 4

My Organization\MSM\ 4

My Organization\Educ\ 4

My Organization\Ridley Hall\ 3

My Organization\Lost and Found\ 2

My Organization\Clare Hall\ 2

My Organization\St Edmunds\ 2

My Organization\Darwin\ 2

My Organization\Pharmacology\ 2

My Organization\English\ 1

My Organization\OIS\ 1

My Organization\botanic\ 1

My Organization\Law\ 1

My Organization\Murray Edwards\ 1

My Organization\Sid\ 1

My Organization\Land Economy\ 1

My Organization\CCI\ 1

My Organization\Criminology\ 1

My Organization\CTF\ 1

My Organization\LCIL\ 1

My Organization\Newnham\ 1

My Organization\Earth Sciences\ 1

My Organization\Human-Evol\ 1

My Organization\Emma\ 1

Total 1,253

Page 2 Managed Endpoint Protection Service 05/02/20 15:22

Appendix 1

OC/121/20

Windows 7 - new ePO

OS Type Number of Systems

Windows 10 10,348

Windows 7 1,253

Windows Server 2012 R2 227

Windows Server 2016 193

Windows 2008 R2 133

Windows Server 2019 70

Windows 8.1 19

Windows Server 2012 18

Windows 2008 9

Windows Vista 3

Windows XP 3

Windows 2003 R2 1

Total 12,277

Page 1 Managed Endpoint Protection Service 05/02/20 15:22

Appendix 2

OC/121/20

University of Cambridge

Information Services Committee

Delivery and implementation of the Digital Presence Strategy

Brief description:

The paper provides an overview of the implementation of the Digital Presence Strategy, covering:

• live and scheduled projects influenced by Digital Presence goals (early deliverables)• a delivery plan with timelines• forecasted impact on staff as the strategy is implemented

Implementation will run over four phases from January 2020, each of which will contain programmes that will influence and be influenced by each other. Delivery will be iterative and layered, i.e. not site by site in totality, but risk-based starting with institutional goals, content strategy, Information Architecture, interaction design and visual design.

Impact on staff across the University should be positive: reducing burden through the use of better tooling, access to automated content delivery and refined workflows for publishing. This is expected to allow existing web editors to invest their time in things that will have a greater benefit to them and the University: improving the quality of content.

Action(s) required:

Members are asked to: • comment on and note the presented implementation plan• endorse UIS’ proposals to bid for the funds necessary to cover additional roles to support

delivery of the strategy, as outlined in Annexe C

Other comments:

The Digital Presence Strategy was endorsed at the Committee’s October 2019 meeting (minute 392b refers).

The Digital Transformation Strategy presented elsewhere on the agenda questions whether investment should be made to create headroom by resourcing the Digital Presence Strategy as an example.

The Strategy connects with activities in ourcambridge, the Brand Strategy, Collaboration Tools Strategy (see minutes of the ISC Operations Committee, 29 October 2019), Digital Transformation Strategy, and Social Media Strategy.

List of papers submitted with this coversheet:

• Digital Presence Strategy update• Annexe A: Influenced Projects• Annexe B: Indicative Services• Annexe C: Indicative Roles and Costs

Author/originating body:

Barney Brown, Head of Digital Communications, Office of External Affairs and Communications

ISC Paper311

OC/121/20

OC/121/20

Digital Presence Strategy – November 2019 update

Early deliverables, delivery plan with timelines and impact on staff

As requested by the ISC at its previous meeting, this paper introduces: • live and scheduled projects influenced by Digital Presence goals (early deliverables) • a delivery plan with timelines • forecasted impact on staff as the strategy is implemented

It also includes as additional annexes:

• details of a proposed Digital Presence Team that will be required to deliver the strategy Live and scheduled projects influenced by Digital Presence goals (early deliverables): There are a number of live projects or projects starting soon that will benefit from adopting Digital Presence Strategy methods. These projects will test early deliverables (approaches to content, Information Architecture and design) and we will improve the production and evolution of the other deliverables of the Digital Presence Strategy based on what we learn from them. This analysis will be robust and run alongside consultation throughout the University aimed at understanding user and business requirements. These projects and other early work on the Digital Presence Strategy are shown in Annexe A. These projects will be delivered through phase one of the delivery plan. Delivery plan with timelines: We are going to implement the Digital Presence Strategy through being:

• Iterative & ‘layered’ i.e. not site by site in totality, but risk based starting with institutional goals, content strategy, Information Architecture, interaction design and visual design. Approaches that will benefit from this approach include the introduction of re-usable components and rationalising single sources of truth. As these iterative benefits become available, they will influence other work.

• Collaborative (in consultation with end users and stakeholders) • Connected (into ourcambridge, Brand Strategy, Collaboration Tools Strategy, Digital

Transformation Strategy and Social Media Strategy) We propose phases of work containing programmes that will influence and be influenced by each other as time progresses. Phase one: Mobilisation (3 months starting January 2020)

· Communicate the work of the Digital Presence Strategy across the University · Understand user and business needs · Evaluate user and business needs · Secure funds for phases two and three · Establish the governance processes through the creation of the Digital Presence

Subcommittee · Early deliverables as shown in Annexe A.

Phase two: Deliverables (6 months)

· Build the design system including standards · Establish a central capability for supporting the Digital Presence (the Digital Presence Team) · Develop common data and information architecture approaches · Establish API access to primary services and data sources (eg. Camsis, Booker, Talks.cam)

OC/121/20

· Establish processes and ways of working for new Digital Presence Team · Support and build related communities of practice · Develop training and support for web editors who will be using the new design system · Develop common analytics approaches to measuring success of websites

Phase three: Phased implementation and lessons learned (6 months)

· Establish the new business as usual · Phased introduction of automated data sources as they become available and usable · Adopt design system and Digital Presence approach throughout the cam.ac.uk central site · Begin upgrade of admissions related websites · Inform portfolio delivery · Review lessons learned from phases one to three · Review the Digital Presence Sub-Committee setup

Phase four: Rollout (ongoing to 2025) · Prioritise and upgrade remainder cam.ac.uk websites · Train and support web editors · Iterate improvements to all ongoing deliverables

Forecasted impact on staff: Phase one will be delivered with existing staff. Phases two and beyond will require the formation of a Digital Presence Team detailed in Annexes B and C. The impact on staff will be communicated clearly through a central Sharepoint site, workshops, departmental meetings and 1:1s. We don’t anticipate additional asks on the time web editors devote to managing their sites. Some of their existing burden will be reduced through better tooling, access to automated content delivery and refined workflows for publishing. This will allow them to invest their time in things that will have a greater benefit to them and the University: improving the quality of content. Any process changes that happen as a result of adopting the Digital Presence Strategy will be fully supported through training and digital support channels. As access to and display of data from common sources becomes automated through APIs, less time will be required to update websites. All web editors will be given opportunities to upskill through related Communities of Practice and additional training programmes. Decision for the Committee:

1. to endorse UIS’ proposals to bid for the funds necessary to cover the work costed in Annexe C.

Barney Brown, Head of Digital Communications

Annexe A: Digital Presence Strategy – Influenced projects Annexe B: Digital Presence Team – Indicative services Annexe C: Digital Presence Team – Indicative roles and costs

OC/121/20

Oct'19 Nov '19 Dec '19 Jan ‘20 Feb ‘20 Mar ‘20

Ongoing web projects

Intranet Projects

DPS Implementation

Annexe A: Live and scheduled projects influenced by Digital Presence goals

Key Commit to user needs

Develop internal skills and capability

Adopt an open source model

Right tool, right place, right time

Establish effective governance

08/11/2019

Design systemand patternlibrary

Implementation plan

Technology

Governance

Cam.ac.uk homepageand core landingpages

Admissionscontentstrategy

Equality and Diversity website

Creation, completion and analysis of survey

Create design system development plan Creation of  initial design system

API management layer/gateway

Identify types of data that could be automated, and sources of data

Evaluation of CMS

Review of Search – internal and External

Terms of reference and membership for Digital Presence Subcommittee

Establish annual cycle

User journey mapping, GA analysis and interpretation

IA, layouts, components and design approach

Content strategy and creation of content

Front‐end development

Map E&D presence into home page

User journey mapping for undergraduates and postgraduates

IA for undergraduates and postgraduates

Content strategy for undergraduate and postgraduate editors

Analytics design and templating

Research Office intranet

Content audit across websites, intranets and any other digital platform including Moodle, and analytics across all researcher‐facing content

Business analysis of document management and workflow process in ROO

Migration of Research Administrators’ content from ROO website to cross‐institutional intranet

Recommendation for next step for intranet

UISintranet

Business analysis of document management and workflow process in the UIS

Mapping user needs, business needs and communications priorities

Investigating use cases with departments, Colleges and NSIs – feeding into templates and collaboration tools strategy

Design system research

IA front end and document library

Workflow and process mapping

Card sorting with E&D team Content strategy

Usability testing

Workshops with CAO, GAO, departments and Colleges

Ongoing: understanding University goals for researcher‐facing web content

A process for coordinated web 

activity

Plan for cross‐institutional intranet for research administrators

Output

Journey maps, style guide, content strategy including editorial processes, standard template for analytics for undergraduate and postgraduate 

applicants

Templates for intranets; links to collaboration 

tools strategy

First iteration of new homepage and core 

landing pages

Iterative continual improvement

Communications Internal communications 

Sharepoint site detailing progress and scope

Presentations across Collegiate Cambridge

Continual updates of site with project progress

Digital Presence sessions at related communities of practice

OC/121/20

OC/121/20

Page 1 of 1

Annexe B: Digital Presence Team Indicative Service The service includes:

● Developing, supporting and maintaining the central CMS ● Developing, supporting and maintaining the Design System ● Developing, supporting and maintaining the central Intranet ● Carrying out content audits and expert reviews ● Optimising and improving University Search ● Information architecture development ● User research and testing ● Web development ● Advising on Google Analytics ● Domain name and URL advice and management ● Training and support for related Community of Practice

The website building and management service does not include:

● Updating of website / Intranet content ● Development or maintenance of websites using any technology other than the central CMS ● HTML email template advice ● Bespoke web design for non-University of Cambridge branded websites ● Social media advice

OC/121/20

OC/121/20

Page 1 of 3

Annex C: Digital Presence Team / Planning Assumptions

All figures are indicative annualised costs, but include assumed on-costs

*roles are subject to grading, but reflect market benchmarks

Purpose Role Grade Term Year 1 Year 2 Year 3 Year 4 Year 5 5 Year cost

Head of Digital Presence

User Research 8 FTC 5YR £ 59,501.00 £ 61,286.03 £ 63,124.61 £ 65,018.35 £ 66,968.90 £ 315,898.89

Support / Training 7 FTC 5YR £ 41,111.00 £ 42,344.33 £ 43,614.66 £ 44,923.10 £ 46,270.79 £ 218,263.88

Product Owner (Design System) 9 FTC 5YR £ 69,132.00 £ 70,514.64 £ 71,924.93 £ 73,363.43 £ 74,830.70 £ 359,765.70

UI/Visual Designer 8 FTC 5YR £ 59,501.00 £ 61,286.03 £ 63,124.61 £ 65,018.35 £ 66,968.90 £ 315,898.89

UI/Visual Designer 7 FTC 5YR £ 41,111.00 £ 42,344.33 £ 43,614.66 £ 44,923.10 £ 46,270.79 £ 218,263.88

Content Editor

Content Editor

Analytics & Measurement 7 FTC 5YR £ 41,111.00 £ 42,344.33 £ 43,614.66 £ 44,923.10 £ 46,270.79 £ 218,263.88

Developer 8 FTC 5YR £ 59,501.00 £ 61,286.03 £ 63,124.61 £ 65,018.35 £ 66,968.90 £ 315,898.89

Developer

Developer

Developer

Developer 8 FTC 5YR £ 59,501.00 £ 61,286.03 £ 63,124.61 £ 65,018.35 £ 66,968.90 £ 315,898.89

Developer 8 FTC 5YR £ 59,501.00 £ 61,286.03 £ 63,124.61 £ 65,018.35 £ 66,968.90 £ 315,898.89

Senior User Research / IA 10 0.5 FTC 1YR £ 38,965.00 £ 38,965.00

Senior Designer 10 0.5 FTC 1YR £ 38,965.00 £ 38,965.00

Content Strategist 10 0.5 FTC 1YR £ 38,965.00 £ 38,965.00

(SUB) TOTAL £ 606,865.00 £ 503,977.78 £ 518,391.97 £ 533,224.48 £ 548,487.58 £ 2,710,946.80

Digital Presence

OC/121/20

Page 2 of 3

Divisions providing support / related skills

Product & Service Design UIS Communications Team Mid Range Development OEA&C

User Research UIS Communications Drupal Social Media

UX Designers Sharepoint Branding & Imagery

Content Designer (writer) Funnelback

Product Designers (TBC)

Data Analysts

Business Analysts

OC/121/20

Roles over time

OC/121/20

OC/121/20

University of Cambridge

Planning and Resources Committee

Digital Presence Strategy Implementation Programme

Summary:

The Planning and Resources Committee are requested to consider the scope and benefit of the Digital Presence Strategy Implementation Programme proposed: Phases 1 to 4, with a view to allocating the requested funding for its delivery (as outlined in the Full Case) under the direction of the Information Services Committee (ISC).

The Digital Presence Strategy outlines an approach to change the way that the University’s online presence is projected, providing for universal accessibility, user centred design, and single re-usable sources of information, in a sustainable, scalable and adaptable environment.

Funding for the proposed phases is requested as part of the proposed recalibration of the University’s Capital Fund, which will include provision for prioritised investment in IT systems, infrastructure and strategic initiatives.

Action requested of the PRC:

The Committee is asked to approve the proposal.

Additional comments:

This proposal has the support of the Information Services Committee (19/11/2019). It supports the delivery of the Digital Presence Strategy which the same committee signed off (10/10/2019).

Next steps:

Approval of funding will result in the Programme commencing starting with the assembly of the Digital Presence Team and beginning work on the design system and pattern library. This will result in the start of delivery of scalable, sustainable and future proof ways of building University websites from the end of 2020 with continuous delivery from that point forward.

Author/originating body:

University Information Services

Annex(es):

Digital Presence Team Indicative Roles and costs

PRC 2148

OC/123/20

OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 1 of 15

University of Cambridge: Planning and Resources Committee Capital Projects Process

Full Case

Project Name

Digital Presence Strategy Implementation Programme Phase 1 – Discovery and mobilisation Phase 2 – Alpha Phase 3 – Beta Phase 4 – Live and ongoing evaluation

CPP file reference

Project ID

Department / School / Institution University Information Services

Department Lead / Representative User Barney Brown Head of Digital

Communications

Head of Department / Institution Ian Leslie, Director of UIS

Head of School N/A

Estimated capital cost of project £3.05M

Endorsements

Department / Institution

This proposal has the support of the Information Services Committee (19/11/2019). It supports the delivery of the Digital Presence Strategy which the same committee signed off (10/10/2019).

Programme Board Progress towards delivering the Digital Presence Strategy will be monitored by the Information Services Committee.

School N/A

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 2 of 15

Matters for Decision

The Planning and Resources Committee are requested to consider the scope and benefit of the Digital Presence Strategy Implementation Programme proposed: Phases 1 to 4, with a view to allocating the requested funding for its delivery (as outlined below) under the direction of the Information Services Committee. Funding for the proposed phases is requested as part of the proposed recalibration of the University’s Capital Fund, which will include provision for prioritised investment in IT systems, infrastructure and strategic initiatives. The Planning and Resources Committee is invited to: 1. Approve this Full Case and commission the Information Services Committee to

oversee and manage the delivery of the proposed programme. 2. Approve the funding proposal, including:

- A contribution of £3.05M from the Capital Fund

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 3 of 15

1. Executive Summary

Our current digital presence (2,600+ websites) does not represent our position as a world-leading institution. This is evident through the monitoring of competitor websites’ evolution and recorded perceptions of users of cam.ac.uk. It neither reflects an institution that is committed to widening participation nor meets the needs of people with disabilities. It puts the Collegiate University at increasing risk due to the changing legislative landscape (e.g. General Data Protection Regulation (GDPR) and the Competition and Markets Authority (CMA).) The CMA is there to ensure that we provide accurate information about our courses to applicants. We potentially fail to do this when we have out of date, incomplete or inaccurate information on our websites. Any of our sites that collect personal information must do so within GDPR legislation. The more disparate ways of collecting information we use, the higher the risk of contravening this law. The lack of consistent support for the current proliferation of websites and information hinders the Collegiate University’s ability to adapt, innovate and improve efficiency while maintaining accessibility, security and legislative compliance. Through an improved adequately resourced digital presence the Collegiate University aims to:

1. Provide information, support and services that are easy to discover and use for everyone irrespective of the devices they use, or the routes to information that they take.

2. Ensure the experience of interacting with the Collegiate University through its digital presence reflects its mission. The Collegiate University’s digital presence needs to be able to keep apace of its competitors to support the ongoing engagement of researchers (from grant application to data preservation), students (from pre-applicant to alumnus), teachers, professional staff, donors and the wider public community.

3. Ensure authoritative, single sources of data that are maintained and correct. 4. Deliver solutions that are sustainable, scalable and adaptable for an ever-changing

environment. We aim to be equipped to adapt to the devices and routes that users use and take to access information which will change in the next 5 years.

The Programme has been initiated after the production and delivery of the Websites at Cambridge report in September 2018 and as a response to the Digital Presence Strategy being signed off by the Information Services Committee in October 2019. Digital Presence Strategy https://www.governance.cam.ac.uk/committees/information-services/2019-10-10/MeetingPapersandDocuments/ISC302%20Digital%20Presence%20Strategy.pdf

2. Purpose and Scope

The Programme will focus on delivering on the following strategic activities: 1) Commit to user needs

a) Publish consistently designed and written content, that meets users’ needs, enabling them to complete tasks and make informed decisions quickly and easily.

b) Place equal emphasis on the needs of our users, in addition to those of the organisation to help the Collegiate University provide information, support and services that are easy to discover and use.

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 4 of 15

c) Introduce a User-Centred Design (UCD) approach. This is the process of developing the user interface of a website or application, from the perspective of how it will be understood and used by its intended users.

d) Regularly measure and report whether the experience for users of our websites is improving.

e) Deliver and maintain a cohesive user experience by meeting conventions and existing best practice in the production of content e.g. writing for the web and meeting usability standards.

f) Organise information consistently and based on evidence from research with users to make our websites easy to navigate and to improve search across our digital estate (by exploiting the power of new technologies).

g) Commit to making digital content accessible to any user regardless of device used or their physical or cognitive ability.

2) Establish effective governance a) Form a Digital Presence Sub-Committee initially under the Information Services

Committee with ongoing authority over the University’s digital presence with a tightly defined remit and membership with specific duties and authority.

b) Create a common analytics policy and templated reports (initially using the Google Analytics product) to assist in the creation of objective evidence to report to the Sub-Committee.

c) Help Heads of Departments and other University institutions make responsible management decisions about their websites by providing meaningful data about what’s working and what could be improved.

3) Develop internal skills and capability a) Establish standards and expected skills for web content authors and web editors

across the University along with associated training programmes that help them attain these.

b) Support related Communities of Practice such as the Content Community and Technology Community.

c) Create standard job templates or sections of standard job templates which support various levels of web editor and author.

4) Right tool, right place, right time a) Provide a secure, stable layer of infrastructure to operate and connect digital services

that can be ‘mixed and matched’ as and when required to provide all the necessary elements of our websites. Provide ongoing long-term support for these infrastructural elements to ensure that they are secure, free of bugs and continually evolving to meet the changing needs of the Collegiate University.

b) Develop and maintain a design system and pattern library (which can be used to create branded user interfaces, standardised components and web templates for University apps and websites) which will improve efficiency through service reusability. This system and library will be formed from a well-designed set of components that work seamlessly together, individually or in arbitrary groups to create templates for the vast majority of digital content. The components will be simple to use, well documented, supported, sustainably enhanced and improved to ensure that they continue to meet the needs of the community.

c) Establish common sources of information which are well defined and documented, including policies for their use. These data services must provide accurate and

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 5 of 15

definitive data to Collegiate University consumers and hence must provide well documented and secure Application Programming Interfaces (APIs – allowing system to system communication) access to any supported data, a well understood authorisation model with appropriate levels of granularity and business support for correcting errors in the source data. Changes should be tightly controlled given the expected dependencies placed upon the various elements.

d) Speed up tasks, reduce the opportunity for error and free up people to perform other, more rewarding tasks through the introduction of more automation of the collection and re-use of data as content.

e) Make as many of our web authoring and editing tools self-service to reduce the administrative burden on central resources and reduce the time our users need to wait to access the data they need.

f) Continue to provide a central web authentication system, which should be extended to support authentication of people external to the Collegiate University. Adopt this as the standard authentication mechanism for all Collegiate University websites and other digital presences and make any authentication by alternative means an exception. If a single system cannot cover the entire Collegiate University, then establish a prioritised list of preferences.

g) Use the right tools effectively to optimise and reduce the environmental impact of our digital presence from production to consumption. Seek to assess this through the measurement of our digital carbon footprint.

h) Adopt appropriate cloud technologies to enhance and protect our digital presence and increase speed of access for most content consumers.

5) Adopt a collaborative development model a) Actively encourage, via the Technology Community and other related Communities

of Practice contributions to the infrastructural and design domains from technical experts across the Collegiate University and foster the growth of that same technical expertise in others.

b) Support a central service for code collaboration, testing, deployment and re-use which would house various digital presence assets such as the pattern library, API code, CSS etc.

c) Support code sharing and collaboration across the Collegiate University, making all code public unless there are specific, signed-off licensing terms that prohibit it.

3. Justification

Failure to exploit the transformative power of digital technology is a known risk within the University and delivering the Digital Presence Strategy is a key mitigator against this. Continuing to maintain and develop our collective presence of over 2,600 websites with our current methods and approaches will see the University continue to fall behind its competitors and fail to meet the needs of both its users’ and business objectives. In addition, the University will be unlikely to meet requirements for digital inclusivity (accessibility). Sampling of expenditure on external digital agencies last year showed that the University is already outsourcing at least £200K a year on web projects without measuring effectiveness of spend. The total cost of collective outsourcing is unknown but is likely to be much higher than that. Vice-Chancellor’s Priorities - The Programme will enable the University’s digital presence to support several of these priorities, namely:

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 6 of 15

• Building on continuing efforts to promote greater diversity of gender, race and ethnicity through better training for web editors and clearer methods of building and promoting websites.

• Continuing to signal clearly that Cambridge is open, global and seeking robust and meaningful partnerships outside the UK through clearer communication online.

• Ensuring the Cambridge brand is appropriately promoted and protected around the world through strengthening it through our own channels.

• Seeking greater efficiency through shared administrative services where appropriate without reducing effectiveness by developing re-usable web components and design systems.

ourcambridge initiative – This Programme will also significantly contribute to the ‘Supporting our Staff’ and ‘Simplifying our Processes’ themes within ourcambridge. It will do this through consistent ways of bringing together and supporting web editors from across the University helping them work smarter and giving them the tools and software they need to do their jobs.

4. Outcomes and Benefits

The following deliverables are proposed from this Business Case:

• A supplemented central team of experts who will lead on the development and evolution of University web templates and supporting design systems

• New governance processes for building websites to make them more robust and relevant

• Managed common data and information architecture approaches (to make our websites and how we build them more consistent)

• A design system including standards for University websites

• Early deliverables as per Section 6: Figure 1 (see below) e.g. a new home page for the University

• New channel for supporting web editors around the University who build websites

• An up to date and then periodically refreshed record of user needs (needs of people who use our websites)

• An up to date record of business needs (why we need websites and what we hope them to deliver for the University)

• API access to primary services, student and staff data and data sources from respective services (e.g. CamSIS, Booker, Talks.cam)

Delivery of the full Digital Presence Strategy Implementation Programme will enable the University to adopt a new business as usual for digital delivery of channels and content. Benefits and outcomes from delivery of this Programme are as follows by activity area. Alignment with other organisational strategic objectives and initiatives is also referenced below:

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 7 of 15

# Deliverable Phase Business Outcome Business Benefits How Measure Business Benefits? 1 Analysis of user

needs 1 Greater knowledge and understanding of key

user journeys and tasks and digital expectations of users regardless of their physical or cognitive abilities

– Quality of service – Brand protection – Revenue generation – Legal/regulatory compliance

– Increased user satisfaction as a result of using our websites – Higher completion rates for core tasks, including sales and applications – Enhanced perception of the Cambridge brand by third parties – Websites meeting accessibility standards

2 Analysis of business needs

1 Greater understanding of what the University needs from its digital presence in order to deliver its mission and strategic objectives

– Quality of service – Brand protection – Revenue generation

– Higher conversions for applications – Higher rate of achievement of business goals – Positive feedback from business stakeholders

3 Establish Digital Presence subcommittee

1 Governance and steering for our digital presence, with representation from across Collegiate University

– Legal/regulatory compliance – Risk mitigation (cost avoidance) – Operational efficiencies (due to consistency and standards)

– Avoidance of GDPR/CMA fines – Measure levels of compliance

4 Establish governance framework and policies for websites

1 Coordinated implementation of the Digital Presence Strategy

– Legal/regulatory compliance – Risk mitigation (cost avoidance) – Operational efficiencies – Brand protection

– Avoidance of GDPR/CMA fines – Greater alignment of web-related processes

5 API Management Platform

2 Provision of a single source of truth where data automation is possible

– Legal/regulatory compliance – Operational efficiencies – Brand protection – Environmental

– Improved responsiveness and speed of delivery of digital services – Increased process efficiency – Greater re-use of digital presence assets – Fewer manual errors

6 Provision of stable and secure infrastructure for digital services

2 Reliable, robust and secure platform – Legal/regulatory compliance – Operational efficiencies – Brand protection – Environmental

– Improved responsiveness and speed of delivery of digital services – Increased process efficiency – Increased security

7 Creation of design system

2 Consistent interactions across our digital presence and continuous improvement and deployment to web interfaces

– Legal/regulatory compliance – Operational efficiencies – Brand protection – Cost savings (agency fees)

– Improved speed of delivery of digital services – Increased user satisfaction – Greater re-use of digital presence assets

8 Information architecture & taxonomy

2 Websites that are easily navigated and content that is findable and searchable

– Legal/regulatory compliance – Operational efficiencies – Brand protection – Cost savings (agency fees)

– Improved speed of delivery of digital services – Increased user satisfaction – Greater re-use of digital presence assets

9 Creation of a Digital Presence Team

2 A centre of excellence which supports local digital teams

– Quality of service – Operational efficiencies – Brand protection – Environmental

– Increased user satisfaction – Strive to reduce the carbon footprint of our digital presence – Reuse of local expertise

10 Training and support for staff involved in website creation and maintenance

2 Ensuring the ongoing quality of our digital presence and the wellbeing of staff associated with this field

– Quality of service – Staff wellbeing – Operational efficiencies

– Staff surveys – Greater diversity of gender, race and ethnicity represented in our digital presence – Greater re-use of digital presence assets – Increased level of digital expertise centrally and locally

11 Provision of standard website analytics

2 Enabling an evidence-based approach to website design and development

– Quality of service – Operational efficiencies

– Increased user satisfaction as a result of using our websites – Higher completion rates for core tasks, including sales and applications – Enhanced perception of the Cambridge brand by third parties

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 8 of 15

5. Financial Appraisal

Phase 1: Discovery and mobilisation (including costs for delivery and associated roles for year one) would require seed investment of £402,470 in the form of:

• Short term contract costs (£156,806) to cover user research, information architecture, design and content strategy

• Internal resource (£209,076) to cover product ownership, visual design and development.

• Programme support and non-pay costs (£36,588) to cover software and hardware costs as well as event and communication costs for supporting the programme

Phase 2: Alpha, programme cost for Year 1 would be £377,681:

• Staff costs as per Annexe A: £326,035

• Programme support and non-pay costs (£51,646) to cover software and hardware costs as well as event and communication costs for supporting the programme

Phases 3 and 4: Beta and Live, programme cost for Years 2-5 would be:

• Average annual staff costs as per Annexe A: £516,466

• Programme support and non-pay costs (£51,646) to cover software and hardware costs as well as event and communication costs for supporting the programme

These figures are based on the staff and associated non-pay costs required to deliver the programme as detailed in section 6.

6. Programme

We are going to implement the Digital Presence Strategy through being:

• Iterative & ‘layered’ i.e. not site by site but risk based starting with institutional goals, content strategy, IA, interaction design and visual design.

• Collaborative (in consultation with end users and stakeholders)

• Connected (into ourcambridge, Brand Strategy, Collaboration Tools Strategy, Digital Transformation Strategy and Social Media Strategy)

We propose phases of work containing programmes that will influence and be influenced by each other as time progresses. This will result in an iterative process to delivering the Digital Presence Strategy as opposed to a single final unalterable set of solutions. The more we test and roll out approaches to evolving our digital estate, the more we will learn about what works and what doesn’t therefore we will reprioritise work as it progresses. We can then refine and improve the templates and components we produce as part of this programme. Discovery and mobilisation Conducting User Research to understand user needs and business goals. Establishing required governance and recruiting team to deliver Alpha. Alpha Developing and testing prototypes with small user groups. Internal engagement and involvement with internal stakeholders.

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 9 of 15

Beta Developing and testing at larger scale. Making test versions available to external users until confident we can run at scale. Live and ongoing evaluation Continue to iterate and improve based on user feedback. Sustainably supporting service delivery across the University.

Phase one: Discovery and mobilisation (3 months starting January 2020)

• Understand user and business needs • Begin auditing content. • Begin creation of Information Architecture and Taxonomy (for web, intranet and

documents) • Improve copy across core landing pages of cam.ac.uk • Establish Digital Presence Subcommittee and Digital Presence Programme Board • Secure funds for Phases 2 - 4 • Setup Digital Presence site • Build and release Beta version of Homepage

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 10 of 15

Figure 1: Digital Presence Strategy Implementation Programme deliverables. All activities iterate and improve throughout and beyond the programme.

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 11 of 15

Phase two: Alpha (6 months)

• Ongoing usability testing and consultation

• Build an Alpha version of the design system including standards • Continue auditing content

• Continue creation of Information Architecture and Taxonomy (for web, intranet and documents)

• Develop common data and information architecture approaches

• Improve access to University data sources

• Evaluation and development of CMS strategy

• Develop common analytics approaches to measuring success of websites

• Establish a central capability (Digital Presence Team)

• Establish processes and ways of working for the Digital Presence Team

• Support and build related communities of practice

• Communicate Digital Presence Programme across the University

• Iterate and improve homepage • Release live version of homepage

• Begin training and support for web editors

Phase three: Beta (6 months)

• Iterate and improve the design system

• Test and iterate design system and Digital Presence approach across the cam.ac.uk central site

• Phased introduction of automated data sources

• Review lessons learned from phases one and two

• Review the Digital Presence Sub-Committee setup

• Train and support web editors • Iterate and improve homepage

Phase four: Live and ongoing evaluation (ongoing to 2025)

• Roll out and iterate UX, design and branding through design system

• Prioritise and upgrade remainder of sites

• Iterate and improve common data and information architecture approaches

• Train and support web editors

• Iterate and improve homepage

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 12 of 15

Programme Organisation (Programme Board to be discontinued upon completion of Programme)

Digital governance. Translation of strategy into policy, procedure, process.

Oversight of implementation and delivery.

Strategy and direction.

Delivery accountability.

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 13 of 15

7. Post-programme

UIS will support the Digital Presence Team from its recurrent resources through efficiencies gained through the Digital Presence Strategy Implementation Programme. The Digital Presence Programme Board will discontinue but the Digital Presence Subcommittee (or its evolved or repositioned form) should be retained.

8. Dependencies and related projects

The Brand Strategy and production of refreshed Brand Guidelines are required in order to inform the look and feel of the design system and develop content creation guides. Interaction with the Collaboration Tools Strategy will help inform better ways of working with internally focussed information that until now has been published on external facing websites. The technology approach that the programme adopts to deliver the new Digital Presence will be in line with and rely on the University’s Cloud strategy and API data management platform. Costs for these two initiatives are funded outside of this programme however, the programme may incur costs of £85,000 from year 3 onwards due to pricing tiers within the API management platform agreement. We recommend the University embarks on developing a Search strategy to improve the business-critical service that users in and outside the University use to find digital content from webpages to documents. The current implementation of Funnelback (our search engine) needs reviewing as it is not fit for purpose.

9. Mitigating University risks

The following table summarises risks from the University Risk Register and how delivery of the Digital Presence Strategy Implementation Programme can help mitigate against them. Risk Likelihood

(H/M/L) Impact (H/M/L)

Mitigation

1: Failure to be financially sustainable as a leading global institution.

M H A Collegiate University managed design system and pattern library will reduce expenditure on outsourced website design and build projects. Reducing administrative burden on central resources through improvements to self-service.

2: Failure to maintain and protect our infrastructure as fit-for-purpose, now and for the future.

M H Acting on ongoing objective analysis of our digital presence’s performance. Blocking websites which are compromised. Providing a secure and stable

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 14 of 15

Risk Likelihood (H/M/L)

Impact (H/M/L)

Mitigation

infrastructure for the Collegiate University’s digital presence. Well defined and documented data sources.

3: Failure to adapt to the transformative power of digital technologies.

M H A pattern library and design system managed by a dedicated team of specialists. Support and training for the technical skills needed to evolve and develop the pattern library. Integration of systems using supported APIs leading to data quality improvements and more efficient use of staff time.

4: Failure to communicate effectively with the Cambridge community.

L M Support for communities of practice which help the Cambridge Community communicate more effectively using the Collegiate University’s digital presence.

5: Failure to maintain our administrative processes and structures as fit-for purpose, now and for the future.

L H Support for staff development through Communities of Practice appropriate for web editors. The creation of standard job templates or components of job templates relevant for web editors, authors etc.

6: Failure to be an inclusive and diverse University.

L H Adherence to the Web Content Accessibility Guidelines 2.1 AA standard improves access to our websites for everyone including people with impairments to their vision, hearing, mobility or cognition.

8: Failure to articulate our contribution to society.

H H A simple to use and well-designed set of components used to create websites which are usable.

9: Failure to ensure our people feel valued

M H Support for Communities of Practice. Automating repetitive tasks where possible to free web editors up to be better used and developed.

PRC 2148OC/123/20

DRAFT Full Case Capital Projects Process Digital Presence Strategy Implementation Programme Template Version: Feb-17

cpp_full_digital_presence_strategy Page 15 of 15

10. University Policies

Staff review and development https://www.hr.admin.cam.ac.uk/policies-procedures/staff-review-and-development Computer facilities, email and the internet https://www.hr.admin.cam.ac.uk/policies-procedures/computer-facilities-email-and-internet Data protection policy https://www.information-compliance.admin.cam.ac.uk/data-protection Equal opportunities policy https://www.hr.admin.cam.ac.uk/policies-procedures/equal-opportunities-policy Research policy https://www.admin.cam.ac.uk/offices/research/research/Good_Practice.aspx Web accessibility policy http://www.cam.ac.uk/about-this-site/accessibility Use and misuse of computing facilities https://help.uis.cam.ac.uk/policies/governance-and-policy-documents/use-and-misuse-of-computing-facilities University of Cambridge Access and Participation Plan 2020-2025 https://www.undergraduate.study.cam.ac.uk/files/publications/university_of_cambridge_app_2020_25.pdf

Appendix A – Digital Presence Team Indicative Roles and costs

PRC 2148OC/123/20

Digital Presence Team / Planning Assumptions

All figures are indicative annualised costs, but include assumed on-costs

*roles are subject to grading, but reflect market benchmarks Divisions providing support / related skills

Purpose Role Grade Year 1 Cost Term Yr1 Yr2 Yr3 Yr4 Yr5 5 Year cost Role Grade Cost Term Product & Service Design UIS Communications Team Mid Range Development OEA&C

Head of Digital Presence Senior User Research / IA 10 £ 39,438 0.5 FTC 1YR User Research UIS Communications Drupal Social Media

User Research 8 £ 60,227 FTC 5YR £ 60,227.00 £ 62,033.81 £ 63,894.82 £ 65,811.67 £ 67,786.02 £ 319,753.32 Senior Designer 10 £ 77,930 1 FTC 1YR UX Designers Sharepoint Branding & Imagery

Support / Training 7 £ 41,954 FTC 5YR £ 41,954.00 £ 43,212.62 £ 44,509.00 £ 45,844.27 £ 47,219.60 £ 222,739.48 Content Strategist 10 £ 39,438 0.5 FTC 1YR Content Designer (writer) Funnelback

Product Owner (Design System) 9 £ 69,973 FTC 5YR £ 69,973.00 £ 72,072.19 £ 74,234.36 £ 76,461.39 £ 78,755.23 £ 371,496.16 Product Designers (TBC)

UI/Visual Designer 8 £ 60,227 FTC 5YR £ 60,227.00 £ 62,033.81 £ 63,894.82 £ 65,811.67 £ 67,786.02 £ 319,753.32 Data Analysts

UI/Visual Designer 7 £ 41,954 FTC 5YR £ 41,954.00 £ 43,212.62 £ 44,509.00 £ 45,844.27 £ 47,219.60 £ 222,739.48 Business Analysts

Content Editor £ - £ - £ - £ - £ - £ -

Content Editor £ - £ - £ - £ - £ - £ -

Analytics & Measurement 7 £ 41,954 FTC 5YR £ 41,954.00 £ 43,212.62 £ 44,509.00 £ 45,844.27 £ 47,219.60 £ 222,739.48

Senior Developer 10 £ 78,876 FTC 2YR £ 78,876.00 £ 81,242.28 £ 160,118.28

Developer 9 £ 69,973 FTC 5YR £ 69,973.00 £ 72,072.19 £ 74,234.36 £ 76,461.39 £ 78,755.23 £ 371,496.16

Developer £ - £ - £ - £ - £ - £ -

Developer £ - £ - £ - £ - £ - £ -

Developer £ - £ - £ - £ - £ - £ -

Developer 9 £ 69,973 FTC 5YR £ 69,973.00 £ 72,072.19 £ 74,234.36 £ 76,461.39 £ 78,755.23 £ 371,496.16

SUB TOTAL £ 535,111 £ 535,111.00 £ 551,164.33 £ 484,019.71 £ 498,540.30 £ 513,496.51 £ 2,582,331.86 SUB TOTAL £ 156,806 1YR uplift

AVERAGE ANNUAL COST £ 516,466 per annum TOTAL £ 2,739,138

Digital Presence

PRC 2148OC/123/20

WirelessServiceConnectivityProblems18/10/2019Mark Chaney

Background

At approximately 10.55 am on the 18/10/19 client connections to University Wireless services dropped significantly. This was resolved at approximately 11.40am.

TimelineofEvents

Date/Time Description

18/10/19 10.55 (approx.)

Client connections to University Wireless began to drop significantly.

11:07 Service Status Line set to Amber

11:30 Major incident declared

11.40 (approx.)

Clients were successfully authenticating and receiving Wireless Services again and client numbers returned to normal.

Communications

UIS Comms sent a message on the 18/10/19 at approximately 12.10 outlining the earlier outage and explaining that we were investigating the cause.

Investigation

The various Wireless systems and system logs were checked in an attempt to find a cause of this unexplained outage. At present, the cause is unknown.

RemedialActions

The cause is still unknown and unexplained. However, we are reviewing the appropriate system logs and consulting with the equipment vendors as appropriate.

OC/124/20

WirelessServiceStabilityProblems23/10/2019–13/11/19Alexander Cox

Background

At approximately 10.55 am on the 18/10/19 client connections to University Wireless services dropped significantly and this was resolved at approximately 11.40am. (This incident is covered by the previous report). Aruba Networks (our wireless equipment vendor) TAC continued to work in the background with the Wireless Team to understand the cause of these problems, including onsite TAC engineers from the 21/10/19

This issue reoccurred at approximately 11am on the 23/10/19. Aruba TAC (who were previously investigating these issues) elevated their response level to the highest priority within TAC and Aruba Engineering.

TimelineofEvents

Date/Time Description 18/10/19- 21/10/19

The issue on the 18/10/19 was attributed to (seemingly) random issues with client devices unable to form secure tunnels to the wireless controllers. The issue was traced to whitelist synchronisation problems across the cluster and manually repaired and the problem reported to Aruba TAC. This affected clients randomly but not on all connected devices, including devices owned by the same user.

Aruba TAC continued to work in the background on the issue alongside the Wireless Team to understand the cause of the whitelist synchronisation problems, which included onsite TAC engineers from the 21/10/19.

23/10/19

11.00 (approx.)

11.07

Aruba Engineers remain onsite

Client connections to University Wireless became unstable again and new investigations began.

Wireless Service status set to Amber.

Previous issue with whitelist synchronisation was found to have reoccurred. Additionally, an issue with abnormally high ARP traffic was identified (each ‘rogue’ device creating tens of thousands of scans per 30 seconds), which caused traffic policing to occur on the controllers. This massively contributed to the system instability.

OC/125/20

11.41 A Comms message was sent to IT community advising them that investigations are ongoing and that we are blacklisting (blocking) devices creating large amounts of ARP traffic because this is degrading the Service. Service Desk advised that blacklisted users will start contacting them and what measures need to be taken to remedy the situation.

24/10/19 11.39 13.00 (approx.) 20.30 21:00 22:30

Aruba Engineers remain onsite An IT Service Status message was distributed outlining the action the team were to undertake to deploy (new) temporary fixes ahead of a permanent code update from Aruba. We began to deploy mitigations (to resolve the reoccurring whitelist synchronisation problem) ahead of the code update but this was halted as system instability increased. An additional issue with 802.11r protocol was identified that caused increased system instability. It was later identified that although 802.11r was turned on across the cluster some of the controllers had the protocol activated but some did not, this would manifest in device connection problems The 802.11r protocol was turned off in the system configuration and a controlled sequential reboot of the controllers within the primary cluster was initiated to make sure the 802.11r protocol deactivation status was synchronised across the all the cluster members. It was considered that the system was back to operating normally. However, as client numbers are lower in the evening, we left the status monitor set to amber and would verify the system status under full load.

25/10/19 09.51 09.56 10.19 13.12

Aruba Engineers remain onsite and close monitoring of the system continued. UIS Comms distributed a message explaining the previous day’s efforts and that we now believed the system was now stable. Reports began to be sent from University Institutions of further problems. A further message from UIS Comms was circulated indicating we are aware of further issues. Further investigations began, which identified that although the controllers now had 802.11r disabled correctly not all access points had picked up the configuration change. A phased and controlled reboot of all access points was carried out to make sure all configuration was synchronised. A message from UIS Comms to the IT community, was distributed to state that the Wireless System should now be stable. It was decided to keep the system at amber status over the weekend.

OC/125/20

28/10/19 13.03

After verifying normal operation over the weekend, the service status was set to Green.

28/10/19- 13/11/19

Stability was maintained by the Wireless Team continually monitoring the system and making adjustments to maintain service. The Wireless Team and Service Desk continued to monitor and assist with remedying blacklisted devices for excessive ARP scanning. Several software packages have been identified as the cause of the issue. UIS Comms distributed communications containing mitigating action that can be taken to disable or remove the software.

13/11/19 Wireless code updated successfully to a custom-built code from Aruba mitigating 3 of the 4 issues.

19/11/19 (planned)

A Wireless controller (uws-mc-a9) previously removed from the primary wireless cluster will be reintroduced as now identified as a software fault fixed by the custom code.

CommunicationsMessages were distributed via UIS Comms and the ITSS as indicated in the timeline.

Investigation Issues Identified relating to whitelist synchronisation problems (fixed) Aruba Bug ID Description AOS-185904 Whitelist DB sync not consistent across all the MD's in the cluster AOS-185977 Random Heartbeat misses on the cluster with 5 controllers AOS-185920 Aruba7240 controller keeps rebooting due to “Nanny Rebooted Machine –

fpapps process died” and crashed on pubsub, cfgm, syslogdwrap, aaa and nanny module

802.11r Issues (unfixed but disabled) AOS-196043 802.11r synchronisation not consistent across controllers and access points ARP scanning Issues Devices excessively ARP scanning while connected to the Wireless Service are being blacklisted to prevent system instability.

RemedialActions

• Aruba OS custom-build code was deployed to fix whitelist synchronisation issues on the 13/11/19

• 802.11r remains disabled pending a code fix • Devices excessively ARP scanning while connected to the Wireless Service continue to be

blacklisted. The Service Desk, Wireless Team, and local IT continue to take remedial action and have identified several software packages that are conducting excessive ARP scans.

OC/125/20

MoodleAnti-virusandUnisonissue–2ndJan2020Erica Bithell/Shaun Pullen (acting on behalf of/covering for Jessica Comber-Chaney).

Background

On Thursday 2nd January at about 18:00, one of the pair of production web servers (Bohr) for the VLE Service performed an unplanned/unexpected restart due to a reboot of its host server. The reboot of the host server is outside the scope of this incident write up.

Upon the VLE Server restart two things failed:

• ClamAV (Anti-virus checking software) started, but due to a permissions issue (manual permission change required on restart), it could not correctlyperform virus scans.

• Unison (the software used to keep the pair of the production web servers in sync - PDF's, word docs etc.) restarted, but the process ran for an unusuallylong time without completing normally. No errors were recorded.

Behaviour presented to the users:

• From 18:00 on Thursday 2nd January until around 09:40 on Friday 3rd January, users uploading files to Bohr received error messages and were informedthat their files had viruses (due to the anti-virus failing to scan the file properly, and thus the file being reported to have failed with a virus). This will have included some students with assignment deadlines on January 2nd and 3rd.

• In addition:• Some users (mainly staff) may have experienced an error message when attempting to view previously-marked assignment submissions for

grading • A very small number of users (including students) may have found that downloaded files were empty. This should only affect files that were

uploaded to bohr between about 09:25 and 09:35. Only five files could be identified that came into this category. • Both of these issues:

• Only affected files which had been uploaded after about 18:00 on Thursday January 2nd, or assignments marked after that time• Only occurred if the user accessing the file was using the opposite server from that which had been used when the file was originally uploaded, or

assignment viewed • Moodle availability:

OC/126/20

• Moodle was always available to both staff and students, and only a handful of users experienced an issue with either uploading of some files, or downloading of some files, and only then if the user happened to access Moodle using the affected server.

Data loss:

• No data loss occurred, because all files were always present on at least one server and the database always knew about these files regardless of the server.

Return to normal service:

• At 9:31 on the 3rd of January the Anti-virus issue was resolved and users no longer received any anti-virus errors when uploading. • Errors concerning missing downloadable files resolved 08:50 6th Jan 2020.

Major incident:

• This was not a major incident, and no major incident was declared.

TimelineofEvents

Time/date Event Notes & follow-up

17:57 02 Jan 2020

Last successful operation recorded in unison log on bohr

Before 17:58

bohr rebooted

18:08 02 Jan 2020

First clamscan error message received by Moodle Admin mailbox

Connecting to Unix domain socket resulted in error No such file or directory

OC/126/20

(2)

20:06 First user emails the Moodle Helpdesk reporting a virus scan error message for a file he knows to be uninfected.

In total, six users will email the Helpdesk (3 academics, 1 student, 1 administrator, 1 computer officer) to report or inquire about this issue.

20:24 02 Jan 2020

Jessica Comber-Chaney messages BA, EB and RA on Slack to alert them to quantities of virus scan failure messages that were being received

08:30 03 Jan 2020

EB commented out the unison entry in root's crontab on bohr to prevent an uncontrolled re-start of the process.

A unison process was still running, and functional tests suggested that files were being synced between the two servers, but nothing was being written to unison.log

08:42 03 Jan 2020

Service status line set to amber

Message:

One of our two Moodle servers is having an issue with its automatic virus scanning software, preventing some users from uploading files. We will issue an update on the situation at 11:00

08:59 03 Jan 2020

EB emailed infra-sys@uis.cam.ac.uk and infra-

Bohr rebooted at about 18:00 yesterday evening, and we have a repeat of the previous issue with virus scanning and unison replication.

OC/126/20

fw@uis.cam.ac.uk to request:

• fixing ClamAV log file permissions

• taking bohr off the load balancer while unison sync returns to normal

** Please could someone in Infrastructure take bohr off the load balancer, so that users are directed only to moodle-live1? **

So far, I have done the following:

• Set the service status line to amber, promising an update at 11:00 • Stopped the unison cron on bohr by commenting out its crontab entry. There is a unison process already running

(visible using “top”) and I’d like to see that complete properly before re-enabling it in the crontab. There have been no unison log entries since 17:57 yesterday.

We also need to:

• Fix the permissions on the ClamAV log file on bohr so that its virus scanning starts to operate again (this one for Infrastructure please)

• Review the status of the unison sync (this one for myself and Infrastructure jointly)

09:31 03 Jan 2020

BA fixes ClamAV permissions

Last antivirus notification received by Moodle Admin mailbox.

09:40 03 Jan 2020

Bohr taken off load balancer

All users now on moodle-live1. Normal user experience resumed but at reduced resilience.

09:45 03 Jan 2020

BA killed all unison-related processes and did a clean start from the unison crontab

BA believes that unison was syncing, but had lost the inode reference for its log file.

Subsequent check of moodledata/filedir suggests that the unison sync was proceeding until around 09:34, but may not have been fully up to date.

09:50 03 Jan 2020

Service status line updated

Message:

The issue with virus scanning has been resolved. Moodle is now operating normally, but with reduced resilience while we deal with content re-synchronisation.

OC/126/20

09:55 03 Jan 2020

Messages sent by the Moodle Helpdesk to the Moodle mailing list and Moodle Coordinators

Moodle: Virus scanning issue 2-3 January 2020

Dear Moodle users,

Between 18:00 on 2 January and 9:30 on 3 January, one of our two Moodle servers had an issue with its automatic virus scanning software. This would have prevented some users from uploading files and possibly downloading some content.

This issue has now been resolved. Any users who received error messages that their files contained viruses should now be able to upload their documents to Moodle.

If you are still experiencing problems, please contact the Moodle Helpdesk.

We apologise for any inconvenience caused.

Please contact the Moodle Helpdesk via moodlehelp@uis.cam.ac.uk if you have any questions.

11:30 03 Jan 2020

Statistics gathered on files potentially affected by this incident

select component, count(*) from mdl_files f where timemodified > unix_timestamp("2020-01-02 17:45:00") and timemodified < unix_timestamp("2020-01-03 09:45:00") and filearea <> "draft" and filearea <> "recyclebin_course" and filearea <> "cachedassets" and filename <> "." group by component ;

Component File count

assignfeedback_editpdf 964

assignfeedback_file 3

OC/126/20

assignsubmission_file 37

core 6

mod_data 8

mod_folder 95

mod_resource 20

mod_turnitintooltwo 2

Without having undertaken a detailed analysis, it is clear that the content sync between the servers is not completely up to date. There are files present on each server with timestamps from the impacted period that are not present on the other. However the most likely situation in which users would experience unexpected results would be in the assignment pdf annotation tool, which accounts for 85% of the files. Any of these that were generated on bohr might not have been synched to moodle-live1 and will present as blank pages at this point in time, until the unison sync has caught up.

08:50 06 Jan 2020

• Unison checked and sync up to date

• bohr reinstated on traffic manager

• bhr sanity checked for upload, download & virus scanning

System behaving as expected

08:55 06 Jan 2020

System status set to GREEN

Incident over

OC/126/20

Investigation

• Logs accessed and checked, found to be Clam AV issue – reoccurrence from previous action • ClamAV permissions re-applied • Unison logs checked, found to be replication issue. • Server taken off of load-balancer, Unison stopped and restarted, pause for resync to occur. • Files not present on both servers checked.

RemedialActions

• ClamAV start-up script altered to ensure permissions set when server restarts – to be tested during server patching by Mid Feb • Unison issue cannot be resolved due to the limits of the server architecture. Base issue will be addressed with move to Cloud project and the

redesign of the service architecture.

OC/126/20