Answer: ISO 2700 cannot be implemented to products. It is a management system standard aimed to protect information related to organization's processes, business units or locations. Regarding the organization, ISO 27001 can be implemented to specific processes, business units or locations or you can define the entire organization as the ISO 27001 scope.
2 - To start with risk assessment ISO 27001, is it mandatory to have process list identified first followed by identification of assets and then final risk assessment.
Answer: ISO 27001 does not prescribe any specific methodology for risk assessment, so orga nizations are free to choose the approach that suits them best.. That said, it is not mandatory by the standard to have a process list identified first.
In this white paper you will find information such:
- The types of costs faced within an ISO 27001 implementation project
- How different implementation options could affect your budget planning
- Tips to improve budget planning
- How to verify your budget outline
I also would like to remember you that included in the toolkits you bought you also have access to expert support to help you with the templates, answer questions and evaluate documents, so you can include this approach among other consultancy alternatives you may be considering.
Unfortu nately we have no such materials for SOC 2, but many concepts and examples in the white paper can be extrapolated to SOC 2.
Customer visit and customer satisfaction
Answer:
In reality it doesn’t matter, it is just a box, consider that it belongs to customer satisfaction, or customer communication, or even a tool to win customers, or interested parties’ relationship development. What matters is that your organization believes that customer visits is something worth investing to do it professionally
The way of maintaining the knowledge depends on the way how the knowledge is stored. The purpose of this clause is to ensure the knowledge is up to date. So, in order to maintain the knowledge, you need to identify it first, and it can be in form of work instructions, procedures, etc, and then you need to define how you should keep it up to date and available to the relevant people.
Answer: If you have the Data Protection Officer, then this is the person responsible for data protection in your company.
If you do not have such function, you can assign a role of person responsible for data protection to someone like Head of IT department, Head of legal department, or similar - GDPR itself does not provide any guidelines on this, but it would be good to have someone with enough authority in the company to make important changes.
The requirements for product safety cannot be excluded even if there are no safety issues related to the product. If you are not designing the product and get the drawing from the third party (e.g. customer), they should provide you with information on the product safety. If they don't, you should conduct risk assessment to determine if there are any risks related to the product safety and take appropriate actions. Even if there are no product safety issues, you will still need to have the product safety process.
Thanks for taking time from your busy schedule to reply to me.
Answer: ISO 27001 does not prescribe any solution to be applied for security controls in Annex A, only objectives to be achieved. This gives organizations freedom to implement the most adequate solutions according to their context. For guidelines and recommendations about what to consider in the implementation of security controls, you should consider the ISO 27002 standard.
That said, regarding security of system passwords, service passwords, and application passwords, including passwords at administrator level, you should consider ISO 27002 recommendations for the following controls:
- Control A.9.2.3 (Management of privileged access rights): for shared administration user IDs, you should consider practices like changing passwords frequently and as soon as possible when a privileged one user of these shared IDs leaves or changes job, and communicating these passwords to administrators through secure mechanisms. Besides that, all other recommendations from control A.9.3.1 (Use of secret authentication information), aimed for general users, should also be applicable to administrators.
- Control A.9.3.1 (Use of secret authentication information): when passwords need to be part of automated log on procedures they must be properly protected (e.g., do not store password on plain text)
- Control 9.4.3 (Password management system): when stored, password should be kept on files separated from application system data.
We want to start the risk assessment right before the design stage.
We want to ensure that the design is secure and taking into consideration all the security risks that system environment will be facing.
By understanding the risk and the risk level, all appropriate controls will be put in place at the design stage.
This will then ensure secure development, secure delivery and the end objective to have secure operation and maintenance.
I am thinking of using threat modelling risk assessment at the design stage.
As I understand the risk assessment is not a “one time do and forget” exercise. Thus, we should be having a periodic risk assessment, with review and monitoring. May be it is a good practice to have a yearly exercise.
For our environment, we should have it at every stages.
Hope to get some feedback from you on the above.
Answer: Your thinking is absolutely right. System security must be though as soon as possible in the development process, and s hould be periodically reviewed because of the identification of new types of threats, codification problems and opportunities of improvement. To ensure this thinking is considered in your organization's process you should consider the implementation of a Secure Development Policy (a template for this policy is included in your toolkit, at folder 08 Annex A, subfolder A.14 System acquisition, development and maintenance), as well as integrate the security activities in your current development process. A good reference for secure development is the ISO 15408 standard, which you can see at this link: https://www.iso.org/standard/50341.html
The first thing you have to consider is the identification of the requirements this Information Security Policy must comply to (e.g., laws, contracts, standards, etc.), then, based on these requirements you can plan what to look for as evidences that this policy is implemented and being followed.
This toolkit has four documents (Internal Audit Checklist, Procedure for Internal Audit, Annual Internal Audit Program, and Internal Audit Report) that can help you perform an internal audit considering the ISO 27001, the leading ISO standard for information security, in a easy and efficient way.
These articles will provide you further explanation about internal audit:
- How to prepare for an ISO 27001 internal audit https://advisera.com/27001academy/blog/2016/07/11/how-to-prepare-for-an-iso-27001-internal-audit/
- How to make an Internal Audit checklist for ISO 27001 / ISO 22301 h ttps://advisera.com/27001academy/knowledgebase/how-to-make-an-internal-audit-checklist-for-iso-27001-iso-22301/
On the other side, defects relate to not satisfying service requirements and involve e.g. change on the service in early life support phase. According to ITIL, definition of a problem is " A cause of one or more incidents.". So, if that defect doesn't cause incidents, there is no need to go to problem management. It's rather that you need to send it back to development (Release and Deployment or even to Service Design processes if you conclude that there is an error in service design). So, as you could see, defect can have much deeper causes then "usual relation" incident -problem.
This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy.
If you decline, your information won't be tracked when you visit this website. A single cookie will be used in your browser to remember your preference not to be tracked.