calhire
Hire talent
Every applicant arrives assessed and AI-interviewed.See how

Capability

Enterprise controls

The controls a security review asks about, described at the level a security review asks about them.

CalHire’s enterprise controls cover SAML 2.0 single sign-on, role-based and job-scoped attribute-based access control, departments with approval chains, custom domains and white-labelling, and regional data residency. Tenant isolation is enforced both by database row-level security and by application-level query filters, so a defect in one layer does not expose another tenant’s data.

Last reviewed

The short version

  • SAML 2.0 SSO, with accounts created on first sign-in; removing a member in CalHire revokes their sessions immediately (there is no directory sync, so offboard in both places).
  • Access is job-scoped as well as role-based: a recruiter on one requisition cannot read another.
  • Tenant isolation is enforced twice, at the database and in the application, on the assumption that either could fail.
  • Departments, approval chains, custom domains, white-labelling and regional residency are all configuration rather than a bespoke build.

The controls, plainly

  • SAML 2.0 single sign-on

    Your identity provider owns authentication. Sessions can be revoked centrally, so an offboarding in your IdP takes effect here rather than leaving a live session behind.

  • Roles and job-scoped permissions

    Role-based access decides what a person can do. Attribute-based rules decide which requisitions they can do it on, evaluated server-side on every request rather than hidden in the interface.

  • Departments and approvals

    Requisitions belong to departments, and approval chains gate what needs gating. A hiring manager sees their own pipeline; a department head sees the department.

  • Custom domains and white-labelling

    Careers surfaces on your domain with your brand. Talent experiences your company rather than a vendor’s interface with a logo in the corner.

  • Data residency

    Regional deployment so talent data stays in the region you need it to. Relevant wherever transfer rules make location a legal question rather than a preference.

  • Audit and evidence export

    The same hash-chained trail that carries hiring decisions carries administrative ones: permission grants, configuration changes, and who made them.

Why isolation is enforced twice

Multi-tenant data leaks almost never come from a dramatic breach. They come from a query somebody wrote in a hurry that forgot a tenant filter, and from a code path that nobody thought was reachable from another tenant’s session.

So tenant scoping is enforced in two independent places. PostgreSQL row-level security policies constrain what a connection can see at the database, and application-level global query filters constrain what the data layer will ask for. A developer who forgets the filter hits the database policy. A misconfigured policy hits the application filter.

Neither layer knows about the other. That is the point. Defence in depth is only depth when the layers fail independently.

What a rollout usually looks like

  1. 1

    Identity first

    SAML connection, attribute mapping, and a decision about which groups map to which roles. Getting this right first means every later permission question has one answer rather than two.

  2. 2

    Structure second

    Departments, approval chains, and who can open a requisition. Most of the friction in a rollout is here. Almost none of it is technical.

  3. 3

    Scoring policy third

    Default composite weights, thresholds, and which roles need work samples. Set once as an organisational default, adjusted per role. Shortlisted talent can also be asked to have a private identity on file before a reveal.

  4. 4

    Then integration and brand

    ATS connector, custom domain, white-label styling. These are the visible parts and the easiest to change later, which is why they come last rather than first.

What this does not do

Single sign-on does not make access control decisions for you. Mapping every employee to a role that can see every requisition is a configuration you can create, and no amount of SAML will save you from it.

Data residency constrains where data is stored and processed. It does not by itself answer whether a specific cross-border transfer is lawful for your organisation, which depends on your legal basis and your regulator.

White-labelling changes the surface, not the process. Talent still experiences anonymous screening, staged reveal and zero-ghosting, because those are the product rather than a theme. If your requirement is a fully bespoke hiring flow under your own brand, this is the wrong tool.

An approval chain records who approved something. It cannot make the approval meaningful. A department head who approves everything within four seconds has produced an audit trail that documents a rubber stamp, accurately.

Questions people actually ask

Which identity providers are supported?
Any SAML 2.0 compliant provider. Attribute mapping is configurable, so group-to-role mapping follows whatever convention your directory already uses.
Can a recruiter see requisitions outside their scope?
Not unless you grant it. Access is evaluated server-side against both role and job scope, so restrictions hold for the API as well as the interface.
How is tenant data isolated?
By PostgreSQL row-level security at the database and global query filters in the application, independently. Both would have to fail in the same way for a cross-tenant read to occur.
Can we host talent-facing pages on our own domain?
Yes. Custom domains with white-label branding are supported, so talent sees your company throughout.
What happens when we remove someone in our IdP?
Their session can be revoked centrally rather than expiring on its own schedule. This is the difference between offboarding and hoping.
Do you support regional data residency?
Yes, with regional deployment for the markets we operate in. Where residency is a hard legal requirement, it should be settled during procurement rather than after go-live.

Related

Where this connects to the rest of the platform.

Read the reasoning

The evidence and the argument behind what is on this page.

Compliance9 min read

GDPR and candidate data: what recruiting teams get wrong

Consent is usually the wrong lawful basis for recruitment. What to rely on instead, how long to keep applications, and the rules on automated decisions.

Read
Compliance9 min read

The EU AI Act and hiring: what recruitment teams are responsible for

AI used to recruit or evaluate candidates is high-risk under the EU AI Act. What that means for employers, what providers owe you, and what to ask vendors.

Read
Compliance8 min read

UAE PDPL and candidate data: what recruiters in the Emirates need to know

The UAE has a federal data protection law plus separate free-zone regimes. Which applies to your hiring, and what changes about handling candidate data.

Read

Browse all topics on the blog

See a verified pipeline for one of your roles

Post a role free and review anonymous, skill-ranked talent. No card, no sales call to get started.

Start hiring freeTalk to the team