Tired of endless scrolling? Let CareerBot help you find your dream job.

Try out CareerBot

Security Policy

Are you looking into CareerBot but wondering if you‘re even allowed to use it? Is CareerBot safe? Don‘t worry. Data security and infrastructure are an integral part of CareerBot technology. We’re committed to ensuring all necessary security precautions are taken and we comply with the leading standards, security certifications and penetration testing available.

If you‘re interested in our policies, definitely check out our Terms of Service and Privacy Policy. We strive hard to make those as human and readable as possible (while still keeping our lawyers happy). However, if it‘s compliance and security you‘re worried about, then you‘ve come to the right place.

1. Overview of Security Policy at CareerBot

It is a part of our company’s core values to value and protect any information entrusted to us about our customers. This policy describes how we will safeguard personal and company information, to ensure peace of mind when dealing with our company. It is our policy that:

  • CareerBot will collect only that information about customers which is needed and relevant.
  • We will not disclose information to other parties unless customers have been properly notified of such a disclosure.
  • We will strive to make certain that information about customers is kept accurate and up-to-date.
  • We will use appropriate controls to ensure that this information is kept secure, and is only viewed or used by the proper personnel.
  • We will comply with applicable laws, regulations, and industry standards when protecting employee information.
  • We hold our employees, vendors, contractors, suppliers, and trading partners to meet this same set of policies.

The purpose of this policy is to establish a protocol for creating and maintaining infrastructure and processes that will protect the security of our customers, and to create processes that will enable us to adequately assess potential risks, and respond to incidents or events that impact the security of CareerBot and its clients data or networks.

Confidentiality, Integrity and Availability (CIA)

Our policies for information security at CareerBot our guided by the CIA triad model. In this context, confidentiality is a set of rules that limits access to information, integrity is the assurance that the information is trustworthy and accurate, and availability is a guarantee of reliable access to the information by authorized people.

Our primary technical procedures for CIA compliance include:

  • HTTPS for transmission
  • disk encryption
  • subnets / VPC
  • bastion server(s)

In order to ensure confidentiality, we take a number of measures to ensure that access to sensitive data is restricted to individuals that have relevant training and authorisation to view the data in question, as well as taking measures to secure and protect data through encryption. Further details regarding CareerBot’s confidentiality policies can be found in the ‘Access & Authorization’ and ‘Data Encryption & Protection’ sections of this document.

In order to maintain data integrity, we maintain version, access and encryption controls that ensure that data is kept consistent and accurate at rest and in flight. Furthermore, we maintain backups of data to ensure that in a contingency event, affected data can be returned to its correct state.

In order to ensure data availability, our software and servers are architecture uses high-availability clusters, along with failover controls and adaptive disaster recovery, as detailed in the ‘Disaster Recovery’ section of this document. We take additional security measures to monitor and guard against downtime and unreachable data that can be caused by malicious actions such as denial-of-service attacks.

The CareerBot security model further addresses additional security considerations raised in the Parkerian Hexad model, by maintaining authenticity or non-repudiation of data through logging of data access, and ensuring adequate data possession through the access and authorization controls details under “Access & Authorization”

3. Access & Authorization

We manage user access and authorization through an authentication process that is is designed to confirm the identity of entities accessing the database. In this context, entities are defined as:

  • Users who need access to the database as part of their day-to-day business function
  • Administrators (i.e. sysadmins, DBAs, QA staff) and developers
  • Software systems including application servers, reporting tools, and management and backup suites
  • Physical and logical nodes that the database runs on. Databases can be distributed across multiple nodes both for scaling operations and for ensuring high availability in the event of systems failure or maintenance.

At CareerBot, secure access and authorization is managed through the following policies and practices:

Security Credentials - Separate login credentials for each entity that will need access to the database, and avoid creating a single “admin” login that every user shares.

Supporting In-Database and Centralized User Management - care is taken to ensure that only the minimal set of privileges is provided.

Control Access to Sensitive Data - Sensitive information, such as personally identifiable data, is restricted to users who have been given adequate training and appropriate security clearance.

4. Date Encryption and Protection

We use block level encryption to ensure that all CareerBot data is encrypted whenever it is in transit or at rest.

Our data encryption procedures ensure that only authorised entities are able read our data, and that our data will be protected in the event that eavesdroppers or hackers gain access to the server, network or database.

The protection and encryption of data stored by CareerBot for its users is ensured through the following guidelines and processes:

  • Encrypting Connections to the Database - All user or application access to the database is via encrypted channels including connections established through the drivers, command line or shell, as well as remote access sessions to the database servers themselves. Internal communications between database nodes are encrypted, i.e. traffic replicated between nodes of a database cluster.
  • Enforcing Strong Encryption. The database supports FIPS (Federal Information Processing Standard) 140-2 to ensure the implementation of secure encryption algorithms.
  • Encrypting Data at Rest. On-disk encryption is used to mitigate the threat to security that comes from attacks that bypass the database itself and target the underlying Operating System and physical storage of production servers or backup devices, in order to access raw data.

5. Physical Facility Records

All physical access to data centers by AWS employees is logged and audited routinely, as per the guidance and certification provided athttp://aws.amazon.com/security/

Further information about the AWS global infrastructure can be viewed here:https://aws.amazon.com/about-aws/global-infrastructure/. In addition to the physical infrastructure safeguards that are in place with AWS, the actual configuration of the platform architecture is monitored by the AWS Config service; this service reports on any configuration changes and provides a detailed audit trail of actions taken relating to the underlying system architecture. In addition any changes are sent via alerts to selected staff members to act upon.

6. Internal Reviews

CareerBot will conduct a periodic internal review at least once a year to evaluate our security program. This review is intended as a comprehensive risk assessment to identify all of the reasonably foreseeable internal and external threats to the security, confidentiality, and integrity of Personal Data.

We leverage data from AWS Trusted Advisor and use the Audity Security Checklist provided by AWS (https://d0.awsstatic.com/whitepapers/compliance/AWS_Auditing_Security_Checklist.pdf ) and where relevant, we will adjust our security programme in line with recommendations based on:

  • The results of the monitoring and testing
  • Changes in technology
  • Changes in internal or external threats facing your company
  • Environmental or operational changes
  • Material changes to your company’s business or arrangements, or any other circumstances that may have a material impact

7. Disaster Recovery


In the event of a disaster, we employ and leverage a number of resources and features to ensure business continuity. This enables to significantly minimize any potential impact on your data, our system, and our overall business operations. Backups can be recovered on any cluster on which they are taken.

CareerBot higher-level services, such as Amazon Simple Storage Service (S3), and Amazon Elastic Load Balancing (ELB), have been built with fault tolerance and high availability in mind. Services that provide basic infrastructure, such as Amazon Elastic Compute Cloud (EC2) and Amazon Elastic Block Store (EBS), provide specific features, such as availability zones, elastic IP addresses, and snapshots, that a fault-tolerant and highly available system must take advantage of and use correctly. For reference seehttp://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf

Hardware failovers and Node Recovery

The failover algorithms implemented by Amazon Route 53 are designed not only to route traffic to endpoints that are healthy, but also to help avoid making disaster scenarios worse due to misconfigured health checks and applications, endpoint overloads, and partition failures. The CareerBot clusters for Mongo and Deis will bring up new nodes in event of failed node.

RDS and Elasticache are multi AZ

Our application is distributed across multiple availability zones, which provides us the ability to remain resilient in the face of most failure modes, including natural disasters or system failures, such as by moving between availability zones in the event of a failed node.

Data Storage, Replication and recovery

The continuous copying of data from a database in order to maintain a second version of the database, usually for disaster recovery purposes.

CareerBot uses services and features that support data migration and durable storage, because they enable us to restore backed-up, critical data to secure cloud storage. The essential infrastructure pieces include DNS, networking features, and various Amazon Elastic Compute Cloud (Amazon EC2).

We leverage Simple Storage Service (Amazon S3) to provide a highly durable storage infrastructure designed for mission critical and primary data storage. Objects are redundantly stored on multiple devices across multiple facilities within a region, designed to provide a durability of 99.999999999% (11 9s). We provide further protection for data retention and archiving through versioning in Amazon S3, AWS multi-factor authentication (AWS MFA), bucket policies, and AWS Identity and Access Management (IAM)

  • Signing and Rotating Encryption Keys. Encryption keys for network and disk encryption are periodically rotated. SSL encryption channels use signed certificates to ensure that clients can certify the credentials they receive from server components.

8. Data Transmission

All data is transferred using the HTTPS protocol which provides end to end encryption. HTTPS uses the SSL/TLS protocol, which uses public-key cryptography to prevent eavesdropping, tampering, and forgery. We use a highly available and scalable DNS service and deliver content to our end users with low latency at high data transfer speeds with a content delivery web service.

Through Amazon Elastic Load Balancing access logs, we obtain information about each HTTP and TCP request processed by our load balancer. This includes the IP address and port of the requesting client, the backend IP address of the instance that processed the request, the size of the request and response, and the actual request line from the client (for example, GET http://www.example.com: 80/HTTP/1.1). All requests sent to the load balancer are logged, including requests that never made it to back-end instances.

9. Data Disposition / Decommissioning

When servers are decommissioned their associated disks are deleted (destroyed). Database disks are encrypted AWS Elastic Block Store volumes (EBS). Server disks are non-encrypted EBS volumes running Docker containers and as such never hold data.

When a storage device has reached the end of its useful life, our procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. We uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.

10. 3rd Party Services

Internal Controls

We have internal controls over data access and authorisation to ensure that vendors receive only data required to supply services and the data transfer process is secure

Selection and Contractual Requirements

Prior to selecting a 3rd party provider, CareerBot will specify CIA requirements for data as per the guidelines in the CIA section of this document

We will identify the control measures in place at the vendor that are designed to meet CIA requirements

We will assess whether the vendor is capable of meeting these selection requirements going forward, and will ensure that these are guaranteed by contractual requirements.


We will monitor the access control to and CareerBot data, and will maintain reviews for the configuration of our custom Identity and Access management (IAM) policy for the AWS keys that we use for any 3rd party service providers

Effective: 15th August 2016