Difference in business continuity in 27001:2005 and 27001:2013
The difference in business continuity between 2005 and 2013 revision of ISO 27001 is the following:
2005 revision required the business continuity to be implemented in the whole scope of the ISMS
2013 revision requires the business continuity to be implemented only to the information security aspects of the ISMS - i.e. only for security processes and technology - therefore, the new revision requires less work to be done for business continuity
It is true that by implementing business continuity for ISO 27001 the company does not automatically get ISO 22301, however it is my opinion that it does make sense to implement both of this standards together. The reason for this is that ISO 27001 does not provide any methodology for the business continuity implementation, while ISO 22301 offers very good methodology for it; further, these two standards are high ly compatible, and the implementation of ISO 22301 as part of the ISO 27001 requires perhaps only 10% extra effort.
Information Asset: Business Applications and their Scope
I mean almost same what you wrote in your last sentence that if I include in my scope only hardware and the system software then I will left most important (business) data what is stored on those servers and which are important for company business processes. So that's why I think that in scope should be first most important business processes and during the risk assessment data center will be identified one of the important asset itself where where ISMS should spread on it and of course other assets which will be identified on the data center and outside of the data center as well.
Business Continuity Plan Template
Standards like ISO 22301 or ISO 27001 do not prescribe whether you will have your continuity procedures as part of a single document, or will you separate them in several documents.
From my experience, the optimal structure for mid-sized and for large companies is the following: write a top-level document called Business continuity plan, a separate Incident response plan for describing how you would respond to different incidents, and finally Recovery plans that describe how to recover each of your processes/departments/projects in case of a disruption. For smaller companies you could have all the mentioned in a single document called the "Business continuity plan".
So if you are a mid-sized or a large company, you could write a recovery plan for each of your projects.
The detailed recovery steps for the IT should go into the "Disaster recovery plan" which is nothing else but a more detailed Recovery plan.
Convincing top management about the ISMS implementation
2. How define which are our organizations actives and their owners during risk assessment when this organizations makes technical supporting (all of the other organizations servers are with us and also IT stuff, netflow etc.) to ministry and other organizations as well. I'm asking this question because I'm the organization's infosec manager which supports other oranizations technically and also other organizations have their infosec manager as well so how define which are our actives on the certain p rocesses when we are supporting to other organizations processes technically.
Answer:
If you are managing assets from other organizations, then these other organizations need to define their asset owners and risk owners. You can define asset owners and risk owners only for your own assets.
ISO 27001:2013 is a management standard, and it is the only management standard in the ISO 27k series. This 2013 revision of ISO 27001 had a predecessor (2005 revision of ISO 27001), so this might have caused the confusion.
You're probably asking about ISO 31000, which in the British version is BS ISO 31000. This standard gives you guidelines on how to organize risk management in a company - this is important for security because security management is nothing else but mitigation of security risks.
1. Can I just group them instead of address them one by one specifically? By group, I mean it's like: supplier, customer, internal working unit, goverment agencies, etc..
2. About their requirements, do I have to quote it precisely (from contractual agreement, for instance) or can I use my own words?
Answers:
1) ISO 27001 does not say you need to identify each interested party individually, so yes - you can group them, as long as each interested party in a group has the same requirements.
2) Sure, you can use your own words.
Do we need to place camera for server room?
ISO 27001 does not prescribe what you need to place in the server room or what you should avoid - what ISO 27001 says is that you need to assess your risks, and install security controls accordingly. Therefore, if you have risks of unauthorized access to your server room, then it is a good idea to install the video surveillance.
Theoretically, it is possible to accept any kind of risk.
By the way, the risks are accepted (or not accepted) by only analyzing the risks, not by analyzing associated controls. Usually, the risks that would require classification are related to confidential information.
If you handle some confidential information from your clients, usually the risk is that people handling those information won't know the rules for protecting such confidential information. Therefore, in such cases classification and associated rules for protection are the best way to resolve such risk - so in most cases controls from A.8.2 are found applicable.
Business continuity certifications for individuals
These certifications are each based on different methodology - CBCI is based on BCI' Good Practice Guidelines, CBCP on DRII's Professional practices, while Lead Implementer/Lead Auditor are based on ISO 22301 standard.
Currently it is not clear which certification can bring you more benefits because BCI and DRII are established in the market for a very long time; however ISO 22301, similar to other ISO standards, is becoming more and more predominant, so I expect that in couple of years certifications related to ISO 22301 will have the best perspective.