Security one-pager

Last updated: May 25, 2026 · Private beta · pilot batch 1

1. Runtime and data residency

  • Application runs on Azure Container Apps in the EU, currently Azure Sweden Central for the production app runtime.
  • Primary database: Azure PostgreSQL flexible server in the same Azure production region family.
  • File storage: Azure Blob Storage for original CV files and deletion/retention workflows.
  • AI: Azure OpenAI (GPT-5.4) and Azure Document Intelligence configured for the service's Azure-based runtime.
  • The service is designed to avoid unnecessary extra-regional processing paths for customer content.

2. Tenant isolation

  • Every candidate, role, note, match, and file is scoped to an organization id.
  • PostgreSQL row-level security enforces tenant boundaries at the database layer.
  • Agency mode adds an additional per-client boundary inside an organization.
  • Platform admins have read-only impersonation by default; write actions are gated.

3. AI guardrails

  • Every sub-score links back to the exact CV sentence, note, or feedback that moved it — no black-box numbers.
  • The service is designed to reduce direct identifiers before CV text is sent to the AI model.
  • AI is instructed to ignore protected characteristics and to ignore instructions embedded in candidate documents.
  • Style-blind summary gate and evidence-risk calibration reduce self-preferencing toward AI-polished CVs.
  • Each AI scoring call records model, prompt version, latency, and confidence in ai_usage.

4. No LinkedIn scraping

sHRark only reads what recruiters manually save and upload — typically LinkedIn profile PDFs and CVs. There is no automated crawling of LinkedIn, no grey enrichment vendor, and no background scraping. The (shelved) browser-extension path requires an explicit user action per profile and writes to the same audited intake pipeline as manual uploads.

5. Access control and audit

  • Pilot authentication uses invited email + password access; passwords are handled by the identity layer and are not stored in plaintext by the application.
  • Role-based permissions: recruiter, hiring manager (optionally scoped to a single recruitment), and platform admin.
  • Full-scope bank or enterprise rollout is expected to use a signed agreement plus Microsoft Entra-based SSO/MFA/Conditional Access alignment when required by the customer's security review.
  • Every sensitive mutation (candidate anonymization, export, invite, impersonation, retention) is written to an audit log.
  • API routes require authenticated sessions; middleware enforces tenant scoping before handlers run.

6. Retention and erasure

  • Per-organization retention window (default 24 months); automatic anonymization after expiry.
  • Recruiter-triggered candidate anonymization removes CV text, files, and source artifacts.
  • Aggregate scoring data may be retained post-anonymization for calibration; no personal identifiers remain.
  • DSAR export and deletion endpoints cover the candidate data model end-to-end.

7. Network and headers

  • Encrypted transport and HSTS on the public host.
  • Content Security Policy scoped to the application, approved backend endpoints, and runtime integrations actually in use.
  • No third-party analytics, advertising, or tracking scripts in authenticated product workflows.

8. Operations

  • Schema migrations are applied through versioned, idempotent SQL with a deploy history table.
  • Rollout is CI/CD via GitHub Actions → Azure Container Registry → Azure Container Apps revisions.
  • Operational backup and restore depend on Azure-managed database backup capabilities and storage durability; full-scope bank agreements should define RTO/RPO, retention, and restore-test evidence explicitly.
  • Public health endpoint: /api/health.

9. Stage and roadmap

sHRark is in private beta. The pilot legal pack is intentionally lightweight so evaluation can start without heavy procurement friction. Formal certifications (SOC 2, ISO 27001) are on the roadmap and not yet in place. For regulated full-scope rollout, sHRark expects a signed DPA/order form, a security annex, agreed incident/backup terms, subprocessor review, and Entra-based identity controls where required.

This page is a security summary, not a contractual warranty, certification statement, or guarantee of compliance for a customer's specific use case.

10. Subprocessors

  • Microsoft Azure — hosting, database, storage, AI (EU regions).
  • Resend — transactional email (invitations and notifications).
  • GitHub — source code and CI.

A public pilot summary is maintained at /subprocessors.

11. Contact

Security questions, vulnerability reports, or diligence requests: founder@shrark.com.