Security

How Keepable protects your documents, identity, and audit trail.

Security

Last updated 2 July 2026. Keepable holds important documents on behalf of recipients and the companies that send them. This page describes the controls we run today and the ones we are actively building. If something on this page would be a blocker for your team’s review, write to security@keepable.co and we will work through it with you.

Data residency

Recipient data, document blobs, identity hashes, and audit logs live in AWS region af-south-1 (Cape Town, South Africa). The application tier runs on EC2; the relational store is Amazon RDS for PostgreSQL with daily snapshots; document blobs sit in Amazon S3 with KMS encryption and Object Lock retention. We use Cloudflare in front of the application for CDN, DNS, and edge routing.

Identity verification runs in Nigeria and the liveness check runs inside our own AWS region, so identity data does not leave the country. Where a sub-processor does process data outside Nigeria (notably Resend for transactional email), we rely on a transfer mechanism permitted under section 41 of the Nigeria Data Protection Act. See the Data Processing Addendum and Privacy Notice for the full list.

Encryption

  • TLS 1.2 or higher in transit on every public endpoint.
  • AES-256 at rest on every Postgres volume, S3 bucket, and snapshot, with keys managed by AWS Key Management Service.
  • Per-environment KMS keys with IAM-controlled access and CloudTrail logging on every key operation.

The document seal

Every document delivered to a Keepable mailbox is sealed at the moment of receipt. The seal is a P-256 signature issued by an AWS KMS key, bound to the document’s cryptographic hash and to an entry in our append-only audit log. Recipients can verify a downloaded file at any time with the public verifier on this site. If a sealed file is altered after delivery, verification fails.

Signed covenants

When a document is signed inside Keepable, we return the completed agreement as a covenant: a PDF carrying an embedded advanced electronic signature in the PAdES standard (PDF Advanced Electronic Signatures), together with a trusted RFC-3161 timestamp. The signing certificate chains to a private certificate authority we operate inside our own AWS account, and the signing key is held in AWS KMS and never leaves it. Because the full certificate chain and the timestamp are embedded in the PDF itself, a covenant can be checked with standard PDF-signature tooling; the proof travels with the file and does not depend on Keepable remaining reachable. The signing events are also recorded in the append-only audit log below.

Identity and authentication

  • Passkeys (WebAuthn) are the primary credential for every recipient. We do not use SMS one-time passwords; SIM-swap fraud is a live threat in Nigeria and we treat it as a known weakness in any SMS-based factor.
  • Identity binding. Every mailbox is linked to a Nigerian National Identification Number, verified through an accredited identity-verification provider with a liveness check at onboarding. The raw NIN is used only for that check and is not retained after it completes. We retain a keyed one-way hash (HMAC), with the key held separately from the data store, so a copy of the database on its own cannot be reversed to recover a NIN.
  • Account recovery repeats the identity and liveness check and then requires a new passkey. A NIN alone cannot recover a mailbox.
  • Sign-in alerts are sent on new devices and unusual sign-in patterns.

If someone copies Keepable

A copied website can ask for information, just as a copied bank website can. A NIN by itself cannot access a Keepable mailbox: opening or recovering one also requires a fresh identity and liveness check, and everyday access requires your passkey on your device.

Keepable staff will not ask you to send your NIN, face capture, passkey, password, BVN or OTP in email, WhatsApp, social media, a call or a support conversation. A message, logo or web page cannot prove who sent it. If one makes you unsure, stop and report it to security@keepable.co.

Plane isolation

The recipient, sender, and staff surfaces run as separate applications with separate auth, separate sessions, and separate IAM identities. A sender cannot view recipient mailbox state; a recipient cannot see another recipient’s data; a staff console operator cannot read mailbox contents without an explicit, audit-logged break-glass workflow.

Sender single sign-on runs on self-hosted, open-source software inside our own AWS account, so sender credentials are never handed to a third-party identity service.

Staff access

Staff access to production systems follows a least-privilege model. Console access is mediated by our managed identity provider with mandatory hardware-key MFA. Database access runs through an audited, time-boxed access path with full session recording. Offboarding is automated against the staff directory: when a staff member leaves, their access is revoked.

Audit trail and integrity

Every state-changing event in Keepable lands in an append-only log. We compute per-hour Merkle roots over the log and anchor them to S3 Object Lock; recipients verifying a sealed document can confirm that the audit chain has not been rewritten.

Backups and recovery

Daily encrypted snapshots of the relational store and the document blob bucket, retained on a 7-day cycle. Recovery procedures are exercised on a regular cadence.

Incident response

We aim to detect security incidents through a combination of cloud-native audit logging and threat detection, application telemetry, and out-of-band reports from researchers. When an incident affects personal data, we commit to notifying affected recipients, our regulator, and our DPO within 72 hours of becoming aware of it, in line with the NDPA. Senders are notified under the timelines in their Data Processing Addendum.

Vulnerability disclosure

We welcome reports from independent researchers.

  • Report to: security@keepable.co.
  • Include a clear write-up and proof-of-concept.
  • We acknowledge within two business days and coordinate disclosure timelines transparently.
  • We will not pursue legal action against good-faith research that respects user privacy and avoids service disruption.

We run internal penetration tests on the application stack at least annually and after material architectural changes, and we work with external testers ahead of significant releases.

Compliance posture

  • Registered with the Nigeria Data Protection Commission (NDPC).
  • SOC 2 Type II is in progress; the scope is the Security trust services criterion. We will publish the report on this page when it is issued.
  • HIPAA and PCI-DSS are out of scope. Keepable is not a place to store cardholder data or protected health information.

Sub-processors

The current list of sub-processors handling personal data is in the Privacy Notice and the DPA. We give at least 30 days’ notice to senders before adding or replacing a sub-processor that touches Customer Data.

Contact

Security reports: security@keepable.co. Data protection officer: dpo@keepable.co.

Last updated: 2 July 2026.