EDMS Requirements Checklist for Kenyan Organisations

An electronic document management system should be evaluated against the work your organisation actually performs, not a list of impressive feature names. This checklist helps Kenyan records officers, IT teams and departmental owners turn a document lifecycle into observable acceptance tests.

It complements our general DMS selection guide: that guide frames the selection decision; this one provides evidence to collect during a pilot. The tests below are vendor-neutral requirements, not a claim that every system—or every Dockria configuration—passes them.

Start with a small, representative test pack

Use fictional documents: a scanned letter, a revised agreement, a confidential personnel record and a completed approval. Include an unreadable page and an intentionally duplicated reference. Avoid placing live personal data in a demonstration environment.

For each requirement, record the business owner, priority (mandatory or desirable), expected result, observed result, evidence reference and unresolved issue. Mark it Pass, Partial, Fail or Not tested. A presentation is not a pass; an observed result with an accountable reviewer is.

1. Capture and classify without losing context

• Capture: import the test pack from the channels your team uses. Reconcile the original count with accepted, rejected and duplicate files. Ask how failed imports are retried without creating extra records.
• Quality: inspect page order, legibility and missing pages. Test whether low-quality scans are flagged for human correction rather than treated as reliable text.
• Classification: require a document type, reference, owner and relevant event date. Submit a record with a missing required field and a duplicate identifier; record what happens.
• Provenance: keep the source location, capture date and quality-check decision. Establish which copy is authoritative before migrating.

For scanning preparation rather than system evaluation, use the paper-record digitisation guide. A successful import is not permission to destroy the original.

2. Prove permissions with allowed and denied actions

Create a records officer, departmental reviewer and unrelated employee. Define what each may read, change, download, share and delete. Test direct links and search results as well as folder navigation: a restricted record’s title or search snippet can itself reveal personal information.

• Attempt each action as both an authorised and unauthorised role, including access to older versions.
• Change a user’s department and remove access. Check existing sessions and previously created share links.
• Document administrator privileges and the process for approving exceptional access. Ask how leavers and temporary delegates are handled.

The legal baseline is not a particular software badge. Data Protection Act sections 25, 30 and 41 address processing principles, lawful processing and protection by design/default. Translate the applicable duties into controls your privacy and security owners can inspect.

3. Retrieve the right document and the right version

Find the same record by reference, document type, date and a phrase inside a scan. Include similar names and changed filenames. Agree acceptable retrieval behaviour for your own test collection; do not accept a performance promise without the collection size and test conditions.

Upload a correction, identify the current approved version and retrieve an earlier version with its history. Try simultaneous edits. Confirm how conflicts are resolved and whether approval applies to the exact version that will be issued.

4. Test approvals, sharing and evidence together

• Route a draft through review, rejection, correction and approval. Check what each role can do in each state.
• Test an absent approver and an unauthorised attempt to bypass the route. Record the escalation or delegation procedure.
• Create an external share, then expire or revoke it. Check whether download is permitted and what happens to copies already downloaded.
• Inspect the activity record for the actor, action, time and affected version. Export evidence and check who can access or alter it.

A revoked link cannot recall a file already copied elsewhere. Treat recipient checks, purpose and onward-sharing rules as part of the process, not merely a link setting.

5. Exercise retention, preservation and disposal safely

Attach an approved rule to a fictional record class. Identify the event that starts the period, how missing dates are handled and who approves exceptions. On test records, simulate a due review, a preservation hold, release of that hold and an authorised disposition decision.

Ask the supplier to distinguish archive, reversible deletion and permanent disposal. Inspect the evidence left behind, the effect on versions and indexes, and the documented treatment of backups. Do not enable irreversible automation until the rule and authority are confirmed.

General Regulations, regulation 19 requires a personal-data retention schedule and periodic review. It does not supply one period for every file. Our Kenyan retention and disposal guide separates the legal questions from the configuration questions.

6. Verify recovery, migration and exit

• Ask for a recovery demonstration and evidence of restore testing. Check that permissions, versions and metadata survive—not just document bytes.
• Export a representative collection with metadata, relationships and available history. Open it independently and reconcile counts and identifiers.
• Document data locations, support access, subprocessors and the applicable transfer safeguards. A location claim alone does not establish compliance.
• Assign ownership of training, incident escalation, configuration changes and periodic access reviews. Confirm any integration through an actual agreed test, not a logo on a slide.

A worked acceptance entry

Illustrative requirement R-07: only registry staff may retrieve a confidential file. Owner: registry lead. Priority: mandatory. Test: a registry user opens it, an unrelated user searches its reference and follows its direct link. Expected: the registry user can read it; the unrelated user cannot see its content or restricted metadata. Evidence: test identities, configuration, observed results and activity export. Decision: unresolved until both positive and negative tests pass.

This example is a test design, not a reported customer result. A partial result should have an owner and a retest condition; it should not disappear into an overall score that hides a mandatory failure.

Where Dockria fits—and what to verify

Dockria’s supplied Help Center Guide documents role-based permissions, search and audit logs. Use these as starting points for a demonstration, not substitutes for the tests above. The organisation remains responsible for its lawful processing, approved rules and operating procedures.

To run these tests against Dockria, use our EDMS evaluation checklist, which lists what to ask to see for each area, and the illustrative review walkthrough for one configured approval and rejection path.

Primary sources

• Kenya Data Protection Act, 2019 — sections 25, 30, 39 and 41.
• Data Protection (General) Regulations, 2021 — regulation 19 (retention schedule and review).