Legal

Security & Responsible Disclosure

Last updated 5 November 2026 8 min read

Security is part of how Marabi Made It designs, builds and runs software, not an afterthought. This page describes how we protect the data and systems we are trusted with, how we respond when something goes wrong, and how security researchers and users can report a vulnerability to us safely and be treated fairly.

At a glance

We design for security from the start: least privilege, encryption in transit, multi-factor authentication, regular updates and tested backups.
If something goes wrong, we contain it, tell affected clients within 48 hours of confirming it, and notify the regulator within 72 hours where the law requires.
If you find a vulnerability, email marabimadeit@gmail.com with the subject "Security report". We acknowledge within three Business Days.
Good-faith research that follows our rules is welcome. We will not pursue legal action against you for it.
We do not currently offer a monetary bounty, but we are glad to credit you if you wish.

This summary is for convenience. The full text below is what applies.

1.Our commitment

1.1We treat the security of client systems and the personal data they hold as a core professional duty. We aim to build systems that are secure by design and by default, in line with section 41 of the Data Protection Act, 2019, and to be open about how we do it.
1.2Our principals, Aineah Marabi (Founder and Lead Software Developer) and Ian Otollo (Co-Founder and Developer), are accountable for security at the studio.

2.Scope

2.1This policy applies to marabimadeit.co.ke and its sub-pages, and to systems that we host or operate for clients, to the extent the client has agreed in the Statement of Work. It also covers our internal systems and accounts.
2.2Systems that a client hosts itself are the client's responsibility, but we are glad to receive a report about a weakness in work that we built, and we will pass it to the client and help fix it.
2.3Third-party services we use, such as hosting platforms, payment providers and email services, are run by their owners. Please report problems in them to those owners, and tell us if they affect our clients.

3.Definitions

Vulnerability: a weakness in a system, process or configuration that could be exploited to compromise confidentiality, integrity or availability.
Researcher: a person who reports a vulnerability to us in good faith.
Security incident: an event that compromises, or is reasonably likely to compromise, the confidentiality, integrity or availability of systems or data.
Business Day: a day other than a Saturday, a Sunday or a public holiday in Kenya.

4.How we protect systems and data

Area	What we do
Encryption	TLS for all data in transit. Encryption at rest where the platform supports it, and always for backups of production data and for stored secrets.
Access control	Least privilege: people get only the access they need, reviewed regularly and removed promptly when roles end. Role-based access in the systems we build.
Authentication	Multi-factor authentication on administrative, cloud, source-control, email and domain accounts. Unique strong passwords held in a password manager. No shared accounts.
Secure development	Code review, dependency review and updates, separation of development, staging and production, no production data in development, and secrets kept out of source code.
Testing	Automated checks on every change and manual review of authentication, authorisation, input handling and payment flows before launch.
Backups and recovery	For systems we host, daily backups kept for 30 days, stored separately from production, and restored in tests to confirm they work.
Monitoring	Availability and error monitoring, and review of unusual access and administrative activity.
Devices and people	Studio devices use disk encryption, screen locks and security updates. Everyone with access is bound by a duty of confidentiality.
Suppliers	We choose suppliers with sound security practices and review them when they change, and require data-protection terms where they handle personal data.

5.Secure delivery on client projects

5.1For each project we identify the data it will hold and the risks it faces, choose controls to match, and document them in the handover. Payment flows are built to use licensed providers, so card details and M-Pesa credentials never pass through or rest in our code or the Client's database.
5.2We transfer administrative accounts and secrets to the Client at handover and recommend that the Client rotate credentials once the project goes live and whenever a person with access leaves.
5.3Security issues found during the warranty period are treated as critical defects under the Engagement Terms.

6.If something goes wrong

6.1We follow a simple incident process: detect and assess; contain and preserve evidence; remove the cause and recover; notify; and review to prevent a recurrence.
6.2Where a security incident affects a client's data, we will notify the client without undue delay, and in any event within 48 hours of confirming it, saying what we know, what we are doing, and what the client should do.
6.3Where we are the data controller, we will notify the Data Commissioner within 72 hours of becoming aware of a breach that is likely to result in a risk to individuals, as section 43 of the Data Protection Act, 2019 requires, and will notify the individuals concerned without unreasonable delay.
6.4After a significant incident we give the affected client a written summary covering cause, impact, actions taken and steps to prevent a repeat.

7.How to report a vulnerability

7.1Email marabimadeit@gmail.com with the subject "Security report". If you would like to send encrypted details, say so in a first message and we will arrange a secure channel.
7.2Please include: the system and address affected; a description of the vulnerability and its likely impact; clear steps to reproduce it, or a proof of concept; your contact details; and whether you want to be credited.
7.3Please give us a reasonable time to fix the problem before you disclose it publicly. We ask for at least 90 days from your report, and will talk to you if we need longer or if the issue is being actively exploited.

8.What you can expect from us

8.1We will acknowledge your report within three Business Days, assess it and tell you whether we accept it as a vulnerability within seven Business Days, and then update you at least every 14 days until it is resolved.
8.2We will fix confirmed issues according to severity, using the targets below, and tell you when it is fixed. We will treat your report and your identity as confidential unless you agree to be named or the law requires disclosure.

Severity	Examples	Target for a fix or mitigation
Critical	Remote code execution, authentication bypass, exposure of personal data at scale	Mitigation within 72 hours; full fix within 14 days
High	Privilege escalation, stored cross-site scripting on authenticated pages, access to another user's data	Within 30 days
Medium	Reflected cross-site scripting, cross-site request forgery on sensitive actions, information disclosure of limited impact	Within 60 days
Low	Minor misconfiguration or low-impact issues	Within 90 days or the next scheduled release

9.Safe harbour

9.1If you make a good-faith effort to follow this policy, we will consider your research to be authorised, we will work with you to understand and resolve the issue, and we will not take or support legal action against you for it, including under the Computer Misuse and Cybercrimes Act, 2018, in respect of the research we have authorised.
9.2This safe harbour applies only to our own systems and to research that stays within the rules below. It cannot authorise access to systems owned by others, and we cannot bind third parties or the authorities. If a third party takes action against you for research done in compliance with this policy, we will say publicly that your research was authorised.

10.Rules of engagement

10.1Test only against accounts and data you own or that we have given you permission to use. Do not access, modify, copy or delete data that is not yours, and stop and tell us at once if you reach personal data or sensitive information.
10.2Use the minimum testing needed to show the problem. Do not degrade the service for others, disrupt availability or leave backdoors. Do not use automated scanners at a rate that affects service.
10.3Do not demand payment or conditions in return for a report, or threaten to publish a vulnerability to pressure us. Do not share the vulnerability with others before we have had a reasonable chance to fix it.
10.4Comply with the law, and with our Acceptable Use Policy.

11.Out of scope

11.1The following are not accepted as vulnerabilities, although we are glad to hear about them as suggestions: denial-of-service attacks and volumetric testing; social engineering, phishing or physical attacks against our people, clients or premises; spam or social-media issues; vulnerabilities in third-party services we do not control; missing security headers, cookie flags or best-practice settings with no demonstrable impact; descriptions of software versions without a working exploit; and the content of public pages that is visible by design.
11.2Testing of client-hosted systems is out of scope unless the client has given written permission.

12.Recognition

12.1We do not currently run a paid bug-bounty programme and cannot offer monetary rewards. We are happy to thank you by name, with your consent, once an issue is resolved, and to give you a written confirmation of the report.

13.What we ask of clients and visitors

13.1Security is shared. Clients should use strong, unique passwords and multi-factor authentication on the accounts we hand over, restrict administrator rights, remove access for people who leave, keep devices updated, and tell us at once if they suspect a compromise.
13.2Please be alert to payment-fraud and impersonation attempts. We will never ask you to pay to an account that is not shown on an invoice we issued, or to share a password or one-time code. If something looks unusual, confirm with us by phone before acting.

14.Contact and review

14.1Security reports and questions: marabimadeit@gmail.com, subject "Security report". We review this policy at least annually and after any significant incident. Last updated 5 November 2026.