PIP Tender documents – Document 4 Part 5 (unredacted because the DWP are incompetent)

(Information Provided Courtesy of Soiniciulacht)

Tender Document 4

Redacted name: Mark Shrimpton, Director of Services & Information at DRUK

Redacted name: Paul Stanfield, who will fill the key role of Account Director

Redacted name: Louise Edwards, Reed in Partnership

Redacted: annual turnover of £2.93 billion. During this period of growth we have managed to consistently grow our profit margins to £385m in 2011

Redacted: the newly acquired Medicals Direct Group (being announced this month)

Redacted: Sourcing the working capital and financing repayment
Capita, similar to most multi-national companies, operates a central financing model, under which funding is raised centrally and provided to group operating companies as required. This allows the group to raise funding in the cheapest and most efficient manner. Funding is raised centrally via multiple sources, including:

equity (Capita plc shares are quoted on the London Stock Exchange)

bonds (typically issued in the US Private Placement market), and

bank credit facilities (including a Revolving Credit Facility of £425m).
Capita normally funds capital expenditure, associated non-capitalised set up costs and day-to-day working capital across all contracts from these central sources of finance. In some instances the high equipment content of certain contracts may be funded through operating leases, the cost of which is expensed through the profit & loss accounts over the contract life.
For PIP the overall working capital requirement for Lot 2 is £16.6m. The funding for this requirement will be provided from the group’s central financing arrangements as described above. Currently, as a result of the arrangement of a term loan of £285 million in February 2012 and equity issuance of £274 million in April 2012, Capita has substantial cash on deposit (in excess of £200m) and unutilised available bank revolving credit lines of £425 million. This £625 million of headroom is more than sufficient to support the PIP contract’s funding requirements incorporating much more than the 25% stretch requested.
Furthermore, Capita generates substantial operating cash flow (over £350 million pa). Liquidity and funding levels are forecast and checked regularly as part of a monthly process, to ensure there is sufficient headroom to cover ongoing needs. Extra funding is arranged and bonds issued as necessary to operate within the group’s policies and covenants. There are no major bond maturities falling due for refinancing in the next few years, with only £123m maturing in the next three years.
Within Capita we rigorously monitor our capital expenditure. The group’s aim as stated within our annual report and accounts is to contain our capital expenditure at or below 4% of

Redacted: revenue. In 2011, we met this objective, with net capex at 3.5% of annual revenue (this equated to 3.6% in 2010). We believe capex at or below 4% is sustainable for the foreseeable future. There are currently no indications of significant capex requirements in our business forecasts or bid pipeline, however, we do not constrain ourselves in the case of exceptional opportunities and will use this financial strength as needed. The PIP opportunity is one of those opportunities for which we will flex this requirement, but the overall Group’s capital target will remain within the 4% maximum limit. (It is also worth noting that we have included a ‘conservative’ 8% cost of money within our prices to the DWP in order to provide a single price per assessment without any upfront charges.)
In summary, the level of risk associated with sourcing the working capital and financing repayment is very low.

Redacted: HeART (Health Assessment & Reporting Tool) which includes WARP technology, a part Capita owned solution that is a leader in report writing software for HPs

Redacted: Given the mandated use of Citrix, data will need to be manually keyed from PIP CS to HeART during this period, as screen scraping technologies (which otherwise would provide an efficient

Redacted: method of transfer) are unlikely to be reliable in a Citrix environment.

Redacted: (information appears to have been correctly redacted)

Redacted: (appears to have been correctly redacted)

Redacted: HeART will be subject to the full accreditation process and we will secure the data using an EAL accredited encryption product. When the assessment data is generated it will be temporarily stored on the hard disc of the offline laptop, synchronised with the central HeART system and subsequently deleted from the local hard disc.
In principle this technique is no different from generating reports locally using any other tool (e.g. Microsoft Word) except it provides a more reliable method of carrying out assessments which are underpinned by formal XML structures. Access control for the laptops used by assessors, will be via 2 stage authentication using key generation devices, using the same level of security as the “tokens” that will be supplied by DWP at a later stage, in order to enable access to the online assessment tool. The archiving and removal process for this assessment data will be agreed with the DWP security accreditor. In order to transmit the reports securely to the DWP prior to the availability of the online assessment tool, we will agree an encryption format and secure transmission mechanism (e.g. SFTP, PGP) as a method of ensuring data is received as transmitted with no en-route tampering or unauthorised access.

Redacted: Assist UK’s CEO, Alan Norton

Redacted: Account Director, Paul Stanfield

Redacted: Paul

Redacted: Head of Implementation and Programme Management, Steve Patison

Redacted: Steve

Redacted: Account Director, Paul Stanfield

Redacted: Paul Stanfield

Redacted: Linda Roberts, CEO of WIRED

Redacted: Sir Graeme Catto, chairman of our Governance committee

Redacted: (table appears to have been correctly redacted)

Redacted: Steve Patison

Redacted: such as integration with Transport Direct for the provision of personal route maps from claimant homes to centres

Redacted: Professor Sir Graeme Catto

Redacted: see below page 57

Redacted (pages 54-57):

Input/Output/Handoff System Mechanism – Automated/Manual
Claim Referral Capita HeART (Health Assessment & Reporting Tool) Communications link via DWP (and DSD) network to Capita MPLS network. Manual rekeying of PIP CS items
Triage Capita HeART Carried out using automated rules based algorithms plus manual review and verification
Further Medical Evidence Capita HeARTCTDS ServiceDWP Scanning Request raised by HeART and Capita Total Document Solutions (CTDS) generate document for FME supplier. FME scanned by DWP (Balfour Beatty) into Document Repository
Scheduling Appointments Capita HeART plus Graticule Generates appointment letters supplemented by SMS reminders (Capita SMS bureau)
Assessment Report DWP Provided Keyed directly into DWP online assessment tool. During “clerical period”, keyed offline into Warp (PIP Report Format) and then transferred to DWP.
Assessment Summary PIP CS Entered directly into PIP CS. Possible later automation
MI/BI SQL Reporting Services Offline copy of HeART database generated overnight to provide source for MI reporting. Telephony system supplements SLA reporting
Payment of HPs Capita HeARTSAP All HP details are stored on HeART with details of assessments. SAP will make payments to contract assessors and FME providers via AP module or via SAP Payroll for permanent staff
Schedules and work Allocation for medical assessors Capita HeART Expert Administration System (EAS) We will utilise the existing synchronisation interface to download this data to HPs laptops. We will disable the generation and subsequent upload of medical reports as this will be replaced by the DWP report tool
Claimant Expenses Capita HeARTBACS Claim entered into HeART (including bank account details). Receipts scanned and linked. Selective verification/payment via Capita BACS
Travel directions Transport Direct Facility for public sector travel: home to centre.
Bulk Printing CTDS Existing secure service provided across Group
Complaints HeART Details logged on system/actioned via workflow

Physical connections – all Capita systems described above and illustrated in the diagram will be hosted in our secure production and DR data centres with secure links between. The interface with DWP will be via a dedicated network link.

Our Core System: HeART – there is considerable commonality between the IT platform required to support the PIP assessments and that currently deployed in Capita Health & Wellbeing to deliver administrative functionality for our Medico Legal and Occupational Health businesses. This means that there is relatively little development work required to create a version to support the PIP service. The system provides end to end case management via a workflow engine allowing for proactive management of cases through to completion. At the core of the platform is a Microsoft Dynamics CRM instance. Document storage is facilitated by the use of a Microsoft SharePoint instance.

At the heart of the system is an advanced appointment selection engine that allows management of HP and venue resource availability. The appointment search facility can also take into account ‘advanced’ requirements such as expert gender or personal specialisms (e.g. to speak languages). The core CRM application is synchronised with an offline application called the Expert Administration System (EAS) to remotely administer any cases for which they are providing medical reports.

b) System Changes & Enhancements

An agile scrum test-driven framework will be used during development and testing. This produces fully tested and documented incremental components of the system in 3 week cycles to UAT, including deployment and data migration scripts. Continuous integration of code and unit tests will ensure the integrity of components between changes. In addition, automated testing after every deployment will ensure continuing operation of the overall system on all environments. All code will be stored in a Microsoft TFS repository, which will allow tracking of every component version in each release. TFS allows branching and merging of code for multi-phased development enabling parallel working and reducing the overall timescale. Automated TFS builds will ensure system integrity.

There will be daily integration of code into the System Test (including Model Office) environment followed by automated testing. On a three-weekly cycle, fully tested components of functionality will be delivered to the secure Pre-Production environment for UAT. A set of test scripts will be created and executed against all delivered functionality. Prior to go live, there will be a longer period of end-to-end UAT including full regression testing of all system functionality including completion of the security accreditation process. The Pre-Production environment will also be used for training and penetration testing as the infrastructure configuration will be similar to production. Solution phases will be deployed to production, and penetration, performance, volume and resilience testing will be performed. To minimise disruption, production deployments will be scheduled outside normal working hours.

It is envisaged that there will be one major release followed by patch releases (red process in diagram above). If subsequent major phases are required, additional environments will be created to mirror existing, and the purple release process will be followed.

Input from the DWP will be required for the definition and agreement of document formats and other communications between the service and stakeholders (particularly claimants).

HeART will need to be enhanced to fully meet the requirements of PIP and we have already augmented our existing development team to ensure the following enhancements have been scoped, designed and costed into our proposal in order to ensure we can deliver the new service in the available timescales as follows. We have included a complete work breakdown schedule for these enhancements and incorporated this into the implementation plan. Other enhancements are:

Appointment booking engine

Whilst an appointment booking engine already exists within the core solution, the system will need to be adapted to take in to account 90 minute travel time. The solution will also be modified to include home visit functionality. (We will however be able to draw upon the systems experience in this area from our newly acquired Medical Direct business.)

Recruitment / Learning and Development

We have an enterprise-level IT solution to deliver volume recruitment functionality and other specific solutions for HP recruitment. For PIP we will tailor the volume recruitment system to specifically focus on HP (GP, nurse, occupational therapist etc.) recruitment (using our experience of specialist spot HP recruitment as required). This will include the interfacing of the application within the required recruitment process flow for PIP. Similarly, our existing training modules will be developed to deliver PIP specific e-training and training portfolio tracking functionality for HPs.

Claimant Portal

The current Capita Health & Wellbeing portal will be enhanced to provide claimants with a bespoke portal providing claim tracking and appointment rescheduling functionality.


Our platform also provides full integration capability which we have deployed for our existing health business, so that third parties can directly interact with the platform via a number of integration mediums including XML, Web Services and a web portal.

We have integrated with many external organisations. At RSA for example; automated referrals are transferred from their Colossus system into our CRM. Reports created on Warp contain embedded ICD9 codes which are used to look up appropriate compensation amounts and transferred back to RSA.

Interfaces will be developed to the following existing applications to deliver the overall IT solution:

Learning and Development systems – integration between the HP management database functionality with the L&D training systems both for initial and refresher training

SAP / BACS payment gateway – Capita Health & Wellbeing existing HPs already have their wage / invoice payments generated from the core system and an automatic interface to the corporate SAP environment which will be extended for PIP

Capita Fulfilment – integration between CRM case management system and fulfilment

Graticule / Accession – integration into route planning and scheduling software to allow for enhanced appointment search capability

Transport Direct – The batch travel planning capability to assist in the production of personalised travel plans

Social media integration – functionality to allow communication via Twitter, Facebook etc.

Telephony system – CTI Integration between telephony and the workflow management / case management system will facilitate responsive service to claimant phone calls.

Steps taken to mitigate risk

The key IT mitigation strategies are:

solution is based on existing functionality already utilised within the Capita health business

system has been developed by Capita Health & Wellbeing in conjunction with Ciber: our long term development partner (8,500 employees and turnover > $1bn)

additional development requirements have been identified as part of the tender solution – all identified, estimated and peer reviewed

solution is based on COTS packages requiring configuration rather than code creation (no part of the solution requires development of bespoke PIP-specific modules)

third party development partners have been part of the project team developing the bid; resource requirements for project delivery are known and a full project plan specified

some of the design and early development work will be started before the contract award is made – this de-risks the overall delivery timescales, and

we have a tried and tested delivery model for large scale projects.

c) Integrating Referrals

The most efficient integration points would be the transfer of referrals from PIP CS into HeART. We will initially manually re-key referrals, and work together with DWP over the first year of the contract in order to facilitate the automated transfer of referrals.

Redacted: (see below page 60)

Redacted (pages 58-60):

a) IT Environments

We have specified production, user acceptance test/pre production and systems test environments and included the hardware and network components as well as describing which software modules are supported on each of them. Pre-Production/UAT and Production are equally sized in order that performance tests can be accurately performed and are in line with the Lot activity volumes as described in the cost model. The Pre-Production environment will also be used for training and penetration testing.

Development and test environments have been sized to support the development team described in the resource model.

All of the environments are dedicated to PIP.

The diagram below provides a high level view of the infrastructure that supports our proposed solution: including the central hardware, distributed hardware, interfaces with the DWP/DSD and security domains.

All code will be stored in a Microsoft TFS repository, which will allow careful tracking of every version of every component of software in each release. TFS will allow branching and merging of code for multi-phased development. Automated TFS builds on check-in will ensure the integrity of code.

There will be daily integration of code into the System Test environment followed by automated testing. On a 3-4 weekly cycle, fully tested components of functionality will be delivered to the secure Pre-Production environment for UAT. A set of test scripts will be created and executed against all delivered functionality. Prior to go live, there will be a longer period of end-to-end UAT with particular emphasis on business processes and full regression testing of all system functionality. A complete “image” of the preceding live version of the system will be retained to de-risk upgrades, by allowing reversion to the previous version in the event of a major problem occurring.

At an agreed phase of the solution, penetration, performance, volume and resilience testing will be performed. To minimise disruption, production deployments will be scheduled outside normal working hours. Full system backups will be taken.

b) Hardware & Software Products

A full list of Hardware & Software is provided in a separate document as specified (7.2 IT Systems), The following summarises the functionality provided by the main software components of the solution:

Microsoft Dynamics CRM 2011 – case management

Additional CRM entity definitions and forms, created using the Dynamics CRM customisation user interface (to ensure forward compatibility of these with new CRM Versions)

Workflows – CRM workflows used to automate tasks on Cases. Created using the Dynamics CRM workflow user interface

Reports – used by managers to control staff utilisation and capacity planning. Created via SQL Server Reporting Services / RDL and configuration in the CRM UI

SharePoint Document Management – document management software for storing correspondence, and case-related documents

Knowledge Lake Imaging Server – third party application that inserts scanned documents into SharePoint. Developed and maintained by Knowledge Lake

Web Access – provides the external access to CRM and SharePoint, via a web application (the portal) and various web services

 Expert Administration System (EAS) – rich client application used by HPs to indicate their availability, view calendar of appointments, download/review medical records, mark appointments as attended / FTA and write, submit and correct reports (will not be deployed for PIP reports except during “clerical period”). Uses a local SQL Express database that is stored in a secure location (see below). .NET 3.5, Windows Forms, and SQL 2008 CE

 CAPITA Portal – portal allowing CAPITA and Prognostic Health customers to create Cases, upload documentation (e.g. LOAs and medical records), and view the progress of cases. ASP.NET 3.5.

All software will be supported and we will ensure that all software versions are upgraded as required during the contract to ensure they remain within the supplier’s support window. This will avoid any remediation activities.

Hardware is based on Wintel architecture. IBM Tivoli is used to monitor this estate and VMWare to manage server partitions. Again all hardware will be fully supported and maintained accordingly.

Components’ capacity have been sized to meet the projected DWP volumes plus 50% for servers and 30% for storage.

c) IT Change Processes

Change Requests may be initiated by nominated DWP contacts, a system supplier or Capita. The Project Manager will capture and document it in the project repository. Change Requests raised by a 3rd party supplier will be immediately brought to the attention of DWP.

The Change Management process includes an initial impact assessment, a technical impact assessment, a build and test plan, a back-out plan and associated costs and resources required, all of which will be agreed during the impact assessment stage. We will prepare a recommendation for each change request (in conjunction with any other party if appropriate) and present it to the DWP for approval via a Change Request Form. The project team will implement, close, or defer the change request based upon the decision to approve, disapprove, or defer the request. The decision to approve, disapprove or defer will be communicated back to all interested parties. For approved change requests, the work will be reflected in an updated release plan.

It is envisaged that any change project will be implemented in one of two modes:

Agile development mode – whereby functionality is developed in 3-4 week sprint increments. Sprint may be grouped for deployment to production on a 4 to 12 week cycle. The development team will be sized with 4-9 members depending on the size of the development workload.

Small Enhancement Mode – is a controlled Project Change Management Process. This is a process by which requests for modifications to the established scope, schedule, or cost are controlled and managed.

A project repository will be agreed and used to capture, track, and communicate status of change requests. Indicative milestones for changes: <50 man days, 50-1000 man days and >1000 man days are as requested illustrated in 7.2 IT Changes document.

Changes will be categorised and allocated one of the following release slots:

 Emergency Change – to be scheduled out of hours the same day. This is by exceptional process. Where possible these are deferred to the weekly patch cycle below.

 Weekly Minor Patch/Operating System Maintenance – when sufficient changes are accumulated these would be deployed in an agreed weekly out of hours support slot. The intention is that is not the norm but all changes are deployed on the same day of the week and time

 1-3 Month Minor Development Releases – depending on the level of development change these would be planned on a 1-3 month basis

 Major releases – where possible these would be broken down into sprints/phases and deployed on a 1-3 month cycle. Where this is not possible deployment timescales would be included as part of the planning phase:

 a replica of the supported software will be maintained in a test environment at all times. Periodically there are released hot fixes and roll ups of the Microsoft applications. As part of the support service, the supported software would be tested against standard hot fixes and service packs within the test environment. We would then agree a schedule for the application of these to the other pre-production and production environments

 it is expected that patches / updates are categorised based on the following levels each of which have specific SLA’s, required documentation and levels of authorisation. These are: P1 – Planned; P1 – Retrospective Emergency (Use of this is strictly controlled); P2 – High Priority; and P3 – Normal Change.

Redacted: (see below page 63)

Redacted (pages 61 – 63):

components tolerance to variations in capacity and the effort and time that would be required to deploy additional capacity in the future. Based on our current assessment of the required capacity, we have included:

between 50% and 100% surge capacity in server processing power, and

around 30% immediate extra capacity in primary storage (based on the total required over 5 years) although we are rapidly able to increase this to 50% and beyond if required.

We have scoped sized infrastructure models with associated hardware/software lists for each lot, as well as multi-lot combinations.

b) Capacity Management

We will use our proven capability in Capacity Management to ensure that the required capacity is available to support the PIP Assessment process, at all times.

We will achieve this by:

planning and ensuring sufficient capacity exists to process the current and anticipated workloads at the required performance, quality and quantity

monitoring actual services used versus those provided to ensure the right profile is used at all times

checking performance levels are within the bounds of our SLA targets, and recommending corrective action if not

proactively identifying work and or levels of service available on existing and planned capacity, supported by engaging with the Authority to understand their demand profile

using capacity to its optimum

ensuring the right performance is delivered by using performance testing as required for new or updated software releases, and

providing a Capacity Plan that details future known capacity demand based on anticipated workload forecasting taking into account both identified business growth for existing services as well as capacity requirements for new services, and against each major new release.

Our Capacity Manager will produce reports that will be reviewed as part of standard monthly service reporting or on an ad-hoc frequency if there are pressing capacity related issues that need resolution.

In addition all aspects of the infrastructure are fully instrumented and a wide range of performance and capacity metrics are captured, including server percentage use and spare storage capacity. This falls within the scope of our Systems Management solution and is based on the IBM Tivoli suite at the core. We install instrumentation agents on all major hardware components including servers, storage and networking. Data captured and processed through Tivoli is presented to the operations team through a dashboard display that shows the overall level of system health via a “Traffic Lights” metaphor. This will provide early warning of any component nearing capacity limits to allow early action. Should capacity be needed then we can allocate additional virtual servers or storage partitions within a few days.

We will also work proactively to continually improve the scalability and performance of the service where required, through:

proactive analysis and trending with modelling tools to determine consumption of future growth levels and subsequently propose remedial actions / projects

discovery of bottlenecks in time to correct before business services are adversely affected,


consistent capacity reporting, providing the right information at the right time.

We will develop a Capacity Plan that looks to the future with the aim of understanding the business drivers for 12, 18 and 24 months into the future. This will be reviewed monthly as part of the Service Management Review, to ensure business ideas are being factored in at the right time and with the right end goals in mind. Any suggestions will then be discussed in the appropriate forums and with key stakeholder groups, to consider how to make the best use of new technology, infrastructure, applications, methods and processes.

c) Flexing Capacity

We understand that there may be unexpected requirement for additional capacity on the IT systems. This may be as a result of:

a sudden influx of new applicants for PIP

requirement to move people from DLA to PIP more quickly

or just through the pattern of assessments in the working week being compressed into a shorter time period than planned.

In order to be able to accommodate this we will deploy a robust and scalable technology multi-tiered architecture that has a degree of spare capacity built in and is able to increase capacity in a modular way with the right tools to provide accurate information on current utilisation and the ability to model future operational scenarios.

Additional processing capacity can easily be added ‘horizontally’ by adding extra servers into each tier (data, application, presentation). This approach vastly reduces the time required to add additional capacity, over scaling ‘vertically’, meaning that we can often add additional processing capacity within just a few days if necessary.

Due to the relatively low cost of storage in comparison to the cost of installing and configuring the storage the IT platform will initially be provisioned with a full 5 years worth of primary storage capacity.

d) System Availability

Good availability of the IT systems that support the assessment process will help ensure a consistently high quality service is delivered to all PIP Applicants. All aspects of IT must be reliable and secure, right through from Laptops that our assessors will use when working face to face with applicants through to the central IT systems that manage the scheduling of appointments and power the self service portal that we have included in our solution.

We will ensure that all service levels are consistently achieved by monitoring end user services, as well as the availability of individual IT components, in order to minimise the risk of service failures and also understand the true ‘end user’ impact of any failure, should one occur.

Our approach to availability management encompasses all aspects of the service, including implementing corrective action to meet agreed availability, reliability and maintainability levels. These actions will be identified by reactive processes such as Incident Management and any failed Changes or Releases, as well as proactive processes in line with Problem Management, trend analysis and service improvement initiatives. Maintenance schedules will be defined in agreement with our service stakeholders, and these will be agreed well in advance to ensure there is no operational or business impact, especially around business critical periods.

We will be working to a system availability target of 99.8% to underpin any Operating Level Agreements that are in place.

Redacted: (see below page 66)

Redactions (pages 64-66):

a) System Monitoring

As per the Production Architecture diagram above, we have architected the infrastructure to provide hardware redundancy so that single server or storage component failure will not affect the service and have ensured the configuration has inbuilt load balancing and failover. The proposed system monitoring tools (IBM Tivoli) have been used by Capita for a number of years and our configurations ensure no performance degradation is incurred.

CheckPoint F5 Big IP

CheckPoint F5 Big IP is deployed as the hardware load balancer. This is capable of monitoring the health of the CRM and SharePoint web applications and is deployed to provide HA and scalability for the web front-ends.

IBM Tivoli Monitoring (ITM)

ITM provides monitoring for essential system resources, to detect bottlenecks and potential problems and to automatically recover from critical situations. ITM avoids our system administrators having to manually scan extensive performance data prior to remedial action.

ePolicy Orchestrator Agent

The ePO Agent will be installed on every CRM server to ensure protection from various network security threats. The agent is responsible for deploying software components such as VirusScan Enterprise and Anti-Spyware Enterprise and keeping them up to date with current AntiVirus signatures.

The ePO Agent communicates with the central Anti-Virus server, to obtain details of what software components should be installed. It will then transfer and install any policy changes or software updates that need to be applied.

McAfee VirusScan Enterprise + Anti-Spyware Enterprise

McAfee VirusScan Enterprise protect the CRM system from viruses, worms, Trojan horses, as well as potentially unwanted code and programs. There are daily registry-signature updates.

In addition Anti-Spyware Enterprise finds and blocks both known and unknown spyware using behavioural-based methods.

netForensics Agent

A NetForensics agent will be installed on every CRM server to send security related events to the central Security Information Manager (SIM) system. The SIM will collect logs/ events, aggregating them and forwarding them to the central management system. Here they are correlated, analysed, and compared with current known vulnerabilities. The resulting information is used to generate alerts and provide a security dashboard visualisation.


Tripwire is a configuration control solution that provides file integrity monitoring together with a compliance policy management to protect, detect and correct IT systems security.

b) Resilience

Local resilience is built into the virtual servers with multiple fans, CPUs, power supplies, network connections etc.

The CRM virtualised server infrastructure makes use of VMWare High Availability (HA) and Dynamically Allocate System Resources (DRS) features that will enable windows server images to be rapidly moved or restarted on a different physical platform in the event of a hardware failure.

Resilience is included in the production physical server cluster by using Microsoft Clustering Services (MSCS).

The production environment will be hosted at Capita’s primary data centre at West Malling in Kent, with a mirrored environment at our DR Data Centre at Laindon in Essex. Data will be replicated between the centres using a dedicated 1GB fibre link to ensure we are able to meet the RTO and RPO targets in case of a complete loss of the primary data centre.

The SQL databases are mirrored to a running SQL server at the DR Data Centre. Microsoft support SQL mirroring for CRM, SharePoint, WARP and CleanseData. It is possible to configure CRM and SharePoint with a secondary SQL server such that in the event that the primary SQL server is down the secondary may be invoked quickly, subject to breaking the mirror and enabling write access to these mirror backup SQL databases. This method of providing DR availability for CRM and SharePoint SQL databases is a fully Microsoft supported and documented DR method.

c) DataBase Backup

In addition to mirroring transactions to the DR configuration, overnight an offline copy of the database will be created to provide a source for MI/BI reporting. The database will also be backed up onto offline media and will be stored offsite as part of an agreed periodic regime to ensure sufficient history is maintained in the event of any requirement to retrieve data over an agreed period. This supplements the audit log which provides the definitive log of events and data changes.

d) Disaster Recovery

We have configured the DR systems so that, in the event of a complete loss of the primary data centre, the service can be resumed within 24 hours using the mirrored configuration at the DR data centre. During the day completed transactions are shipped across the fibre link between the Production and DR Data Centres, and are stored on a Storage Area Network (SAN) device, that will mirror that of the production database. In the event of a complete loss of the primary data centre, then virtual servers (on existing physical hardware in the DR data centre) will be configured, using the “image build” from the production instances. After testing the entire configuration, the users will be able to log onto this environment within 24 hours and will have data that reflects the last completed transactions prior to the outage. Part of the DR plan will include IP address and DNS changes to direct clients to the servers running at the DR Data Centre. We propose to carry out DR tests on an annual basis to ensure they will be operable in an emergency.


Capita operates using industry standards for the delivery and management of IT including:

ITILV3 (used since 2009)

Prince2 (used for more than 10 years)

CMMI (largely internal to Capita)

certified to ISO27001:2005 Information Security Management System (ISMS)

certified to ISO9001:2008 Quality Management System (QMS)

certified to BS25999:2006 Business Continuity Management System (BCMS)

accredited to PCI DSS as a Hosting Service Provider

operating to Impact Level 3 – Restricted

BACS approved bureau, and

registered EU Code of Conduct Data Centres Energy Efficiency.

Each of these disciplines is used consistently throughout our client base. The transition from ITIL V2 to ITIL V3 occurred in 2009 and ITIL V3 is now fully integrated in our Service Management offerings.

The PIP solution is based on existing systems already utilised within a number of Capita businesses. The prime system has been developed by Capita Health & Wellbeing in conjunction with CIBER, our long term development partner (8,500 employees and turnover > $1bn).

CIBER utilise a number of methodologies and best practices across its operations for software delivery, project management and customer service which conform to the same international standards adhered to by Capita and which have been successfully dovetailing with Capita practices for many years.

CIBER’s Project Management Methodology (CPMM), combines best practices from the fields of Project Management and Quality Assurance with practical insights gained from CIBER’s extensive delivery experience. The approaches are consistent with themes advanced by such internationally known organizations as the Project Management Institute (PMI), the Software Engineering Institute (SEI), and the International Organization for Standardization (ISO).

CIBER utilise a comprehensive delivery methodology that, when coupled with our Project Management Methodology, enables the delivery of solutions effectively, in accordance with industry best practices. CIBER’s Software Delivery Methodology (CSDM) is a set of repeatable, measurable processes that guide software development and manage all facets of the software delivery process. CSDM fits within CIBER’s larger ISO 9001quality framework of policies and procedures that direct business processes. This framework incorporates a number of industry recognised development approaches including Agile

Redactions (pages 75-76):

“LOT” SPECIFIC RESPONSE FOR LOT 2 – Central England and Wales

We recognise that the security of the solution is of critical importance to both the DWP and the individual applicants who entrust us with their personal data. As the Assessment Provider we will handle large amounts of data from personal, sensitive, to aggregated, all of which needs to be handled and protected in a robust, appropriate and consistent manner. Furthermore we recognise that the DWP operate in a highly regulated environment and face numerous compliance regimes relating to the provision of Information Assurance (IA), Security and Data Protection. In order to address these challenges, a strategic approach is required, using a risk based methodology. Our SME and Lot 2 partners such as Assist UK members, WIRED and Equal Approach will achieve and adhere to security and audit requirements supported by our Infosec practice.


Capita is experienced in addressing security within a geographically diverse environment and have highly skilled security and support personnel located across the UK able to offer additional support as and when required. Our extensive experience includes the design and implementation of bespoke solutions for HMG clients, including the provision of secure infrastructures and the handling of Protectively Marked information. These secure solutions include IL2 (PROTECT), IL3 (RESTRICTED) & IL4 (CONFIDENTIAL) infrastructures within Local Authorities, Non-Departmental Government Bodies and Central Government, and IL5 (SECRET) and IL6 (TOP SECRET) environments in the Defence sector.

Security Policy

The security requirements for PIP are aligned to several HMG and DWP policies, manuals of security and International Standards such as The HMG Security Policy Framework (SPF), ISSS and the IS027000 series. We will ensure that our solution is fully compliant with all relevant DWP and HMG security requirements, policies and guidelines in accordance with the business Impact Levels (IL) and/or the Protective Marking of the information assets. This will ensure the continued security assurance in terms of Confidentiality, Integrity and Availability relating to the systems and data of both the DWP and the AP. Any changes required due to change of policy under potential Welsh devolution will be incorporated within policy and plans.


Our overarching security approach is based on a risk management core. Technical Security for our solution will be assessed using the HMG IS1 methodology, and recorded in the RMADS. This risk posture will be reassessed quarterly for personal data assets, and annually for other assets or following a substantive change. Equally Physical Security will be assessed using the ISSS specified Minimum Baseline Measures Matrix (MBMM). We will continuously work with DWP in relation to risk management, including the formal recording and notification of identified current or emerging risks and vulnerabilities.

Security Manager & Security Management Plan

A Capita Security Manager will be assigned, responsible for managing all the day-to-day security governance, compliance and IA related activities with the DWP SIRO and Accreditor. This role will also be responsible for the management of audits, personnel security and on-site physical security where appropriate, and will be based in our Lot 2 service centre Birmingham.

The Security Manager will create, own and implement the Security Management Plan; a draft of which is included with this proposal. We will present an updated Security Management Plan to DWP within one calendar month of Transition commencement. This will be a living document that is maintained under strict version control throughout the contract term.

Security Zones & Data Aggregation

We are also aware that the solution must be architected and managed based on a security zone approach whereby data, assets and environments carrying differing impact levels are segregated. An example of this would be the additional security controls applied to areas of data aggregation which raises the impact level from IL2 to IL3 for confidentiality.

One such area would be the hosting of applicant data in our CRM system where we would expect the aggregation of these records, which include sensitive personal information, to raise the impact level up to IL3. Procedural controls will be established to prevent the accidental aggregation of data outside an approved security zone. For example, we will place a limit on the number of completed assessment forms that an assessor can carry at any one time.

The physical and logical controls that we will put in place around any single Security Zone will be commensurate with the impact level of the data managed within that Zone. For example; biometric verification to gain access to the data centre that is hosting the PIP CRM platform, but would not require the same level of control to enter an assessment centre.

Information Management & Training

We will provide training and awareness to all staff enabling them to apply Information Management practices operationally, including Information Security controls. Quality Information Management practices will be adopted and integrated with IAMM requirements to ensure that all DWP or applicant data handled by Capita is understood, recorded, protected in accordance with its protective marking/IL and associated storage environment such as servers, portable electronic devices or paper-based information held within cabinets.

Future Enhancements

We are aware that the delivery of the PIP programme is operating on an accelerated timeline. Therefore, through the design of our solution it is our intention to minimise the scope of any initial accreditation activity that may be required. As the service matures, we will most likely seek opportunities to make it more efficient, and reduce any ongoing burden on the DWP, which may lead to further accreditation activity.

3 thoughts on “PIP Tender documents – Document 4 Part 5 (unredacted because the DWP are incompetent)

Leave a Reply