Data Breach Response Policy

1. Purpose and Scope

Very Big Machine ("we," "our," or "us") is committed to safeguarding the personal data entrusted to us by users of our Services. This Data Breach Response Policy ("Policy") establishes our procedures for identifying, assessing, containing, and reporting personal data security incidents affecting any Very Big Machine product or service, including Google Workspace Add-ons, Chrome Extensions, and web-based tools.

This Policy applies to all personal data processed by Very Big Machine—whether held in our systems, transmitted through our Services, or stored in third-party infrastructure on our behalf—and is designed to meet or exceed the requirements of the EU General Data Protection Regulation (GDPR), the UK GDPR, the California Consumer Privacy Act (CCPA/CPRA), and applicable U.S. state breach notification laws.

2. Data We Hold

Because we practice strict data minimization, the personal data held by Very Big Machine is limited in scope. This significantly reduces both the risk profile of a potential breach and the potential impact on affected users. The personal data we retain is:

We do not retain documents, files, PDF content, or any other user-generated content beyond the duration of a processing session. Such content is never written to our databases or storage services.

3. Infrastructure and Preventive Security Controls

Very Big Machine's backend is built exclusively on Google Cloud Platform (GCP) and Firebase. The following security controls are in place as baseline protection against data breaches:

3.1 Google Cloud Platform and Firebase

• Certifications: GCP holds ISO/IEC 27001:2013, SOC 2 Type II, SOC 3, and PCI DSS certifications. Firebase operates on the same Google infrastructure.
• Encryption at Rest: All data in Firestore and other GCP storage services is encrypted at rest using AES-256 with Google-managed keys under Google's Key Management Service (KMS).
• Encryption in Transit: All traffic to and from GCP services is encrypted using TLS 1.2 or higher. We enforce HTTPS and HSTS on all web-facing endpoints.
• Physical Security: Google's data centers employ 24/7 security personnel, biometric access controls, and are not publicly identified by location.
• Automated Threat Detection: GCP Security Command Center provides continuous monitoring for misconfigurations, vulnerabilities, and anomalous activity across our infrastructure.

3.2 Application-Level Controls

• Identity and Access Management (IAM): Access to production systems is restricted to authorized Very Big Machine personnel under the principle of least privilege, using GCP IAM with role-based access controls.
• Multi-Factor Authentication (MFA): All administrative accounts require MFA; direct database access requires additional authentication layers.
• Firestore Security Rules: Database access is enforced at the Firestore rule layer; no user can access another user's records.
• Dependency Management: We regularly audit third-party libraries and dependencies for known vulnerabilities and apply updates promptly.
• Secure Development Practices: Code changes are reviewed before deployment; secret management is handled through Google Secret Manager, not hardcoded credentials.

4. Definition of a Data Breach

For the purposes of this Policy, a "data breach" (or "personal data breach") means any security incident that leads to the accidental or unlawful:

• Destruction of personal data (e.g., data deleted without authorization)
• Loss of personal data (e.g., data becomes inaccessible or irrecoverable)
• Alteration of personal data (e.g., data modified without authorization)
• Unauthorized Disclosure of personal data (e.g., data transmitted to an unintended recipient)
• Unauthorized Access to personal data (e.g., a third party gains access to our database)

This covers both intentional attacks (e.g., unauthorized access, SQL injection, credential theft) and unintentional events (e.g., misconfigured database permissions, accidental data disclosure).

5. Detection and Identification

Security incidents may be detected through several channels:

• Automated alerts from GCP Security Command Center, Firebase monitoring, or Cloud Logging anomaly detection
• Notification from Google as an infrastructure provider
• Reports from users, security researchers, or third-party services
• Internal discovery during code reviews, audits, or routine operations

Upon detection of a potential incident, our response team will be notified immediately. We aim to confirm or rule out a data breach within 24 hours of initial detection. The incident will be documented from this point forward, including timestamps, the scope of affected data, and all actions taken.

6. Severity Assessment

Each confirmed incident is assessed across three dimensions to determine severity and appropriate response:

Severity is assessed by considering: (a) the nature and sensitivity of the exposed data; (b) the number of affected individuals; (c) the likelihood of harm (identity theft, financial fraud, discrimination); and (d) the ability of affected individuals to mitigate the risk themselves.

7. Containment and Eradication

Upon confirming a breach, we will take immediate steps to limit further damage:

1. Isolate: Revoke compromised credentials, disable affected service accounts, or restrict network access to impacted systems as appropriate.
2. Preserve Evidence: Take snapshots of affected systems and logs before making changes, to support forensic investigation.
3. Assess Scope: Identify the full extent of affected data and users using GCP Cloud Logging and Firestore audit logs.
4. Patch or Remediate: Close the vulnerability through a code fix, configuration change, or infrastructure update. Engage Google Cloud security support if necessary.
5. Restore: Restore service from a known-good state and confirm the vulnerability is resolved before bringing systems fully online.
6. Re-Audit: Conduct a broader audit of related systems to ensure no secondary vulnerabilities exist.

8. Notification — Regulatory Authorities

Where a breach is likely to result in a risk to the rights and freedoms of natural persons, we will notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. Applicable authorities include:

• EEA users: The lead supervisory authority under the EU GDPR (based on the location of affected data subjects)
• UK users: The Information Commissioner's Office (ICO)
• U.S. users: Applicable state attorneys general per state breach notification laws (e.g., New York SHIELD Act, California Civil Code §1798.82)

Regulatory notifications will include: (a) the nature of the breach; (b) categories and approximate number of data subjects and records affected; (c) the name and contact details of our data protection point of contact; (d) likely consequences of the breach; and (e) measures taken or proposed to address the breach.

If we cannot provide all information within 72 hours, we will make an initial report and provide supplementary information as soon as reasonably possible.

9. Notification — Affected Users

When a breach is likely to result in a high risk to affected users (e.g., risk of identity fraud, financial harm, or discrimination), we will notify affected users directly and without undue delay. Notifications will be sent to the email address on file and will include:

• A plain-language description of the nature of the breach
• The specific categories of data that were affected (e.g., name and email address)
• The likely consequences of the breach for the individual
• Steps we have taken or are taking to contain and remediate the breach
• Steps the user can take to protect themselves (e.g., changing their Google account password if credentials were potentially compromised)
• Contact information for follow-up questions

If contacting affected individuals directly is impractical (e.g., email addresses are themselves compromised), we will issue a public notice on our website at verybigmachine.com with equivalent information.

For U.S. users, notification timelines comply with applicable state law requirements (e.g., as expeditiously as possible and without unreasonable delay, not to exceed 30–72 days depending on the state).

10. Post-Incident Review

Following containment and resolution of any breach, we will conduct a post-incident review to:

• Document a complete incident timeline and root cause analysis
• Evaluate the effectiveness of our detection, containment, and notification procedures
• Identify systemic gaps in our security posture and implement corrective actions
• Update this Policy or our internal security procedures as warranted
• Retain records of the incident, response actions, and outcome for at least three (3) years, as required by GDPR Article 33(5)

Findings from post-incident reviews are used to improve our preventive controls and to better protect user data in the future.

11. Reporting a Vulnerability

We welcome responsible disclosure of security vulnerabilities in our products. If you have discovered a potential vulnerability, please contact us at security@verybigmachine.com before making any public disclosure. We commit to:

• Acknowledging your report within 48 hours
• Investigating and providing an initial assessment within 7 business days
• Working with you to understand and remediate the issue before any public disclosure
• Crediting responsible disclosures in our security acknowledgements (upon request)

Please do not access, modify, or delete data in production systems. Proof-of-concept demonstrations should be conducted in a controlled manner that does not affect real user data.

12. Contact

For questions about this Policy or to report a security concern: