Information Security Policy Home

The ThingLogix Information security policy is approved by the ThingLogix management, published and communicated as appropriate to all employees.

The security policy document set details the high level security principles for the ThingLogix and establishes the framework under which each of the other sections of the security document set should be interpreted, managed and applied.

The overall purpose of this policy document is to provide both an overview of ThingLogix information security requirements and standards and reference documents which may be used to address specific queries on information security.

This security policy applies and will be available to all staff working in ThingLogix in whatever capacity. It is also relevant as evidence of good, recognised information security practices during internal or external audit processes. Relevant sections of the policy may also be used as a reference point in negotiating or agreeing contracts with external suppliers.

The standards and controls detailed within this policy document set the security goals within ThingLogix in line with the security strategy to achieve compliance with ISO27001 (Long term goal of ThingLogix). To this end the policy document details the aspiration of ThingLogix to comply with the standard it does not provide a summary of the current state of security controls in place at any given time.

The purpose of detailing some ISO27001 compliant controls in this policy document is to set the standards that ThingLogix aim to achieve and to provide the detail required and where applicable, 3^rd party suppliers to ensure that both existing and planned systems comply, or work incrementally towards compliance with ISO27001.

Policy / Procedure Statement

This policy has been developed for use across ThingLogix and complies with the requirements of widely recognised good information security practice. It will:

• Assist staff to apply the correct level of security control to their day to day activities in line with good practice and applicable regulation and legislation.
• Be formatted, controlled and distributed in line with ThingLogix requirements.
• Assist with the development and commissioning of new processes and systems by detailing the required security settings and standards.
• The policy will be available, as the correct up to date version, on the intranet to all staff.
• Any departments or staff who have a requirement to store or otherwise use hard copies of this policy should ensure that they frequently check that they have the latest version of the policy and refer any queries to the information security team. They should also ensure that any old, outdated versions of this document are destroyed and replaced as necessary.

Responsibilities

Information Security Manager (currently COO of ThingLogix)

For ensuring that this policy and the information risk policy is implemented, reviewed and its effect is monitored.

The Security Manager is responsible for the definition, implementation, monitoring and management of the Information Security Management and information security policy documents.

Chief Technology Officer (CTO)

The CTO is responsible for ensuring these policies and procedures are specifically implemented within our Foundry product, and will coordinate with our delivery teams for any customizations required for customer deployment.

Executive Team

The Executive Team at ThingLogix is responsible for both approving these policies and procedures, but also for ensuring adherence and execution within their company spans of control in the departments or geography where they operate.

Staff

All staff will adhere to this policy and associated procedures. They will raise any issues of non- compliance, information risk or incidents with either their line manager or directly with the security team.

Overview of this document

This section of the Security Policy statement introduces the set of documents that collectively make up the Security Policy that governs the operations. This section defines the general principles of the Security Policy, and establishes the framework under which each of the other Security Policy documents must be interpreted, approved, communicated, and managed. There is also a description of the most important roles and responsibilities for information governance within the organization

Other legislation and policies referred to

• ISO27001:2005 / ISO/IEC17799:2000. Information Technology – Information security management systems requirements.
• ISO27002:2005. Code of practice for information security management systems.
• ISO27005:2008. Information Security Risk Management.

General principles

The importance of information security

1. Information can be defined as useful data for a particular analysis, decision or task. Information must always be protected appropriately irrespective of how it is stored, presented or communicated.
2. The main aims of information security are to preserve:
   • Confidentiality: ensuring that information is accessible only to those who are authorised to have access.
   • Integrity: safeguarding the accuracy and completeness of information and processing methods.
   • Availability: ensuring that authorised users have access to information when needed.

It also aims to support the requirements of:

• Accountability: accounting for the actions of individuals by monitoring their activities.
• Non-Repudiation: legally acceptable assurance that transmitted information has been issued from and received by the correct, appropriately authorised, individuals.

ThingLogix has a responsibility to securely manage its information assets, the information made available to it by providers, and the people who use providers’ services, as well as that provided by its own employees, contractors, and business partners, and to protect that information from unauthorised disclosure, loss of integrity or availability. ThingLogix also has the responsibility to ensure products and deliverables for customers are securely managed and built to allow adequate customer configuration and management of security options to secure their data being processed using the ThingLogix products and deliverables. However, Customer are ultimately responsible for the security of their AWS environments onto which all ThingLogix Foundry deployments are delivered. This is because Customers own their AWS environments and can, and should, remove ThingLogix user access after successful transition and turnover from ThingLogix delivery teams.

All parts of the organisation are responsible for making sure that information is protected adequately. The Executive Team is responsible for issuing and endorsing this Security Policy. They recognise the sensitive nature of the information that the organisation stores and processes, and the serious potential harm that could be caused by security incidents affecting this information. They will therefore give the highest priority to information security. This will mean that security matters will be considered as a high priority in making any business decisions. This will help ThingLogix to allocate sufficient human, technical and financial resources to information security management, and to take appropriate action in response to all violations of Security Policy.

1. ThingLogix will use this Security Policy as the basis for an organisation-wide strategy to set the correct level of information security.
2. The security efforts will be:
   • Coordinated: security measures will be based on a common framework provided by the Security Policy, and all staff will be involved in maintaining compliance with the security policy.
   • Proactive: we will detect, identify and manage vulnerabilities, threats, and security gaps to prevent security incidents as far as we possibly can.
   • Supported at the highest level: senior management are actively committed to information security and give their full support to implementing the required security controls that are identified through a continuous risk assessment process.
   • These security efforts will be structured and directed by the Security Policy, which covers all aspects of information security within Thinglogix business operations.

Purpose of the Security Policy

1. This Security Policy comprises a set of decisions endorsed by the Executive Team about how ThingLogix will address its obligations relating to information security and data protection. The policy will also address actual or potential security issues relating to the information assets that ThingLogix either owns or handles on behalf of other parties.
2. The Security Policy serves several purposes, it:
3. Clearly defines management’s expectations, so that requirements can be applied uniformly.

• Represents a framework that provides direction to ThingLogix, so that resources are allocated efficiently.
• Acts as a measure against which compliance requirements can be validated.
• Enables the requirements of the policy and the consequences of non-compliance to be communicated.
• Assigns responsibilities and highlights the strategic value of information security
• throughout the organisation, and to relevant third parties.

Scope of the Security Policy

1. For the purpose of the Security Policy, “ThingLogix Services” are those services provided in relation to the core business of the organisation.
2. The scope of the Security Policy is defined across three dimensions:
   • The people who are subject to the Policy and who need to comply with it.
   • The assets that are covered by the Policy and subject to its protection.
   • The regulatory and legislative obligations and requirements that the policy covers.

People

The Security Policy applies to all ThingLogix staff, directly or indirectly managed, who are involved with supporting the delivery of regulatory and associated activities, including:

• Permanent employees of ThingLogix or an affiliate organisation.
• Individuals contracted by ThingLogix either directly or through employment agencies.
• Staff of sub-contractors of ThingLogix.
• Any other individuals with authorised access to ThingLogix information assets or
• information processing facilities.

ThingLogix Users

• The term ‘ThingLogix users’ denotes all staff within the organisation, including those not directly employed by ThingLogix but with access to the organisation’s systems and information assets. Information security requirements will be communicated to these staff and will be included in all third party contracts.

Assets

1. The Security Policy applies to all premises, physical equipment, software and data owned or managed by ThingLogix, directly or indirectly through sub-contractors, to deliver services. This scope particularly includes the data relating to authorised ThingLogix users and providers that is stored or processed.
2. Some computing facilities, such as the end-user client desktops with third party contractors, are outside the direct management control of ThingLogix. However, where they are used to process ThingLogix data they still fall within the scope of this Security Policy. The security requirements are included within the relevant contract with the contractor.

4.5 Types of security documents

The whole Security Policy comprises the set of documents listed in Security Policy Documents section. There are a number of other documents that support the Security Policy and provide more detailed guidance on aspects of the Policy for specific audiences and communication purposes. There are four categories of security documents of particular importance.

4.5.1 Policies

A policy consists of high-level, mandatory statements that provide direction as to what must be done. A policy does not address the details of how something should be done. Policies are largely technology-independent, and sufficiently generic that they need do not need to be updated often. Typically, a policy will have a number of supporting standards, which provide detail that would be inappropriate in a policy. For example, a policy might require that all servers be hardened. In this case, a hardening standard could be written for each type of server, providing configuration requirements specific to the server’s technology that will change more frequently than the underlying policy.

4.5.2 Standards

A standard contains lower-level mandatory statements that also address what must be done. Standards may be technology-independent (for example, a data classification standard), or technology-specific (for example, cryptology standards for various AWS services). In many cases, standards are tiered. A baseline standard provides the minimum requirements for a particular component or area (for example, DynamoDB server baseline hardening standard). Additional standards may be written that are more stringent variations of the baseline (for example, RDS hardening standard for use with systems deployed in a customer AWS environment containing sensitive or PII information).

4.5.3 Procedures

Some standards, such as hardening standards, are difficult to implement because of the large number of configuration settings that require deep knowledge of a particular system. In such cases, procedures may be developed to provide the detailed requirements. Procedures may be automated, reducing the time and resources required to perform a mandatory task, as well as ensuring more accurate application of the task. Procedures are also produced for non-technical requirements, such as incident reporting.

Guidelines

Guidelines are recommendations on good practice that either do not require to be mandated in the Security Policy, fall outside the scope of the Security Policy or provide ‘user friendly’ interpretation of the policies, standards and procedures.

Structure of policy documents

The security policy documentation set consists of sections mapped to the controls objectives.

Environments

For the purposes of applying the security policy, all the information processing environments within ThingLogix will be regarded as a single environment that is subject to the application of all security requirements contained within the policy documents. Where any potential exceptions to this are identified, they should be documented and notified to the Information Security manager.

Review and evaluation

Approval

The Security Policy document must undergo a two-step process before being approved and published. This involves:

• Internal review and approval: the security policy must be reviewed and approved by the Information Security Manager and the Executive Team. The policy will then be added to this Wiki.
• Once published to this Wiki, the Policy will be adopted immediately. The policy will then be communicated to all staff by notification of the new/updated publishing on the Wiki intranet, and compliance with the policies will then be mandated at ThingLogix. Acceptable notifications to staff include email, slack, or the regularly scheduled all-hands conference call.

Review

The Security Policy will be reviewed regularly and amended as necessary each time there are new threats, amendments to security-related good practice, or major changes to ThingLogix infrastructure, services or organisational structure. This continuous review process will be risk-driven and carried out in accordance with ISO27001:2005.

Communication and training

The Security Policy will be properly communicated to all people within its scope to ensure that all are aware of them. This will involve a combination of different communication channels, including:

• Security induction training.
• Email notification.
• Intranet-based security reminders.
• Mandatory security training packages applicable to all staff.

As well as employees, this will also include third party suppliers and ThingLogix will ensure that all relevant contracts include the compliance requirements from this information security policy.

There will be specific standards and instructions about more specific information security requirements. These will be distributed directly to individuals to be acknowledged by signature, for example, confidentiality and non-disclosure agreements.

Managing exceptions

To accommodate new requirements or handle temporary operational issues, ThingLogix may grant waivers covering variance from or non-compliance with the Security Policy. Granting a waiver from a policy requirement can only be authorised by the Information Security Manager, who will seek approval from the Executive Team where necessary.

Waivers will only be granted where a fully justified business need can be identified. A waiver may be granted retrospectively where an emergency situation has arisen involving an actual or potential loss of service.

The waiver categories are:

• Technical maintenance involving ThingLogix information assets only. These need to be approved by the Information Security Manager, or a member of the Executive Team (if the Security Manager is not available).
• Any waiver affecting the processing of personal identifiable data will need to be approved by the Executive Team.

For each waiver request, the Information Security Manager will decide which category applies. Any request must specify a minimum of:

• The assets involved
• The policy statements or requirements involved
• The details of and justification for the non-compliance
• The period of time during which the exception should apply
• The details of the actions planned to remove the non-compliance
• The people affected by the exception.
• At the end of the waiver period, the Information Security Manager will ensure that compliance is reinstated, and will report this to the Executive Team.

Consequences of policy violations

An internal investigation will be set up to examine the detail of any serious untoward security incidents, and will take any necessary actions including invoking disciplinary procedures where appropriate.

Where subcontractor staff have been found to have committed a security breach or policy violation, the subcontractor may be asked to bar the responsible individual from working for ThingLogix. In certain circumstances, the contract may be terminated.

Any person within the scope of the Security Policy can be held responsible for a violation where the violation is malicious or as a result of negligence.

Ignorance of policy requirements will not be accepted as mitigation for a security violation.