Security & compliance
What we do, and what we will not claim.
Specifics rather than adjectives — including the parts that are still open. If you are handing us member records, client files or children's data, you should be able to check our reasoning.
How does Techmode secure the systems it builds?
Techmode builds to a standard set of security practices: least-privilege access, encrypted transport, secrets kept out of code, dependency updates applied rather than logged, and an audit trail on anything that touches money or personal data. We align our work to Kenya's Data Protection Act 2019 and say plainly where a question is still open.
Practices
How we actually build.
Access is least-privilege by default
Every system we build starts from nobody having access and adds the minimum that a role needs. Administrative access is separate from daily-use access, and shared logins are designed out rather than discouraged.
Data is encrypted in transit, and at rest where the platform allows
Everything moves over TLS. Managed databases and object storage we deploy on encrypt at rest by default, and we leave it on. Where a legacy system you already run cannot do this, we will tell you rather than let it be assumed.
Secrets never live in code
API keys, service-account credentials and tokens live in the platform's secret store and are injected at runtime. A key in a repository is treated as compromised and rotated, not quietly removed.
Dependencies are updated, not just reported
Security advisories on the packages we use are acted on. On a care plan that happens as part of the monthly work; without one we will still tell you when something material lands.
Anything touching money or personal data keeps an audit trail
Who did what, when, and what the record looked like before the change. Written at the time rather than reconstructed, because a trail assembled later is not a trail.
Forms are defended against abuse, not just spam
Rate limiting by address, timing and honeypot checks, and server-side validation of everything. Client-side validation is a convenience for the visitor and is never the control.
Failure paths are designed, not discovered
A payment callback that never arrives, a sync that conflicts, an integration that times out — each has a defined behaviour that surfaces the problem to a person. Silent failure is the outcome we design hardest against.
Handover includes the keys
At launch you receive every credential and account. If you later stop working with us, our access is removed and yours is unaffected — you own the systems, so there is nothing to withhold.
Kenya Data Protection Act 2019
The law, applied to the work.
Not a summary of the Act — what following it changes about how a system gets designed.
Lawful basis is chosen, not assumed
For enquiries and marketing that means consent, given actively — never a pre-ticked box — and recorded. For systems we build for you, the basis is agreed during design, because it changes what the system is allowed to do.
Data is minimised to what the job needs
Every field a form collects has to justify itself. Collecting a national ID number because it might be useful later is the kind of decision that becomes a breach notification later.
Data subject rights are built in, not bolted on
Access, correction, deletion and withdrawal of consent are designed as things the system can actually do. A right you cannot execute without a developer is not a right you can honour within seven days.
Retention is set deliberately
How long each kind of record is kept, and what happens at the end of it, is decided during design rather than defaulting to forever.
We tell you where the data physically sits
This site runs on Vercel in the EU (Frankfurt) region, and enquiries are delivered by email and to a private spreadsheet in Google Workspace. We do not claim Kenyan data residency, because it would not be true. Where a project genuinely requires local hosting, that is a design decision with a cost, and we will price it.
What we do with your data specifically — the enquiry you send us — is in the privacy policy.
Still open
What we have not answered yet.
Naming these is the point of the section. Anyone can publish a list of practices; the useful signal is which questions the business has not closed.
Is Techmode registered with the ODPC as a data controller?
An administrative matter the business is working through. This page and the privacy policy will state the position once it is settled, rather than implying one now.
Do you hold a formal certification such as ISO 27001?
No. We are a new agency and we have not been through a certification audit. The practices above are what we do; presenting them as certified would be a claim we cannot support.
Have you had a security incident?
No — and as a new agency that is a statement about how little history there is, not a track record. If one ever occurs on a system we run, you will hear it from us with the facts and the timeline.
Have a security question that is not answered here? Email [email protected] and we will answer it plainly, including when the answer is no.
Questions
Security, answered.
Where is our data hosted?
This website runs on Vercel in the EU (Frankfurt) region. For systems we build for you, hosting is a decision we make together during design, including whether local hosting is a requirement worth its cost. We will always tell you where data actually sits rather than implying local residency.
Does Techmode comply with the Data Protection Act 2019?
We align our own handling of enquiry data to it — consent as the lawful basis, data minimised, rights honoured within seven days — and we design the systems we build for you around it. Whether the business is registered with the ODPC as a data controller is an open administrative question, stated as such above.
Will our data be sent to an AI provider?
Only where the project needs it and you have agreed to it, and only the part of the data the task requires. Where data is sensitive we design around that from the start — redaction before a model sees anything, or a model in an environment you control. It is a decision we make with you.
Who has access to our systems during a project?
The people working on it, with the least access that lets them work, and access is removed at handover. We do not keep standing credentials to a client system after a project ends unless you have asked us to for support.
What happens if you find a vulnerability after launch?
We tell you, with what it affects and what we recommend. On a care plan the fix is part of the work. Without one, you still get told — withholding it to sell a support contract would be indefensible.
Can we run a penetration test against what you build?
Yes, and we would encourage it for anything handling money or personal data at scale. Tell us before you do, so we do not treat it as a live attack, and we will fix what it finds.
Ready for software that wins you customers?
Book a free, no-obligation consultation. We'll map your fastest wins and show you exactly what's possible — in plain language, with clear numbers.
Prefer direct? [email protected] · +254 731 290 928 · Mon–Sat, 8am–6pm EAT