UPDATE June 2015: Since the original publication of this article, the Government’s approach to G-Cloud security has significantly changed. Please refer to this article instead – it explains the new security assertions process introduced with G-Cloud 6. To keep in touch with future developments why not sign-up to receive our regular news .
The Government’s G-Cloud service is open for business. To date over 1,700 information and communications services have been added to the Cloudstore catalogue. In practice, only a tiny fraction of these services have actually been approved for use by public sector organisations. The main barrier is security accreditation .
For suppliers who wish to offer their services through to G-Cloud there is a business imperative to become accredited. This will make your services more attractive to, and more likely to be selected by the public sector customer.
Here is a run down of the steps you’ll need to take so your service gets accredited.
Steps to accreditation
Step one: The first step of the process is to complete and submit the “G-Cloud Service Description – Security Accreditation Scope” template. The initial assessment is performed by the G-Cloud programme office, which will primarily focus on your eligibility to join G-Cloud. If your application is deemed acceptable it will be submitted to the Pan Governmental Accreditor (PGA).
Step two: The PGA will examine the information provided to ensure that the ISO 27001 certification is ‘suitably scoped’. Understanding what is meant by ‘suitably scoped’ is important: in simple terms this means that all elements of the service must be subject to certification. In addition, the Accreditor is seeking evidence that the security controls in some key areas are robust and sufficiently comprehensive. Unsurprisingly, this is likely to be an iterative process if the information supplied is incomplete or insufficiently detailed.
Step three: Once the Accreditor has agreed that the scope of the ISO 27001 certification is sufficient, he/she will specify what evidence is required along with appropriate assurance activities. In many cases the evidence will be based on independent audit reports (e.g. 6-monthly surveillance audits), but may require examples of audits of 3rdparties, certificates for evaluated products, and so on. Assurance activities are often based around an IT Health Check (ITHC), conducted by an accredited penetration testing company, but could include information related to the use and configuration of evaluated products. In some cases specialist assurance activities may be required, especially if the use of technology, or the system architecture, are novel or unusual.
Step 4: All of this evidence will be submitted as a Risk Management and Accreditation Document Set (RMADS) – a specific ‘light-weight’ template has been developed for this purpose. Other documents that must be submitted, and agreed with the PGA, include a Statement of Residual Risk, Security Operating Procedures (SyOPs) and IA Conditions for consuming organisations. Once the PGA is content an accreditation certificate will be issued. There are specific issues around the role of personal data (and sensitive personal data) – there is a separate questionnaire that must be completed to confirm that the service provider can support the customers obligations under the Data Protection Act 1998 (DPA). It is unlikely that a service provider would be accredited if their service is judged non-conformant with the DPA requirements.
Step 5: If the service is being offered at IL3 full accreditation is required. This is broadly the same approach as that used for IL2, except that the implementation of ISO 27001 controls using the HMG Baseline Control Set (BCS) is mandatory. It is also strongly recommended that a technical risk assessment is undertaken using the HMG IS1&2 methodology, along with a risk treatment plan that is aligned with CESG good practice guides. It is expected that IL3 services will be delivered by a G-Cloud service provider who is connected to the PSN at IL3 – compliance with the PSN Code of Connection (CoCo) is required. Whilst it is theoretically possible to offer IL3 services via the Internet, it is likely that a CESG evaluated cryptographic product would be required. It is also more likely that specialist assurance services will be required to validate the configuration and use of the service providers systems.
We hope these definitions help to make the G-Cloud security accreditation process a bit clearer. Look out for more G-Cloud accreditation tips, posted here shortly.
Article by Peter Curran ,Principal IA Consultantat Ascentor.
Looking for support for your G-Cloud project? Find out how we can help.
Other articles you might like:
- PSN Accreditation the process explained
- Busting the G-Cloud Security Jargon
- Information Assurance for PSN – CAS(T)