SECURITY & PRIVACY straight answers

Know where your people data lives. Know who can reach it.

HollyHR checks the selected workspace before serving a record, gives selected high-sensitivity fields another encryption layer and names the providers involved. The gaps are here too.

Controlled early access · evidence reviewed 18 July 2026 · no certification or blanket UK-hosting claim

Access checked against the selected organisation Provider regions named by data purpose Current limitations published beside the controls
Open private documentSYNTHETIC
REQUESTMaya Patel · Employment contract.pdfOpen in HollyHR
Authenticated sessionServer-side session is active
Selected membershipAcme Studio · active
Document permissionViewer may open this record
Same-workspace lookupDocument belongs to Acme Studio
AUTHORISATION RESULTPrivate attachment link issued
60 seconds
A document id from another workspace does not change the selected organisation.
Synthetic view. The real service proves the signed-in workspace, permission and organisation-scoped document before issuing a short-lived attachment link.
Who can reach a record?

Sign-in opens the door. It does not open every drawer.

HollyHR starts with an authenticated server-side session, then proves an active membership in the selected organisation. The service still has to check the permission and keep that organisation attached to the data operation.

This tenancy boundary is enforced by the application and backed by guards and cross-organisation tests. Database row-level security is not active as a second independent layer, so the page does not call the boundary database-guaranteed.

Prove an active membership

Signing in is not enough. HollyHR checks that the person still belongs to the selected organisation.

Check the specific permission

Role, relationship and resource rules decide whether this person may perform this action.

Keep the organisation in the query

Business-data reads and writes carry the organisation boundary into the application repository.

DATA LOCATION MAPDifferent jobs. Named regions.
Reviewed 18 July 2026
Primary HR recordsNeon
EU · Frankfurt
Application requestsVercel runtime
EU · Frankfurt
Uploaded documentsAWS S3
UK · London
Database backup copiesAWS S3
UK · London
Product analyticsPostHog Cloud
EU project
Sanitised error metadataSentry
EU project

Email, billing, support and human mailbox providers have their own regions and transfer terms. The public register names them instead of stretching one UK/EU claim over the whole service.

Production-facing region evidence is kept per data purpose. This is not a claim that every HollyHR sub-processor is UK- or EU-only.
Where does the data live?

UK-built is useful context. It is not a residency answer.

HollyHR's primary HR records and application runtime are in the EU. Uploaded documents and HollyHR database backup copies are in AWS London. Product analytics and error monitoring use EU projects.

Email, billing, support and mailbox providers can process elsewhere under their own terms and safeguards. The register names those boundaries individually instead of describing the whole service as UK-only.

Inspect every named sub-processor
How is sensitive data protected?

Encrypt the values that deserve another layer. Restrict the read as well.

Storage encryption helps if storage is exposed. It does not decide whether a manager, administrator or support operator should see a salary, bank value or tax identifier in the running product.

Transport and managed storage

HTTPS protects data in transit. The managed database and private object storage encrypt data at rest.

Application-encrypted values

Selected bank, tax/government identifier and compensation values are encrypted before persistence.

Private document delivery

Uploaded HR files are not public URLs. An authorised open creates a short-lived signed attachment link.

Maya Patel · protected fieldsMASKED
MP
EMPLOYEE RECORDMaya PatelPeople Operations Lead
Acme Studio
Bank account•••• 6789
Encrypted before persistence · masked by default
Tax / government IDEncrypted value
Application-level authenticated encryption
Compensation£ — protected
Encrypted before persistence · authorised server reads
An extra layer for selected fields—not a claim that every column is encrypted twice.

The managed database and storage providers encrypt data at rest. HollyHR adds its own encryption to selected bank, tax/government identifier and compensation values.

Synthetic values. Access checks still matter: encryption at rest does not decide who should see a field in the running product.
SIGN-IN AND ASSURANCEIdentity first. Workspace next. Step up where adopted.
01
Magic linkThe stored transient token is hashed
Shipped
02
Google; Microsoft when configuredWork-account OAuth through Better Auth
Available
03
Database sessionSelected workspace and revocation state stay server-side
Shipped
04
Second factorPlatform-admin entry is gated; selected sensitive actions step up
Scoped

Tenant users can enrol a second factor, and selected sensitive actions require fresh proof. Universal privileged-tenant entry enforcement is not claimed yet.

Session assurance is risk- and surface-specific. A security page should not turn a scoped step-up control into a blanket MFA claim.
How does sign-in work?

Passwordless access. Revocable sessions. More proof for sensitive actions.

HollyHR supports magic-link and Google sign-in, with Microsoft work-account sign-in where configured. Transient verification identifiers are stored hashed, while the selected workspace and revocation state live in the database-backed session.

Platform-admin workspace entry is MFA-gated. Tenant users can enrol a second factor, and selected sensitive System Admin and HR Admin actions ask for fresh proof. A universal MFA gate on every privileged tenant sign-in is not claimed.

What if something goes wrong—or you leave?

Backups protect the service. Exports protect your choices.

HollyHR takes a nightly database copy to separate versioned storage in London and has restored a prior S3 dump into a disposable database branch. That is useful evidence, not a public recovery-time promise.

An authorised customer can prepare a structured organisation export with eligible uploaded files and a manifest. Portability should not require a commercial negotiation.

RECOVERY AND PORTABILITYCopies for us. An exit for you.
Not an uptime or recovery-time SLA
STEP 1Nightly database copy

PostgreSQL dump scheduled at 03:33 UTC

STEP 2Archive sanity check

Gzip integrity and minimum-size check

STEP 3Separate UK bucket

Versioned S3 storage in London with lifecycle retention

STEP 4Restore route

A prior S3 dump was restored into a disposable Neon branch

CUSTOMER-CONTROLLED EXITOrganisation export prepared
Named CSV areas14
Eligible uploaded filesIncluded
Included / skipped manifestIncluded
Signed download window5 min
Prepared after a fresh security check
Backups support HollyHR recovery; the organisation export supports customer portability. Neither should be described as a complete database clone or guaranteed recovery time.
Shared responsibility

Good controls still need good decisions.

HollyHR protects and processes the service. The employer remains the controller of its people data and decides why it is held, who should see it and how long it is needed.

Keep access current

Choose appropriate roles, remove leavers promptly and use MFA for the people and actions that need it.

Use people data lawfully

Your organisation remains responsible for lawful basis, notices, retention choices and responding as controller.

Protect exports and links

Downloaded exports and temporary links remain sensitive after they leave the HollyHR interface.

Proof, without theatre

Security is an operating practice, not a badge collection.

HollyHR is a controlled early-access product. The current controls are real; so are the maturity gaps. A careful buyer should see both before sharing an employee record.

Bring us your due-diligence checklist

Independent assurance

Not claimed: ISO 27001, SOC 2, Cyber Essentials or a completed external penetration test.

Tenant isolation

Application scoping, guards and cross-organisation tests are active. Database RLS is not active as an additional layer.

Defence depth

Security headers and CSP reporting are active. CSP enforcement, universal tenant-admin MFA and file malware quarantine are not claimed.

Operational promises

There is a live status surface, incident process, nightly backup and prior restore evidence. No public SLA, RPO, RTO or 24/7 security operation is promised.

Security questions, answered

Straight answers for the awkward bits.

Locations, access, encryption, MFA, incidents, assurance, export and UK GDPR—without turning a limitation into a footnote.

How does HollyHR protect employee data?

HollyHR combines server-side sessions, active-organisation membership checks, permission-aware services, application-scoped database queries, extra encryption for selected high-sensitivity values, private signed document access and audit records for sensitive actions. No single layer is presented as a complete guarantee.

Where is HollyHR data stored, and does it leave the UK?

Primary HR records and the application runtime are in the EU, while uploaded documents and HollyHR database backup copies are stored in AWS London. Supporting providers—including email, billing, support and human mailbox services—have their own regions and transfer terms, so HollyHR does not claim that all processing stays in the UK.

Who owns the employee data in HollyHR?

The customer controls its organisation data. HollyHR processes that data to provide the service under its Data Processing Agreement. Customers can prepare an organisation export without opening a support ticket, but some provider records and legal-retention evidence have separate handling boundaries.

Does HollyHR support MFA?

Yes, but the policy is deliberately described by scope. Platform-admin workspace entry is MFA-gated. Selected sensitive System Admin and HR Admin actions require a fresh step-up, and tenant users may enrol a second factor. HollyHR does not yet claim universal MFA enforcement whenever every privileged tenant user signs in.

Can HollyHR staff see employee data?

Not through blanket tenant impersonation. Support or security access is capability-gated, purpose-bound, time-limited and organisation-bound, and person-bound where applicable. Platform-admin workspace entry is MFA-gated; selected sensitive reveals and actions require fresh step-up. Approved organisation-wide read-only view-as can occur with customer approval, so HollyHR does not claim that staff can never see customer data.

Is data encrypted in transit and at rest?

HTTPS protects service traffic and the managed database and object-storage providers encrypt data at rest. HollyHR also applies authenticated application encryption to selected bank, tax or government identifier and compensation values. That is not a claim that every database column is encrypted twice.

How do backups and recovery work?

HollyHR schedules a nightly PostgreSQL archive, checks the compressed archive and stores it in a versioned AWS S3 bucket in London. A prior S3 dump has been restored into a disposable Neon branch. HollyHR does not publish a guaranteed recovery time, recovery point or uptime SLA.

What happens if there is a security incident?

HollyHR has documented incident and personal-data-breach procedures, production health checks and a public status page. Affected customers would be contacted according to the contractual and legal circumstances. The controlled early-access service does not claim a staffed 24/7 security operation or a public numeric response-time commitment.

Is HollyHR certified or independently penetration-tested?

No. HollyHR does not currently claim ISO 27001, SOC 2 or Cyber Essentials certification, and it has not completed an external penetration test. Those are genuine maturity gaps rather than badges the page tries to imply.

What happens to our data if we leave?

An authorised customer can prepare a structured organisation export with named CSV areas, eligible uploaded files and a manifest. Ordinary leaver offboarding archives access; it is not data erasure, and the person's records remain. Verified erasure removes or anonymises identifying live data, queues known document and avatar objects for deletion, and retains justified referential, audit, statutory and operational records. Provider-side records need separate handling, while backup copies age out rather than disappearing instantly.

Does using HollyHR make us UK GDPR compliant?

No software makes an employer automatically compliant. HollyHR provides a DPA, sub-processor register, access controls, export, DSAR and erasure routes to support UK GDPR duties. The customer still decides lawful basis, notices, permissions, retention and how the service is used.

Is employee data used to train AI?

Core HollyHR workflows do not require an AI provider. Optional developer-preview AI access can return approved, scoped data to a tool chosen by the customer; that tool has its own retention, training, region and sub-processor terms. Connecting it is a separate customer decision, not a hidden part of ordinary HR processing.

A careful question is welcome

Bring us your people-data checklist.

Join early access if the product fits. If a security answer decides it, ask us directly—we would rather qualify a claim than bluff through procurement.