Legal

Security Incident Response Policy

B2B2GO · ProductivityByPhil · ABN 48 721 872 764 · Melbourne, Australia
Version 1.1 · Effective 11 June 2026 · Owner: Philip Vieyra

1. Purpose & scope

This policy defines how ProductivityByPhil detects, responds to, contains, and reports security incidents affecting B2B2GO and the personal data it processes on behalf of merchants and their buyers. It applies to all systems that store or transmit B2B2GO data, including the application backend, the Neon Postgres database, OAuth credentials, and the storefront widget.

A security incident is any event that compromises, or has a credible likelihood of compromising, the confidentiality, integrity, or availability of B2B2GO systems or the personal data they hold — including unauthorised access, credential exposure, data loss, malicious code, or service compromise.

2. Roles

B2B2GO is operated as a sole trader. There are no staff: Philip Vieyra is the only individual with access to the credentials and systems (Vercel, Neon / Databricks, Shopify) that hold B2B2GO personal data. As Incident Response Lead he is responsible for detection triage, decision-making, containment, notification, and post-incident review. Where specialist input is required (legal, forensic, or hosting-provider escalation), the Lead engages the relevant external party.

3. Detection & reporting

Incidents may be identified through:

• Authentication and audit logs maintained by the platforms that hold personal data (Vercel, Neon / Databricks, Shopify), including login and access records;
• Alerts from those infrastructure providers;
• Shopify platform notifications, including compliance webhook activity;
• Reports from merchants, buyers, or third-party researchers.

Access to systems holding personal data is restricted to the sole operator. Those platforms record that access through their own authentication and audit logs, which are reviewed when an incident is suspected. Any suspected incident is recorded immediately with date/time, source, and a description of what was observed. The clock for assessment and notification starts at the moment of becoming aware.

4. Severity classification

5. Response procedure

1. Identify & record — confirm the incident is genuine, assign a severity, and open an incident record.
2. Contain — stop ongoing harm. Actions may include revoking and rotating affected OAuth tokens and API keys, disabling compromised endpoints, isolating affected database access, and forcing credential resets.
3. Eradicate — remove the root cause (patch the vulnerability, close the misconfiguration, remove malicious artefacts).
4. Recover — restore affected services from verified-clean backups, confirm integrity, and monitor for recurrence.
5. Assess data impact — determine what personal data was affected, whose, and whether the incident is likely to result in serious harm.

6. Data loss prevention

B2B2GO's data loss prevention strategy protects the integrity and availability of personal data held in the Neon Postgres database. The database provider, Neon / Databricks Inc, is United States–incorporated and stores B2B2GO data in the Sydney (ap-southeast-2) region; consistent with APP 8 of the Privacy Act 1988 (Cth), the provider may have limited administrative access to infrastructure for support and security purposes, as described in the ProductivityByPhil Privacy Policy.

• Continuous automated backups with point-in-time recovery (PITR) allow the database to be restored to any moment within the provider's retention window.
• Backups are encrypted at rest using AES-256, consistent with the encryption applied to live data.
• Test and production data are kept strictly separate; development and testing never run against production personal data.
• Restores are verified for integrity before being relied upon during recovery.
• Access to production data and backups is restricted to the operator and protected by scoped, encrypted credentials.

7. Handling buyer and merchant data requests

B2B2GO implements Shopify's mandatory compliance webhooks, which are treated as part of incident and data-rights handling:

• customers/data_request — buyer data-access requests are fulfilled to the requesting merchant within the timeframe required by Shopify.
• customers/redact — buyer personal data is erased on request.
• shop/redact — on app uninstall, shop and associated data are erased; OAuth tokens are deleted within 30 days.

8. Notification

Where an incident affects personal data, ProductivityByPhil notifies the relevant parties without undue delay:

• Affected merchants — notified as soon as practicable, and no later than 72 hours after becoming aware of a confirmed incident affecting their data, including what happened, the data involved, and remediation steps.
• Shopify — notified promptly of incidents affecting merchant or buyer data, in line with Shopify Partner Program obligations.
• Office of the Australian Information Commissioner (OAIC) — where an incident is assessed as an eligible data breach under the Notifiable Data Breaches scheme (Privacy Act 1988 (Cth)), affected individuals and the OAIC are notified as soon as practicable.
• Other regulators — additional notifications are made where required by the law applicable to an affected individual's jurisdiction.

9. Post-incident review

After every Critical or High incident, a review is completed documenting the timeline, root cause, effectiveness of the response, and corrective actions. Corrective actions are tracked to completion and feed back into this policy and into B2B2GO's controls.

10. Review & maintenance

This policy is reviewed at least annually, and after any Critical or High incident or material change to B2B2GO's architecture or data handling.