Security at CustomerEQ

1. Infrastructure

• The Service runs on reputable cloud providers whose data centers maintain SOC 2, ISO 27001, and similar compliance attestations.
• Production workloads are isolated from development and staging environments with separate networks, credentials, and access policies.
• Managed PostgreSQL is used for primary data storage, with point-in-time recovery, automated snapshots, and encryption at rest.
• Secrets (API keys, OAuth tokens, database credentials) are stored in a dedicated secret manager and rotated on a defined schedule and after any suspected exposure.

2. Encryption

• In transit: all traffic to and from the Service is encrypted using TLS 1.2 or higher. HSTS is enabled on our web properties.
• At rest: databases, object storage, and automated backups are encrypted at rest using AES-256.
• Sensitive fields: OAuth refresh tokens and credentials used to access third-party APIs (including Google Business Profile) are stored encrypted with an application-level key separate from the storage layer key.

3. Access control

• Employee access to production systems requires multi-factor authentication and is granted on a least-privilege basis.
• Access to Customer data is restricted to personnel who need it to deliver and operate the Service. Access is logged and reviewed periodically.
• Within the application, role-based access controls (admin, manager, analyst, member) govern which features and data a user can see. Customers can create and assign roles appropriate to their organization.
• OAuth tokens used to access third-party APIs are scoped to the minimum permissions required for the requested functionality.

4. Application security

• Authentication is performed against a managed identity provider with secure password storage (hashed, salted), account lockout protections, and optional SSO.
• APIs enforce authentication and authorization on every request; inputs are validated using schema validators.
• Standard web-application protections are applied, including CSRF protection on state-changing routes, Content-Security-Policy headers, and protections against SQL injection, XSS, and open redirects.
• Dependencies are monitored for known vulnerabilities and patched on a regular cadence; critical vulnerabilities are patched out-of-band.
• Automated unit, integration, and end-to-end tests run on every change before deployment.

5. Secure software development

• Source code is version-controlled, code-reviewed, and changes to production systems are deployed through CI/CD pipelines with audit trails.
• Secret scanning and dependency scanning run on every commit.
• Security reviews are performed on material changes to authentication, authorization, data handling, or third-party integrations.

6. Monitoring and logging

• Application and infrastructure logs are centralized and retained in a write-protected store for investigation and audit purposes.
• Errors and anomalies are tracked via an error-monitoring service; alerting covers availability, latency, and error-rate regressions.
• Access to production and admin consoles is audit-logged with user attribution.

7. Backups and business continuity

• Databases are backed up automatically with point-in-time recovery.
• Backups are encrypted and retained according to a documented retention schedule.
• Restore procedures are exercised periodically.

8. Incident response

• We maintain an incident response plan covering triage, containment, eradication, recovery, and post-incident review.
• If a security incident affects Customer data, we will notify affected Customers without undue delay and provide information that enables them to meet their own notification obligations.
• We will cooperate with Customers and regulators as required by applicable law.

9. Vendor management

We carefully select subprocessors and service providers that handle Customer data. We evaluate their security, privacy, and compliance practices, sign data-processing agreements where applicable, and share data with them only to the extent required to deliver the Service.

10. Third-party APIs (including Google Business Profile)

When a Customer authorizes CustomerEQ to connect to a third-party service (for example, Google Business Profile), we follow these practices:

• We use OAuth wherever available and request only the minimum scopes required for the requested functionality (for example, read-only access to reviews).
• We store refresh tokens encrypted and use short-lived access tokens at runtime.
• We never post, edit, or delete content on behalf of a Customer unless they explicitly request that action.
• We honor revocation: when a Customer disconnects an integration, we stop using the corresponding tokens and purge them on our next credential-rotation pass.
• Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

11. Responsible disclosure

If you believe you have discovered a security vulnerability in the Service, please email us at sid.mathur@gmail.com with details and any proof-of-concept. Please give us a reasonable opportunity to investigate and remediate before public disclosure. We will acknowledge valid reports and credit reporters where appropriate.

Please do not test for vulnerabilities against real customer data, perform denial-of-service testing, or access data belonging to other Customers.

12. Compliance roadmap

CustomerEQ is building toward formal attestations (for example, SOC 2 Type II) as the business matures. Customers with specific compliance or contractual requirements can contact us to discuss current posture and timelines.

13. Contact

Security questions, due-diligence requests, or vulnerability reports can be sent to sid.mathur@gmail.com.