The term mobile code existed in the old ISO 27001 2005 revision - it meant the code like Java script. However, in the new 2013 revision, there is no more mention of mobile code in ISO 27001.
Answer: PCI-DSS is not my field of expertise, but ISO 27001 does not require you to implement any of these tools - ISO 27001 requires you to assess whether there are risks in your organization that would require such tools, and if yes - then you would n eed to implement the tools.
In my experience, large majority of companies already do have most of the technology they need, but they don't use it in an appropriate way.
Upgrades to Documentation Set
Dear Doug,
You're not entitled for a discounted upgrade, but for a free upgrade
Our policy is to send free upgrades to all customers who purchased the toolkit in the last 12 months - we made an upgrade in October 2013, and we've sent you the email with this upgrade, but it seems it didn't reach you.
In any case, my colleague will send you the upgraded toolkit (compliant with ISO 27001 2013 revision) shortly.
Which is first - BIA or risk assessment?
Answer: I assume that by "RIA" you refer to risk assessment. ISO 22301 is fine with both approaches - risk assessment first and BIA second, or the other way around.
My preference is to perform the risk assessment first because you will have a much better feeling about which incidents can happen (and therefore better assess the impact during BIA), but you can also use the list of assets you identified during your risk assessment as an input for BIA when you need to identify all the required resources.
Addres change after certification
Gokhan,
1) About company relocation - you should read the terms and conditions with your certification body and see what they require, but in most cases you would have to notify them of such change, and they would check whether you adapted your ISMS during their first surveillance visit. You would normally need to assess the risks again and implement all the new controls as identified during risk treatment.
2) If your risk assessment and treatment shows that by having a key instead of a digital lock sufficiently decreases the risks, than this is OK.
Corporate information security policy
Answer: Basically, ISO 27001:2013 requires you to include these items in the top-level policy (clause 5.2):
- Objectives and framework for setting them
- Commitment to fulfill the requirements
- Commitment for continual improvement
So not really much.
Excluding secure development from Statement of Applicability
14.1.2
14.1.3
14.2.1
14.2.2
14.2.3
14.2.4
All the way till
15.1.3
Answer: If your risk assessment has proved there are no risks, and there are no contractual or regulatory requirements in this respect, then you can exclude these controls from SoA - in this case, you have to explain the reason for their exclusion. If you use our SoA template, you will mark those controls as non-applicable, and in the column "Reason" briefly explain that there are no risks and no requirements.
However, controls A.14.1.2 and A.14.1.3 are related to e-commerce, so if you have web shop, it will be difficult to exclude those. Further, controls from A.15 are about suppliers, which include your telecom provider, so it will be difficult to exclude anything from A.15.
Documenting the record control
Answer: Yes, you are right - this is the requirement from ISO 27001:2005.
So it is safe to say that an organization shall have five documented procedures. In addition to the four which you have mentioned plus one for records control. Of course the organization has the flexibility to have one documented procedure for document and record control.
Answer: I agree with you only partially - you could write a fifth procedure for records management, however best practice is to document records management in each policy or procedure which requires creation of records. For exampl e, if your Access control policy requires written approval of privileges, then this same Access control policy can define how these approval records are created, where they are stored, how are they protected, etc.
In most cases, you would create a table at the end of each policy/procedure where you would specify those rules for all the records.
(By the way, ISO 27001:2013 does not require documenting 4 mandatory procedures you referred to - this was the requirement from the old ISO 27001:2005.)
Is the latest 2013 revision of ISO 27001 finalized?
Also what should be the approach for an organisation who is already certified and is looking for expanding their scope.
First you have to define exactly your new scope, then amend the ISMS Scope document but also your other policies and procedures accordingly. Finally, you have to ask your certification body to re-certify you with the new scope.
Statement of Applicability is the document where you should refer to individual clauses/controls of ISO 27001 and specify how you implemented them.
2) Is the Project plan a required document, since the realization of the project is defined in the contract with the client?
Project plan is not a required document, but it is recommended since there you specify into more detail who has to do what during the project (normally you wouldn't specify such level of detail in a contract).
3) Is it required to nominate a person responsible for ISMS by a separate decision, or can this be documented in the job description?
You can do it either way, but usually you specify who is responsible for what in various ISMS policies and procedures.
4) Are Business Continuity Policy and Business Continuity Plan mandatory?
If you implement ISO 22301, both of these documents are required; if you implement ISO 27001 then Business Continuity Policy is not required, while Business continuity plan (or procedures) are required according to control A.17.1.2. Theoretically, you could decide to exclude control A.17.1.2, but I haven't seen anyone do it.