calhire
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 session revocation, so removing someone from your identity provider actually removes their access.
  • 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. Candidates experience your company rather than a vendor’s interface with a logo in the corner.

  • Data residency

    Regional deployment so candidate 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 or an identity check. Set once as an organisational default, adjusted per role.

  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. Candidates still experience 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 candidate-facing pages on our own domain?
Yes. Custom domains with white-label branding are supported, so candidates see 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.

  • AI governance, bias auditing and the audit trail

    Adverse-impact analysis on the four-fifths rule, a hash-chained audit trail, candidate appeals, and DSAR handling. The evidence exists before anyone asks for it.

  • ATS integration and the public API

    Deep connectors for Workday, Greenhouse, Lever and SAP SuccessFactors, a generic webhook connector, and a REST API. Identity syncs only after a reveal.

  • Identity broker and staged reveal

    CalHire holds the candidate’s identity. An employer requests it, the candidate consents or declines, and consent releases it to that one employer with an immutable record.

See a verified pipeline for one of your roles

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

Start hiring freeTalk to the team