Security & Trust

BRE Pulse LLC  ·  Last Updated: October 23, 2026

This page explains how BRE Pulse LLC ("BRE Pulse," "we," "our") protects the data our customers and their business communities trust us with on the brepulse.com platform. It is a plain-language companion to our Privacy Policy and Terms of Service, not a replacement for either.

Access controls

Every organization on the platform is isolated from every other organization; server-side authorization checks run on every request, not just in the interface.

• Roles. Within an organization, an owner or admin manages who has access. BRE roles (owner, admin, staff) govern what a person can see and edit; confidential business records are further restricted to a named project team where the organization sets that.
• Passwords. Passwords are never stored in plain text. We store only a PBKDF2-SHA256 hash (100,000 iterations, a unique random salt per account) — we could not recover your password even if compelled to.
• Sign-in and sessions. Every sign-in is a session recorded on our side. You can see where you are signed in and end any session; organization owners and admins can sign a member out everywhere. Changing or resetting a password ends your other sessions. Failed sign-in attempts are rate-limited to slow down password-guessing.
• Multi-factor authentication (MFA). Organization accounts can enable MFA using an authenticator app plus one-time recovery codes, with a controlled process to reset MFA if a device is lost.
• Single sign-on (SSO). Organization accounts can connect their own identity provider over OpenID Connect — Microsoft Entra ID, Google Workspace, or another standards-based OIDC provider — and, where the organization chooses, require it for sign-in.
• Security Center. Organization admins get a Security Center covering active sessions, sign-in history, MFA and SSO status, connected integrations, organization API keys, and recent permission and sharing changes.
• Organization API keys. Keys are scoped to specific resources, named, revocable, and rate-limited. We store only a SHA-256 hash of the key — the full key is shown once, at creation, and cannot be retrieved again.
• Webhooks. Outbound webhook payloads are signed (HMAC-SHA256) so a receiving system can verify they came from us.
• Audit log. Consequential actions — sharing changes, exports, API key and webhook changes, permission and security-setting changes — are written to an append-only audit log that application code never edits or deletes. Sign-in attempts, successful or not, are kept in a separate sign-in history that organization admins can review.

Encryption

• In transit. All traffic to brepulse.com runs over HTTPS (TLS); a plain http:// request is redirected to HTTPS before anything is read or written.
• At rest. Application records and uploaded files are stored with providers that encrypt data at rest.
• Sensitive tokens. Where we hold a credential on a customer's behalf — for example, an OAuth token from a connected Microsoft 365 calendar, or a webhook signing secret — it is separately encrypted (AES-GCM) with a key held outside the database, never in the database in the clear.

Data & AI trust

Our full Data & AI Trust Standard covers source provenance, confidence, human approval and confidentiality levels in detail. In short:

• Where the platform uses AI to draft an answer, summarize a record, or analyze a document, the relevant customer content is sent to the AI model provider named on our Subprocessors page to generate that response. We send only the content needed for that request.
• Business records marked business confidential are restricted to the organization (and, where set, a named project team) — that visibility level is enforced on the server for every read, including AI features, so confidential information stays where its owner put it.
• AI drafts and analyzes; it does not make final decisions. Adverse classifications of a business, pricing and product changes, and anything sent externally pass through a named human before they take effect.
• AI-generated text on the platform is labeled.

Backup & disaster recovery

The application database keeps a point-in-time history from which it can be restored. We test restoring it into a separate database and check every table's row count against the original. Uploaded files (documents, recordings, images) are kept in separate storage from the database.

Where data is

The application database is hosted in the United States. Uploaded files are stored with an eastern North America placement preference; a placement preference is not a guarantee of jurisdiction. Requests to brepulse.com may be handled at the network location nearest the person using the service, which can be outside the United States. Each provider on our subprocessor list processes the data it receives where that provider operates.

Incident response

If you believe you have found a security issue affecting BRE Pulse, or you are a customer reporting a suspected incident, contact us through Support. We investigate reported incidents, and where a confirmed security incident affects a customer's data, we notify the affected customer without undue delay with the details we have and what we are doing about it.

Vulnerability disclosure

We welcome good-faith reports of security vulnerabilities in BRE Pulse.

• How to report. Contact us through Support with enough detail to reproduce the issue (affected URL, steps, and impact). Please do not include real customer or business data in your report.
• Safe harbor. If you make a good-faith effort to report a vulnerability to us privately, avoid accessing or modifying data beyond what is needed to demonstrate the issue, avoid degrading service for others, and give us a reasonable opportunity to fix the issue before any public disclosure, we will not pursue legal action against you for that research and will treat your report as authorized.
• What to expect. A security report is a Severity 1 request under our published response commitments: we respond within one business day — a human reply that acknowledges the report and says what happens next — and then work continuously toward a workaround or a fix. We will tell you what we found and, where a change ships, that it shipped.

Our machine-readable disclosure contact is published at /.well-known/security.txt per RFC 9116.

Data retention, export & deletion

• Retention. We retain account and business data for as long as an account is active or as needed to provide the service. If you close your account, tell us and we delete or anonymize your personal information, normally within 30 days of your request, and confirm when it is done. Security and audit logs, billing records, and anything we must keep by law are retained longer — see our Privacy Policy for the full policy.
• Export. You are not locked in. Depending on your plan, you can export your own data as a report (PDF, Word, or CSV), export your business list as CSV, export a selected map cohort as CSV, or pull records programmatically through the organization API.
• Deletion requests. To request access to, correction of, or deletion of your personal information, contact us through Support.

Subprocessors

We use a limited set of subprocessors — companies that process data on our behalf to provide the service. See the current list, with what each one does and what data it sees, on our Subprocessors page.

Security program

We run an internal security program covering access review, change management, incident response, backups, vendor management, vulnerability management, logging and security policies, and we keep dated evidence of each check we run.

Questions about anything on this page? Contact us through Support.