Information Security Policy

Godroox LLC — GodManager Platform
Owner: Wellington Alves Gomes, Owner, Godroox LLC

1. Purpose and Scope

This Information Security Policy describes how Godroox LLC ("Godroox") protects the confidentiality, integrity, and availability of the information processed by the GodManager platform ("the Service"). It applies to all systems, data, personnel, and third-party services involved in operating the Service.

GodManager is a software-as-a-service property management platform for property management companies in the United States. It processes business and personal data including property records, tenant and owner information, financial transactions, and — where a user chooses to connect a bank account — encrypted financial account tokens obtained through Plaid.

This document describes both the controls currently in place and the improvements that are planned or in progress, with target timelines. Godroox treats information security as an ongoing program of continuous improvement.

2. Organization and Responsibility

Godroox is a small organization. The Owner, Wellington Alves Gomes, is responsible for information security decisions, including access management, vendor selection, incident response, and approval of changes to production systems.

System access is limited to the Owner and a small number of vetted contractors engaged for specific development tasks. Access is granted on a least-privilege basis and removed when no longer required.

3. Access Control

• Authentication: Users authenticate with a username (email) and password. Passwords are stored using bcrypt one-way hashing (12 rounds); plain-text passwords are never stored.
• Session management: Authenticated sessions use a secure, HTTP-only cookie. In production, the session cookie is marked Secure (transmitted only over HTTPS) and SameSite to mitigate cross-site risks. Sessions expire after 24 hours.
• Brute-force protection: Login attempts are rate-limited (a maximum number of attempts per window, with temporary lockout) to deter automated password-guessing.
• Role-based access control: The Service defines distinct user roles (administrator, manager, accountant, leasing, maintenance, field, viewer, owner, tenant, vendor, and platform super-administrator). Access to features and data is gated by role and per-section permissions.
• Tenant isolation: The Service is multi-tenant. Each client organization's data is scoped by a client identifier so that users can access only the data belonging to their organization. Database-level row isolation provides defense in depth.
• Administrative access: Access to production infrastructure (hosting, database, storage, code repository) is restricted to the Owner and protected by multi-factor authentication (MFA) on each provider account. Credentials are stored in a password manager, not in plain text or in code.

4. Data Protection and Encryption

• Encryption in transit: All traffic between clients and the Service is served over HTTPS/TLS by the hosting and edge providers.
• Encryption of sensitive credentials at rest: Bank account access tokens obtained through Plaid are encrypted at the application layer using AES-256-GCM before being stored. The encryption key is held only in the production environment configuration and is never committed to source control.
• Password hashing: As above, bcrypt is used for all account passwords.
• No card data stored: Godroox does not store full payment card numbers. Subscription card payments are handled by Stripe.
• Database and storage: The production database (PostgreSQL) and object storage (Cloudflare R2) are hosted by reputable providers that apply encryption at rest at the infrastructure level.

Planned improvements (data protection)

• Encryption of additional sensitive fields: Certain sensitive fields entered by client organizations (for example, tenant SSN/ITIN and vendor bank account details) are currently stored in plain text within the tenant-isolated database. Godroox is implementing application-layer encryption (using the same AES-256-GCM mechanism already in place for Plaid tokens) for these fields. Target: within 60 days.
• Signed session tokens: Godroox is upgrading session cookies to use cryptographic signing (HMAC) to further protect session integrity. Target: within 60 days.

5. Network and Transport Security

• The Service is delivered over HTTPS/TLS by the hosting platform (Railway) and edge/CDN provider (Cloudflare).
• Godroox is adding HTTP security response headers (including HTTP Strict Transport Security, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy) at the application layer to enforce HTTPS and reduce common web risks. Target: within 30 days.

6. Logging, Monitoring, and Audit

• Audit logging: Key actions (such as record deletions, balance updates, password changes, and financial document changes) are recorded in an audit log capturing the actor, timestamp, IP address, user agent, and relevant context.
• Application monitoring: Application errors and operational events are logged through the hosting platform.
• Planned improvement: Godroox is expanding audit coverage to additional sensitive operations and defining a log retention period. Target: within 90 days.

7. Vendor and Subprocessor Management

Godroox relies on established, reputable third-party providers, each processing only the data needed for its function:

Godroox selects vendors that maintain recognized security practices and reviews this list periodically.

8. Plaid Integration — Scope and Handling

• Godroox uses Plaid's Auth and Identity products to verify and link bank accounts at the user's request.
• Godroox does not use Plaid to move money, initiate payments, or retrieve transaction history.
• Godroox does not receive or store users' online banking credentials; these are handled solely by Plaid.
• Data received from Plaid (access tokens and limited account metadata) is treated as sensitive. Access tokens are encrypted at rest (AES-256-GCM). Only the last digits of an account number (the mask) are retained for display.
• Users may disconnect a linked account; Godroox is adding a self-service disconnect/revocation flow. Target: within 60 days.

9. Vulnerability Management

• Godroox relies on managed, patched infrastructure from its hosting and platform providers, and keeps application dependencies updated.
• Code changes affecting production are reviewed before deployment, with particular scrutiny for changes that touch financial data or authentication.
• Planned improvement: Godroox is establishing a routine process to scan application dependencies and production assets for known vulnerabilities and to remediate findings on a defined schedule. Target: within 90 days.

10. Data Retention and Deletion

• Data is retained while a client account is active and as required for legal, accounting, and audit purposes.
• After account closure, production data is deleted after a limited recovery window; backups are overwritten on a rolling basis.
• Planned improvement: Godroox is formalizing and automating its retention and deletion schedule, including a defined retention period for audit logs and a documented process for honoring deletion requests. Target: within 90 days.

11. Backup and Recovery

• The production database is hosted on Railway, which provides managed backups at the infrastructure level.
• Planned improvement: Godroox is documenting its backup configuration and recovery procedure, and will periodically test data restoration to confirm recoverability. Target: within 60 days.

12. Incident Response

In the event of a suspected security incident, Godroox follows these steps:

1. Contain: Isolate the affected system; if a deployment is implicated, roll back to the last known-good release.
2. Assess: Determine the scope and what data may have been affected.
3. Remediate: Fix the underlying cause and rotate any potentially exposed credentials.
4. Notify: Inform affected client organizations and, where required by law, affected individuals and authorities, without undue delay.
5. Review: Document the incident and the corrective actions taken.

Godroox is formalizing this procedure into a written incident-response plan with defined notification timelines. Target: within 60 days.

13. User Authentication and MFA

• Administrative access to production infrastructure is protected by MFA at the provider level.
• End-user accounts authenticate with username and password, protected by brute-force rate limiting.
• Multi-factor authentication (MFA) is available to all end users. The Service offers app-based, time-based one-time password (TOTP) MFA compatible with standard authenticator apps (e.g., Google Authenticator, Authy, 1Password). Each user can enable MFA from their account; the TOTP secret is encrypted at rest, and one-time backup codes are issued for account recovery.
• When a user enables MFA, it is enforced at login: a valid TOTP code (or a backup code) is required in addition to the password before a session is granted. This applies to accounts that link financial accounts via Plaid.

14. Privacy

Godroox maintains a public Privacy Policy describing what data is collected, how it is used, with whom it is shared, and the rights of individuals. The Privacy Policy is available at godmanager.us and is provided in English, Portuguese, and Spanish.

15. Policy Review

This Information Security Policy is reviewed periodically and updated as the Service and its controls evolve. Material changes are reflected in the "Last updated" date.

16. Contact

For security questions or to report a vulnerability or incident:

Godroox LLC
7480 Stone Creek Trail, Kissimmee, FL 34747, USA
Email: contact@godmanager.us

*This document reflects controls in place as of the last-updated date and improvements in progress with target timelines. It is maintained internally by Godroox LLC and is intended to describe our security program accurately and honestly.*