Security

BrikMate is a lease-administration product used by commercial real estate teams to extract, abstract, and report on lease portfolios. Customer leases are confidential business documents — protecting them is foundational to our service.

This page describes how we protect customer data: where it's stored, how it's encrypted, who can access it, our sub-processors, our breach-notification SLA, and how to reach our security team. It is intended as an honest, factual summary, not marketing copy.

For the contractual baseline, see our Terms of Service and Privacy Policy. For sub-processor details, see Sub-processors.

At a glance

• Customer data hosted entirely in U.S. cloud regions (Render us-east-1, AWS S3 us-east-1).
• TLS 1.2+ in transit, AES-256 at rest, argon2id for password hashing.
• MFA mandatory on every system that touches BrikMate source code or customer data.
• Multi-tenant isolation at the application, database, and storage layers, including per-tenant S3 buckets.
• 72-hour breach-notification SLA (24-hour internal target).
• SOC 2 Type II observation period beginning Q3 2026; first independent penetration test in the same quarter.
• 100% U.S.-based engineering staff.

Data hosting

BrikMate's production environment runs entirely in U.S. cloud regions:

• Application servers and PostgreSQL — Render (us-east-1, U.S.).
• Object storage — AWS S3 (us-east-1, U.S.).
• Application logs and monitoring — Datadog (us1, U.S.).
• Cloud audit logs — AWS CloudTrail.

No customer data is stored or processed outside the United States. All BrikMate engineering staff are U.S.-based.

Encryption

In transit

Every external connection — browser to application, application to database, application to object storage, application to every sub-processor — runs over TLS 1.2 or higher. HTTP requests are rejected at the edge. Modern cipher suites (ECDHE+AES-GCM, ChaCha20-Poly1305) are required; legacy ciphers are disabled.

At rest

• PostgreSQL — AES-256, cloud-managed key.
• AWS S3 — AES-256 with cloud-managed keys; customer-managed keys (CMK) on the enterprise-tier roadmap.
• Application secrets — managed by Doppler, AES-256 at rest, decrypted only into application memory at runtime.

Application-level

• User passwords are hashed with argon2id (per-user salt; never reversible).
• JWT signing uses asymmetric keys held only in production secrets storage with a documented rotation procedure.

Endpoints

Every laptop with logical access to BrikMate systems is FileVault-encrypted end-to-end.

Multi-tenant isolation

BrikMate is multi-tenant by design. Customer data is isolated at three layers:

• Application layer. Every query is scoped by org_id; cross-tenant queries are rejected by an internal lint rule and reviewed in code review.
• Database layer. PostgreSQL row-level isolation via org_id foreign keys on every customer-data table.
• Storage layer. Each customer's documents live in a per-tenant S3 bucket with IAM bucket policies that restrict access to that tenant's principals.

Access control

We follow a least-privilege model for production access:

• Every employee and contractor uses a named account; shared or pooled credentials are not permitted for human access. The only pooled credentials are service-account credentials for automation, stored in our secrets manager and never used by humans.
• MFA is mandatory on every system that touches BrikMate source code or customer data — Google Workspace, GitHub, Render, AWS, Datadog, Doppler, and every other operational tool. TOTP authenticators or hardware keys are preferred; SMS is used only as a last resort.
• Production console access (Render, AWS, Datadog) is restricted to a small, named set of engineers.
• Production database writes go through code-reviewed migrations; ad-hoc writes are not permitted.
• Access is reviewed at least quarterly across every system.
• Departing employees and contractors have access revoked the same business day, against a documented runbook.

Pre-employment checks

Before access is granted, every employee and contractor signs:

• A Confidentiality / Non-Disclosure Agreement.
• A Proprietary Information & Inventions Agreement (IP assignment).
• An Acceptable Use Policy acknowledgement.
• An Information Security Policy acknowledgement.

Pre-employment background checks are performed via Checkr, administered through our PEO Justworks, covering identity verification, criminal history (county / state / federal), employment verification, and reference checks, with a 7-year U.S. lookback window.

Sub-processors

A current list of named sub-processors is published at brikmate.com/subprocessors. For each sub-processor, the list shows: country, purpose, the categories of data processed, and DPA-on-file status.

Sub-processors are reviewed at least quarterly. Customers under contracts that require notice receive at least 30 days' notice before a new sub-processor is added.

AI and customer data

BrikMate's product uses third-party AI services to process leases:

• Reducto — OCR and document parsing.
• OpenAI and Anthropic — language-model extraction of lease fields.

Inputs and outputs to these vendors run on their commercial / API tiers, where the vendors' terms confirm in writing that BrikMate's inputs and outputs are not used to train their models. Customer documents are sent to these sub-processors only via BrikMate's organizational API keys from backend code, and only to deliver the contracted service.

We do not send customer data to consumer AI tools such as ChatGPT or Claude.ai. Internal use of those tools by BrikMate staff is restricted by our Acceptable Use Policy.

Breach notification

If BrikMate becomes aware of a security breach affecting customer data, we will notify the affected customer within 72 hours of awareness — committed in the BrikMate Master Services Agreement, aligned with GDPR Art. 33 and U.S. state breach-notification laws.

In practice, our internal target is to notify within 24 hours of confirmed awareness, leaving an explicit safety margin against the contractual SLA.

The notice will include: scope of affected data, affected timeframe, what is known about cause and the containment actions taken, and a named BrikMate contact for follow-up. A full post-mortem follows within a reasonable period after containment.

Compliance and audits

• SOC 2 Type II — observation period beginning Q3 2026; report expected 12 months later. Interim readiness exports and Type I report (when available) shareable under NDA.
• Penetration testing — independent third-party penetration test scheduled for Q3 2026; thereafter, the assessment runs annually. Reports shareable under NDA.
• Vulnerability management — application dependencies are pinned via lockfile and reviewed on every change; continuous CI vulnerability scanning is being rolled out in the current operational quarter. Severity-based remediation SLAs (Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days).
• Written policies — Information Security Policy, Acceptable Use Policy, Data Retention & Destruction Schedule, Vendor Risk & Sub-processor Register, Risk Register. Reviewed quarterly. Shareable under NDA.

Reporting a security issue

We welcome reports from security researchers, customers, and the public.

Email: security@brikmate.com

We acknowledge receipt within one business day. Please include:

• A description of the issue.
• Steps to reproduce, if applicable.
• Any relevant URLs, payloads, or screenshots.
• Your preferred follow-up contact.

We do not currently run a public bug-bounty program, but we credit responsible disclosures with the reporter's permission.

Privacy

For details on what personal data BrikMate processes, the legal bases for processing, retention, sub-processors, international transfers, and your rights as a data subject, see our Privacy Policy.

Document history

2026-04-30 — Initial public version.

For the contractual baseline, see Terms of Service. Questions not covered here: security@brikmate.com.

‍