Cabinet Office

Main navigation

IA in Service Agreements

Introduction

This section is targetted primarily at government bodies setting in place medium to large scale contracts for the provision of IT-related services. It sets out the governance framework for security in contractual arrangements.

Statement of Best Practice

It must be recognised from the outset that achieving security in service delivery involves a number of complex ownership issues. Some of these can be addressed though a contractual route; others can only be addressed satisfactorily through the establishment of a working relationship supported by an effective set of processes and procedures.

Principles of Governance

Governance for contractual arrangements divides into two areas: governance relating to the department or organisation in terms of the process of letting the contract; and governance applying to the supplier being contracted.

Organisational governance

Within Central Government, the Office of Government Commerce (OGC) Gateway^(TM) procurement process provides the overall governance framework in this area. For other bodies the Gateway(TM) process is recommended as best practice.

CSIA can provide a template Information Assurance (security) schedule for inclusion in contracts.

It is also important to note that whereas some responsibilities may be devolved down to the supplier, the department (or NDPB or Local Authority) remains the information owner. The Data Protection Act and the Freedom of Information Act are key issues in terms of the retention of ownership of responsibility.

Supplier governance
In the case of a supplier providing a service on their own hardware, the service supplier has the responsibility for achieving IA in service delivery.

Consequently where protectively marked information is being processed, the governance framework for the supplier is made up of precisely those standards and guidelines that apply to government organisations, including but not limited to:

• The Manual of Protective Security (mainly for HMG but also for companies with List X sites).
• All applicable HMG Information Security (Infosec) memoranda and standards.
• CPNI recommendations.
• Where a GSi connection is involved, the GSi Code of Connection and related documentation and requirements.
• ISO/IEC 17799 in all cases.

The contractual terms must explicitly include a statement to this effect, with any specific exceptions clearly stated.

In other cases, and possibly in addition to the central policy documentation, there may be requirements which are organisation-specific. Where an infrastructure system is involved for example (such as the Criminal Justice network or the NHSNet), the applicable connection criteria for that system must be upheld if the service supplier hardware is to be connected to it, and this too must be clearly set out as a contractual requirement.

In other cases, such as co-location and managed hosting, there must be a clear allocation and acceptance of responsibility. In the case of managed hosting for example, there may be divided responsibilities, for example up to and including the operating system will be managed by one party, with applications managed by another, possibly on a subcontracted basis. In this case all implications should be fully investigated before contract acceptance (such as the implications of using a service provider lockdown on the operating system, any potential requirement for alerting to a third party in the event of an incident, and the division of responsibilities for contingency planning).

The issue of subcontracting must also be considered, with (in the general case) the prime contractor retaining responsibility for security in all allocated areas, irrespective of whether or not subcontractors are used by the prime.

For offshore contracts, ISO/IEC 17799 can provide an internationally recognised basis for mutual understanding of required levels of security. CPNI briefing 03/2005 provides guidance on the risks for CNI organisations.

Guidance on Procurement

The governance framework for the supplier is more clear-cut than that applying to the contracting organisation (e.g. a department). Therefore the remainder of this section provides guidance which, although not binding, nevertheless represents detailed best practice. We have chosen a number of key areas which experience has shown can prove difficult.

Compliance
In outsourcing or PFI arrangements, security in the delivery platform is a matter for the service supplier to agree with the Accreditor (and/or auditors).

Documentation
In a system procurement it is usually possible to specify the security solution albeit at a high level, at the time of issuing the Invitation to Tender (ITT). In the case of services however, the delivery platform design will vary between bidders, and it falls to the supplier to generate the system security documentation. There are two main risks that arise from this:

• The lack of a specific security policy statement (such as a Risk Management and Accreditation Documentation Set, RMADS) at the time of contract award decreases visibility for the contracting organisation, and increases risk. Contracting bodies should ask for an initial statement to be included as part of the supplier proposal, to reduce the risk and to show competence. Where appropriate, bidders should be referred to ISO/IEC 17799, IS2 and/or the corresponding template RMADS.
• There may be a temptation to set out detailed IA requirements in the ITT or service specification. Since the security statement (e.g. RMADS) is binding in a security sense, and given that the IA schedule will mandate compliance against the RMADS, security requirements are then set out in two places, which can give rise to inconsistency. Wherever possible, unless there are mandatory detailed security requirements in specific areas, the contract should concentrate on the contractual details relating to security (which would not normally form part of the RMADS).

Termination
The tendency when drawing up a security schedule is to concentrate on the positive. Nevertheless the OGC template includes a section on termination and thought must be put into its completion, specifically:

• The contracting organisation must retain control over ongoing security during wind down and eventual disposal. This is true also for contractor-owned and leased equipment.
• Where there is List X sponsorship, it is the responsibility of the sponsoring department to agree that there is no longer a requirement for List X, and List X status must not be removed without this agreement.
• There may be ongoing responsibilities, for example where there is a need to archive information, or where external bodies are involved in termination.

Risk Management Plan
Service suppliers should be asked to develop and agree an IA Management Plan at an early stage. The plan should identify those activities which will achieve the necessary level of IA, such as:

• Scope and context of security approval such as accreditation (including necessary evidence of compliance)
• Division of accreditation responsibilities
• Accreditation or approval milestones
• Process for accreditation maintenance
• Definition of documentation sets
• Accreditation deliverables list (including reports and data)
• IT Health Check (ITHC) requirements
• Data migration processes
• Dependencies and links with project plan
• Key success factors, risks and contingencies
• Initial version of security subproject plans
• Ongoing security requirements (patching, anti–virus updates etc.)

An IA Management Plan will provide a number of benefits, primarily a shared vision of IA, an agreed timetable and a common approach to management of risk in the process itself. One specific benefit is that it can underpin the contractual and commercial issues. On ITHC’s for example, where the IA Management Plan identifies the need for an ITHC under the CHECK scheme, this can feed into the procurement process to ensure that the Terms and Conditions reflect those of the scheme; the very act of identifying the requirement for an ITHC prompts questions relating to responsibility for payment for those services, and the responsibility for addressing any issues raised as a result of the test.

For larger developments, the use of an approach based on staged approval can reduce overall project risk. The stages can be linked to stages in the development, or to specific services, or to specific components. If such an approach can be agreed with the approval authority (Accreditor) through the medium of an IA Management Plan, then this can avoid the ‘all or nothing’ single decision which itself can lead to IA compromises.

Whilst some risk can be transferred to the developer, in the general case the contracting authority is left with the risk of not having a system if the developer fails to deliver. For security-related project risks, the IA Management Plan provides the authority with visibility of those risks.

Development and shared environments
Whilst the emphasis in the contract may be on the delivered operational environment, security in any related development and/or support environments must be considered as a key issue, since failures in these areas have the potential to severely affect project timescales and in some cases, the feasibility of the project itself. For areas involving protectively marked information, such security requirements will be spelled out in the normal case by a Security Aspects Letter (a template is available from the Manual of Protective Security). In all cases there must be an agreed division of responsibilities covering areas not included in the Security Aspects Letter, such as commercial confidentiality.

Development or temporary environments may require accreditation in their own right. The same is true of environments shared between the department and the supplier. In all cases contracting bodies should consider the way in which they intend to communicate with the supplier and securely exchange documentation.

Offshore work
Offshore work involves a number of legal issues which require specific investigation. The transport of sensitive personal information outside the European economic area for example, requires the permission of the individual, unless a ‘safe harbour’ arrangement has been established. CPNI briefing 03/2005 provides guidance on the risks for CNI organisations.