Internal audit is a tool to gauge the health of your QMS. You must have a documented procedure for your internal audit process. Your procedure must address the following control requirements:   The scope of your internal audit program must cover:  Audit of the QMS – to determine conformity to the IATF 16949 standard;  Audit of the QMS – to determine conformity to organizational requirements; Audit of QMS processes and their interaction – to determine if the QMS has been effectively implemented and maintained;Audit of each manufacturing process to determine its effectiveness; Audit of product across all stages of production and delivery- to determine conformity to requirements specified by the customer and regulatory bodies. All shifts involved in activities affecting product or process quality. Note that there may be shifts for manufacturing processes as well as support processes.   You must adjust the audit frequency (and perhaps even the audit scope), of specific QMS processes; manufacturing processes; shifts; and products when:

• You experience internal or external nonconformities 
• Get customer complaints 
• Have critical or high risk processes 
• Have frequent or significant changes to processes and product 

    OEM customers may also specify the scope, frequency, criteria, responsibility, etc of internal audits. Your annual internal audit program should consider the following:

• Input from audited area and related areas
• Key customer oriented processes
• Process and product performance results and expectations
• Analysis of quality cost data
• Capability of processes and use of statistical techniques
• Effective and efficient implementation of processes (lean manufacturing techniques)
• Opportunities for continual improvement
• Relationships with customers 

Over the Certification Body’s (or Registrar) audit cycle (3 years), the CB must audit all of your organization’s processes and their applicable customer-specific requirements.  Your internal audit program should be more detailed and exhaustive than the external CB audit. With this outlook in mind, your internal audit program should consider auditing all your QMS processes at least once within the CB 3 year audit cycle (preferably once a year) and some processes more often based on the criteria covered above.  The design process (whether onsite of off-site) should be audited at least once within each consecutive 12 month period. Your internal QMS audit program should include all off-site processes and subcontract ‘sites’ that support your facility. These audits may be done by others, such as head office, sister facility or qualified subcontract auditors.Audit criteria , refers to the specific QMS policies, objectives; IATF  requirements; documentation; customer and regulatory requirements, etc., that the audit is referenced to or conducted against. Audit criteria may relate to the whole audit program as well as each individual audit. Audit methods refer to the specific techniques that auditors use to gather objective audit evidence that can be evaluated to determine conformity to audit criteria . Examples of audit methods include – interview of personnel, observation of activities; review of documents and records; etc.The qualification/training requirements may vary for the different types of audits required by this standard. You must define the minimum qualification/training requirements for internal auditors for each type of audit : 

• Personnel performing QMS audits or manufacturing process audits must have adequate training on
  • the requirements of the IATF 16949 standard;
  • training on the automotive process to auditing;
  • audit practices and audit experience as defined by ISO 19011 and IATF guidance;
  • QMS processes and their interaction; customer requirements and applicable regulatory requirements.
• Personnel performing product audits must have training on
  • production and delivery processes;
  • audit practices and techniques; p
  • product specific customer requirements and
  • applicable regulatory requirements.

Product specific auditors do not necessarily need training on the requirements of the TS 16949 Standard.  You must have appropriate resources to carry out your annual audit program. These include – having sufficient trained auditors available to conduct scheduled audits; sufficient time to perform audits; availability of process personnel to be audited; time and tools to prepare audit records and reports; etc.  

Auditor Independence – Auditors can audit their own department provided their objectivity and impartiality is not compromised, but they cannot audit their own work. You must ensure auditor independence when assigning personnel to specific audits.  

Process owners must take timely corrective action on nonconformities found in their area. They should use the corrective action procedure (clause 8.5.2) to determine root cause, take action and follow-up to determine if results indicate that the root cause has been eliminated.

Audit results must be summarized and reported for management review . The Management Representative must also report any opportunities for QMS improvement . The MR must analyze the results of each audit as well as the annual audit program to determine strengths and weaknesses in QMS processes, interactions, functions, products, etc., to identify and prioritize opportunities for improvement.  Audit records include – annual audit schedule; audit planning- (criteria, scope, frequency, methods, auditor selection and assignment, etc); auditor competence and training; audit checklists and forms; audit notes and other evidence gathered; audit findings; nonconformity reports; audit reports; corrective actions and follow-up of internal audit nonconformities; analysis of audit program performance indicators and trends; and identified improvement opportunities.  Like all QMS processes , you must have performance objectives (indicators) to measure the effectiveness of your internal audit process and monitor trends in these indicators, to continually improve your audit program. Performance indicators may include reducing the number of – late or delayed audits; incomplete audits; incomplete audit records and late reports; auditor errors; auditee complaints; and use of untrained auditors; etc.  T

9.2.2.1 Internal audit programme

The organization must have a documented internal audit process. The process is to include the development and implementation of an internal audit program that covers the entire quality management system including quality management system audits, manufacturing process audits, and product audits. The audit program are to be prioritized based upon risk, internal and external performance trends, and criticality of the process(es). Where the organization is responsible for software development, the organization must include software development capability assessments in their internal audit program. The frequency of audits are to be reviewed and, where appropriate, adjusted based on occurrence of process changes, internal and external nonconformities, and/or customer complaints. The effectiveness of the audit program is to be reviewed as a part of management review.

The standard requires the supplier to establish and maintain documented process for planning and implementing internal quality audits. The standard requires process for both planning and implementing audits and these should cover the following:

• Preparing the annual audit program
• The selection of auditors and team leader if necessary
• Planning audits Of each type
• Conducting the audit
• Recording observations
• Determining corrective actions
• Reporting audit findings
• Implementing corrective actions
• Confirming the effectiveness of corrective actions
• The forms on which you plan the audit
• The forms on which you record the observations and corrective actions
• Any warning notices you send out of impending audits, overdue corrective actions,
  escalation actions

Certain activities such as the opening and closing meeting have been omitted for clarity because they are not always needed for internal audits. The product audit process would be somewhat different but the principles would be the same. There audits should be comprehensive and there is a need to ensure that the audit program covers all aspects of the quality system in all areas where it is to be employed. The coverage of the audit program should be designed so that it obtains sufficient confidence in operations to be able to declare that the system is effective. There may be a need for different types of audit programs depending on whether the audits are of the quality system, processes, products, or services. The audit program should be presented as a calendar chart showing where and when the audits will take place. All audits should be conducted against a standard for the performance being measured. Examinations without such a standard are surveys, not audits. Audits can also be conducted against contracts, project plans, specifications — in fact any document with which the organization has declared it will comply. The standard now requires system audits to be conducted to verify compliance with IATF 16949 and any other system requirements. In order to ensure that your audit program is comprehensive you will need to draw up a matrix showing what policies, procedures, standards, etc. apply to which areas of the organization. The program also has to include shift working so your auditors need to be very flexible.

Internal audit for entire Quality management system

Developing and implementing an internal audit program for the entire quality management system, including quality management system audits, manufacturing process audits, and product audits, is a crucial step in ensuring that an organization maintains a high level of quality and compliance. Define the scope of the internal audit program, which should cover all aspects of the quality management system, including manufacturing processes and products. Clearly outline the objectives of each type of audit, such as ensuring compliance with regulations, identifying process improvements, and verifying product quality. Assemble a team of skilled and knowledgeable individuals from different departments who will conduct the internal audits. The team should include personnel who are independent from the areas being audited. Develop audit criteria and checklists based on applicable standards, regulations, company policies, and industry best practices. These will serve as guidelines for the auditors during the assessment process. Develop an audit schedule, identifying the frequency and timing of audits for different areas of the quality management system. Prioritize high-risk areas and critical processes for more frequent audits. Perform the internal audits according to the established schedule and using the criteria and checklists. The audit team should conduct interviews, review documentation, observe processes, and collect objective evidence to assess compliance and effectiveness. During the audits, document any non-conformities or deviations from the established criteria. Also, identify opportunities for improvement in processes or products. Prepare detailed audit reports that clearly outline the findings, including both positive aspects and areas for improvement. Communicate the results to the relevant stakeholders, such as process owners and management. Work with the respective departments to develop and implement corrective actions for identified non-conformities. Ensure that appropriate actions are taken to address the issues raised during the audits. Follow up on the implementation and effectiveness of the corrective actions. Use the findings from the internal audits to drive continuous improvement in the quality management system. Identify systemic issues and develop plans to address them. Regularly present the results of the internal audit program to top management during management review meetings. Seek feedback and support from management in addressing identified issues and improving the quality management system. Provide training to the audit team to enhance their auditing skills and knowledge. Ensure that auditors are competent and up-to-date with relevant regulations and standards. Continuously monitor the effectiveness of the internal audit program and make adjustments as necessary. Keep the program up-to-date with changes in regulations, company processes, and best practices.By following this process, an organization can ensure that its internal audit program contributes to the improvement of the quality management system, manufacturing processes, and product quality, ultimately leading to enhanced overall performance and customer satisfaction.

Prioritizing the audit program

Prioritizing the audit program based on risk, internal and external performance trends, and criticality of the processes is a strategic approach to ensure that resources are allocated effectively and that audits focus on the areas that have the most significant impact on the organization. Conduct a comprehensive risk assessment of the organization’s processes, products, and quality management system. Identify areas with the highest risks, such as those that could lead to safety hazards, compliance violations, or significant financial losses. Allocate more frequent and thorough audits to high-risk areas. Analyze internal performance data and metrics to identify trends and areas of concern. This could include data on customer complaints, product defects, process deviations, and internal non-conformities. Focus audits on areas that consistently show performance issues or have experienced recent declines in performance. Monitor external performance data, including customer feedback, industry benchmarks, and regulatory compliance reports. Identify any external indicators of potential problems and include relevant areas in the audit program. Determine the criticality of each process within the organization. Critical processes are those that have a significant impact on the overall quality of products or services, customer satisfaction, or regulatory compliance. Prioritize audits for critical processes to ensure they are functioning optimally. Seek input from top management and relevant stakeholders to understand their concerns and priorities. Take into account their perspectives when prioritizing audits, as they may have insights into critical areas that require attention. Ensure that audits are scheduled to meet regulatory and certification requirements. Prioritize audits that are necessary for maintaining compliance with relevant standards and regulations. Consider the availability of resources, including personnel and time, when setting the audit schedule. Optimize the use of resources by aligning them with the areas of highest priority. Assess the potential impact of conducting audits on risk mitigation and improvement opportunities. Prioritize audits that offer opportunities for significant improvement and efficiency gains. Adjust the frequency of audits based on the factors mentioned above. High-risk areas or critical processes may require more frequent audits to ensure continuous monitoring and improvement. Continuously review and adapt the audit program based on the changing risk landscape and performance trends. Flexibility is crucial to respond to emerging issues and new priorities.By employing this prioritization approach, the organization can focus its internal audit efforts on areas that matter most, resulting in a more effective and efficient audit program that contributes significantly to the improvement of the quality management system and overall organizational performance.

Including software development capability assessments in audit program

Including software development capability assessments in the organization’s internal audit program is crucial for several reasons. As the organization is responsible for software development, ensuring the effectiveness and maturity of its software development processes is paramount to delivering high-quality software products and maintaining a competitive edge in the market. By conducting software development capability assessments, the organization can evaluate the efficiency and compliance of its development practices, identify areas of improvement, and mitigate potential risks.Firstly, software development capability assessments enable the organization to gauge the proficiency of its development teams and processes. It helps in assessing whether the teams possess the necessary skills, tools, and resources to carry out their tasks effectively. By identifying any gaps or deficiencies, the organization can invest in targeted training and development initiatives, thus enhancing the overall competency of its software development workforce.Secondly, these assessments contribute to the improvement of software development processes. By evaluating the software development lifecycle, code quality, and adherence to best practices, the organization can identify bottlenecks and inefficiencies. This empowers them to implement process improvements, streamline workflows, and adopt industry-standard methodologies, leading to faster delivery cycles and higher-quality software.Thirdly, software development capability assessments assist in ensuring compliance with relevant standards and regulations. Regular assessments help in verifying compliance, mitigating potential legal and financial risks, and building trust with customers and stakeholders.Moreover, these assessments provide valuable insights into the security and reliability of the software being developed. By conducting code reviews, vulnerability assessments, and security audits, the organization can proactively identify and address security flaws before software products are deployed to customers.Ultimately, integrating software development capability assessments into the internal audit program reinforces the organization’s commitment to continuous improvement. It fosters a culture of quality, innovation, and risk management within the development teams, enabling the organization to deliver cutting-edge software solutions that meet customer expectations and drive business success.

Review in MRM

Reviewing the effectiveness of the audit program as part of the management review is a critical aspect of maintaining a robust and successful internal audit process. The management review is a strategic and high-level meeting where top management assesses the overall performance of the organization, including its quality management system and related processes. By including the audit program in the management review, the organization ensures that audits are aligned with the company’s objectives and contribute effectively to continuous improvement. The audit program’s effectiveness is evaluated during the management review to determine how well it is achieving its intended goals. This includes assessing whether the audit program is identifying areas of non-conformity, opportunities for improvement, and whether corrective actions are being implemented in a timely manner. Management review provides an opportunity to assess whether the resources allocated to the audit program, such as personnel, time, and tools, are adequate and properly utilized. Any adjustments needed to optimize resource allocation can be addressed during this review. The management review allows the organization to analyze whether the audit program adequately addresses high-risk areas identified in the risk assessment. It ensures that the most critical processes and areas are audited more frequently and with greater rigor. Top management can review the audit program’s performance in meeting regulatory requirements and industry standards. This helps to ensure that the organization remains compliant with relevant regulations and maintains any necessary certifications. Management review provides insights into how the audit program contributes to the organization’s overall improvement efforts. It helps identify areas where the audit process can be enhanced, and it ensures that audit findings are used effectively to drive positive change.Management review includes an assessment of the effectiveness of corrective actions taken in response to audit findings. This ensures that identified issues are adequately addressed and that improvements are sustained over time. Reviewing the audit program during management review allows top management to hold responsible parties accountable for the execution and outcomes of audits. It encourages open communication and commitment to the audit process across the organization. By integrating the audit program into the management review, the organization ensures that audits are aligned with its strategic objectives. It helps focus audits on areas that have the most significant impact on achieving organizational goals.

1.0 Objective :

To define a System for setting of Information Security Objectives/Key Performance Indicators (KPIs) and monitoring them for achievement.

2.0 Scope :    

Relates to Objectives/KPIs related to Information Security for all the key functions of  XXX

3.0 Responsibility:   

• CISO     
• Department Heads

4.0     Procedure:

Setting of Objectives /Key Performance Indicators

Management of XXX shall set yearly Information Security Objectives/KPIs for all the Departments . Department Heads  sets own objectives  based upon the risk assessment . The Information security objectives /KPIs fall into 5  broad  categories :

1. IT and business alignment
2. Information security risk management process
3. Compliance processes
4. Awareness process
5. Audit processes

            It is ensured that the Objectives are in line with the Corporate policy for Information Security Management.

   Information Security  Objectives  for departments

The Department Head of each section/department sets up Information Security Objectives  and are communicated to all the key members of the team. Defined objectives cover:

•  Measurable targets
• Time frame to achieve the targets 
• Plan of action for achievement of the Objectives.

Monitoring of Objectives

Monitoring of  Objectives  is done by Department Heads  and the frequency of review is set by the  Department Head , for each objective / KPI and  are usually half-yearly. The achievement of Objectives is reviewed on a six monthly basis and are recorded in the Objectives Review Report . The objectives review details are consolidated and discussed in the Management Review Meeting attended by the higher Management.

5.0 Records:

1. Objectives and their Review Records  ( F-08)
2. Management Review Meeting Minutes. ( F-10)

 6.0 References:  

     Nil 

Example of Objective

1. IT and business alignment

Objective	Method/sources	Targets	Justification	Findings	Justification	Action plans
% of business strategic goals and requirements supported by information security strategic goals and decisions.	Review business strategic decisions and ensure that they have been risk-assessed in relation to IT and information security issues. Likewise all major information security strategic decisions should be reviewed and approved by upper management to ensure alignment with business services and strategies.	100%	All business decisions need to be supported by IT decisions and specifically information security issues. If not relevant, this needs to be documented and approved as part of the project phase.	50%	Our latest outsourcing and IT procurement decisions have not been aligned with our IT strategy and specifically not with information security requirements.	Ensure that IT requirements are mandatory on the agenda and all relevant information security requirements and potential issues are identified and addressed.
Level of business (stakeholders) satisfaction with offered information security services and internal support. Does information security bring value to the stakeholders?	Data collected through interviews or survey forms sent to relevant stakeholder of each business unit, business process or similar.	High	Our baseline is above average e.g. high level of satisfaction with offered information security services (scale going from low over medium, high, to excellent).	High	Compared to last year we have increased the level of satisfaction from medium to high.	No action plans
Percentage of executive management roles with clearly defined accountability for information security decisions.	Review job roles and descriptions to ensure that responsibility and accountability has been defined and communicated.	80%	It’s important that management and, in particular, business unit owners and IT-systems owners have clearly defined roles and accountability. We are planning to increase the numbers from 50% to 80% this year and next year ensure 100% coverage.	85%	We are on target this year with 85%	No action plans
% of changes to the information security strategy that is approved by management.	Review current information security strategy or major information security strategic decisions and ensure that management has formally approved them.	100%	All information security strategic decisions need to be approved by management.	75%	Some IT-strategic decisions to outsource critical IT-systems during 2022 were not risk assessed or approved by management.	Ensure that all major IT-strategic decisions are management approved. Establish some baseline requirements for management approval. For example: 1) Critical IT-services 2) Sensitive data? 3) Specific information security issues 4) Budgetary scope 5) Conflicts with business strategies

2. Information security risk management process

Objective	Method/sources	Targets	Justification	Findings	Justification	Action plans
% of business processes and their-services covered by the risk management process.	Interviews and correlation with management.	50%	Depending on current maturity level of an organisation it could be all or only some of the business processes/IT-services. Extending coverage could be part of a maturity process.	40%	Four critical business processes have not been subjected to a BIA	We need to find out if it’s a resource problem or poor risk planning
% of approved risk treatment plans actually being implemented compared to last risk assessment.	Correlate with previous risk assessment reports.	100%	We need to ensure that proposed and approved risk treatment plans are carried through and not forgotten or “saved for later”.	60%	Only 60% of the approved action plans have been implemented this year. This is a drop on 20% compared to last year.	Training of risk treatment to the team. Identify the root cause for e.g. is it financial issue, lack of ownership or other factors.
Are significant organisational or technological changes being reflected in the latest risk assessment?	Interview and review of risk assessment reports.	100%	All major technological shifts (IT- procurement, investments, outsourcing, etc.) need to be reflected in the IT-risk assessment.	100%	Our use of cloud outsourcing services and the approval of BYOD has been included in the IT-risk assessment.	No action plans
% of IT budgets used to manage IT risk management processes.This requires information security spending to be documented	Correlate total man-hours spent on risk assessment process with total IT-budget.	No value	Target could be just to track spending on IT-risk management processes. The metric doesn’t necessarily need to define a maximum % of IT budget or information security budget.	15%	Budgets and time spend on the IT-risk assessment process have increased 15% since last assessment.	Further analysis needs to be done. Causes can range from: 1) Changes in the methodology 2) Resource issues 3) Increase in number of identified risks (correlate with other metrics)
Number of new threats and risks identified compared to previous risk assessment.	Compare total numbers of risks/vulnerabilities, and/or criticality level with previous IT-risk assessments.	0	We need to reduce our risk posture and ensure that prior risks and vulnerabilities don’t reoccur.	7	The total number of critical risks/ vulnerabilities is slightly increasing, but the number of recurrent risks/ vulnerabilities has decreased, which indicates that we have effectively addressed prior IT-risk assessment identified risks.	Further analysis needs to be done. Causes can range from: 1) Changes in the methodology 2) Resource issues 3) Increase in number of identified risks (correlate with other metrics)
Tracking changes to risk appetite. Does it increase or decrease? Can we correlate it to strategic, organisational or financial decisions?	Look at changes to risk threshold. Arguments for rejections and approvals of action plans would also be a source. Correlate that with strategy changes, technology changes, security incidents, organisational changes, etc.	No change	Changes to risk appetite should be recorded as part of management reporting along with explanation of possible reasons.	Decrease	Our risk appetite has decreased this year compared to last year.	Analyse why risk appetite has changed.
Level of satisfaction with risk outcome from business perspective. This could be the risk outcome from the BIA, vulnerability assessment or action plans. The business needs to review the quality and output of the BIA to ensure data is correct. Measurement scale: not satisfied, acceptable or very satisfied.	Interviews or self-assessment questionnaire.	Very Satisfied	We need a high level of satisfaction (very satisfied) with the risk results from the BIA’s and vulnerability assessments.	Acceptable	Input from business owners, system owners and IT operations suggest that the results were not aligned with their expectations. There were too many errors in the assessments and especially in relation to the maturity assessment of IT- controls.	We need to ensure that the people performing the risk assessment are adequately competent and internal review of results must be done before final reporting.

3. Compliance processes

Objective	Method/sources	Targets	Justification	Findings	Justification	Action plans
Number of non-compliance issues and derived costs per year (e.g. external requirements, policies and procedures)	Reviewing end-of-year reported incidents including major external audit findings	0	No major non-compliance issue with either financial or image impact.	1	We had a data breach by our outsourcing vendor	Review relevant IT-security processes and vendor contract.
Time between identification of non-compliance and implementation of fixes. Helps identify problems with the efficiency of the compliance process.	Correlate time of reported non-compliance issues of security incidents with actual implementation time.	0 cases	Depending on the complexity, the issue needs to be addressed within two working days.	2 Case	We had two incidents that still haven’t been resolved.	We need to evaluate the effectiveness of the internal compliance department. Do we need to restructure the process? Are there any resource constraints or internal opposition?
Costs for fixing non-compliance issues such as administrative work in relation to fixing the problems (process optimization, procedures, policies or IT controls).	Review total costs associated with fixing non-compliance with annual IT-budget.	20% (max)	Under normal circumstances, there is a maximum of 20% of IT-budgets allowed for addressing security related issues.	more then 20%	Costs relating to non-compliance issue exceed the 20% limit. This includes performing a new pen-test and reworking of policies with the assistance of external consultants.	Has a business case and cost-benefit analysis been performed? Who has reviewed and approved the spending?
Total costs due to reputation loss, financial fines, loss of clients, etc.) Per compliance incident.	Review total impact costs associated with compliance issue.	0%	Recording the total cost and comparing this with last year. The target is not to have an increase in costs, but a decrease.	Reduction by 15%	Total cost associated with this year’s compliance incidents has decreased by 15 % and there was 1 less incident.	No action plans

4. Awareness process

Objective	Method/sources	Targets	Justification	Findings	Justification	Action plans
% deviation when comparing established success factors for awareness campaigns with the results of implemented campaigns.	Comparing results from awareness/ training program with results of physical audits or employee quizzes/tests.	80%	he goal was to ensure that minimum 80% completed the test/quiz following the campaign. Physical inspection of work areas shows a significant decrease in physical sensitive work paper, unlocked workstations, USB devices, etc.	60%	Less than 60% answered correctly on the mobile device policies and use of cloud-services. During our internal audit, we discovered unlocked workstations and customer-sensitive documents lying in the printer room.	We need to re-evaluate the way we present the message. Perhaps we can make it more story-driven and be better at using the intranet.
Are awareness plans/ strategies/sessions/courses, etc. aligned with information security risks currently of concern to the organisation?	Correlate awareness/training programs and strategy with current risk posture (results from risk assessment, external requirements, security incidents, technological changes, audits, etc.).	Yes	There needs to be a direct link between focus-areas of awareness/training and current risk posture.	No	The awareness strategy has been arbitrarily chosen more based on security trends and media talk than actual risks relevant to the organisation.	We need to ensure that it’s derived from relevant risks to our organisation.
% of IT users who have visited the security awareness intranet site so far this month.	Document the monthly visit rate on the information security section of the intranet.	70%	Our average visit rate must not fall below 70%.	90%	The last update with the malware alert was seen by 90% of IT-employees	No action plans
Cost-effectiveness of the awareness and training program E.g. can we detect a reduction in security incidents with financial impact, impact to intangibles (image/reputation).	Compare security incident before/ after awareness/ training efforts. This could also include physical observations of related employee behaviour, number of support calls or input from network security (IDS, IPS, content filtering or policy violations). Other sources: Results from audits.	Decrease	We must be able to detect a reduction in security incidents following our awareness/training programs.	Decrease	All approved follow-up plans have been implemented.	No action plans
Retention of key awareness messages % of employees that remember awareness messages. Can be measured by doing tests/quizzes on prior awareness campaign themes.	Compare results of tests performed a short time after completion to test run after a longer period of time e.g. 2- 6 month.	60%	Success rate of 60% of employees remembering prior awareness/training themes.	less then 50%	The knowledge of the topics drops dramatically after 6 months, compared to tests run after completion of awareness training.	We need to maintain awareness and knowledge on important security themes by increasing the frequency of awareness initiatives.

1.0 Purpose

The purpose of this procedure is to continually improve the suitability, adequacy and effectiveness of the established ISMS. continual improvement requires measuring the effectiveness and efficiency of technology, people and processes and adapting to inevitable changes in the environment – technical, organisational or otherwise

2.0 Scope

This procedure applies to continual improvement in the ISMS for all identified processes

3.0 Responsibility:

3.1 Department/section heads: To identify the “areas of improvement” and to implement the improvement in the section after getting the approval from the Top Management.

3.2 Management representative: To remind the department/section heads/process owners about the continual improvement and request to present the status to the Top Management

3.3 CISO : To approve the continual improvement plans which may improve the Information Security management system. To ensure that there is adequate resources for the plan and to monitor the status reports from the department/ section heads/process owners.

4 Procedure:

The respective department/section heads shall identify the areas for improvement based on the policy, objectives and strategic plans of the organization. The areas of improvement shall be based on:

• improvements in strategy (i.e. why things are done): Improving strategy improves or maintains the suitability of an ISMS and requires improving knowledge and understanding of the environment and threat landscape.
• improvements in practice (i.e. what is done): Improving practice can increase the effectiveness of the ISMS and resulting security controls.
• improvements in process (i.e. how things are done):Improving processes can increase the efficiency of controls and surrounding processes.

Improvements can be made in the short or long term. However most improvements will follow the process below:

• Identify opportunity for improvement.
• Identify root cause (as applicable).
• Allocate responsibility for implementing change.
• Identify, analyse and evaluate (based on cost vs benefit) possible solutions.
• Plan implementation of changes.
• Implement changes.
• Measure effectiveness of actions

4.1 Steps in an improvement process

Process	Example activities
1.Define what you should measure	Identify technical, operational and strategic goals Define what you will measure
2.Define what you can measure	Scoping Risk assessment and risk treatment plans Identify the strategy for improvement
3. Gather the data 4. Process the data	Implement improvement plans Implement controls, services monitoring etc.
5. Analyse the data	Analyse gathered data (e.g. from monitoring) Carry out gap analysis Internal and external audits
6. Present and use the information 7. Implement corrective action	Implement corrective actions and fixes; Record lessons learned Feed back and report

The departmental/section heads shall identify and document the areas of improvement in the Continual Improvement Plan (F 012) form and send it to the management representative (MR) for review. The management representative (MR) shall review and send the plan to the CISO for final approval. Respective departmental personnel shall make prioritized action plan for the areas of continual improvement and the same shall be followed to complete the assignment in time. Respective departmental/section head shall review the status of the continual improvement plan. and the status of the plan shall be presented to the management during management review meetings. The effectiveness of continual improvement plans shall be monitored and reviewed periodically and the same shall be discussed in MRM.

4.2 Sources of information and opportunities for improvement

Opportunity for improvement	Sources of information
Organisational changes	Meetings with top management Departmental/organisational announcements, news bulletins etc.
Changes in business requirements/circumstances	Third party requirements Public media and news Security/business conferences Team meetings Management reviews Service reviews
Change in security requirements	Policy reviews Information security incidents Service requests Change requests Bulletins and announcements
Changes in regulatory environment	Notifications from suppliers Notifications from third parties Notification from statutory bodies e.g. the Information Commissioner’s Office Internal security forums Security mailing lists
Contact with Special Interest Groups	Security conferences and community meetings Security mailing lists
Changes in skill sets	Recruitment of new staff Knowledge gained from training
User/customer engagement	Service requests User satisfaction surveys Knowledge bases
Service requests	Service desk management tools Knowledge bases
Risk assessments	Risk assessment outputs Gap analysis reports
Vulnerabilities	Vendor vulnerability announcements Security community mailing lists Results from penetration testing and vulnerability scanning Log files Service requests and notifications from users/customers
Information security incidents	Intrusion detection/prevention system alerts Log files and network flows Knowledge gained from analysing and resolving incidents
Internal audit and review	Review meetings Policy reviews Audit reports Vulnerability scanning and penetration testing reports Security reviews
External audits	Review meetings Audit reports Vulnerability scanning and penetration testing reports Security reviews

5 Reference:

Continual Improvement Plan

1. SCOPE

This procedure applies to all the activities within the scope of the XXX Information System Management System.(ISO 27001:2022 )

2. PURPOSE

2.1 To ensure that top management systematically reviews the ISMS and its performance in accordance with the established operating procedures.

2.2 To review the adequacy. suitability. and effectiveness of previous corrective and preventive actions including those related to outsourced service and supplier performance.

3.3 To identify strengths and opportunities for improvement and make recommendations for continual improvement.

3. REFERENCE DOCUMENTS

3.1 XXX Information Security Management system Manual,
3.2 Procedure for Internal ISMS Audit.
3.3 Procedure for Non Conformity & Corrective Action

4. TERMS & DEFINITIONS

4.1 Management Review: cross-functional review by an organization’s top management which takes place at regular intervals aimed to assess the organization’s success at achieving objectives established thus ensuring its continued suitability, adequacy, and effectiveness and to take action to correct it when necessary.

4.2 ISMS Objective: A statement describes what should be achieved within the time frame and available resources. It shall be consistent with the evidence-based practice and the visions that the institution creates itself to achieve.

4.3 Audit: A systematic, independent, and documented process for obtaining audit evidence (records, statements of fact, or other information which are relevant and verifiable) and evaluating it objectively to determine the extent to which the audit criteria (set of policies. procedures, or requirements) are fulfilled.

5. RESPONSIBILITY AND AUTHORITY

The following will be responsible for the process of preparing for the Management Review Meeting :
5.1 CEO :
5.1.1 Assure the implementation of the MR policy
5.1.2 Chair the MR meeting
5.1.3 Invite members of the top management to the meeting
5.1.4 invite other categories of staff as per necessity (e.g. quality focal points, internal auditors)
5.2 CISO and Staff of department:
5.2.1 Set in coordination with the Director, the date and time of the meeting.
5.2.2 Prepare and present the agenda of the meeting according to the agenda stated above.
5.2.3 Take the list of attendance.
5.2.4 Make minutes of the meeting that includes discussion points raised with the suggestions as well as the decisions that have made during the output session.
5.2.5 Follow-up the decisions that have been taken during the output discussion.
5.2.6 Follow-up the implementation of the MR.

6. DETAILS OF PROCEDURE

6.1 Attendants:

6.1.1 Top management review meeting shall be held once a year . The meeting is allocated a maximum of 2:30 hours. The distribution is according to the following:

1 hour: presenting the review input.
30 minutes: questions and answers
1 hour: review output (it is recommended that this section is attended by the CEO, CISO, directors, and  heads of departments)

6.1.2 The Management review meeting to be chaired by CEO or CISO in case CEO is not available. In case CEO is not available, CISO must brief the CEO the finding and the output of the meeting with the CEO.

6.2 Agenda of MR:

6.2.1 Review Input: this part of the review shall include information on:

1. Follow-up actions from previous management reviews.:This refers to all issues raised or resolved since the last review to make sure problems are being resolved properly. and to look for trends in the data. The action which was taken as result of the previous MRM must be reviewed. It must be verified that all the actions have been taken and also the effectiveness of the action taken must be verified. In case the the action was not completed or was found not to be effective, the root cause must identified and corrective action should be taken.
2. Changes in external and internal issues that are relevant to the Information Security management system.
3. Changes in needs and expectations of interested parties that are relevant to the information security management system;
4. Status of non conformity and corrective actions. This refers to reporting of steps that have been taken to manage failures detected as well as steps to avoid the occurrence of any potential problems that are likely to rise.
5. Process and result of performance monitoring and measurement. This refers to reporting whether XXX is reaching and/or maintaining performance targets.
6. Results of audits. By reporting the results of audits carried during the previous period (internal and external). It should include the presentation of data analysis showing strengths and opportunities for improvement in the system.
7. Information Security objectives: This refers to the Information Security objectives which was established during the previous MRM. The review must verify if the objectives were met and incase they were not met what was the root cause that it was not met and what corrective action was taken . Also the Information Security objective for the next year must be established based on the audit findings and the result of the performance monitoring and measurement.
8. Feedback from Interested parties . Through analysis of reporting results of feedback from Interested parties that have been collected through various channels such as satisfaction surveys and compliments and complaints system. The reporting should look closely at both the negative and positive feedback.
9. The result of the Event and Incident Reporting System and analysis.
10. The effectiveness of actions taken to address risks as a result of risk assessment and the status of the risk treatment plan:
11. Opportunities for continual improvement. This refers to proposing corrective and preventative actions to be taken based on the outcome of the review of the system carried out since the last MR in order to improve the quality of ISMS.

6.2.2 Review Output: This part of the review shall be allocated to discuss and decide on actions to be taken to improve the management system, services/ processes. and resource needed. The output shall include any decisions and actions related to:

1. Improvement of the effectiveness of the Information management system and its processes. This refers to the fact that based on the information that has been discussed whether there are areas where worthwhile improvements can be made.
2. Any need for change in Information Security Management System

6.3 Forms and records of the review:

The record of the review will be maintained by the IT department and a summary report of the meeting will be sent to the Management Representative.

7. RETAINED DOCUMENTED INFORMATION

7.1 Management Review record (ISMS F027)
7.2 Data analysis reports. (ISMS F028)
7.3 Management review agenda and minutes(ISMS F029)

1.Purpose

The purpose of this procedure is to:
● Ensure protection of sensitive information regarding ISO 27001
● Provide system and instructions.
● Assign responsibilities for identifying training needs.
● Provide the required training for establishing awareness programs. And
● Maintaining training records.

2. Application

This procedure applies to all training and awareness programs.

3. Scope

All employees (classified, hourly, contractors, business partners)

4. Procedure

4.1 General

• The objective of training program is to ensure that employees possess the required knowledge and skills for performing their jobs; and that they are familiar with relevant requirements of the information security systems pertaining to their job functions.
• Awareness programs focus on understanding the importance of customer requirements, and the relevance of individual contributions towards meeting these requirements and achieving the security policy and objectives.
• Employees are made aware of the types of device defects which may occur from the improper performance of their specific jobs.

4.2 Competence requirements, security and privacy awareness and training needs

• Company-wide training and awareness programs are provided to all employees, irrespective of their function and position in the company. These programs include general orientation, rules and regulations, safety, and other such company-wide systems and issues. Compliance department with the SecOps unit and CISO are responsible for determining requirements and identifying training and awareness needs for company-wide programs.
• Training and awareness programs will be perform when there is environmental or operational changes affect the security of electronic PHI (ePHI), credit card information or other sensitive data, for examples new or updated policies or procedures, new or upgraded software or hardware, new security technology, or new threats or vulnerabilities to ePHI and/or credit card information, and at least once a year. The training and awareness programs which perform at least once a year, will include:
  • Protection from Malicious Software – Any employee who has access to ePHI, credit card information or other sensitive data must be trained to identify the symptoms of malicious software, and the procedures for reporting and controlling such problems.
  • Log-In Monitoring – employees should be trained to recognize discrepancies in log-in procedures, and technical safeguards must be in place to detect suspicious log-in activity. Routine monitoring of account activity, such as detecting repeated incorrect password entries should be performed, and know how to recognize when their accounts may have been accessed without their knowledge.
  • Password Management – employees should be trained in creating, changing and safeguarding secure passwords. This guidance in particular must be periodically reviewed to ensure it remains effective as password requirements change over time.
• Competence requirements and training needs for specific positions and jobs are defined in the Job Descriptions maintained by relevant departments, using Form Job Description.
• Training needs for individual employees are determined on the basis of their education, experience and job performance, including periodical evaluations conducted by Human Resources

5. Company-wide training and awareness programs

5.1 General orientation training:

Human Resources provides employee orientation training to all new and existing employees. This training familiarizes employees with administrative rules, employee programs and benefits, etc.; and explains the product, product requirements, and the information security system:

• Overview of the company’s information security system;
• Discussion of security and privacy policy; and
• Explanation of how individual employees can contribute to maintaining and improving the information security system.

Participation in the employee orientation training is recorded. These records are maintained by Human Resources

6.2 General orientation and information security system training:

• The CISO is responsible for promoting constant awareness for information security among the users of information systems.
• The Compliance Officer is responsible for issuing an awareness program at least once a year for information security which includes continuous awareness-training and updates. HR department is responsible for updating the Compliance department of incoming new employees (including their role, start date and employment emails). Compliance department is responsible for liaising with SecOps and the CISO to examine the most appropriate training courses as per certification/legal requirements and further based on the expert opinion of the CISO. Awareness for information security derives from constant exposure to security issues. The CISO is responsible for the allocation of training/marketing resources for security issues such as ePHI and/or credit card information including in the following issues:
  • Use of company-wide systems: Wide groups of employees are trained in the use of interdepartmental systems, such as part and material coding/numbering system, bar-code system, retrieval and creation of electronic (computer) documents and records, and so forth. Training is provided by the department that is responsible for the system. Training records are maintained by the department that provides training and monitored by the Compliance Officer to ensure enforcement.
  • Media Control: Training on media control covering removal and receipt of hardware/software including access control, accountability, data backup, data storage, mobile storage devices, and disposal of electronic data.
  • External training: Seminars, conferences, and other forms of external training. Requests for external training are evaluated and processed by Human Resources.
  • Self-study: The Company encourages personnel on all levels to read professional reports, magazines, and books. Requests for magazines and books are evaluated and processed by individual departments. Self-study is considered in formal recognition of skills as an alternative form of training. Where appropriate, self-study is recorded.
  • Report: Implementing an Incident response plan that helps employees identify potential incidents, and understand what steps to follow in the event of potential data breaches.
  • Document: Documentation of training is automated within the training monitoring tools which is supervised by the Compliance team

6.0 Training and Awareness Monitoring Tools

• Learning Management System: The Company uses a Learning Management System (“LMS”) to complete the equired training courses online customized to the specific department and role they fulfill.
• The courses are interactive and contain questions throughout that must be passed in order to receive the certificate for the specific course.
• Emails are automatically sent to employees on their first day of employment from the LMS platform to set up their individual accounts and with a link to the required courses. Employees are required to complete critical security related courses within 1 week of the start of their employment.
• Further retraining is required on a periodic basis (yearly and quarterly depending on the role within the company).
• The LMS sends reminder emails 3 days before the completion deadline to employees who have not completed the required training.
• An email is sent to the compliance department if the deadline has passed without completion of the required training. Further action will be taken if required

7.0 Departmental training

• As part of their training, personnel are made aware of device defects which may occur from the improper performance of their specific jobs. Also, personnel who perform verification and validation activities are made aware of defects and errors that they may encounter.
• On-the-job training, i.e. working under supervision of a more experienced employee, is provided to all personnel in any new or modified job affecting product quality. On the-job training is recorded, to include its scope, duration, and the name of the person who supervised the training.
• Employees who have been performing their jobs or functions for at least six months prior to the initial implementation of this procedure may have their qualifications formally confirmed by their supervisors or departmental managers, without having to go through the initial training. This confirmation is documented in a written statement,
• Including specific designation of the particular jobs and functions for which the employee is being confirmed. The confirmation record is equivalent to a training record, and is filed and maintained as such by Human Resources.
• Employees who do not perform satisfactorily are provided with additional or repeated training.

8.0 Training effectiveness evaluation

The method used for evaluation of effectiveness for each training activity will be proportionate to the risk involved in the work for which the training is provided. The following methods and approaches are used for evaluating the effectiveness of training provided:

• Follow-up evaluation of individual employees: Following competency or skill training, employees are evaluated by their supervisors or departmental managers. This evaluation assesses whether a particular training has achieved its objectives and if the employee is sufficiently competent and/or skilled to perform the new job function for which he or she was trained. Results of this evaluation are recorded and are kept together with the original training record.
• Review of overall performance in areas related to particular training: When wider groups of employees are trained in safety, emergency procedures, or interdepartmental systems, this type of training is evaluated by comparing statistical performance data from before and after the training was provided. For example, the effectiveness of safety training is measured by tracking rates of work-related accidents.
• Correlation of training with nonconformists and system failures: Training and competency are always considered when investigating causes of product and process nonconformities and failures of the information security system. When inadequate training is the cause, the investigation goes further to determine specifically which particular training is at fault. This training is then reviewed and improved, by changing its scope, format, or frequency, as appropriate.
• Global evaluation of training by management review: Training and awareness programs and their effectiveness are evaluated by management reviews. This includes presentation and discussion of data correlating information security performance in particular areas with specific training and awareness programs. Operational Procedure, Management Review, defines this process.
• LMS metrics: Employees must complete testing during the process of completing required courses within the LMS. Metrics are predefined to evaluate employee understanding of materials and to ensure an adequate level of comprehension based on the risk associated with each topic.

1 Introduction

This procedure describes the steps to be taken when a nonconformity is found within the Information Security Management System (ISMS). A nonconformity is defined by ISO as the “non-fulfillment of a requirement”.
This is a wide definition which basically means that the ISMS is not succeeding in its purpose, which is to fulfil the information security requirements of the organization. A nonconformity may arise for many reasons, in many forms and from many different sources. The purpose of this procedure is to ensure that they are recorded when they are identified and that the appropriate steps are taken to ensure that the immediate and wider actual and potential impacts of the nonconformity are addressed.
In addition to internal and external audits, non conformity may be identified from the day- to-day performance of procedures, management meetings and communication with suppliers, customers and other interested parties.

2 Nonconformity Management Procedure

2.1 Procedure Diagram

The procedure for identifying and managing non conformity is summarized in the diagram below. The detail of the steps is described in the following sections.

2.2 Identifying Nonconformities

Nonconformities may be identified from any source and the [Information Security Manager] will encourage staff, users, customers and suppliers to propose ways in which they can be addressed. Such nonconformities may be identified from:

• Security reviews
• Team meetings
• Supplier meetings
• Risk assessments
• User surveys
• Internal and external audits

However, the above is not an exhaustive list.

2.3 Add to Nonconformity and Corrective Action Log

Once identified, the nonconformity will be documented within the Nonconformity and Corrective Action Log with a status of “Open”. At this stage, the action to correct the nonconformity has not necessarily been determined. As much detail as possible should be specified as to the exact nature of the nonconformity.

2.4 React to the Nonconformity

If action needs to be taken to address the nonconformity immediately then this should be done without delay. This may be to fix it, stop it from getting worse or to reduce its effects until further action may be taken. Appropriate resources should be allocated to addressing the nonconformity depending on the current assessment of its seriousness. Actions taken should be recorded in the action log, with dates.

2.5 Cause determination

Once logged and initial reactive actions put in place, the nonconformity will be evaluated to assess its underlying cause i.e. why it has arisen. Other parties may be consulted during this stage to understand the mechanism and events leading to the nonconformity. The identified cause should be recorded in the action log with as much description as appropriate.

2.6 Assess potential impact

Once the cause is understood, a review should be undertaken to assess whether similar nonconformities already exist elsewhere within the ISMS and whether they could potentially arise in the future. The findings of this review should be recorded in the action log.

2.7 Implement corrective action

Once the cause and real or potential impact has been established, appropriate corrective action should be identified to address both the current situation and potential future impact of the nonconformity. The expected benefits of correcting the nonconformity should be sufficient to justify the resources required to achieve the corrective action. The details of the corrective action to be taken should be recorded in the action log, along with the timescale and person responsible. Dated progress updates should also be added when appropriate. Once corrective action has been completed the status of the nonconformity record within the Nonconformity and Corrective Action Log should be updated to “Review Pending” and the date of closure recorded.

2.8 Review effectiveness of corrective action

After a reasonable period of time (which will depend on the nature of the nonconformity and the corrective action) the effectiveness of the corrective action should be reviewed to assess whether it has fixed the issue, including its actual and potential impacts. If the benefits expected are not achieved, the reasons for this will be investigated as part of the regular management review meeting. If successful, the date and results of the review will be recorded, and the status of the nonconformity will be updated to “Closed”.

2.9 Amend ISMS if necessary

If the nonconformity is judged to have occurred due to a fault in the ISMS, it may be necessary to amend the ISMS itself, including any relevant policies, procedures and forms. This should be done with the agreement of top management.

1 Introduction

“Documented information” is defined by ISO as “information required to be controlled and maintained by an organization and the medium on which it is contained”. This term covers what used to be referred to as “documents and records” and for reasons of clarity this procedure still draws a distinction between these two types of documented information. The use of documented information is an essential part of the Information Security Management System (ISMS) in order to set out management intention, provide clear guidance about how things should be done and provide evidence of activities that have been performed. The ISO/IEC 27001 standard requires that all documented information that makes up the ISMS must be controlled to ensure that it is available and suitable for use, where and when needed, and is adequately protected. Such control is essential in order to ensure that the correct processes and procedures are in use at all times within the organization and that they remain appropriate for the purpose for which they were created. The general principles set out in the standard and adopted within this procedure are that all documented information must be:
➤ Readily identifiable and available
➤ Dated, and authorised by a designated person
➤ Legible
➤ Maintained under version control and available to all people and locations where relevant activities are performed
➤ Promptly withdrawn when obsolete and retained where required for legal or knowledge preservation purposes
This procedure sets out how this level of control will be achieved within XXX.

2 Document Control Procedure

This procedure applies to “documents” (as opposed to “records” which are covered later) which are generally created via a word processor (or similar office application) and describe management intention such as policies, plans and procedures.

2.1 Overview
The overall process of control for documents is shown in the diagram below.

Each of these steps is described in more detail in the remaining sections of this procedure.

2.2 Creation of Documents
The creation of documents will be at the request of the XXX management team and may be done by any competent individual appropriate to the subject and level of the document. However, there are a number of rules that must be followed when creating a document to be used in the ISMS.

2.2.1 Naming Convention
The convention for the naming of documents within the ISMS is to use the following format:

ISMS-DOC-xx-yy Document Title Vn Status dd

where:

• ISMS = Information Security Management System
• DOC = Document
• XX = Dept
• yy = Unique document number
• Document Title = Meaningful description of document
• Vn= Version n
• Status = Status of document (Draft or Final)
• dd = Number of draft, if appropriate

2.2.2 Version control

A unique number will be allocated for each document and an index of document references maintained within the ISMS Quality System.

Document version numbers will consist of a major number only e.g. V2 is Version 2.
When a document is created for the first time it will have a version number of 1 and be in a status of Draft. Each time a draft is distributed, any further changes will result in the draft number being incremented by 1 e.g. from 1 to 2.
For example, when a document is first created it will be Version 1 Draft 1. A second draft will be V1 Draft 2 etc. When the document is approved it will become V1 Final.
The version number will be incremented when a subsequent version is created in draft status.
For example, a revision of an approved document which is at V1 Final will be V2 Draft 1 then V2 Draft 2 etc. until approved when it will become V2 Final.
Documents must include a revision history as follows:

Version	Date	Revision	Author	Summery of change

Once the document reaches its final version, only approved versions should be recorded in this table.

2.2.3 Document Status
The status reflects the stage that the document is at, as follows:
Draft = Under development and discussion i.e. it has not been approved
Final =Following approval and release into live work environment

2.2.4 Documents of External Origin
Documents that originate outside of the organization, but form part of the ISMS will be allocated a reference and a header page attached at the front of the document, setting out information that is normally included in internal documents i.e.:

• Document reference
• Version
• Date
• Status
• Distribution

Such documents will then be subject to the same controls as those that originate internally.

2.3 Document Review

Draft documents will be reviewed by a level and number of staff appropriate to the document content and subject.
Guidelines are as follows:

Document Type	Reviewer
Strategy
Policy
Procedure
plan

Once approved, the date of next scheduled review should be recorded in the Information Security Management System Documentation Log.

2.4 Document Approval

All documents must go through an approval board to ensure that they are correct, fit for purpose and produced within local document control guidelines. The board will differ dependent upon the type of document and may go to numerous groups prior to being approved. In standard terms, approval boards are:

Document Type	Approver
Strategy
Policy
Procedure
plan

Each document that requires approval should have a table for the purpose as shown below:

Approval

Name	Position	Signature	Date

Once approved a copy of the document must be printed and signed by the approver. [Note – you may choose to do this electronically rather than by printing a copy]. This copy will then be retained in a central file
Upon approval of a new version of a document, all holders of previous versions will be instructed to obtain a new version and destroy the old one.

2.5 Communication and Distribution

A distribution list will be included as follows:
Distribution

Name	Title

This list must be accurate as it will be used as the basis for informing users of the document that a new version is now available.

2.6 Review and Maintenance of Documents

All final documents must be stored electronically and in paper format both locally and off-site to ensure that they are accessible in any given situation.
ISMS documents are stored electronically on the shared drive under the relevant sub-folder (e.g. Management responsibility, Management review etc.). The drive is a shared drive to which all appropriate members of XXX have access, in line with the published Access Control Policy.
Final documents are stored in paper format in a filing structure that mimics the electronic version. [State the location of the paper files].
A full copy of final documentation will be reproduced and stored within the Definitive Media Library.

2.7 Archival of Documents

Approved documents exceeding their useful life are stored in a Superseded Folder on the shared drive in order to form an audit trail of document development and usage. They should be marked as being superseded in order to prevent them being used as a latest version by mistake.

2.8 Disposal of Documents

Paper copies of approved documents that have been superseded are to be disposed of in secure bins or shredded, in line with agreed Asset Handling Procedures.

3 Records Lifecycle

This section describes the control of the type of documented information that generally shows what has been done i.e. is a “record” of activity, such as a completed form, security log or meeting minutes.

3.1 Identification

There is a variety of types of record that may form part of the ISMS and these will be associated with the specific processes that are involved, such as:

• Security incidents
• Change requests
• Configuration items
• Security event logs

In addition, there will be more general items such as meeting minutes which could apply across processes. In terms of identification, in many cases this will be dictated by the tool creating the record, for example a unique numbering system such as INC000001 for security incidents or CHG000001 for changes will be used by the tool.

3.2 Storage

Many records within the ISMS will be stored in application databases specifically created for the purpose e.g. the security incident database. For non-database records, a logical filing structure will be created according to the area of the ISMS involved. Where possible, all records will be held electronically; paper documents should be scanned in if an original electronic copy is not available.

3.3 Protection

Records held in application databases will be subject to regular backups in line with the agreed backup policy. File storage areas will also be backed up regularly, with all latest backups held at an offsite location. Access to the records will be restricted to authorised individuals in accordance with the XXX’s Access Control Policy.

3.4 Retrieval

Records will generally be retrieved via the application that created them e.g. the service desk system for security incidents and an event viewer for logs. Reporting tools will also be used to process and consolidate data into meaningful information.

3.5 Retention

The period of retention of records within the ISMS will depend upon their usefulness to XXX and any legal, regulatory or contractual constraints. Security- related service desk records are useful for historical trend analysis and so will be kept for a period of at least 7 years. Particular care will be taken where records may have some commercial relevance in the event of a dispute e.g. contracts and minutes of meetings with suppliers and these should be kept for the same length of time. Records that are particularly detailed and only relevant for a short period of time such as server event logs should only be kept as long as there is an immediate requirement for them. Specific retention periods are set out in the Records Retention and Protection Policy.

3.6 Disposal

Many systems provide for the concept of archiving and in most cases, this should be used rather than deletion. However, once it has been decided to dispose of a set of records they should be deleted using the appropriate software e.g. the service desk system will provide a facility to delete security incident records. If such records are held on hardware that is also to be disposed of then all hard disks must be shredded by an approved contractor.Paper copies of records that are to be disposed of should be shredded in line with agreed Asset Handling Procedures.

Purpose

The purpose is to ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered. The employees and contractors are aware of and fulfill their information security responsibilities. To protect the organisation’s interests as part of the process of changing or terminating employment.

Scope

The scope is to define the functioning of the XXX focusing on the manpower & IT that is used to run the XXX. This policy applies to all those personnel working in the XXX as staff, contractors and also covers the aspect where any staff who requires access to XXX’s information systems or information of any type or format (paper or electronic).

Human Resource Security Policy

3.1 Screening

• As per ISMS HR Procedure, Screening of the candidate shall be carried out for all candidates
• Information on all candidates being considered for positions within the XXX is collected and handled in accordance with Indian legislation existing in the Pune jurisdiction. Depending on applicable legislation, the candidates are informed beforehand about the screening activities.

3.2 During Employment

• All staff/contractors are to follow Clear Desk and Clear Screen Policy.
• Management responsibilities shall include ensuring that staff and contractors:
  • Are properly briefed on their information security roles and responsibilities prior to being granted access to confidential information or information systems
  • Are provided with guidelines to state information security expectations of their role within the XXX
  • Are motivated to fulfill the information security policies of the XXX
  • Achieve a level of awareness on information security relevant to their roles and responsibilities within the XXX
  • Conform to the terms and conditions of employment/association, which includes the XXX’s security policy and methods of working
  • Continue to have the appropriate skills and qualifications and are educated on a regular basis.
• If staff and contractors are not made aware of their information security responsibilities, they can cause considerable damage to the XXX. Motivated personnel are likely to be more reliable and cause fewer information security incidents.

3.3 Terms And Conditions Of Employment

• The agreement with staff and contractors states their and the XXX’s responsibilities for the functioning within the XXX and in relation to information security.
• The agreements for staff or contractors reflect the XXX’s policies for the functioning of information security in addition to clarifying and stating:
  • That all staff and contractors who are given access to confidential information are also briefed upon the guidelines of information security.
  • Responsibilities for the clarification of information and management of XXX’s assets associated with information, information processing facilities and information services handled by the staff or contractor.
  • Responsibilities of the staff or contractor for the handling of information received from Interested parties;
  • Actions to be taken if the staff or contractor disregards the XXX’s security requirements.
  • Information security roles and responsibilities should be communicated to job candidates during the pre-employment process.
• The XXX ensures that staff and contractors agree to terms and conditions concerning information security, appropriate to the nature and extent of access they will have to the XXX’s assets associated with information systems and services.
• Where appropriate, responsibilities controlled within the terms and conditions of employment should continue for a defined period after the end of the employment.
• A Non- Disclosure Agreement (NDA) shall be signed by all staff, contractors.

3.4 Information Security Awareness And Training

• All employees of the XXX and, where relevant, contractors shall receive appropriate awareness education and training and regular updates in XXX policies and procedures, as relevant for their job function.
• Awareness, education and training can be part of, or conducted in collaboration with, other training activities, for example general IT or general security training. Awareness, education and training activities shall be suitable and relevant to the individual’s roles, responsibilities and skills.
• An assessment of the employees/contractors understanding is conducted at the end of an awareness, education and training course to test knowledge transfer.

3.5 Compliance With Rules And Regulations

• By signing the Appointment letter an employee is deemed to have expressed his/her acceptance of all the policies, rules, regulations, terms and conditions framed from time to time by the concerned authorized officers.
• During employment, the terms of employment of employee/ contractors shall be governed by the policies and rules framed from time to time covering, among others, Discipline, Code of Conduct etc.

3.6 Confidentiality And Non-Disclosure

Whether information in written or verbal, or contained in computer hardware or software, disk, hard disk, tape or other media, this information is of substantial value, highly confidential and is not known to the general public. Such Information is being provided and disclosed to the staff, contractor solely for use in connection with his/her employment or work of the XXX. NDA is to be signed by all employee/ contractors. Signing to be followed as per Procedure.

3.7 Alteration In The Terms Of Employment

• • XXX reserves the right to make reasonable changes to the duties of an employee, contractor according to the needs of the operation including, relocating/shifting such staff’s workplace and / or transferring such staff to serve at any other location of the XXX.
• • The XXX reserves the right to make reasonable changes to any terms or conditions of employment of any staff with prior notice.

3.8 Termination and Change Of Employment

• Information security responsibilities and duties that remains valid after termination or change of employment is defined, communicated to the staff or contractor and enforced.
• Changes of responsibility or employment are managed as the termination of the current responsibility or employment combined with the initiation of the new responsibilities or employment.
• The Human Resources function is generally responsible for the overall termination process and shall work together with the supervising Dept in change of the person leaving to manage the information security aspects of the procedures. In the case of a contractor provided through an external party, this termination process is undertaken by the external party in accordance with the contract between the XXX and the external party.
• Establishment Department shall inform employee or contractors of changes to personnel and operating arrangements.

3.9 Disciplinary Action

• There shall be a formal and communicated disciplinary process in place to take action against employee who have committed an information security breach.
• Disciplinary action shall be taken by the management depending upon the severity of the event.

3.10 Discharge/Dismissal/Termination

The services of employee may be terminated after giving him one month’s prior notice as per the terms of appointment / service agreement, if any, or payment of basic salary, in lieu thereof or for that matter clearance of any pending salary or financial reimbursements and terminate him immediately after settlement of the same.

3.11 Staff Exit Policy

• Processes are implemented to ensure that all access rights of users of XXX’s information systems are removed in a timely manner upon termination or suspension of their employment, contract or agreement.
• Processes and responsibilities are agreed upon and implemented to enable emergency suspension of a user’s access when that access is considered a risk to the XXX or its systems as defined. Establishment Dept. fill user’s clearance certificate & get it signed by their reporting Dept in charge before user’s last working day.

Enforcement

Any staff, contractor who is found to have violated the policies may be subject to disciplinary action, up to, including termination of employment or legal case against the staff, depending on the degree of the offense committed.

Sample Employment Contractual Agreement

Employee Information and Technology Security Agreement I acknowledge that [name of organization]’s information and technology security policies, guidelines, and procedures have been made available to me for review and consideration. I also certify that I have been given ample opportunity to have any and all questions about my responsibilities addressed. I am, therefore, aware that I am accountable for information and technology security procedures as they govern the acceptable performance of my job. I understand that failure to abide by any and all policies, guidelines, and procedures can result in organizational, civil, or criminal action and/or the termination of my employment. Signature: ______________________________ Printed Name: ______________________________ Job Title: ___________________________________ Date: ______/_____/______

Contractor/Consultant/Outsider Information and Technology Security Agreement I acknowledge that [name of organization] has provided me with adequate time to review and consider the information and technology security policies, guidelines, and procedures it deems applicable to responsibilities I am undertaking on behalf of [name of organization], regardless of my employment status. I also certify that I have been given ample opportunity to have any and all questions about my responsibilities addressed. I am, therefore, aware that I am accountable for those information and technology security procedures as they relate to my work for, or on the behalf of, [name of organization]. I understand that failure to abide by any and all policies, guidelines, and procedures can result in organizational, civil, or criminal action and/or the termination of my relationship with [name of organization]. Signature: __________________ Printed Name: __________________ Affiliation: _______________________ Date: /__

Purpose

XXX applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system.

Scope

XXX apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example

• developing layered protections;
• establishing sound security policy, architecture, and controls as the foundation for design;
• incorporating security requirements into the system development life cycle;
• delineating physical and logical security boundaries;
• ensuring that system developers are trained on how to build secure software;
• tailoring security controls to meet organizational and operational needs;
• performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and
• reducing risk to acceptable levels, thus enabling informed risk management decisions.

Policy

Top management at XXX understands that principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation effort. To this end XXX has produced this secure system engineering principles policy to ensure that the Company:

Produces principles that will be applied to in-house information system engineering activities

– Ensures that security will be designed into all architecture layers balancing the need for security with that of accessibility

• Ensures that new technology is analysed for security risks
• Ensures that the design is reviewed against known attack patterns
• Ensures that Principles are reviewed to ensure their effectiveness in contributing to enhanced standards of security within the engineering process
• Ensure that Principles are reviewed to ensure they remain up-to-date in terms of combating any new potential threats and in advances in technology

Top management also understand that certain suppliers may have inadequate information security management and will, in such cases, identify and apply controls necessary to ensure security is maintained. It will use
confidentiality agreements

• non-disclosure agreements and
• second party audits where appropriate.

• The Company will also take into account any Data Protection regulations and will be aware of all legal and contractual responsibilities in the area.
• Application development procedures will also apply secure engineering principles when developing applications for both input and output interfaces.
• Responsibility for upholding this policy is truly company-wide under the authority of the Managing Director who encourages the personal commitment of all staff to address information security as part of their skills.

Principle for Engineering secure system

Security Foundation

Principle 1: Establish a sound security policy as the “foundation” for design.
A security policy is an important document to develop while designing an information system. The security policy begins with the organization’s basic commitment to information security formulated as a general policy statement. The policy is then applied to all aspects of the system design or security solution. The policy identifies security goals (e.g., confidentiality, integrity, availability, accountability, and assurance) the system should support and these goals guide the procedures, standards and controls used in the IT security architecture design. The policy also should require definition of critical assets, the perceived threat, and security-related roles and responsibilities.

Principle 2: Treat security as an integral part of the overall system design.
Security must be considered in information system design and should be integrated fully into the system life-cycle. Experience has shown it to be both difficult and costly to introduce security measures properly and successfully after a system has been developed, so security should be implemented in the design stage of all new information systems, and where possible, in the modification and continuing operation of all legacy systems. This includes establishing security policies, understanding the resulting security requirements, participating in the evaluation of security products, and in the engineering, design, implementation, and disposal of the system.

Principle 3: Clearly delineate the physical and logical security boundaries governed by associated security policies.
Information technology exists in physical and logical locations, and boundaries exist between these locations. An understanding of what is to be protected from external factors can help ensure adequate protective measures are applied where they will be most effective. Sometimes a boundary is defined by people, information, and information technology associated with one physical location. But this ignores the reality that, within a single location, many different security policies may be in place, some covering publicly accessible information and some covering sensitive or confidential information. Other times a boundary is defined by a security policy that governs a specific set of information and information technology that can cross physical boundaries. Further complicating the matter is that, many times, a single machine or server may house both public-access and sensitive information. As a result, multiple security policies may apply to a single machine or within a single system. Therefore, when developing an information system, security boundaries must be considered and communicated in relevant system documentation and security policies.

Principle 4: Ensure that developers are trained in how to develop secure software.
Ensure that developers are adequately trained in the design, development, configuration control, integration, and testing of secure software before developing the system.

RISK BASED

Principle 5: Reduce risk to an acceptable level.
Risk is defined as the combination of (1) the likelihood that a particular threat source will exercise (intentionally exploit or unintentionally trigger) a particular information system vulnerability and (2) the resulting adverse impact on organizational operations, assets, or individuals should this occur. Recognize that the elimination of all risk is not cost-effective. A cost-benefit analysis should be conducted for each proposed control. In some cases, the benefits of a more secure system may not justify the direct and indirect costs. Benefits include more than just prevention of monetary loss; for example, controls may be essential for maintaining public trust and confidence. Direct costs include the cost of purchasing and installing a given technology; indirect costs include decreased system performance and additional training. The goal is to enhance mission/business capabilities by mitigating mission/business risk to an acceptable level. (Related Principle: 6)

Principle 6: Assume that external systems are insecure.
The term information domain arises from the practice of partitioning information resources according to access control, need, and levels of protection required. Organizations implement specific measures to enforce this partitioning and to provide for the deliberate flow of authorized information between information domains. The boundary of an information domain represents the security perimeter for that domain. An external domain is one that is not under your control. In general, external systems should be considered insecure. Until an external domain has been deemed “trusted,” system engineers, architects, and IT specialists should presume the security measures of an external system are different than those of a trusted internal system and design the system security features accordingly.

Principle 7: Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness.
To meet stated security requirements, a systems designer, architect, or security practitioner will need to identify and address all competing operational needs. It may be necessary to modify or adjust security goals due to other operational requirements. In modifying or adjusting security goals, an acceptance of greater risk and cost may be inevitable. By identifying and addressing these trade-offs as early as possible, decision makers will have greater latitude and be able to achieve more effective systems. (Related: Principle 4)

Principle 8: Implement tailored system security measures to meet organizational security goals.
In general, IT security measures are tailored according to an organization’s unique needs. While numerous factors, such as the overriding mission requirements, and guidance, are to be considered, the fundamental issue is the protection of the mission or business from IT security-related, negative impacts. Because IT security needs are not uniform, system designers and security practitioners should consider the level of trust when connecting to other external networks and internal sub- domains. Recognizing the uniqueness of each system allows a layered security strategy to be used – implementing lower assurance solutions with lower costs to protect less critical systems and higher assurance solutions only at the most critical areas.

Principle 9: Protect information while being processed, in transit, and in storage.
The risk of unauthorized modification or destruction of data, disclosure of information, and denial of access to data while in transit should be considered along with the risks associated with data that is in storage or being processed. Therefore, system engineers, architects, and IT specialists should implement security measures to preserve, as needed, the integrity, confidentiality, and availability of data, including application software, while the information is being processed, in transit, and in storage.

Principle 10: Consider custom products to achieve adequate security.
Designers should recognize that in some instances it may not be possible to meet security goals with systems constructed entirely from commercial off-the-shelf (COTS) products. In such instances, it may be necessary to augment COTS with non-COTS mechanisms.

Principle 11: Protect against all likely classes of “attacks.”
In designing the security controls, multiple classes of “attacks” need to be considered. Those classes that result in unacceptable risk need to be mitigated. Examples of “attack” classes are: passive monitoring, active network attacks, exploitation by insiders, attacks requiring physical access or proximity, and the insertion of back doors and malicious code during software development and/or distribution.

EASY TO USE

Principle 12: Where possible, base security on open standards for portability and interoperability.
Most organizations depend significantly on distributed information systems to perform their mission or business. These systems distribute information both across their own organization and to other organizations. For security capabilities to be effective in such environments, security program designers should make every effort to incorporate interoperability and portability into all security measures, including hardware and software, and implementation practices.

Principle 13: Use common language in developing security requirements.
The use of a common language when developing security requirements permits organizations to evaluate and compare security products and features evaluated in a common test environment. When a “common” evaluation process is based upon common requirements or criteria, a level of confidence can be established that ensures product security functions conform to an organization’s security requirements. The Common Criteria (CC; available at http://www.commoncriteriaportal.org/) provides a source of common expressions for common needs and supports a common assessment methodology. Use of CC “protection profiles” and “security targets” greatly aids the development of products (and to some extent systems) that have IT security functions. The rigor and repeatability of the CC methodology provides for thorough definition of user security needs. Security targets provide system integrators with key information needed in the procurement of components and implementation of secure IT systems.

Principle 14: Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process.
As mission and business processes and the threat environment change, security requirements and technical protection methods must be updated. IT-related risks to the mission/business vary over time and undergo periodic assessment. Periodic assessment should be performed to enable system designers and managers to make informed risk management decisions on whether to accept or mitigate identified risks with changes or updates to the security capability. The lack of timely identification through consistent security solution re-evaluation and correction of evolving, applicable IT vulnerabilities results in false trust and increased risk. Each security mechanism should be able to support migration to new technology or upgrade of new features without requiring an entire system redesign. The security design should be modular so that individual parts of the security design can be upgraded without the requirement to modify the entire system.

Principle 15: Strive for operational ease of use.
The more difficult it is to maintain and operate a security control the less effective that control is likely to be. Therefore, security controls should be designed to be consistent with the concept of operations and with ease-of-use as an important consideration. The experience and expertise of administrators and users should be appropriate and proportional to the operation of the security control. An organization must invest the resources necessary to ensure system administrators and users are properly trained. Moreover, administrator and user training costs along with the life-cycle operational costs should be considered when determining the cost-effectiveness of the security control.

INCREASE RESILIENCE

Principle 16: Implement layered security (ensure no single point of vulnerability).
Security designs should consider a layered approach to address or protect against a specific threat or to reduce vulnerability. For example, the use of a packet-filtering router in conjunction with an application gateway and an intrusion detection system combine to increase the work-factor an attacker must expend to successfully attack the system. Add good password controls and adequate user training to improve the system’s security posture even more. By using multiple, overlapping protection approaches, the failure or circumvention of any individual protection approach will not leave the system unprotected. Through user training and awareness, well-crafted policies and procedures, and redundancy of protection mechanisms, layered protections enable effective protection of information technology for the purpose of achieving mission objectives. The need for layered protections is especially important when COTS products are used. Practical experience has shown that the current state-of-the-art for security quality in COTS products does not provide a high degree of protection against sophisticated attacks. It is possible to help mitigate this situation by placing several controls in series, requiring additional work by attackers to accomplish their goals.

Principle 17: Design and operate an IT system to limit damage and to be resilient in response.
Information systems should be resistant to attack, should limit damage, and should recover rapidly when attacks do occur. The principle suggested here recognizes the need for adequate protection technologies at all levels to ensure that any potential cyber attack will be countered effectively. There are vulnerabilities that cannot be fixed, those that have not yet been fixed, those that are not known, and those that could be fixed but are not (e.g., risky services allowed through firewalls) to allow increased operational capabilities. In addition to achieving a secure initial state, secure systems should have a well-defined status after failure, either to a secure failure state or via a recovery procedure to a known secure state. Organizations should establish detect and respond capabilities, manage single points of failure in their systems, and implement a reporting and response strategy. (Related: Principle 14)

Principle 18: Provide assurance that the system is, and continues to be, resilient in the face of expected threats.
Assurance is the grounds for confidence that a system meets its security expectations. These expectations can typically be summarized as providing sufficient resistance to both direct penetration and attempts to circumvent security controls. Good understanding of the threat environment, evaluation of requirement sets, hardware and software engineering disciplines, and product and system evaluations are primary measures used to achieve assurance. Additionally, the documentation of the specific and evolving threats is important in making timely adjustments in applied security and strategically supporting incremental security enhancements.

Principle 19: Limit or contain vulnerabilities.
Design systems to limit or contain vulnerabilities. If a vulnerability does exist, damage can be limited or contained, allowing other information system elements to function properly. Limiting and containing insecurities also helps to focus response and reconstitution efforts to information system areas most in need. (Related: Principle 10)

Principle 20: Isolate public access systems from mission critical resources (e.g., data, processes, etc.).
While the trend toward shared infrastructure has considerable merit in many cases, it is not universally applicable. In cases where the sensitivity or criticality of the information is high, organizations may want to limit the number of systems on which that data is stored and isolate them, either physically or logically. Physical isolation may include ensuring that no physical connection exists between an organization’s public access information resources and an organization’s critical information. When implementing logical isolation solutions, layers of security services and mechanisms should be established between public systems and secure systems responsible for protecting mission critical resources. Security layers may include using network architecture designs such as demilitarized zones and screened subnets. Finally, system designers and administrators should enforce organizational security policies and procedures regarding use of public access systems.

Principle 21: Use boundary mechanisms to separate computing systems and network infrastructures.
To control the flow of information and access across network boundaries in computing and communications infrastructures, and to enforce the proper separation of user groups, a suite of access control devices and accompanying access control policies should be used. Determine the following for communications across network boundaries:

• What external interfaces are required
• Whether information is pushed or pulled
• What ports, protocols, and network services are required
• What requirements exist for system information exchanges; for example, trust relationships, database replication services, and domain name resolution processes

Principle 22: Design and implement audit mechanisms to detect unauthorized use and to support incident investigations.
Organizations should monitor, record, and periodically review audit logs to identify unauthorized use and to ensure system resources are functioning properly. In some cases, organizations may be required to disclose information obtained through auditing mechanisms to appropriate third parties, including law enforcement authorities. Many organizations have implemented consent to monitor policies which state that evidence of unauthorized use (e.g., audit trails) may be used to support administrative or criminal investigations.

Principle 23: Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability.
Continuity of operations plans or disaster recovery procedures address continuance of an organization’s operation in the event of a disaster or prolonged service interruption that affects the organization’s mission. Such plans should address an emergency response phase, a recovery phase, and a return to normal operation phase. Personnel responsibilities during an incident and available resources should be identified. In reality, contingency and disaster recovery plans do not address every possible scenario or assumption. Rather, focus on the events most likely to occur and identify an acceptable method of recovery. Periodically, the plans and procedures should be exercised to ensure that they are effective and well understood.

REDUCE VULNERABILITIES

Principle 24: Strive for simplicity.
The more complex the mechanism, the more likely it may possess exploitable flaws. Simple mechanisms tend to have fewer exploitable flaws and require less maintenance. Further, because configuration management issues are simplified, updating or replacing a simple mechanism becomes a less intensive process.

Principle 25: Minimize the system elements to be trusted.
Security measures include people, operations, and technology. Where technology is used, hardware, firmware, and software should be designed and implemented so that a minimum number of system elements need to be trusted in order to maintain protection. Further, to ensure cost-effective and timely certification of system security features, it is important to minimize the amount of software and hardware expected to provide the most secure functions for the system.

Principle 26: Implement least privilege.
The concept of limiting access, or “least privilege,” is simply to provide no more authorizations than necessary to perform required functions. This is perhaps most often applied in the administration of the system. Its goal is to reduce risk by limiting the number of people with access to critical system security controls (i.e., controlling who is allowed to enable or disable system security features or change the privileges of users or programs). Best practice suggests it is better to have several administrators with limited access to security resources rather than one person with “super user” permissions. . Consideration should be given to implementing role-based access controls for various aspects of system use, not only administration. The system security policy can identify and define the various roles of users or processes. Each role is assigned those permissions needed to perform its functions. Each permission specifies a permitted access to a particular resource (such as “read” and “write” access to a specified file or directory, “connect” access to a given host and port, etc.). Unless permission is granted explicitly, the user or process should not be able to access the protected resource. Additionally, identify the roles/responsibilities that, for security purposes, should remain separate (this is commonly termed “separation of duties”).

Principle 27: Do not implement unnecessary security mechanisms.
Every security mechanism should support a security service or set of services, and every security service should support one or more security goals. Extra measures should not be implemented if they do not support a recognized service or security goal. Such mechanisms could add unneeded complexity to the system and are potential sources of additional vulnerabilities. An example is file encryption supporting the access control service that in turn supports the goals of confidentiality and integrity by preventing unauthorized file access. If file encryption is a necessary part of accomplishing the goals, then the mechanism is appropriate. However, if these security goals are adequately supported without inclusion of file encryption, then that mechanism would be an unneeded system complexity.

Principle 28: Ensure proper security in the shutdown or disposal of a system.
Although a system may be powered down, critical information still resides on the system and could be retrieved by an unauthorized user or organization. Access to critical information systems must be controlled at all times. At the end of a system’s life-cycle, system designers should develop procedures to dispose of an information system’s assets in a proper and secure fashion. Procedures must be implemented to ensure system hard drives, volatile memory, and other media are purged to an acceptable level and do not retain residual information.

Principle 29: Identify and prevent common errors and vulnerabilities.
Many errors reoccur with disturbing regularity – errors such as buffer overflows, race conditions, format string errors, failing to check input for validity, and programs being given excessive privileges. Learning from the past will improve future results.

DESIGN WITH THE NETWORK IN MIND

Principle 30: Implement security through a combination of measures distributed physically and logically.
Often, a single security service is achieved by cooperating elements existing on separate machines. For example, system authentication is typically accomplished using elements ranging from the user- interface on a workstation through the networking elements to an application on an authentication server. It is important to associate all elements with the security service they provide. These components are likely to be shared across systems to achieve security as infrastructure resources come under more senior budget and operational control.

Principle 31: Formulate security measures to address multiple overlapping information domains.
An information domain is a set of active entities (person, process, or devices) and their data objects. A single information domain may be subject to multiple security policies. A single security policy may span multiple information domains. An efficient and cost effective security capability should be able to enforce multiple security policies to protect multiple information domains without the need to separate physically the information and respective information systems processing the data. This principle argues for moving away from the traditional practice of creating separate LANs and infrastructures for various sensitivity levels (e.g., security classification or business function such as proposal development) and moving toward solutions that enable the use of common, shared, infrastructures with appropriate protections at the operating system, application, and workstation level. Moreover, to accomplish missions and protect critical functions, organizations have many types of information to safeguard. With this principle in mind, system engineers, architects, and IT specialists should develop a security capability that allows organizations with multiple levels of information sensitivity to achieve the basic security goals in an efficient manner.

Principle 32: Authenticate users and processes to ensure appropriate access control decisions both within and across domains.
Authentication is the process where a system establishes the validity of a transmission, message, or a means of verifying the eligibility of an individual, process, or machine to carry out a desired action, thereby ensuring that security is not compromised by an untrusted source. It is essential that adequate authentication be achieved in order to implement security policies and achieve security goals. Additionally, level of trust is always an issue when dealing with cross-domain interactions. The solution is to establish an authentication policy and apply it to cross-domain interactions as required. Note: A user may have rights to use more than one name in multiple domains. Further, rights may differ among the domains, potentially leading to security policy violations.

Principle 33: Use unique identities to ensure accountability.
An identity may represent an actual user or a process with its own identity, e.g., a program making a remote access. Unique identities are a required element in order to be able to:

• Maintain accountability and traceability of a user or process
• Assign specific rights to an individual user or process
• Provide for non-repudiation
• Enforce access control decisions
• Establish the identity of a peer in a secure communications path
• Prevent unauthorized users from masquerading as an authorized user

1.0 Purpose

The purpose of the XXX’s Information Asset Management Policy is to establish the rules for the control of hardware, software, applications, and information used by XXX

2.0 Scope

The scope of this policy extends to all XXX departments, employees, third parties, vendors and partners who utilize or who are responsible for the development, management and maintenance of all XXX’s information assets. The XXX’s Information Asset Management Policy applies to individuals who are responsible for the use, purchase, implementation, management, and/or maintenance of XXX information resources.

The XXX categorises information assets as:

• Information and Information Systems:
  • Databases
  • Data files
  • Hardcopy documents
  • User guides
  • Notebooks
  • Training material
  • Policies, Procedures
  • Business Continuity plans
  • Financial Data
• Software:
  • Applications
  • System software
  • Development software
  • Utilities software
• Physical:
  • Computer equipment
  • Communications equipment
  • Portable and local Media – storage and recording
  • Property and accommodation
• Services:
  • Communications
  • Utilities (power. lighting, environmental controls)
• Personnel:
  • Knowledge
  • Skills
  • Experience
• Intangibles:
  • Reputation

3 Some terms used

3.1 Information Asset Owner
The owners of an information asset are those individuals who have primary responsibility for the viability and suitability of the asset. The owner is a senior person within an organization with sufficient authority and officially designated as accountable for a specific business process / function within an organization. The owner must determine what information assets are they responsible for. The responsibility is not restricted to the information systems within their domain and should go beyond in defining the information that needs to be managed within those systems. Such information may include Personally Identifiable Information (PII) along with critical business data in both electronic and non-electronic formats. It is the owner’s responsibility to set the security requirements for information assets and communicate those requirements to all of the assets’ custodians. Owners are also responsible to assess these requirements from time to time based on the changing threat profiles and / or the value of information with passage of time. Owners should ensure that the defined security requirements are implemented and maintained by the data custodians. Further, the effectiveness of the controls implemented should be assessed at regular intervals (e.g. through audits). An owner may delegate these security responsibilities, but the owner remains ultimately responsible for the protection of the asset.

3.2 Custodian of an Information Asset
The term “custodian” refers to any individual in the organization who has the responsibility to protect an information asset as it is stored, transported, or processed in line with the requirements defined by the information asset owner. “Custodians” includes users from the Information Technology / Information Security function along with the staff who may be responsible for transporting information (e.g. paper records / CDs / USBs etc) from one place to another or even the facilities or security staff who may have physical access to information processing and storing facilities. Certain roles within the organization such as IT staff with administrative / root privileges may have unlimited access to the agency’s information system, these are critical roles and sufficient controls and procedures must be developed for such privileged access. Data Users also have a critical role to protect and maintain an organization’s information systems and data. For the purpose of information security, a Data User is any employee, contractor or third-party provider who is authorized by the Data Owner to access information assets. At times, the data custodian may play the role of a trusted advisor to the owner advising him on the risks and controls suitable for the information asset. However, the ultimate responsibility lies with the Owner and in no circumstances, the data custodian shall deem the role of an owner.

3.3 Risks to Information Assets
An Information Asset Owner should assess the risks to the information assets and ensure adequate controls to protect against:

1. Loss of Confidentiality: Inappropriate access to, or disclosure of, protectively marked or personal data by Data users, public and / or malicious actors, whether accidental or deliberate
2. Loss of Integrity: Data users acting in error or deliberately, or external parties accessing your information illegally, acting maliciously to compromise the integrity of your data with an intention to defraud you or your customers or to cause reputation damage to your organization
3. Loss of Availability: This could be either temporary or permanent.
   • Information loss – particularly during transfer or movement of information, or because of business change (mergers, acquisitions, restructuring).
   • Loss of access to information due to system / network outages caused due to errors or deliberate actions.
   • Loss of digital continuity – i.e. losing the ability to use your information in the way required when needed. By use we mean being able to find, open, work with, understand and trust your information. The lifecycle of a piece of information – how long you need to use and keep it – is often different to the lifecycle of the IT system used to access and support it.
4. Information Currency: Business needs change, systems change, the value of an information asset may change or the organization’s information risk appetite may change. An organization’s processes should be agile to manage the information security of the asset in accordance to the changing business environment.

4 Policy Statement

The XXX’s Information Governance Group (IGG) co-ordinates responsibility for the management of information assets by appointing nominated information asset owners across departments. All identified information assets must be recorded and managed by information asset owners in accordance with the XXX’s Information Security Management System. The XXX must take the following steps to ensure all information assets are appropriately identified, recorded and maintained:

4.1 Information and Information Systems

Information held and maintained by the XXX can either be in hard copy form stored in physical locations, filing systems, office locations or stored electronically using software and electronic backup systems.

Types of Information and Information Systems assets:

• Databases – Access to these must be given to authorised employees only and logs should be maintained to record all access to and changes made to any data held within any database system.
• Data files – Access to any data file(s) must be given to authorised employees only and logs must be maintained to record all access to and changes made to any data held within database systems.
• Hard copy documents – All hard copy documents containing sensitive and personal information must be accessed, processed, maintained and securely stored in accordance with the XXX’s Information Safe Haven guidance. Restricted hard copy documents requiring controlled access must have a signing in/out record maintained wherever appropriate.
• User guides – All user guides which assist and aid in the understanding of processes, procedures or systems should be safely stored and should be easily and readily accessible to all relevant employees – wherever possible. Guides which exist only in physical form should be digitised to include an electronic version which can be stored electronically on the XXX’s ICT Network.
• Notebooks – Information contained in notebooks which are used to record sensitive or personal information must be transferred to secure information systems as soon as possible and either the pages or entire notebook must be securely destroyed once the information has been transferred.
• Training material – All relevant training material(s) must be stored and made readily accessible to all relevant employees. Duplication or physical reproduction of training manuals must be kept to a minimum and avoided wherever possible.
• Policies and Procedures – All XXX Policies and Procedures should be made available and disseminated via the XXX’s main website. All original copies of Policies and Procedures documents whether electronic or hardcopy must be safely stored, regularly reviewed and a version history control record must be maintained for each document to ensure they are up to date.
• Business Continuity plans – All Business Continuity plans must be regularly reviewed, disseminated to appropriate employees and stored safely for easy retrieval as and when necessary.
• Financial Data – Data and Information relating to XXX financial data must be restricted to authorized employees only. Recording mechanisms must be in place for logging access, changes and use of financial data and information.

4.2 Software

Computer and IT systems software is widely used across the XXX and is vital to the day to day running of the XXX .The use of software has continued to change the way the XXX works. Substantial investment has been made in Software along with accompanying ongoing costs and expenditure such as annual software/systems support, licensing and staff training.

• Applications – Software used by the XXX must be appropriately sourced using XXX approved suppliers and must be evaluated for business need, suitability, efficiency, and ease of use, cost effectiveness and integration into existing XXX systems. All software approved for use by the XXX must be recorded on an approved software list. Appropriate numbers of software licenses must be purchased to cover volume of use and to satisfy legal requirements. Software media must be stored (physically and electronically) in a secure, centralized location along with software installation codes and registration numbers. Access to software media by employees must be controlled and limited to authorized employees only. A record must be maintained of all installations of software, licensing volumes SLA documentation and references in a centralized location where access is provided to authorize employees only. A signing in/out system should be used for controlling the use of physical software media.
• System software – Server/system software such as Operating Systems, must be evaluated for business need, suitability, efficiency, cost effectiveness and integration into existing XXX systems. Operating System installation media must be stored in a secure, centralized location along with installation codes. Access to Server/system software media by employees must be controlled and limited to authorized employees only. A record must be maintained of all installations of software, licensing volumes SLA documentation and references in a centralized location where access is provided to authorize employees only. A signing in/out system should be used for controlling the use of physical software media. Backups of complete Server/systems installations must be routinely carried out for disaster recovery purposes. Installation, configuration and maintenance of Server/system software must only be undertaken by employees who are trained and qualified to do so.
• Development software – software for the support of existing systems and for the development of in-house solutions must follow the same processes for procurement and use as for the applications and Server/systems software. Development software should only be used by employees who are trained or who are undergoing training to use the development software.

All types of software (with the exception of routine security updates and patches verified by software vendors) must go through agreed purchasing procedures and must be recorded on a XXX approved software list. Where the software is used in the storing, handling, processing or retention of data including personal data relating to the XXX’s information or services commissioned by the XXX, then the purchasing procedure should follow the guidelines contained within the XXX’s ‘Supplier Information Security Policy’ and approved by the Director of Finance and ICT Services in line with the ‘Protocol for the Approval of new Systems or Changes to Existing Systems by the Director of Finance’.

4.3 Physical

The XXX’s most visible information assets are those which are physically located throughout the XXX such as computers, printers and phones etc. Offices and buildings must also be considered as information assets – providing location for the housing and installation of the XXX’s ICT Data and Communications Network infrastructure and physically stored documents and information.

• Computer equipment – A large number of computing devices are in use across the XXX. Computers are one of the most costly single items of equipment and must be subject to controls from procurement to disposal. The XXX must be able to track all activity and use relating to all XXX computing devices using various means such as via the computer network and/or using logging systems such as signing in and out and other such recording mechanisms. All computers must be allocated a unique asset tag number which is recorded against the manufacturer’s serial number and model which should never be altered or exchanged with any other computer. Throughout its life, a computer may be subject to hardware upgrades, new software installations, configuration changes and maintenance and all such activity must be appropriately recorded, maintained and updated by the ICT Service.
• Communications equipment – Mobile and office phones are widely used communications devices across the XXX. Other network and communications devices identified as information assets include routers, switches, video conferencing equipment etc. Along with computing equipment, these devices must be allocated an asset tag number. All communications equipment must be identified, recorded and appropriately maintained by the ICT Service.
• Portable, local media storage – Media such as CD/DVDs, Magnetic tape, flash/portable hard disks are valuable information assets because they are used to save and retrieve XXX information and data. Irrespective of the information stored on them, all such media must be classified and handled as ‘RESTRICTED’ in accordance with the XXX’s Information Classification and Handling Policy. The portable nature of this type of media requires responsible use and adherence to all XXX policies, procedures and processes which are in place for the protection of information and data. Appropriate labelling and recording mechanisms should be in place to ensure the safety and integrity of media – enabling tracking of essential media such as for data backups e.g. media required to carry out data/file restores must be signed in and out from a secure location. Portable media must be used in accordance with the XXX’s Encryption & Cryptographic Controls Policy, Desktop and Mobile Device Procedures and Data Protection and Storage Media Handling Procedures. All physical computer, communications and storage media/devices must go through purchasing procedures and must be recorded on a XXX approved hardware inventory.
• Property and accommodation – The XXX’s Corporate Asset Management Plan provides comprehensive information relating to buildings and property as information assets. ICT equipment along with Data and Network Communications infrastructure equipment is housed in many buildings and property owned by the XXX and is therefore subject to the Corporate Asset Management Plan

4.4 Services

• Communications – It is vital for the XXX to maintain its ability to communicate in many different forms. Communications equipment must be maintained and clear processes, policies and procedures for the provision of this service must be in place. E-mail is also a vital means of communication and as such, requires a robust, reliable infrastructure to enable the XXX to communicate effectively and reliably, both internally and externally.
• Utilities (power. lighting, environmental controls) – These services are information assets as they provide fundamental requirements for the XXX to function appropriately, safely and effectively. It is essential that property maintenance and inspections are routinely carried out and that employees are proactive in reporting faults, whenever noted, to the XXX’s Property Services division.

4.5 Personnel

The XXX cannot function without its workforce – it is its largest asset. The provision of good public services requires XXX employees to have the necessary skills, knowledge and ability to work within many different areas and departments across the XXX. The number of unique functions and specialisms across the XXX requires a varied knowledge and skills base which must be supported by robust recruitment processes, appropriate training provision and good management of employee skill identification, work placement and allocation.

• Knowledge and Experience – The XXX has a great pool of employees who have a wide knowledge and experience base to draw on and as such, is a valuable information asset.
• Skills – All XXX employees must possess the necessary skills and ability to do their jobs.

4.6 Intangibles

Reputation – The XXX is very aware that public perception and confidence in its ability to deliver effective, efficient public services is of the utmost importance. Reputation is an asset which promotes confidence and generates support in what the XXX is trying to achieve. The XXX takes its reputation seriously and proactively engages to develop policies and procedures along with a consistent approach in maintaining and presenting the right image. The XXX encourages good reputation and is assisted by:

• Good working practices
• Corporate Image Branding
• Public Consultation

4.7 Information Classification and Handling

All XXX information has a value to the organization, however not all of the information has an equal value or requires the same level of protection. Being able to identify the value of information assets is key to understanding the level of security that they require. The XXX maintains an Information Classification and handling scheme which involves grouping information and categorizing content to establish the most appropriate way of handling, storing, retrieving and to determine who is authorized to access particular Information. All information in both electronic and physical forms must be categorized using either ‘PUBLIC’, ‘CONTROLLED’ or ‘RESTRICTED’ and must be appropriately labelled.
Any information that is not specifically marked as being ‘RESTRICTED’ or ‘CONTROLLED’ will be deemed to be ‘PUBLIC’. Where information is grouped together, the highest classification must be applied to all information in the group. The XXX’s information classification and handling policy and procedures provide further information

4.8 Guidelines for an Information Asset Owner

Information asset owner are individuals who are responsible and accountable for the information assets within an organization. Information asset owners shall define the controls necessary for the information asset and work with information custodians to ensure that they are implemented and effective.

• Classification: Asset owner should support the ISM in the task of asset classification by explaining the need and importance for all information asset assigned under his /her responsibility.
• Labelling: Asset owner SHOULD identify the appropriate labels for all assets as per their classification to support the Need-To-Know requirement and data labelling education and awareness for the staff, employees and contractors.
• Controls allocation: Owner SHOULD ensure the application of all baseline controls to all classified assets. Additional, stronger controls MAY be applied, if necessary and based on the risk assessment conducted. The controls shall consistently protect the Information Asset throughout their life cycle.
• Access Control and Physical Security: Asset Owner must authorize access to only those who have a business need for the information, and ensure that access is removed for those who no longer have a business need for the information. The Access control shall include physical as well as logical access to the information asset. The controls shall be chosen based on an assessment of risk.
• Logging & Security Monitoring: The asset owner shall identify suitable technical controls and processes to log and monitor systems for potential malicious activities or system disruptions.
• Awareness: The asset owner shall ensure that all personnel having access to the information asset are aware of the organization’s security requirements and any legal or regulatory responsibilities.
• Retention & Archival: The asset owner shall determine and document the retention periods of information assets governed by the organization’s policies and regulatory requirements.
• Incident Handling: The asset owner shall be responsible for the information asset. Any incident that compromises the confidentiality, integrity or availability of data should be reported and managed.
• Business Continuity: The information asset owner shall ensure the availability of information as and when required for the continuance of business.
• Ensure compliance: The asset owner shall ensure that the information asset is secured in compliance with the organizational security policy and state of Qatar laws and regulations.

4.9 Guidelines for the Information Asset Custodian

Information asset custodians are individuals in physical or logical possession of information. Information asset custodians are expected to work with information asset owners to gain a better understanding of these requirements. The information security controls implemented by the custodian must be documented and shared with the asset owner.

4.9.1 Information Technology Manager (IT Function)

• Classification: Assist the Asset owner along with the ISM in the task of asset classification.
• Labelling: Implement the data labeling as identified by the Asset owner. Advise the owner on technical limitations if any and possible technical mitigating solutions.
• Controls allocation: Identify and apply all controls (baseline and additional) to all information assets to protect the confidentiality, integrity, and availability of the information asset. The controls shall consistently protect the Information Asset throughout their life cycle.
• Access Control and Physical Security: Implement the necessary processes and controls to manage access control to information assets. Access shall be provided to only those who have a business need for the information, and ensure that access is removed for those who no longer have a business need for the information. The Access control shall include physical as well as logical access to the information asset. The controls shall be chosen based on an assessment of risk.
• Logging & Security Monitoring: Implement suitable technical controls and processes to log and monitor systems for potential malicious activities or system disruptions.
• Retention & Archival: Design and implement systems that shall ensure that information assets and the information life cycle are managed in line with the document retention policy.
• Incident Handling: Implement procedures for managing incidents. This should include incident reporting and incident response.
• Business Continuity: Design and implement the necessary procedures and controls to ensure the availability of information as and when required for the continuance of business.

4.9.2 Information Security Manager (Information Security Function)

• Information Governance: The Information Security Manager will manage the information security program of the organization. The ISM will develop information security policies to ensure that the organization’s information assets are secured adequately in line with the Information owner requirements and corporate policies and national regulations such as NIA Policy, Information Privacy Protection Law and Cyber crime law amongst others. IG and AC
• Information Classification: Assist the information owner in identifying assets and classifying them. The ISM should also assist the information asset owner and the ITM in selecting appropriate controls to provide the necessary assurance to information asset owners.
• Controls: Ensure the application of all baseline controls to all information assets.
• Risk Management: Conduct a Risk assessment in association with the information asset owner and prepare an appropriate Risk treatment plan. Monitor the effectiveness of risk treatment processes and plans periodically.
• Awareness: Design and deliver an information security awareness to all personnel having access to the information assets. The awareness shall elevate among the users an understanding of the organization’s security requirements and any legal or regulatory responsibilities.
• Incident Management: Define an Incident Management policy and necessary procedures. Work with the ITM to detect, respond and contain incidents. Inform and report senior management about critical incidents.
• Maintain co-ordination with government and law enforcement agencies to report and manage critical incidents.

4.9.3 Guidelines for Data User

• Information Governance: The Data user shall be responsible for the information assets (systems / infrastructure) provided to them to carry out their official responsibilities.
• Information Classification: The Data User shall adhere to the information classification scheme approved by the management and maintain the classification (label) provided by the information asset owner.]

5 Acceptable Use of Assets

All XXX departments, employees, elected members, contractors, vendors and partner agencies must observe and abide by all Acceptable Use policies and procedures pertaining to all XXX owned information assets.

6 Breaches of Policy

Breaches of this policy and/or security incidents can be defined as events which could have, or have resulted in, loss or damage to XXX assets, or an event which is in breach of the XXX’s security procedures and policies. All XXX employees, elected members, partner agencies, contractors and vendors have a responsibility to report security incidents and breaches of this policy as quickly as possible through the XXX’s Incident Reporting Procedure. This obligation also extends to any external organization contracted to support or access the Information Systems of the XXX. The XXX will take appropriate measures to remedy any breach of the policy and its associated procedures and guidelines through the relevant frameworks in place. In the case of an individual then the matter may be dealt with under the disciplinary process.

Example of Information Asset Register Format

S.No.	Asset Name	Category	Confidentiality	Integrity	Availability	Aggregate Security Level	Label	Group/ Department	Owner	Contact Details	Support Contact Details