Business continuity anddisaster recovery.
Your Kenii site does not depend on Kenii staying online. Here is what does depend on us, what does not, and the risks we are not going to pretend away.
What is being continued
An institution’s Kenii site does not depend on Kenii staying online. The software runs inside the institution’s own content management system, on infrastructure the institution owns. If Kenii’s own services went dark, an institution’s catalog, program pages, Compass and handbook keep serving.
That is the most important continuity property of the product, and it is a consequence of the architecture rather than a promise about Kenii’s uptime.
What depends on Kenii being reachable
| Service | If unavailable |
|---|---|
| License verification | Modules keep running. Grants are cached and honored for 30 days offline. |
| Update service | Institutions cannot download a new version. Installed versions are unaffected. |
| Evaluation sandboxes | Prospective customers cannot browse a demo. No production site is affected. |
The 30-day offline grace exists so a licensing outage cannot switch off an institution’s catalog.
Institutional backups
Kenii holds no copy of institutional data, so Kenii cannot restore an institution’s site. Backup and restore of the database and files is the institution’s responsibility, usually through its hosting provider.
Kenii states this before implementation rather than after an incident, and will confirm during implementation that a backup exists and has been restored at least once.
Kenii’s own recovery
- Source code is held in version control with a remote copy. A total loss of local machines does not lose the product.
- Vendor-side services are rebuildable from that source plus configuration. Recovery objective: those services restored within five business days.
- Credentials are held in one file with an offline copy. Loss of that file without the copy would require reissuing every credential, which is the recovery path.
Key-person risk, stated honestly
Kenii is two founders and a small team. Product knowledge concentrates in one person. That is a real continuity risk to an institution, and this document names it rather than implying redundancy that does not exist.
Mitigations in place: source and documentation are in version control accessible to more than one person, and the delivered product runs without Kenii.
Testing
This plan has not yet been tested end to end. The first test is scheduled to establish whether a vendor-side service can be rebuilt from source within the stated objective, and the result will be recorded here.
Kenii will not claim a tested plan before that happens.
Your site keeps runningif we go dark.
That is architecture, not a promise. Ask for a demo and your team can verify it on infrastructure you control.