Security

How Keepable protects identities, documents, requests, and records.

Security

Last updated 13 September 2026. Keepable helps people and organisations exchange important documents, complete requests, and keep a record of what happened. This page explains the security controls we use today and the ones we are still building. If your team needs more information for a security review, email security@keepable.co.

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.

Our identity-verification provider processes the NIN check in Nigeria. The liveness check and primary application data are processed in our AWS region in Cape Town, so some personal data is processed outside Nigeria. We use a transfer mechanism permitted under section 41 of the Nigeria Data Protection Act where required. 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 documents

When a document is signed in Keepable, we return the completed agreement as a PDF called a covenant. The PDF carries a PAdES advanced electronic signature.

The signing certificate chains to a private certificate authority in our AWS account. AWS KMS holds the signing key, which never leaves KMS. Keepable’s verifier trusts only the authenticated private root and the document-signing certificates we currently authorise. It does not trust a certificate merely because the PDF contains it.

The PDF records the organisation and when Keepable accepted its send action. That is not necessarily when the PDF was generated. Other PDF-signature tools must be configured to trust our private root.

Identity and authentication

  • Passkeys (WebAuthn) are the main sign-in method for recipients. A passkey uses a fingerprint, face or device PIN. We do not use SMS one-time passwords because SMS codes are vulnerable to SIM-swap fraud.
  • Identity binding. An accredited provider checks each National Identification Number (NIN) during onboarding. A liveness check confirms the person is present. We do not retain the raw NIN after the check. We retain a keyed one-way hash (HMAC), with its key stored separately, so the database alone cannot reveal 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.

Separate systems and access

The recipient app, Keepable Workspace, and staff tools run as separate applications. They use separate authentication, sessions, and cloud identities. An organisation cannot view a person’s mailbox activity; one person cannot see another person’s data; and a staff console operator cannot read mailbox contents without using an explicit, audit-logged emergency-access process.

Workspace single sign-on runs on self-hosted, open-source software inside our own AWS account, so organisation credentials are not 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 action that changes a Keepable record is added to an append-only log. We compute hourly Merkle roots over the log and anchor them to S3 Object Lock. A person verifying a sealed document can use this record to confirm that the audit chain has not been rewritten.

Backups and recovery

We create daily encrypted backups of the relational database and document store, retained on a seven-day cycle. We test our recovery procedures regularly.

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: 13 September 2026.