GCS Security Policy | Grizzly Client Services

1. Security overview

GCS uses reasonable safeguards for a paid pilot, including account scoping, session controls, CSRF protection, password hashing, optional or required two-factor authentication, activation controls, recovery-code handling, and security event logging. No system is perfectly secure.

2. Account security

Clients must keep account credentials confidential, use unique passwords, restrict access to authorized users, avoid shared inbox risks where possible, and notify GCS promptly if they suspect compromise, unauthorized access, or incorrect workspace access.

3. Password responsibilities

Client users are responsible for choosing strong passwords and protecting devices and email accounts used for activation or recovery. GCS may reset, disable, or require password changes when risk is suspected.

4. Two-factor authentication

Two-factor authentication may be available or required depending on account settings. If enabled, users should store recovery codes securely and avoid sharing authentication devices, codes, or recovery materials.

5. Access controls

Workspace access is intended to be scoped by account and role. Clients should request removal or role changes when personnel leave, change duties, or no longer require access.

6. Client account scoping

GCS is designed to separate client workspaces from internal admin areas and other clients. If a client sees data they do not recognize or believes scoping failed, they must report it immediately and avoid copying or using the information.

7. No code or repository access

Security and client portal access do not provide source code, repository, infrastructure, admin, deployment, provider-dashboard, or platform-control access. Attempts to obtain such access without written authorization are prohibited.

8. Logging and security events

GCS may log authentication events, activation events, IP addresses, user-agent strings, setup acceptance records, billing events, and security-relevant actions to investigate issues, protect accounts, and maintain auditability.

9. Incident reporting

Suspected security incidents should be reported to [email protected] or the configured GCS support email shown on this page. Include account details, timestamps, affected users, and a careful description of what happened.

10. Provider security limitations

GCS depends on providers for hosting, payment, email, and other services. Provider outages, vulnerabilities, policy changes, or account restrictions may affect service security or availability and may require coordinated response.

11. Responsible disclosure

Security researchers should contact GCS before testing and must not access customer data, disrupt service, exfiltrate data, or publicly disclose issues before coordinated review. A formal bounty program is not promised in this draft.

12. Lawyer-review notice

This Security Policy is a serious draft for review and does not guarantee perfect security or certified compliance. Draft for review. Not legal advice. Lawyer review required before full commercial reliance.