果冻传媒

6. Disaster Recovery

• Network asset owners must ensure that Disaster Recovery (DR) plans are in place for any and all assets within their remit, ensuring continuity of critical network functions in the event of major disruption or system failure.
• DR plans must define recovery objectives, including Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
• DR tests must be conducted at least annually to validate recovery arrangements, verify documentation accuracy, and identify improvement opportunities.
• Any lessons learned from DR tests or live incidents must be incorporated into updated plans.
  
  

7. Resilient Network Design

• Resilience principles must be embedded into network architecture, ensuring that single points of failure are avoided wherever technically and financially feasible.
• Core services(routing, switching, firewalls, DNS, DHCP, VPNs)must be deployed:
  • in redundant configurations that support fail over and high availability.
  • across geographically dispersed locations to ensure service continuity during localised outages.
• Connectivity to the Internet and to critical systems (including cloud services) must be supported by diverse network paths, reducing the impact of upstream provider or equipment failures.
• Logical and physical segregation must be complemented by resilient inter鈥憇ite connectivity and redundant power, cooling, and physical controls.
• Resilience considerations must be included in project design stages and validated through technical review prior to go鈥憀ive.
• Critical configurations, topology information, firewall rules, certificates, and routing tables must be backed up securely and regularly, stored in protected locations separate from production systems.
• Network devices must be configured according to the requirements of IMST 10 Secure Configuration Standard.
  
  

8. Network Monitoring

• All network monitoring activity must comply with IMP 12 Investigation of Digital Systems and Communications.
• Network monitoring capabilities must provide visibility into performance, availability, and security across all on鈥憄remises and cloud鈥慴ased network components.
• Monitoring systems must be configured to detect:
  • Unusual traffic patterns or anomalies
  • Denial鈥憃f鈥慡ervice indicators
  • Configuration drift
  • Device failures or environmental alerts
  • Loss of equipment resilience or redundancy
  • Capacity
• Alerts generated by security-monitoring systems must be reviewed immediately and escalated according to the University鈥檚 incident management process.
• Monitoring data must be secured, access鈥慶ontrolled, and retained in line with applicable legal and policy requirements.
• Monitoring tools must under go regular review to ensure they remain effective against evolving threats and technology changes.
  
  

9. Secure Network Tools

• Only tools approved by IDG, or teams to whom such responsibility has been delegated, may be used to manage, test, administer, or analyse the University network. These include:
  • Configuration management tools
  • Monitoring and logging platforms
  • Diagnostic and packet鈥慳nalysis tools
  • Automated deployment/orchestration platforms
  • All networking hardware
• Tools must be:
  • Kept up鈥憈o鈥慸ate with patches
  • Securely configured
  • Restricted to authorised users
• Use of penetration鈥憈esting, scanning, or traffic鈥慽nspection tools require approval from the Information Security, Risk and Compliance (ISRC) team.
  
  

10. Remote Access

• Remote access to administrative interfaces of network services is only permitted where necessary and must use:
  • Encrypted channels (e.g., VPN, SSH, TLS鈥慴ased management)
  • Approved devices that meet security baselines including having Multi-Factor Authentication (MFA) enabled.
  • Management interfaces which support MFA must have it enabled.
• Direct access from the public Internet to administrative ports or management GUIs must be blocked, unless explicitly approved with documented risk mitigation. Network areas hosting administrative ports or management GUIs must be protected with MFA.
• Remote access permissions must be:
  • Regularly reviewed
  • Removed when no longer required
  • Logged and monitored for unusual activity
• Cloud-management portals must follow similar controls, applying conditional access, IP allow鈥憀isting where possible, and secure identity governance practices.

11. Exceptions

11.1 under this policy must be submitted to the CRISO or their designate. Authority to approve exception requests is delegated to the Information Risk and Compliance Team. Activities that have received prior approval by the Research Governance and Ethics Committee will be exempt, but the CRISO must be notified.

11.2 This policy may have an impact on users of assistive technology or assistive software dependent on circumstances. These individual cases will be considered on a case-by-case basis.

12. Compliance Monitoring

12.1 All members of the University are expected to comply with this document as part of the Information Management Policy Framework (IMPF). Where breaches of the IMPF present a significant risk, including those falling under Regulations鈥痑nd Regulation鈥�, they will be subject to the appropriate student or staff disciplinary procedure or applicable contractual terms for staff not employed directly by the University or contractors.

12.2 It is the responsibility of all members to report any instances of non-compliance to the Information Risk and Compliance Team. This can be done via the鈥�. This team monitors adherence to the IMPF using reported data and other available tools.

12.3 Where issues require escalation or further review, they will be referred to the Information Security and Data Protection Committee via the Chief Risk Information & Security Officer (CRISO) and include either Conduct and Resolution Team or Employee Relations Team, as appropriate.

Amendment History:鈥�鈥�鈥�鈥�