GateBud

This page describes our current security practices for prospective and existing customers. Together with the Privacy Policy and Subprocessors page, it makes up the Privacy & Security Schedule to our Master SaaS Agreement. It does not replace or amend your signed agreement; its agreed order of precedence applies.

1. Security approach

GateBud™ limits access to customer data, encrypts it in transit and keeps each organisation's data separate.

• Access to customer data is restricted to people who need it.
• GateBud uses established managed cloud providers for hosting and database infrastructure.
• Security controls are reviewed as the product and its infrastructure change.

2. Infrastructure

GateBud runs on established managed cloud providers rather than its own physical servers or data centres.

At a high level:

• Cloud-hosted architecture. The application and database run on reputable managed cloud services.
• Managed infrastructure. Operating systems, database engines and platform patching are managed by our providers, which means critical infrastructure security updates are applied promptly and consistently.
• Redundancy and availability. Our providers offer redundant, highly available infrastructure. Our application is designed to take advantage of that.
• Continuous monitoring. We use monitoring and error-tracking tools to observe the health of the platform and to alert us to problems.
• Data location. Our main database is in Sydney, Australia, and the application runs there too. GateBud accesses customer data from New Zealand. Some providers process data in the United States and the European Union, for example email delivery, off-site backups, error monitoring and analytics.

Every provider we use is listed on our Subprocessors page, with what it does, the data it handles and where it runs. Providers may change over time (see section 10).

3. Account security

Access to GateBud is controlled through individual user accounts.

• Authentication. Users sign in through our authentication system, which is built on a reputable managed authentication provider.
• Multi-factor authentication (MFA). MFA is not currently available for customer sign-ins. GateBud's administrative access to production infrastructure is protected by MFA (see section 6).
• Password security. Passwords are stored using industry-standard one-way hashing by our authentication provider; GateBud never stores plain-text passwords.
• Session management. User sessions are managed securely, with sign-in tokens handled according to current best practice.
• Role-based permissions. Access within an organisation's account is governed by roles, so users see and do only what their role allows.

4. Data protection

• Encryption in transit. All connections to GateBud are encrypted using HTTPS/TLS. Data moving between you and the platform is protected in transit.
• Encryption at rest. Customer data is encrypted at rest where supported by our infrastructure providers.
• Data segregation. GateBud is a multi-tenant platform. Each organisation's data is logically separated, and access controls are enforced at the database level (row-level security) so one customer cannot access another customer's data. Cross-tenant isolation is verified by automated tests that run before every release.
• Access controls and least privilege. Access to production systems and customer data is restricted to the people who genuinely need it, on a least-privilege basis.
• Secure backups. Customer data is backed up daily. Backups are protected by the same access controls, and an independent encrypted copy is held with a separate provider. See section 7.

5. Application security

We build and maintain GateBud with security in mind throughout the development process.

• Development and review. Changes follow a review and testing process before release.
• Deployment safety. Our normal release process verifies changes in a separate staging environment before production. Production deployments are atomic, and releases can be rolled back if a problem is detected.
• Dependency management. We use well-maintained, reputable libraries and keep dependencies reasonably up to date, applying security updates as needed.
• Vulnerability remediation. We monitor for issues in our own code and in our dependencies, and prioritise fixing security-relevant problems.
• Logging and monitoring. We use error-tracking and logging tools to detect, diagnose and respond to problems.

GateBud is not currently ISO 27001 or SOC 2 certified.

6. Operational security

• Change management. The normal process is develop, review, test on staging, then release to production, with the ability to roll back. Emergency changes follow a separate controlled process.
• Monitoring. We monitor platform health and errors and are alerted to significant issues.
• Incident response. We have a process for responding to security and availability incidents (see section 8).
• Access reviews. Access to production systems and administrative tools is limited to those who need it and reviewed periodically.
• Administrative controls. GateBud's own administrative access to production infrastructure and provider accounts is protected by multi-factor authentication and least-privilege principles.
• Personnel confidentiality. Everyone who works on GateBud is bound by written confidentiality and intellectual property terms before they start.
• Device security. We maintain a device security policy requiring disk encryption, screen locks and multi-factor authentication on any device used for GateBud work, and we keep an inventory of the hardware and services that hold data.

7. Backup & recovery

• Daily backups. Customer data is backed up daily through our managed database infrastructure. In addition, an encrypted copy of the database and of uploaded files is stored each day with a separate, independent provider and kept for 30 days, so a backup exists outside our primary infrastructure.
• Disaster recovery. Our reliance on managed, redundant cloud infrastructure supports recovery from most infrastructure-level failures.
• Restoration testing. A database restore drill is scheduled monthly. It restores an off-site database backup into a temporary test environment and checks key tables and data. This database check does not establish that uploaded files or staff sign-in have been restored end to end.

We do not currently guarantee a specific recovery time objective (RTO) or recovery point objective (RPO) unless separately agreed in writing.

8. Incident response

If a security or availability incident occurs, we follow a high-level process designed to limit impact and keep customers informed:

1. Detect. Identify the issue through monitoring, alerts, or a report.
2. Investigate. Assess what happened, what is affected, and how serious it is.
3. Contain. Take steps to stop the issue spreading and limit its impact.
4. Recover. Restore normal, secure operation.
5. Notify. Where an incident materially affects customer data, notify affected customers without undue delay, and provide information to help them meet their own obligations. Customers with a signed agreement are also covered by its breach notification terms.
6. Learn and improve. Review what happened and make changes to reduce the chance of it recurring.

Notification timing depends on the nature and severity of the incident. We act as quickly as reasonably practicable.

We maintain a documented incident response plan, including ransomware scenarios.

9. Privacy

GateBud handles personal information in accordance with the New Zealand Privacy Act 2020 and the Information Privacy Principles.

• How we handle information collected through our website and direct dealings is described in our Privacy Policy.
• How we handle personal information within customer data on our customers' behalf is set out in your signed agreement, this page and our Subprocessors page.

Customers own their data. We process it to provide and support the service. PostHog usage analytics for signed-in staff is linked to their account. Microsoft Clarity records use of the staff dashboard with screen content masked and staff account and organisation labels attached. Clarity does not run on public visitor check-in pages. The Privacy Policy explains the information collected and how it is used.

10. Third-party providers

GateBud uses third-party providers for hosting, storage, authentication, email delivery, monitoring, analytics and similar operational services. We assess providers based on the service they supply.

The providers we use may change as the platform evolves. Every current provider is listed on our Subprocessors page. When we add, remove or change a provider, we update that page. Customers with a signed agreement are given notice of changes as that agreement sets out, at least 30 days for a material change. We remain responsible for our providers' performance in connection with the Services.

11. Customer responsibilities

Security is a shared responsibility. There are practical steps every customer can take to keep their own account secure:

• Use strong, unique passwords for GateBud accounts.
• Protect the email account you use to sign in to GateBud with multi-factor authentication. A compromised inbox is the most common way any account gets taken over.
• Manage user permissions, giving each person only the access they need.
• Remove access promptly for people who leave your organisation or change roles.
• Keep devices secure, including keeping browsers and operating systems up to date.
• Report suspicious activity to us as soon as you notice it.

12. Responsible disclosure

We welcome reports from security researchers and customers who believe they have found a security vulnerability in GateBud.

• How to report: email security@gatebud.com with details of the issue and, where possible, steps to reproduce it.
• What to expect: we aim to acknowledge reports within 3 business days, then investigate and address the issue.

Please act in good faith, avoid accessing or modifying other people's data, and give us reasonable time to respond before disclosing an issue publicly.