Security Policy

How Propsena protects the data it is trusted with, what we commit to when something goes wrong, and how to tell us about a vulnerability.

Last updated September 14, 2026

In short

  • Tenant isolation is a database policy, not an application convention, and a test proves it on every build.
  • Sensitive fields are encrypted with AES-256-GCM; all traffic is encrypted in transit; backups are encrypted and restore-tested weekly.
  • Every change leaves an immutable audit record. Support access is read-only and logged.
  • We are SOC 2-aligned, hosted in the United States, and publish our subprocessors.
  • Found something? We acknowledge good-faith reports within 3 business days.

Our approach

Propsena holds the records a property management company runs on: tenant and owner details, leases, ledgers, payments and communications. We treat that as a duty, not a feature. Security is designed into the platform at the layer that cannot be bypassed from application code, and every control described here runs in production today.

Our controls are mapped to the SOC 2 Trust Services Criteria and verified continuously in our build pipeline. We describe ourselves as SOC 2-aligned; we do not claim a SOC 2 attestation until an independent auditor has issued one. Customers and prospects can request the current control matrix by email.

Platform controls

Tenant isolation, enforced by PostgreSQL

Row-level security on every organization table, forced for the application role. A bug in application code cannot reach another company’s data — and a test proves the isolation on every build.

RLS + FORCE on every org table · isolation proof in CI

Encryption by default

AES-256-GCM protects SSNs, tax IDs, OAuth tokens and connected-service credentials at rest; TLS protects everything in transit. Keys rotate with zero downtime.

AES-256-GCM at rest · TLS in transit · zero-downtime key rotation

Identity and least privilege

A dedicated, self-hosted OpenID Connect identity provider, six scoped roles, a staff-only API surface for portal users, and read-only impersonation for support.

OIDC identity provider · 6 roles · portal fence enforced by tests

Immutable audit trail

Every mutation writes an audit record with who, what and when. The general ledger is append-only: corrections post reversing entries, never edits.

Append-only audit log · append-only ledger

Hardened perimeter

HMAC-SHA256, timing-safe verification on every inbound webhook, rate limiting on every endpoint, strict CSP and HSTS headers, and schema validation at every boundary.

HMAC webhooks · rate limits · CSP + HSTS · Zod at the edge

Continuous assurance

A vulnerability gate and verified-secret scanning on every commit, a weekly OWASP ZAP scan of staging, and a weekly backup restore drill that proves the backup is real.

Dependency + secret gates · weekly ZAP · weekly restore drill

Data protection

  • Tenant isolation in the database. Every organization-scoped table has row-level security enabled and forced for the application database role, so a query can only ever see the organization it is running for. An automated test proves the isolation on every build.
  • Encryption at rest. Social Security numbers, tax IDs, OAuth tokens and connected-service credentials are encrypted at the field level with AES-256-GCM using keys held outside the database. Keys rotate without downtime. Disks and backups are encrypted by the cloud provider.
  • Encryption in transit. All traffic uses TLS, and browsers are told to use HTTPS only through HTTP Strict Transport Security with preloading.
  • Backups. A full logical backup runs nightly, write-ahead logs stream continuously for point-in-time recovery, and a backup is taken before every schema migration. Every Monday an automated drill restores the latest backup into a disposable database and checks that the data, the ledgers and the security roles came back intact.
  • Data location. Production systems and backups run in Google Cloud data centers in the United States.
  • Error telemetry. Application errors are reported to a self-hosted monitoring service, with personal data scrubbed before the report leaves the server.

Identity and access

  • Sign-in is handled by a dedicated, self-hosted OpenID Connect identity provider. Propsena never stores passwords. The provider supports multi-factor authentication, and we recommend it for every user.
  • Six roles (administrator, property manager, maintenance, owner, tenant, vendor) limit what each person can see and do. Owners, tenants and vendors reach only a portal-scoped API surface; the staff surface is fenced off and the fence is enforced by automated tests.
  • Propsena staff reach the platform administration area only through a separate sign-in restricted to an allow-list of named accounts. When support needs to see a customer’s account, it does so in a read-only impersonation mode that is time-limited and recorded in the audit log.
  • Production infrastructure is reached through the cloud provider’s identity-aware access layer; there are no shared credentials and no public database ports.

Secure development

  • Every input is validated against a schema at the boundary, and every inbound webhook is verified with a timing-safe HMAC-SHA256 signature before it is processed.
  • Every request is rate limited, and strict Content Security Policy and related headers are sent on every response.
  • Every change is reviewed and must pass automated tests, a dependency vulnerability gate that blocks known high-severity issues, and a scan for verified leaked secrets before it can be merged.
  • A weekly OWASP ZAP scan runs against the staging environment, which mirrors production.
  • Every mutation in the application writes an audit record with who did what and when; the general ledger is append-only and corrections post reversing entries.

Monitoring and incident response

Health checks, error monitoring and the audit log give us the signal to detect problems early. When a security incident is suspected we triage it, contain it, preserve the evidence and fix the cause. If an incident results in unauthorized access to a customer’s data, we notify that customer without undue delay and within 72 hours of confirming it, share what we know, and cooperate with the customer’s own obligations to notify affected people. Every incident closes with a written review and the follow-up work it produced.

SOC 2 control map

Trust services criteriaControls in productionStatus
SecurityDatabase-enforced isolation · encryption · identity · hardened perimeter Implemented
AvailabilityNightly encrypted backups · weekly restore drill · health checks Implemented
ConfidentialityField-level encryption · PII masking · least privilege by role Implemented
Processing integrityAppend-only ledger · idempotent payments · immutable audit trail Implemented
PrivacyUS data residency · scrubbed error telemetry · CCPA-ready Implemented

Controls are mapped to the SOC 2 Trust Services Criteria and verified continuously in CI. Ask us for the current control matrix.

Subprocessors

These providers process customer data on our behalf. We give customers notice before adding one. How each is used is described in our Privacy Policy.

ProviderPurposeLocation
Google Cloud PlatformApplication hosting, PostgreSQL database, file storage (Cloud Storage), the self-hosted identity provider, encrypted backupsUnited States
Google Gemini APIAI features: the Propsena assistant, drafting, triage, summaries and screeningUnited States
Google Maps PlatformAddress lookup and autocompleteUnited States
StripeSubscription billing for Propsena plans; rent and fee payments through Stripe ConnectUnited States
TwilioSMS delivery and inbound text messagesUnited States
OpenPhoneBusiness calling and texting for customers who connect itUnited States
LiveKitReal-time voice calls inside the team collaboration hubUnited States
ResendTransactional email (receipts, reminders, notifications, demo confirmations)United States
DocuSignElectronic signatures for leases and documentsUnited States
Intuit QuickBooksAccounting sync for customers who connect itUnited States
ZillowListing and valuation data for customers who connect itUnited States
Lob and PostGridPrinting and mailing of physical noticesUnited States
PostHogProduct analytics: page views and usage eventsUnited States
CrispSupport chat shown during onboardingEuropean Union

Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability in propsena.com, the Propsena application or its portals, tell us and we will work with you to fix it.

How to report

  • Email info@propsena.com with “Security” in the subject line. Our contact details are also published at /.well-known/security.txt.
  • Include the affected URL or component, steps to reproduce, the impact you believe it has, and how we can reach you.

What we commit to

  • Acknowledge your report within 3 business days.
  • Keep you informed while we investigate and fix the issue.
  • Credit you publicly, if you want us to, once the issue is resolved.
  • Not pursue legal action against research conducted in good faith under this policy, and, if a third party does, make it known that your research was authorized.

Ground rules

  • Only test accounts and data you own or are authorized to use. Never access, modify or delete another user’s data; stop and report as soon as you have evidence of a vulnerability.
  • No denial of service, no spam, no social engineering of our staff or customers, no physical attacks, and no testing of third-party services we use.
  • Do not exfiltrate data beyond what is needed to demonstrate the issue, and delete anything you retrieved once you have reported it.
  • Give us a reasonable time to fix the issue before disclosing it publicly; we ask for 90 days, or sooner once a fix has shipped.

We do not currently run a paid bug bounty program. Reports about missing best-practice headers on non-sensitive pages, rate-limit behaviour without a demonstrated impact, or findings from automated scanners without a working proof of concept are appreciated but treated as low priority.

What we ask of customers

Security is shared. We ask every customer to:

  • Use strong, unique passwords and turn on multi-factor authentication.
  • Give each person the least role they need, and remove staff who leave the same day.
  • Protect the credentials of the services you connect, and disconnect ones you no longer use.
  • Keep the devices used to reach Propsena updated and locked.
  • Report anything suspicious, including lost devices and phishing, to info@propsena.com immediately.

Security contact

Mail
Propsena, Inc.
30 N Gould St, Ste R
Sheridan, WY 82801, USA