Skip to content
Personal record cards passing through access, retention, transfer and deletion gates with locks and a review checklist

Before a Kenyan Portal Goes Live: 14 Privacy Questions

Avidni Editorial Team / Portals14 min read.

A portal concentrates identity, documents, decisions and activity in one service. These questions help product, legal, security and operational owners expose privacy gaps before real people and real records enter the system.

Kenya's Data Protection Act, 2019 establishes principles, rights and obligations for personal data processing. The Office of the Data Protection Commissioner guidance provides additional materials for controllers and processors. Use those primary sources and applicable sector rules when turning the questions below into acceptance criteria.

1. What specific purpose requires each data field?

Create a field-level inventory covering registration, profile, forms, documents, messages, analytics and audit records. For every item, name the purpose, lawful basis, owner and consequence of not collecting it. Remove fields retained only because they might be useful later. A clear purpose is also the foundation for a useful privacy notice and retention decision.

2. Who is the controller, and which parties are processors?

Name the legal entity deciding why and how data is processed. List hosting, messaging, analytics, identity, support and other providers that process data on its behalf. Record contracts, instructions, security expectations, subprocessors, deletion duties and the owner who reviews changes.

3. What lawful basis applies to each purpose?

Do not use one blanket answer for account administration, service delivery, fraud prevention, analytics and marketing. Document the basis for each purpose and have it reviewed. Where the basis is consent, make the choice specific, informed, recorded and as easy to withdraw as to give.

4. Does the person understand what will happen?

Place concise information at the moment it matters, with a fuller notice available. Explain the controller, purpose, required and optional fields, recipients, retention, rights and contact route in plain language. Test the notice with representative users instead of treating acceptance of long terms as proof of understanding.

5. Are children or other vulnerable people expected to use it?

Identify age and vulnerability risks during discovery. Decide whether access should be prevented, supported through a guardian, or designed with additional protections. Avoid collecting age or identity evidence unless the need, method, retention and safeguards are justified.

6. Can every role see only what it needs?

Test access at organisation, record and field level. Include administrators, support staff, reviewers, clients, delegated users and former users. Enforce authorisation on the server for every read, update, download and export. Attempt cross-account access directly, not only through visible buttons. Review privileged access and emergency access separately.

7. How are identity and account recovery verified?

Balance recovery with the sensitivity of the account. Define enrolment, authentication, device or factor changes, locked accounts and support-assisted recovery. Avoid security questions based on discoverable facts. Notify people of material account changes and protect support staff from pressure to bypass the process.

8. Where does the data travel and stay?

Map the browser, application, database, file storage, backups, logs, notifications, support tools and every external integration. Identify countries and providers involved. Have counsel or the data protection lead assess cross-border transfer requirements and safeguards. Keep the map current as vendors and features change.

9. How long is each record retained?

Set retention by record class and purpose, not one indefinite period for the whole portal. Cover active accounts, rejected applications, uploaded documents, messages, audit logs, support records and backups. Define the event that starts the period, legal holds, deletion method, backup expiry and evidence that the schedule runs.

10. Can people exercise their data rights in practice?

Provide a discoverable request route and an internal workflow to verify the requester, locate records across systems, review exemptions, respond securely and record completion. Test access, correction, objection, restriction, portability or deletion scenarios that apply. A notice that names rights without an operating process is incomplete.

11. Are automated decisions explainable and reviewable?

Identify scoring, eligibility, routing or prioritisation that materially affects a person. Record the data and rules involved, quality checks, bias risks, explanation shown and route to meaningful human review. Do not allow an opaque integration to become the final authority because it is convenient.

12. What appears in logs, analytics and support tools?

Logs need enough detail to investigate failures and misuse, but should not become an uncontrolled copy of form contents, tokens or documents. Redact secrets and sensitive fields, restrict access, set retention and record administrative actions. Configure analytics so collection matches the disclosed purpose and consent approach.

13. Is a data protection impact assessment required?

Screen the portal for high-risk processing, including sensitive data, systematic monitoring, large-scale processing, vulnerable people, new technology or consequential decisions. If an assessment is required or prudent, complete it while design choices can still change. Record risks, mitigations, residual risk, approval and review triggers.

14. What happens when data is exposed, lost or unavailable?

Define detection, containment, evidence preservation, impact assessment, decision authority, provider coordination, communication and recovery. Keep contacts and procedures outside the affected portal. Exercise a realistic incident scenario and verify that the team can identify affected records and people without reconstructing the system under pressure.

Turn the answers into launch evidence

  1. Approved data inventory and purpose map.
  2. Role and permission test results.
  3. Current processor and data-flow register.
  4. Reviewed notices and consent records where applicable.
  5. Retention schedule with tested deletion jobs.
  6. Rights-request procedure and exercise result.
  7. Impact-assessment decision and completed assessment where required.
  8. Incident exercise record and open actions.
  9. Named product, privacy, security and operational owners.

Avidni's client portal service brings workflow, privacy, permissions and operating evidence into the design before launch.

Review a Portal Concept

Build the website or system your next stage needs.

Strategy, Delivery and Ownership in one accountable process.

Bring the brief, the challenge or simply the outcome you need. Avidni will shape it into a clear delivery plan for a business website, e-commerce store, client portal or automated workflow. You will know what is being built, who owns each decision and what happens after launch, with ongoing care available where it adds real value.

Start a Project