Supplier chain risk management procedure

1.0 Purpose

This Procedure establishes the means with which to assess the risks and opportunities associated with use of supplier’s product or services such as the contracting, procurement, and provision of supplies and services on a corporate and project level, as well as the development of sustainable commercial relations. As part of this commitment, XXX considers it a priority to prevent all risks originating from its supply chain or the goods and services produced or supplied by the companies in its supply chain. The scope XXX, its Group companies, and all operations conducted in countries where the Group is present in a concession business model that intervenes in the entire value chain of the infrastructure sector. This Procedure covers our management approach to the supply chain and reflects our commitment and that of our suppliers

2.0 Scope

These standards apply to all information and information systems that support the operations and assets of the XXX, including those provided or managed by supplier, contractor, or other source, as well as services that are either fully or partially provided, including XXX’s hosted, outsourced, and cloud-based solutions. Principal Offices, employees, contractors, external service providers and system users are required to comply with these supply chain risk management procedure

3.0 Principles of supply chain security

3.1. Understand what needs to be protected and why

You should know:

• The sensitivity of the contracts you let or will be letting.
• The value of your information or assets which suppliers hold, will hold, have access to, or handle, as part of the contract.

Think about the level of protection you need suppliers to give to your assets and information, as well as the products or services they will deliver to you as part of the contract.

3.2. Know who your suppliers are and build an understanding of what their security looks like

You should know:

• Who your suppliers are. You will need to think about how far down your supply chain you need to go to gain understanding and confidence in your suppliers.You may have to rely on your immediate suppliers to provide information about sub-contractors, and it may take some time to ascertain the full extent of your supply chain.
• The maturity and effectiveness of your suppliers’ current security arrangements. For example you could use CPNI Personnel Security Maturity Model to assess the maturity of your suppliers’ people security arrangements.
• What security protections you have asked your immediate suppliers to provide, and what they, in turn, have asked any sub-contractors to do:
  • Determine whether or not your suppliers and their sub-contractors have provided the security requirements asked of them.
  • Understand what access (physical and logical) your suppliers have to your systems, premises and information and how you will control it.
  • Understand how your immediate suppliers, control access to, and use of, your information and/or assets – including systems and premises, by any sub-contractors they employ.
• You should focus your efforts in this area on those parts of your suppliers’ business or systems that are used to handle your contract information, or to deliver the contracted product or service.

3.3. Understand the security risk posed by your supply chain

Assess the risks these arrangements pose to your information or assets, to the products or services to be delivered, and to the wider supply chain.

Sources of risk

Risks to and from the supply chain can take many forms. For example, a supplier may fail to adequately secure their systems, may have a malicious insider, or a supplier’s members of staff may fail to properly handle or manage your information. It could be that you have poorly communicated your security needs so the supplier does the wrong things, or the supplier may deliberately seek to undermine your systems through malicious action (this may be under state influence for national security applications). Use the best information you can to understand these security risks. For example:

• Common cyber attacks – reducing the impact
• Insider data collection report
• Insider risk assessment
• CPNI Holistic Management of Employee Risk (HomER).

Understanding the risk associated with your supply chain is key to ensuring security measures and mitigations are proportionate, effective and responsive. Use this understanding to decide the appropriate levels of protection you will expect suppliers across your supply chain to provide for any contract information, and contracted products or services.

Plan of action

It may be useful to group different lines of work, contracts or suppliers into different risk profiles, based on considerations such as: the impact on your operations of any loss, damage or disruption, the capability of likely threats, the nature of the service they are providing, the type and sensitivity of information they are processing etc. Each profile will require slightly different treatment and handling to reflect your view of the associated risks. This may make things easier to manage and control. You should document these decisions and share them with suppliers. For example, you may decide that contracts which provide basic commodities such as stationery, or cleaning services require very different approaches to management to those that provide critical services or products.

3.4. Communicate your view of security needs to your suppliers

Ensure that your suppliers understand their responsibility to provide appropriate protection for your contract information and contracted products and services and the implications of failing to do so. Ensure your suppliers adhere to their security responsibilities and include any associated security requirements in any sub contracts they let. You should decide whether you are willing to permit your suppliers to sub-contract and delegate authority to do so appropriately. Give your suppliers clear guidance on the criteria to use for such decisions (e.g. the types of contract that they can let with little/no recourse to you, and those where your prior approval and sign-off must always be sought).

3.5. Set and communicate minimum security requirements for your suppliers

You should set minimum security requirements for suppliers which are justified, proportionate and achievable. Ensure these requirements reflect your assessment of security risks, but also take account of the maturity of your suppliers’ security arrangements and their ability to deliver the requirements you intend to set. It may also be sensible to identify circumstances where it would be disproportionate to expect suppliers to meet the minimum security requirements. For example, this may only be relevant for those suppliers who only need ad hoc, or occasional access to limited and specific data, and/or access to your premises. You should document these considerations and provide guidance on the steps you intend to take to manage these engagements. This approach could help reduce your workload and avoid creating additional, unnecessary work for these parties.

Case by case

Consider setting different protection requirements for different types of contracts, based on the risk associated with them – avoid situations where you force all your suppliers to deliver the same set of security requirements when it may not be proportionate or justified to do so. Explain the rationale for these requirements to your suppliers, so they understand what is required from them. Include your minimum security requirements in the contracts you have with suppliers and in addition, require that your suppliers pass these down to any sub-contractors they might have.

3.6. Build security considerations into your contracting processes and require that your suppliers do the same

Build security considerations into your normal contracting processes. This will help you to manage security throughout the contract, including termination and the transfer of services to another supplier.

Evidence
Require prospective suppliers to provide evidence of their approach to security and their ability to meet the minimum security requirements you have set at different stages of the contract competition.

Providing support
Develop appropriate supporting guidance, tools and processes to enable the effective management of the supply chain by you and your suppliers, at all levels.

You should:

• Ensure the security considerations you build into your contracts are proportionate and align with the various stages of the contracting process.
• Require their adoption in contracts and train all parties on their use.
• Check that your supporting guidance, tools and processes are being used throughout the whole of your supply chain.
• Require contracts to be renewed at appropriate intervals, and require reassessment of associated risks at the same time.
• Seek assurance that your suppliers understand and support your approach to security and only ask them to take action or provide information where it is necessary to support the management of supply chain security risks.
• Ensure that contracts clearly set out specific requirements for the return and deletion of your information and assets by a supplier on termination or transfer of that contract.

3.7. Meet your own security responsibilities as a supplier and consumer

Ensure that you enforce and meet any requirements on you as a supplier. Provide upward reporting and pass security requirements down to sub-contractors. Welcome any audit interventions your customer might make, tell them about any issues you are encountering and work proactively with them to make improvements. Challenge your customers if guidance covering their security needs is not forthcoming, and seek assurance that they are they happy with the measures you are taking.

3.8. Raise awareness of security within your supply chain

Explain security risks to your suppliers using language they can understand. Encourage them to ensure that key staff (e.g. procurement, security, marketing) are trained on, and understand these risks, as well as their responsibilities to help manage them.

• Set goals: Establish supply chain security awareness and education for appropriate staff.
• Information sharing:Promote and adopt the sharing of security information across your supply chain to enable better understanding and anticipation of emerging security attacks..

3.9. Provide support for security incidents

Whilst it is reasonable to expect your suppliers to manage security risks in accordance with the contract, you should be prepared to provide support and assistance if necessary where security incidents have the potential to affect your business or the wider supply chain.

Make requirements clear
You should clearly set out requirements for managing and reporting security incidents in the contract. These should clarify supplier’s responsibilities for advising you about such incidents – reporting timescales, who to report to etc. Suppliers should also be clear about what support they can expect from you if an incident occurs – required ‘clean up’ actions, losses incurred, etc.

Propagate lessons learned
Where lessons have been learnt from security incidents, communicate these to all your suppliers, to help them becoming victims of ‘known and manageable’ attacks.

3.10. Build assurance activities into your supply chain management

• Require those suppliers who are key to the security of your supply chain, via contracts, to provide upward reporting of security performance and to adhere to any risk management policies and processes.
• Build the ‘right to audit’ into all contracts and exercise this. Require your suppliers to do the same for any contracts that they have let that relate to your contract and your organisation. (Note that this might not always be possible or desirable, particularly where this relates to a Cloud service).
• Build, where justified, assurance requirements such as Cyber Essentials Plus, penetration tests, external audit or formal security certifications into your security requirements.
• Establish key performance indicators to measure the performance of your supply chain security management practice.
• Review and act on any findings and lessons learned.
• Encourage suppliers to promote good security behaviours.

3.11. Encourage the continuous improvement of security within your supply chain

• Encourage your suppliers to continue improving their security arrangements, emphasising how this might enable them to compete for and win future contracts with you. This will also help you to grow your supply chain and choice of potential suppliers.
• Advise and support your suppliers as they seek to make these improvements.
• Avoid creating unnecessary barriers to such improvements: acknowledge and be prepared to recognise any existing security practices or certifications they might have that could demonstrate how they meet your minimum security requirements.
• Allow time for your suppliers to achieve security improvements, but require them to provide you with timescales and plans that demonstrate how they intend to achieve them.
• Listen to and act on any concerns highlighted through performance monitoring, incidents, or upward reporting from suppliers that may suggest that current approaches are not working as effectively as planned.

3.12. Build trust with suppliers

• Seek to build strategic partnerships with key suppliers, sharing issues with them, encouraging and valuing their input. Gain their buy-in to your approach to supply chain security, so that it takes account of their needs as well as your own.
• Let them manage sub-contractors for you, but require them to provide you with appropriate reporting to confirm the status of these relationships.
• Maintain continuous and effective communications with your suppliers.
• Look at supply chain management as a shared issue.

4.Procedures

All information assets that process, store, receive, transmit or otherwise could impact the confidentiality, integrity, and accessibility of XXX information must meet the required security controls defined in this procedure that are based on the ISMS Risk assessment procedure.

4.1 Supply Chain Risk Management Plan

The following shall be implemented:

a. Develop a plan for managing supply chain risks associated with acquisition, delivery, integration, operations and maintenance, and disposal of the information systems and services:

1. The Supply Chain Risk Management (SCRM) plan should provide the basis for determining whether a technology, service or information system is fit for purpose and as such the controls need to be tailored accordingly.
2. The SCRM plan shall include the following:
   • an expression of the supply chain risk tolerance for the agency;
   • acceptable supply chain risk mitigation strategies or controls;
   • a process for consistently evaluating and monitoring supply chain risk;
   • approaches for implementing and communicating the plan;
   • a description of and justification for supply chain risk mitigation measures taken; and associated roles and responsibilities..

b. Review and update the supply chain risk management plan on an annual basis or as required, to address threat, organizational or environmental changes.
c. Protect the supply chain risk management plan from unauthorized disclosure and modification.

4.2 Establish SCRM Team

The following shall be implemented:
a. Establish a supply chain risk management team that consists of the defined roles and is responsible for identifying, assessing, and managing risks while using coordinated efforts.
b. The SCRM team shall consist of personnel with diverse roles and responsibilities for leading and supporting SCRM activities, including risk executives, information technology, contracting, information security, privacy, mission, or business, legal, supply chain and logistics and acquisition.
c. The SCRM team shall be an extension of the security and privacy risk management processes or be included as part of an organizational risk management team.

4.3 Supply Chain Controls and Processes

The following shall be implemented:

1. Establish processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of information systems in coordination with the identified supply chain personnel.
   • Supply chain elements include organizations, entities, or tools employed for the acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components.
   • Supply chain processes include hardware, software, and firmware development processes;
   • shipping and handling procedures; personnel security and physical security programs;
   • configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components.
2. Employ the following controls to protect against supply chain risks to information assets, systems, system components, or system services and to limit the harm or consequences from supply chain related events (examples):
   • Control Assessments
   • External System Services
   • Acquisition Process
   • Controlled Maintenance
   • Component Authenticity
   • Component Disposal
3. Document the selected and implemented supply chain processes and controls in an agencydefined document such as a SCRM plan.

4.4 Acquisition Strategies, Tools, and Methods

Acquisition strategies, contract tools, and procurement methods shall be employed to protect against, identify, and mitigate supply chain risks. Examples are as follows:

• Including incentive programs to system integrators, suppliers, or external services providers to ensure that they provide verification of integrity as well as traceability.
• Requiring tamper-evident packaging.
• Using trusted or controlled distribution.
• stablish compliance standards for all third-party vendors, including manufacturers, suppliers, and distributors.
• Define user roles and implement security controls to restrict who is able to access your system and what level of clearance they’ve given.
• Perform a thorough vendor risk assessment prior to signing any contracts.
• Implement data stewardship standards that define who owns certain data and what they’re to do with that data.
• Provide comprehensive training for all employees about cyber security protocols.
• Implement a software solution that provides you with total visibility into your supply chain, so you can quickly identify unusual activity.
• Work with vendors in your supply chain network to develop a unified disaster recovery plan to ensure business continuity.
• Establish backup controls to safeguard your data backups.
• Regularly update your company’s anti-virus, anti-spyware, and firewall software solutions, as well as look into more advanced cyber security measures, such as DNS filtering and network access control.

4.5 Supplier Assessments and Reviews

Supply chain-related risks associated with suppliers or contractors and the system, system component, or system service they provide shall be assessed and reviewed annually. An assessment and review of supplier risk should include security and supply chain risk management processes, foreign ownership, and the ability of the supplier to effectively assess subordinate second tier and third-tier suppliers and contractors. The reviews shall consider documented processes, documented controls, and publicly available information related to the supplier or contractor.

4.6 Notification Agreements

Agreements and procedures with entities involved in the supply chain shall be established for the notification of supply chain compromises including security incident and a privacy breach and the notification of assessment or audit results.

4.7 Inspection of Systems or Components

A process to inspect information systems annually or upon any indications of the tampering of information systems shall be implemented. Indications of a need for inspection include changes in packaging, specifications, factory location, or entity in which the part is purchased, and when individuals return from travel to high-risk locations.

4.8 Component Authenticity

The following shall be implemented:
a. Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and
b. Report counterfeit system components to the agency-defined personnel.
Organizations should include in their anti-counterfeit policy and procedures, a means to help ensure that the components acquired and used are authentic and have not been subject to tampering.

4.9 Component Authenticity | Anti-Counterfeit Training
The following agency-defined roles shall be trained to detect counterfeit system components (including hardware, software, and firmware).

• Personnel conducting configuration management activities
• System administrators
• Database administrators
• Network administrators
• Procurement personnel

4.10 Component Authenticity | Configuration Control for Component

Configuration control shall be maintained over system components awaiting service or repair and serviced or repaired components awaiting return to service. Organizations shall manage risks associated with component repair including the repair process and any replacements, updates, and revisions of hardware and software components within the supply
chain infrastructure.

4.11 Component Disposal

Defined data, documentation, tools, or system components shall be disposed of without exposing sensitive or operational information, which may lead to a future supply chain compromise. Examples include the following:
a. Monitoring and documenting the chain of custody through the destruction process.
b. Training disposal service personnel to ensure accurate delivery of service against disposal policy and procedures.
c. Implementing assessment procedures for the verification of disposal processes with a frequency that fits agency needs.
d. Using Media Sanitization techniques—including clearing, purging, cryptographic erase, deidentification of personally identifiable information, and destruction—prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal.

5. Enforcement

Violations of this policy or failure to implement provisions of this policy may result in disciplinary action up to and including termination, civil litigation, and/or criminal prosecution.

1. Purpose

This procedure defines intellectual property and outlines the responsibilities of the XXX’s employees and key processes in managing the creation, procurement and use of intellectual property rights (IPR).

2. Scope

This procedure outlines what department employees must do to avoid infringing the copyright and IP of others, and meet obligations under the Copyright Act 1957. Intellectual Property (IP) covers a range of intangible property that results from creative and intellectual effort including literary and artistic works, computer programs, databases, film and sound recording, trademarks, and designs. The most common type of IP that departmental employees will create, acquire and/or use in their work is copyright.

Copyright exists in content developed or acquired by the XXX whether for public use or for limited use such as training, as well as in works created or owned by others (i.e. third-party materials) used by the XXX. Copyright is automatic, and creators or owners do not need to register their copyright or display a copyright symbol for their work to be protected. XXX(as the employer) owns the copyright in material created by its employees in the course of their duties unless otherwise agreed between the employer and employee. It does not matter that the employee creates the material (either wholly or in part) outside normal work hours and without using XXX facilities or equipment. Generally, the deciding factor is whether the materials created relate to the employee’s official duties. Creators as an employee of XXX also have moral rights which are additional to copyrights and include the right to attribution, the right against false attribution, and the right to have the integrity of their work respected.

3. Responsibilities

3.1 All employees

• Avoid infringing the IP rights or moral rights of others.
• Use, to the maximum extent possible, third-party materials that have a Creative Commons or a similar open licence to:
  • minimise the costs of seeking permission and managing third-party licences
  • reduce costs of statutory licences for copying within the organization
• Ensure that copying or adaptation of third-party materials is either permitted or permission has been obtained.
• Ensure all third-party materials in departmental publications are attributed and to any licence conditions.
• Maintain appropriate records of copyright materials created, used or procured in accordance with the XXX’s Handling of Information and other asset policy.
• Comply with the requirements of the statutory and voluntary licences, when copying and communicating third-party materials for purposes of their work.
• Participate in copyright sampling surveys as required to meet statutory licence agreements.

3.2 Copyright team, Information and Governance Management

Provide guides, tools and advice to XXX employees in relation to creation and use of IP, including:

• location and use of Creative Commons, other openly licensed or public domain materials
• finding alternatives, workaround or in-house solutions to using third-party materials
• requesting and managing permissions to use third-party materials (i.e. licences)
• adopting best practice copyright record keeping and management
• Respond to external parties who request permission to copy department works.
• Liaise with the unit who is custodian of the work, to confirm the XXX’s copyright in the materials.
• Ensure records relating to the creation, procurement and use of copyright material are appropriately stored, monitored and maintained.
• Ensure significant IP (e.g. trademarks, published content such as online courses, teaching materials, posters, videos, ebooks, apps) with public, strategic or innovative value is recorded in the XXX’s Intellectual property register

4.0 Procedure

1. Company shall respect intellectual property (IP) and conduct its business in compliance with the IP-related laws as applicable in the jurisdiction of Republic of India and its agreements with other companies.
2. Company shall actively protect its own IP.
3. Company shall maintain an effective system of IP asset management, including maintaining an inventory and records of IP-related assets and agreements.
4. Company shall not knowingly infringe a third party’s intellectual property in its products, services, or components, or disclose or use a third party’s trade secrets without the express or implied consent of the owner or as permitted by law.
5. Company shall not knowingly purchase or use counterfeit or other infringing goods and services in running its business, including counterfeit trademark goods or infringing copyright material (such as software, publications, video, audio, or other content).
6. Company shall document and maintain written records of all substantial transactions and uses that involve the exercise of IP rights. (This includes, for example, licenses or assignments of rights; manufacture, reproduction or distribution of patented, trademarked or copyrighted items; and disclosure and use of trade secrets.)
7. Company shall require, through binding policies or agreements with employees and contractors that its personnel comply with the applicable IP laws and the Company’s IP policies and IP-related provisions in agreements with other companies.
8. Company shall develop and implement a management system to help ensure that all personnel follow its IP policies. This management system shall encompass all IP-related policies, procedures and adequate and accurate records necessary to implement, measure, and improve Company’s IP protection and compliance program.

5. Using third-party material

All employees seeking to use third-party material must follow these steps:

Step 1: Assess if the material is protected by copyright

• If yes – go to step 2
• If no – go to step 3

Step 2: Assess if the use is permitted or if permission is required
Ensure that copying or adaptation of third-party materials is either permitted or permission has been obtained.

If use is permitted
Some creators permit the use of their work without further permission, as long as the user adheres to their conditions. .

Forward all requests received from third parties, to use the XXX’s owned copyright materials not licensed with a CC licence, to the Information Management team.

If permission is required
If it is not clear that the employee can use the material, then they must request permission (a licence) from the copyright owner in writing.

The copyright owner may give permission under certain conditions, such as payment (licence fee), a time limit (term), and/or a specific attribution. Contact the Copyright team for help with permission requests.

Step 3: Attribute and adhere to any conditions
Ensure all third-party materials in departmental publications are attributed and adhere to any licence conditions.

All third-party materials must be attributed (i.e. acknowledged) in XXX publications (whether print, video, audio or online), even attribution is not a requirement of the licence or the material is in the public domain. An attribution is essential because it tells everyone that copyright in the attributed material is not owned by the XXX.

Adhering to any conditions is essential for use of third-party material to be legal. In addition to attribution, other conditions may include, but are not limited to:

• non-commercial use only
• no derivatives (i.e. no changes or editing)
• share alike (i.e. share under same licence as original)
• remuneration (a licence fee)
• who can access ( publicly available)
• a time limit which states when the licence expires (a licence term)
• the number of copies (e.g. print run) or downloads a person can make.
• Apply an appropriate copyright licence

6. Maintain records for copyright and other IP

Step 1: Record copyright elements used in significant publications
When developing significant assets (e.g. projects, reports, websites, training and professional development materials), the author must record the incorporated copyright elements (e.g. material sourced under open licences, content for which specific permission has been obtained, department-created diagrams and illustrations). The Copyright register template can be used to record copyright elements in an asset.

Step 2: Save and maintain records relating to use, creation and procurement of copyright and other IP
CISO and dept Head must ensure all records relating to copyright and IP are saved in the relevant records management system and materials acquired under limited terms (e.g. a time-limited licence) are monitored and use discontinued when terms expire. Saved records should include any copyright licences, permission emails, contractor agreements, assignment of copyright, MOUs with other organisations, and the copyright register .

Step 3: Record significant copyright or other IP in the department’s IP register
CISO and dept Head must ensure significant IP with public, strategic or innovative value created by their business unit is recorded in the XXX’s Intellectual property register

7. Security And Confidentiality Management

• Company shall maintain physical security designed to effectively protect trade secrets(where applicable) and other confidential information, and IP-related records, masters, tools, inventory and related materials.
• Company shall maintain computer and network security effective for protecting trade secrets, other confidential and proprietary information, and IP related records, and for discouraging violations of Company’s IP policies on the Company’s computers and networks.
• Company and its personnel shall only make trade secrets and other proprietary information available to third parties on a “need to know?? basis, and subject to company procedures and written agreements containing adequate confidentiality and other protections.
• Company shall execute written confidential or Non-disclosure agreements with third parties prior to disclosure of any confidential information of the Company to any third party(ies).
• Any IP generated, created or developed by any of the employees/representatives and agents of the Company and/or consultants engaged by the Company, during the term of their employment or engagement as the case may be, for and/or on behalf of the Company, shall be “work made for hire?? and shall be assigned by such persons to the Company. Further, the Company shall have the sole and exclusive ownership to such IP generated, developed or created unless otherwise agreed by the Company by way of a written contract or as may be applicable by the relevant IP law.

8. Training And Capacity Building

• Company shall provide ongoing appropriate level training on IP protection and management to all relevant personnel.
• Company shall provide specialized training to those personnel responsible for the development and implementation of the IP protection, management, and compliance program
• Company shall provide appropriate level training on IP protection and management for relevant supply chain members.

9. Monitoring And Measurement

• Company shall establish and operate a system to monitor its performance in meeting the Company’s relevant IP policies.
• Company shall incorporate the information gained from the IP compliance team through the monitoring system into the overall evaluation of its departments.

10. Corrective Actions And Improvements

• Company shall maintain a system to track and deal with problems in IP protection, management and compliance found through the monitoring process. The tracking system will identify the corrective action to be taken, the timeline, and the responsible party.
• Company shall develop and implement an annual or other regular improvement plan for IP protection, management, and compliance.
• In case of violation/infringement of any IPR such as trademark infringement by any employee/representative or any third party infringing upon the IPR of the Company, the Compliance Team of the Company would first investigate the matter in association with its Advocates and make recommendations to the Director/CFO for resolution of such violation/infringement including need for any legal course of action.

11. IP Licensing and Transfer

• The Company may license its IP to any of its Subsidiaries, Affiliates or a third party (ies) through various modes of licensing strategy such as: Exclusive licensing, Sole licensing, Non-Exclusive Licensing, Sub-licensing and licensing in general. The Company shall document such IP licensing through a license Agreement where each such license agreement shall define the terms and conditions for the proper use of IP of the Company.
• The Company may transfer its IP to any of its Subsidiaries, Affiliates or a third party (ies) through a signed IP transfer agreement on the conditions as may be deemed to be fit and proper to the Company.

12. Jurisdiction

• This Policy shall be governed by the laws of Republic of India and the courts at Pune Maharashtra shall have the jurisdiction to the same.

Overview

There are many occasions when information is transferred between departments, to third-party service providers, to other public bodies, commercial organisations and individuals. This is done using a wide variety of media and methods, in electronic and paper format. In every transfer there is a risk that the information may be lost, misappropriated or accidentally released. XXX has a duty of care in handling information. For legal reasons such as confidentiality or data protection, and to maintain the trust of our service users and partners it is essential that the transfer is performed in a way that adequately protects the information. It is the role of the Sender to assess the risks and ensure that adequate controls are in place. This policy outlines the responsibilities attached and the minimum security requirements for transfer.

Scope

This procedure states the minimum security requirements for physical transfer of information into, across and out of the organisation, in any format. For the purpose of this document, Information refers to both textual information (e.g. word-processed documents, reports and spreadsheets), and raw unformatted data (e.g. backup tapes), in any format and on any medium. This policy applies to all employees of the XXX and any Third-party that processes the organisation
information.

Procedure

4.1. The sender’s responsibility
With each information transfer there is a risk that the information may be lost, misappropriated or accidentally released. It is the responsibility of the sender to assess all risks and ensure that adequate controls are in compliance with this policy. This section contains some of the things that must be considered before transferring information.

4.2. Is the transfer legal and necessary?
It is dangerous to assume that because someone asks for information that they are necessarily authorized or legally entitled to have it. If you are in doubt then you should check with your manager. Once you are sure that the transfer is legal and necessary then you must decide what kind of information you are dealing with. This will determine what security is appropriate. To transfer personal or confidential information without these checks may leave XXX open to Legal and Reputational damage and the sender may be subject to disciplinary action.

4.3. Is it Personal information?

Personal information is about a living, identifiable individual. If it contains details of racial or ethnic origin, political opinions, religious beliefs, trade union membership, physical or mental health, sexual life, commission of offences, court appearances and sentences it is further classified as sensitive personal information. Anything we do with personal information must comply with the Data Protection Act. Before you make any transfer you must:

• Ensure transfers to Media organisations are approved by the Communications Department.
• Obtain and document the approval of the Information Owner for transfer
• Ensure that the transfer is legal (in particular under the Data Protection Act. See Appendix below)
• Ensure that the transfer is necessary (is there a less intrusive way)
• Remove or blackout anything that is not essential for the recipient’s purpose
• Have a documented agreement in place to ensure the recipient understands their responsibilities under the law, particularly what to do with the transfer file after they have extracted the information to their system

4.4. Is it confidential information?
Confidential information is that for which the XXX has a duty of confidentiality. This may include information that affects the business interests of a third party, or for which the sender does not hold copyright e.g. bank details, salary details, contracts, agreements. Unauthorised release of confidential information can leave the XXX open to legal sanction or litigation. It can also erode the trust of the Public and its Partners in the XXX itself. Before you transfer you must:

• Obtain and document the approval of the information owner for transfer
• Ensure that you are not breaching a Duty of Confidentiality
• Ensure that the transfer is necessary (is there a less intrusive way)
• Remove anything that is not essential for the recipient’s purpose
• Have a documented agreement in place to ensure the recipient understands their responsibilities under the law, particularly what to do with the transfer file after they have extracted the information to their system

4.5. Does Public information need any special controls?
Public information is any information that is freely released or exchanged and presents minimal risk to the organization in terms of content, quality or timeliness e.g. promotional brochures. In general there are no special security requirements for transfer of Public information because their release represents no special risk. Public information will be transferred in the most cost-effective method available. Before you transfer you must seek the permission of the Department that produced or owns this information before making any transfer, even if the transfer appears harmless.

4.6 Transfer Principles
The following principles apply to all Information transfer in, out and within the XXX scope:

1. Formal arrangement and agreements that surround the sharing must be set up prior to data transfer
2. Agreements should, where it is not covered by other arrangements, define ‘type’, ‘fair processing’, ‘usage – what for and how’, ‘accuracy’, ‘handling duration’, and the ‘remit for transfer’
3. Information transfer must be in accordance with any ethical, legal, or governance requirements held upon the data, and justifiable in this context. CISO/ Dept Heads will make all reasonable attempts to ascertain and log these requirements prior to transfer
4. Transfer of personal Information must be undertaken in line with data protection legislation.
5. Transfer volume and frequency must be in accordance with the minimum required.
6. Transfer arrangements must minimise any risk associated with the loss or improper use of the information being transferred
7. It is the ‘ norm’ to perform handling under a Information Sharing Agreement or Open-Use Licence
8. Manual or automated steps must be in place to check that transfers are in accordance with these principles

5.0 Requirements for Transferring Personal or Confidential Information
Having decided what kind of information you have, and prepared it for transfer, the sender must consider the various methods of transfer available and whether they are appropriate. For all transfers of Personal or Confidential information it is essential that the identity and authorisation of the recipient has been appropriately authenticated by the sender.
5.1. Electronic Mail
Information must be enclosed in an attachment and encrypted using a product approved by the XXX set at an appropriate strength. Minimum standard for encryption is AES (256 bit). WINZIP 11.1 and above offer this.

• Any password must be to Organisation standard. 7 characters, mix of alpha and numeric. Further details of the password policy can be found in secure Authentication procedure. § Any password to open the attached file must be transferred to the recipient using a different method than e-mail, e.g. a telephone call to an agreed telephone number, closed letter.
• E-mail message must contain clear instructions on the recipient’s responsibilities and instructions on what to do if they are not the correct recipient.
• An accompanying message and the filename must not reveal the contents of the encrypted file.
• Check with the recipient that their e-mail system will not filter out or quarantine the transferred file.
• The sender must check at an appropriate time that the transfer has been successful, and report any issues to their line manager.

5.2. Electronic Data Transfer (FTP, Secure FTP, BACS, DCSF’s COLLECT)
Standard FTP without encryption is inherently insecure and should not be used for transmitting personal or confidential information. SFTP file transfers are acceptable but such transfers must be set up and administered by the Information Services department. External secure transmission systems such as BACS or DCSF’s COLLECT system are designed to be secure provided that they are implemented configured and used correctly. However, it is the responsibility of the sender to ensure that the use of such a system is appropriate for the use they propose. If in doubt, advice should be sought from the system owner.

5.3. Electronic memory, (CD, DVD, Floppy, USB drive, Memory Card)
Information must be enclosed in a file and encrypted using a product approved by the XXX set at an appropriate strength. Minimum standard for encryption is AES (256 bit). WINZIP 11.1 and above offer this.

• Any password must be to Organisation standard. 7 characters, mix of alpha and numeric. Further details of the password policy can be found in Chapter 7 of the Information Security policy.
• Any password to open the attached file must be transferred to the recipient using a different method than e-mail, e.g. a telephone call to an agreed telephone number, closed letter.
• An accompanying message should contain clear instructions on the recipient’s responsibilities, and instructions on what to do if they are not the correct recipient.
• An accompanying message and the filename must not reveal the contents of the encrypted file.
• The sender must check at an appropriate time that the transfer has been successful, and report any issues to their line manager.

5.4. FAX Transmission
FAX is inherently insecure and is not recommended for transfer of sensitive information. However it is acknowledged that certain circumstances demand it.

• Sender must check that the Fax number is correct and that the receiver is awaiting transmission.
• For high sensitivity information the number must be double-checked by a colleague before transmission, and telephone contact should be maintained throughout transmission.
• Both sender and receiver must have an agreed process to avoid their copy being left on the Fax machine, and a clear requirement to securely destroy the message when no longer required.
• The message should contain clear instructions on the recipient’s responsibilities and instructions on what to do if they are not the correct recipient.
• The sender must check at an appropriate time that the transfer has been successful, and report any issues to their line manager.

5.5. Delivery by Post or by Hand
It is essential that the file, whether electronic or paper is kept secure in transit, tracked during transit, and delivered to the correct individual.

• An appropriate delivery mechanism must be used.
• Package must be securely and appropriately packed, clearly labelled and have a seal, which must be broken to open the package.
• Package must have a return address and contact details.
• The label must not indicate the nature or value of the contents.
• Package must be received and signed for by addressee.
• The sender must check at an appropriate time that the transfer has been successful, and report any issues to their line manager.

5.6. Telephone/Mobile Phone
As phone calls may be monitored, overheard or intercepted either deliberately or accidentally, care must be taken as follows.

• § Transferred information must be kept to a minimum.
• § Personal or Confidential information must not be transferred over the telephone unless the identity and authorisation of the receiver has been appropriately confirmed.

5.7 Internet Based Collaborative Sites
Must not be used for Personal or Confidential information.

5.8. Text messaging (SMS), instant Messaging (IM)
Must not be used for Personal or Confidential information.

1 Purpose

To establish the processes that IT must follow when considering the engagement of Cloud Computing services and service providers.

2 Scope

This procedure applies to all XXX’s Information or Information Systems which are stored with or hosted by any party other than the XXX within one of its Data Centres.

3 Classification

This procedure provides the process to be followed when considering and before making a decision to contract Cloud Computing services such as:

Applications As A Service (AaaS)/Software As-A-Service (SaaS)
Platform-As-A-Service (PaaS)
Infrastructure-As-A-Service (IaaS).

Classification Description:

1. Level One Data – “Confidential”
2. Level Two Data – “Restricted”
3. Level Three Data – “Internal Use”
4. Level Four Data – “General”

4 Procedures

Consistent with the principles provided in the Enterprise Architecture Policy, it is the XXX’s preferred position to adopt and use Cloud Computing services first, with all new services deployed in the cloud where possible.

4.1 Risk assessment
The CISO must conduct a risk assessment when considering the use of Cloud Computing services. The extent of the ‘risk assessment’ must be commensurate with the Information Security Classification (Ref: Risk assessment Procedure)

As a first step, the CISO must consider whether the selection of a Cloud Computing service is appropriate given the Information Security Classification (Ref: Risk assessment Procedure) associated with the Information System under consideration. With reference to the Cloud Service Use Inherent Risk Schedule determine whether the XXX should be considering a Cloud Computing service and the level of rigor that should be applied in this and subsequent processes before selecting a Cloud Computing provider.

The CISO should also consider the cost to manage the associated risks and its impact on the value proposition.The following risk categories should be used when identifying risks:

• quality – does the cloud solution meet stakeholder needs
• financial – does the cloud solution provide value for money
• organisational – does the cloud solution work within the XXX’s culture
• integration – can the cloud solution meet objectives without business or technical integration difficulties
• compliance – does the cloud solution comply with XXX’s legal, regulatory and policy obligations
• business continuity – can the cloud solution recover from outages or disaster situation
• external – is the Cloud Service Provider’s performance adequate.

The Cloud Computing service provider and all subcontractors in the service provision supply chain must be subject to the risk assessment and conditions on the service agreement/contract. Each of the factors below should be addressed when preparing a risk assessment for proposed Cloud Computing deployments.

4.1.1 Evaluation process

CISO should use the Information security policy for supplier relationship as the basis for evaluating the implementation of a potential Cloud Computing solution. When deciding to use a Cloud Computing service or to store Information or data in a facility which is not owned by the XXX, it is the responsibility of the CICO to consult with other appropriate Information System Custodians, process owners, stakeholders, and subject matter experts during the evaluation process.

4.1.2 Intellectual property and copyright
CISO should refer to the Intellectual Property Policy and Procedure to ensure that Information or data is not stored in any facility where the XXX’s intellectual property, copyright, trademarks or patents may be compromised. Information or data must not be stored in such a way that allows unauthorised parties to claim ownership of the Information or data.

4.1.3 Location of provider and relevant infrastructure
Due to the nature of web-based services, providers or their equipment will often be based interstate or overseas. If any data is to be hosted or stored outside the organziation, CISO must check where this will be, who will have access, who will be managing this and how. Depending on the response, additional terms and conditions may need to be included in the legal contracts to mitigate any potential risks. Providers should notify the XXX if any of these conditions change during the agreement. Data must not be allowed to be stored outside the country as it may be subject to different laws, which could affect XXX compliance requirements, such as privacy. Use of three-way encryption (upload, download and storage) should be considered to improve data security.

4.1.4 Privacy and Data Security
The University is subject to the Indian IT Act 2000 which specifies conditions regarding the use and handling of Personal Information as defined in that Act. If any Personal Information is to be collected by, or disclosed or transferred to the service provider, CISO needs to make sure it meets these requirements. The Information System Custodian can assess these requirements by undertaking a Privacy Threshold Assessment (PTA) and, if required, a Privacy Impact Assessment (PIA). Performing a PTA enables the CISO to quickly assess whether Personal Information is involved. If Personal Information is involved, a PIA should be completed (effort commensurate with the risk) . To fulfill its privacy obligations the XXX must take reasonable steps to protect Personal Information from misuse, loss, unauthorized access, modification or disclosure. XXX will retain ownership of its Information irrespective of where it is stored. Information and Communication Technology (ICT) Services should be consulted where any security issues are unclear. Relevant data security issues for the CISO to consider include:

• data control
• data encryption
• blending of data with other customer data
• business process if a security breach does occur or if data is damaged or destroyed
• data backup frequency/conventions/standards/accessibility
• availability of an audit trail to demonstrate that data is reliable.

Relevant data access issues for the CISO to consider include:

• quick and easy access
• format useability
• process to follow if data cannot be accessed or access is delayed
• ease with which the data can be amended or deleted if required.
• Information or data that has been marked as Restricted or Confidential, Information must be stored in a way that minimises the likelihood that the Information or data can be accessed by any unauthorised parties.

4.1.5 Records retention and availability
All XXX records must be stored, retained and accessed in accordance with relevant legislation and XXX’s Information classification and Handling policy.

4.1.6 Data classification

Storing or transmitting of level 1 data is prohibited on all cloud services unless:

• A contract with vendor contains appropriate Information Security Supplemental Language
• Utilization of the service is approved by the appropriate data owner
• Approval is granted by the CISO and approved by the CEO
• The cloud service must be configured to utilize the multi-factor service Duo or other approved multi factor solution.

2. Storing or transmitting of level 2 and Level 3 data Levels is prohibited on all cloud services unless:

• A contract with vendor contains appropriate Information Security Supplemental Language
• Utilization of the service is approved by the appropriate data owner
• Approval is granted by the CISO and approved by the CEO
• The cloud service must be configured to utilize the multi-factor service Duo or other approved multi factor solution.

3. Cloud application administrators are responsible for maintaining accurate and timely user account status

• Terminated users must have their account to the cloud service disabled no later than the day of termination.
• Accounts should be provisioned with the Principle of Least Privilege

4. Cloud application administrators are responsible for reviewing all accounts and their associated level of application access on a quarterly basis

• Active accounts should be compared to employee records.
• Any terminated users should have their accounts removed or disabled.

5. Cloud application administrators are required to provide an annual report of compliance with this policy.

• Once a year any administrator of a cloud-based SaaS application will be required to provide a listing showing all the accounts and their associated rights or privilege level associated to that account to the CISO.
• Application Owners of applications that manage Level one data must work with the cloud application vendor to get the updated SOC 2 audit and cyber liability insurance certificate of insurance (COI) on an annual basis and post those documents with the CISO

Failure to maintain these reporting requirements will lead to the violating application being blocked from running on the network.

4.1.7 Business continuity
CISO must ensure the continuity of service for every system with a Cloud Computing provider. This requires CISO to:

• determine if the Cloud Computing provider’s business continuity and disaster recovery plan is acceptable
• determine the impact of outages
• ensure the availability of data in the event of any and all types of outage (e.g. through off site backup data that is accessible to the organisation)
• prepare a business continuity plan for both short and long term
• include scheduled outages in service level agreements
• arrange a guarantee of availability
• consider the use of multiple Cloud Computing providers depending on the business criticality of the system deployed to the cloud
• determine whether Information is able to be retrieved or disposed of in compliance with the Indian IT act 2000 during or at the conclusion of a contract with the Cloud Computing provider.

4.1.8 Legal issues
Prior to approaching the market, CISO should determine the contractual terms required, even when it is anticipated that a standardised ‘click wrap’ agreement will be the only option. A prior understanding of the XXX’s terms will provide a basis to ensure the final contract will meet business requirements, security requirements and adequately address the risks associated with the cloud solution.

At a minimum the SLA will include:

• clear definition of services
• agreed upon service levels including service availability time, service outages, routine maintenance timeframes, upgrades and changes to the cloud computing services
• clearly defined physical and logical security conditions
• performance measurement
• problem management
• customer duties
• disaster recovery
• termination of agreement
• protection of sensitive Information and intellectual property
• agreement of the disposal of Information when required
• definition of vendor versus customer responsibilities, especially pertaining to backups, incident response, and data recovery.

An exit strategy for disengaging from the vendor and/or service should be planned before committing Information or data to a Cloud Computing or outsourced service. The exit strategy should outline how the relevant records will be preserved and maintained, and how the service can be discontinued or transitioned to another provider. Contracts and/or agreements are to cover the Cloud Computing provider and all subcontractors involved in providing the Cloud Computing service. XXX should consider including the need for vulnerability assessment/penetration testing in any contracts/agreements with Cloud Computing service providers. This is mandatory when Restricted Information is involved.

1.     Purpose

The purpose of this policy is to provide guidance on when digital signatures are considered accepted means of validating the identity of a signer in XXX electronic documents and correspondence, and thus a substitute for traditional “wet” signatures, within the organization.  Because communication has become primarily electronic, the goal is to reduce confusion about when a digital signature is trusted.

2.     Scope

This policy applies to all XXX employees and affiliates. This policy applies to all XXX employees, contractors, and other agents conducting XXX business with a XXX-provided digital key pair.  This policy applies only to intra-organization digitally signed documents and correspondence and not to electronic materials sent to or received from non-XXX affiliated persons or organizations.

3.     Policy

A digital signature is an acceptable substitute for a wet signature on any intra-organization document or correspondence, with the exception of those noted on the site of the Chief Financial Officer (CFO) on the organization’s intranet:  <CFO’s Office URL>

The CFO’s office will maintain an organization-wide list of the types of documents and correspondence that are not covered by this policy.

Digital signatures must apply to individuals only.  Digital signatures for roles, positions, or titles (e.g. the CFO) are not considered valid.

Responsibilities

Digital signature acceptance requires specific action on both the part of the employee signing the document or correspondence (hereafter the signer), and the employee receiving/reading the document or correspondence (hereafter the recipient).

1. Signer Responsibilities

• Signers must obtain a signing key pair from CEO/CFO.  
• This key pair will be generated using XXX’s Public Key Infrastructure (PKI) and the public key will be signed by the XXX’s Certificate Authority (CA),
• Signers must sign documents and correspondence using software approved by XXX IT organization.Signers must protect their private key and keep it secret.
• If a signer believes that the signer’s private key was stolen or otherwise compromised, the signer must contact XXX Identity Management Group immediately to have the signer’s digital key pair revoked.

2. Recipient Responsibilities

• Recipients must read documents and correspondence using software approved by XXX IT department.
• Recipients must verify that the signer’s public key was signed by the XXX’s Certificate Authority (CA), by viewing the details about the signed key using the software they are using to read the document or correspondence.
• If the signer’s digital signature does not appear valid, the recipient must not trust the source of the document or correspondence.
• If a recipient believes that a digital signature has been abused, the recipient must report the recipient’s concern to XXX Identity Management Group.

4.     Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2  Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3  Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Purpose

To define security requirements for user identification and authentication controls required to safeguard access to XXX’s information and information systems.

Scope

This procedure applies to all XXX users who access the organization’s systems, applications, services, and technology resources. All users are responsible for adhering to this policy. If needed or appropriate, information regarding roles, responsibilities, management commitment, and coordination among organizational entities are embedded within these
procedures.

Responsibilities:

Chief Information Security Officer (CISO):

The CISO is responsible for, but not limited to the following activities:

• Revisions, implementation, workforce education, interpretation, and enforcement of this procedure.
• Ensuring system passwords are changed whenever there is a security incident that indicates a password compromise.

System/Application Administrators:

System/application administrators are responsible for, but not limited to the following activities:

• Configuring systems or implementing technical controls that comply with the requirements of this procedure.
• Maintain a list of commonly used and compromised (or expected of) passwords, and review and updates the list at least every 180 days. Implement a system that checks for and rejects the use of these passwords by users.
• Configuring the password management system to allow for long passwords and passphrases, including spaces and all printable characters.
• Configuring the password management system to assist workforce members in selecting strong passwords and authenticators.
• Ensuring default passwords across all organizational systems are changed.

General Requirements:

Access to covered information will be traceable to an individual using a unique user identification (userID) code. The use of generic, shared, or group userIDs, and passwords, or any other type of access that could lead to actions being performed that would not require individual authentication or identification is prohibited. These requirements apply to ANY user with access to XXX’s information systems including non-organizational user such as customers, clients, and/or contractors. Certain types of user support transactions, like resetting passwords, whether by the Help Desk, system administrator, or self-provisioning tool, will require positive verification of the requestor’s identity. Positive verification can be accomplished through one of the following:

• In person, face-to-face verification.
• Responding correctly to “secret” questions that the requestor previously provided the answers to. The questions are used by the Help Desk or a self-provisioning tool to verify the requestor’s identity if face-to-face verification is not possible or feasible. At least two questions will be asked by the Help Desk or the self-provisioning tool before providing the requestor with a temporary password.
• Cell phone verification: Technology used to send a one-time temporary code to a predefined cell phone number. The code is used to gain access to a screen where the requester is prompted to create a new password. used to send a one-time temporary code to a predefined cell phone number. The code is used to gain access to a screen where the requester is prompted to create a new password.
• Workforce members are required to send acknowledgement whenever a password is successfully received or reset to confirm the information was sent to the correct user and the account has not been compromised.
  

Authentication Requirements:

Authentication requirements defined by this procedure will be required in all information technology (e.g., workstations, laptops, mobile devices, servers, routers, etc.) configuration standards. If application specific identification and authentication controls are needed those will be defined in a separate standard. Information technology password configuration requirements are as follows:

• Passwords will be (8) eight characters in length.
• Passwords will be comprised of at least three of the following: uppercase alpha character; lowercase alpha character; numeric character; and special character (i.e., !, @, #, $, %, &, *, ?).
• Passwords will not be the same as a user’s ID/logon.
• Passwords will not be included in automated log-on processes.

For all initial, first-time, log-on’s or under any circumstance that requires a user to change their password (e.g., account recovery), users will be provided a secure (i.e., not guessable) temporary password to use to login. Upon login, the user will be immediately prompted (i.e., forced) to change the temporary password to something only they know that meets the previously mentioned composition requirements. Temporary/default passwords will:

• Be one time use only
• Follow same composition rules as regular passwords

Electronic Signatures:

Electronic signatures used in conjunction with passwords for the purposes of authentication and system access will be protected by ensuring the following:

• The organization requires that electronic signatures are unique to one individual and cannot be reused by, or reassigned to, anyone else. Workforce members will be held accountable to all actions initiated under their electronic signatures.
• Identity verification of the individual is required prior to establishing, assigning, or certifying an individual’s electronic signature or any element of such signature.
• Electronic signatures based upon bio metrics are designed to ensure that they cannot be used by any individual other than their genuine owners.
• Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records.
• Signed electronic records shall contain information associated with the signing in human readable format.
• If relevant, ensure that all legal considerations related to the use of electronic signatures are addressed.
• For any electronic signatures that are not based upon bio metrics, these instances shall employ at least two distinct identification components that can be administered and evaluated for authorized authentication.
  

Documentation Retention:

Documentation of compliance assessments will be retained for a period of no less than 6 years from the date of the assessment.

Applicability:

All employees, volunteers, trainees, consultants, contractors, and other persons (i.e., workforce) whose conduct, in the performance of work for XXX, is under the direct control of XXX, whether or not they are compensated by XXXX.

Compliance:

Workforce members are required to comply with all information security policies/procedures as a condition of employment/contract with XXX. Workforce members who fail to abide by requirements outlined in information security policies/procedures are subject to disciplinary action up to and including termination of employment/contract.

The following checklist can be used for both internal audits as well as Gap Analysis tools.

Annex A Information security controls

A 5 Organizational controls

Clause	Control	Is the control applicable ? If yes how it it applied and is it effective
5.1 Policies for information security	Information security policy and topic-specific policies shall be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.
5.2 Information security roles and responsibilities	Information security roles and responsibilities shall be defined and allocated according to the organization needs.
5.3 Segregation of duties	Conflicting duties and conflicting areas of responsibility shall be segregated.
5.4 Management responsibilities	Management shall require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization.
5.5 Contact with authorities	The organization shall establish and maintain contact with relevant authorities.
5.6 Contact with special interest groups	The organization shall establish and maintain contact with special interest groups or other specialist security forums and professional associations.
5.7 Threat intelligence	Information relating to information security threats shall be collected and analysed to produce threat intelligence.
5.8 Information security in project management	Information security shall be integrated into project management.
5.9 Inventory of information and other associated assets	An inventory of information and other associated assets, including owners, shall be developed and maintained.
5.10 Acceptable use of information and other associated assets	Rules for the acceptable use and procedures for handling information and other associated assets shall be identified, documented and implemented.
5.11 Return of assets	Personnel and other interested parties as appropriate shall return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement.
5.12 Classification of information	Information shall be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.
5.13 Labeling of information	An appropriate set of procedures for information labeling shall be developed and implemented in accordance with the information classification scheme adopted by the organization.
5.14 Information transfer	Information transfer rules, procedures, or agreements shall be in place for all types of transfer facilities within the organization and between the organization and other parties.
5.15 Access control	Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements.
5.16 Identity management	The full life cycle of identities shall be managed.
5.17 Authentication information	Allocation and management of authentication information shall be controlled by a management process, including advising personnel on appropriate handling of authentication information.
5.18 Access rights	Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.
5.19 Information security in supplier relationships	Processes and procedures shall be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.
5.20 Addressing information security within supplier agreements	Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.
5.21 Managing information security in the information and communication technology (ICT) supply chain	Processes and procedures shall be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.
5.22 Monitoring, review and change management of supplier services	The organization shall regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
5.23 Information security for use of cloud services	Processes for acquisition, use, management and exit from cloud services shall be established in accordance with the organization’s information security requirements.
5.24 Information security incident management planning and preparation	The organization shall plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
5.25 Assessment and decision on information security events	The organization shall assess information security events and decide if they are to be categorized as information security incidents.
5.26 Response to information security incidents	Information security incidents shall be responded to in accordance with the documented procedures.
5.27 Learning from information security incidents	Knowledge gained from information security incidents shall be used to strengthen and improve the information security controls.
5.28 Collection of evidence	The organization shall establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events.
5.29 Information security during disruption	The organization shall plan how to maintain information security at an appropriate level during disruption.
5.30 ICT readiness for business continuity	ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.
5.31 Legal, statutory, regulatory and contractual requirements	Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements shall be identified, documented and kept up to date.
5.32 Intellectual property rights	The organization shall implement appropriate procedures to protect intellectual property rights.
5.33 Protection of records	Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release.
5.34 Privacy and protection of personal identifiable information (PII)	The organization shall identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements.
5.35 Independent review of information security	The organization’s approach to managing information security and its implementation including people, processes and technologies shall be reviewed independently at planned intervals, or when significant changes occur.
5.36 Compliance with policies, rules and standards for information security	Compliance with the organization’s information security policy, topic-specific policies, rules and standards shall be regularly reviewed.
5.37 Documented operating procedures	Operating procedures for information processing facilities shall be documented and made available to personnel who need them.

A 6 People controls

Clause	Control	Is the control applicable ? If yes how it it applied and is it effective
6.1 Screening	Background verification checks on all candidates to become personnel shall be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks.
6.2 Terms and conditions of employment	The employment contractual agreements shall state the personnel’s and the organization’s responsibilities for information security.
6.3 Information security awareness, education and training	Personnel of the organization and relevant interested parties shall receive appropriate information security awareness, education and training and regular updates of the organization’s information security policy, topic-specific policies and procedures, as relevant for their job function.
6.4 Disciplinary process	A disciplinary process shall be formalized and communicated to take actions against personnel and other relevant interested parties who have committed an information security policy violation.
6.5 Responsibilities after termination or change of employment	Information security responsibilities and duties that remain valid after termination or change of employment shall be defined, enforced and communicated to relevant personnel and other interested parties.
6.6 Confidentiality or non-disclosure agreements	Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information shall be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.
6.7 Remote working	Security measures shall be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization’s premises.
6.8 Information security event reporting	The organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

A 7 Physical controls

Clause	Control	Is the control applicable ? If yes how it it applied and is it effective
7.1 Physical security perimeters	Security perimeters shall be defined and used to protect areas that contain information and other associated assets.
7.2 Physical entry	Secure areas shall be protected by appropriate entry controls and access points.
7.3 Securing offices, rooms and facilities	Physical security for offices, rooms and facilities shall be designed and implemented.
7.4 Physical security monitoring	Premises shall be continuously monitored for unauthorized physical access.
7.5 Protecting against physical and environmental threats	Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure shall be designed and implemented.
7.6 Working in secure areas	Security measures for working in secure areas shall be designed and implemented.
7.7 Clear desk and clear screen	Clear desk rules for papers and removable storage media and clear screen rules for information processing facilities shall be defined and appropriately enforced.
7.8 Equipment siting and protection	Equipment shall be sited securely and protected.
7.9 Security of assets off-premises	Off-site assets shall be protected.
7.10 Storage media	Storage media shall be managed through their life cycle of acquisition, use, transportation and disposal in accordance with the organization’s classification scheme and handling requirements.
7.11 Supporting utilities	Information processing facilities shall be protected from power failures and other disruptions caused by failures in supporting utilities.
7.12 Cabling security	Cables carrying power, data or supporting information services shall be protected from interception, interference or damage.
7.13 Equipment maintenance	Equipment shall be maintained correctly to ensure availability, integrity and confidentiality of information.
7.14 Secure disposal or re-use of equipment	Items of equipment containing storage media shall be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.

A 8 Technological controls

Clause	Control	Is the control applicable ? If yes how it it applied and is it effective
8.1 User end point devices	Information stored on, processed by or accessible via user end point devices shall be protected.
8.2 Privileged access rights	The allocation and use of privileged access rights shall be restricted and managed.
8.3 Information access restriction	Access to information and other associated assets shall be restricted in accordance with the established topic-specific policy on access control.
8.4 Access to source code	Read and write access to source code, development tools and software libraries shall be appropriately managed.
8.5 Secure authentication	Secure authentication technologies and procedures shall be implemented based on information access restrictions and the topic-specific policy on access control.
8.6 Capacity management	The use of resources shall be monitored and adjusted in line with current and expected capacity requirements.
8.7 Protection against malware	Protection against malware shall be implemented and supported by appropriate user awareness.
8.8 Management of technical vulnerabilities	Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
8.9 Configuration management	Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored and reviewed.
8.10 Information deletion	Information stored in information systems, devices or in any other storage media shall be deleted when no longer required.
8.11 Data masking	Data masking shall be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.
8.12 Data leakage prevention	Data leakage prevention measures shall be applied to systems, networks and any other devices that process, store or transmit sensitive information.
8.13 Information backup	Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.
8.14 Redundancy of information processing facilities	Information processing facilities shall be implemented with redundancy sufficient to meet availability requirements.
8.15 Logging	Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.
8.16 Monitoring activities	Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential infor- mation security incidents.
8.17 Clock synchronization	The clocks of information processing systems used by the organization shall be synchronized to approved time sources.
8.18 Use of privileged utility programs	The use of utility programs that can be capable of overriding system and application controls shall be restricted and tightly controlled.
8.19 Installation of software on operational systems	Procedures and measures shall be implemented to securely manage software installation on operational systems.
8.20 Networks security	Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.
8.21 Security of network services	Security mechanisms, service levels and service requirements of network services shall be identified, implemented and monitored.
8.22 Segregation of networks	Groups of information services, users and information systems shall be segregated in the organization’s networks.
8.23 Web filtering	Access to external websites shall be managed to reduce exposure to malicious content.
8.24 Use of cryptography	Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented.
8.25 Secure development life cycle	Rules for the secure development of software and systems shall be established and applied.
8.26 Application security requirements	Information security requirements shall be identified, specified and approved when developing or acquiring applications.
8.27 Secure system architecture and engineering principles	Principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.
8.28 Secure coding	Secure coding principles shall be applied to software development.
8.29 Security testing in development and acceptance .	Security testing processes shall be defined and implemented in the development life cycle
8.30 Outsourced development	The organization shall direct, monitor and review the activities related to outsourced system development.
8.31 Separation of development, test and production environments	Development, testing and production environments shall be separated and secured.
8.32 Change management	Changes to information processing facilities and information systems shall be subject to change management procedures.
8.33 Test information	Test information shall be appropriately selected, protected and managed.
8.34 Protection of information systems during audit testing	Audit tests and other assurance activities involving assessment of op- erational systems shall be planned and agreed between the tester and appropriate management.

Purpose

The purpose of this policy is to provide a minimum baseline standard for connecting Bluetooth enabled devices to the XXX network or XXX owned devices. The intent of the minimum standard is to ensure sufficient protection Personally Identifiable Information (PII) and confidential XXX data.

Scope

This policy applies to any Bluetooth enabled device that is connected to XXX network or owned devices.

Policy

Insecure Bluetooth connections can introduce a number of potential serious security issues. Hence, there is a need for a minimum standard for connecting Bluetooth enable devices.

3.1 Version

No Bluetooth Device shall be deployed on XXX equipment that does not meet a minimum of Bluetooth v2.1 specifications without written authorization from the IT Team. Any Bluetooth equipment purchased prior to this policy must comply with all parts of this policy except the Bluetooth version specifications.

3.2 Pins and Pairing
When pairing your Bluetooth unit to your Bluetooth enabled equipment (i.e. phone, laptop, etc.), ensure that you are not in a public area where you PIN can be compromised. If your Bluetooth enabled equipment asks for you to enter your pin after you have initially paired it, you must refuse the pairing request and report it to IT, through your Help Desk, immediately.

3.3 Device Security Settings

• All Bluetooth devices shall employ ‘security mode 3’ which encrypts traffic in both directions, between your Bluetooth Device and its paired equipment.
• Use a minimum PIN length of 8. A longer PIN provides more security.
• Switch the Bluetooth device to use the hidden mode (non-discoverable)
• Only activate Bluetooth only when it is needed.
• Ensure device firmware is up-to-date.

3.4 Security Audits

The IT Team may perform random audits to ensure compliancy with this policy. In the process of performing such audits, IT Team members shall not eavesdrop on any phone conversation.

3.5 Unauthorized Use

The following is a list of unauthorized uses of XXX-owned Bluetooth devices:

• Eavesdropping, device ID spoofing, DoS attacks, or any form of attacking other Bluetooth enabled devices.
• Using XXX-owned Bluetooth equipment on non-XXX-owned Bluetooth enabled devices.
• Unauthorized modification of Bluetooth devices for any purpose.

3.6 User Responsibilities

• It is the Bluetooth user’s responsibility to comply with this policy.
• Bluetooth mode must be turned off when not in use.
• PII and/or XXX Confidential or Sensitive data must not be transmitted or stored on Bluetooth enabled devices.
• Bluetooth users must only access XXX information systems using approved Bluetooth device hardware, software, solutions, and connections.
• Bluetooth device hardware, software, solutions, and connections that do not meet the standards of this policy shall not be authorized for deployment.
• Bluetooth users must act appropriately to protect information, network access, passwords, cryptographic keys, and Bluetooth equipment.
• Bluetooth users are required to report any misuse, loss, or theft of Bluetooth devices or systems immediately to IT.

4. Policy Compliance

4.1 Compliance Measurement
The IT Team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the IT Team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

1 Purpose

This procedure is intended to ensure that:

• the organization continually operates in accordance with the specified policies, procedures and external requirements in meeting company goals and objectives in relation to information security.
• improvements to the Information Security Management System (ISMS) are identified, implemented and suitable to achieve objectives.

2 Scope

This procedure:

• includes planning, execution, reporting and follow–up of ISMS internal audits; and
• applies to all departments/business units within scope of the organization’s ISMS.

3 Roles and responsibilities

3.1 Information Security Management Representative (ISMR)

• Appoints the Lead Auditor and the Audit Team (note: the Lead Auditor and ISMR may be the same person).
• Together with the Lead Auditor, reviews the corrective and preventive actions and the follow-up.
• Maintains confidentiality of the audit evidence, analysis and findings/results.

3.2 Lead Auditor

• Prepares an Audit Plan/Notification as a basis for planning the audit and for disseminating information about the audit.
• Leads the ISMS internal audit activities.
• Co-ordinates the audit schedule with concerned department/section heads.
• Plans the audit, prepares the working documents and briefs the audit team.
• Consolidates all audit findings and observations and prepares internal audit report.
• Reports critical non-conformities to the auditee immediately.
• Report to the auditee the audit results clearly and without delay.
• Conducts the opening and closing meeting.

3.3 Audit Team Member

• Supports the Lead Auditor’s activities (may be the same person).
• Performs the audit using the consolidated audit checklist.
• Reports any non-conformities and recommends suggestions for improvement.
• Retains the confidentiality of audit findings.
• Acts in an ethical manner at all times.

3.4 Auditee

▪ Receives, considers and discusses the audit report.
▪ Determines, resources, drives and completes corrective actions as necessary.
▪ Is and remains accountable for protecting information assets.

4 Procedure

4.1 General

4.1.1 An ISMS audit programme shall be created that contains all scheduled and potential audits for the whole calendar year. This shall include schedule of internal audits, audits of suppliers, audits to be performed by clients and third-party audits, asappropriate.
4.1.2 Internal audits shall be scheduled twice a year or as the need arises.
4.1.3 Only competent personnel who are truly independent of the subject area shall perform audits.
4.1.4 Members of the Internal Audit Team shall be appointed and supervised by the Lead Auditor.
4.1.5 Auditees are notified at least three working days in advance of the audit, ideally up to a month before giving them ample time to prepare.

4.2 Planning and Preparing the Audit

4.2.1 An annual ISMS internal audit programme shall be prepared by the Lead Auditor and approved by top management. It should be revised to reflect any changes in the priorities or schedule during the year.
4.2.2 Based on the audit programme, the Lead Auditor shall prepare the respective audit plans.
4.2.3 The Audit Plan/Notification shall be prepared by the Lead Auditor, reviewed and approved by the ISMR. It shall be communicated to the auditor/s and the auditees. It shall be designed to be flexible in order to permit changes based on the information gathered during the audit. The plan shall include:

• Audit objective and scope.
• Department/Section and responsible individuals in charge.
• Audit team members. The number of auditors depends on the audit area size.
• Management system/s to be audited (possibly more than one at once i.e. combined audits).
• Date, place and timescale for the audit fieldwork, planned distribution date of the audit report and some indication of the anticipated date of the clearance meeting.

4.3 Pre-audit meeting

4.3.1 One or more pre-audit meetings between the ISMR, Lead Auditor and auditors shall take place not later than one day prior to the audit proper. Objectives are as follows:

• To ensure the availability of all the resources needed and other logistics that may be required by the auditor.
• The scope of the audit is verified from the Audit Plan

4.4 Opening meeting

4.4.1 An opening meeting, where deemed appropriate by the ISMR and Lead Auditor, shall be held on the day of the audit but before the audit proper. The following may be discussed during the opening meeting:

• The purpose and scope of the audit.
• Confirmation of the audit plan
• Clarification of other matters must be settled before the audit takes place.

4.5 Audit Execution

4.5.1 The auditor/s will perform the ISMS internal audit using several checklists:

• ISMS Internal Audit Checklist/Observation Form: contains specific items that are particular to the organizational unit to be audited. The assigned auditors are responsible for generating the questions and checks on this form.
• Mandatory Requirements Checklist: describes checks relating to the mandatory requirements from the main body of the applicable version of ISO/IEC 27001.
• Discretionary Requirements Checklist: describes checks pertaining to the information security controls outlined in Annex A of ISO/IEC 27001. The organization chooses which – if any – of the Annex A controls are applicable i.e. are necessary to mitigate its unacceptable information risks.

4.5.2 Audit findings are collected through interviews, examination of documents and observation of activities and conditions in the areas of concern and noted on the checklists, referencing the supporting audit evidence (e.g. interview notes and ISMS documents reviewed).
4.5.3 Evidence suggesting other non-conformities should be noted if they seem significant, even though not covered by the checklist, along with other objective evidence and/or observations reflecting positively or negatively on the information security management system.

4.6 Audit Reporting

4.6.1 The auditor/s shall allow time for analysing, drafting and discussing the audit findings e.g.:

• Review and analysis of evidence leading to reportable findings.
• Consolidation of findings including grouping of related issues and tabulation.
• Classification/prioritization of findings according to their significance and/or urgency (see section 4.6.4).
• Drafting of audit report including recommendations.

4.6.2 The audit team shall review all of their findings whether they are to be reported as non-conformities or as observations. Essentially:

• Everything significant enough to be ‘reportable’ should indeed be reported; and
• Everything reported should be supported by sufficient objective evidence to withstand reasonable scrutiny.

4.6.3 The Lead Auditor typically consolidates everything into the audit report, or at least checks and challenges the content of a report drafted by the team.
4.6.4 Classification of findings shall be:

• Major non-conformity – a significant deficiency in the ISMS, typically a point of absolute non-conformity with one of the mandatory requirements in the main body of ISO/IEC 27001 (e.g. a missing required document or one that substantially fails to address the specified content) or a serious error in the identification, assessment or treatment of information risks (such as missing or ineffective ‘necessary’ controls). These are show-stoppers, preventing certification unless/until resolved.
• Minor non-conformity – a minor deficiency or technical non-conformity with a limited or indirect effect on information risk and security.
• Improvement potential – a suggested ISMS improvement which may or may not be adopted by the organization, perhaps with modifications, drawing on the auditor’s independent perspective and experience.
• Positive findings – something that goes beyond what is required by the standard, included for the sake of presenting a fair and balanced opinion that acknowledges good practice.

4.6.5 Both major and minor non-conformities require appropriate corrective actions to be documented using the corrective action policy/procedure within the ISMS (or, if absent, an equivalent process).
4.6.6 Improvement potentials concerning information security weaknesses require appropriate preventive actions to be documented, ideally entering the organization’s continual improvement process.
4.6.7 The Lead Auditor shall prepare a standard internal audit Report containing the following information:

• Audit Reference Number
• Date of Audit
• Department/Section Audited/Process Name
• Name of Auditee and auditors
• Statement of findings (all non-conformities found)
• Reference to the information security management system and standard
• Corrective and Preventive Actions with completion date
• Follow-up actions for non-conformities
• Verification of follow-up actions

4.6.8 Auditors shall follow a code of conduct in the manner of reporting as stated in this document:

• The report should be concise but factual and presented in a constructive manner.
• The findings should be within the scope of audit and shows the relationship of the standard used.
• The report should not show bias by the individual auditor.

4.6.9 The Lead Auditor shall issue a formal Audit Report to the ISMR (if the ISMR is not the Lead Auditor).
4.6.10 The internal audit report shall be maintained and controlled by the ISMR.

4.7 Clearance Meeting

4.7.1 The Lead Auditor shall preside over the clearance meeting attended by the audit team and auditees.
4.7.2 The auditor/s shall report the findings and observations, summarising the good points before discussing non-conformities supported by the audit evidence and (if applicable) recommendations and improvement opportunities to be considered.
4.7.3 All parties shall safeguard the confidentiality of the ISMS internal audit report.

5 Audit Follow-up and Closure

5.1.1 Whereas the auditors are responsible for identifying non-conformities, auditees are responsible for resolving non-conformities.
5.1.2 Approved corrective actions shall be based on time scales agreed with the auditors.
5.1.3 The Lead Auditor shall follow-up to check the implementation of corrective action as stated on the Non-conformity/Corrective and Preventive Action report or NCPAR. Normally, follow-ups will use an abbreviated form of this audit procedure to verify the completion and effectiveness of the agreed corrective or preventive actions according
to the agreed timescales.
5.1.4 The lead auditor shall issue a new NCPAR if corrective actions are not fully implemented by the committed date, and/or are not effective.
5.1.5 “Re-issue” shall be noted on the remarks column of the NCPAR log if any of the situations noted here become apparent.
5.1.6 An audit will not be considered complete and closed until all corrective actions or measures have been successfully implemented to the satisfaction of the Lead Auditor.

6 Auditors’ Qualifications

6.1 Personal attributes

6.1.1 Auditors shall possess the personal attributes, skills and competencies necessary to uphold the principles of auditing. An auditor should be:

• Ethical: fair, truthful, sincere, honest and discreet;
• Open-minded: willing to consider alternative ideas or points of view;
• Diplomatic: tactful in dealing with people, particularly those who are senior or over-committed;
• Observant and perceptive: actively aware of physical surroundings, activities, body-language, instinctively aware of and able to understand complex situations;
• Versatile: able to adjust readily to different situations;
• Tenacious: persistent, focused on achieving objectives;
• Decisive: reaches timely conclusions based on logical reasoning and analysis; and
• Self-reliant and self-motivated: acts and functions independently while interacting effectively with others.

6.2 General knowledge and skills of an ISMS auditor

6.2.1 Auditors should have knowledge and skills
6.2.2 Audit principles, procedures and techniques: to enable the auditor to apply those appropriate to different audits and ensure that audits are conducted consistently and systematically. An auditor should be able to:

• Apply audit principles, procedures and techniques;
• Plan and organize the work effectively;
• Conduct the audit within the agreed time schedule;
• Prioritize and focus on matters of significance;
• Collect information through effective interviewing, listening, observing and reviewing documents, records and data;
• Understand the appropriateness and consequences of using sampling techniques for auditing;
• Verify the accuracy of collected information;
• Confirm the sufficiency and appropriateness of audit evidence to support audit findings and conclusions;
• Assess those factors that can affect the reliability of the audit findings and conclusions;
• Use work documents to record audit activities;
• Prepare audit reports of suitable quality and professionalism;
• Maintain the confidentiality and security of information, and
• Communicate effectively, either through personal linguistic skills or through an interpreter.

6.2.3 Management system and reference documents: to enable the auditor to comprehend the scope of the audit and apply audit criteria. Knowledge and skills in this area should cover:

• Interaction between the parts of the management system;
• ISMS standards, applicable procedures or other documents used as audit criteria;
• Recognizing differences between and priority of the reference documents;
• Application of the reference documents to different audit situations, and
• Information systems and technology for, authorization, security, distribution and control of documents, data and records.

6.2.4 Organization/business context: to enable the auditor to comprehend the organization’s operational context. Knowledge and skills in this area should cover aspects such as:

• Organization size, structure, functions and relationships,
• General business processes and related terminology, and
• Cultural and social customs of the auditee.

6.2.5 Applicable laws, regulations and other obligations: to enable the auditor to work within, and be aware of, various obligations towards information security, privacy, governance and other requirements that apply to the organization being audited. Knowledge and skills in this area should cover relevant:

• Local, regional and national codes, laws and regulations;
• Contracts and agreements;
• International treaties and conventions; and
• Other compliance requirements such as applicable standards.

6.3 Lead Auditors’ Qualifications

6.3.1 Audit team leaders should have additional knowledge and skills in audit leadership to facilitate the efficient and effective conduct of the audit. An audit team leader should be able to:

• Plan the audit and make effective use of resources during the audit;
• Represent the audit team in communications with the audit client and auditee;
• Organize, direct and motive audit team members;
• Mentor and provide guidance to auditor team members;
• Lead the audit team to reach the audit conclusions;
• Prevent or resolve conflicts; and
• Prepare and complete the audit report.

6.4 Specific Knowledge and Skills of ISMS Auditors.

6.4.1 Information security management system auditors should have knowledge and skills in Information security-related methods and techniques. To enable the auditor to examine information security management systems and to generate appropriate audit findings and conclusions. Knowledge and skills in this area should cover

• Information security terminology and concepts;
• Information security management principles and their application; and
• Information security management tools and their application.

6.4.2 Processes and products, including services: to enable the auditor to comprehend the technological context in which the audit is being conducted. Knowledge and skills in this area should cover:

• Industry-specific terminology;
• Technical characteristics of processes and products, including services, and industry-specific processes and practices.

7 Records

7.1.1 As well as miscellaneous audit evidence (such as copies of documents, audit notes, records of interviews, system printouts etc.), ISMS internal audits generate the following formal records:

• Audit programme
• Audit plan/Notification
• Audit checklist/Observation sheet
• Mandatory requirements checklist
• Discretionary requirements checklist
• Internal audit report
• Nonconformity and corrective reports (if required)
• ISMS improvement suggestions (if appropriate)

7.1.2 All information shall be appropriately secured given its often confidential nature.
7.1.3 All information shall be properly filed and indexed, providing a starting point or background context for the next ISMS audit.

1.0 Purpose

The purpose of this policy is to set the requirements for proper facilitation and operation of the XXX threat intelligence program. The development of a threat intelligence program will support the continuous improvement of the overall network security, as well as offering the opportunity to engage in in-depth collection, analysis, and communication of IOCs while providing visibility into our immediate threat landscape to identify red flags before they turn into full-blown issues.

2.0 Scope

This Threat Intelligence Policy applies to all business processes and data, information systems and components, personnel, and physical areas of XXX.

3.0 Policy

The Threat Intelligence Program will adhere to the steps of Planning, Collection, Analysis, Communication, and Collaboration & Feedback.

3.1. Planning

1. The Threat Intelligence Program will be established and governed with roles and responsibilities.
2. The Threat Intelligence Team will combine the following responsibilities:
   • Malware analysis
   • Reverse-engineering
   • Forensics and eDiscovery
   • Management of threat intelligence
   • Intelligence gathering, analysis, and distribution of threat information
   • Threat assessment
   • Collaboration with all information security teams within the organization
3. A threat collaboration environment will be established to safeguard different aspects of the organization, while filling intelligence gaps of other roles.
4. The threat collaboration environment will be composed of teams including Threat Intelligence, Vulnerability Management, Incident Management, and Security.
5. An analytical methodology will be decided upon and adhered to, ensuring the organization to proactively mitigate advanced threats.

3.2. Collection:

a. A threat intelligence strategy will be established and maintained on a regular basis, at least annually.
b. Internal and external sources will be used for intelligence gathering. Sources must be relevant, timely, and reliable. These feeds will be analyzed daily for the most up-to-date, relevant intelligence gathering.
c. Industry-recommended standards for formatting and exchange of threat data will be used during collection. The fewest standards capable of providing the functionality needed will be used, including STIXX, TAXII, and openIOC .

3.3. Intelligence Analysis:

a. A formalized process for analysis must be established, educated, and updated.
b. A Threat Escalation Protocol (TEP) will be established for critical intelligence escalation procedures.
c. The Diamond Model will be used for carrying out threat analysis based on hypothesis generation and testing.
d. Threat analysis software may be used, subject to organizational vendor risk assessments and procurement procedures.
e. A threat intel portal or central knowledge base will be established and utilized.
f. Runbooks will be established, distributed, and followed to handle specific security incidents.

3.4. Collaboration & Feedback:

a. Alerts, briefings, and reports generated and distributed to relevant stakeholders regularly [indicate frequency, e.g.: daily alerts, weekly briefings, monthly reports.
b. An intelligence feedback loop will be established to ensure accurate and consistent threat intelligence.

Threat Intelligence Project Charter

Business Driver	Concerns/Motivations
Increased security	Limited visibility into the threat landscape means more solutions need to be put in place. Meet the operating needs of the organization in a secure manner:Safeguard data at rest, in transit, and in use across on-premise and hosted systems.Safeguard the confidentiality, integrity, and availability of the network, systems, and applications to the required levels by the business.There are no cookie-cutter solutions to threat intelligence– threat intelligence solutions offer other helpful security features to provide an all-cylinders-firing security tool.
In response to an incident	Organization suffered an incident where the network was breached. In order to strengthen its network security, a threat intelligence program is a necessary initiative to address gaps in defenses. Move from a reactive response model to a predictive model to identify risks before potential impact and threats before potential attack.
Replacement	Our previous threat intelligence program was not sufficient in preventing today’s attacks and needs to be reevaluated.
Risk management concerns	Our current threat intelligence program does not provide a formalized data collection, analysis, or collaboration process – all critical components to ensuring we maintain a risk management-focused environment.

Roles and Responsibilities

Individuals needed and responsible for threat intelligence may include the following:

• Chief Information Security Officer
• Senior management
• Security team staff
• Help desk
• Information owner
• Information systems staff
• Building and/or facilities management staff

Other individuals that may be needed include representation from:

• Public Affairs
• Legal/Compliance department
• Internal Audit/Risk Management
• Other workforce members involved in the incident or needed to fix/resolve it
• Contractors (as necessary)

Many of these roles will work together to form the threat collaboration environment. Organizations must look at the threat intelligence with a holistic mindset. Threat intelligence operates as a component of the larger threat collaboration environment and must be designed to complement existing security operations.

Project Team

Role	Name	Contact Information	Involvement
Project Sponsor			Full-time (Core), Part-time Involved at a singular stage
Project Manager
Information Sharing/Liaison Analyst
Security Operations Team
Incident Response Team
Vulnerability Management Team
Stakeholder/Vendor Management Analyst
Subject Matter Experts

Financial Obligations for a Threat Intelligence Implementation

Total Budget	$
Hardware
Software Licensing
Third-Party Software
Application Licensing
Documentation and Training
Annual Maintenance Costs
Etc.

Project Costs

Expense	Approved Budget	Actual Cost
Staffing
RFP Submission Costs
Consulting Costs

4.0 Policy Compliance

4.1 Compliance Measurement
The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.