TECHNOLOGY POLICY SUMMARY FOR THIRD PARTY SUPPLIERS

Size: px
Start display at page:

Download "TECHNOLOGY POLICY SUMMARY FOR THIRD PARTY SUPPLIERS"

Transcription

1 TECHNOLOGY POLICY SUMMARY FOR THIRD PARTY SUPPLIERS RATIONALE Group Policy Rationale This Policy has been designed to assist in managing the risk that: The Group fails to simultaneously deliver Technology which meets customer expectations, supports Group strategy and complies with all applicable laws and regulations. The overall risk includes the following high level risks: Policy Risk 01 - The risk that the Group fails to govern its Technology in line with corporate governance requirements, Group strategic objectives, legal and regulatory requirements. Policy Risk 02 - The risk that the Group fails to build or acquire technology that meets customer expectations, supports Group strategy and complies with all applicable laws and regulations. Policy Risk 03 - The risk that the Group fails to maintain availability of IT services that meets customer expectations, supports Group strategy and complies with all applicable laws and regulations. Policy Risk 04 - The risk that the Group fails to correctly operate the processes that underpin the delivery of IT services. Whilst related, the risk that the Group fails to protect information from unauthorised disclosure, modification, or corruption and applications/systems being compromised is managed by the Information & Cyber Security Policy Customer Impact The Group s vision is to be the best bank for customers. The Technology Policy supports this vision and the aim of providing investors with strong, stable and sustainable returns by: Provision of the right structure and execution of governance to enable the customer impacts of technology risk to be assessed and addressed. Ensuring the customer impacts of IT risks are mitigated through having effective systems, controls and processes in place. Ensuring the customer impacts of IT events are effectively identified and managed through appropriate systems, controls and processes. Supporting operational efficiency which delivers good customer outcomes. SCOPE The IT Disaster Recovery requirements of this third party summary of the Group Policy apply to all suppliers who are hosting technology used by the Group. All other requirements apply to suppliers who are hosting bespoke technology off Group premises where the third or fourth party is managing the implementation of controls. This includes suppliers providing an externally managed cloud service, Page 1 of 6

2 including Software as a Service (SaaS), Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Only those key controls relevant to the technology services being provided to or for the Group need to be operated. The following suppliers/services are out of scope of this summary: Third party suppliers where they are acting as a Technology Provider to or for the Group, and their technology is hosted on Group premises where LBG are managing the implementation of controls. (Note - Suppliers whose technology is hosted on Group premises are in scope if they have remote access capability.) Third party suppliers providing externally hosted (off premise) Commercial Off The Shelf Technology (COTS). LBG internally managed cloud services. LBG public cloud (shared infrastructure with logical separation between clients) where LBG are managing the implementation of controls. MANDATORY REQUIREMENTS GENERAL Suppliers must: Governance Ensure that all elements of technology supporting Group services, including downstream supplier relationships, comply with contractual agreements and schedules of work. Ensure that technology processes, applications and systems are compliant with local, international, statutory, legislative, contractual and regulatory requirements. Build Demonstrate that applications / systems are designed, developed, tested and implemented in accordance with the Group s requirements. Ensure that knowledge and information to support processes is accurately documented and made available to the Group on request including technical documentation, user manuals and recovery processes. Operate a Standard for managing the implementation of all types of technology change which includes documenting, impact assessing and approving all IT changes, including emergency, to ensure that they meet contractual requirements and do not negatively impact systems and services. Ensure that an IT service management application/tool is used to manage all IT changes. Ensure that appropriate implementation and back-out plans are in place and tested before promotion to live/production for all services operated on behalf of the Group. Ensure new implementations or significant changes to Group hosted applications/systems complete IT Disaster Recovery (ITDR) proving, including LBG connectivity, prior to release into live/production to evidence the recovery objectives Page 2 of 6

3 can be met. The Group s Supplier Manager or relevant Business contact must be advised so that they can engage appropriate resources within the Group Availability, Performance and Recovery Define, prioritise, regularly monitor and maintain IT services to ensure resilience, minimising potential disruption to Group services. Support continuity and recovery of service by ensuring that IT hardware and software are kept at version levels that allow the Group and the supplier (as per contractual obligations) to support, maintain, secure and/or patch where required. Implement processes to manage incidents and problems including trend analysis in line with service level agreements with the Group. This should include reporting incidents experienced with other clients that may be common across the technology provided. Implement ITDR requirements based on the required availability of the system/application, as directed by the Group s Application Owner. Applications/systems that are critical (break the service chain) to a Group Critical Business Process must be hosted in a data centre. The Supplier must perform, as directed by the Group s Application Owner, proving of ITDR capability on target recovery infrastructure. Proving is required to evidence that recovery can be achieved in line with the objectives i.e. that the Recovery Time Capability (RTC) and Recovery Point Capability (RPC) meet the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) specified by the Group. ITDR capability and proving frequency requirements must be detailed in the contract for provision of the system or application. The Supplier must notify the Group s Supplier Manager or relevant Business contact of any failed Disaster Recovery Proving so that non-compliance to ITDR requirements can be notified to the Group s Application owner, and this must be retested successfully within 3 months of the failure. Operation Create and maintain an up-to-date and accurate record of technology assets (for example: hardware, software, licences, source code and versioning). Clearly document key IT resources (services, assets, people) and capabilities which should be mapped to the to the services being provided to the Group. Create and maintain an inventory of configuration information aligning with the relevant change and configuration management processes associated with providing contracted services to the Group. Ensure procedures are in place for the design, development and scheduling of batch jobs. Ensure a process to monitor the creation, prioritising, scheduling and execution of batch jobs and associated alerting is in place. Ensure capacity management processes including configuration are in place. Ensure maintenance of IT systems and assets in accordance with the supplier s recommended service intervals and specifications or other requirements as agreed Page 3 of 6

4 with the Group. DEFINITIONS Technology Provider Data Centre Recovery Time Capability Recovery Point Capability Recovery Time Objective Recovery Point Objective Any person or group responsible for the development, implementation, maintenance or management of technology hardware, software and infrastructure systems. For the purposes of this policy, this is a Lloyds Banking Group owned or managed data centre, or a supplier owned or managed data centre as agreed with the Group. The amount of time taken to switch from the primary system to a disaster recovery system from the point of recovery invocation The amount of data loss measured in time following the failure of a system The time required to switch from the primary system to a disaster recovery system from the point of recovery invocation. The acceptable amount of data loss measured in time following the failure of a system KEY CONTROLS Control Title Control Description Frequency Technology solutions are developed in accordance with Group requirements Sign off from the Group is obtained for technology solutions prior to implementation for Group Separate test environments are established services An environment definition document (or equivalent) and a master test plan (or equivalent) are in place for projects impacting Group services A readiness check is by the environment owner to confirm that the functional test environment is reflective of the live environment or a justification for it not reflecting live is documented Functional and nonfunctional testing is Technical support documentation Functional and non-functional testing (to documented requirements) for projects impacting Group services is Test plans must be formally documented and approved prior to the commencement of testing Technical documentation, user manuals recovery processes etc. for all Group services exists and Page 4 of 6

5 are reviewed on an annual basis or following a change Change standard and A standard for managing the tooling implementation of technology change is in place and is reviewed annually An IT Service Management application or tool is used to Implementation and back out plans for technical change Emergency change An IT incident management process is fully implemented manage technology changes All technical changes for Group services have an approved implementation and back out plan An emergency change process is documented Emergency changes are approved as per process A process for Incident Management is documented All incidents are logged, prioritised and assigned to the relevant teams for timely response and investigation Incidents are tracked to resolution based on severity Problem trend analysis is Currency management procedures are in place Hardware and software inventories are in place Batch jobs are created, prioritised and scheduled A process for Problem Management is documented Trend analysis is conducted for recurring problems on Group contracted services and progress on remediation documented and is tracked. A Currency Management process (hardware and software) is defined and reviewed annually All Group supporting applications/systems currency is reviewed in accordance with the process All currency issues are logged and tracked to remediation An asset inventory is in place which is updated following technology changes and contains configuration data, age of systems, and type of vendor support The inventory is reviewed on an annual basis Ensure procedures are in place for the design, development and scheduling of batch jobs impacting Group services Monthly Page 5 of 6

6 Alerts are prioritised and configured in line with alerting requirements Monitoring of the creation, prioritising, scheduling and execution of batch jobs must be in place Alert monitoring requirements are defined and approved Configure and prioritise alerts in line with defined requirements Ensure continual monitoring of alerts for all Group systems is in place and issues are identified and tracked to resolution Capacity management procedures are in place and executed Proving programme for critical systems and core technology infrastructure in line with the proving schedule A Capacity Management process, including configuration, must be documented, approved and reviewed annually Capacity Management processes must be operating for Group systems, with alerts managed and trend analysis RTC and RPC for the system has been published by the Supplier RTC & RPC meet RTO & RPO requirements as specified by the Group MANDATORY REQUIREMENTS NON-COMPLIANCE Any control failures or material differences between the requirements set out above and the supplier s own controls should be raised by the Supplier with the Group s Supplier Manager or relevant Business contact. The Supplier Manager or relevant Business contact will then discuss the non compliance with the Accountable Executive for the relationship and local Risk team to agree way forward. Version Number Effective Date th November th July 2018 Next Planned Revision: July 2019 Page 6 of 6