Security at Native Keeper

If you're trusting Native Keeper with data about your workforce — including in many cases health records, sickness data, DBS certificates, Right to Work evidence, and payroll identifiers — you deserve to know how we protect that data.

This page is a straight-talk overview of how we approach security. It's organised so a busy CISO, a curious procurement reviewer, or a developer evaluating us can find what they need quickly. If you need more detail than this page provides, every section ends with a way to ask us.

We build for three principles:

Principle What it means in practice

Least privilege People and systems get the minimum access they need to do their job. Access is logged, reviewed, and removed when no longer needed. This applies to our team and — via granular permissions — to your team.

Defence in depth No single control is treated as sufficient. We layer encryption, access control, monitoring, and contractual safeguards so that any single failure doesn't compromise the system.

Secure by default Customers should get strong security without having to configure it. The defaults are safe; the more sensitive an operation, the more friction we design into it.

Security isn't a separate project at Native Keeper — it's a constraint on every product and engineering decision.

• TLS 1.2 minimum, TLS 1.3 preferred, on all connections to and from the Service
• HSTS (HTTP Strict Transport Security) enforced on all public domains
• Modern cipher suites only; legacy and weak ciphers disabled
• Certificate management automated via our CDN provider with regular rotation

• AES-256 encryption for all Customer Personal Data stored in primary databases
• AES-256 encryption for backups
• AES-256 encryption for uploaded files — including DBS certificates, RTW evidence, training certificates, and any other sensitive documents you upload
• Key management via cloud-provider key management services; keys are rotated regularly and never stored alongside encrypted data

Because Native Keeper is designed to hold sensitive workforce documents, uploaded files receive specific attention:

• Encrypted at rest using AES-256
• Access requires authentication — files are not served from publicly accessible URLs
• Time-limited signed URLs for document access, with short expiry
• No CDN caching of authenticated document downloads
• Same access controls as the record they are attached to — the file is only visible to Admin Users with permission on that employee's record

• Logical separation of customer data within multi-tenant infrastructure, enforced at the application and database layer
• Row-level security policies prevent any customer from accessing data belonging to another
• No shared file storage across customers

• EU data residency available on supported plans: workforce data stored exclusively within the EEA (Frankfurt region)
• UK data residency available on supported plans
• Default residency: EU for European customers, US for others
• CDN and edge processing distributed globally for performance but encrypted in transit

• No customer data on local devices. Our team accesses production data only through audited channels, never by downloading datasets.
• No routine access to workforce record content. We do not, in the ordinary course of providing the Service, read the content of your employee records or uploaded documents. Access for troubleshooting, security, or legal compliance is on a break-glass basis, is logged, and requires justification.
• Multi-factor authentication (MFA) required for all employee and contractor access to production systems, source code, and administrative interfaces
• Role-based access control (RBAC) with least-privilege defaults
• Just-in-time (JIT) access for any escalated production access, requiring justification and an automatic expiry
• Hardware security keys required for the most sensitive operations
• All production access logged and reviewed
• Periodic access reviews to remove unused or excessive privileges
• Immediate revocation when a team member leaves

We strongly recommend enabling MFA on every Native Keeper account and reviewing Admin User access periodically.

• Strong password requirements enforced at signup
• Multi-factor authentication (MFA) available on all paid plans
• Single sign-on (SSO) with SAML 2.0 and OIDC available on enterprise plans
• Granular Admin User permissions — you decide which of your Admin Users can see which records, and which sensitive document categories (e.g. DBS certificates, health records) they can access
• Session management with reasonable timeouts and easy session revocation
• Audit log of significant account activity available to administrators on supported plans — including who accessed which employee records, who uploaded or deleted documents, and who changed permissions

• Secure development lifecycle (SDL) with security considerations at design, implementation, and review stages
• Code review required for every change to production code, by a second engineer
• Automated dependency scanning for known vulnerabilities in our software supply chain, blocking merges of vulnerable dependencies
• Static application security testing (SAST) integrated into our CI pipeline
• Secrets management with no credentials in source code; all secrets stored in dedicated secret managers
• Branch protection with required reviews and passing tests before code reaches production

• Hosted on world-class providers: Vercel for application delivery, Supabase for database and file storage, Cloudflare for CDN and security — all of which maintain SOC 2 Type II reports, ISO 27001 certifications, and other recognised security attestations
• No on-premise infrastructure. We rely on certified, audited cloud providers for physical security, environmental controls, and hardware lifecycle
• Network segmentation between production, staging, and development environments
• Web application firewall (WAF) filtering malicious requests
• DDoS protection at the network edge

Documented patching SLAs by severity:

Severity Target time to patch

Critical (CVSS 9.0–10.0) Within 24–72 hours

High (CVSS 7.0–8.9) Within 7 days

Medium (CVSS 4.0–6.9) Within 30 days

Low (CVSS 0.1–3.9) Within 90 days

• Continuous vulnerability scanning of dependencies and infrastructure
• Penetration testing planned annually by an independent third-party once the product reaches the appropriate scale and maturity (see Section 10)

• Centralised logging of security-relevant events from application, infrastructure, and access layers
• Automated alerting on anomalous activity (unusual access patterns, configuration changes, failed authentication spikes)
• 24/7 paging for critical alerts to on-call engineers
• Audit logs retained for at least 12 months

• Automated daily backups of all customer data
• Encrypted backups stored in geographically separate locations from primary data
• Tested recovery procedures to ensure backups are restorable
• Point-in-time recovery available for the database within a defined window
• Retention consistent with HR use case — because workforce records often have statutory retention obligations, our backup and recovery approach preserves data appropriately

• Documented disaster recovery plan with defined recovery time and recovery point objectives
• Multi-region failover for critical infrastructure services (provided by our underlying cloud providers)
• Regular review of business continuity arrangements

We maintain a documented incident response plan that defines:

For Personal Data Breaches, we notify affected customers without undue delay and in any event within 72 hours of becoming aware of the breach, with the information required by GDPR Article 33.

• How incidents are detected (automated alerts, customer reports, partner notifications)
• How incidents are triaged by severity
• Who is responsible at each stage of response
• How affected customers are notified, including the 72-hour breach notification commitment in our DPA
• How we conduct post-incident reviews to prevent recurrence

• Background checks appropriate to role and jurisdiction for team members with access to sensitive systems or data
• Confidentiality obligations in every employment and contractor agreement
• Security and privacy training at onboarding and refreshed periodically
• Phishing-resistance training including simulated phishing exercises
• Acceptable use policy for internal systems
• Offboarding process that revokes access on the last day of employment or engagement

We rely on a small number of carefully selected third parties to deliver the Service.

Before engaging any sub-processor with access to Customer Personal Data:

• We assess their security posture, including certifications (ISO 27001, SOC 2 Type II) and recent audit reports
• We review their data-protection commitments and contractual terms
• We sign a data processing agreement imposing obligations no less protective than what we owe our customers
• We document the purpose, scope, and data categories they will process
• We assess their suitability for holding HR-sensitive data, including document uploads
• We periodically review continued compliance.

The full list of sub-processors — with their purpose, location, and the safeguards applied to international transfers — is at nativekeeper.com/legal/sub-processors. You can subscribe to email notifications of any change with 30 days' prior notice.

We only share what is necessary for each vendor's function:

• Payment processor (Stripe): Billing and payment data only. Stripe handles full payment card data directly; we never see or store card numbers. No workforce records are sent to Stripe.
• Email delivery (Resend): Recipient addresses of Admin Users and email content (which includes summary compliance-reminder information but not full workforce records).
• Analytics (PostHog): Behavioural data on how Admin Users interact with the dashboard. No workforce record content or Data Subject personal data.
• Error monitoring (Sentry): Technical error data. Personally identifiable information is scrubbed before transmission where technically feasible.

The full picture is in our Privacy Policy and GDPR page.

• Security and privacy reinforce each other. Our commitments include:
• Customer Personal Data is yours. You can export and delete it at any time.
• We do not sell or share Personal Data for cross-context behavioural advertising
• We do not use workforce record content to train any AI model — ours or any third party's
• Signed Data Processing Agreement with every paying customer (see /legal/dpa)
• GDPR Art. 28-compliant terms including EU SCCs and UK IDTA for international transfers
• Support for Special Category and Criminal-Offence Data under Art. 9 and Art. 10 UK/EU GDPR
• Self-service data-subject-request tools so you can fulfil access, portability, and erasure requests from your workforce
• Configurable retention so workforce records don't outlive their lawful basis
• Regional data residency available on supported plans

We are honest about where we are on the compliance journey.

Certification or framework Status

UK GDPR / EU GDPR Compliant; signed DPA with every paying customer

DPA 2018 (UK) Compliant; supports Art. 9 and Art. 10 processing where the customer has a lawful basis

CCPA / CPRA Compliant for California residents (see Privacy Policy, Section 13)

PECR / ePrivacy Compliant for cookies and electronic communications

ICO registration Registered with the UK Information Commissioner's Office (registration number on our GDPR page)

ISO 27001 🟡 On our roadmap — planned after SOC 2

CQC and other sector regulator certifications Not held. Many regulated employers use Native Keeper to support their record-keeping obligations under sector regulation, but responsibility for meeting those obligations remains with the customer.

HIPAA ❌ Not currently designed for HIPAA covered entities; we do not sign BAAs at this time

PCI DSS We do not store payment card data. Payment processing is handled entirely by Stripe, which maintains PCI DSS Level 1 certification.

Sub-processors' certifications All major sub-processors are SOC 2 Type II audited and ISO 27001 certified

We don't post badges for certifications we haven't earned. When the SOC 2 report is available, this section will be updated and the report will be available to customers under NDA.

• SOC 2 Type II 🟡 In progress — we have begun the readiness work and will publish our report once the audit window concludes

• Annual third-party penetration testing is planned as part of our SOC 2 readiness work
• Bug bounty program is on our roadmap; we expect to launch one as we scale
• Until then, we operate a responsible disclosure program (see Section 11)

If you believe you've found a security vulnerability in Native Keeper, we want to hear about it.

• Email: legal@nativekeeper.com
• Subject: "Security disclosure"
• What to include: A clear description, steps to reproduce, the impact you've identified, and any proof-of-concept that helps us verify

• Acknowledgement within 2 business days
• Initial assessment within 7 days
• Fix or workaround on a timeline appropriate to severity (see Section 4.3)
• Updates as we work — we will keep you informed
• Public acknowledgement (with your permission) once the issue is resolved
• No legal action against researchers acting in good faith under these rules

We do not currently offer monetary rewards but may at our discretion offer recognition and thanks for impactful disclosures. This will change when our bug bounty program launches.

• Do not access, modify, or delete data belonging to anyone other than yourself
• Do not perform testing that could degrade the Service for other customers (DoS, brute force, fuzzing of production)
• Do not demand payment as a condition of disclosure
• Give us a reasonable opportunity to fix the issue before disclosing publicly

Security is shared. Even the most secure platform doesn't protect against a compromised customer account. To get the full benefit of Native Keeper's security model, we recommend:

Do Why it matters

Enable MFA on every Native Keeper account Stops the overwhelming majority of credential-stuffing and phishing attacks

Use a unique, strong password (ideally from a password manager) Prevents reuse-driven account takeover

Use SSO where available Centralises identity and offboarding

Review Admin User access regularly Removes ex-employees and stale accounts

Restrict access to sensitive documents (DBS certificates, health records) to Admin Users who genuinely need it Data minimisation and least privilege reduce breach impact

Configure retention so old records are deleted when lawful basis ends Data you don't keep can't be stolen

Ensure your use of the Service complies with the AUP and applicable law Misuse of the Service creates risk for you and your workforce

Report any suspicious activity on your account to legal@nativekeeper.com immediately Speed matters in incident response

If you're evaluating Native Keeper for your organisation, we can provide:

Resource How to get it

We try to make procurement reviews easy. If you have specific requirements that aren't covered above, just ask.

• Standard security questionnaire response (SIG Lite, CAIQ, or your own template) Email legal@nativekeeper.com — turnaround typically 5 business days
• Counter-signed DPA legal@nativekeeper.com
• Counter-signed NDA before sharing further detail legal@nativekeeper.com
• Pen test summary (when available) Under NDA, via legal@nativekeeper.com
• SOC 2 Type II report (when available) Under NDA, via legal@nativekeeper.com
• Architecture and data-flow diagrams Under NDA, via legal@nativekeeper.com
• Sub-processor list with current safeguards Public at /legal/sub-processors
• Privacy and compliance documentation Public at /legal/privacy, /legal/gdpr, /legal/dpa

Topic Email

Security disclosures legal@nativekeeper.com

Procurement and questionnaires legal@nativekeeper.com

Data protection and DPA legal@nativekeeper.com

General enquiries and support hello@nativekeeper.com

Postal address:

NeonStack Ltd

The North Colchester Business Centre

340 The Crescent

Colchester, England, CO4 9AD

United Kingdom