Security at AryaPM

AryaPM is built inside a working property-management office in Kelowna, British Columbia, so the platform was designed from its first day around three constraints: one property must never see another’s data, a resident must never see more than their own household, and every privileged action must leave a trace.

• Least privilege by default: every role starts with the minimum it needs, and access is widened deliberately, never implicitly.
• Defence in depth: tenancy boundaries are enforced in the database, not only in the application, so a bug in one layer cannot expose data in another.
• Boring, proven infrastructure: we run on established enterprise providers rather than self-hosting, and we keep our footprint small enough to reason about.
• Honesty about maturity: we are a young company and we publish what we have, not what we intend to have.

• Primary storage in Canada: the database, file storage, authentication records and backups are hosted in a Canadian data-centre region operated by an enterprise cloud infrastructure provider.
• Encryption everywhere: all traffic between browsers, our application and our providers uses TLS, and data is encrypted at rest on disk and in backups.
• Backups every six hours, retained for 14 days, stored encrypted and separately from the live database.
• Tenant isolation at the database layer: every client-scoped table carries row-level security policies keyed to the client organisation, so a query from one tenancy cannot return another tenancy's rows even if application code is wrong.
• Transient processing outside Canada: some compute, content-delivery, payment, messaging and screening providers may process data briefly outside Canada, most commonly in the United States, as our Privacy Policy and DPA describe.

• Multi-factor authentication with authenticator apps, available to every user and required for AryaPM staff.
• Passkeys and biometric sign-in on supported devices, so residents and staff can sign in without a password to phish.
• Enterprise single sign-on via SAML for client organisations that request it, so staff accounts follow the organisation's own identity provider and offboarding.
• Role-based access with ten distinct roles, from platform administrator to resident, guest, agent, technician, housekeeping, concierge and security personnel; each sees only the desks and records its role permits.
• Invitation-only accounts: nobody can self-register into a property. Access is granted by an administrator, and every grant and removal is recorded.
• Immutable audit logs for financial records: journal entries, ledger postings and payment events are append-only and stamped with who acted and when, so a balance can always be reconstructed.
• Session controls: short-lived tokens, sign-out on password change, and administrator impersonation that is time-limited and logged.

• Automated dependency monitoring with prompt updates when a vulnerability is published in a library we use.
• Secure development practices: changes that touch authentication, tenancy boundaries, payments or notifications are reviewed before release, and the platform ships in small, reversible deployments.
• Secrets never reach the browser: signing keys, provider credentials and service-role database access exist only on the server and in the deployment platform's encrypted configuration, never in client code or source control.
• Webhook signature verification: every inbound event from a payment, email or messaging provider is verified against that provider's signing secret before it can change a record.
• Server-side authorisation on every write: the browser is never trusted to decide what a user may do; the database policies and server functions re-check on each request.
• Rate limiting and abuse controls on sign-in, invitations and public forms.

Card and bank-account payments are handled by a PCI DSS-compliant payment processor. Payment details are entered on the processor’s hosted, encrypted forms and never pass through AryaPM’s servers or database.

• AryaPM never stores card numbers, security codes or bank-account numbers. We hold only the processor's opaque references and the last few digits it returns for display.
• PCI scope stays with the processor; AryaPM's own responsibility is limited to using the processor's integration correctly and protecting the references it issues.
• Pre-authorised debit mandates, where a client enables them, are collected and stored by the processor under its own compliance programme.
• Refunds, payouts and reconciliation are reviewed by authorised staff and recorded in the immutable ledger.

• Built for British Columbia's Personal Information Protection Act and Canada's PIPEDA, with the client organisation accountable for resident data and AryaPM acting as its service provider.
• A Data Processing Addendum is published and accepted in-app by each client organisation's administrator; it sets out sub-processors, security measures, incident notification and deletion commitments.
• A current sub-processor list, described by category, function and processing location, is available to client organisations on request.
• Resident privacy is enforced in the product: complainant identities stay inside the file, bylaw history is never shown to other residents, and residents see only their own live matters.
• Records retention follows the client's statutory obligations, and exports are available at any time so that the client, not AryaPM, controls its records.

• Six-hourly encrypted backups with 14-day retention give a recovery point of at most six hours for the database.
• The application runs on a managed, globally distributed hosting platform; a failed deployment can be rolled back to the previous release in minutes.
• Uploaded documents and photographs are stored in redundant object storage in the same Canadian region.
• Provider status is monitored, and clients are told promptly when an incident affects the availability of the Service or of a delivery channel such as email or SMS.
• Because the client controls its own exports, no property is ever dependent on AryaPM to retrieve its statutory records.

We welcome reports from security researchers and from the people who use the platform. If you believe you have found a vulnerability, report it to support@aryapm.ca with the subject “Security”. Include enough detail for us to reproduce the issue; we will acknowledge within two business days and keep you informed as we investigate and fix it.

We treat good-faith research as authorised, provided you do not access, alter or disclose data that is not yours, do not degrade the Service for others, and give us a reasonable time to remediate before any public disclosure. We do not currently run a paid bounty programme.

We are working toward an independent SOC 2 Type II examination. Until it is complete, we provide a written summary of our controls and our Data Processing Addendum to clients on request, and we answer reasonable security questionnaires.

We do not claim any certification we do not hold. If a page, proposal or conversation ever suggests otherwise, please tell us at support@aryapm.ca and we will correct it.