Security Policy

1. Our Security Commitments

Braille Link is committed to protecting the confidentiality, integrity, and availability of all data entrusted to us by our users and institutions. Our security programme is built on the following core principles:

• Defence in depth: We apply multiple layers of security controls so that no single failure exposes user data.
• Least privilege: Access to systems and data is granted only to the extent required to perform a specific function.
• Transparency: We are open about our security practices and disclose significant incidents to affected users in a timely manner.
• Honest description: This policy describes the controls that are in place today. Where a control is optional, depends on configuration, or is provided by a supplier, we say so.
• User empowerment: We provide users with the tools (MFA, passkeys, audit logs, role management) to help secure their own accounts and institutions.

2. Encryption

2.1 Encryption in Transit

Data sent between your device and the production Braille Link service travels over HTTPS using Transport Layer Security (TLS). The service sends an HTTP Strict Transport Security (HSTS) header so that browsers keep using HTTPS. Connections between our own services use TLS 1.2 or higher where they cross a network.

2.2 Encryption at Rest

The production database is a managed PostgreSQL database operated by our hosting provider, which encrypts stored database data and its backups at rest under its own platform controls. Sensitive configuration values held by the application are additionally encrypted with an application key.

Where Document Reader is enabled, extracted text and audio records are kept in the database, and generated audio files are kept on the application server's storage. Audio files may be regenerated if that storage is reset. Braille Link does not currently use a separate object-storage service.

2.3 Password Storage

Passwords are never stored in plain text. We store a salted bcrypt hash of each password. Hashing is designed to make it impractical to recover a password from the stored value, but it cannot protect a password that is short, reused, or easy to guess.

2.4 Session Tokens

Session tokens are generated with a cryptographically secure random number generator and the server keeps a hash of the session token, not the token itself. Braille Link does not currently issue customer API keys.

3. Authentication Security

3.1 Multi-Factor Authentication (MFA)

Braille Link supports multi-factor authentication using authenticator-app codes (TOTP) with backup codes. Any user can enrol in MFA through their account settings, and we strongly encourage it for administrators and other privileged roles. Requiring MFA for privileged roles is a platform setting; it is not switched on by default at present, so administrators should enrol themselves.

3.2 Passkeys and Biometrics

Braille Link supports WebAuthn passkeys, which let you sign in with your device's fingerprint, face, PIN, or a hardware security key. Passkeys resist phishing and are recommended for high-privilege accounts. Your fingerprint or face data stays on your device; we receive only public-key credential data.

3.3 Account Lockout

By default an account is locked for 15 minutes after 5 consecutive failed sign-in attempts. The lock lifts automatically when that period ends, and an administrator or our support team can help if you remain locked out. Sign-in, password-reset, and recovery requests are also rate limited.

3.4 Session Management

By default a session ends after 25 minutes without activity and after 8 hours in total. Institutions may be given different session settings. Sessions end when you sign out, and you or an administrator can revoke sessions and block devices where those controls are available to your role.

3.5 Password Policy

Standard user passwords must be at least 5 characters to keep the system usable with Braille-first input. Administrator and privileged accounts must use passwords of at least 10 characters and may be required to reset their password before elevated access is enabled. Because the standard minimum is short, we encourage every user to choose a longer password and to add MFA or a passkey.

4. Access Controls

4.1 Role-Based Access Control

Braille Link uses role-based access control. Roles include platform owner, super administrator, programme administrator, institution administrator, and user. Each role carries a defined set of permissions. Institution administrators are responsible for assigning appropriate roles within their institution and removing access that is no longer needed.

4.2 Institution Separation and Feature Access

Institutions share one database, and the application limits each request to the records of the signed-in user's institution. Access to features such as Braille input and the workspace is also controlled per user, so that members of the same institution can be given different access.

4.3 Access by Our Own Team

Braille Link is operated by a small team. Access to production systems is limited to the people who need it to run and support the service, and is removed when it is no longer needed.

4.4 Admin Audit Logs

Administrative and security-relevant actions are recorded in audit logs, including account creation and deletion, role changes, privileged-user changes, data exports, and billing changes. Administrators can review the audit records available to their role. By default audit records are kept for 730 days and are then deleted automatically.

5. Infrastructure Security

5.1 Cloud Hosting

Braille Link's application, database, and vision service are hosted by Render, a cloud hosting provider. Render is responsible for the physical security of its data centres and the underlying platform, and publishes its own security and compliance information. We do not operate our own data centres.

5.2 Environment Separation

Production runs separately from development and test environments and uses its own database and credentials. Database credentials and other secrets are held as deployment secrets rather than in source code.

5.3 Network and Application Protection

Network-level filtering and denial-of-service mitigation are provided by our hosting platform as part of its managed service. At the application layer we apply input validation, rate limiting, security response headers, and access checks on each request.

5.4 Backups

Database backups are provided by our managed database provider under its plan and service terms. We do not publish a guaranteed recovery time or recovery point in this policy. Institutions that need specific backup or recovery commitments should agree them with us in writing.

6. Vulnerability Management

6.1 How We Find Problems

We run automated tests on changes before release, including tests that check institutions cannot see one another's records, and we review the third-party libraries we depend on. We also act on reports from users, institutions, and security researchers.

Braille Link has not yet commissioned an independent penetration test and does not hold a security certification. If that changes, we will say so in this policy.

6.2 Fix Targets

These are targets we work towards, not guarantees:

• Critical vulnerabilities: We start work as soon as we confirm the problem and aim to fix or mitigate it within 7 days.
• High severity vulnerabilities: We aim to fix or mitigate within 30 days.
• Medium and low severity vulnerabilities: Fixed in a later scheduled release.

7. Responsible Disclosure Program

Braille Link welcomes responsible security research. If you discover a security vulnerability in our platform, we ask that you report it to us privately so we can address it before public disclosure.

7.1 How to Report

Report vulnerabilities by email to: support@tusomebraille.com

Please include in your report:

• A clear description of the vulnerability and its potential impact.
• Steps to reproduce or a proof-of-concept (PoC) — avoid storing or transmitting sensitive data as part of your PoC.
• The affected URL, endpoint, or component.
• Any relevant screenshots or HTTP request/response captures.
• Your contact information for follow-up.

7.2 Our Commitments to Researchers

• We will acknowledge receipt of your report within 2 business days.
• We will investigate and provide an initial assessment within 10 business days.
• We will keep you informed of remediation progress.
• We will not take legal action against researchers who act in good faith under this policy.
• We will credit you in our security acknowledgements (if you wish).

7.3 90-Day Disclosure Window

We ask that researchers allow Braille Link a 90-day period from the date of our confirmation of the vulnerability to implement a fix before publicly disclosing the details. If a patch cannot be completed within 90 days, we will discuss an appropriate disclosure timeline with you. We are committed to timely remediation and will not use this window to indefinitely delay disclosure.

7.4 Out of Scope

The following are outside the scope of our responsible disclosure programme:

• Social engineering or phishing attacks targeting Braille Link staff or users.
• Physical attacks against our infrastructure.
• Vulnerabilities in third-party services not under our control.
• Denial-of-service testing without prior written consent.
• Accessing or modifying accounts or data belonging to other users without their consent.

8. Compliance

8.1 Data Protection Law

Braille Link is operated from Uganda and handles personal data under Uganda's Data Protection and Privacy Act, 2019 and its Regulations. Our Privacy Policy explains what we collect, why, who receives it, and the rights you have.

8.2 Education Records

When Braille Link handles learner records on behalf of an institution, we use them only to provide the Service to that institution. Institutions remain responsible for their learners' education records. For institutions subject to laws such as FERPA in the United States, we will support the institution's lawful instructions; we do not claim any FERPA or similar certification.

8.3 Where Data Is Processed

Braille Link data is processed in our hosting provider's cloud region, which is outside Uganda. Institutions with data-residency requirements should contact us at support@tusomebraille.com before use so we can discuss what is possible.

8.4 Certifications

Braille Link does not currently hold ISO/IEC 27001, SOC 2, or similar certification. We review this policy whenever the system changes so that it stays accurate.

9. Security Incident Notification

If we confirm a security incident that results in unauthorised access to, disclosure of, or loss of personal data, Braille Link will:

• Notify the relevant data protection authority as the law requires. In Uganda this means notifying the Personal Data Protection Office immediately after we become aware of the breach.
• Notify affected users and institutions without undue delay, by email to the registered account address, in the manner required by law or directed by the authority.
• Describe what happened, the data affected, the likely consequences, and the steps we are taking.
• Share a summary with affected institutions once the incident is resolved, describing what we changed to prevent it happening again.

10. Contact

For security-related enquiries, vulnerability reports, or incident notifications, please contact us at:

• Security team: support@tusomebraille.com
• General support: support@tusomebraille.com
• Privacy enquiries: support@tusomebraille.com
• Company: Avora Technologies Limited, a company registered in Uganda under the Companies Act, registration number 80034962283894 (computer programming, consultancy and related activities)
• Registered office: Kagoda, Lukuli, Kampala, Central Region, Uganda
• Postal address: P.O. Box 211562, Kampala GPO, Uganda
• Website: tusomebraille.com

We read security reports during support hours (Monday to Friday, 8:00 AM to 6:00 PM East Africa Time) and act on urgent reports as soon as we see them. Please mark urgent reports clearly in the subject line, and do not share vulnerability details through any other channel until a fix has been deployed.