Security at G-amini

1. G-amini Cloud

G-amini Cloud runs on container infrastructure at major cloud providers, with an optional Kenyan data-centre region for customers who need data to stay in the country. Production systems are monitored around the clock for availability, errors and security events.

2. Backups and disaster recovery

• Every database is backed up daily, and backups are retained for 30 days.
• Backups are encrypted and copied to a separate location from the production servers.
• Cloud databases also support point-in-time recovery, giving a recovery point objective (RPO) of 1 hour. Our recovery time objective (RTO) is 4 hours.
• Administrators can download a full backup of their own database at any time, and can create a test copy (sandbox) on Growth and Enterprise packages.
• Restore procedures are tested regularly, not just documented.

3. Database isolation

Each customer has its own database. Data is never mixed between customers in shared tables, and access rules on our servers prevent one customer's database from reaching another's. This design also makes per-customer backup, restore, export and data-residency choices simple and reliable.

4. Accounts, passwords and sign-in

• Passwords are never stored in readable form. They are hashed with a slow, salted algorithm designed for passwords, and sent only over encrypted connections.
• Administrators can require two-factor authentication, set minimum password length, limit failed login attempts and set session timeouts.
• Enterprise customers can restrict logins to approved IP ranges and sign in with Google, Microsoft or LDAP single sign-on.
• Access within a company is controlled by security groups (User, Manager, Administrator) per app, record rules (for example, salespeople see only their own pipeline) and field-level restrictions that hide sensitive values such as salaries and cost prices.

5. Braysons staff access

Our support team cannot see your passwords. When you ask for help, a support engineer may sign in to your database using their own named credentials, with your permission, and only for as long as the case requires. Every staff access is logged separately from customer activity. Access to production infrastructure is limited to a small group of engineers and protected by personal keys and two-factor authentication.

6. System security

• Servers run hardened, minimal operating system images with security patches applied promptly.
• Infrastructure is defined in code and reviewed before changes reach production.
• Engineering laptops use full-disk encryption, screen locks and managed updates.
• Secrets such as API keys are stored in a dedicated secrets manager, never in source code.

7. Physical security

Our hosting providers operate certified data centres with restricted perimeters, badge or biometric access, 24/7 video surveillance and on-site security staff. Braysons staff do not have physical access to the servers.

8. Encryption

• All traffic between your browser or mobile app and G-amini uses HTTPS with modern TLS settings.
• Traffic between our internal services is encrypted as well.
• Databases, uploaded files and backups are encrypted at rest with AES-256.

9. Network defence

Our providers absorb large-scale denial-of-service attacks at the network edge. Firewalls limit which services are reachable, and automated rate limiting and intrusion prevention block brute-force login attempts and abusive traffic. Administrators can add CAPTCHA to public website forms.

10. Payment safety

• Cards: card details are entered on the payment provider's PCI-DSS compliant hosted checkout with 3-D Secure. G-amini never receives or stores card numbers; auto-renewal uses a token held by the provider.
• M-Pesa: payment callbacks from Safaricom's Daraja API are validated, stored once per transaction code to reject duplicates, and matched to invoices automatically. Unmatched payments go to a suspense account for review, never silently discarded.
• PayPal: payments are approved inside PayPal; we receive only the confirmation.

11. Software security

Security is part of how G-amini ERP is designed and built:

• Injection: the data layer builds parameterised queries, so business code does not assemble SQL by hand.
• Cross-site scripting: templates escape output by default; raw HTML must be explicitly approved in code review.
• Cross-site request forgery: every form and state-changing request carries a token that other sites cannot forge.
• Access control: permission and record-rule checks run on every request on the server, so knowing a record's ID or URL never grants access to it.
• Shared links: portal and document links are signed with unique tokens and can be set to expire.
• Code review and testing: every change is reviewed by another engineer and passes automated tests, including access-rule and tenant-isolation tests. Every release is checked against the OWASP Top 10, and independent penetration tests are carried out regularly.

12. Audit trail and compliance

G-amini logs every change to business records with the user, time and old and new values. Posted accounting entries are hash-chained so they cannot be altered without detection, and accounting audit logs are kept for 7 years. Lock dates prevent changes to closed periods. These controls support audits, KRA requirements and the Kenya Data Protection Act, 2019.

Every PDF generated by G-amini ERP carries the "G-amini ERP by Braysons" mark and producer metadata, and legal copies of posted invoices are stored as issued, so a reprint always matches the original.

13. Responsible disclosure

If you believe you have found a security vulnerability in G-amini ERP or our website, please tell us so we can fix it before it is misused.

• Email support@g-amini.co.ke with a description of the issue, the steps to reproduce it and the affected URL or version.
• Test only against your own trial database. Do not access, change or delete other customers' data, and do not run denial-of-service or social-engineering tests.
• Give us reasonable time to fix the issue before telling anyone else.

We will acknowledge your report within 2 business days, keep you informed while we work on it, and credit you publicly once it is fixed if you would like us to. We will not take legal action against researchers who follow these rules in good faith.