Infrastructure
Kigs Apex products, including CashTrace and Rentisha, run on Google Cloud Run. Cloud Run containers are ephemeral, auto-scaled, and isolated at the VM boundary by gVisor. Production traffic terminates TLS at Google's load balancer before reaching our services.
Compute
Google Cloud Run (Nairobi-region eligible; failover across EU-West regions where applicable).
TLS
Enforced by Google Cloud load balancer. HTTP is not accepted.
Container runtime
Dockerised, standalone Next.js output (output: 'standalone' in next.config.js).
Secrets
Managed via Google Secret Manager and environment variables, not committed to source.
Browser security headers
Every response from kigsapexsolutions.com carries the following security headers (configured in next.config.js):
HSTS
max-age=31536000; includeSubDomains; preload. All subdomains forced to HTTPS for one year.
X-Frame-Options
DENY. The site cannot be embedded in third-party iframes.
X-Content-Type-Options
nosniff. Browsers must honour declared MIME types.
Content-Security-Policy
default-src 'self'; frame-src limited to google.com and maps.google.com; connect-src 'self'; frame-ancestors 'none'.
Referrer-Policy
origin-when-cross-origin. External referrers leak origin only, not path.
Permissions-Policy
Camera, microphone, geolocation, payment, USB, accelerometer, gyroscope, magnetometer all denied by default.
Rate limiting & CSRF
Public API routes on this site (contact form, questionnaire, newsletter) enforce request-origin validation and per-IP rate limits before processing. The implementation lives in lib/rateLimit.js and lib/security.js.
Origin allowlist
Requests must originate from kigsapexsolutions.com (or localhost in development). Missing or mismatched Origin/Referer is rejected.
Rate limits
Per-IP sliding-window counters. Subscribe: 3/hour. Contact submissions: limited at the server level.
Log hygiene
User input is sanitized before any logging (sanitizeForLog in lib/security.js), no raw user content in logs.
Input validation
Email and phone patterns validated server-side regardless of client-side checks.
Kenya Data Protection Act 2019
Rentisha, our property operations product, handles tenant and owner data. Kigs Apex is registered with the Office of the Data Protection Commissioner as a data processor under Kenya's Data Protection Act 2019. Registration is a filing with the regulator rather than an audit or certification; the controls below are what we actually run behind it.
Data Processor, Kenya
Office of the Data Protection Commissioner · Registration 729-0989-093D
Consent capture
Tenants explicitly consent to data processing at onboarding. Consent state is stored and surfaced in their portal.
Purpose limitation
Tenant data is used for rent collection, arrears follow-up, maintenance, and compliance, not marketed or sold.
Right of access
Tenants can download their own ledger, statements, and lease documents from the Rentisha portal at any time.
SMS channel
Outbound SMS is routed through a CA-licensed bulk SMS provider with registered business Sender ID.
Anti-harassment caps
Automated tenant messaging includes frequency caps, mandatory opt-out language, and immutable audit of every message sent.
KRA eTIMS integration
Invoices issued through Rentisha are transmitted to the Kenya Revenue Authority via the eTIMS API at the moment of issue. This keeps the landlord's VAT and withholding posture synchronised with KRA without a separate filing step.
Transmission
Every invoice reaches KRA eTIMS within the same request cycle as issuance. Failures are queued for retry and surfaced on the compliance dashboard.
Audit log
Every eTIMS submission is written to an append-only audit log per invoice, retained for the statutory period.
Incident response & disclosure
If you believe you've found a security issue in any Kigs Apex product or on this site, email security@kigsapexsolutions.com or info@kigsapexsolutions.com. We acknowledge reports within 48 business hours, give a triage decision within 5 business days, and keep reporters updated through remediation. We don't threaten good-faith security researchers with legal action.
Acknowledgement SLA
48 business hours from report receipt.
Triage SLA
5 business days for a severity classification and remediation timeline.
Disclosure
Coordinated. We prefer private disclosure first; happy to credit reporters publicly on resolution.
How the products behave under pressure.
The controls above describe how data is held. These describe what the systems do when something goes wrong: when KRA is unreachable, when a payment cannot be identified, when a classifier is unsure, when a tenant has asked not to be contacted. They are stated as guarantees rather than as configuration, deliberately.
Arrears escalation
- Steps
- 4
- Sequence
- grace → reminder → notice → final
- Cadence
- set per organisation
- Late fee
- flat % of arrears
- Languages
- EN · SW
- Final notice cites
- Distress for Rent Act
- Every step
- logged, attributable
Per-organisation defaults. Every step is disclosed to the tenant in advance.
Message suppression
- 1 · Opted out
- indefinite
- 2 · Restricted
- DSAR art. 18
- 3 · Quiet hours
- EAT
- 4 · Frequency cap
- hourly + daily
- Caps count
- delivered, not attempted
- Opt-out honoured
- before any other rule
- Suppressed sends
- still audited
Checked in a fixed precedence; the reason recorded is the strongest true one.
KRA eTIMS filing
- Filed
- at issue
- On KRA outage
- queued, retried
- Retry budget
- bounded, then escalated
- Double filing
- structurally prevented
- In-flight submissions
- single-flight
- Orphaned rows
- swept and replayed
- Every submission
- append-only audit
Per invoice, at issue. Not batched at month end.
Payment matching
- Tiers
- 3, descending confidence
- Auto-applied
- exact reference only
- Below certainty
- ranked, human-confirmed
- Unresolved
- reconciliation queue
- Identity vs allocation
- separate queues
- Overpayment
- wallet credit
- Rounding
- 2 dp, every step
Anything below certainty is a suggestion, not a ledger write.
Message classification
- Intents
- 6, closed set
- Below threshold
- deterministic fallback
- Languages
- EN · SW · Sheng
- Rationale stored
- yes, per message
- Irreversible action
- opt-out only
- Model output
- schema-validated
- Unparseable
- fails to fallback, not to error
Falls back to a deterministic matcher below threshold, or on any error.
Data protection
- ODPC role
- Data Processor
- Registration
- 729-0989-093D
- DSAR types
- 6
- Isolation
- Postgres RLS
- Enforcement
- database, not application
- Notification log
- append-only
- Region
- africa-south1
These are the operating guarantees of CashTrace and Rentisha in production, stated as behaviour rather than configuration. Escalation cadence, late fee and message templates are set per organisation; the rest is a fixed property of the system. We do not publish thresholds, retry constants, match tolerances or schema details: they would tell you little about whether the systems work, and rather too much to anyone trying to work around them.
Honest gaps
We don't hide incomplete work. At the time of writing:
- We are not yet ISO 27001 or SOC 2 certified. Controls are aligned to the frameworks; formal audit has not been completed.
- A public status page is not yet live. Product uptime incidents are tracked internally; we plan to publish a page at /status.
- Formal third-party penetration tests have not been commissioned for CashTrace or Rentisha. Both products have been pen-tested informally against OWASP Top 10 patterns only.
Updates to this page appear in the changelog.