E-CRB System specification

Transcription

1 On behalf of Bi or Tri Borough CRB Partnerhip Appendix A E-CRB System specification July 2012

2 Requirement Scope Functional Requirements Validation of Application Data Processing of Applications User Administration and Record Keeping Reporting, Alerts and Communication Access Restrictions and Security Data Protection Technical Requirements Infrastructure and Connectivity Post Go Live Security and Integrity Licensing Performance and Reliability System Development System Support and Maintenance General Requirements Training

3 Requirement Scope 1. The Royal Borough of Kensington and Chelsea Council (RBKC) are requesting quotations on behalf of the Bi or Tri Borough CRB Partnership ( The Partnership). RBKC is the lead borough of the Partnership, which may include the London Borough of Hammersmith and Fulham, and Westminster City Council. The Partnership will be registered with the CRB when a decision is made by each partner as to whether to proceed, following receipt of the quotations. The Partnership would want to enable access to the system for the countersignatories from each partner. 2. The Partnership would want to be able to offer the following via the system with immediate effect. a. An Umbrella Body service to other organisations, in the public, private and a Voluntary sector. Functional Requirements 3. The supplier MUST be a registered e- broker with the CRB, and be Ministry of Justice compliant with ISO The system MUST provide a facility for employees and volunteers as well as Public, Private and other organisations to complete an online application form containing all the fields required by the CRB check together with an Independent Safeguarding Authority (ISA) barred list check.

4 5. Applicant MUST be able to access the online application form with a temporary login and password generated by the system. Would the system generate a reminder? Who can reset forgotten passwords? 6. The system MUST provide applicants with notice on use of the system that they are required to accept before they can commence completion of the online application form. The wording of this notice to be supplied by the Partnership. 7. The system MUST require a separate login by a Registered Identity Checker (RIC), using their usual login and password details, to complete the Section X [apply for a CRB check] (ID) documents check data. 8. Applicant must be able to save the application form. 9. Password MUST be set-up to expire, not to allow access after 3 failures, allow users to change and configure them as well as requiring them to be 8 characters which must include at least one number. 10. The online application form MUST be continuously maintained in line with any mandatory changes required by the CRB including any additional requirements.

5 11. Organisation name to be recorded onto the system automatically as determined by the RIC login, but will flexibility to amend so RICs can cover for other partners if necessary. Validation of Application Data 12. The system MUST validate and ensure that the mandatory fields are completed and within defined criteria. Where mandatory fields are incomplete or outside set criteria, the user cannot finalise the application and is prompted to input the missing or corrected data. 13. The system MUST cross check ID documents against data input by applicant for inconsistencies. Where inconsistencies are found there MUST be the ability for the RIC or HR to cancel the application and where necessary a fresh application is able to be commenced. Countersignatory should also receive a notification to alert the inconsistencies. 14. Validation MUST be built into the system so the ID document section contains an appropriate number and combination of ID documents including prompts that date of birth and address details have been checked by the RIC. 15. The system MUST ensure that applications cannot be submitted by the applicant or RIC until all inconsistencies between applicant input data and ID document data are resolve, all mandatory information is complete and ID check data is validated.

6 Processing of Applications 16. The system MUST have the functionality for a Countersignatory to review basic application details including name, date of birth, organisation, position, and volunteer (yes or no), National Insurance Number (NiNo) and MUST have the ability to cancel an application and not transmit it via the e- Bulk service. 17. The system MUST enable the Countersignatory to access sufficient data from each application to carry out a check against ISA barred lists before transmission to the CRB through the e-bulk system. The data required is as set out at 16 above. 18. The system MUST incorporate a further stage of electronic data capture, before transmission via the e-bulk service to include relevant countersignatory details determined by the countersignatory login. 19. The system MUST enable transmission to the CRB, via the e-bulk system, of batches of applications, in accordance with the requirements specified by the CRB, following approval by the Countersignatory. 20. The system MUST enable transmission to RBKC, LBHF, WCC and any other organisation of data received from the CRB, via the e-bulk system, of completed Disclosures. 21. The system MUST ensure the data is securely transferred between all authorised parties to the level specified by the Home Office under the CRB e-bulk terms and conditions.

7 22. The system MUST enable completed disclosure information received via the e-bulk system to auto populate relevant fields on the tracking information to include date of issue and disclosure number and to indicate if a hard copy disclosure has been issued to the registered body. User Administration and Record Keeping 23. The system MUST have the ability for the Partnership Countersignatories to set up each Public, Private or Volunteer organisation separately and define levels of access so that only the tracking information relating to that school or organisation s applicants can be viewed by them, with ALL countersignatories being able to access all tracking data and search across their organisation. 24. Countersignatories MUST also be able to remove or suspend access. 25. It MUST be possible for Countersignatories to search for an applicant by name, date of birth, NiNo or Disclosure number. 26. Information showing progress from the CRB tracking service MUST be incorporated against each applicant s summary that can be viewed by the RIC and Countersignatories. This MUST be auto-generated via a link between the system and the CRB tracking service. 27. The system MUST hold standard letter templates that will merge with applicant data and can be printed or ed by RIC s or by

8 countersignatories. Wording of templates to be provided by the Partnership. 28. It MUST be possible for each partner to be able to amend standard letter templates and upload these to the system. 29. The system MUST have the facility for the countersignatory to make notes in a free text field regarding queries for each application and the ability to flag or pause an application for further attention. Reporting, Alerts and Communication 30. Countersignatories MUST have the ability to run standard reports from the system to monitor the CRB process including outstanding applications (where either the applicant or RIC section has not been completed) or Disclosure not issued by CRB (to include Countersignatory defined date range of when sent or transmitted to CRB) 31. There MUST be the ability for countersignatories to obtain user defined reports from the system. This needs to cover all standard and complex reports currently available via the current systems. i.e. managers, head teacher, senior managers reports. 32. Report MUST be made available in Excel formats including CSV to facilitate transfer into council s HR system and other organisation and to enable back-up data to be retained.

9 33. The system MUST have automatic alerts for RIC s and countersignatories by partner to highlight outstanding applications, at predetermined intervals. Access Restrictions and Security 34. There MUST be a management (audit) trail of activity within the system including automatic generation of RIC name in section X based on user login details. 35. Data captured on the system MUST be held securely, for all Public, Private and Voluntary organisations with access limited to authorised users via login and password, as determined by each partner. Data MUST be held in accordance with the CRB Code of practice and e-bulk requirements. Data Protection 36. The system MUST comply with data protection guidelines. 37. Each partner MUST be able to monitor archived records within the system and where required, after retention periods are met, be able to delete?. 38. System Control and administration features MUST have a full audit trail so that changes to the configuration can be audited. Suppliers MUST provide an overview of this functionality.

10 Technical Requirements Infrastructure and Connectivity 39. The supplier MUST be able to host the necessary servers for the system or provide server capacity in a suitable environment. If any third party supplier is involved in the provision of such services, the supplier MUST provide full details of those other suppliers. 40. Public, Private and Voluntary Organisations PC s will vary in their capacity and specification. Tenders MUST advise if there are any minimum system requirements and applications required to access their system and perform the required functionality as stated at section 1 above. 41. Supplier MUST detail any integration capabilities with other software applications including the HR system, document management systems and any other HR systems in use. For RBKC this is Northgate Resourcelink, LBHF use Midland itrent and WCC use Oracle. 42. Network Security the system MUST prevent unauthorised access to stored data through any network attached components. Please describe in a method statement how the system is protected from network intrusion in terms of application security and password protection, whether access limited to known/defined IP addresses, firewalls and intrusion detection systems in place etc. 43. The supplier MUST provide/evidence: Location of data centre and specification of environment; How the server environment is protected and backed up; How long backups are retained for and where held, how data would be restored in the event of an incident; In the event of a catastrophic

11 incident, restore time to normality; In the event of accidental data loss, extent of loss if notified within the hour and period to recovery. Post Go Live 44. Supplier MUST include details of support and maintenance arrangements for the products and services they intend to supply as part of the proposal in the first and subsequent years. 45. Suppliers should define their software release strategies, including for example; fixes, patches, distribution methods, minor upgrades and major upgrades. Suppliers should be prepared to outline their long term product development and investment strategy. Security and Integrity 46. The supplier MUST detail the licensing options and arrangements for the systems, including any restrictions of numbers of users able to access the system at any one time. Licensing 47. The supplier MUST detail the licensing options and arrangements for the systems, including any restrictions of numbers of users able to access the system at any one time. Performance and Reliability 48. The system MUST be able to accommodate the volumes processed ( 8599 if all 3 councils opt to use this system) and cope with monthly and seasonal

12 variations in applications without performance reductions. In 2011 RBKC processed 2495 CRBs, LBHF 3204 CRBs and WCC 2900 CRBs. The cost per transaction in the pricing matrix should be based on these volumes. 49. The system MUST be scalable and able to cope with the possibility of adding volumes from other organisations. The supplier must provide details of any maximum number of organisations that can be held on the system and any maximum number of applications that can be held against each organisation. 50. The supplier MUST provide details of any maximum number of users that can access the system at any one time and whether there are any activities with will affect user access and use of the system. In particular, whether there will be any deterioration to the user service levels during backups or other system administration activities. System Development 51. System amendments MUST be made free of charge to comply with any legislative changes or changes required by the CRB that affect the CRB disclosure and e-bulk service. System changes MUST be in place to coincide with the enactment of statutory provisions and MUST be in accordance with any requirements specified by the CRB. 52. The specification is written whilst awaiting full information about the creation of the Disclosure and Barring Service and implementation for the Protection of Freedom Act The system must be able to comply with these requirements.

13 53. They supplier MUST indicate its acceptance of the need to maintain its system by applying relevant software upgrades, patches and fixes, in a timely manner. System Support and Maintenance 54. The supplier MUST describe the support and maintenance arrangements for the proposed system. General Requirements Implementation The supplier MUST provide an indicative plan for implementation setting out the organisation resource assumptions. The supplier MUST outline their approach to testing of the solution including provision of a test plan. The supplier MUST work within the Partnerships implementation schedule to commence with testing of the E-CRB system from mid- October 2012, with a go live date (for specific pilot areas) from mid January Training The supplier MUST describe the training that will be required for all system users and detail the options for delivery e.g. online learning. The supplier MUST state the amount of training time each Countersignatiory and each RIC will normally require to become fully proficient on the system. The supplier MUST describe the training documentation it will provide.

14