Security at Skailer
Control who signs in, who sees what and what every integration can reach
01Sign-in you set
Allow password, Google or Microsoft sign-in, and require 2FA for everyone.02Access down to the field
Each role can view or edit specific fields, for specific people.03Admin actions on record
Logging in as an employee is a permission, lasts an hour and goes to the audit log.The problem
A security review shouldn't take longer than the rollout
The HR team has picked a system, and then the questionnaire arrives: questions about sign-in, access, logging, integrations, AI, hosting and subprocessors. The answers sit with different people at the vendor, and every round of email adds a week. Meanwhile the old setup stays in place: spreadsheets with salaries shared by link, integrations running under an HR manager's login, and former employees who can still sign in. Skailer changes that by putting the controls in the admin's hands and the answers on this page.
Sign-in and identity
Decide how people sign in and require a second factor for everyone
Admins switch each sign-in method on or off: password, Google or Microsoft Entra ID. Google sign-in can be limited to your Google Workspace domains, and Skailer checks the domain Google reports, not just the text after @ in an email address. Microsoft sign-in works for the tenants you list. Two-factor authentication with any TOTP app can be required for the whole organization, and it is asked again when someone accepts an invitation or resets a password, so an email link alone can't take over an account.
01Three sign-in methods
Password, Google, Microsoft Entra ID; at least one must stay on.02Workspace domain check
Google sign-in limited to the domains Google confirms for your organization.03Required 2FA
TOTP apps with one-time backup codes; admins can reset it for a locked-out employee.04Password policy
Minimum length of 8 or more, expiry from 1 to 180 days.05Allowed email domains
Work emails only from the domains you list.Access control
Open each role to the fields and people it needs, and nothing more
Every role in Skailer sets view or edit rights per field group, custom field and custom table column, and per module. It also sets whose data it reaches: the person's own record, their reports, their teams, one location or one legal entity. A new custom field stays hidden until a role is given access. Sensitive actions are separate permissions: managing system access, deleting profiles, logging in as an employee, changing security settings.
01Field-level rights
No access, view or edit for each field, custom field and table column.02Scoped by structure
Reports, teams, departments, locations or legal entities.03Hidden by default
New custom fields and tables are invisible until granted.04Reversible lockout
Disable someone's sign-in without changing their employment records.05Limited portal for new hires
Before the start date, only their onboarding items.
Audit and accountability
Keep a record of who did what, including admins
Admins who need to see the product as an employee sees it use Log in as. It needs its own permission, opens in a separate tab with a banner, and ends after one hour. Inside the session they can't change the password or 2FA, sign documents, give consent, connect integrations or manage API users, and they can't log in as other admins, API users or people who left. Each session start goes to the audit log, and actions during the session are recorded with the person who performed them. The audit log can be searched through the API.
01Log in as with limits
One hour, a banner on every page, restricted actions.02Audit log
Searchable through the API with its own permission.03Termination log
Every automatic change a departure makes.04Balance history
Every leave accrual, carryover and correction with author and date.05Signing evidence
Email code check, sealed file, trusted timestamp and a signing report.
Integrations and AI
Give every integration and AI tool a narrow, revocable way in
The public API accepts only tokens of service users, accounts made for one integration with their own role. Responses hold only the fields that role allows, tokens expire when you choose, and the Skailer web app refuses them. Webhooks are signed with HMAC-SHA256 and go only to public addresses. AI clients connected through MCP sign in as one person and get that person's permissions. The built-in assistant is off until an admin turns it on, reads only what the user may see, and changes nothing without the user's confirmation.
01Service users only
Browser sessions and employee tokens are refused by the API.02Scoped responses
The service user's role decides which fields come back.03Signed webhooks
HMAC-SHA256 signature and secret rotation.04OAuth for email and AI clients
No mailbox passwords stored; MCP signs in per person, read-only unless they allow changes.05AI within permissions
Off by default, confirmation before any change, anonymous surveys stay anonymous.Privacy
Collect consent and set how long candidate data is kept
Recruiting can run consent management under GDPR or Russia's 152-FZ. Candidates receive a consent request with your privacy policy and can ask to edit or delete their data. Each profile shows its consent status, and you set the retention period in days. Inside the company, anonymous surveys keep results hidden until at least 3 people have answered, and the same rule applies to exports and AI summaries.
01Consent under GDPR or 152-FZ
Requested, given, expiring, expired or declined, on every candidate.02Retention period
Set in days, and extended on the candidate profile when needed.03Candidate requests
Links to request an edit or deletion in the consent email.04Survey anonymity
A reveal threshold of at least 3 for results, export and AI.How does Skailer protect HR data?
For reviewers
The questions reviewers ask, answered
| Question | Answer |
|---|---|
| How do users sign in? | Password, Google (limited to your Workspace domains) or Microsoft Entra ID (your tenants). Admins choose which methods are on. |
| Can we require 2FA? | Yes, for the whole organization. TOTP apps with backup codes; also asked on invitation and password reset. |
| Do you support SAML SSO or SCIM? | Not today. Google and Microsoft Entra ID sign-in are available. |
| Who can see salaries? | Only roles given access to compensation fields, and only for the people in the role's scope. |
| Can admins act as other users? | Only with the Log in as permission, for one hour, with restricted actions, recorded in the audit log. |
| Is there an audit log? | Yes, searchable through the API. |
| How do integrations access data? | Through service users with their own roles and tokens with a lifetime you set. |
| How are outgoing events secured? | Webhooks are signed with HMAC-SHA256, go only to public addresses, and the secret can be rotated. |
| What can AI see and change? | Only what the user may see. Changes need the user's confirmation; nothing is deleted. AI is off until an admin enables it. |
| What happens when someone leaves? | Termination hands their responsibilities to a successor; admins disable sign-in in one action. |
How it works
How we work through your security review
01Check the controls yourself
Review sign-in, roles, audit and integrations in a demo account.02Set it up before rollout
Choose sign-in methods, require 2FA and build roles before anyone is invited.03Go live with integrations scoped
Create service users for each integration and connect AI clients per person.Security at Skailer, answered
Does Skailer support SSO?
Yes, through Google sign-in (limited to your Workspace domains) and Microsoft Entra ID sign-in (limited to your tenants). SAML and SCIM aren't supported today.