TeamKinetic policy documents

Available Policies

Data Asset Protection and Resilience

last updated: 16 December 2020

Server Hosting and Data Location

All TeamKinetic servers and data is hosted in at least tier 2 data centers in the UK. A tier 2 data centre has an expected uptime of 99.982% (1.6 hours of downtime annually).

Data Centre Security

All data centres have at a minimum;

24 x 7 x 365 manned security and monitoring
24 hour on site Network Operations Centre (NOC)
Biometric access policies
Internal and external CCTV systems
Security breach alarms

All access is subject the following protocol;

All visitors must have a genuine reason to visit a site.
All visitors must provide us with at least 24 hour notice before coming onto site.
All visitors must have a valid form of photo identification.
All visitors must have the access code, which was generated for this visit.
Once they arrive, all visitors will only have access to the section of the site they require access to.
We retain the right to deny access to anyone who breaks any of the terms above.

Data centre security policies are regularly audited by a third party auditing company, as part of their security ISO certificates.

All data centres have at least ISO 9001 and 27001 certification. These certificates are recommended by the British government for hosting companies and guarantee that our site’s security, documentation, service standards and processes are all of a high standard, as expected of a data centre. ISO accreditations are held with the external auditing company ISOQAR.

Data Centre Interconnectivity

All our data centres must meet the following minimum data interconnectivity standards;

Diverse fibre routing via multiple carriers
Truncated internal cable network
ODF/DDF (Optical Distribution Frame/Digital Distribution Frame) bandwidth
Cross connection to a number of Tier 1 carriers
Internal inventory systems track all cables, circuits and cross-connects
Scalable architecture including multiple redundant core switches and routers

Data Centre Power and Environment

All our data centres must meet the following minimum power and environment conditions;

Dual independent power feeds, backed up by dual battery string Uninterrupted Power Supplies (UPS) systems (deployed as standard)
6 x 1.5 MW diesel generators – protect services from any single power failure
24 x 7 environmental monitoring systems
Constant evaluation and testing of all systems
N+1 redundant Heating Ventilation Air Conditioning (HVAC) system
Fully redundant air handling units provide constant fresh airflow
Leak detection

See https://www.rapidswitch.com/datacentres-and-colocation/maidenhead-data-centre/ for more details of the data centre.

Additionally Amazon AWS S3 storage is utilised to store both in application assets (profile images, opportunity documents etc) and backups of the database, web server, and virtual hosts.

The data center employs a strict physical access policy to the server hardware with manned 24/7 security, biometric access, internal and external CCTV, and security breach alarms.

As a tier 2 data center there are multiple redundancies and pathways for cooling, power, and data. Hardware firewalls and traffic analysis is employed to mitigate the potential for DdoS attacks and malicious attacks.

A minimum attack surface policy is employed for our servers. Only essential ports are opened and limited to IP where possible. Only a single administrative account is enabled and only the systems lead has administrative access to the server. All other access is limited to the scope and context of the user.

Minimize risk of loss - Data and Backup

Database transaction logs are backed up every 15 minutes and full database backups are taken once a day, encrypted by AES256. An offsite backup is created once a week. Virtual host guest OSes (including the web and database servers) are backed up daily using Veem, encrypted using AES256, and moved to offsite storage. All backups are kept for 30 days.

In the event of data loss due to error or mis-configuration the database can be rolled back to the suitable transactional data point and the data repaired. In the event of total failure or server crash a new instance can be brought online with a absolute maximum data loss of 24 hours.

Application code and content (uploads and other user data) is backed up in full each day to off-site storage. Centralised versioning software is used to maintain a full and complete backup of the application code and all changes.

Updates and changes are developed on the beta branch of the application code and fully tested before being merged into the release branch.

Our recovery time objective (RTO) is 2 hours.

Our recovery point objective (RPO) is 30 minutes for transactional database recovery and 24 hours for total server failure.

Decommissioning of Data and Data Carrying Hardware

We follow the procedure as laid out below to ensure data and data hardware is decommissioned without legacy data being left accessible. Not all milestones are always required but every step is completed

Initiate Decommissioning of the Service
1. Information Asset Manager submits decommission request to his/her Director including rationale for action
  1. Information Asset Manager verifies that proceeding with decommission planning is approved at ITS Director level
2. MILESTONE: Decommission Planning Approved

Formulate the Decommission Plan
1. Decommission Planning
  1. Decommission Project Manager is assigned by Information Asset Manager
  2. Because of the importance of a decommission decision, the Project Manager identifies and documents who is responsible for delegated portions of the process
  3. Identify and correlate the types of services and the types of users that use the service
  4. If alternatives are available, identify alternative services and develop a migration path to the alternative service(s)
  5. Develop a communication plan for each type of user and sub-service
  6. Project Manager sets target dates for the following 7 milestones and communicates them to the Service Manager:
    1. Plan Complete
    2. Decommission of Service Approved
    3. Service Offline – When setting this date consider the impact to your users. Users will not be able to access the service after this milestone.
    4. Point of No Return
    5. Service End – When setting this date consider SLAs, licenses, and warranties. The service is committed to these agreements until this milestone.
    6. Decommission Complete
    7. Data Removed
2. MILESTONE: Plan Complete – The plan to decommission the service is finished.

Get Final Approval
1. Decommission Approval
  1. Information Asset Manager submits decommission plan to all ITS Directors for review and approval
  2. Information Asset Manager verifies that ITS Directors' team approves decommissioning the service
2. MILESTONE: Decommission of Service Approved - Service decommission execution may proceed.

Offline the Service
1. Taking the Service Offline
  1. The Offline and End dates are most important and these dates must be communicated effectively to customers as well as throughout Information Technology Services.
    1. Notify ITS Accounting of the Service Offline and Service End dates
  2. Users can no longer access the system after the Service Offline date
    1. Enact communication plans to direct users to alternatives if required
    2. Remove access to the service being decommissioned
2. MILESTONE: Service Offline – The service is no longer available to users.

Prepare to Decommission
1. End of Service Preparation
  1. During this phase the service remains ready to redeploy if needed
  2. Resources are still allocated until the End Date
    1. Personnel
    2. Hardware
  3. Create an archive of the decommissioning target as it was on the Offline Date
    1. Include in this archive the data archives that existed under normal operations
    2. Comply with all data archival regulations
    3. Continue to honor existing archival plan after decommission
    4. Store the archive in a usable format
    5. Get rid of data unless it will be needed
    6. Verify the Data Removal date will be honored
  4. Document the service
    1. How to access the archive of the decommissioned service
    2. What this service relies on
      1. Vendors
      2. Hardware
    3. Who worked on the service
  5. Stop billing users
  6. Verify migration of any functions identified as still needed
  7. Notification of decommission – Examples of contacts that need decommission notification often include but are not limited to the following:
    1. Revoke Certificates (e.g. Code Signing, SSL Cert)
    2. Firewall Rules
    3. Service Accounts (e.g. LDAP Service Account, AD Service Account)
    4. Backup Services (e.g. CommVault)
    5. Automated Monitoring (e.g. Splunk)
    6. Security Scans and Web Application Firewall
    7. Asset Management (e.g. HAM entry)
    8. PCI Listing
    9. PII Listing
    10. Job Descriptions
    11. Removal from other systems’ whitelists
2. MILESTONE: Point of No Return – Preparations to decommission the service are complete.

End the Service
1. Service Ending
  1. Resources are deallocated
    1. Personnel become available for other assignments
    2. Decision is made to repurpose or retire hardware
  2. Stop paying vendor bills
  3. Finalize all accounts
    1. Final bill to customers
    2. Refund for unused service
2. MILESTONE: Service End – The service has ended although some cleanup tasks remain

Wrap up the Decommission
1. Decommission Completion
2. Send hard drives/data carrying hardware to the Systems team for disposal if required.
3. MILESTONE: Decommission Complete (Celebrate) – The decommission process is complete.

Post-Decommission
1. Data Removal
  1. Check data is removed from live systems
  2. Communicate archive end date to customer (the date at which archives containing decommissioned data will stop being retained)
  3. Post archive retention date check oldest archive to ensure data is not present
2. MILESTONE: Archived Data Removed – The final archive of the service is deleted