Information Security Policy

1. Purpose and Scope

This Information Security Policy ("Policy") establishes the principles, standards, and controls that Very Big Machine ("we," "our," or "us") applies to protect the confidentiality, integrity, and availability of information assets across all of our products, services, and operations.

This Policy applies to:

• All Very Big Machine software products, including Google Workspace Add-ons, Chrome Extensions, and web-based tools
• All systems, infrastructure, code repositories, and data stores used to build, operate, and deliver those products
• All personnel, contractors, and service providers who access Very Big Machine systems or process Very Big Machine or user data on our behalf

This Policy is informed by and consistent with the ISO/IEC 27001:2022 framework, the NIST Cybersecurity Framework (CSF), and the requirements of the EU General Data Protection Regulation (GDPR) and applicable U.S. privacy law.

2. Security Objectives

Very Big Machine is committed to maintaining security practices that uphold the following core objectives:

Additional objectives include: minimizing the attack surface through data minimization; ensuring secure-by-default configurations; and maintaining transparency with users about our security practices.

3. Roles and Responsibilities

3.1 Security Ownership

The founder and principal engineer of Very Big Machine serves as the de facto Security Officer, responsible for: maintaining this Policy; overseeing implementation of security controls; managing security incidents; and ensuring compliance with applicable law. As the organization grows, dedicated security responsibilities will be formally assigned.

3.2 All Personnel

All individuals with access to Very Big Machine systems are required to:

• Read, understand, and comply with this Policy and related procedures
• Report suspected security incidents, vulnerabilities, or policy violations promptly to security@verybigmachine.com
• Complete security awareness training appropriate to their role
• Not circumvent, disable, or interfere with security controls

3.3 Third-Party Contractors

Contractors or service providers who are granted access to Very Big Machine systems must acknowledge and agree to comply with this Policy before access is provisioned. Access is scoped to the minimum required for the engagement and revoked promptly upon completion.

4. Information Classification

Very Big Machine classifies information into three tiers to ensure proportionate protection:

Confidential data must never be stored in source code, commit history, logs, or any system not specifically designed and secured for its storage. Secrets are managed exclusively through Google Secret Manager or equivalent secrets management tooling.

5. Access Control

5.1 Principle of Least Privilege

Access to all systems — including GCP projects, Firebase consoles, Firestore databases, code repositories, and third-party services — is granted on the basis of least privilege: each account, service, or individual is given only the minimum access required to perform their function, and no more.

5.2 Authentication

• Multi-Factor Authentication (MFA): Required for all administrative accounts, including Google Cloud Console, Firebase Console, GitHub, Stripe Dashboard, and any third-party service with access to production systems or user data.
• User Authentication: End-user authentication in Very Big Machine applications is handled through Google OAuth 2.0. We do not store passwords. Google manages the credential lifecycle.
• Service-to-Service Authentication: Automated processes authenticate using dedicated GCP Service Accounts with scoped IAM roles. Service account keys are rotated on a defined schedule and stored in Google Secret Manager.

5.3 Access Reviews

Access rights for all personnel and service accounts are reviewed periodically. Access is promptly revoked when an individual's role changes, a contractor engagement ends, or an access right is no longer required.

5.4 Firestore Security Rules

All database access in Firestore is enforced by Security Rules deployed at the database layer. Rules are reviewed on every code change that touches data access patterns. No user-facing API endpoint operates without an enforcing security rule; rules are maintained in version control and reviewed before deployment.

6. Cryptography

6.1 Encryption at Rest

All data stored in GCP services (Firestore, Cloud Storage, Cloud Run) is encrypted at rest using AES-256. Encryption keys are managed by Google's Key Management Service (KMS). Customer-managed encryption keys (CMEK) may be applied for specific high-sensitivity data stores where required.

6.2 Encryption in Transit

All network communication between clients and Very Big Machine services, and between Very Big Machine services and third-party APIs, is encrypted using TLS 1.2 at minimum; TLS 1.3 is used wherever supported. HTTPS is enforced on all web-facing endpoints; HTTP-to-HTTPS redirection is configured at the Firebase Hosting and Cloud Run layers. HSTS (HTTP Strict Transport Security) is enabled.

6.3 Secret Management

API keys, service account credentials, webhook secrets, and other application secrets are:

• Stored exclusively in Google Secret Manager, never in source code, environment variable files checked into version control, or application logs
• Accessed by Cloud Run services and Cloud Functions using Secret Manager bindings with IAM-scoped service accounts
• Rotated immediately upon any suspected compromise, and on a scheduled basis for long-lived credentials

7. Infrastructure and Cloud Security

7.1 Google Cloud Platform

Very Big Machine's production infrastructure runs entirely on Google Cloud Platform (GCP) and Firebase. GCP provides infrastructure-level security controls that underpin our security posture:

• Certifications: ISO/IEC 27001:2013, SOC 2 Type II, SOC 3, PCI DSS, FedRAMP Moderate, CSA STAR
• Physical Security: Google data centers feature multi-layer physical access controls, 24/7 on-site security, and are not publicly disclosed by location
• Threat Detection: GCP Security Command Center (SCC) provides continuous monitoring for vulnerabilities, misconfigurations, and anomalous activity across our GCP organization
• DDoS Protection: Google Front End (GFE) and Cloud Armor provide network-level distributed denial-of-service protection for Cloud Run services
• Network Controls: Services are deployed in least-privilege VPC configurations; internal services are not exposed to the public internet without explicit firewall rules

7.2 Configuration Management

Infrastructure configuration is version-controlled wherever possible. Cloud Run service definitions, Firebase configuration, and IAM policies are stored in source control and deployed through automated pipelines. Manual changes to production configuration are avoided and, where necessary, are documented and reviewed.

7.3 Separation of Environments

Development, staging (where applicable), and production environments are logically separated. Production credentials and service accounts are never used in development or testing. Test data does not contain real user personal information.

8. Secure Development

8.1 Secure-by-Default Principles

Security is a first-class concern throughout the development lifecycle, not an afterthought. Very Big Machine adheres to the following secure development practices:

• Input Validation: All data received from external sources (user inputs, API responses, webhook payloads) is validated and sanitized before use. SQL injection, XSS, CSRF, and injection attacks are mitigated at the application layer.
• Authentication and Authorization: Every API endpoint and database operation enforces authentication and authorization checks. No endpoint is left publicly accessible without explicit design intent and review.
• Data Minimization in Code: Developers are expected to collect and log only the minimum data needed. Logs must not contain personal data, authentication tokens, or secrets.
• Dependency Security: Third-party libraries and packages are reviewed before adoption. Known vulnerabilities in dependencies are remediated promptly, prioritizing those with CVSS scores of 7.0 (High) or above.

8.2 Code Review

All code changes that touch authentication, authorization, data access, cryptography, or external integrations are reviewed before deployment to production. Reviews verify that security controls are correctly implemented and that no new vulnerabilities are introduced.

8.3 OWASP Top 10

Development practices are guided by the OWASP Top 10. The following threats receive explicit attention in design and review:

• Broken Access Control — Firestore rules + server-side authorization on all endpoints
• Cryptographic Failures — GCP-managed encryption; no custom crypto implementations
• Injection — Input validation and parameterized queries/Firestore SDK use
• Security Misconfiguration — Infrastructure-as-code review; no default credentials
• Vulnerable and Outdated Components — Regular dependency audits
• Identification and Authentication Failures — Google OAuth + MFA on admin accounts
• Security Logging and Monitoring Failures — GCP Cloud Logging + SCC alerts

8.4 Google Platform Compliance

Applications distributed through the Google Workspace Marketplace and Chrome Web Store must comply with Google's developer policies, including the Google API Services User Data Policy (Limited Use requirements) and Chrome Web Store Developer Program Policies. Security reviews of API scope requests are conducted before each Marketplace or Web Store submission.

9. Vulnerability Management

9.1 Identification

Vulnerabilities may be identified through: automated dependency scanning; GCP Security Command Center alerts; responsible disclosure reports from external researchers; and manual code and configuration review. All reported or discovered vulnerabilities are logged and triaged.

9.2 Remediation Timelines

9.3 Responsible Disclosure

We operate a responsible disclosure program. External researchers who discover a vulnerability in our Services are encouraged to report it to security@verybigmachine.com before public disclosure. We commit to acknowledging reports within 48 hours and providing updates on remediation progress. We will not take legal action against good-faith security researchers who comply with our disclosure guidelines.

10. Security Monitoring and Logging

10.1 What We Log

Very Big Machine maintains security-relevant logs to support incident detection, investigation, and audit. Log sources include:

• GCP Cloud Audit Logs: Admin Activity logs (who changed what in our GCP project), Data Access logs for sensitive Firestore operations, and System Event logs
• Cloud Run Request Logs: HTTP request metadata (method, path, status code, latency) for all services — not request bodies
• Firebase Authentication Logs: Sign-in events and authentication errors
• GCP Security Command Center: Findings from threat detection, vulnerability scanning, and misconfiguration detection

10.2 What We Do Not Log

Logs must not contain: user passwords or authentication tokens; personal data (including email addresses, names, or document content); payment instrument data; or API keys. Log output is reviewed during code review to ensure compliance with this requirement.

10.3 Log Retention and Protection

Security logs are retained for a minimum of 90 days in GCP Cloud Logging, with audit logs retained for up to 400 days per GCP default policies. Log data is stored in GCP and subject to the same access controls and encryption as other infrastructure. Log integrity is maintained by GCP's append-only logging infrastructure.

10.4 Alerting

GCP Security Command Center is configured to generate alerts for high-severity findings. Alert thresholds and notification channels are reviewed and updated as our infrastructure evolves.

11. Third-Party and Supplier Security

Very Big Machine relies on a limited set of third-party service providers. Before integrating a new third-party service that will process or have access to user data, we evaluate:

• The provider's security certifications and compliance posture (e.g., SOC 2, ISO 27001)
• Their data processing and subprocessor agreements
• The minimum data that must be shared to achieve the integration's purpose
• Whether the integration can be architected to avoid sharing personal data at all

Current third-party service providers with access to user data are documented in our Privacy Policy. Each is bound by a data processing agreement (DPA) or equivalent contractual commitment. If a third-party provider experiences a security incident that affects Very Big Machine user data, we will follow the procedures in our Data Breach Response Policy.

12. Incident Management

Security incidents are managed in accordance with our Data Breach Response Policy, which defines procedures for: detection and identification; severity assessment; containment and eradication; regulatory and user notification (including the 72-hour GDPR notification requirement); and post-incident review.

All security incidents — whether or not they involve personal data — are logged, investigated, and subject to a post-incident review. The goals of the review are to identify root cause, prevent recurrence, and improve our controls.

To report a security incident or suspected breach, contact security@verybigmachine.com.

13. Business Continuity and Disaster Recovery

13.1 Infrastructure Resilience

Our Services are hosted on GCP, which provides multi-zone and, where configured, multi-region redundancy. Firebase Hosting and Cloud Run services automatically distribute traffic across available zones. Firestore is a globally replicated, multi-region database with built-in high availability and automatic failover.

13.2 Backups

Firestore provides point-in-time recovery (PITR) and supports scheduled exports to Cloud Storage. Critical application configurations and secrets are version-controlled or stored in durable managed services (Secret Manager, Firebase Remote Config). Source code is maintained in a version-controlled repository with access controls and history preservation.

13.3 Recovery Objectives

We target a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 24 hours for production services in the event of a major infrastructure failure. These targets are supported by GCP's managed infrastructure and regular backup testing.

14. Compliance and Legal

Very Big Machine's security program is designed to support compliance with the following frameworks and regulations:

Compliance obligations are reviewed whenever new legislation, regulation, or platform policy takes effect that may affect our Services or users.

15. Policy Review and Updates

This Policy is reviewed and updated:

• At a minimum, once per calendar year
• Following any significant security incident
• When material changes are made to our infrastructure, products, or data processing practices
• When new legal or regulatory requirements come into effect that affect our security obligations

The "Last Reviewed" date at the top of this page is updated with each revision. Users are notified of material changes to this Policy via email and/or a notice on our website.

16. Contact

Questions about this Policy, security concerns, or vulnerability disclosures should be directed to:

Related policies: Data Breach Response Policy  ·  Privacy Policy  ·  Acceptable Use Policy