How Edict keeps one institution's documents away from another's

This page describes the controls we operate and the commitments we are prepared to put in writing. Implementation specifics — architecture, configuration and thresholds — are shared with your security team under NDA rather than published here.

Tenant isolation

Every institution's records are logically separated from every other's. Separation is enforced at the data layer, beneath the application, so that a request which does not carry a valid institution context returns nothing at all — it does not fall back to returning everything. Application-level checks run on top of that as a second, independent layer.

Institutions whose procurement policy requires physical rather than logical separation can be provisioned on dedicated infrastructure, in a region they specify, with an independent backup schedule. The isolation controls above remain in force there as defence in depth.

How a request is attributed to your institution

Institution context is established on every request from the domain it arrives on, the credential it presents, or the authenticated session it belongs to. Custom domains and their certificates are managed for you.

Files and documents

Uploaded files and generated documents are held in access-controlled storage, partitioned per institution, with paths constructed and validated centrally rather than assembled by individual features. Files are not publicly addressable; access is granted per request against the requesting user's permissions.

Encryption

Encrypted in transit and at rest. Sensitive personal fields — identity numbers, contact details — carry an additional layer of application-level encryption so they are not readable from the underlying store alone.

Authentication and access

Sessions are short-lived and refreshed rather than long-lived. Two-factor authentication is supported using standard authenticator apps. Passwords are subject to a length and complexity policy, checked against known-breached credentials, and stored only in hashed form using a current, deliberately slow algorithm.

Roles and permissions are configurable per institution, so that preparing a document and issuing one can be held by different people.

Authorisation of issued documents

Issuing is an attributable act, not a rubber stamp. Each signing officer holds a personal credential known only to them, stored only in hashed form. Repeated failed attempts lock that officer's signing capability for a period and record the failure. The credential can be revoked and reissued, and authorising is a separate permission from document processing.

Each issued document carries the authorised signature block from your institution's settings, and a cryptographic hash of the exact issued file is stored against the record. Any alteration to that file after issuance is therefore detectable.

What this is not:Edict does not currently issue certificates from a certificate authority, and does not apply PAdES or PKI cryptographic signatures. What it provides is attributed authorisation plus tamper-evidence. We would rather state that precisely than let the word "signed" do more work than it should.

Audit logging

An append-only log records stage transitions, document generation, authorisation, revocation, annulment, amendment, permission changes, failed authorisation attempts and verification queries — each with the actor and a timestamp. Entries cannot be edited or removed through the application.

Abuse and rate limiting

Public verification is rate-limited per source and returns only the minimum a verifier needs. Programmatic verification is rate-limited per credential, at a level set by your plan. Thresholds are not published, and are tuned rather than fixed.

Identity verification

Institution onboarding includes a business-registration check. Applicant identity verification runs through established third-party providers, with a manual review path for cases and jurisdictions without automated coverage, and optional face matching. Identity numbers are stored in a form that supports lookup without exposing the number itself.

Payments

Edict supports Paystack, Flutterwave and Remita. Where split payments are enabled, the platform fee is deducted at the gateway and settlement flows directly to your institution's own account.Edict never custodies tenant funds. Gateway credentials are held as managed secrets, never in source code or deployment images.

Data protection

Edict is built to Nigeria Data Protection Act principles: data minimisation, explicit consent capture, and a right of access. We will execute a data processing agreement with your institution.

What we do not claim yet

We hold no SOC 2 or ISO 27001 certification today. We do not operate a public status page. We have not yet completed a third-party penetration test. We have no customer logos on this site because we have not yet earned the right to display any.

When any of that changes, this page changes. We would rather you knew where we stand than discovered it during an audit.

Getting the detail

If your security team needs specifics — architecture, data flows, configuration, retention, subprocessors, or a completed security questionnaire — we provide them directly under NDA. Email [email protected] and ask for the security pack.