How AvenorOps handles your data

AvenorOps is multi-tenant: every supplier, contract, document and activity record carries the identifier of the firm that owns it (firm_id). Isolation is enforced in two independent layers, so a mistake in one does not expose data:

• Database level. Postgres Row-Level Security policies are enabled on customer tables. The database itself refuses to return rows belonging to another firm, regardless of what the application asks for.
• Application level. Server-side permission checks (assertFirmAdmin / assertGlobalAdmin, centralised in a single module) gate every administrative operation, and queries are scoped by firm before they reach the database.

In plain terms: the application does not simply trust itself to filter correctly. The database enforces the boundary as well.

• Customer data (database, authentication records and uploaded documents) is stored in Supabase — managed PostgreSQL, Auth and object storage.
• The Supabase project runs on AWS in the ap-northeast-2 (Seoul) region. Data residency in New Zealand or Australia is not currently offered; if regional residency is a requirement for your firm, contact us before onboarding.
• The AvenorOps web application is hosted by Lovable, which serves the application and runs its server-side functions.

• Authentication is managed by Supabase Auth. AvenorOps does not store or handle raw passwords; credentials are held and verified by Supabase.
• There is no open self-signup. During the beta, access is invite-only: a request is reviewed and approved by an administrator, and the person then receives a time-limited invitation link. Firm administrators can invite colleagues into their own firm only.
• Access can be revoked immediately and completely. Deactivating a user disables the account at the authentication layer (an account-level ban), not merely with an application flag — existing sessions stop working and the person cannot sign back in. Records they created are retained for audit and ownership history rather than deleted.
• Roles are stored separately from user profiles (a dedicated roles table) to avoid privilege-escalation via profile edits.

avenorops.com

Firm administrators can see exactly who has access, change a person's role, and revoke access immediately from firm settings.

• In transit: all traffic to the application and to the database/API is served over HTTPS/TLS.
• At rest: Supabase provides encryption at rest for the managed Postgres database and object storage as part of its platform (AWS-managed disk encryption). We rely on the platform's guarantee here; AvenorOps does not add an additional application-level encryption layer, and does not operate customer-managed encryption keys.

Third parties that may process or store customer data:

• Supabase (on AWS) — database, authentication, file storage.
• Lovable — application hosting, server-side execution, and the outbound email service used to send transactional and authentication email (invitations, password resets, renewal alerts). Lovable's own downstream email-delivery provider is not something we can independently confirm; we can request written confirmation on request.
• Google Analytics — anonymous usage analytics on the public marketing pages. It is not used to send customer records from inside the application.

We are not aware of any other third party that touches customer data. If you need a formal, contractually-maintained sub-processor list, tell us — it does not exist as a formal document today.

Deleted suppliers, contracts and documents go to a recoverable trash and are permanently removed (including the stored files) after 30 days.

User removal is deactivation, not deletion, so ownership and audit history stays intact. On request, an individual's identifying details (name and email) can be anonymised and their login revoked — their historical records remain, attributed to a generic placeholder, so ownership and audit trails aren't broken.

Deletion of a firm's entire dataset works on a defined schedule, not an open-ended one: once AvenorOps schedules a firm for deletion (at the firm's request), a 30-day grace period applies — the schedule can be cancelled at any point before then — after which an automated job permanently deletes everything for that firm: suppliers, contracts, policies, documents (including stored files), users and their logins. A full export of the firm's data can be provided before deletion proceeds.

What isn't yet formalised: there's no committed turnaround time for how quickly AvenorOps schedules a deletion once requested, and this remains a process an AvenorOps admin carries out on the firm's behalf rather than a self-service button in the app. A fully self-service flow is planned before general availability.

AvenorOps is an early-stage New Zealand company. We do not hold SOC 2, ISO 27001, or any other third-party security certification, and we have not undergone an independent security audit or penetration test. We make no claim of alignment with any formal security framework.

We would rather tell you that plainly than imply otherwise. If your due-diligence process requires specific answers — a security questionnaire, architecture detail, or written confirmation of any point on this page — send it through and we will answer it directly and honestly.

Security questions, vulnerability reports, or due-diligence requests: security@avenorops.com.

If you believe you have found a vulnerability, please report it to that address before disclosing it publicly, and include enough detail for us to reproduce it. We will acknowledge reports and keep you updated on the fix.