Security in the first place
New GDPR-compliant personal data protection
We are always ready for changes in legislation, and that includes the new General Data Protection Regulation (GDPR). So how are we going to help you ease into the GDPR and how will it affect your work in Teamio?
Tech Specs & Security
Teamio is a fully modular, multi-tenant web-based recruitment workflow management solution.
It facilitates effective info sharing between companies and job seekers. Helps to maintain a recruitment process. Looks for candidates who fit the needs, issues job positions, keeps communication history with involved job applicants, manages job tenders and interviews. And much more. Of course in compliance with EU legislation. It’ s secure. Effective. Comfortable. It’s Teamio.
Software as a Service
Teamio is run as a SaaS (Software as a Service), which simply means:
- it is operated in a private cloud
- it is located at multiple data centers due to high availability
- Teamio servers & data are located in multiple data centers within the EU
- LMC as an Application Service Provider (ASP) ensures continuous operation
Personal Data Protection
- User data can be accessed only by a restrictive group of authorized staff.
- Concerned to sensitive data, security measures always include a full track of operations and activities associated with the operator identity.
Segregation of Roles
We recognize the following roles from the very nature of the user request handling:
- CustomerCare [40+] - receives customer requirements and try to process (in the first-line)
- Support [20+] - technical support staff (second-line of processing pipeline)
- Business [20+] - to solve functional requirements for products, campaigns, etc. (3rd line)
- System administration [10+] - to maintain tech resources (servers, backups...)
Above described roles have to (or potentially may have) access to a part/complete user data. Indicative numbers of staffing may helps to depict the size of support inevitably accessing sensitive data.
Personal Data Deletion
There are two ways to delete a personal data of the applicant:
Each client can choose an individual period of validity of the consent.
Deletion of personal data is always an irreversible step.
Recovery of deleted candidate is not possible due to all related data is permanently anonymized.
There is no way behind this point, how to gather any info (including most of auditing info) about such a deleted candidate or related activities.
The one and only exception is a Consents log (see Audit section below).
Technical Security Measures
- User access is provided by encrypted connection - only
- Non-production (development / testing) environment separated out of production-grade data
- User data confined within production, non-production uses synthetic/obfuscated data corpus
- Security-relevant activities on production systems are monitored, logged and timely evaluated
- Activation of components/services (per user request) is always validated at LMC side
- Teamio solution is continuously developed and tested (functionality and security together)
- Updates and patches are released on a daily basis (or faster in case of a serious trouble)
- Processing and protection of user data is ensured in accordance with EU legislation (GDPR).
- All detected breaches of sensitive (personal) data protection are reported to both the supervisory authority and the data subject within the reporting obligation (according to GDPR).
- The scope and content of the report is precisely specified by the legislation (EU Regulation 2016/679, Articles 33, 34), which we strictly follow.
The full text of the GDPR directive is available at European Commision official site.
Support requests are collected and registered using HelpDesk and processed by Customer Care in the shortest possible time, obviously during common business hours (Mon-Fri, 08-17 CET).
Compatibility & Minimum Requirements
- Teamio is accessible through the web browser (it is compatible with major browsers - Firefox, Chrome, Explorer/Edge, Safari at least)
Data in Transit
Web access allows HTTPS (encrypted) connections only.
- Enforces TLS 1.2 protocol
- The X509v3 SSL certificate is signed by trusted CAs (accepted by all major web browsers)
- The client certificate is not required
Separation of individual client sessions is ensured by the cookie mechanism.
All production system traffic in both directions is filtered and only HTTPS for user interaction and encrypted access (SSH protocol with key authentication) for maintenance / updating of the application is enabled.
User authentication (Sign-in) involves a single-factor, form -based (user/password) mechanism. User accounts are treated as individual (LMC strongly discourage to share accounts among multiple users). The number of attempts to log in to the system under a particular user identity is dynamically restricted to protect against brute-force password attacks. The plain text password is never stored and is present only in-memory at the time of user login in. Passwords are stored only hashed. The hashing algorithm is continually modified to respond to the changing state of technology.
Logon parameters must meet password policy. The current setting follows:
- The username is a unique identifier (an email address can also be used).
- The minimum enforced password length is 8 characters, maximum is limited to 128 characters.
- A password complexity is enforced (a combination of at least two character sets of digits, characters, special characters).
- So-called trivial passwords (numeric / character series, e.g. 123456, abcdef) are rejected.
- It is enforced to change the initial password (after setting up the user / password setting by the operator) at the next logon.
- The password change is not enforced (i.e. the password does not expire), therefore the history of the used passwords is not recorded.
- The password hashing algorithm is PBKDF2(HMAC-SHA256), 1M iterations, „salted“ individually per account.
- 5 unsuccessful attempts to log-in blocks the particular user account for an 1 hour.
Particular user actions are authorized based on predefined role granted to the individual user. Self-care role management is administered by mandated users of each tenant (registered company space) individually.
The following user roles are defined (availability depends on Teamio edition):
- HR Manager - role has an access to the all registered job positions & to all responses to these positions. There is privilege to change company profile settings (templates, headers, etc.). Can be (optionally) set to any combination of the following rights:
- Access to service statistics
- Access to recruitment statistics
- Access to account credit administration
- User account management
- Recruiter - role has an access only to own registered job positions & relevant responses. There is no right to change company profile settings. Role has privilege to:
- Access to shared pool of applicants including access to other recruiter’s (within the tenant) candidates who have been pre-selected, interviewed, or joined.
- Access to incoming messages (if the edition contains Inbox service).
- Recruiter (without the possibility of spending credits) - varies only by blocking credits (e.g. payment by credit for posting, uncovering a CV in a database, etc.)
- Line Manager - role has access only to the candidates for job positions shared to. There is no right to change company profile settings or work with a job position. Role has privilege to:
- Add comments
- Invite applicants to interviews
Data at Rest
Teamio code runs sandboxed in WildFly application servers built-up on the top of hardened Linux operating systems.
All components run virtualized (OpenStack) on the private cloud solution due to high-availability and fast disaster recovery options.
Main portion of data are kept within the High Availability Disaster Recovery database back-end (IBM DB2).
The helper applications use the PostgreSQL database cluster.
Data are continuously synchronized and mirrored to multiple locations, also backup is made on the regular basis.
Backup takes place according to a defined plan (retention is implicitly set for 14 days):
- All servers are backed up by the cloud provider in the form of volume snapshot
- Transaction log backup is ongoing (to ensure data recovery within 24 working day hours far from the crash)
- Snapshot of the cloud platform takes place daily, every 4 hours
- Full data backup data runs weekly
Multi-level backup system is used:
- Online replication of data to multiple locations
- Backup of private cloud itself
- Internal backup systems
Monitoring & Supervision
The operations monitoring runs continuously (24x7).
The status is supervised (and any issues notified) daily (07-22 CET):
- external monitoring services together with internal systems are employed to check the status
- to check the three months history of uptime of the core entrance Teamio points and chosen subdomains on jobs.cz that are used for hosting of Career Pages, visit http://stats.pingdom.com/xxltcf7m2rk7
The development, integration and testing environments are fully virtualized and run on a private cloud platform. The environments are logically split (by firewalling). Access rights to different environments are different. Mentioned again, the production environment is fully separated (physically) from non-production environments.
Planning, development and testing of any updates/new releases of Teamio takes place in the framework of agile development (We cycle using SCRUM’s Sprints).
All used components (including in-house developed) are tested for stability, availability, and security prior to production deployment, so that vendor / platform manufacturer support is always maintained.
In the case of identified security flaws, updates (patches/fixes) are applied after testing in the shortest possible time.
Testing takes place in a continuous and multi-level development:
- Prior to accepting any change in the source code, a developers review (local Lint and four-eye control principle) takes place.
- In the framework of code quality control, static code analysis is performed (using the code review instruments).
- The application is further controlled (still pre-production) by dynamic analysis (using specialized penetration test tools).
- Regular (annual) independent assessment of application security (through penetration testing) is also carried out by a specialized 3rd parties.
Passed tests will open release management process to move the new code to production. This is fully automated (no hand-intervention allowed) deployment process with full audit track (to ensure rollback to the last good version, when deployment fails).
Audit records are taken as a track of all significant activities of the users. Audit (logging) is layered, descending from the application level to the system as follows:
- History (of user activities)
- Business log
- Security log
- Application log
- System log
- Consents log
Each record is tied with the timestamp and the user identity. Records are kept in the log(s) for the period specified for particular audit track, but at least 180 days.
Detailed info about user activities (e.g. reasons for refusal, "brand" from which the response was delivered, etc.), currently comes from the modules:
Recruitment Activity (Teamio Smart Edition only)
Activities over company (tenant) user's
Detailed info about particular user actions/automated actions of the system (over 700 different types of events are currently registered - operations with positions, job applicants, service orders, etc).
Info about security-related actions (e.g. authentication result etc).
Low-level application events:
- HTTP requests
- Database accesses
- Performance measurement info
- Application errors
Consent log (GDPR related)
We keep the information in the consent log for ten years.
- Name, Surname, Email of the applicant
- Business ID
- the date of the consent / the non-consent
Check the LMC's GDPR page for more detailed info.
All the main principles, measures and technical solutions used to safely develop and operate Teamio and protect sensitive user data are listed on this page.
Upon request, we provide our business partners with a detailed description of LMC security measures in the format defined by the ISO/IEC 27001.
This level of providing security information to third parties is final (no further security info, like Test Reports, Internal Security Guidelines etc. are provided outside LMC).
Declaration of Conformity
We confirm that the web service provided by us is developed in accordance with the current knowledge of application security.
As part of the risk management process, we periodically identify the risks of our services caused by potential vulnerabilities and implement measures to suppress them.
The service is regularly subjected to security audits according to the OWASP ASVS Level 3 criteria (OWASP Application Security Verification Standard) in order to guarantee the resistance of the service against known vulnerabilities, regularly defined in the OWASP Top 10 ranking.
The severity of vulnerabilities is evaluated according to the CVSS Base Metric Group methodology, and according to our criteria, production services must not contain vulnerabilities higher than Low (on the None-Low-Medium-High-Critical scale).
As a matter of principle, we do not provide other materials or greater detail of our security measures.