Testing deployment — not live. Data here is not production and may be reset at any time.
Security & Trust

Trust that traces to a mechanism, not a slogan

Every claim on this page names how it actually works. No “bank-level security” — just the architecture, so you can evaluate it.

Bring-your-own-database

Grantledger is multi-tenant, but each tenant’s employee data lives in their own database. The vendor operates the application and the workflow — it never holds your raw employee data in a shared, vendor-owned store.

The practical effect: a compromise of the Grantledger control plane does not hand over a pooled database of every customer’s employees, because there isn’t one.

Per-tenant envelope encryption

Sensitive data is encrypted with one data-encryption key (DEK) per tenant, wrapped by an AWS KMS master key.

  • Annual automatic master-key rotation
  • Event-driven per-tenant DEK rotation on suspected compromise
  • Cross-tenant cryptographic binding — one tenant’s data can’t be decrypted with another’s key
  • Secrets (DB passwords, SMTP, MFA seeds) stored only as ciphertext
Audit integrity

A log you can prove wasn’t edited

Every workflow, role, permission, consent, and grievance action is written to a hash-chained audit log: each row’s hash includes the previous row’s hash.

  • Editing a past row breaks the chain
  • Deleting a middle row breaks the chain
  • Deleting the most recent rows is caught by a vendor-side anchor that pins the expected chain length and head
  • Encrypted fields are logged as ciphertext — never plaintext

Access control

  • Mandatory TOTP MFA for admin roles
  • Recovery codes encrypted at rest
  • Admin / IT / Manager / Employee roles
  • Managers scoped to direct reports only
  • Per-system granter / approver / revoker authority
  • Four-eyes approval — no self-approval, ever

Boundary hardening

  • SSRF guard on every tenant-supplied host (DB & SMTP)
  • CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy
  • Rate-limiting on all unauthenticated endpoints
  • Signed, expiring tokens for machine-to-machine trust
  • Signature-verified billing webhooks

How we build

Not marketing — our actual engineering practice:

  • Strict test-driven development (red → green)
  • A mandatory multi-pass, adversarial security audit on every component
  • Findings fixed test-first and logged, not deferred
Responsible disclosure

Found something? Tell us.

We welcome coordinated disclosure of security issues. Please don’t publicly disclose before we’ve had a chance to remediate.

See how this maps to your compliance program.

GDPR, DPDP, and the controls auditors ask about.

See compliance →