DiraOne Privacy Policy

Our Privacy Commitment

DiraOne is designed for governance information that matters.

Boards, Councils and committees may use DiraOne to work with sensitive institutional information, Board papers, decisions, actions, audit matters, risk information, performance records and other governance content.

Privacy, confidentiality and controlled access are therefore built into the way DiraOne operates.

Our core principles are simple:

• Your institution remains in control of its governance records.
• Access follows authorised roles, appointments and responsibilities.
• One identity does not mean shared access across institutions.
• Technical administration does not automatically provide access to confidential Board content.
• Personal data should only be processed for a clear and lawful purpose.
• AI should assist authorised users without bypassing privacy or governance controls.

1. About This Privacy Policy

This Privacy Policy explains how ABNO Softwares Ltd (“ABNO Softwares”, “ABNO”, “DiraOne”, “we”, “us” or “our”) collects, uses, stores, protects, shares and otherwise processes personal data in connection with DiraOne.

This Policy applies to:

• diraone.com and related DiraOne public webpages;
• institution workspaces such as {institution}.diraone.com;
• My Dira at my.diraone.com;
• the DiraOne Audit Room;
• Dira Assistant and other permission-aware AI functionality;
• DiraOne mobile, tablet and web experiences;
• approved integrations, APIs and notifications;
• Governance Readiness Assessments;
• demonstrations and Board-Cycle Pilots;
• customer onboarding;
• subscriptions and billing;
• support interactions; and
• other DiraOne services that refer to this Privacy Policy.

2. Who We Are

DiraOne is provided and operated by ABNO Softwares Ltd.

DiraOne is an independent governance operating system designed to connect Boards, Councils and committees to trusted institutional information, protected decision-making, visible accountability and institutional continuity.

ABNO Softwares Ltd is registered with the Office of the Data Protection Commissioner (ODPC) in Kenya as both a Data Controller and a Data Processor.

Registration as both reflects the fact that ABNO Softwares may perform different data-protection roles depending on the particular processing activity.

3. Our Role as Data Controller and Data Processor

The role of ABNO Softwares depends on why and how particular personal data is being processed.

3.1 When an Institution Uses DiraOne

Where an institution subscribes to DiraOne and uses the platform for its governance activities, that institution will ordinarily determine:

• why institutional personal data is processed;
• which people should have access;
• which Boards and committees exist;
• which governance records should be maintained;
• which systems should connect to DiraOne;
• applicable information classifications;
• applicable retention requirements; and
• the lawful purpose for the processing.

In this relationship:

The institution will ordinarily act as the Data Controller.

ABNO Softwares Ltd will ordinarily act as the Data Processor.

ABNO Softwares processes the institution's personal data according to:

• the institution's documented instructions;
• the applicable Data Processing Agreement;
• the institutional contract;
• applicable law; and
• DiraOne security and privacy controls.

Examples of institution-controlled data include:

• Board and Council structures;
• committee structures;
• member appointments;
• tenure information;
• Board papers;
• committee papers;
• meeting packs;
• minutes;
• declarations of interest;
• voting records;
• resolutions;
• actions;
• evidence;
• audit findings;
• risk registers;
• compliance records;
• performance information; and
• authorised information obtained from connected institutional systems.

3.2 When ABNO Softwares Acts as Data Controller

ABNO Softwares may act as the Data Controller for information that it determines how and why to process for its own legitimate purposes.

Examples include:

• website enquiries;
• Governance Readiness Assessment requests;
• demo requests;
• Board-Cycle Pilot requests;
• customer and commercial contacts;
• contractual administration;
• subscription administration;
• billing;
• customer-support administration;
• platform-security information;
• fraud and abuse prevention;
• service-performance information;
• regulatory compliance records; and
• permitted marketing communications.

The fact that ABNO Softwares is registered as both a Data Controller and a Data Processor does not mean that it acts in both capacities for every processing activity.

The relevant role depends on the particular purpose and circumstances.

4. Our Data Protection Principles

DiraOne is designed around the following principles.

Lawfulness, fairness and transparency

Personal data should only be processed where there is an appropriate lawful basis and the processing should be understandable to the people affected.

Purpose limitation

Personal data collected for a defined purpose should not be used indiscriminately for unrelated purposes.

Data minimisation

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

Accuracy

Reasonable steps should be taken to keep personal data accurate and appropriately current.

Storage limitation

Personal data should not be retained indefinitely without an appropriate legal, institutional, contractual, security, audit or governance requirement.

Integrity and confidentiality

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

Accountability

Data protection should be supported by demonstrable:

• controls;
• policies;
• audit trails;
• permissions;
• documented processing;
• contractual safeguards; and
• security practices.

5. Institutional Control

Your institution's governance records remain your institution's records.

ABNO Softwares does not claim ownership of an institution's governance information merely because that information is processed through DiraOne.

Institutional records may include:

• Board papers;
• Council papers;
• committee papers;
• minutes;
• resolutions;
• voting information;
• declarations;
• appointment records;
• action registers;
• evidence;
• audit records;
• risk records;
• performance information; and
• other governance records.

The institution remains responsible for these records subject to applicable law and contractual requirements.

6. One Identity Does Not Mean Shared Access

A member may serve on several Boards, Councils or committees.

My Dira allows that member to use one identity across authorised appointments.

This convenience does not merge institutional information.

Each institution remains separately protected.

Access may be evaluated according to:

• institution;
• Board or Council;
• committee;
• verified appointment;
• role;
• effective dates;
• meeting;
• agenda item;
• document;
• information classification; and
• specifically granted permissions.

A person's membership of one Board does not automatically provide access to another Board.

A person's role in one committee does not automatically provide access to another committee.

Serving on multiple Boards does not automatically provide cross-institution oversight rights.

7. Effective-Dated Permissions

Governance appointments change.

DiraOne is designed to support access that changes with verified governance appointments and assignments.

Where appropriately configured:

• access begins when an authorised appointment becomes effective;
• committee permissions follow committee assignments;
• future access ends when an appointment expires;
• external-review access expires at the end of its authorised period;
• historical governance records remain intact; and
• changes in leadership do not overwrite legitimate institutional history.

The end of a user's access does not necessarily require deletion of official historical records relating to that user's previous governance role.

8. Personal Data We May Process

The information processed depends on your relationship with DiraOne.

8.1 Identity and Contact Information

This may include:

• name;
• email address;
• telephone number;
• institution;
• department;
• professional title;
• professional role;
• professional contact information; and
• profile photograph where provided or required.

8.2 Governance Appointment Information

This may include:

• Board or Council appointment;
• seat or position;
• committee membership;
• chairmanship;
• Board or Council Secretariat role;
• appointment instrument;
• term start date;
• term end date;
• reappointment information;
• historical appointments;
• attendance;
• induction;
• training;
• evaluation information;
• skills information;
• declarations; and
• recusals.

8.3 Meeting and Governance Information

This may include:

• notices;
• agendas;
• meeting papers;
• Board packs;
• annexes;
• meeting attendance;
• apologies;
• comments;
• questions;
• declarations;
• conflict information;
• recusals;
• voting records;
• abstentions;
• resolutions;
• approvals;
• minutes;
• circular decisions;
• actions;
• evidence;
• progress information; and
• closure information.

Some governance information may be highly confidential.

8.4 Audit, Risk, Compliance and Performance Information

DiraOne may process authorised information relating to:

• audit plans;
• audit findings;
• management responses;
• corrective actions;
• evidence;
• risk registers;
• risk owners;
• risk-treatment plans;
• compliance obligations;
• policies;
• strategic objectives;
• performance contracts;
• performance indicators;
• targets;
• actual results;
• supporting evidence;
• variance explanations; and
• recovery actions.

8.5 Institutional Intelligence

Where authorised by the institution, DiraOne may receive governance information from connected institutional systems.

This may include information relating to:

• finance;
• students or trainees;
• admissions;
• HR;
• payroll;
• procurement;
• stores;
• assets;
• service delivery;
• customer or stakeholder experience;
• institutional performance; and
• other authorised operational information.

Where practical, DiraOne may present this information as:

• aggregates;
• summaries;
• trends;
• exceptions;
• governance indicators;
• source-linked evidence; or
• certified snapshots.

DiraOne is not intended to unnecessarily duplicate entire operational databases.

8.6 My Dira Information

My Dira may process:

• active Board and committee appointments;
• roles;
• meetings;
• papers requiring review;
• decisions requiring attention;
• actions;
• reading position;
• reviewed status;
• bookmarks;
• highlights;
• notification preferences;
• preferences; and
• private notes.

8.7 Device and Authentication Information

To operate and protect DiraOne, we may process:

• IP address;
• browser information;
• operating system;
• device type;
• session identifiers;
• login activity;
• authentication events;
• failed login attempts;
• access history;
• approximate network location;
• security events;
• technical logs; and
• device-security information where applicable.

8.8 Commercial and Support Information

This may include:

• Governance Readiness Assessment requests;
• demo requests;
• pilot requests;
• institution name;
• role;
• areas of interest;
• meeting preferences;
• subscription information;
• invoice information;
• payment-administration information;
• support requests;
• support correspondence;
• screenshots or documents supplied for support;
• diagnostic information; and
• authorised support-access records.

9. Private Member Notes

Members may annotate Board papers for their personal preparation.

DiraOne treats private member notes as a distinct category of information.

A private note should remain visible only to the member who created it unless that member deliberately converts or shares it as an authorised:

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

Ordinary institution administrators, ICT personnel, other Board members and DiraOne support personnel do not automatically receive access to a member's private notes.

10. How We Obtain Personal Data

We may receive personal data:

• directly from you;
• from the institution that appointed or employs you;
• from an authorised Board or Council Secretariat;
• from an authorised institutional administrator;
• from an approved institutional source system;
• from an authorised auditor or reviewer;
• from an authorised regulator or oversight body;
• automatically through your use of DiraOne;
• when you communicate with us; or
• from another lawful source where permitted by applicable law.

11. Why We Process Personal Data

We may process personal data to:

Provide DiraOne

Including:

• user authentication;
• governance workspaces;
• My Dira;
• meetings;
• papers;
• decisions;
• actions;
• audit;
• risk;
• compliance;
• performance;
• evidence; and
• other contracted functionality.

Maintain accurate governance records

DiraOne preserves appointment, committee, meeting, decision and accountability history so records remain reliable as leadership and Board membership change.

Protect confidential information

We process identity, role, permission, authentication and security information to ensure users access only authorised information.

Provide My Dira

We use relevant information to provide one personal governance experience across authorised appointments while preserving institutional separation.

Operate DiraOne Audit Room

We process data needed to provide evidence-specific and time-limited external assurance access.

Provide institutional intelligence

We process authorised information from connected systems to provide governance summaries, exceptions, indicators and evidence.

Operate Dira Assistant

We process authorised content to provide permission-aware AI assistance.

Provide support

We use appropriate information to diagnose and resolve service issues.

Protect DiraOne

We process technical and security information to:

• prevent abuse;
• identify unauthorised access;
• detect suspicious activity;
• investigate incidents;
• improve resilience; and
• protect customers and users.

Administer subscriptions and payments

We process information necessary to administer:

• quotations;
• subscriptions;
• invoices;
• payments; and
• customer relationships.

Communicate with you

This may include:

• secure access codes;
• meeting notifications;
• action reminders;
• security alerts;
• service notifications;
• onboarding communications;
• audit-request alerts; and
• support communications.

12. Legal Bases for Processing

Where ABNO Softwares acts as Data Controller, personal data will only be processed where an appropriate lawful basis applies.

Depending on the circumstances, this may include:

• consent;
• performance of a contract;
• steps taken before entering into a contract;
• compliance with a legal obligation;
• legitimate interests that do not override the individual's rights;
• performance of a task carried out in the public interest;
• exercise of official authority where applicable; or
• another lawful basis recognised under applicable law.

Where ABNO Softwares acts as Data Processor, the institution acting as Data Controller is ordinarily responsible for establishing the lawful basis for the processing it instructs us to perform.

Where processing is based on consent, the individual may withdraw that consent subject to applicable law.

13. Sensitive and Confidential Governance Information

DiraOne may process information that requires enhanced protection.

Institutions may classify information using categories such as:

• General Board;
• Committee Restricted;
• Confidential;
• Highly Confidential;
• Chair and Secretary Only;
• In-camera;
• Legal Privilege; and
• Whistle-blower Protected.

Classification may influence:

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

Our trust principle

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

14. Governance-Controlled Access

DiraOne distinguishes between:

Platform administration

Technical functions needed to operate DiraOne.

Institution administration

Configuration of the institution's DiraOne environment.

Governance-content authority

Authority to permit access to confidential governance information.

Member access

Access arising from an authorised governance appointment.

External assurance access

Specific access granted to an auditor, regulator or reviewer.

Technical authority alone does not create governance authority.

15. Least-Privilege Access

Access should be limited to the information reasonably required for an authorised person's responsibilities.

DiraOne may support:

• role-based permissions;
• appointment-based permissions;
• committee restrictions;
• meeting restrictions;
• agenda-level restrictions;
• information classification;
• read-only access;
• download restrictions;
• export restrictions;
• time-limited access; and
• additional controls for highly confidential material.

16. Dira Assistant and Artificial Intelligence

Dira Assistant is designed to support authorised users without taking governance authority away from people.

Dira Assistant may assist with:

• summarising papers;
• explaining complex information;
• comparing versions;
• identifying missing annexes;
• identifying inconsistent information;
• answering source-backed questions;
• preparing draft governance content;
• surfacing overdue actions;
• highlighting repeat findings;
• identifying performance exceptions; and
• suggesting questions for consideration.

Dira Assistant may only process information available within the current user's authorised context.

AI is not a shortcut around DiraOne permissions.

16.1 What Dira Assistant Must Not Do

Dira Assistant must not:

• vote on behalf of a member;
• approve on behalf of a member;
• reject on behalf of a member;
• declare a conflict on behalf of a member;
• issue an authoritative resolution without required human approval;
• grant permissions;
• bypass confidentiality controls;
• independently close audit findings;
• independently close governance actions requiring human verification; or
• expose one institution's confidential information to another institution.

AI-assisted outputs may require review by an authorised person before becoming part of an official governance record.

16.2 Third-Party AI Providers

Where third-party technology is used to provide AI functionality, appropriate:

• contractual;
• confidentiality;
• security; and
• data-protection

controls will apply.

Customer governance information will not be used to train unrelated general-purpose AI models except where this is expressly permitted by the applicable contractual arrangement and lawful basis.

17. DiraOne Audit Room

DiraOne Audit Room provides controlled external access for:

• external auditors;
• regulators;
• independent reviewers;
• assurance teams; and
• other specifically authorised persons.

An Audit Room invitation may define:

• purpose;
• audit or review;
• financial year;
• committee;
• finding;
• evidence category;
• authorised documents;
• start date;
• expiry date;
• read-only status;
• download rights; and
• print rights.

Access is designed to be time-bound and automatically or procedurally withdrawn when the authorised period ends.

External reviewers do not receive ordinary institution-administration rights merely because they have been invited to an Audit Room.

18. Institutional Integrations

DiraOne may integrate with authorised systems including:

• Intellimis;
• ABN Unisol;
• ABN Genesis;
• Jiunge;
• Mteja360;
• MtejaFlow;
• Delytt;
• Nuru365;
• External ERPs & CRMs;
• document repositories;
• data warehouses; and
• other approved systems.

Operational systems remain responsible for their underlying transactions and operational records.

DiraOne receives authorised governance information rather than automatically becoming the operational source of truth.

19. Integration Security

Where appropriate, DiraOne integrations should use:

• least-privilege access;
• read-only service accounts where possible;
• secure APIs;
• signed webhooks;
• encryption;
• monitored synchronisation;
• controlled credentials; and
• defined data scope.

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

Where a Board only requires an aggregate or governance indicator, unnecessary underlying personal records should not automatically be exposed.

20. How We Share Personal Data

We may share personal data where necessary and lawful with:

Your institution

Authorised institution personnel may receive information according to their governance roles.

Other authorised users

Board, Council, committee, management, audit, risk, compliance or other authorised users may access information within their permitted scope.

Auditors, regulators and reviewers

Authorised information may be made available through DiraOne Audit Room or another approved mechanism.

Service providers and subprocessors

We may use providers supporting areas such as:

• cloud infrastructure;
• identity;
• authentication;
• email;
• messaging;
• monitoring;
• backups;
• security;
• payment services;
• customer support; and
• AI functionality.

Professional advisers

Information may be disclosed to professional advisers where necessary and subject to appropriate confidentiality obligations.

Lawful authorities

We may disclose personal data where required by:

• applicable law;
• court order;
• regulatory requirement; or
• another lawful process.

Corporate restructuring

Personal data may be transferred in connection with a lawful merger, acquisition, restructuring or transfer of the DiraOne business subject to appropriate safeguards.

21. We Do Not Mix Institutional Governance Data

Information belonging to one institution is not made available to another institution simply because:

• both institutions use DiraOne;
• both institutions use another ABNO Softwares product;
• the same member serves on both Boards;
• both use the same cloud infrastructure;
• both are supported by ABNO Softwares; or
• the same user identity is associated with both.

Cross-institution information is only made available where a separate and appropriate oversight authority has been expressly established and authorised.

22. Service Providers and Subprocessors

ABNO Softwares may use appropriately qualified service providers to operate DiraOne.

Providers may support:

• hosting;
• storage;
• authentication;
• notifications;
• monitoring;
• security;
• backups;
• communications;
• payments;
• customer support;
• integrations; or
• AI services.

Such providers should receive only information reasonably necessary for their authorised service.

Appropriate contractual and security controls will apply.

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

Where appropriate, DiraOne may maintain a current Subprocessor List through the DiraOne Trust Centre.

23. International Data Transfers

DiraOne may use infrastructure or authorised service providers located outside Kenya.

Where personal data is transferred internationally, appropriate safeguards required under applicable law will be applied.

Depending on the circumstances, these may include:

• contractual safeguards;
• recognised transfer mechanisms;
• assessment of the recipient jurisdiction;
• encryption;
• access restrictions;
• other legally recognised safeguards; or
• consent where legally appropriate.

Where an institution requires specific hosting or localisation arrangements, these may be addressed contractually.

24. Security

DiraOne uses technical and organisational controls designed to protect personal and confidential information.

Depending on the service and applicable risk, controls may include:

• encryption in transit;
• encryption at rest;
• multi-factor authentication;
• passwordless authentication;
• device-based authentication;
• biometric authentication where supported;
• tenant isolation;
• role-based access;
• appointment-aware access;
• committee-aware access;
• agenda-level controls;
• classification-aware authorisation;
• step-up authentication;
• security monitoring;
• activity logs;
• audit trails;
• backups;
• restoration testing;
• continuity procedures;
• incident response; and
• controlled support access.

No internet-connected system can eliminate every security risk.

We continually review safeguards based on the sensitivity of the information and evolving threats.

25. Support Access

ABNO Softwares support personnel do not require permanent unrestricted access to confidential DiraOne content merely to operate the service.

Where technical access to protected customer information is necessary to resolve a particular issue, DiraOne is designed around the following process:

1. Request

The affected problem or function is identified.

2. Authorise

An authorised institution representative determines whether protected access is required.

3. Limit

Access is restricted to the required:

• institution;
• problem;
• function;
• role;
• personnel; and
• time period.

4. Record

The support access and relevant activity are logged.

5. Expire

Temporary access is withdrawn when the authorised period ends or the issue is resolved.

26. Emergency or Break-Glass Access

Exceptional circumstances may require emergency access to protect:

• service security;
• availability;
• data integrity; or
• institutional continuity.

Where implemented, break-glass access should include:

• a documented reason;
• appropriate authorisation;
• defined scope;
• limited duration;
• activity logging;
• appropriate notification;
• expiry; and
• post-access review.

Emergency access is not intended to replace normal support procedures.

27. Audit Trails

DiraOne may record significant security and governance events.

Depending on the relevant function, this may include:

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

Audit trails help preserve governance integrity, investigate incidents and demonstrate accountability.

28. Data Retention

Personal data is retained only for as long as reasonably necessary for the purpose for which it is processed, taking into account:

• applicable law;
• institutional retention policies;
• governing instruments;
• audit requirements;
• contractual requirements;
• regulatory requirements;
• legal claims;
• investigations;
• security requirements; and
• legitimate governance-record requirements.

Different types of information may therefore have different retention periods.

28.1 Historical Governance Records

Ending an appointment does not necessarily require deletion of records such as:

• attendance;
• appointments;
• minutes;
• conflicts;
• votes;
• decisions;
• resolutions; and
• evidence.

Such information may be part of the institution's legitimate or legally required governance history.

28.2 Deletion

Where personal data no longer needs to be retained, it may be:

• securely deleted;
• anonymised;
• pseudonymised; or
• otherwise disposed of

according to the applicable legal, contractual and retention framework.

Backup copies may be removed according to scheduled backup-retention cycles rather than immediately from every recovery copy.

29. Backups and Continuity

DiraOne may maintain:

• backups;
• backup monitoring;
• restore testing;
• recovery procedures;
• availability monitoring;
• incident-recovery procedures; and
• continuity controls.

Backup access is restricted according to appropriate security controls.

Backups are maintained for service resilience and recovery and are not intended to provide an alternative means of obtaining expired or unauthorised access.

30. Data Protection Impact Assessments

Where processing is likely to create a high risk to the rights and freedoms of individuals, an appropriate Data Protection Impact Assessment (DPIA) may be required.

A DPIA may consider:

• the planned processing;
• the purpose;
• necessity;
• proportionality;
• risks to individuals;
• sensitive data involved;
• security controls;
• privacy safeguards; and
• measures proposed to reduce identified risks.

Where an institution's proposed use of DiraOne requires a DPIA, ABNO Softwares may provide appropriate information about the platform to support that assessment.

The relevant Data Controller remains responsible for determining whether and how its DPIA obligations apply.

31. Personal Data Breaches

A personal data breach may involve unauthorised:

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

DiraOne maintains incident-response processes intended to support:

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

Where ABNO Softwares acts as Data Processor, we will notify the relevant Data Controller in accordance with applicable law and contractual requirements.

Where ABNO Softwares acts as Data Controller, we will assess and fulfil applicable regulatory and data-subject notification requirements.

32. Your Data Protection Rights

Subject to applicable law and lawful limitations, you may have the right to:

• be informed about how your personal data is processed;
• access personal data held about you;
• object to certain processing;
• request correction of inaccurate information;
• request deletion where legally applicable;
• restrict certain processing where applicable;
• request eligible data portability;
• withdraw consent where processing relies on consent; and
• receive protections regarding certain automated decision-making.

These rights may be subject to legitimate legal, governance, confidentiality and recordkeeping requirements.

For example, a person may not necessarily require deletion of an accurate Board resolution merely because their Board term has ended.

33. How to Exercise Your Rights

Where your request concerns governance data held through DiraOne on behalf of an institution, that institution will ordinarily be the appropriate Data Controller.

You may therefore contact the institution directly.

ABNO Softwares will support the institution in responding where required under the applicable Data Processing Agreement and law.

Where ABNO Softwares is the Data Controller for the relevant information, requests may be made through the contact details at the end of this Policy.

We may need to verify your identity before acting on a request.

Please avoid sending unnecessary confidential information when submitting a privacy request.

34. Children's and Learner Information

DiraOne is not designed as a general student-management or child-facing platform.

However, education institutions using DiraOne may connect operational systems containing information relating to students or trainees.

Where governance requires such information:

• only information appropriate to the governance purpose should be used;
• aggregation should be preferred where individual identity is unnecessary;
• access should be appropriately restricted;
• enhanced protections should be applied where required; and
• the relevant institution remains responsible for establishing the appropriate lawful basis.

For example, a Board seeking an enrolment figure will ordinarily not need unrestricted access to every learner's full personal record.

35. Marketing Communications

Where permitted by law, ABNO Softwares may send information relating to:

• DiraOne;
• governance resources;
• events;
• webinars;
• Governance Readiness Assessments;
• Board-Cycle Pilots;
• product updates; and
• related professional services.

Marketing communications will provide an appropriate method to opt out.

Opting out of marketing does not prevent necessary:

• security communications;
• account messages;
• meeting notifications;
• service notices;
• billing communications; or
• support communications.

Marketing consent will not be made a condition for receiving governance information that a person is otherwise entitled to access.

36. Cookies and Similar Technologies

DiraOne websites and services may use cookies or similar technologies for purposes such as:

• essential functionality;
• authentication;
• security;
• session management;
• preferences;
• performance measurement; and
• analytics.

Where consent is required for non-essential cookies, appropriate choices will be provided.

More information may be provided in the DiraOne Cookie Policy.

37. Third-Party Links and Services

DiraOne may contain links to:

• institutional systems;
• virtual-meeting services;
• websites;
• payment services;
• document repositories; or
• other third-party resources.

Independent third-party services may have their own privacy practices.

This Privacy Policy does not govern processing carried out by an independent third party for its own purposes.

Where ABNO Softwares appoints a third party as a DiraOne subprocessor or service provider, the applicable DiraOne contractual and data-protection controls apply.

38. Data Ownership, Portability and Exit

The subscribing institution owns its institutional governance records subject to applicable legal and contractual requirements.

DiraOne is intended to support institutional continuity rather than create artificial data lock-in.

When an institution leaves DiraOne, governed:

• export;
• archival;
• retention; and
• deletion

will be managed according to the applicable institutional agreement, Data Processing Agreement and lawful retention requirements.

Individuals may also have statutory portability rights where the legal requirements for portability are satisfied.

39. Privacy by Design

Privacy should be considered before a DiraOne feature reaches production.

When appropriate, product and engineering teams should consider:

• Is this personal data necessary?
• Can less data achieve the same purpose?
• Who should have access?
• Can access expire automatically?
• Does the user understand how their information is being used?
• How long should the information be retained?
• Does the action require stronger authentication?
• Is the activity auditable?
• Could this create cross-tenant exposure?
• Does AI introduce additional privacy risk?
• Does the processing require a DPIA?

Privacy should be an engineering requirement, not merely a legal disclaimer.

40. Secure Development

DiraOne's engineering lifecycle is intended to incorporate appropriate security and privacy controls across:

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

Controls may include:

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

41. Customer Responsibilities

Data protection is a shared responsibility.

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

• establishing lawful bases for institutional processing;
• maintaining accurate appointment records;
• determining authorised users;
• removing inappropriate access;
• classifying information appropriately;
• determining retention periods;
• maintaining internal governance procedures;
• authorising connected systems;
• protecting institution-managed devices;
• responding to data-subject requests where they are the Controller; and
• notifying DiraOne of suspected incidents that may affect the service.

DiraOne provides controls.

The institution remains responsible for using those controls appropriately.

42. What DiraOne Does Not Claim

Use of DiraOne does not by itself:

• certify an institution as compliant with the Data Protection Act;
• replace the institution's Data Protection Officer;
• replace legal advice;
• replace regulatory interpretation;
• replace professional audit advice;
• remove the institution's responsibilities as Data Controller; or
• guarantee that an institution's policies and processing practices are compliant.

Effective data protection depends on:

• appropriate technology;
• lawful processing;
• people;
• processes;
• policies;
• training;
• accountability; and
• continuing oversight.

43. Changes to This Privacy Policy

We may update this Privacy Policy to reflect:

• changes to DiraOne;
• changes in applicable law;
• regulatory guidance;
• security improvements;
• new functionality;
• changes in subprocessors; or
• changes in processing activities.

The latest version will display its effective date.

Where a change materially affects how personal data is processed, appropriate steps will be taken to notify affected institutions or users.

44. Complaints

If you have concerns about how your personal data has been processed, we encourage you to contact:

• the relevant institution where that institution is the Data Controller; or
• the DiraOne Privacy Office where ABNO Softwares is responsible for the relevant processing.

You may also have the right to complain to the appropriate data-protection authority.

In Kenya, the relevant regulator is the:

Office of the Data Protection Commissioner (ODPC).

45. Data Protection Registration

ABNO Softwares Ltd is registered with the Office of the Data Protection Commissioner in Kenya as both:

• a Data Controller; and
• a Data Processor.

These registrations reflect the different roles ABNO Softwares may perform depending on the relevant processing activity.

Registration should not be interpreted as removing any continuing obligation to comply with applicable data-protection law.

46. Contact Us

DiraOne Privacy Office

ABNO Softwares Ltd

Email: info@abnosoftwares.com

Website: diraone.com

For institution-controlled governance records, the institution using DiraOne may be the appropriate Data Controller and primary point of contact.