As long as the control plan meets all relevant requirements of the standard, you can remove numerical values and reference to appropriate documents.
Control plan must at minimum include the following:
a) control used for the manufacturing process control
b) first-off/last-off part validation;
c) methods for monitoring of controls;
d) the customer-required information;
e) specified reaction plan.
Addressing internal and external issues
Determined issues whether internal or external do not necessarily require taking actions to address them. Basically, the information about the context is input for planning your Environmental Management System.
Also for internal and external issues, is it enough to that I rated each of them based on severity and occurrence, made an action plan for each item, and significance. Is that enough?
Internal and external issues are not environmental aspects and they do not require evaluation and taking actions like for environmental aspects. All the organization needs to do is to define context of the organization and all further steps in implementation of the standard will be affected by the context of the organization.
I agree. 8.5.5 is not limite to warranty and servicing, but an over all responsibility toward the product.
SoA and Risk Treatment Plan
Thanks for the advice; I thought that was the case.
Documents to be reviewed during stage 1 audit
Answer:
The Stage 1 audit is often called a ‘documentation review’ audit because the auditor will review your documentation to establish whether it is in line with the requirements of the standard. This stage is more of a ‘reconnaissance’ audit, or a ‘pre-assessment’, whereby the auditor does a high-level review of your management system and establishes whether the internal audit programme is in place.
Stage 1 is completed on-site to determine whether your management system has met the minimum requirements of the standard and is ready for a certification audit. The auditor will point out any areas of nonconformity and potential improvements of the management system.
Documents to be reviewed during this stage of the audit are all the documents that belong to the scope of your management system, this includes documents required by the standard itself and the ones that the organization determined as necessary for effective maintenance of the manage ment system.
Answer: Unfortunately we do not have a template or tool covering specifically Information Security in Project Management, but there are many similarities with implementing an ISMS that you can use to drive the implementation of this control in a specific project:
1 - You have to define information security objectives and include them in the project objectives, the same way you define information security objectives for an ISMS aligned with organization's objectives, the only difference is that these objectives are restricted to the scope of the project
2 - You have to perform at the beginning, and periodically, information risk assessments in the project, like you would do it with other business processes, to identify necessary controls
3 - You have to ensure that information security practices are part of all phases of the project (e.g., from the issue of the project charter to project closing)
In short, you can think the inc lusion of information security in project management as if you are going to implement a small ISMS that will fit the projects needs and will be proportional to the project's lifetime and budget.
This article will provide you further explanation about Information security in project management:
- How to manage security in project management according to ISO 27001 A.6.1.5 https://advisera.com/27001academy/what-is-iso-27001/
I advise you to look for a legal expert to provide information about related laws, standards and regulations in these regions, because these are the main sources that motivate the development and adoptio n of certificates.
Answer:
Most probably the question is about proactive and reactive Problem management.
Reactive Problem Management is reaction to created Problem Record, usually based on an incident. So, Problem Management is triggered to do something (find a root cause of one or more incidents).
On the other side, Proactive Problem Management is usually carried out in scope of Continual Service Improvement and means - "let's see if we can find some common pattern in incident/problem history in order to prevent future incidents".
- Software tools are more expensive, but provide you more control and management capabilities, like access control and searching functionalities.
- Templates are cheaper and more adequate to work with non-structured information (like policies text), but they are less efficient and effective in large environments.