ISMS Implementation using ISO 27001 version 2005 or 2013
In my opinion you should start with the 2013 version from the beginning, if you are familiar with the 2005 version, that could help understanding the concepts since the 2013 version is easier than the 2005 for experienced people.
If you are planning to get certified, please consider that after September 2014 there will be no more new certifications for the 2005 version, and the 2005 versions will be required to make a transition until October 2015. So if you start your ISMS in 2005 version, you will need to make the transition next year. Starting in 2013 version you will save time and money.
Preparation plan as part of Business continuity strategy
Answer: Since this Preparation plan is a kind of ToDo list which defines who needs to do what, when and with which resources, the method of evaluating the results could be by assessing the following information and comparing it with the plan:
- Records of implementation
- Financial accounting systems
- Reports from responsible persons
- Audit
- etc.
Quantity and quality of ISO 27001 documentation for certification audit
The certification process is performed in 2 stages: Stage 1 audit, also called Document review where your documentation is checked against the standard, and Stage 2 audit, also called Main audit which is performed onsite.
In Stage 1 audit your documentation is checked whether it is compliant with the standard - quantity is not so important as quality because for example smaller companies will have fewer documents but they still need to be compliant with the standard and appropriate for company needs.
However the most important is Stage 2 audit - this is where the auditor will check whether your company performs all the activities that are written in your documents. This means that you may have high-quality documents, but if you don't act accordingly, you will still fail the audit.
Opening Port 22 allows secure shell login to the server, using SSH protocol, which is a good option for remote access, using encryption between server and client.
Regarding the risks of source code access, we can identify the following:
- Lack of change management control
- Property rights violations
- Lack of control on Code security
- Server availability
- Software Development Lifecyle practices not accomplished
- Difficults in Service Level Agreement between service provider and customer.
Providing access to source code is a good practice or not depends on the business relation between parties and also the purpose of the server/code.
As a service provider it is a good practice to have an AUP (Acceptable Use Policy) signed by your customers regarding the services you are providing, where this point should be covered for server and code access. Also the AUP should include the RACI matrix identifying who is Responsible, Accountable, Consulted and Informed, defining the ownership of the asset.
If there is a need for shared administrator priviledges in th e server, you should use different user accounts and an external log system recording user activity in the server.
Thanks
Is clause 7.2 Competences of personnel mandatory in ISO 22301?
Answer: Clause 7.2 of ISO 22301 says "retain appropriate documented information as evidence of competence and any actions taken" - therefore, you must maintain records of all trainings and competences of your employees, and this is why we have listed that clause as mandatory in our List of documents.
However, I think that making a Training and awareness plan is useful although it is not mandatory according to ISO 22301, so this is why we have suggested that document in our List of documents under the section "Commonly used non-mandatory documents".
ISMS scope in Quality Manual
Neither ISO 9001 nor ISO 27001 prescribe how you should structure your documentation. So basically, you have the following options:
a) ISMS Scope document is a separate document - this is the most common option
b) ISMS scope is defined within the Information Security Policy document - this is option that is sometimes used by smaller companies
c) ISMS scope is defined within the Quality Manual - this is very rare, but theoretically possible.
Here you'll find a catalogue of threats and vulnerabilities: https://advisera.com/27001academy/knowledgebase/threats-vulnerabilities/
This catalogue is made for assessing threats and vulnerabilities of assets, but it can be used for processes as well. By the way, when speaking about ISO 27001, it is much better to do asset-based risk assessment because it gives much more precise results.
Information security incident managment Categories
For me, the items you mentioned are not categories, but examples of individual IT incidents.
In any case, since incidents are nothing else but materialized risks, here you'll see examples of threats and vulnerabilities that create information security risks: https://wiki.iso27001standard.com/inde*************************************
Secure system engineering principles
If this application that you're testing (together with its data) is within the scope of your ISMS, then yes - you should apply the Secure system engineering principles policy on this application.
Yes, information security and business continuity are very related - the most recent trend in most banks is that the functions of BCP and CISO are merged in one department or one person.
Arguments are these: you can do risk assessment at the same time for both information security and business continuity; incident management is very much related; training and awareness is almost the same, etc.