1. Security Overview
At TindahanGo, data security is central to our engineering, deployment, and infrastructure operations. We recognize that retail shops, mini groceries, and sari-sari stores trust us with their sales, stock, and credit ledgers. We use reasonable layered security controls to reduce unauthorized access, accidental alteration and leakage risks. No service can guarantee complete security.
2. Data Encryption
Implemented controls include the following; this policy does not claim encryption of every database, upload or backup at rest:
- Encryption in Transit: The production public API uses HTTPS/TLS to protect data in transit.
- Password Hashing: We do not store plaintext passwords or cashier security PINs. Credentials are hashed using bcrypt before database storage.
- Sessions: Signed access tokens, refresh-token rotation/revocation and server-side account, role, branch and device checks protect API access. Signing a JWT is not the same as encrypting it.
3. Database Isolation & Tenancy Security
TindahanGo is multi-tenant: businesses share database infrastructure. Access separation relies on application authorization and company/branch-scoped queries:
- Business records are associated with their company directly or through owned branch, transaction and related records.
- REST API authorization and scoped queries are designed to prevent cross-company access. This is not a claim of PostgreSQL row-level security or an absolute guarantee against defects.
- Catalog/branding images use public URLs; rental identity/condition evidence uses separate private storage and permission-checked endpoints. Do not put sensitive identity data into catalog photos.
- Superadmins can review payment queues but operate under restricted access controls.
4. Backups & Disaster Recovery
We maintain recovery procedures and may maintain continuity backups. Backup schedules, locations, encryption, and deletion timing are operational controls and are not guaranteed by this public policy.
- Recovery: Recovery procedures are maintained for service-continuity incidents.
5. Monitoring, Logging, & Rate Limiting
We use bounded security and operational controls:
- Logging and optional monitoring: Request, security and audit logs support investigation. Sentry error/performance monitoring is configuration-dependent; its presence in source does not prove production enablement.
- Rate Limiting: Authentication controls limit repeated attempts; these reduce risk but do not guarantee prevention of automated attacks.
6. Security Incident Response
When we learn of or reasonably believe that a personal data breach or security incident has occurred:
- We will investigate and take containment and remediation measures appropriate to the information available; initial reporting does not wait for full validation.
- When acting as a Personal Information Processor, we will report to the Client/PIC without undue delay upon knowledge of or reasonable belief that a personal data breach affecting Client data has occurred, and provide reasonable cooperation and available incident information.
- Where Philippine breach-notification requirements apply, the PIC remains responsible for required notifications to the NPC and affected data subjects within the applicable statutory period, including the 72-hour requirement under NPC Circular 16-03, subject to lawful exceptions or postponement. Where OCTECH acts as the PIC, OCTECH is responsible for its applicable notification obligations. No shorter contractual deadline is promised here.
7. Responsible Disclosure Policy
We welcome reports from independent security researchers to make TindahanGo safer. If you find a security vulnerability:
- Email the details to admin@octechph.com. Operator: OCTECH SOFTWARE DEVELOPMENT SERVICES, Namnama, Tuding, Itogon, Benguet 2604, Philippines; +63 960 293 2001; https://tindahango.com.
- Allow our team reasonable time (e.g., 30 days) to resolve the issue before publishing details publicly.
- Do not attempt to access, download, or manipulate other tenants' data during your research.