Trust
Security is a procurement question, so we answer it in public
Institutions that hand us beneficiary registers, revenue ledgers and court files are entitled to know exactly how those are protected — before the questionnaire stage. This page is what we would send you anyway, published up front.
Controls
What we put in place, on every engagement
Six control areas that appear in every architecture we deliver. Each is evidenced in the design documentation handed over at go-live.
Data residency & ownership
- Systems deploy into in-country facilities — including government data centres and commercial Kenyan facilities — or a client-selected regional jurisdiction. The residency decision belongs to the institution.
- The institution holds administrative control, the source code and the credentials. Architecture is portable by design so a future migration is never blocked by us.
- Processing is mapped to a lawful basis under the Kenya Data Protection Act, 2019, with ODPC-ready documentation produced as part of delivery.
Encryption
- Data encrypted in transit with TLS, and at rest at the storage layer, on every deployment we operate.
- Secrets and credentials held in managed secret storage, never in source control or configuration files committed to a repository.
- Key custody and rotation responsibilities are written into the engagement agreement rather than left implicit.
Access control
- Role-based access mapped to the institution's own delegation of authority — not to a generic vendor role model.
- Least-privilege by default: access is granted per role and reviewed at each phase gate during delivery.
- Administrative access to production is separated from development access, and handed to the institution at go-live.
Audit & traceability
- Field-level audit logging on records that carry evidentiary or financial weight: who changed what, when, and under whose authority.
- Append-only trails on registry and case-management deployments, so a record's history cannot be quietly rewritten.
- Reporting figures trace back to source records, which is what makes a donor or Auditor-General submission defensible.
Infrastructure & resilience
- Hardened deployments with security updates applied under the support agreement, not on an ad-hoc basis.
- Backup and restore procedures agreed with the institution at design stage, and tested before go-live rather than after an incident.
- Monitoring and SLA reporting from day one of hypercare, with an agreed escalation path.
Secure delivery
- Delivered by a practice accredited by the ICT Authority of Kenya for Information Security (Cert. No. 11179).
- Hardening and penetration testing are treated as standard scope on deployments that handle sensitive data, not as a paid add-on.
- AI components are auditable, explainable and human-in-the-loop — no black-box model makes a consequential decision unreviewed.
Independently accredited
Claims you can verify without asking us
Certificates open as signed PDFs. Reference numbers can be checked with the issuing authority directly.
This website
We hold our own site to the same standard
A security page on an unhardened site is a brochure. These headers are enforced on every response from rosewillbome.com and can be checked with any header inspector.
| Control | What it does |
|---|---|
| HTTP Strict Transport Security | Enforced for one year, including subdomains, and submitted for preload. |
| Content Security Policy | Restricts scripts, styles, frames and connections to an explicit allowlist. |
| Clickjacking protection | Framing denied outright via frame-ancestors and X-Frame-Options. |
| MIME sniffing | Disabled with X-Content-Type-Options: nosniff. |
| Referrer policy | strict-origin-when-cross-origin — no path data leaks to third parties. |
| Permissions policy | Camera, microphone, geolocation, payment and USB access disabled site-wide. |
| Cross-origin isolation | Opener and resource policies set to same-origin. |
| Third-party scripts | Analytics only, gated behind consent, with no third-party script able to read form input. |
Coordinated vulnerability disclosure
If you believe you have found a security issue in this website or in a system we operate, we want to hear from you — and we will not pursue anyone who reports in good faith under the terms below.
Machine-readable policy: /.well-known/security.txt (RFC 9116)
What we ask of researchers
- Report privately to the address above and give us a reasonable period to remediate before any public disclosure.
- Do not access, modify or exfiltrate data belonging to any institution or beneficiary. A proof of concept should stop at demonstrating the issue.
- No denial-of-service testing, social engineering of our staff or clients, or physical testing of any facility.
- Include enough detail to reproduce: the URL or endpoint, the steps, and what you observed.
What you can expect from us
- Acknowledgement of your report within three business days.
- An assessment and a remediation timeline within ten business days.
- Credit in our advisory, where you would like it.
Send us your due-diligence questionnaire
We answer security and data-protection questionnaires as standard, and can supply architecture documentation, the DPIA approach and reference contacts under NDA.
- Response within 24 hours
- NDA available on request
- No-obligation discovery call