DiraOne Data Protection

1. Our Data Protection Framework

DiraOne is designed to support compliance with applicable data-protection requirements, including the Kenya Data Protection Act, 2019 and applicable regulations.

Our data-protection approach follows core principles including:

Lawfulness, fairness and transparency

Personal data should be processed only for a lawful and clearly understood purpose.

Purpose limitation

Information collected or received for governance should not be repurposed indiscriminately.

Data minimisation

DiraOne should process only the information reasonably required for the relevant governance, security, service or contractual purpose.

Accuracy

Personal and institutional information should be kept accurate and, where appropriate, current.

Storage limitation

Personal data should not be retained indefinitely without an appropriate institutional, legal, regulatory, audit or contractual reason.

Integrity and confidentiality

Personal and confidential information should be protected against unauthorised access, disclosure, alteration, destruction or loss.

Accountability

Data protection should be demonstrable through controls, policies, permissions, records and audit trails.

These principles reflect the requirements of Kenya’s data-protection framework.

2. Controller and Processor Responsibilities

DiraOne serves institutions rather than taking ownership of their governance information.

The institution

For governance information processed through DiraOne, the subscribing institution will ordinarily act as the Data Controller.

The institution determines matters such as:

• why personal data is processed;
• authorised governance roles;
• Board and committee access;
• applicable retention periods;
• governance classifications;
• lawful processing purposes;
• which institutional systems may connect to DiraOne; and
• which external auditors or reviewers may receive authorised access.

ABNO Softwares

ABNO Softwares, as the provider of DiraOne, will ordinarily act as the Data Processor for institutional governance information.

We process such information to deliver DiraOne and in accordance with:

• the institution’s documented instructions;
• applicable contractual terms;
• applicable data-protection law; and
• DiraOne security and data-protection controls.

ABNO Softwares may separately act as a Data Controller for limited information processed for its own purposes, such as website enquiries, billing, commercial relationships, platform security and permitted service communications.

Under Kenyan data-protection guidance, a controller determines the purpose and means of processing while a processor processes personal data on the controller’s behalf.

3. Institutional Data Ownership

Your governance records remain your institution’s records.

DiraOne does not claim ownership of an institution’s:

• Board papers;
• Council papers;
• minutes;
• resolutions;
• committee records;
• audit information;
• performance records;
• risk records;
• evidence;
• governance documents; or
• institutional information received through approved integrations.

The institution remains responsible for its records subject to applicable law, retention requirements and contractual arrangements.

Where an institution leaves DiraOne, appropriate governed export and exit arrangements may be provided under the applicable agreement.

DiraOne should strengthen institutional continuity—not create artificial data lock-in.

4. Independent by Design

DiraOne is an independent governance platform.

It may integrate with:

• Intellimis;
• ABN Unisol;
• Genesis;
• Jiunge;
• Mteja360;
• MtejaFlow;
• Delytt;
• Nuru365;
• SAP;
• Oracle;
• Microsoft Dynamics;
• Sage;
• Odoo;
• document repositories;
• data warehouses; and
• other authorised systems.

However, sensitive DiraOne governance content is not administered through those operational systems.

This separation is deliberate.

Our trust principle

Nobody should gain access to confidential Board information merely because they administer the institution’s ERP, network or cloud environment.

5. One Identity Does Not Mean Shared Access

My Dira allows a member to use one identity across several authorised Board, Council or committee appointments.

For example, a person may serve on three different institutional Boards and access all three through My Dira.

That convenience does not merge those institutions.

Each institution remains separately protected.

Access can be evaluated according to:

• institution;
• Board or Council;
• committee;
• verified appointment;
• role;
• appointment dates;
• committee-assignment dates;
• meeting;
• agenda item;
• document;
• information classification; and
• specifically delegated rights.

A user’s membership of one Board does not give access to another.

A user’s role in one committee does not automatically provide access to another committee.

A County or Regional Director serving on several Boards does not automatically receive portfolio-wide oversight rights merely because of those appointments.

6. Effective-Dated Access

Governance appointments change.

DiraOne is designed so that access can change with them.

Where configured appropriately:

• access begins according to the authorised appointment or assignment date;
• committee access follows the applicable committee term;
• future access ends when the relevant appointment ends;
• historical participation remains accurately recorded;
• expired access does not erase legitimate governance history; and
• reappointment does not require rewriting previous records.

This helps institutions protect current information while preserving accurate institutional memory.

7. Governance-Controlled Access

The right to administer technology is not the same as the right to see governance content.

DiraOne separates:

Platform administration

Technical functions required to operate the service.

Institution administration

Configuration of the institution’s authorised DiraOne environment.

Governance authority

Authority to grant access to confidential governance information.

Member access

Access arising from an authorised Board or committee appointment.

External assurance access

Specific access granted to auditors, regulators or reviewers.

Authorised governance officers determine access to institutional governance content according to the institution’s governance structure.

ICT teams may support:

• connectivity;
• devices;
• identity integration;
• SSO;
• networking; and

system integrations

without automatically gaining access to confidential Board papers.

8. Least Privilege

Access should be limited to what a person reasonably requires to perform an authorised role.

DiraOne’s access-control model is intended to support:

• role-based permissions;
• appointment-based permissions;
• committee-level restrictions;
• meeting-level restrictions;
• agenda-level restrictions;
• document classification;
• temporary access;
• read-only access;
• restricted downloads;
• restricted exports; and
• additional controls for highly sensitive information.

Where a user no longer requires access, that access should be removed or expire.

9. Information Classification

Not every Board document carries the same sensitivity.

DiraOne may allow institutions to classify information using categories such as:

General Board

Committee Restricted

Confidential

Highly Confidential

Chair and Secretary Only

In-camera

Legal Privilege

Whistle-blower Protected

The institution determines the classification appropriate to its governance framework.

Classification may influence:

• who can access the material;
• whether it may be downloaded;
• whether it may be printed;
• whether it appears in search;
• whether it is available offline;
• whether additional authentication is required; and
• how it is retained.

10. Authentication

DiraOne is designed to provide strong security without forcing Board members through unnecessarily complex processes.

Controls may include:

• passwordless authentication;
• multi-factor authentication;
• secure one-time codes;
• trusted-device controls;
• biometric or device-based authentication where supported;
• secure sessions;
• session expiry;
• suspicious-sign-in detection; and
• step-up authentication for sensitive actions.

A member may therefore access ordinary authorised information easily while being asked for additional verification before particularly sensitive actions.

11. Encryption

DiraOne is designed to protect information:

In transit

Connections to DiraOne should use encrypted communication protocols.

At rest

Stored information should be protected using appropriate encryption and infrastructure safeguards.

Encryption is one part of a wider security model that also includes access control, monitoring, audit trails, backup, secure development and incident response.

12. Tenant Isolation

Each DiraOne institution operates within a logically isolated tenant environment.

Tenant separation applies not only to ordinary records but should also extend, as appropriate, to:

• documents;
• governance data;
• permissions;
• search;
• audit records;
• cached information;
• integration credentials;
• AI context; and
• institution-specific configurations.

DiraOne should never use one institution’s confidential governance content to serve another institution.

13. Private Member Notes

Members may need to annotate Board papers for their own preparation.

DiraOne treats private member notes as a distinct category.

A private note should remain visible only to the member who created it unless that member deliberately turns it into an authorised:

• question;
• comment;
• amendment;
• clarification request; or
• other formal contribution.

A Secretary, ICT administrator, fellow member or ordinary support user should not automatically see another member’s private notes.

14. Secure Board Packs and Governance Records

Governance records should not change silently.

DiraOne therefore uses version and history controls intended to preserve the integrity of important records.

This may include:

• certified Board packs;
• minutes;
• resolutions;
• voting records;
• declarations;
• appointment records;
• audit evidence;
• action evidence; and
• approved governance documents.

A certified Board pack preserves the information that was actually before the Board when a decision was made, even where live source-system information later changes.

15. Institutional Integrations

DiraOne connects governance to institutional truth without becoming another operational ERP.

Where practical, integrations should follow principles such as:

• least-privilege service accounts;
• read-only access where appropriate;
• secure APIs;
• controlled webhooks;
• encrypted connections;
• explicit authorisation;
• monitored synchronisation;
• defined data ownership;
• limited data scope; and
• visible integration health.

Unrestricted direct database access should not be the default integration model.

DiraOne should receive the information required for governance rather than unnecessarily replicate entire operational systems.

16. Data Minimisation in Board Intelligence

A Board frequently needs an answer, not an operational database.

For example, a Board member may need to know:

“How many active students do we have?”

DiraOne may obtain an authorised, source-defined answer without exposing every student record to every Board member.

Where possible, governance intelligence should therefore use:

• aggregates;
• summaries;
• trends;
• exceptions;
• reconciled indicators;
• certified snapshots; or
• appropriately limited supporting evidence.

Detailed personal information should be exposed only where the governance purpose and authorised role require it.

17. DiraOne Audit Room

External auditors and reviewers should receive the evidence they need—not unrestricted access to the institution.

DiraOne Audit Room is designed around controlled external access.

An Audit Room invitation may define:

• audit or review purpose;
• relevant financial year;
• evidence category;
• finding;
• committee;
• request scope;
• start date;
• expiry date;
• download rights;
• print rights; and
• other restrictions.

Audit Room access is intended to be:

• specifically authorised;
• read-only by default;
• time-bound;
• auditable; and
• automatically withdrawn when the approved period ends.

External auditors do not receive ordinary institution-administration rights simply because they are conducting an audit.

18. Dira Assistant and Personal Data

Dira Assistant is permission-aware.

AI does not become a shortcut around DiraOne’s data-protection controls.

Dira Assistant may use information you are already authorised to access to assist with activities such as:

• summarising papers;
• explaining complex information;
• comparing versions;
• identifying inconsistencies;
• answering source-backed questions;
• highlighting overdue actions;
• preparing draft governance outputs; and
• identifying possible gaps.

Dira Assistant must not:

• bypass permissions;
• expose another institution’s confidential information;
• vote for a member;
• approve a decision;
• grant permissions;
• declare a conflict on someone’s behalf;
• independently close an audit finding; or
• turn generated content into an authoritative Board decision without the appropriate human process.

Where third-party AI technology is used, appropriate processor/subprocessor controls should apply.

19. Support Access

DiraOne does not rely on standing vendor access to confidential customer content.

Where technical support requires access to protected institutional information, the expected workflow is:

1. Request

A specific technical problem is identified.

2. Authorise

An authorised institutional governance officer determines whether protected access is necessary.

3. Limit

Access is restricted according to:

• institution;
• purpose;
• function;
• required data;
• authorised support personnel; and
• time period.

4. Record

Support activity is logged.

5. Expire

Temporary access ends when the approved period ends or the issue is resolved.

This approach is designed to ensure support solves problems without becoming a permanent confidentiality risk.

20. Break-Glass Access

Exceptional circumstances may require emergency access to protect service continuity or address a critical security incident.

Such access should be exceptional rather than routine.

Where implemented, break-glass controls should include:

• a recorded reason;
• an authorised person;
• defined scope;
• limited duration;
• logging;
• appropriate notification;
• automatic expiry; and
• post-access review.

21. Audit Trails

Important actions in DiraOne should generate appropriate records.

Depending on the function, logs may include:

• sign-ins;
• access attempts;
• document access;
• permission changes;
• meeting activity;
• votes;
• approvals;
• declarations;
• exports;
• downloads;
• support access;
• administrative changes; and
• other security-relevant events.

Audit logs help institutions investigate incidents, support accountability and preserve governance history.

22. Data Retention

Different records require different retention periods.

Retention should therefore be based on factors including:

• applicable law;
• institutional policy;
• governing instruments;
• audit obligations;
• contractual obligations;
• regulatory requirements;
• litigation or investigation requirements; and
• legitimate governance-record requirements.

DiraOne supports the principle that personal data should not be retained longer than necessary for its lawful purpose. Kenya’s ODPC identifies data-retention policies as an important part of organisational compliance.

Ending a Board member’s term does not automatically require deletion of accurate historical records such as:

• attendance;
• resolutions;
• conflicts;
• votes;
• approved minutes; or
• appointment history.

These records may remain necessary as part of the institution’s official governance history.

23. Secure Deletion and Disposal

Where personal data no longer has a lawful or legitimate retention requirement, it should be securely deleted, anonymised or otherwise disposed of according to the applicable retention framework.

Deletion processes should consider:

• primary databases;
• document stores;
• archives;
• backups;
• temporary files;
• exports; and
• appropriate third-party systems.

Backup deletion may follow controlled backup-retention schedules rather than immediate removal from every recovery copy.

24. Backups and Continuity

DiraOne’s managed-service controls should include appropriate:

• backups;
• backup monitoring;
• restoration testing;
• continuity procedures;
• incident recovery;
• availability monitoring; and
• recovery processes.

Backup access should be appropriately restricted and protected.

Backups are for resilience and recovery—not an alternative means of accessing expired or unauthorised information.

25. Security Monitoring

DiraOne may process security and technical information to help protect the service.

This may include:

• IP addresses;
• session activity;
• authentication events;
• failed login attempts;
• unusual activity;
• system logs;
• device information;
• infrastructure events; and
• security alerts.

Such information should be used for legitimate security, fraud-prevention, troubleshooting and service-protection purposes.

26. Data Protection Impact Assessments

Where planned processing is likely to create a high risk to the rights and freedoms of individuals, an appropriate Data Protection Impact Assessment (DPIA) should be considered or undertaken before the processing begins.

A DPIA evaluates matters such as:

• the intended processing;
• necessity and proportionality;
• risks to individuals;
• privacy implications;
• security controls; and
• measures to reduce identified risks.

Kenya’s Data Protection Act requires a DPIA for processing likely to result in high risk to data subjects and specifies the core matters such an assessment should cover.

DiraOne’s architecture should support institutions in carrying out their own DPIAs where their proposed use of the platform requires one.

27. Personal Data Breaches

A personal-data breach may include unauthorised:

• access;
• acquisition;
• disclosure;
• alteration;
• destruction; or
• loss of personal data.

DiraOne maintains incident-response processes intended to support:

• detection;
• containment;
• assessment;
• investigation;
• remediation;
• documentation;
• customer notification; and
• regulatory response where applicable.

Under Kenya’s Data Protection Act, where the statutory conditions are met, a controller must notify the Data Commissioner within 72 hours of becoming aware of a qualifying breach. A processor must notify the controller without delay and, where reasonably practicable, within 48 hours of becoming aware of the breach.

Where ABNO Softwares acts as the processor, we will support the relevant controller in meeting applicable breach-response obligations.

28. International Transfers

DiraOne may use infrastructure or authorised subprocessors located outside Kenya.

Where personal data is transferred internationally, appropriate safeguards must be applied in accordance with applicable law.

Depending on the circumstances, safeguards may include:

• contractual protection;
• assessment of the recipient jurisdiction;
• approved transfer mechanisms;
• technical safeguards;
• encryption;
• access restrictions; and
• other legally recognised measures.

Kenya’s data-protection framework requires appropriate safeguards for transfers of personal data outside Kenya.

Where an institution requires a particular hosting location or dedicated environment, this may be addressed through the applicable DiraOne commercial and technical arrangement.

29. Subprocessors

ABNO Softwares may use specialised service providers to operate DiraOne.

Depending on the deployed architecture, these may include providers supporting:

• cloud hosting;
• email delivery;
• authentication;
• monitoring;
• backups;
• communications;
• payments;
• customer support;
• security; and
• AI functionality.

Subprocessors should receive only the information required for their authorised service and be subject to appropriate data-protection and confidentiality obligations.

DiraOne intends to maintain a current Subprocessor List through its Trust Centre or another appropriate customer channel.

A subprocessor does not receive governance authority merely because it provides infrastructure or a technical service.

30. Data Sharing

Routine disclosure of personal data to another organisation should have:

• a clear purpose;
• an appropriate lawful basis;
• defined data;
• authorised recipients;
• suitable confidentiality measures;
• relevant security safeguards; and
• appropriate contractual or data-sharing terms where required.

The ODPC identifies data-sharing agreements as an important control for regular sharing of personal data.

31. Data Subject Rights

Depending on applicable law and the particular circumstances, individuals may have rights relating to their personal data, including rights to:

• be informed about how their data is used;
• access their personal data;
• object to certain processing;
• correct inaccurate or misleading information;
• request erasure where legally applicable;
• request eligible data portability; and
• receive protections relating to certain automated decision-making.

The ODPC recognises these rights within Kenya’s data-protection framework.

Rights are subject to lawful limitations.

For example, exercising a privacy right does not necessarily permit alteration or deletion of an accurate official Board resolution or other governance record that an institution is legally required to preserve.

32. Children’s and Learner Data

DiraOne is not designed as a student-management system.

However, institutions in education may connect operational systems containing student or trainee information.

Where governance requires information relating to learners:

• only information required for the governance purpose should be presented;
• aggregation should be preferred where detailed identities are unnecessary;
• access should be appropriately restricted;
• sensitive information should receive enhanced protection; and
• the institution remains responsible for establishing the appropriate lawful basis for the processing.

A Board seeking an enrolment total generally does not need access to every learner’s personal record.

33. Privacy by Design

New DiraOne functionality should consider privacy and data protection from the design stage.

Product reviews should consider questions such as:

Is this information actually needed?

Can the same purpose be achieved with less personal data?

Who should see it?

How long should it remain available?

Does the user understand what is happening?

Can access expire automatically?

Does the action need stronger authentication?

Is the activity auditable?

Does the feature introduce cross-tenant risk?

Does AI introduce additional privacy risk?

Is a DPIA appropriate?

Privacy should be part of product engineering rather than a check performed only after development.

34. Secure Development

DiraOne’s engineering lifecycle should incorporate appropriate security practices across:

Design → Build → Test → Secure → Deploy → Monitor → Improve

Controls should include, as appropriate:

• access-control reviews;
• secure coding;
• code review;
• dependency management;
• automated testing;
• vulnerability management;
• secrets management;
• environment separation;
• deployment controls;
• logging;
• monitoring; and
• remediation.

No security control is treated as permanently complete.

Protection must evolve with the platform, threats and regulatory environment.

35. Data Protection Governance

DiraOne’s data-protection programme should include appropriate:

• data-protection policies;
• retention policies;
• processing records;
• processor agreements;
• subprocessor governance;
• security controls;
• incident-response procedures;
• DPIAs where appropriate;
• training;
• access reviews;
• audit records; and
• periodic compliance review.

ABNO Softwares will assess its controller/processor obligations according to applicable law and the services it provides.

36. Customer Responsibilities

Data protection is shared.

Institutions using DiraOne are responsible for matters within their control, including:

• establishing appropriate lawful bases for institutional processing;
• maintaining accurate member and appointment information;
• granting access only to authorised users;
• removing inappropriate access;
• classifying information properly;
• determining appropriate retention periods;
• protecting user devices;
• maintaining internal governance procedures;
• ensuring connected systems are appropriately authorised;
• responding to data-subject requests where they are the controller; and
• notifying DiraOne of suspected security incidents affecting the service.

DiraOne provides controls.

The institution determines how those controls are lawfully applied to its governance environment.

37. What DiraOne Does Not Claim

DiraOne provides technology and controls designed to support strong governance and data protection.

Using DiraOne does not, by itself:

• certify an institution as compliant with the Data Protection Act;
• replace the institution’s Data Protection Officer or privacy adviser;
• replace legal advice;
• replace regulatory interpretation;
• replace internal governance responsibility; or
• remove the institution’s obligations as Data Controller.

Compliance depends on technology, people, policies, lawful processing and continuing institutional oversight.

38. Our Data Protection Promise

Protect access, not just files.

DiraOne’s approach can be summarised in six commitments:

1. Institutional ownership Your institution remains in control of its governance records.

2. Governance-controlled access Technology administration alone does not unlock the Boardroom.

3. Institutional separation One identity does not mix information from different institutions.

4. Minimum necessary access Users receive the information required for their authorised responsibilities.

5. Accountable support Support access is not permanent; sensitive access should be authorised, restricted and logged.

6. Human authority AI assists authorised people without overriding governance or privacy controls.

39. Questions About Data Protection

For questions about DiraOne’s data-protection practices:

DiraOne Data Protection Contact
ABNO Softwares Ltd
Email: info@abnosoftwares.com
Website: diraone.com

Where your request concerns governance records held by an institution using DiraOne, that institution may be the appropriate Data Controller and primary point of contact.

You may also have the right to contact the Office of the Data Protection Commissioner (ODPC) or another applicable supervisory authority.

DiraOne

The Independent Governance Operating System

One trusted place for every decision.

Data protection by design. Governance by authority.